PR
図1 ソフトウェア・プロダクトライン<BR>一つの開発プロジェクトから,アーキテクチャ構築のための開発プロセスを分離する考え方。米Microsoft社が提案する新たなソフトウェア開発の基盤技術(開発プロセスや開発ツールの支援機能などから成る技術群)である「Software Factories」でも提示されている。図の左側が,アーキテクチャ構築のための開発プロセス。このアーキテクチャに基づいて開発されたフレームワークやコンポーネントの成果物を資産として,右側のプロダクト生産,つまり通常の開発プロジェクトでカスタマイズして再利用する。こうすることで,長期的に複数の開発プロジェクトで再利用される資産としてのアーキテクチャ構築と,短期的な1度限りの要求に基づく開発プロジェクトの開発プロセスを分離する。
図1 ソフトウェア・プロダクトライン<BR>一つの開発プロジェクトから,アーキテクチャ構築のための開発プロセスを分離する考え方。米Microsoft社が提案する新たなソフトウェア開発の基盤技術(開発プロセスや開発ツールの支援機能などから成る技術群)である「Software Factories」でも提示されている。図の左側が,アーキテクチャ構築のための開発プロセス。このアーキテクチャに基づいて開発されたフレームワークやコンポーネントの成果物を資産として,右側のプロダクト生産,つまり通常の開発プロジェクトでカスタマイズして再利用する。こうすることで,長期的に複数の開発プロジェクトで再利用される資産としてのアーキテクチャ構築と,短期的な1度限りの要求に基づく開発プロジェクトの開発プロセスを分離する。
[画像のクリックで拡大表示]
図2 現状分析に基づいてシステムを開発&lt;BR&gt;問題領域にある現状の課題を分析し,適切なモデル表現で課題の解決や要求を加味した理想的問題領域を定義する。次に,その理想的問題領域をITで実現する理想的解決領域の定義にマッピングし,最後にモデル表現を洗練(詳細化,具象化)して,実装レベルの解決領域の定義として解決策を提供する。現状の問題領域を,直接,実装レベルの解決領域に対応付けないのには理由がある。抽象化したモデル表現を構築することで,現状の業務や実装技術の制約に依存せず,経営上/業務上の課題と要求だけを分析/解決可能なモデルを資産として残せるからである。
図2 現状分析に基づいてシステムを開発<BR>問題領域にある現状の課題を分析し,適切なモデル表現で課題の解決や要求を加味した理想的問題領域を定義する。次に,その理想的問題領域をITで実現する理想的解決領域の定義にマッピングし,最後にモデル表現を洗練(詳細化,具象化)して,実装レベルの解決領域の定義として解決策を提供する。現状の問題領域を,直接,実装レベルの解決領域に対応付けないのには理由がある。抽象化したモデル表現を構築することで,現状の業務や実装技術の制約に依存せず,経営上/業務上の課題と要求だけを分析/解決可能なモデルを資産として残せるからである。
[画像のクリックで拡大表示]
図3 SOAによるシステム構築&lt;BR&gt;社内にある既存のシステムを利用して,電子商取引システムを実現する例。バックエンドにある各部門の業務システムが既に持っているアプリケーションやデータベースを有効活用するために,各機能をWebサービスとして公開する。Webサイトの運営に必要な処理は,Webサービスを組み合わせて実現する。
図3 SOAによるシステム構築<BR>社内にある既存のシステムを利用して,電子商取引システムを実現する例。バックエンドにある各部門の業務システムが既に持っているアプリケーションやデータベースを有効活用するために,各機能をWebサービスとして公開する。Webサイトの運営に必要な処理は,Webサービスを組み合わせて実現する。
[画像のクリックで拡大表示]

アーキテクチャを独立させる

 開発対象となるシステムのアーキテクチャも,個別の開発プロジェクト内に閉じたものと考えてはならない。変化しない個所として切り出されたアーキテクチャを,複数プロジェクトで横断的に再利用することを考える。このため,個別の開発プロジェクトで一体的に扱うのではなく,アーキテクチャを扱う独立した開発プロセスが必要だ。例えば,ソフトウェア・プロダクトラインの採用などが考えられる(図1[拡大表示])。特に要求の多様化に伴ってさまざまなバリエーションを持つ製品開発では,要求の多様性に依存しない共通した基盤をアーキテクチャとして構築し,維持することが重要である。この基盤は,一つの開発プロジェクトだけでは構築できない。

 これに加えて,最近の品質管理に対する意識の高まりから,テスト作業も個別の開発プロジェクトから分離する傾向にある。大規模開発では以前から専任のソフトウェア品質管理チームを設けていたが,ウォータフォール型の方法論の枠内に限定されていたため活動に制約があった。これからは品質管理を開発プロセスとして独立させ,要求定義やアーキテクチャ構築との開発プロセス上の関係を再構築する必要がある。品質管理をソフトウェア開発の構成要素としてとらえ,その独立性と一貫性を考えるべきだ。

現状分析の方法も変化すべき

 これに応じて,現状分析の方法も変える必要がある。これまでは,現状分析に基づいて課題を明確化し,課題の解決と将来システムに寄せられるであろう要求を加味して,新規システムの開発計画を立てていた(図2[拡大表示])。つまり,現状分析に時間やコストをかけるのが当たり前だった。

 しかし,全体最適化を考える必要がある現在では状況が異なる。システムのスコープが相当大規模になるため,現状分析をすべて実施するとコストや時間が膨大になる。また時間がかかると,抽出された分析結果がすでに時代遅れになっている可能性も出てくる。本来,システムの全体最適化では,現状分析の結果を重視すべきではない。将来やりたいことを実現するための制約や課題を明確化するのが肝要だ。だから現状分析は必要最小限にとどめてよい*3

 現状分析では,ソフトウェア資産として存在する各種のデータとアプリケーションを詳細化し過ぎないことも大切だ。一定の抽象レベルで整理,体系化すべきである。そして,非効率的な部分,冗長性を持つ部分があっても,すべて効率化しようとしてはならない。長期的な視点を持って,効率化するのに有効な個所,ボトルネックが生じている個所に着目する。

 ボトルネックが生じている個所は,システム間の結合を密にして冗長性を排除したデータモデルを構築したり,分散処理をできるだけ起こさない構成にする。その他の部分は,現状資産を有効に活用するために,SOAによる疎結合技術を適用する方法が有効だろう(図3[拡大表示])。もちろん,それによって非効率な部分は多少残るかもしれない。例えば先に述べたデータの孤島化は解消できないかもしれない。しかし,将来的にそれがボトルネックにならないと考えられる場合は経済性を優先することも必要だ。つまり,コストや時間とのバランスを考えた技術と開発アプローチを選択し,モデルの詳細レベルを決定することが必要なのである。

 以上,今回はソフトウェア工学をめぐる問題について,技術進化の方向性,ならびに開発プロセスの観点から検証してきた。次回はコンポーネント開発,アスペクト指向パラダイムなどを取り上げてさらに考察を加える。最後に,進むべき方向性への提言を与えたい。

萩原 正義 Masayoshi Hagiwara/マイクロソフト Software Architect

1993年マイクロソフト入社。北海道大学,早稲田大学非常勤講師。.NET開発,アーキテクチャの調査研究と技術啓蒙に従事。アスペクト指向,フレームワーク実装技術,開発方法論,データ中心アプローチとオブジェクト指向分析/設計との融合,モデル駆動型アーキテクチャ,サービス指向アーキテクチャなどが現在の興味対象。趣味は,IT業界の著名人との雑談とウィンター・スポーツ。ソフトウェア技術の発展に貢献することが夢。