Rogue Engineer's Diary / やさぐれ日記(2005-08-21)

2005-08-21

■ コンポーネント化のコストとパフォーマンス

コンポーネント化というのは半端で無いほどの開発資源の投資を伴う割に、かなり後にならないとその効果が目に見えないという点で、非常に大きなリスクを伴う、一種のギャンブルであるとも言える

というの話の続きを。

■ コンポーネント化のコスト

まず「半端で無いほどの開発資源の投資」とは何を指すかについて整理してみる。下の図はソフトウェアエンジニアリングの古典としておなじみ、Fred Brooksの"Mythical Man-Month"（日本語題は「人月の神話」）の一章"The Tar Pit"から引っ張ってきた図。

この図が言おうとしているのは、

単なる『プログラム』を『プログラム製品』にするには、多様な環境や入力に対し安定した動作を提供し、またさまざまなユーザが利用できるようにしなければならない。これを実現するにはテストおよびドキュメントの整備が要求されるため、3倍の工数が必要となる。
『プログラム』を『プログラミングシステム』にするには、プログラムを部品化（コンポーネント化）し、それら部品の組み合わせによって機能を実現するように構築し直さなければならない。これを実現するには部品ごとのインタフェースを明確に定義すること、さまざまな部品の組み合わせに対応するためにテストを十分に行うこと、等の作業が要求されるため、ここでも3倍の工数が必要となる。
『プログラム製品』あるいは『プログラミングシステム』を『プログラミングシステム製品』へ発展させる場合にも、同様に3倍の工数が必要となる。『プログラム』から『プログラムシステム製品』を作るためには9倍の工数が必要だ。

ということ。ちなみにこの本が書かれたのは今から30年前（1975年）という大昔である。「3倍」とか「9倍」という数字が妥当であるかは議論の余地もあるだろうが、個人的な経験からすると、この値は今もなお、かなりいい線を行っているように思える。

さて、上の図が妥当なモデルであると仮定した場合、コンポーネント化というのは『プログラム製品』を『プログラミングシステム』へ発展させる作業である、ということになる。ということで、工数は3倍、あるいはそれ以上（手持ちの製品において『プログラム』から『プログラム製品』への移行が不十分である場合）となる可能性が出てくる、というワケだ。

これだけでも大変な負担であるが、さらに野心的な目標、つまり自前のコンポーネントアーキテクチャを打ちたてようとした場合においては、その負担はさらにハネ上がる。1990年代を通じて、MicrosoftはCOMとその発展形、Netscape はXPCOM、ジャストシステムはJOCAと、それぞれオリジナルのコンポーネントアーキテクチャを立ち上げようとしていたが、これらのケースでは

コンポーネントアーキテクチャの確立
製品のコンポーネント化

という二つのハードルを超えなければならない。ちなみにNetscapeはこれらに加え、「Javaによる全面的な再実装」まで同時に行おうとしていた。さすがにここまで来ると「野心的」を超えて「無謀」と呼ぶべき域に入り込んでいた、と言えるのかも知れない。

■ コンポーネント化によって得られるパフォーマンス

ではこんなに大きな工数を掛けて（賭けて?）手に入るものとは何であろうか。

製品間での共有型再利用による効果

コンポーネント化によるプログラムの再利用と共有が実現出来れば、工数の削減が可能になる、ということは良く言われる。代表的な例としては、複数の製品で共通した機能を切り出し、コンポーネント化するというのが挙げられるであろう。Microsoft Officeに含まれるWord, Excel, Powerpointなどの各製品において、コマンドバー、Office アシスタント、ファイルダイアログ、スクリプトの操作、などの機能が共通化されていることはご存知の通り。これは一つに、各製品で重複した開発を行わないことによる工数削減効果を期待したものであると言える。

一方NetscapeはVersion6.0で、HTMLのレンダリングエンジン部分をコンポーネント化し、ブラウザ (Navigator)、メーラ(Messenger)、HTMLエディタ(Composer)、プッシュ型配信クライアント(Netcaster)などで共有させようとしていた。無論Netscape CommunicatorのVersion4.0で既に、これらの機能は単一の製品として全て含まれてはいたのだが、実際のところは…

1997年から1998年にかけて、ネットスケープの製品群が抱えていた深刻な弱点として、クライアント機能担当チームの開発者たちが、十分にモジュール化されていないコードを大量に共有していたことが指摘される。これにより生じたスパゲッティコードが原因で、各チームが独立してビルドやテストを行ったり、または各コンポーネントを独立した機能を持つ製品として（個別に）リリースすることはほぼ不可能となっていた。
("Competing on Internet Time" p.202, やさぐれ訳)

といった具合に、コードレベルでの共有が開発の進行を逆に阻害していたようである。これをインタフェースのきちんと定義された、コンポーネントレベルの共有に切り替えることにより、「お互いの足を踏むことなく」各機能の開発チームが作業を進行できるようにすることを目論んでいた、と言えそうだ。

上に述べたMicrosoftとNetscapeの両者の例において、まず共通しているのは複数の製品が関係しているという点だろう。コンポーネントを共有するような製品を数多く持っているようなところでは、当然のことながらコンポーネント化による効果は大きくなる。裏を返せば、単一の製品しか持たない場合にそれをコンポーネント化しても、コンポーネントの共有による工数の削減というものは期待できない。

バージョン間での再利用による効果

また、コンポーネント化では「バージョン間での再利用」と呼ぶべき効果も期待できる。プログラムを明確なインタフェースにより切り分ければ、（理想的には）前バージョンからそのまま引き継いだ「再利用」コンポーネントと、新規コンポーネントを組み合わせることによるスムーズな開発が実施できる（はずである）、ということ。

1996年9月に発売された一太郎7は"JOCA(Justsystem Object Component Architecture)"によるコンポーネント技術を採用していたが、次のバージョンである一太郎8は、そのわずか5ヶ月後の1997年2月に発売されている…実はこの後に「これはバージョン間の再利用の良い例であろう」、と続けるつもりだったのだが、一太郎8が発売された当時の「がんばれ！！ゲイツ君」の記事などを見た限りでは、どうも少々怪しそうだ。ということでこの件に関する見解はしばらく保留しておく。

このようなかたちでの再利用を実現するためには、バージョンが変わった際にコンポーネント間のインタフェースに不整合が出ないような仕組みが必要となる。Microsoft COM (Component Object Model)は、これを最重要課題の一つとしてとらえており、コンポーネントを提供する側と、コンポーネントを使用する側の間で、期待するコンポーネントのバージョンが異なっている場合にも問題が発生しないよう、さまざまな工夫がこらされている。

なお、当然ながらバージョン間での再利用は、コンポーネント化をした後のバージョンでの製品開発において初めて有効になる。コンポーネント化を行った最初のバージョンで掛かったコストを、次バージョン以降で回収していくというカンジと言えば良いだろうか。無論、その間にコンポーネントアーキテクチャが根本から変更されてしまったりすれば元も子もなくなるため、コンポーネントアーキテクチャを新しく作る際には、なるべく長期にわたり使えるようなものを考えなければならない。コンポーネントアーキテクチャを設計する人々の苦労は増える一方である。

(つづく)

[ツッコミを入れる]

ツッコミ・コメントがあればどうぞ! E-mailアドレスは公開されません。

[TrackBack URL: http://fukumori.org/diary/tb.rb/20050821]

本日のリンク元