第3回　詳細設計工程のITアーキテクト

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

（1）機能パッケージをまたがる状態遷移図
（2）排他制御（ロック）仕様書
（3）コンポーネント図
（4）インピーダンスミスマッチの解決手順書
（5）物理データモデル図

　この工程のポイントは「変化への対応」です。システムへの要求仕様は決して確定しません。開発途中も初期リリース後も変化し続けます。この「変化」にどう対応するのか、これが情報システムの「本質的な複雑さ」の正体です。検証しやすさを最大化し、変化対応時の影響範囲を局所化するように、モジュール分割の基準を決定します。

　ITアーキテクトは、要求仕様の全体整合性に責任を持ちます。準正常系や異常系の仕様など、これまで明文化されなかった「暗黙の仕様」は詳細を詰める担当者レベルの作業の中で決まることが少なくありません。この事後的に決まる仕様が、全体整合性を崩し、連結テスト後の大きなリスクになります。ITアーキテクトは機能横断的な仕様を可視化し、仕様が変化する中でアプリケーション構造を維持するためのベースラインを規定します。

（1）機能パッケージをまたがる状態遷移図
　個別機能パッケージに閉じない（パッケージ横断の）仕様を可視化した文書が、「機能パッケージをまたがる状態遷移図」です。例えば、仕入れ機能と注文受付機能の場合、まだ仕入れていない段階で、注文をどう扱うかといった考慮が必要になります。具体的には、注文を受けてあとで注文確定通知するのか、初回の仕入れが完了した商品だけ注文可能とするのか、在庫切れと初回仕入れ未完は区別するのか、などです。取り得る「状態」を定義し、その間で可能な遷移を線でつなぎ、動的な仕様を表現します。

　ITアーキテクトは、個別機能の担当者のスコープでは見渡すことができない、機能横断的な仕様を可視化し、この明らかになった仕様から各機能パッケージの責務を矛盾の無いように規定します。機能横断の仕様を冗長な自然言語の羅列ではなく、簡潔な図を用いた仕様のエッセンスを明確に描くことで、各担当者は個別要素の詳細設計に集中できるようになります。

（2）排他制御（ロック）仕様書
　データ整合性を維持するために必要な排他キーと機能の関係を示した文書が「排他制御（ロック）仕様書」です。ロック仕様は、データ整合性維持のみならず、システムの更新性能を大きく左右します。ロックの粒度を小さくすると、論理的には更新処理の同時実行性を高めることが可能ですが、ロック取得にかかる処理のオーバーヘッドにより物理的な制約から性能が劣化するからです。

　ITアーキテクトは、システム全体のデータ整合性を保ちつつも、トランザクションの同時実行性を最大化するために、排他制御（ロック粒度）を機能横断的な立場から仕様を決める必要があります。特に機能パッケージをまたがる排他制御が必要な場合は主体的に仕様策定に参加し、性能要件を満たせることを机上評価しながら詳細設計を支援します。

（3）コンポーネント図
　基本設計工程で作成した2つのパッケージ図（永続化と機能）を基に、ソフトウエアモジュールの境界線（インタフェース）仕様と依存関係を示した文書が「コンポーネント図」です。パッケージ図（永続化）は、互いに独立したエンティティーを管理するのでパッケージ間に重複はありません。1パッケージを1コンポーネントで表現します。一方、パッケージ図（機能）は、機能要件を個々の機能パッケージ内に閉じることを優先したので、機能パッケージの詳細を見ると機能パッケージ間に重複が生じている可能性があります。このような重複部分を独立した別のコンポーネント（共通コンポーネント）として切り出します。

　共通コンポーネントを切り出す際に留意すべき点は、要求は変化するということです。現時点の要求仕様から共通と判断しても、要求が変化すると共通でなくなる可能性があります。また、共通コンポーネントは（不特定多数の）利用者から重複を排除する目的のために作るわけですから、利用者ごとの性能面での最適化からズレが生じる可能性があります。

（4）インピーダンスミスマッチの解決手順書
　永続化装置上のデータ構造と、アプリケーションのオブジェクト構造のギャップを埋める方式を示した文書が「インピーダンスミスマッチの解決手順書」です。永続化装置にRDBMSを用いる環境では、「O/Rマッピング」といわれる技術要素になります。

　RDBに最適化されたSQL文をオブジェクト指向言語に埋め込むと冗長な実装になります。一方、オブジェクト指向でRDBをカプセル化しようとしても「更新トランザクションスコープ」や「効率的な表の連結」などは、うまくいきません。また、マッピングで扱うデータ量が増えるとSQL文の発行回数が増えたり、オブジェクトの生成量が増えたりし、性能問題の温床になることが多いものです。テスト工程や本番運用で品質問題や性能問題を避けるために、明確な処理方式を規定します。

（5）物理データモデル図
　論理データモデルの物理的配置、及び索引の適用を定めた文書が「物理データモデル図」です。「論理図まではきれいに描けるけれど、物理になると崩れる」というのが、データモデルに関する共通の課題認識ではないでしょうか。データモデリングでは、概念、論理、物理と段階的に情報を整理し、モデルを具体化・詳細化していきます。しかし、最後のステップに物理的な制約があり、性能など非機能要件の壁が持っています。テーブル設計がシステムの変化対応力を大きく左右することに異論はないでしょう。性能と柔軟性のトレードオフを認識し、必要十分な変化対応力を維持するために、永続化パッケージの各担当者と協力して固めます。