インタフェースこそが資産
この記事は，「日経エレクトロニクス」と「日経バイト」が刊行した別冊『組み込みソフトウエア2006---品質管理と開発技法の実践的改革A to Z』の掲載記事を抜粋したものです。詳細はこちら。
ソフトウエアのアーキテクチャについては，部分部分の機能をしっかり確立した上で，「インタフェースこそが資産である」という考え方を現場に根付かせることが重要である。よく誤解しがちだが，ソフトウエアのモジュールが資産なのではなく，インタフェースが我々の資産である。
従って，インタフェースを変えてしまうということは，資産を捨てることになる。それぐらいの気持ちで取り組む必要がある。逆にいうと，インタフェースを簡単に変えられない仕組みを，きちんとトップの側が構築してやることが責務だろう（図6）。私は実は着任してまだ半年程度だが，今，必死になって「ソフトウエアが何行あるかは大きな問題ではない。とにかくインタフェースを変えるな」と口を酸っぱくして言っている。
図6 統合設計チームによる大規模ソフト課題の解決
統合設計チームにより，ソフトウエア全体のアーキテクチャの決定や基本性能の検証をする。これにより「インタフェースこそ資産」という価値観を開発組織全体に徹底させ，簡単にインタフェースを変更できないような環境を整備する。
インタフェースを大事にするということは，要はソフトウエア資産として内部にきちんと蓄積するということである。特にこのソフトウエアを資産化する，プラットフォームを構築するというときに，トップダウンの力が必要になる（図7）。
どういう力が必要かというと「やめさせる」ということである。トップダウンでできることの一番のポイントは「やめさせる」という点である。現場は止まらない。それぞれの機能を担当している部署，新機能を開発しているエンジニア達は，当たり前のことだが，自分で自分のことを止めない。エンジニアはみな新しい機種に新しい機能を入れようと，必死になっている。
図7 プラットフォーム型開発でソフトウエア資産を共用化
ソフトウエアの構造をさまざまな機器間で統一し，共通のハードウエア・プラットフォーム上でソフトウエア・プラットフォームを確立する。
従って，トップの最大の責任は「おまえ，それやめろ。その機種に入れるな」「おれの責任だから，このモジュールは次の機種に回してくれ」と決めて，そう言うことだ。現場で，自分で自分を止めるような聖人はいない。みなギリギリまで頑張ってしまうものだ。
もう1つは開発プロセスのあり方である。ウオーターフォール型で開発を進めてしまうと，事業者などからの仕様変更がギリギリの段階で来ることもある。やはり反復型の開発で，段階ごとにキッチリと作り上げていくプロセスを取らないと，実際には時代に追い付いていけない（図8）。
図8 ウオーターフォール型から反復型に
ウオーターフォール型の開発プロセスの場合，下流工程でアーキテクチャ上の不具合が発生すると，大きな手戻りにより開発工数の増大と納期遅れを招く。反復型であれば，開発の初期段階でこうした不具合を発見可能できる。
Linuxを扱うに当たっては，エコシステムと呼ばれる仲間作りも非常に需要である。世界的には，欧州のWAP Forumを中心とした組織「OMA（open mobile alliance）」や，デジタル家電向けLinuxの推進団体「CE Linux Forum（CELF）」などがある。携帯電話機にLinuxを採用した以上，やはり誰でも簡単にアプリケーションを作ることができて，それらが将来，携帯電話機の上でも簡単に動作するという姿が理想的ではあるが，そういうエコシステムを実現するための仕組みとして，今，こうした活動があるのだと認識している。
図9 オープンソースへの期待
Linux分野には，ツールなどを含めてさまざまなオープンソースのソフトウエアがある。こうしたツールを利用し再利用の促進や開発の効率化を図っていく。
オープンソースのコミュニティについても，やはりLinuxの上にコミュニティの作ったソフトウエアがどんどん載るような形を作っていきたいと考えている（図9）。Linuxは世界中で勉強している学生も多いし，潜在的な人口は圧倒的に多い。ツールもよく調べてみると，本当にたくさんある。先日，Linuxの開発者であるLinus Torvalds氏にお会いしたが，お互いに知らないオープンソースのソフトウエアがあった。Linus Torvalds氏でも知らないのかと思ったが，それくらいオープンソースの世の中は広いし，高いポテンシャルを持っているのだと思う。オープンソースは今出ているものに関しては，バグはほとんどないし，品質は非常に高い。我々もぜひこうしたソフトウエアなりツールなりを活用していきたいと思っている。（つづく）
