概要

  UMLのチュートリアルおよびEJBやCOM+に基づいたシステムのモデリング例の紹介を中心とした講演でした。UMLは、２０００年の第４四半期にver1.4へと改訂される見込みのようです。UMLに関しては、ver1.4からver2.0の改訂をコンポーネントモデリングのより良いサポートが大きな課題となっているようです。とは言うもののUML ver1.4^*では、とりあえずコンポーネントの定義がより厳密になったレベルに留まっているようです。すなわち、「複数のインターフェイスを有し、内部的にはソフトウエアコードで構成される、モジュール性のある置換可能なシステムの基幹部分」という定義になったようです。さらに、EJBやCOM+上に構築されたe-コマースシステムを事例に用いて、システムのアーキテクチャがコンポーネントモデルによりEJBやCOM+の違いを超越して統一的に表現できることを示していました。また、EJBやCOM+で登場するデザインパターンやフレームワーク全体をUMLのパターンの記法を用いて論理的な側面（クラス、タイプ、インターフェイス、依存関係）、コンポーネントの側面（コンポーネント、インターフェイス、依存関係）、配置的な側面（タスク、ノード、コンポーネント、依存関係）の３側面でモデリングしたモデルを示していました。

  *10月13日の時点では、UMLver1.4の仕様書は公開されていないようです。

