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

Page1 Page2

Back Issue

1 ソフトウェア工業化を目指して 2 開発手法「ソフトウェア・プロダクトライン」とは？ 3 長期的な要求を定義するフィーチャ・モデル 4 フィーチャの実現法とサブジェクト指向パラダイム 5 ビューポイントによる関心の分離と開発プロセスの実現 6 DSLによるモデル駆動型開発 7 Software Factoriesによる可変性を管理したモデル駆動型開発の例

　この連載を開始したとき、ソフトウェア産業には、オブジェクト指向、コンポーネント・ベース開発、フレームワークの採用、パターンの発見と適用、アーキテクチャの構築、繰り返し型の開発、テスト駆動、ユースケース駆動などの＜要素技術＞が整いつつあるが、産業の成熟度が低いことから、ソフトウェア開発における＜全体構想＞の欠如がかえって鮮明になりつつあることを述べた。つまり全体構想を明らかにすることで、要素技術の採用理由、目的への適合性が判断可能になる。

　この最終回では、Software Factoriesの全体構想における最新動向と、ほかのソフトウェア工学周辺技術と比較した場合の位置付けを解説する。

◆Software Factoriesの全体構想における最新動向*1

　われわれ（MAAC：Microsoft Architect Advisory Councilの名で呼ばれるアーキテクトの集まり）はSoftware Factoriesを日本人の手で次世代開発基盤技術として改良しようとしている。大きく分けると改良点としては、Software Factoriesがスコープとしていない「要求開発との連携」と「プロダクト生産のカスタマイズで利用する開発プロセスの資産化」である。

　前者はOpenthology 1.0の仕様*2を、後者はソフトウェア・セル生産方式*3を使う。いずれも米マイクロソフト社のSoftware Factoriesには含まれていない。この改良点の意味するところは、Software Factoriesがこの分野での問題解決をあいまいにしているということだ。

　要求開発方法やプロダクト生産のカスタマイズで利用する開発プロセスは、Software Factoriesでは任意の方法を選択することが可能である。しかし、本来ソフトウェアの工業化においては、規定すべき部分はきちんと定義すべきであると考える。この改良点はいずれ書籍にまとめて世界に発信したいと考えている。

*1 検討中の内容を含むため最終的な仕様は変更の可能性がある。

*2 「要求開発アライアンス」を参照のこと。

*3 「松本吉弘博士のサイト」を参照のこと。

　さて、この現在開発中のSoftware Factoriesでは、ソフトウェア開発基盤は以下の4つの資産管理法で実現される。

（1） 要求開発資産： プロセス・キャビネット、プロセス・セル
（2） 要求定義： ビジネス・ケーパビリティ・グリッド
（3） プロダクトライン資産*4： プロダクトライン・グリッド／ビューポイント、アーティファクトなど
（4） プロセスライン資産*5： ソフトウェア・セル

*4 Software Factoriesはソフトウェアの可変性管理のためのドメイン工学は必須とするが、プロダクトライン開発は実は必須としない。従って、プロダクトライン開発のチーム・モデル、開発プロセスは必須ではないが、ドメイン工学から得られる資産の管理は必要である。ここでは、簡単のためにこの資産をプロダクトライン資産と呼んでいる。

*5 プロダクトラインがソフトウェアの成果物（アーティファクト）を扱いファミリー化するのに対して、プロセスラインは開発プロセスを成果物として扱いファミリー化する。Software Factoriesでは、この2つの資産管理を明確化していない。

　この4つに集約された資産管理法は、ソフトウェア開発基盤の全体構想のキーポイントである。以下、それぞれを詳しく説明していこう。

（1） Openthologyによる要求開発資産の管理法

　要求開発では、PDCA（Plan-Do-Check-Act）のサイクルに従って要求が開発される。そこでPDCAの各段階と準備／立案／デザイン／移行の各フェイズのマトリックスを作成する。準備フェイズのPlanの段階では、全体計画、要求開発チーム策定計画など、マトリックスのグリッドのそれぞれで必要となる作業項目を定義していく。

　各フェイズ分けに関しては、準備フェイズでは初期知識の可視化と合意に基づく計画を、PDCAが一巡した次の立案フェイズではビジネス課題に関する概観の可視化を行う。こうしてできたマトリックスで管理される、要求開発プロセスのPDCAの各段階と各フェイズでの成果物（資産）を収容する論理的なコンテナをプロセス・キャビネットという。

　実際の要求開発では、プロセス・キャビネットから全体計画に関するPDCA、教育に関するPDCAなどを取り出し、PDCA単位の組み合わせで全体のスケジュールを実行する。このPDCA単位で成果物を管理するのがプロセス・セルである。つまりプロセス・セルは、プロセス・キャビネットの再利用単位である。

