連載 次世代開発基盤技術“Software Factories”詳解 第8回 ソフトウェア工業化の未来 ―― Software Factoriesとソフトウェア・セル生産方式 ―― マイクロソフト株式会社　萩原 正義 2005/11/19
Page1 Page2

◆周辺工学技術から見たSoftware Factoriesの位置付け

　ここでは、いくつかの周辺技術の観点から、Software Factoriesの位置付けを評価してみよう。

（1）開発プロセスの適正さ

　開発プロジェクトに合わせた開発プロセスの適正化を図らなければ、成果物、ドキュメント、モデルの開発と保守やレビューなどの負担が増大し、かえって問題となる。

　プロジェクトの規模が大きくなれば、より分散化した複雑な技術が適用され、ステークホルダー数は増加し、より厳格な規約に従う必要がある。しかし、小規模なプロジェクトでは、開発プロセスは軽量であるべきである。つまり、レガシー・システムのバージョン・アップ、システム間連携、リアルタイム、組み込み系などの大規模プロジェクトでは、分散チーム開発、標準化や契約や法令上の要求など外部的制約が必要であるが、Webアプリケーション、パッケージ・アプリケーション、コンポーネント指向開発などの中規模プロジェクトやプロトタイピングなどの小規模プロジェクトでは、少人数チーム、内部規定などで十分で、開発プロセスの必要性は小さくなる。

　開発組織はプロジェクトの各繰り返しやプロジェクト終了ごとに結果の検証を行い、常に開発プロセスの改善に努力しなければならない。Software Factoriesが採用するプロダクトライン開発、ソフトウェア・セル生産方式におけるセルの組み合わせの変更などによるアジャイル開発は、こうした開発プロセスの一般原則に従って、検証され採用されるべきである。

（2）並列開発による開発生産性の改善

　ソフトウェアの開発生産性の改善では、できるだけ並列開発可能な部分を増やすことを考えなければならない。つまり、開発プロセスのタスク構成では、1タスクの完了を待って次のタスクが実行可能となるような効率の悪い開発をできるだけ避けなければならない。開発プロセスで並列開発を可能とするには、開発プロセス全体を特定の分割単位で構成し、その単位で並列に作業を進められる枠組みが必要である。

　プロセスを分割する有力な手段は、モデルを導入することである。例えば、ユースケースやストーリーは要求定義のモデルであると同時に、開発プロセスを分割する単位でもある。セルはソフトウェア・セル生産方式が提供する作業単位で開発プロセスの分割単位である。

　分割単位や作業単位だけでは必ずしも並行開発が可能となるわけではなく、逐次開発が避けられない場合も存在するが、同一の作業単位を複数同時に実行したり、1つの作業単位を複数の開発プロジェクトで併用したりして開発生産性を改善することが可能である。

　ユースケースやセルのもう1つの特徴は、モデルのスコープによる分割のため、そのモデルが定義する作業項目と、そのモデルの作業項目を実行する開発者の割り当ての分離が可能な点である。

（3）一度限りの開発からプロダクトライン開発への移行

　現在は、OOA/D開発方法論のUP（Unified Process：統一ソフトウェア開発プロセス）やRUP（Rational Unified Process：ラショナル統一プロセス）に見られるように、1つの開発プロセス内で要求定義、アーキテクチャ構築、設計、実装、テストをすべてカバーする開発スタイルが主流である。アジャイル開発プロセスも基本的にはプロジェクトの要求をストーリーで定義し、テストで仕様化して開発を進める。

　つまりこれらの開発プロセスは、単発の一度限りで完了する開発スタイル（ワン−オフの開発）である。これらの開発では、ソフトウェア資産として、コンポーネント、フレームワーク、パターン、コーディング・イディオム、テスト、設計モデルなどを再利用して生産性を高めようとしている。

　しかしながら、生産性をより高めようとするならば、ソフトウェア資産は、複数のプロジェクトにまたがる長期的な視野で構築しなければならないし、そのための要求定義、保守の方法、モデル化を考えなければならない。また、開発プロセス自体の再利用も考える必要がある。こうしてみると、単にコンポーネントなどの成果物、つまり、ソフトウェア資産だけの再利用と、その技術だけを中心に考える開発スタイルはすでに限界にあると考えた方がいいだろう。

