第2回　基本設計工程のITアーキテクト

　ITアーキテクトが作成する成果物に注目し、何のために作るのかを明らかにします。システム開発のライフサイクルを軸にし、今回は基本設計工程を対象にします。基本設計工程では、主に次の5つの成果物を作成します。

（1）論理データモデル図
（2）パッケージ図（永続化視点）
（3）パッケージ図（機能視点）
（4）アーキテクチャー設計ドキュメント
（5）アーキテクチャー評価ドキュメント

　ITアーキテクトのはこの工程で、アプリケーションの構造を創出し、その構造を評価します。基本設計工程ではサブシステムごとに設計作業を進め、要件定義の深堀や、要件の変更（改善）が発生しているはずです。そこでITアーキテクトのタスクとしてポイントになるのは、並行する設計作業間で矛盾が生じないようにサブシステム間の依存関係を整理し、また、そのアプリケーション構造を支えるインフラを含めてアーキテクチャーを設計することです。

　ITアーキテクトに求められるのは、「複雑な要求を複雑なまま実装する」力技ではありません。全体問題を部分問題の集合に分解する能力が求められます。その能力は大きく分けて2つあります。1つは、全体整合性を保ったまま部分問題を定義することです。これを「分割統治」と呼びます。これができれば、個々のエンジニアの作業が行いやすくなります。

　もう1つは、機能要件と非機能要件を分離することです。これを「関心事の分離」と呼びます。機能要件と非機能要件は異なる関心事（視点）であり、異なる視点からそれぞれ設計を詳細化しても、互いに矛盾が生じないことが求められます。複数のエンジニアがそれぞれの領域で設計作業を並行して進められるように、こうした設計を先行して行います。

（1）論理データモデル図
　情報システムは単純化すれば、入出力システムです。入力データを永続化し、要件に応じてデータを加工して出力します。この「入」と「出」の折り返し地点にデータベースが存在します。つまり、データベースの構造はシステムの「土台」となり、この土台の良しあしが変化への対応力を決めるといっても過言ではありません。論理データモデル図は、この土台の論理構造を示したものです。

　サブシステムごとに論理データモデルを作ると、サブシステム間でのデータ連携が発生します。そうなるとデータの整合性が崩れたり、システム全体で最新のデータを共有できずにデータ鮮度が問題になったりします。全体最適を担うITアーキテクトがシステム全体としてデータの一元管理（整合性と鮮度）を担保するために論理データモデルの全体版を作り、それをエンジニアが詳細化します。

（2）パッケージ図（永続化視点）
　大きなシステムになると論理データモデルが扱う情報も多くなり、一つの文書では管理が難しくなります。そこで、論理データモデルを分割し、分割した一つひとつをパッケージと呼びます。パッケージは互いに独立するように分割します。「パッケージ図（永続化視点）」とは論理モデルを分割した図のことで、永続化視点という言葉を添えているのは、機能視点でもパッケージ図を作成するからです。

（3）パッケージ図（機能視点）
　機能要件を互いに独立したパッケージに分割した文書が、「パッケージ図（機能視点）」です。機能の独立性がパッケージ単位に担保できていることを可視化し、関係者全員で共有します。機能の独立とは他の機能に依存せず、パッケージ内に要件が「閉じている」ことを意味します。ここでいう「閉じている」とは、機能パッケージ間で関連を持たないことを指します。

　基本設計工程では、要件定義工程で明らかにならなかった機能要件が明確になってきます。事前に定義した要件と、事後的に決まった要件の間に矛盾がないようにしなければなりません。それを機能パッケージごとに確認していく必要があります。この際、ある機能パッケージの要件が精緻化されたり、改善されたりしても、他の機能パッケージに影響を「受けない/与えない」ことが、設計を並行して進める上で重要です。機能パッケージの責務と設計の役割分担を明確にするために作成します。

（4）アーキテクチャー設計ドキュメント
　ここまで説明した（1）(2）(3)がアプリケーションの基本構造になります。この基本構造を保ち、非機能要件を満たすアーキテクチャーを設計した文書が「アーキテクチャー設計ドキュメント」です。この成果物は要件定義工程で作成したグランドデザインの詳細化版に当たり、ハードウエアとソフトウエア構成の2つの構成図に分けて表記します。

　アプリケーションの基本構造が「分割統治」という観点から導き出すのに加えて、アーキテクチャー設計は「関心事の分離」という観点が必要になります。例えば、性能のボトルネックがどこに発生するのか、どのようにスケーラビリティーを実現するのかといった非機能要件を満たすために設計を進めていきますが、それらを検討する際、機能要件を実現する上での基本構造と対立しないようにします。つまり、互いに独立した最適化を進めても全体として問題が無いことを担保するということです。

（5）アーキテクチャー評価ドキュメント
　アーキテクチャー設計の評価には、要件定義工程で作成した「品質特性シナリオ」を使います。ATAMという方法論を用いた場合、利害関係者全員の投票により、シナリオごとに「重要度」と「難易度」を選びます。そうして選ばれた重要度と難易度を鑑みてトレードオフ分析とリスクを洗い出したものが「アーキテクチャー評価ドキュメント」です。

　この評価でクリティカルな問題が発見されれば、アーキテクチャーを見直します。その際、実機検証を行わないと設計の妥当性を判断できないアーキテクチャー的決定事項が見つかるかもしれません。このような場合は仮の決定事項とし、動的検証を実施した上でアーキテクチャーを確定させます。