　プロセス・セルは、要求開発プロセスの逐次実行作業の単位であるが、複数のプロセス・セルを並行して実行することは可能である。例えば、準備フェイズ計画セル、要求開発チーム策定計画セル、教育計画セルを順番に並べて逐次実行する場合や、準備フェイズ計画セルを実行後、要求開発チーム策定計画セルと教育計画セルを並列に実行するために、作業を分岐することも可能である。

　次に、プロセス・セルを組み合わせたプロセス・セル・パターンを使い、組織的なプロセス再利用を行う枠組みを考える。この構築されたプロセス・セル・パターンから、プロセス・セルの中身を分解してWBS（Work Breakdown Structure）表を作成して工程管理表とし、工数、予想期間を入れる。また工程管理表とリソース（開発メンバー）を見ながら、プロセス・セルをスケジュール表に組み込む。

　現在、要求開発プロセス・セルは標準化を策定中である。

（2） ビジネス・ケーパビリティ・グリッドによる要求定義の管理法

　Openthologyの要求開発など*6で定義された要求は、次にSoftware Factoriesのプロダクトライン資産として開発される。そのためには要求定義をビジネス･ケーパビリティ・グリッドの形式に再定義する。

*6 そのほかの要求開発方法で要求を定義してもよい。

　OpenthologyではPDCAサイクルで要求開発プロセスの関連成果物が管理される。これは要求開発プロセスを駆動するうえでは便利な資産管理法であるが、いったん開発された要求定義を管理する形式としては適切ではない。そこで要求定義は、経営的な執行レベル／組織の役割と、適切な関心のマトリックス形式に再定義する。このマトリックス形式をビジネス・ケーパビリティ・グリッドと呼ぶ。

　ビジネス・ケーパビリティ・グリッドは、執行レベルのstrategy（戦略）／tactics（戦術）／operations（業務）の分類と、関心のenterprise（ビジネス）／information（情報）／application（アプリケーション）／technology（技術）の組み合わせのグリッドである。

　例えばinformationの関心では、strategy執行レベルには価値分析、価値評価基準策定、KPI（Key Performance Indicator：重要業績評価指標）策定、戦略策定、投資およびROI（Return On Investment：投資利益率）評価が存在し、tactics執行レベルにはエンタープライズ・アーキテクチャ／ビジネス・エンティティ設計が存在し、operations執行レベルにはビジネスシステム・プロトタイピングおよびto-be事業組織評価が存在する。

　このマトリックスにより、要求定義は経営の視点で管理される。ビジネス・ケーパビリティ・グリッド形式は意図的に、次に説明する（3）のプロダクトライン資産のプロダクトライン・グリッドの形式に類似させている。これにより、要求定義はプロダクトライン開発に従った、コンポーネントやフレームワーク、開発ツールなどのソフトウェア資産に対応付けられるようになっている。

（3） プロダクトライン・グリッド／ビューポイント*7によるプロダクトライン資産の管理法

　Software Factoriesはドメイン分析を行うことで、長期的な視点でソフトウェア要求を資産化する。上記（2）の分類で提供される要求定義をソフトウェア・スコープへの要求として分析し、可変性を切り出す。ここでは、長期的視点で見て共通の要求部分と、可変性を持ち選択的な要求部分を分離し、フィーチャ・モデルを作成する。

　一方では、ソフトウェアを資産として管理するうえで便利な資産管理法を考慮する。資産管理法では、カスタム開発要求に対して資産を効率的に活用するためのマトリックス形式のメタデータを利用する。これをプロダクトライン・グリッドと呼ぶ。

*7 「第5回 ビューポイントによる関心の分離と開発プロセスの実現」の表2の説明では、簡単のために、プロダクトライン・グリッドがビューポイントに等しい分類の例を示しているが、実際、両者は異なっていてもよい。例えば、ビューポイントはEA（エンタープライズ・アーキテクチャ）の関心以外に、ドメイン、フィーチャ、既存資産などで定義することも可能である。この表2では、プロダクトライン・グリッドをセルと呼んでいたが、ソフトウェア・セル生産方式のセルとの区別のため、ここではプロダクトライン・グリッドと呼び直している。

　このプロダクトライン・グリッドは、プロダクト生産プロセスにおけるカスタマイズを駆動するビューポイントの基盤になるため、開発プロセスのフェイズをマトリックスの軸として持つ必要があり、概念／論理／物理のフェイズの軸を持つ。しかし、そのほかの軸としては、関心の形式に限定される必要はない。ここでは典型的なenterprise／information／application／technologyの関心の形式を想定する。

