コンポーネント開発5つのステップ：コンポーネント開発のキホン（2）

[最首英裕，イーシー・ワン 代表取締役社長（CEO）]

［2-1］コンポーネント化への道筋

　ソフトウェア部品のコンポーネント化というテーマを実ビジネスにしようと考えていた時、私が思い描いていたのは、「ソフトウェア部品産業の創出」という“壮大な夢”だった。つまり、こういうことだ。

　…世の中は次第に知識社会へと移行しつつある。企業の価値は、蓄積される知識をいかに効果的に活用するかという観点で計られるようになってくる。知識を蓄積し、再利用するというメカニズムが達成されれば、知識の提供者と利用者という二元的な関係は消滅し、知識社会の担い手であるナレッジ・ワーカーすべてが、知識の生産者であり提供者であり利用者である、という構図が成り立つのではないだろうか。このような社会において、コンポーネント（という部品）は、それ自体が流通する単位になり、成熟が進むにつれて1つの産業に成長していく…。

　もちろん現実的には、このようなイメージへ一気に到達することは難しい。そのため私は基盤技術をJavaに限定し、いくつかの現実的なステップを設定することで、ソフトウェア・コンポーネントの流通という夢の実現を果たそうとしている。以下、これらのステップを解説しよう。全部で5ステップある。

［1st ステップ：Javaによる開発の実践］

　なぜ、Javaが（ソフトウェアの）コンポーネント化に役立つのか？ 一番大きな理由は、プラットフォームに依存しないというJava特有の要素だ。これまでのプログラミング技術は、ハードウェアやOSなど、特定のプラットフォームに大きく依存してきた。OSのバージョンに依存し、リコンパイルしても利用できないようなソフトウェア・モジュールは、再利用の大きな妨げになる。それ以上の弊害は、ソフトウェア開発に従事しているエンジニアの経験が、特定のプラットフォームに依存してしまうことだ。最近はあまり聞かなくなったかもしれないが、かつてのIT業界は「メインフレーム系ソフトウェア会社」だとか「UNIX系ソフトウェアハウス」といった“看板”を掲げていたものだ。現在でこそ、多くのIT系企業が、メインフレームからオープン系システムへの移行を実践し始めており、多くの場合、彼らはJavaを選択する。その理由はまさに、Javaがプラットフォーム非依存の標準技術であることにある。

［2nd ステップ：コンポーネント・ベース開発の実践］

　オブジェクト指向設計を丁寧に仕上げていれば、コンポーネント化が進んでいくのだろうか？

　コンポーネント化の目的は、知識を蓄積し、再利用しながら、保守性や生産性を向上させることだが、そもそも、ソフトウェアの再利用性を向上させるとは、どういうことなのか？

　対象とするソフトウェアが実現している、もしくは支援している業務は果たして、単独で再利用可能な“単位”なのだろうか？

　コンポーネント化を実現したとしよう。ではそのコンポーネントは誰でも上手に再利用できるだろうか？

　こうしたことを考えていくと、まずは、（社員や外注先を含めた）ソフトウェア開発に携わる関係者全員が同じレベルで実践できる共通の思考方式（あるいは共通のプロセスともいっていい）が必要なのではないか、という壁にぶち当たる。これは、実際の開発作業において、オブジェクト指向設計の精度を上げるということよりも、もっと根本的で重要なことかもしれない。つまり、標準的なアーキテクチャの構築、プロセスを定義する、ということである。

　ある企業のケースを紹介しよう。自社の標準的なアーキテクチャを決定し、それをフレームワークという形で実装した。フレームワークには、その企業グループ全体で共通に使える機能を取り込み、アプリケーション実装者は、比較的単純なモデルでシステムを構築できるようにした。現在この企業は、自社のフレームワークに関するトレーニングコースを開発し、社外のソフトウェア開発企業を含めた標準化を進めている。

