ソフトウェア再利用ガイドブック

ソフトウェア再利用ガイドブック―アーキテクチャ、プロセス、組織の変革による再利用ビジネス成功への道

ソフトウェアの再利用について思うところあり、本棚からこの古い本を引っ張り出す。
Amazonで見たら既に廃刊してて、中古にプレミア価格ついてる。

それはいいとして。
本書では、再利用によりビジネス上の利益が見込める場合はドメイン・エンジニアリングを開始しなさい、と教えている。

ドメイン・エンジニアリング
　・ドメインを定義し範囲を明確にする
　・例、ニーズ、トレンドを分析する
　・ドメインモデルとアーキテクチャを開発する
　・共通性と可変性を構造化する
　・再利用可能なコンポーネントシステム、言語、ツールを設計する

アプリケーション・システム・エンジニアリング
　・ドメインモデルとアーキテクチャに関連する差分の分析と設計を行う
　・開始点としてコンポーネントシステムを使用する
　・コンポーネントを発見し、特化し、統合する
　・可変メカニズム、言語、ジェネレーター、…、を利用する

要するに再利用可能なドメインのコンポーネント化を促進するためには、個別のアプリケーション開発とは分離した計画・活動・管理・組織が必要ですよ、と。これは基本的にはビジネス視点、つまり、複数アプリケーションを跨る再利用・共通化の観点での話だが、単一アプリケーション開発プロジェクトにも必要だよなぁ、と最近よく思う。

各業務開発チームに共通な非機能要求を解決するために、アーキテクトチームを編成することは普通に受け入れられるけど、複数業務共通の問題を解決するチームはなかなか編成させてくれないことが多い。

これには色々原因があると思う。
一つは、分析でモジュール分割が十分に検討される前にチームが編成されること。
一つは、例えば会社標準のWBSや開発プロセスに、この”複数業務共有地の悲劇”を解決する明示的なタスクが無いこと。
（もう一つは、ドメインオブジェクトの没落とトランザクションスクリプトの隆盛…と言いたいとこだけど、これはまぁ、コンポーネント化技法の違いの問題であり、たいしたことはない。）

後々ヤコブソンは、複数のユースケースに跨るドメインオブジェクトのモジュール性を維持する困難さを解決する手法として、AOSD(ユースケースによるアスペクト指向ソフトウェア開発 (Object Oriented Selectionシリーズ))を言い出すけど、あくまでテクニカルな解決方法で、この『ソフトウェア再利用ガイドブック』で熱心に語った計画・活動・管理・組織の分離の問題にはあまり触れてない。

とにかく…ITのプロマネというやつは、適当にチーム組んだり、適当に標準プロセスそのまま実行しちゃったりしちゃいかん。