「工業生産の効率的手法」を ソフトウェア開発に適用する 〜次世代開発基盤技術“Software Factories”〜

　 前回「モデル中心の開発手法が自律型システムの構築を可能にする」 では、ソフトウェアのライフサイクル全般をサポートするために、マイクロソフトが掲げたDSI（Dynamic Systems Initiative）のビジョンについて説明をした。そのビジョンを受けて今回は、マイクロソフトがVisual Studio 2005のリリースとともに導入を進めているSoftware Factoriesについて解説する。 Software Factoriesとは、ソフトウェアの開発段階に着目し、より効率的に、そして高い生産性を維持しながら開発作業を進めていくために考案されたマイクロソフト独自の工学的なアプローチである。

　大規模な業務システムを構築するといったようなプロジェクトをうまく成功させるためには、過去の成功事例をパターン化・ガイドライン化したものを用意したり、うまく進んだプロセスを標準化したりといったアプローチを取ることが多いと思われる。これは比較的経験の浅い人がプロジェクトに関わることになっても、ある一定レベルの品質を確保できるようにと考えた結果、生まれてきたアプローチの方法といえるだろう。

　言い換えれば、標準（マニュアル）化された作業手順、別の場所で製造され運び込まれた部品、組み立てのために必要な治工具（ツール）類が整備された工場ラインに似た環境であり、業務システム（ソフトウェア）の開発現場においても同様のアプローチを取り、標準化されたものを用いて作業を進めるようにすることで、リードタイム（納期）と品質を確保することができるという考えである。このアプローチは、きわめて工業生産的であり、生産現場においては日本を筆頭にあらゆる地域で成功をおさめてきた方法である。Software Factoriesの目指すところは、この「ソフトウェア開発の工業化」にほかならない。

　Software Factoriesは複数のソフトウェア工学の研究成果やベストプラクティスと呼ばれる経験から構成される開発基盤技術である。以下、Software Factoriesを構成するさまざまな要素を細かく見ていこう。

◆ アーキテクチャ構築のための開発プロセス

　Software Factoriesでは、アーキテクチャ構築を強制するための開発プロセスであるプロダクトライン・アーキテクチャを採用し、RUPのようにモデリングの上流でアーキテクチャを定義する方式とは異なるスタンスを取って、実証されたアーキテクチャを強制することにより、短期的に高品質なアプリケーションを開発することを目指している。プロダクトの開発者は、プロダクトラインで提供されるプロセスやツールを用いて、アプリケーションロジックの開発に専念するだけで、余計なアーキテクチャを検討する必要がない。マイクロソフトの場合は、Visual Studio 2005開発環境に実証済みのアーキテクチャを使う仕組みが盛り込まれるため、Visual Studio 2005と同時に提供される開発プロセスを採用することで、特に意識をすることなくプロダクトラインに沿った開発を進めることになる。

◆ プロダクトライン開発

　Software Factoriesの心臓部ともいえる構成要素が「プロダクトライン開発」である。図1では左側のブロックにあたる。プロダクトライン開発は、先ほどから説明している工業生産でいうところの生産ラインにあたる。この生産ラインをどう設計すればモノが効率的・高品質に生産できるかが決まってくるのである。ソフトウェアの世界においても製造業同様に有効なプロダクトラインを作ることにより、ソフトウェアの開発の効率及び品質の向上を図ることが可能となる。

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

　また、ソフトウェア資産の管理は従来のドキュメント・ベースからMicrosoft Visual Studioなどの統合開発環境（IDE）ツールで提供される制約と自動化が基準となる。

◆ アーキテクチャ構築のためのドメイン工学

　アーキテクチャを構築するには、長期的に必要な複数プロジェクトにまたがる機能要件と非機能要件に適切な分析を加え、変わらない要求と変わる要求を分離するモデリングが必要である。そのうえで、変わる要求に対しては適切な柔軟性を持つ可変性（Variability）を考えておく必要がある。

　企業システムや、ソフトウェア・パッケージとサービスの提供では長期的な保守が重要な問題となるが、UMLによるクラス図やシーケンス図だけでは要件が変わりうることの表現や、要件の変化がどの程度の範囲にまで影響するかを可視化（モデリング）することができない。そのため、ドメイン工学では、UMLに加えて別のモデル表現が必要だと提唱している。フィーチャ・モデル（図2）はドメイン分析では代表的なモデル表現である。

図2 フィーチャ・モデル

　フィーチャ・モデルとは、アーキテクチャの提供する長期的なフィーチャ（機能要件と非機能要件）を木構造として表現するものである。フィーチャは段階的に詳細化され、提供が必須なフィーチャと選択的なフィーチャに分類される。また、どちらか一方しか選択できない相互排他的フィーチャの関係も図示する。

　可変性の実現技術としては、設計時、コンパイル時、リンク時、実行時などのバインド（結合）のタイミング要求に応じて、継承、インターフェイスを介した委譲などの間接参照、実行時のリフレクション、Webサービス技術などを導入する。Software Factoriesは可変性の実現技術に依存しない拡張性、仕様の可視化とその管理機構を提供する。

◆ アーキテクチャ・パターンとパターン言語

　ソフトウェアを開発する過程で繰り返し発生する問題に対しては、再利用性の高い解決方法のベストプラクティスをシステム構築の知識（ドメイン）に依存したパターンとして発見・蓄積し、汎用性の高い概念として抽象化していく。そしてさらに、このパターンあるいはパターンの組み合わせであるパターン言語でアーキテクチャを構築し、プラットフォームに対する抽象化を進める。

