前回のコラムでは、システム開発プロジェクトの開始時に行う、プロジェクトチームの発足や要件定義についてご紹介しました。
今回は、要件定義後の基本設計フェーズで行う、システムアーキテクチャの設計や評価に関する活動内容をお伝えします。

■ 第13回 基本設計（第1回）（ADD、システムアーキテクチャ設計）

活動前半では、基本設計フェーズにおけるITアーキテクトの主業務の一つ、アーキテクチャ設計について学びました。アーキテクチャ設計とは、機能要件や品質特性を定義した要件定義の成果物からシステムの全体像を具体化する作業のことで、以下の3つがあります。
・ システムアーキテクチャ設計
　各要件を満たすために、ハードウェア、ソフトウェア、ネットワーク、ミドルウェアそれぞれの役割と配置を定義した全体像（システム構成）を作る。
・ インフラアーキテクチャ設計
　現状の制約下にて各要件を満たす新しいハードウェア、ネットワーク、ミドルウェアの選定を行う。
・ アプリケーションアーキテクチャ設計
　アプリケーションの構造やハードウェア・ミドルウェアに対するソフトウェア機能の配置を決定し、それらを実現するためのフレームワークを選定・構築する。

さらに、活動後半ではアーキテクチャ設計手法の一つであるADD(アーキテクチャ品質特性駆動設計)について学びました。
ADDとはAttribute Driven Designの略で、カーネギーメロン大学(SEI)により提唱された品質特性と機能要件を両立させるアーキテクチャを目標とする設計手法です。
(参考URL: http://www.sei.cmu.edu/reports/06tr023.pdf)

第13回ではADDの概要や具体的な手順を学ぶとともに、演習によってその内容を体験しました。参加者は演習を通して、ADDのステップの中でも特に重要な『アーキテクチャドライバ(※)の発見』について、より理解を深めることができました。

■ 第14回 基本設計（第2回）（システムアーキテクチャ設計）

第13回に続いて、アーキテクチャ設計手法の一つであるADDの演習を行いました。前回の演習で決定したアーキテクチャドライバを実現するための設計パターンを列挙して評価するとともに、他のアーキテクチャドライバとの対応も考慮してシステムアーキテクチャを洗練させていきました。過去の回とは異なり、冒頭の振り返り以外は全て演習時間に充てるという、とても密度の濃い内容でしたが、活発な意見交換を経て演習の中でもアーキテクチャがブラッシュアップされていくなど、参加者がさまざまな知見や気づきを得られた回でした。

■ 第15回 基本設計（第3回）(ATAM、システムアーキテクチャ評価）

システムに限った話ではありませんが、作成した成果物を第三者が客観的な視点で評価するのは、非常に重要なことです。第15回ではシステムアーキテクチャを評価するための手法としてATAM(Architecture Trade-off Analysis Method)について学習しました。
ATAMとは、ADDと同じくSEIが開発したシステムアーキテクチャの静的分析手法のひとつです。活動の前半ではATAM実施の流れを解説し、後半の演習で前回作成したシステムアーキテクチャの評価を行いました。
参加者は演習を通して自身が作成したシステムアーキテクチャの評価を受けることで、当人だけでは見落としがちなアーキテクチャ上の課題や改善点に気づくとともに、他者の意見を取り入れることによりアーキテクチャが洗練されていくことを体験しました。

今回は第13回から第15回までの活動をご紹介しましたが、いかがでしたでしょうか？

アーキテクチャ設計は後続のシステム開発/運用の成否を占う重要なタスクであり、ITアーキテクトにとって最大の腕の見せ所といっても過言ではありません。これまでは経験者の暗黙知がものをいうと言われてきましたが、今回ご紹介したADDやATAMの出現によりその状況が変わりつつあります。
これからITアーキテクトを目指す方々はぜひ参考にしてみてください。

• ※　機能要求、品質要求、ビジネス要求、技術的制約のうち、特にアーキテクチャ形成上、最も大きな影響を及ぼす可能性のある要求・制約のこと。

• AWSは、米国その他の諸国における、Amazon.com, Inc.またはその関連会社の登録商標又は商標です。