連載 次世代開発基盤技術“Software Factories”詳解 第1回 ソフトウェア工業化を目指して マイクロソフト株式会社　萩原 正義 2005/03/16

Page1 Page2

　「Software Factories」は2004年10月にバンクーバーで開催された「OOPSLA 2004」で発表された。OOPSLAとは、世界トップレベルのソフトウェア工学、次世代開発パラダイム、開発方法論に関係する研究者、アーキテクト、実践者、企業開発担当者が集う学会である。筆者はOOPSLA 2004にSoftware Factoriesの開発アーキテクトとともに参加し、理念を共有した。

　筆者が本連載の執筆を引き受けた理由は、マイクロソフト社の1社員としてではなくアーキテクトの1人として、この技術の将来性と既存技術に与える影響の大きさを1人でも多くの開発者に伝えたかったからである。

◆ソフトウェア開発の課題

　品質の高いソフトウェアの開発は本質的に困難な作業だが、早期の市場投入、高い顧客満足度の要求とあいまってその度合いはさらに増している。困難さの主な原因として、アルゴリズム上の課題、設計の困難さ、分散配置の問題、物理的な制約、開発組織の体制、経済性の評価、政治的要因、人間の理解力の限界などが挙げられる。この中で、特に企業の大規模情報システムの開発において技術的に対応すべき課題は、設計の困難さ、分散配置の問題、開発組織の体制となろう。

　現代的ソフトウェア開発では、オブジェクト指向、コンポーネント・ベース開発、フレームワークの採用、パターンの発見と適用、アーキテクチャの構築、繰り返し型の開発、テスト駆動、ユースケース駆動などが採用される。確かにこれらの技術や手法は一定の成果を上げている。しかしその一方で、技術や手法の採用基準のあいまいさと属人性の問題、例えば、オブジェクト指向のクラスやコンポーネントの識別、ドメイン分割の技術者の経験による差などの解決や、今後複雑化する要求への対応を考慮した次世代の開発基盤技術の構築が強く求められている。

　産業の発展段階からいえば、現在のソフトウェア産業はようやく要素技術が整いソフトウェア工学の基礎技術が適用されつつある段階であり、ほかの製造業と比較してみると産業としての成熟度は高いとはいえない。例えば、ソフトウェア部品の標準化、開発の効率性、品質の管理基準、要求への対応などほとんどの項目で（成熟した産業として）十分とはいえないのである。ソフトウェアとIT技術が真の革命を起こすには、ソフトウェア・サイエンスとソフトウェア工学の成果を十分に生かした工業化レベルに達する必要がある。

　Software Factoriesはその名前のとおり日本の大型汎用機時代のソフトウェア工場の理念に近い。しかし、アーキテクチャの多様性、グローバルで仮想化された企業構造と統合化システム、要求の複雑化と多様化、リアルタイム性の要求など、当時と現在の背景の違いから、まったく新しいソフトウェア工学に基づきマイクロソフト社が提案し提供する次世代開発基盤技術である。

◆ソフトウェア開発における意思決定戦略

　ソフトウェア開発における意思決定戦略とは、要件や課題を判断して、開発手法、開発アプローチ、開発方法論、開発プロセスなどの多次元な選択肢を決定することである（図1）。

　代表的な開発手法としては、プロトタイプ開発、ドメインクラス開発、プロダクトライン開発が存在し、開発アプローチとしては特にユースケース駆動のプロセス中心アプローチ（POA）とデータ中心アプローチ（DOA）が存在する。また、開発方法論、開発プロセスとしては、UP（Unified Process）、アジャイル、Catalysis、そのほかとしてSOA、パターン指向設計、マルチパラダイム設計などが存在する。

図1　ソフトウェア開発における意思決定戦略

ソフトウェア開発の意思決定戦略として、要件や課題を判断して、開発手法、開発アプローチ、開発方法論、開発プロセスなどの多次元な選択肢を決定する。これに基づきソフトウェア開発を実践する。