　例えば、Javaで3階層を構築するのによく用いられる画面制御のためのフレームワークに「MVC（Model-View-Controller）」があるが、これこそまさにベストプラクティスの代表であるといえる。MVCのように、実際の経験を抽象化したレベルで新たなベストプラクティスを発見し、再帰的に抽象化を進めていくこと。つまり、MVCパターンのフレームワークをベースにして、新たな共通パターンの抽象化を行う、といったことがその例である。

　オブジェクト指向をはじめ、抽象化による複雑さの隠ぺいと管理こそがソフトウェア開発の発展にある方向性を与えると考えられる。一方、パターンを無秩序に発見し、採用することは、ソフトウェア開発の複雑化を助長するだけで発展の方向性には寄与しないだろう。パターンは標準化と共有を進めることで、品質の確保と生産性の改善に寄与することができる。そういう意味では、パターンの発見だけが目的で標準化が重視されず、フレームワークが乱立する現在の技術トレンドは誤りである。

◆ コンポーネント・ベース開発

　コンポーネント・ベース開発（CBD：Component Based Development）を採用するということは、「アーキテクチャの構造と振る舞いを仕様化するためのコンポーネント単位の管理」と「C#やJavaなどで書かれた実装コンポーネントの開発と利用」を分離して考える開発手法を導入するということである。「論理コンポーネントによる仕様化」と「実装コンポーネントによる実現」の分離といってもよい。業務要件の可視化と保守可能な仕様で、なおかつ業務実行単位である「論理コンポーネント」と、テスト駆動開発でテスト実行が容易な高品質、再利用性の高い「実装コンポーネント」がソフトウェア資産として管理される。

◆ モデル駆動型アーキテクチャとドメイン依存言語

　フレームワークのクラス構造やAPIを使った従来の開発に代わり、特定ドメインで共通性・汎用性の高い概念のモデルを用意し、モデルによるシステムの分析設計を行う。そして、そのモデルを（Visual Studioのような）開発環境が取り込み、解釈して、アーキテクチャで提供される既存の実装コンポーネントを再利用したり、あるいは新規のカスタム実装コード追加用のスケルトン・コードを生成したりするのが、ドメイン依存言語（DSL：Domain Specific Language）の役割である。DSLの登場により、これまで行われてきたAPIベースの開発は激減すると思われる。

　ただし、Software Factoriesが目指すのは、モデルによる分析設計から100％実装コードを生成する理念を持つ（つまりカスタム実装コードの追加を行わない）とする「モデル駆動型アーキテクチャ（MDA：Model Driven Architecture）」とは違う。Software Factoriesは現実的な有効性を考慮し、アーキテクチャが持つ共通概念の実装の再利用と可変性の実現技術の選択において、コード生成機構を適用するのみである。

◆ ソフトウェア開発のビジネスモデル

　Software Factoriesは、ドメイン依存アーキテクチャ開発、例えば、業種別フレームワークや特定の非機能要件のレイヤーアーキテクチャ、とプロジェクト開発の2つの開発を開発サプライチェーンとして連鎖させる新たなビジネスモデルにより、既存の開発基盤を再構築する産業モデルを提案する。ソフトウェアの工業化は技術の発展だけでは解決不可能であり、家内制手工業による前近代的な産業構造の改革が必要なのである。なお、「IT産業構造発展のメタファー」に関しては、米マイクロソフトのアーキテクトが寄稿した「Metroplis」という記事が参考となるだろう。

萩原正義氏（マイクロソフト ソフトウェアアーキテクト）に聞く

マイクロソフトがSoftware Factoriesを提唱する理由

Software Factoriesは「工業化」のアプローチを取る開発プロセスです。では、Software Factoriesと従来から存在するプロセスとはどこが異なり、なぜ新しいアプローチが必要になったのでしょうか？ 業務システムの大半がメインフレームで構成されていた時代では、アプリケーションアーキテクチャはオンラインとバッチという、ほぼこの2種類に分類されていました。つまり、アーキテクチャそのものが極めて単純だったため、構築においては、いわゆるウォーターフォール型のプロセスで済んでいたものが、最近の業務システムではインターネットやWebサービスといったオンラインやバッチに必ずしも分類できない技術を取り込むことが必要になり、複雑化したことに関係があるわけです。 　例えば、在庫量の更新を翌日の朝の会議の情報用として日次単位でバッチ処理していたというシステムを想定してみましょう。 　企業として競争力を上げるためという名目で、リアルタイムにその状況をトレースしたいという要求が発生したとします。システムとしてこの要求が可能になると、今度は出先から携帯電話を使い、HTTP経由でリアルタイムに在庫状況を把握したいという営業現場からのリクエストがあがってくるかもしれません。この要求にも応えることで、その企業は、より新しいビジネス価値を生み出すことが可能になるかもしれません。 　さらに、自社システムのみならず、パートナー関係にある取引先のシステムと接続し、さらに競争力のあるシステムを構築することになれば、リアルタイム処理ではないけれど、コスト面や生産性で優位なWebサービスを使う場合も出てくるでしょう。Webサービスを使いながらユーザーの使い勝手の良さを重視したスマートクライアントを導入する際は、対話的な処理を実現しなければなりませんが、その際、必ずしも、バックエンド（サーバ）へのリクエストがリアルタイムに発生しているとは限らないのです。 　このように、システムに対する要求は複雑かつ、多様化しています。そして、こうした要求に対応できる新たな（ソフトウェア開発のための）標準化のプロセスが求められていました。このような背景のもと、マイクロソフトではSoftware Factoriesというアプローチを提唱し始めたわけです。

◆ モデリング・プラクティス コーナーへ