　現在の開発環境は、開発ツールのデフォルト設定を見て分かるように、ワン−オフの開発スタイルを前提としている。これが近い将来、ソフトウェア・プロダクトラインがデフォルト設定となり、その特例としてワン−オフの開発スタイルが存在するような立場の逆転が起こるであろう。

（4）ソフトウェア・セル生産のセルの構築法

　ソフトウェア・セル生産方式ではセルの作業範囲を決定する必要がある。ただしまだ新しい技術であるため、決定のための確立した方法があるわけではない。現在、筆者が考えている方法は、以下の図3で説明されるDSM（Design Structure Matrix）*14という開発プロセスの分析手法を活用することである。

*14 DSMについての説明は、「The Design Structure Matrix - DSM」 を参照のこと

　DSMはカリフォルニア州立大学名誉教授のDonald Steward氏がGEに在籍していた当時、原子炉設計を支援するために開発したプロセス分析手法である。従来のプロセス分析手法であるPERT（Program Evaluation and Review Technique）チャートやガントチャートがタスクの実行順序だけを表現するのに対して、DSMはタスク間の情報の流れに着目する。

　DSMは業務プロセスを構成する各タスク間で交換される情報の流れを単純化するため、時間的に後続のタスクが先行タスクへ情報を提供して手戻りを生じさせる場合や、情報交換が時間順序の離れ過ぎたタスク間で行われていて密な連携がとれない場合を分析する。

　分析によって見つかった問題は、タスクの並べ替えによる手戻りの回避、連携を密にするタスクのグループ化で解決する。このタスクをセルでの作業として置き換えれば、セルの構成順序や連携の方法に一定の規則を与えることが可能であると考える。

図3 DSMの説明（参考文献からの引用、筆者訳）

　図3において、業務プロセスを構成するタスクAとBの関係には、並列、逐次、相互依存関係にあるカップル化の3種類が存在する。図内の図形表現はタスクを長方形として、この3種類の関係を示す。その下にあるマトリックスは、この図形表現をタスク間の情報の流れで示したDSM表現である。このようにDSM表現はマトリックスで表され、横軸はタスクが別のタスクに情報を提供する際の提供元、縦軸はタスクが情報を提供する際の提供先を示す。

　DSM表現のマトリックスに記述された“X”は横軸のタスクから縦軸のタスクへの情報の提供が行われていることを示す。タスクAとB間に情報のやりとりが存在しなければ、両タスクに依存関係は存在しないので、並列に実行可能である。タスクAからタスクBへの情報提供があれば、タスクAからタスクBへの順序で実行可能である。

　タスクAからタスクBへ、かつ、タスクBからタスクAへの双方向の情報交換が存在する場合、業務プロセスでいずれかのタスクを時間的に先行させても、後続のもう1つのタスクから先行するタスクへの情報提供が存在するための手戻りが発生する。こうした手戻りが不可避である場合は、できるだけ業務プロセス上の時間順序が近接するタスクとしてグループ化することで、手戻りの影響を小さくすることが可能である。

　DSMはこのようなマトリックスに基づき、タスクの配列を好ましい順序に変えることで業務プロセス実行を改善する分析手法である。

（5）要求モデルとソフトウェア資産モデルのインピーダンス・ミスマッチ

　UPのような方法論、アジャイル開発、モデル駆動型開発、プロダクトライン開発を問わず、どんなソフトウェア開発であっても、「開発対象のソフトウェアが実現すべき要求（機能要求、非機能要求）」と「要求を実現した成果物」の間には、インピーダンス・ミスマッチが存在する。

　ここでいうインピーダンス・ミスマッチとは、両者の間に完全に可逆的なトレーサビリティの構築ができず、モデルで表現した場合は、要求モデルとコンポーネントなどの資産モデル間にモデルの意味的なギャップが存在することである。

　ソフトウェア工学の発展は、再利用性を追求してきた歴史であると同時に、この両者間のギャップを埋めてきた歴史でもある。ギャップを埋めることによって、要求の変更や、コンポーネントを動作させるIT技術の変更が発生した場合に、その変更を他方へ速やかに波及させ、変化への迅速な対応を可能とする。あるいはギャップを埋めることで、技術の複雑さを隠ぺいして管理する抽象レベルの高い厳密なモデルの定義が可能になる。

　しかし実際のところ、両者のギャップは大きく、完全な解決を見ていない。その本質的な理由は、要求が「何をしたいか」を表現し、比較的短期で変化しやすい傾向にあるのに対して、ソフトウェア資産が「どうあるべきか」を表現し、資産という性格上、長期に変化しないことが望まれるためである。