所感

  特に目新しさはなかったのですが、EJBやCOM+による具体的な例を中心としてUMLのコンポーネントモデリングの表現力をレベルアップしようという努力は感じられました。ただ、マイクロソフトの.NET戦略に見られるようにコンポーネントやコンポーネントをサポートするためのプログラミング言語に対する考え方は現在も発展中であり、モデリング言語として効果的にそれをサポートし、多数の人が納得するようなコンセプトや表現方法を発展させるのはまだ時間がかかりそうだなと感じました。

  講演ではUMLと開発プロセスについても少し言及していましたが、講演者がモデルの構成が複雑すぎる点やコンポーネントを中心とした開発への対応が不十分だという点を挙げてUnified Process(UP)[1]に対して批判的な意見であったことを個人的には残念に思いました。講演者が批判している点は、UPを紹介している著作において分析モデル、設計モデル、テストモデル等々が多数のモデルが提案されており、このような多数のモデルの維持も困難だし、モデル間の要素の意味的な関連性も明確ではないということでした。

  UPの著作を注意して(あるいは好意的に）読めば、最低限作成及び維持すべきモデルとしては要求モデル、設計モデル、実装モデル、テストモデルの４種類に過ぎず、実装モデルは実装コードそのものなので実際には実装コード以外に３種類のモデルが加わったに過ぎないということが分かります。だから、UPはモデル数が多くて維持が大変だというKobrynさんの主張はあまり当を得ているとは思えません。また、UPでは要求から設計、実装、テストの成果物に至るまでのtraceabilityが存在しており、他の開発プロセスと比べてモデルの要素間の対応がつきにくいとも思えません。UPの本では要求から設計までに至るまでの手順をねっとりと説明することに拘泥するあまり、UPの本質的な部分の理解が困難になるのかもしれません。

  一方、コンポーネントを中心とした開発で作成すべきモデルとしてKobrynさんが講演で示したモデルは、UPで言うところのアーキテクチャを説明するために作成する4+1モデルビューの概念とそれほど違わないように思いました。UPではアーキテクチャを策定する際に、システムに必要なコンポーネントを識別し、識別されたコンポーネントの組み合わせによりアーキテクチャが満足すべき品質属性（操作性、信頼性、性能、保守性）を満足するか否かという評価を行いながら、アーキテクチャを決定していきます。このような開発手順は、コンポーネントを中心とした開発を推奨するKobrynさんの説明とうまく整合するものであれ、対立するものではないように思えます。Kobrynさんが、コンポーネントを中心とした開発で作成すべきモデルについてUPの本の記述を正しく理解していないのは、UPの本においてアーキテクチャの表現やコンポーネントとアーキテクチャの関係に関する説明が大幅に不足していることが一因となっていると思います。アーキテクチャの表現に関する説明に関しては、RUPの入門書[2]の方が参考になります。ただし、RUPの入門書はアーキテクチャの具体例が挙げられていない点で内容が少し抽象的に思えるかもしれません。

  まとめると、Kobrynさんの主張はUPのコンセプトに対する理解不足に起因する誤解が多いと思います。その一方で、UPの本も本質的な部分を分かりやすく伝えていないという点でそのような誤解を生み出す原因を与えていると思います。

概要

  欧米を中心にソフトウエア開発の生産性を向上させるために取り組まれているSoftware の製品系列化（Product Line）の実践方法に関する講演でした。Product Lineとは、メーカ等で機種の異なった製品に組み込まれるソフトウエア資産（アーキテクチャやコンポーネント）を共通化し、それにより生産性を向上させるというアプローチです。このようなアプローチが今欧米で注目されている最大の理由は、ソフトウエア技術者不足の深刻化のようです。

  このようなアプローチに取り組んで成功を収めた会社として、Celsius Tech社（戦闘艦システム）、Motorola社（単方向ポケベル製品ファミリー）、HP社（プリンターシステム）、Cummins Engine Co(エンジン制御システム)、Nokia社（携帯電話）等々が挙げられていました。これらの成功例では、開発コストの削減、開発期間の短縮、単位期間に市場に投入できる製品バリエーションの増大等が達成されたようです。

  講演の話を総合すると、Product Lineを実現するためには開発組織として以下の４分野に渡って能力を向上させる必要があるようです。

1）ドメインの理解
2）要求（製品系列の仕様）
3）アーキテクチャ
4）コンポーネント

  それらの４点について個人のスキルや創造性に負う部分もあるのですが、１）から４）を効率的に実行するためには組織構造や管理方式も大きく変わる必要があるようです。すなわち、開発組織がなるべく有機的にマーケティング組織や研究開発組織と連携するような組織構造が求められるようです。たぶん、日本でも個別製品毎にプロジェクトチームを組むことはあると思うのですが、Product Lineに対応するために製品系列全体についてプロジェクト組織を組むようなイメージになるのだと思います。

  SEIでは、このような先行的な成功例を研究し、Product Line方式で開発を行うために開発組織が備えるべき基本的な能力としてSoftware Engineering Practice Area, Technical Management Practice Area, Organizational Management Practice Areaの３分野を定義しています。これらのPractice Areaの中でSoftware Engineering Practice Areaのハイライトとそれに対する筆者の見解を、次の解説の節で論じたいと思います。

独断的な解説

  今回の講演でSoftware Engineering面のPracticeとして強調されたのは、要求獲得および管理（要求管理）とコンポーネントに基づくアーキテクチャです。まず、要求管理の面では製品系列の要求を共通性と個別性という観点で分析し、技術的な実現可能を考慮しながら製品仕様の絞込み（Scoping）をしていくという能力が非常に重要になるということです。要求として、なんでもありの総花的で複雑すぎる要求仕様とならないようにスコープ管理をしっかり行いましょうということが強調されていました。また、ソフトウエアアーキテクチャについては、ソフトウエアのFURPS(Functionality Usability　Reliability Performance Supportability)を実現するためのハイレベルの設計思想であり、コンポーネントから構成される構造を有するという立場にたって話が展開されました。アーキテクチャについては、当然のことながらURPSの部分であらわされる品質属性と要求の中の共通性と個別性をサポートするための設計（コンポーネント）構造を両立させることが最大の課題となります。ただし、このようなアーキテクチャをどのように考案するかについては、歯切れの良い答えは提供されていません。優秀なアーキテクトが必要だと主張しているに留まっています。ただ、アーキテクトの介在が必要にせよプロセスとしては「既存製品のソフトウエアアーキテクチャの分析」を行い、「限定された要求内容から出発して、徐々に機能を追加」していき、「アーキテクチャと要求のトレードオフ」を意識しながら開発していく必要を強調していました。また、当然のことながらアーキテクチャの開発にはそれなりの時間を要し、計測的に「新技術の動向を留意し、技術の適用可能性を判断する」ことも必要になります。

  このような主張は、技術的な観点ではUnified Process(UP)やRational Unified Process(RUP)で提案しているプロセスのコンセプトが解決しようとしているものと完全にマッチすると考えられます。例えば、要求の共通性とバリエーションはユースケースモデリングによりユースケースやユースケース間の汎化や拡張という観点で整理できますし、その結果得られたユースケースの構成を反映する形でソフトウエアのアーキテクチャの構造を決定するというUPやRUPの考え方はそのまま使えるはずです。また、要求とアーキテクチャのトレードオフを考えながら、要求のスコープを管理し、反復的にアーキテクチャを発展させるという点でも主張はかなり類似しています。ということでUPやRUPには、Product Lineに対応する統一的な要求、アーキテクチャ、コンポーネントを作成するためにSoftware Engineering上必要なPracticeは盛り込まれているのです。それも、RUPを考案したラショナルソフトウエアがProduct Lineの最初の成功例として挙げられていたCelsius Techの例に深く関与していたことや、UPの主唱者であるJacobson博士はユースケースを考えた一つの動機としてエリクソン社でProduct Lineをカバーする統一的なアーキテクチャを作っていたということを考えれば単なる偶然の一致ではないことがわかります。極論すれば、UPやRUPはProduct Lineに対応する統一的な要求、アーキテクチャ、コンポーネントを作成し、活用するために生まれてきたともいえるかもしれません。

  それでは、UPやRUPを適用することでProduct Lineをサポートする統一化されたアーキテクチャやコンポーネントはかならず得られるのでしょうか？当然、話はそれほど単純ではありません。あたりまえのことですが、UPやRUPは統一的なアーキテクチャを考案するための知的作業を自動化したり、省力化するものではありません。そのため、UPやRUPを導入したからと言って、Product Lineをサポートする統一化されたアーキテクチャやコンポーネントが生まれるというものではありません。結局、プロセスは知的財産の産物であるアーキテクチャから製品を生み出すための手順や方法を一定の範囲で示しますが、それ以上のものではないからです。その一方で、Product Lineを個別の製品に展開したり、アーキテクチャを複数の世代に渡って維持、発展させるためにはプロセスが大きな役割を果たすと期待できます。

  では、アーキテクチャを何とか考案できさえすれば、Product Lineをサポートできるのでしょうか？たぶん、製品開発に関わるビジネスプロセスの能力、技術面と管理面の人材とスキルのレベルが成功、失敗を決める大きな因子として残ると思います。Technical Management Practice Area, Organizational Management Practice Areaの２つの領域は、これらの課題に対応したものです。かなり単純化したレベルで言えば、マーケットとの空間、時間的間合いを詰めるための組織構造やビジネスプロセスが必要になるということです。すなわち、製品の顧客、営業担当者、マーケティング担当者と開発部隊との（空間、時間的）距離、ソフトウエア資産を作る開発チームと個別製品を作る開発チームとの距離を縮めるための組織構造やプロセスへの転換が求められます。開発組織がProduct Lineをサポートする統一化された要求、アーキテクチャ、コンポーネントを開発するための能力を向上させるために組織構造が変わった例として、講演ではCelsius Techの開発組織の変遷が示されました。Celsius Techは、当初プロジェクトマネジャーの下に個別機能、共通機能、システム統合を担当するチームが並列する形の組織構造だったのが、開発チームとアーキテクチャチーム、顧客毎のプロジェクト管理チーム、マーケティングチーム等々に分かれ、現在は開発仕様に責任を持つ２つのビジネスユニット、開発チーム、R&Dグループ、技術企画グループの構成となっているようです。R&Dグループ、技術企画グループは、技術担当の副社長直属の組織となっているようです。このような変遷は、技術中心の水平組織から管理中心の階層組織へと移行し、最終的にはビジネス、開発、R&Dが水平的に連携する組織へと転換していったと解釈することができます。

  このような組織構造やプロセスへの転換の末に実効を挙げるためには、技術面と管理的な面で強烈なリーダシップを発揮する人材が必要になります。すなわち、製品の顧客、営業担当者、マーケティング担当者と開発部隊の代表者を一斉集めた中で建設的な製品のビジネスおよび技術的ビジョンを取りまとめることができるかなり強力な手腕が求められるのだと思います。そのためには、労務管理面での管理とは別にProduct Lineのアーキテクチャを理解し、そのアーキテクチャと製品の仕様のトレードオフを判断するような技術管理的なスキルを有する人材が必要になると言えます。この技術管理的なスキルを、NorthropさんはTechnical Management Practice Areaのキーポイントとして強調していました。たぶん、Celsius Techの例で登場するR&Dグループ、技術企画グループを統括する技術担当の副社長はまさにこのような技術管理的な職務に対応するものだと考えられます。

所感

  日本のソフトウエア産業が今後国際的な競争力を増すためには、Product Lineをサポートする統一化されたアーキテクチャやコンポーネントを作りあげられるような開発組織への転換が大きな課題になると思います。その転換のためには、単に開発プロセスを現代化するだけでは十分でなく、組織構造、ビジネスプロセス、人材という面でも既存のやり方を変える必要があることを強く感じました。また、転換できるかどうかについては経営者と従業員が国際的な競争力に対する危機感と既存のやり方を思い切って変えるチャレンジ精神をどれだけ抱けるかにかかっています。

  もし日本の会社が転換できなかったら、どうなるのでしょうか？転換できなかった場合に、至る結末には２種類のシナリオが描けるのではないでしょうか。最初のシナリオは、ソフトウエア開発能力に対する海外依存性が高くなるというシナリオです。すなわち、海外で統一化されたアーキテクチャやコンポーネントを開発し、国内でコンポーネントのアセンブリーを行うというような構図が生まれてくるでしょう。ちょうどそれは、ハードウエア中心の製品に対して大手メーカが取っているアプローチの裏返しのようなソフトウエアR&Dの空洞化現象といえるかもしれません。もう一つのシナリオは、統一化されたアーキテクチャやコンポーネントを提供する専業のベンダーが国内外に現れるというシナリオです。すなわち、既存の国内メーカの開発組織やその協力会社が分社化、スピンアウト、提携により、アセンブリーメーカとコンポーネントメーカへと再構成されるということになります。この場合、コンポーネントメーカは、複数のメーカに対してコンポーネントを供給する形でビジネスを行うというイメージになります。コンポーネントメーカのモデルの方が、ビジネスの目標が明確になり、小回りが利く組織作りが可能だという点では有利だと考えられます。競争力のある製品仕様やアーキテクチャを考案できる潜在能力を持った人材を発掘し、ドメインをうまく選べば国際競争力のあるコンポーネントメーカは日本においてもどんどん育つ可能性はあるのではないでしょうか。

   参考文献

[1]Jacobson, Ivar et al: "The Unified Software Development Process", Addison-Wesley, 1998.
   (邦題：UMLによる統一ソフトウエア開発プロセス、翔泳社、2000)
[2]Kruchten, Philippe: "The Rational Unified Process - An Introduction", Addison-Wesley, 1998.
   (邦題：ラショナル統一プロセス入門、ピアソン・エデュケーション、1999)^*

  *[2]の原書は、今年の４月に第２版に改訂されました。邦訳は、今年の年末から来年早々に出版されそうです。

© 2000 OGIS-RI Co., Ltd.

HOME TOP