統合開発環境への歩みが遅いようだが(20051024)

2005.10.24

統合開発環境への歩みが遅いようだが

　オープンソースの使用がようやく当たり前になってきたという話をよく聞く。
　と言っても、特定の仕組みに慣れきっている人達が、そう簡単に他のものに変われる訳がなかろう。

　しかし、ソフトウェア開発の共通プラットフォームだけは別だと思う。
　これだけは、スムースに入っていく可能性が高い。

　JAVAを使う企業用のプログラム開発者がEclipse⁽¹⁾利用を使う人が急速に増えているという。
　誰でも無償で使えて勉強もし易いから、急速に普及していると見る人が多いようだが、機能の拡張性が優れている上、インターフェース機能が軽いので人気があると見た方がよいと思う。

　統合開発環境と呼ばれるこのプラットフォームがオープン化されたのは2001年11月のことで、それほど昔の話ではない。短期間のうちに、流れは急速に進んだのである。

　これはこれで重要な流れだが、あくまでも企業用プログラム開発の話である。

　こうした流れは、日本の産業の根幹である機器用プログラム開発でも進む筈と思うのだが、まだ奔流というほどではなさそうである。
　どうするか考えあぐねているのだろうか。

　言うまでもないが、機器用プログラム開発とは、「組み込みソフト」のことである。この分野では、使用されるプロセッサや、リアルタイムのOSにも様々なものがある。
　普及しているOSでも、各社各様だったりして、プログラム移植ができなかったりする。それでも、次第に集約化されているのは間違いないが。

　そんな状況下で、すべてを包含する共通の開発環境を作り、ミドルウェアを簡単に使えるようにしようというのがオープンソース型統合開発環境の一番の意義である。

　オープンソースなら、特定のプロセッサやOSに依存することを避けることができるから、長期的に見ればメリットは大きいという考え方である。
　しかし、その流れは、さほど進んでいないように見える。

　検討する時間をとるどころではないというのが実態かも知れないが。

　実際、組み込みソフト分野はどうしようもないほど多忙である。技術仕様の進展が早い上に、要求が厳しいからである。
　多くは、納期が半年程度である。しかも、多少の問題は目をつぶる開発という訳にはいかない。障害発生の際に問題回避ができないと商品化できないからだ。基本的な信頼性のレベルも高い。
　やっかいなのは、ハード条件の縛りだ。リアルタイム稼動の条件や、消費電力制限は当たり前で、その割にはプロセッサ能力やメモリ容量は小さい。職人芸的な綱渡りを要求されていると考えてよかろう。
　市場での競争が激しくなっているから、この傾向はますます顕著となろう。

　従って、人材の量も質も絶対的に不足している。

　こんな状況にもかかわらす、日本企業では、開発スキル標準を決めている企業は一部に留まっているそうだ。⁽²⁾
　そこで、業界としては、お墨付きがついた認定制度を普及させようと頑張っているようである。

　スキル標準が無いのは、この分野では、階層構造化やモジュール化に消極的だったからだと思う。そのため、類似のプログラムを、それぞれの企業が、いや、それどころか、企業内でも、何回でも作ったりしている。もともと効率は悪い。
　「組み込みソフト」で機器の違いがでてしまうから、このような効率化を避けてきたのである。
　今後人は増えないのだから、これでは早晩行き詰まりかねまい。

　仕組みの転換が必要だと思うのだが。

　その一案は、マルチプロセッサ/OSで、ミドルウエアによる機能拡張型の統合開発環境の導入ではないかと思う。

　そもそも、「組み込みソフト」の一番の特徴は、半年という短納期の割には、関係する技術分野が極めて広く、技術変化が激しいという点にある。
　製品開発プロジェクトの組織を見ると感覚的にわかる。

　　製品開発総責任者
　　　｜
　　　システム開発責任者
　　　　｜
　　　　・組み込みソフト開発責任者
　　　　　 - アプリケーション開発責任者
　　　　　 - システム設計担当
　　　　　 - ＱＡ担当
　　　　・ハードウエア開発責任者
　　　　・調整役
　　　　・プラットフォーム担当
　　　　・サポート部隊
　　　　　 - テスト
　　　　　 - 開発環境
　　　　・組み込み関連特定技術導入部隊
　　　　・アフター担当

　ソフトウエア、ハードウエア、外部大規模システムとの通信が互いに深く絡みあっているのだ。そのなかで、製品の多機能化が要求される。

　日本の組織の強みは、こうした“ごちゃ混ぜ”の組織を上手く運営できる点にある。互いの議論のなかから知恵を生み出す仕組みが奏功している訳だ。特に、ハードウェアとソフトウェアのトレードオフ評価では抜群の強みを発揮している。
　しかし、その強みは思っている以上に脆弱な基盤の上で成り立っているのかもしれない。参加メンバーは、あくまでも、既存の開発環境のもとで鍛えられているからだ。

　これからは、巨大な外部システムと機器が繋がる時代である。そうなると、インターフェースの問題が重要になってくる。
　こうなると、“ごちゃ混ぜ”部隊の知恵を入れて、組み込みソフト開発者が力を発揮するには、膨大な労力が必要となろう。「エミュレーター、デバッガ、アセンブラ、コンパイラ」のセットでのスキルを持っているだけでは力は発揮できまい。例えば、上手くいく例を導入したくても、扱っていないプロセッサ、OS、ミドルウエアで稼動しているプログラムには手がでまい。
　決して、個人の能力不足でできないのではない。取り入れたとしても、本当に繋がるとは限らないからである。しかも、解決策の手引きはない。こんなスキルをゼロから蓄えようと考える人などいまい。

　こうなると、“プロセッサ→ボード→ハード制御→OS→領域別ミドルウエア→特定ミドルウエア→アプリケーションソフト”のすべてを統合できる開発環境に進まざるを得ない。
　しかも、それが、特定プロセッサに基づくものではなく、マルチプロセッサ/OSが必要なのである。

　そうなると、この統合環境にのらないミドルウエアは使えなくなる。従って、下手をすると、いままで利用してきた自社製ミドルウエアは捨てなければならなくなるかもしれない。
　そして、この流れに乗らないプロセッサやOSは、特定分野で標準になれない限り、ニッチ品と化す可能性が高い。

　この流れを頭で理解していても、なかなか乗れないのが現状のようだ。
　しかし、乗るつもりがないのなら、どうすべきか決断すべき時だろう。

　決断を延ばせば、どうなるかはわかっていると思うが。

　--- 参照 ---
(1) http://www.eclipse.org/
(2) 経産省/IPA「2005年版組込みソフトウェア産業実態調査　報告書」[2005年6月]
　　http://www.ipa.go.jp/software/sec/download/files/report/200506/es05r001.pdf

　技術力検証の目次へ＞＞＞　　　　トップ頁へ＞＞＞