　図1は、プロダクトライン・グリッドをプロセス・キャビネット、ビジネス・ケーパビリティ・グリッドとともに示している。

図1 Openthologyのプロセス・キャビネット、プロセス・セルとSoftware Factoriesのプロダクトライン・グリッド／ビューポイント、ソフトウェア・セル生産方式のセルの関係

図の左下のプロセス・キャビネットのマトリックスに従い、要求開発はPDCAサイクルを取りながら、準備／立案／デザイン／移行の各フェイズで駆動される。実際の要求開発プロセスは、プロセス・キャビネットから再利用可能な作業項目を取り出し、それぞれの作業項目から逐次実行作業の単位であるプロセス・セルを作り、プロセス・セルを組み合わせたプロセス・セル・パターンで構成する。次に、要求開発の結果、成果物として得られた要求定義は、図の右下のビジネス・ケーパビリティ・グリッドのマトリックス形式に再定義され、Software Factoriesを用いたソフトウェア開発につなげる。ビジネス・ケーパビリティ・グリッドはSoftware Factoriesの資産管理法であるプロダクトライン・グリッド形式に類似し、ITにより実現される場合の資産の開発と再利用の体系化につなげる。プロダクトライン・グリッドは、関心が分類されたマトリックス形式の資産管理法である。この資産管理法を使い、プロダクト生産でのカスタマイズを行うためには、プロダクトライン・グリッドをプロダクト開発者の役割に応じた関心の集合にグループ化したビューポイントを定義する。ビューポイントを複数組み合わせて、プロダクト開発者が行う作業を定義し、Software Factoryとしてパッケージ化して開発者ごとの開発環境を配布する。プロダクト生産はFactoryを実行する各開発者の作業範囲をセルで定義し、セルを連鎖的に実行することで全体の開発プロセスを実行する。

　ソフトウェア資産をプロダクトライン・グリッドで分類、体系化することで、プロダクトライン・グリッドの関心の分離で強制的に管理される。

　しかし、このプロダクトライン・グリッドによる分類法は、ソフトウェア技術での関心で分類、体系化されるため、実際のプロダクト生産で使い勝手がよいとはいえない。そこでソフトウェア開発担当者のスキル、組織的な役割や責務を考慮して、プロダクト生産プロセスを駆動するための別のスコープによる資産の分類法が必要である。すなわち、プロダクトライン・グリッドに加えて、プロダクト生産のカスタマイズで必要となる資産の組み合わせを開発者の使い勝手の観点で分類する、人間中心の分類方法が求められる。

　Software Factoriesのビューポイント*8は、プロダクト生産のカスタマイズに必要な資産を複数のプロダクトライン・グリッドからまとめたスコープである。

　ビューポイントの例としては、問題分析やアプリケーション・アーキテクチャ策定のビューポイントが考えられる*9。プロダクト生産のカスタマイズでは、プロダクトライン・グリッドの（複数の）グリッドで定義されるビューポイントを複数組み合わせた開発プロセスを作成する。これにより開発プロセスはビューポイント駆動で実行される。

*8 「第5回 ビューポイントによる関心の分離と開発プロセスの実現」を参照のこと。

*9 勘のいい読者は要求開発でのプロセス・セルと類似点が多いことが分かるであろう。

　このビューポイントに、フィーチャ・モデルに基づいて実現されるソフトウェア成果物を登録して資産の再利用を行う。

　既存のソフトウェア資産は必ずしもビューポイントの分類に合致しない場合があるが、複数のビューポイントから共通の既存資産へのリンクを持つことを許容すれば、既存のソフトウェア資産は必ずしもビューポイントの分類と合致しなくても再利用可能である。

　また、ビューポイントで管理する成果物（アーティファクト）は調達を含むため、開発済みの資産だけでなく、資産の利用時に調達すべき成果物を含めることも可能である*10。

*10 納期の条件に合わなければ同一仕様の成果物を別の場所から調達することが可能である。

　成果物を利用する際に必要なテスト駆動のための仕様、その限られたスコープで有効となるパターン*11、カスタマイズに必要な微視的なプロセスなどもビューポイントで一体に管理される。

　さらには、そのビューポイントのスコープでカスタマイズに利用するDSL（Domain Specific Language）も設計、実装して管理される*12。DSLはほかのソフトウェア成果物がビューポイントに登録されるとき同時に登録され、ビューポイントの成果物の一部であるアーキテクチャのホットスポットへの設定、分離された関心でのカスタマイズ・コードを生成する機能を持つ。