　しかし、技術の適用限界と最適な条件を理解してこれらの多様な選択肢を多次元に組み合わせることは容易ではない。本来、ソフトウェア開発の複雑さや生産性の改善を目指して発展してきたソフトウェア工学の成果が皮肉にもかえって複雑化を招いている。ここが本質的な問題と考える。アーキテクトは難しい先進的な技術の成果をいち早く啓蒙するのが主ではなく、実情に合わせて技術を整理し、単純化して適正な適用方法を示すことで技術の普及に努めるのが役割と考える。

　さて、ここでは代表的な開発手法（前述したプロトタイプ開発、ドメインクラス開発、プロダクトライン開発の3つ）の意思決定戦略を説明する。開発手法は単独で使うだけでなく、システムのレイヤ、分割したドメインにより、これらを複数組み合わせるのが現実的である。これらの開発手法では、開発規模（コード量、開発者数）により開発コストが変化するので、その開発規模が意思決定戦略の1つの基準となる（図2）。

図2　開発手法の決定戦略

代表的な開発手法には、プロトタイプ開発、ドメインクラス開発、プロダクトライン開発の3つがある。これらの開発手法では、開発規模により開発コストが変化するので、その開発規模が意思決定戦略の1つの基準となる。

プロトタイプ開発が有利となる比較的小規模な開発規模の上限。 　 ドメインクラス開発が有利となる中・大規模の開発規模の上限。長期間の複数回の開発での規模の総和では、ドメインクラス開発はプロダクトライン開発より開発コストが大きくなる。

●プロトタイプ開発

　プロトタイプ開発とは主にRAD開発でのVisual Basicに見られるように、ユーザー・インターフェイス（以降、UI）のフォーム・レイアウトに画面部品を配置し、マウス・クリック・イベントなどのUIイベントに対する処理コードをイベント駆動型で記述する方法である。比較的小規模なアプリケーション開発に適用され、純粋なオブジェクト指向分析設計の手法よりも、アジャイルで手続き的なスクリプト言語を中心とした開発に適する。Webアプリケーションやクライアント／サーバ型のリッチ・クライアントのUI画面の開発に適用される。

　最近では、この技術を発展させ、テスト・ファーストのプラクティス（テスト駆動開発）と組み合わせることで、ソフトウェアの品質確保を図ろうとしている。また、コードを中心としたアジャイル開発で、コード生成機構（ロジック・コードからほかの実装コードや周辺の実装形式を生成する仕組み）を適用して次の段階へと進歩しようとしている。コード生成機構の適用により、開発の中心がUI画面からロジック・コードにベースを移し、それから逆に画面やデータ定義、データアクセス・コードを自動生成して開発生産性を高めようとする。

　ロジック・コードからほかの画面やデータ定義が生成されることにより、ロジック・コードだけを修正すれば、ほかのコードや構成定義を同期的に修正可能である。すなわち、ソフトウェアの資産管理はロジック・コードだけを対象とし、そのほかの開発成果物は自動生成により矛盾なく管理可能となる。

　ロジック・コードにより、できるだけ特定の製品や技術に依存しない、純粋な業務要件だけで決まる処理が記述できれば、非常に保守性が高く、品質を確保した開発が可能である。ロジック・コードに対する機械的なテストケースの自動生成も可能である。Webサービスの観点では、ロジック・コードからWSDLを自動生成することで、実装技術に非依存なWebサービス・コンシューマ（Webサービスを利用するアプリケーション）のためのプロキシ・コードの生成が可能である。

　プロトタイプ開発の採用は、要求システムがある程度大規模でアーキテクチャ確立の有効性が明らかな場合、あるいは、システム仕様の変更による複雑さの増大、拡張性への要求が厳しい場合には適さない。規模や拡張性への要求を慎重に予見し、プロトタイプ開発が適切かどうかをプロジェクト開始段階で判断することが重要である。