　従来のソフトウェア開発は、業務要件をユーザーが定義し、システムをどのように構築していくかは、ソフトウェア開発者側が考えていた。しかし、自社でアーキテクチャの標準を設定し、フレームワークまで構築するという段階にいる企業の場合、顧客企業自身がシステムのアーキテクチャを定義してしまう。開発者側は顧客が設定した“標準”に準拠しながら開発作業を実践することになる。これは開発者側が複数の企業で構成されている場合には特に有効となる。つまり、開発企業各社から提出されるシステム提案のドキュメントは統一感が図れ、その結果、見積り指標も統一される。計画と実績の精査を続けることにより、見積りの精度も向上するのである。

　こうした整備を進めつつ、次のステップに進めるようなコンポーネント・ベース開発を実践していくのである。

［3rd ステップ：コンポーネントの蓄積・再利用］

　コンポーネント化の方向性を統一し、再利用の土台を作っていくことと、実際にコンポーネントを蓄積し、再利用していくことは、かなりレベルの違う話である。前者はつまり、開発プロセスの中に、再利用のためのメカニズムを組み込んでおくということを意味する。

　再利用のメカニズムは、単一プロジェクトだけで成立するものではなく、企業内部全体に作用しなければならない。プロジェクト内部での個別最適と、企業全体の最適化の融合、それを管理する組織とプロセスが必要とされる。第3ステップではこのようなことが重要になってくる。

　ある意味、第3ステップは今まで以上に「場」の存在が重要になってくる。知識を蓄積し、再利用していくための「場」。もちろん、リポジトリ・サーバなどのメカニズムを利用することは必要だが、さらに重要なのは、組織全体に浸透しているプロセスの存在である。そのプロセスに組み込まれて初めてコンポーネントがコンポーネントとして機能し始める。浸透・共有の対象は、システム構築に関わるすべてのスタッフである。つまり、社内外かかわらず、システム構築に関与する人が共有する「場」をいかに構築するかが非常に重要な課題なのである。

［4th ステップ：アライアンス企業間取引］

　第4ステップは、蓄積したコンポーネントを、企業内部の再利用に留めるのではなく、許容する相手にも提供するという段階だ。ここでいう再利用とは、単独のコンポーネントを利用するというだけではなく、ある程度業務として成立するような大きな単位での再利用を指す。EDI（企業間電子商取引）はまさにこのステップに相当するものだが、コンポーネント時代のコンセプトは明らかに違う。

　EDIは、生産者と利用者が明確に区別されていたが、後者は、生産者／利用者の区別をすることなく、相互に価値の増幅を行えるナレッジワーキングの実現を目指すものだからだ。この場合、コンポーネントの提供者はユーザー企業であり、利用者もユーザー企業である。相互にビジネスノウハウを共有することが可能となる。相互に知識や経験を共有するというイメージだ。ただし、両社（あるいは複数の場合もある）ともにユーザー企業であるだけに、両社間（企業間）にはコンポーネント・ブローカーの役割を務める存在が必要である。コンポーネント・ブローカーとは、企業相互で生じるさまざまなギャップを埋め、コンポーネントの正しい適用を提案できる存在である。

［5th ステップ：コンポーネント部品産業］

　この段階は、“部品産業（コンポーネント流通市場）”が成立している、というイメージなのだが、正直言ってまだ確固とした姿を描けているわけではない。そこで交換（流通）するものは、ソフトウェアかもしれないし、ビジネス・モデルとでも言った方がいいものかもしれない。そういう意味で私は、“知の流通”のような形を想定している。

　それは、単一のパッケージソフトウェアに集約させ、ビジネス拡大をしていくというような欧米型のソフトウェアビジネスではない。顧客企業のニーズを拾い上げ、それぞれの顧客に合わせたソフトウェア開発をしていくことに慣れた日本型のソフトウェア開発ビジネスの形態は、知の蓄積や再利用の促進により、他国では達成できないようなレベルでのコンポーネント部品産業創出の可能性を秘めていると思う。