*11 一般にパターンはスコープを限定しないと有効とならない。ここではパターン利用のスコープをビューポイントで強制する。

*12 ここではモデル駆動型開発で利用するDSLの重要性よりも、カスタマイズを支援するツールが成果物として資産管理されることを強調している。

　次に、組み合わされた複数ビューポイントに含まれる各種の成果物（コンポーネント、フレームワーク、DSL、テスト、パターン、微視的な開発プロセス、ガイダンスなど）の開発環境一式をパッケージ化してプロダクト開発者の開発環境に配布する。配布にはチーム開発サーバなどを用いる。この配布されるパッケージはビューポイントを組み合わせたFactoryスキーマ定義から構成され、Factoryテンプレートと呼ばれる。

　Factoryスキーマ定義は開発環境のパッケージ、Factoryテンプレートの構成定義といえる。配布を受けた開発者の開発環境にロードされ、プロダクト生産に利用される環境がSoftware Factoryの実体である。図2はFactoryスキーマ定義をグラフィカルに表現した例である*13。

*13 Factoryスキーマ定義のメタモデルはまだ公式に仕様化されていない。

　

図2 Factoryスキーマ定義のグラフィカルな表現例

プロダクトライン開発では、関心が分離された資産モデルの体系、プロダクトライン・グリッドを構築する。ビューポイントは、特定のプロダクト生産での開発プロセスに合わせてプロダクトライン・グリッドをグループ化した関心の集合であり、可変性を提供する再利用可能な資産を持つ。プロダクト生産ではプロダクト開発者の役割に従って作業が行われ、作業に必要となる関心を複数のビューポイントとして選択する。ここでその複数のビューポイントからFactoryを構築してプロダクト開発者の開発環境に配布する。Factoryスキーマ定義はFactoryを構築するためのビューポイント定義と複数のビューポイント間の関係を記述する。ビューポイント間の関係では、開発プロセスの実行順序、ビューポイント定義内のモデル間の一貫性、制約条件、変更の波及範囲などが表現される。

　Software Factoriesでは、すでに開発された要求定義は分類・資産化され、フィーチャ・モデルに基づいて可変性を可視化した成果物を蓄積する。プロダクトライン・グリッドで関心が分離され、プロダクトライン・グリッドをまとめたビューポイントでプロダクト開発者の作業範囲の微視的な開発プロセスを定義し、ビューポイントを組み合わせてプロダクト生産全体の開発プロセスを回すのである。

　将来の開発環境では、開発者の役割ごとの環境を提供したチーム開発が基本となるだろう。そこでは、ビューポイントのような開発プロセスを分担し、その部分プロセスの開発で必要となる資産を分離した管理法の概念は必須である。これにより、資産と開発プロセスの再利用が推進され、開発生産性、品質、管理可能性（複雑さへの対応）を改善できる。プロダクトライン開発とプロセスラインの考え方はこの再利用の基盤技術の1つとして採用が促進されるだろう。

（4） ソフトウェア・セルによるプロセスライン資産の管理法

　ビューポイントはプロダクトライン開発でプロダクトライン・グリッドと同様に資産として定義され、プロダクト生産に提供される。従って、ビューポイントはプロダクトライン開発を行うアーキテクトが定義する。

　Software Factoriesでのプロダクト生産では、プロダクトライン開発で用意された資産が提供するフィーチャの選択だけで開発が可能なことが望ましい。開発案件はフィーチャをメニューとして受注し、メニューにない開発案件の受注はできるだけ行わない。そうでなければ、資産を有効活用した工業的な開発は困難である。

　これは既存の製造業が既製部品の組み立てだけで製造可能な受注を行うのと同じ考えである。この条件に合わないカスタム要求を持つ開発案件は、Software Factoriesではなく、アジャイル開発や通常の方法論によるOOA/D（Object Oriented Analysis & Design：オブジェクト指向分析・設計）の開発で行うべきである。

　その場合は、プロダクトライン資産の再利用ができない分、複数プロジェクトのスパンでの開発コストは高くなるであろう。従って、プロダクトライン計画では、受注の受け付けでビジネス的に重視すべき顧客は誰で、その顧客が必要とする要求、フィーチャは何かを決めてスコープを絞っておくことが重要である。

　ところで、ビューポイントを組み合わせたプロダクト生産プロセスを、どのようにプロダクト開発者は実行するのであろうか？ 「ビューポイントの選択」と「ビューポイントを組み合わせたFactoryを利用した全体の開発プロセスの決定」では、開発者数、開発リソースの割り振りに影響する受注数、受注の待ち時間に対する要求、調達すべきソフトウェア成果物の制約、開発環境の制約などが影響する。