　資産が長期間変化しない方が望まれるのは、その方が保守が容易でコストがかからないからである。一方、ビジネスの要求が短期的に変化してしまうのは、少しでも収益を高めるために他社との差別化を絶えず目指すからである。つまり、資産でコストを下げるか、要求で収益を上げるかは、IT技術から見て根本的課題である。

　この難問の解決に対してはいくつかのアプローチは存在する。第1のアプローチでは、資産モデルを要求モデルに近づけギャップを埋めようとする。これはUMLコンポーネントなどに見られる方法である。

　逆に、要求モデルを資産モデルに近づけてギャップを埋めようとするのが、第2のアプローチだ。これはユースケース定義を拡張してアスペクト指向設計に結び付ける方法*15である。

*15 “Aspect-Oriented Software Development with Use Cases”, Ivar Jacobson, Pan-Wei Ng, Addison-Wesley, 2005, ISBN 0321268881

　また第3のアプローチでは、要求モデルでも資産モデルでもない中間のモデルを用意して、両者のモデルを中継しようとする。これもアスペクト指向を上流に導入した「テーマ」アプローチ*16などである。「テーマ」は本連載の「第4回 フィーチャの実現法とサブジェクト指向パラダイム」で紹介したサブジェクト指向パラダイムを進化させたモデルである。

*16 “Aspect-Oriented Analysis and Design: The Theme Approach”, Siobhan Clarke, Elisa Baniassad, Addison-Wesley, 2005, ISBN 0321246748

　Software Factoriesでは、フィーチャを要求モデルから資産モデルへ近づける上記の第2のアプローチを採用している。今後は、可変性の分析と実現にアスペクト指向分析設計を組み合わせた、より有効な方法を取り入れると予想される。

◆本連載の終わりに

　本連載を開始したとき、現在のソフトウェア開発の困難を解決するための1つの方法として、ソフトウェア開発の工業化の必要性を説いた。そしてこの工業化を推進することを前提に連載を進めてきた。しかし、ほかの産業に見られるように、工業化の推進は同時にさまざまな問題を引き起こす。

　1つの大きな問題としては、過度な効率化の追求が、ソフトウェア開発の創造性を損なうことである。

　Software Factoriesとソフトウェア・セル生産方式は、ソフトウェア資産と開発プロセスを再利用することで開発を効率化する。しかし、常に同じソフトウェア専門分野を担当してセル生産を実行する開発者が、やる気を持って開発を進められるかどうかを考えなければならない。プロダクトライン開発をするアーキテクトや、プロダクト生産のプロジェクト管理をするプロジェクト・リーダーと同じくらい、セル生産を実行する開発者が自分の責務にやる気や誇りを持って、より高い次元の開発力を身に付けていくための仕組み、プラクティスを尊重しなければならない。

　筆者はどちらかというと、アジャイル開発よりも工学的アプローチを重視する立場を取っている。しかし、開発者のやる気や誇りを尊重し、顧客のビジネス価値、および、ソフトウェア技術、産業を高めていく点では両者の立場には違いがないと思っている。

　いずれにしても、過去からオブジェクト指向、コンポーネント、フレームワーク、サービス指向と、ソフトウェアやシステムの再利用を目指してソフトウェア工学技術は進んできた。その延長として、ソフトウェア・プロダクトラインやプロセスラインの考え方も必ず普及するものと思われる。仮にSoftware Factoriesが存在しなくても、別の技術は登場するであろう。

　われわれソフトウェア技術者は、来るべき時代に備えた姿勢を取る必要がある。開発者の2極化の問題に対応するため、パラダイム、上流と下流、OOA/Dとデータ中心とSOA、コードによる開発とモデル駆動型開発、Javaと.NETなど、異なる技術を中立に見ていく柔軟性を取らなければならない。

　そして何より大切なのは、技術に対する深い好奇心や興味を持ち、誇り高い技術者を目指すことであろう。

萩原 正義 Software Architect

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

　

INDEX
	次世代開発基盤技術“Software Factories”詳解
	第8回 ソフトウェア工業化の未来
	1．Software Factoriesの全体構想における最新動向
	2．周辺工学技術から見たSoftware Factoriesの位置付け

　

「次世代開発基盤技術“Software Factories”詳解」

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）