●ドメインクラス開発

　ドメインクラス開発はオブジェクト指向分析設計技術を適用する開発手法である。システム化の対象となる問題領域（ドメイン）を特定し、その中でオブジェクト指向のクラスとなる対象を分析する。そして、概念モデルとして業務要件の対象構造を定義していく。例えば、企業システムでは経営資源となる、ヒト、モノ、カネ、情報が概念モデルとなり得るし、企業の利益を生むための企業活動の記録も概念モデルとなる。典型的には、モノとしての商品、サービス、顧客であり、企業活動としての購買、製造、販売、物流、請求、支払いなどである。

　これらの概念モデルをどのようなUIやサービス形態で提供するかにかかわらず、その構造の定義だけを明確化する。概念モデルの作成では、経営資源を表現するデータを先行して定義していくデータ中心アプローチと、どのようにサービスを提供していくか、業務プロセスを先行して定義していくプロセス中心アプローチが存在する。オブジェクト指向分析ではプロセス中心アプローチに基づき分析を進める。

　また、概念モデルとその論理レベル表現であるドメインクラスは、オブジェクト指向ではUMLモデル図、データ中心アプローチでは主にDFDモデル図、ERDモデル図を使って表現したり成果物を管理したりする。従って、プロトタイプ開発がコードをベースとした開発とすると、ドメインクラス開発はモデルをベースとした開発といえる。

　モデルはコードに比べて開発の意図、すなわち、開発の業務的な価値、開発の目的や視点、メリットやデメリットなどが明示可能である点で、コードよりも実装技術からの依存性が少なく、大規模システムにおけるソフトウェア構造の全体像の把握と可視化に有利である。それ故、大規模システム向けであるが、より厳格な開発チーム管理、ソフトウェア設計、開発方法論の知識が必要となり、経験が浅い技術者には正しい適用が困難である。

　Webサービスの観点では、WSDLによる抽象的なインターフェイス定義を先行して規定し、サービス提供や利用の具体的な実装方法の決定を遅延させることで、相互運用性に対する品質の確保、Webサービスを適用するシステム間連携での大規模対応に有効である。

●プロダクトライン開発

　プロダクトライン・アーキテクチャは米カーネギーメロン大学ソフトウェア工学研究所で開発された（図3）。主に量産化可能な製品を扱う組み込み系ソフトウェア開発に適用され、生産性や成果物の管理で効果を上げている開発手法である。アーキテクチャの構築という長期的視野を重視し、長期的に継続される複数回のソフトウェア開発向けに適用される。最近では、組み込み系ソフトウェアだけでなく、一般にはアーキテクチャの構築が有効とされる大規模システム、長期間の利用が前提となる企業システムへの適用が試みられている。

図3　プロダクトライン・アーキテクチャ

プロダクトライン・アーキテクチャは、アーキテクチャの構築という長期的視野を重視し、長期的に継続される複数回のソフトウェア開発向けに適用される。左側のプロダクトライン開発がアーキテクチャを構築し、右側のプロダクト生産がそのアーキテクチャを再利用し、提供されるフィーチャを選択して、1回ずつのプロジェクト開発を行う。

　プロダクトライン・アーキテクチャはオブジェクト指向分析設計やその開発プロセスを超えて、アーキテクチャ構築のためのドメイン工学、アーキテクチャ構築を強制する開発プロセス、アーキテクチャを構成するソフトウェア資産を管理し、コンポーネント・ベース開発やモデル駆動型アーキテクチャと組み合わさって、最新のソフトウェア工学の開発手法に成長しようとしている注目の技術である。

　それではSoftware Factoriesとはどのようなものだろうか。次のページでその理念について説明しよう。

INDEX
	次世代開発基盤技術“Software Factories”詳解
	第1回 ソフトウェア工業化を目指して
	1．ソフトウェア開発における意思決定戦略
	2．Software Factoriesの理念

　

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

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