　プロダクト生産プロセスは、それぞれのプロダクト開発者が特定の分野（ドメイン、フィーチャ、アーキテクチャ・レイヤー、既存資産など）の役割を持って実行する。データベースの専門スキルを持つ開発者、UI（ユーザー・インターフェイス）を担当する開発者、顧客管理を担当する開発者、プロジェクト管理を行うマネージャなどがプロダクト生産ではいるはずである。これらの人間中心の役割を加味して開発者の作業範囲にどのFactoryを利用するかを考える。

　ソフトウェア技術の関心の分離による分類ではない、このような人間の分担による作業範囲をセルといい、セルを組み合わせてFactoryを利用しビューポイント駆動により開発を進める。これが、ビューポイントやFactoryといった技術を中心とした開発基盤のモデル化によるSoftware Factoriesと、開発プロセス上の役割や責務といった人間を中心とした開発基盤のモデル化、プロセスラインによるソフトウェア・セル生産方式の融合を図ろうとする理由である。

　例えば顧客管理セルは、ビジネス・エンティティなどのデータ・ビューポイントやビジネス・プロセスなどのアプリケーション・ビューポイントを組み合わせて構成した作業範囲である。プロダクト生産での受注後、ビューポイントが選択され、各プロダクト開発者にFactoryが配布されて、プロダクト生産全体の開発プロセスを構成するセルの定義と組み合わせが構築される。そして、各セルに開発者が割り当てられる。

　1つのセルは1人が作業するのが原則であるが、同一のセルを複数人で並行して実行すれば同一作業はそれだけ短期間で実行可能である。また、プロセスの実行中に特定セルがボトルネックになるなら、セルの作業範囲の変更や、セルへの担当者の割り当てを変更することが可能である。さらに1つのセルは同時に異なる複数の受注からの作業を順次実行することが可能である。受注の作業が終了した時点で、セルの構築は解消され、その受注中に生じた不具合から、セル、あるいは、プロダクトライン開発のビューポイント、Factory（正確にはFactoryスキーマ定義）、プロダクトライン・グリッドの資産にフィードバックがなされて改善される。

【Software Factories用語集】 * プロダクトライン・グリッド： ソフトウェア・ファミリーを関心の分離のグリッドで分類し、体系化した分類の単位。例として、情報の関心で概念レベルのグリッドにはビジネス・エンティティが存在する。 * ビューポイント： プロダクトライン・グリッドを複数組み合わせて、特定のプロダクト開発者用の関心のスコープを定義する。このスコープで定義される関心の集合。例えば、データベース開発者は、プロダクトライン・グリッドの情報の関心の論理レベルと物理レベルの2つのグリッドをまとめた関心からビューポイントを作り、ER（Entity-Relationship）設計モデルとRDB（Relational Database System）の物理スキーマを定義する。 * Factoryスキーマ定義： ビューポイントをさらに複数組み合わせて開発プロセスを作るとき、開発プロセスでのビューポイント間のナビゲート方法や、ビューポイントのスコープで開発される成果物間の依存関係などを定義する。例えば、アプリケーション開発者が、アプリケーションの設計と実装、データベースの設計と実装を行うとする。ここでは、アプリケーションの設計と実装のためのビューポイント、データベースの設計と実装のためのビューポイントの2つを組み合わせて開発環境を構築する必要がある。プロダクトライン・グリッドでいえば、計4つのグリッドから開発環境を作成する。この開発環境で、例えば、アプリケーションの実装クラスとデータベースの物理スキーマ間の一貫性などを定義するのがFactoryスキーマ定義である。 * Factoryテンプレート： Factoryスキーマ定義で一貫性を取るすべてのビューポイントの成果物（アーティファクト）のパッケージ。チーム開発サーバに格納され、各プロダクト開発者に配布される。 * Factory： 各プロダクト開発者に配布されたFactoryテンプレートをロードした開発環境の実体。 * プロダクト生産： Factoryを組み合わせてプロダクト生産プロセスを構築し、カスタム開発をFactoryの開発環境、ソフトウェア資産、ツールで行うこと。 * ソフトウェア・セル： Factoryを配置したプロダクト生産プロセスの開発環境を人間中心の開発プロセスとして見たときの作業範囲。Factoryが技術から見た関心の分離による開発環境の分離方法であるのに対して、ソフトウェア・セルは開発者の役割や責務で見た作業分担の分離方法である。Factoryに対してソフトウェア・セルが割り当てられ、さらにプロダクト開発者が割り当てられる。あるいは、ソフトウェア・セルに対してFactoryが割り当てられ、さらにプロダクト開発者が割り当てられる。

　

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

　

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

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