TOGAF（The Open Group Architecture Framework）のようなエンタープライズアーキテクチャフレームワークは、従来、詳細な計画、膨大な文書化、長期的なビジョン策定と関連づけられてきました。一方、アジャイル手法は反対に、反復的な納品、適応性、顧客からのフィードバックを重視します。多くの組織にとって、これらの2つの異なるアプローチを統合することは摩擦を生じます。その認識上の対立は、アーキテクチャガバナンスの必要性と、迅速な反復を求める欲求との間の緊張にあります。
本書では、組織がアジャイル環境においてTOGAFの原則を効果的に適用する方法を探ります。アーキテクチャ開発手法（ADM）を反復的な開発サイクルと整合させる実践的な戦略を検討し、構造が柔軟性を支援するものとなるよう、それを妨げるものにならないようにします。両フレームワークの微細な違いを理解することで、リーダーは堅牢でありながら変化に応じられるシステムを構築できます。
🧩 コアフレームワークの理解
効果的に統合するためには、まず、ブームワードに頼らず、それぞれのアプローチの本質を理解する必要があります。
🏛️ TOGAFアーキテクチャ開発手法
TOGAFは、企業情報アーキテクチャの設計、計画、実装、ガバナンスに対して構造的なアプローチを提供します。このフレームワークの核となるのがADMサイクルで、以下の複数のフェーズから構成されています：
- フェーズA：アーキテクチャビジョン – 範囲とステークホルダーの要件を定義する。
- フェーズB：ビジネスアーキテクチャ – ビジネス戦略とプロセスを定義する。
- フェーズC：情報システムアーキテクチャ – データアーキテクチャとアプリケーションアーキテクチャをカバーする。
- フェーズD：テクノロジー・アーキテクチャ – インフラストラクチャと技術基準を定義する。
- フェーズE：機会とソリューション – 実装ロードマップの計画を行う。
- フェーズF：移行計画 – 移行ステップの順序を決定する。
- フェーズG：実装ガバナンス – ソリューションが設計と一致していることを確認する。
- フェーズH：アーキテクチャ変更管理 – アーキテクチャへの変更を管理する。
従来、このサイクルは線形または準線形と見なされており、実装を開始する前に完全な定義が求められることがよくあります。これがアジャイルとの摩擦が生じるポイントです。
⚡ アジャイルマインドセット
アジャイルとは単なる一連の実践ではなく、アジャイル・マニフェストに中心を置いたマインドセットです。主な原則には以下が含まれます：
- プロセスやツールよりも、人間と対話の重要性。
- 包括的な文書よりも、動作するソフトウェアの重要性。
- 契約交渉よりも、顧客との協働の重要性。
- 計画の遵守よりも、変化への対応の重要性。
アジャイルチームは通常、短い反復（スプリント）で作業し、機能的な進捗を提供します。彼らは継続的なフィードバックに依存して、製品の方向性を調整します。このような文脈では、硬直したアーキテクチャ計画は価値の提供を遅らせる可能性があります。
🤝 統合の課題
TOGAFとアジャイルを組み合わせる際の主な課題は、時間軸と計画の粒度の違いにあります。TOGAFはしばしば数年単位で企業レベルを捉えますが、アジャイルは週または月単位で動作します。アーキテクチャがしすぎると、チームの方向転換能力が制限されます。一方で、あまりに緩いと、組織は技術的負債や分断のリスクにさらされます。
ここでは、通常 tensions が生じるポイントを説明します：
| 側面 | TOGAFの焦点 | アジャイルの焦点 | 潜在的な対立 |
|---|---|---|---|
| 計画 | 長期的なロードマップ | 短期的なスプリントバックログ | どれだけの将来の詳細が必要か？ |
| 文書化 | 包括的なモデル | 動作するソフトウェア | 文書化の負担は正当化されるか？ |
| 意思決定 | 中央集権的なガバナンス | 分散型の所有権 | 変更を承認するのは誰か？ |
| 変更 | 制御された進化 | 受け入れられた適応 | ずれをどのように管理するか？ |
これらの違いを認識することで、アーキテクトは両者の強みを尊重するハイブリッドモデルを設計できるようになります。
🔄 アジャイルサイクルに合わせたADMの適応
アーキテクチャ開発手法を放棄する必要はありません。むしろ、反復的に行うことができます。「反復的ADM」という概念により、アーキテクチャ作業を開発作業と並行して行うことが可能になり、完全に開発作業の前に実施する必要がなくなります。
🌱 反復的なアーキテクチャビジョン
フェーズA（ビジョン）は一度きりの出来事にしてはいけません。アジャイル環境では、ビジョンは生きている文書として扱われます。それは北極星のような存在ですが、市場からのフィードバックに基づいてコース補正が可能です。アーキテクトは製品オーナーと協力して、ビジョンが製品ロードマップと整合していることを確認します。
主な行動には以下が含まれます：
- 変化しない高レベルの原則を定義する。
- 譲れない制約（セキュリティ、コンプライアンス）を特定する。
- ビジョンを実行可能なアーキテクチャエピックに分割する。
🏗️ ジャストインタイムアーキテクチャ定義
従来のモデルでは、開発が開始される前に、ビジネス、データ、アプリケーション、技術の4つの領域すべてが完全に定義される。アジャイルでは、進行するために必要なものだけを定義することを提案する。これはしばしば「ジャストインタイム」アーキテクチャと呼ばれる。
例えば：
- スプリント1-3：ビジネスアーキテクチャと高レベルのアプリケーション論理に注力する。
- スプリント4-6：特定のデータエンティティが必要になるにつれて、データアーキテクチャを洗練する。
- スプリント7以降：デプロイ環境向けのテクノロジー・アーキテクチャを詳細に定義する。
このアプローチは無駄を削減する。アーキテクトは、イテレーション中に廃棄される可能性のあるコンポーネントのモデリングに時間を費やす必要がない。
🏗️ アーキテクチャランウェイ
この統合における重要な概念が「アーキテクチャランウェイ」である。この用語は、将来の機能開発を支援するために整備しておく必要がある技術的インフラとアーキテクチャ原則を指す。ランウェイがなければ、開発者は機能スプリントの途中で基盤コンポーネントの構築を停止して行わなければならないため、遅延が生じる。
健全なランウェイを維持するために：
- エンベラーを特定する：将来のビジネス価値を実現するために必要な技術的作業を特定する。
- 容量を割り当てる：アーキテクチャエンベラー用にスプリント容量の一部（例：20％）を予約する。
- 標準を自動化する：手動レビューのボトルネックを回避するために、インフラストラクチャをコードとして使用して技術的標準を強制する。
これにより、アジャイルチームが巨大なアーキテクチャプロジェクトが完了するのを待たずに、必要なツールやフレームワークを確保できる。
🛡️ 軽量なガバナンス
アジャイル環境におけるガバナンスは軽量である必要がある。重い承認プロセスはモーメンタムを殺す。目的は、ボトルネックを生じさせることなく、コンプライアンスと品質を確保することである。
📝 アーキテクチャ意思決定記録（ADRs）
巨大なアーキテクチャ文書の代わりに、組織はアーキテクチャ意思決定記録（ADR）を使用できる。ADRは、その背景と結果を含む重要なアーキテクチャ意思決定を記録するものである。これはコードリポジトリに保管される軽量な文書である。
ADRの利点には以下が含まれる：
- トレーサビリティ：数か月または数年後に、なぜその意思決定がなされたのかを知ること。
- 協働： チームメンバーは、意思決定を簡単にレビューおよびコメントできます。
- 透明性： 意思決定の履歴は誰もがアクセス可能です。
🔍 アーキテクチャレビュー委員会
伝統的なアーキテクチャレビュー委員会（ARB）は、ボトルネックになることがあります。アジャイルでは、ARBはゲートキーパーではなく、コンサルティング機関として機能すべきです。レビューは各スプリントごとではなく、重要なマイルストーンで行われるべきです。
以下の調整を検討してください：
- リスクに注力する： 企業に影響を与える可能性のある高いリスクの意思決定のみをレビューする。
- 非同期レビュー： アーキテクトがスケジュールの衝突を避けるために非同期でフィードバックを提供できるようにする。
- 同僚レビュー： 正式なARBレビューの前に、開発者が互いのアーキテクチャの整合性をレビューすることを促す。
👥 役割と責任
成功した統合には明確な役割定義が必要です。伝統的な「チーフアーキテクト」の役割は、より分散型のモデルに進化する必要があることがよくあります。
🧑💼 エンタープライズアーキテクト
エンタープライズアーキテクトは長期的なビジョンに注力します。組織を導くための標準、原則、パターンを定義します。異なるチームが互換性のないスイロを構築しないようにします。
🧑💻 システムアーキテクト
システムアーキテクトは開発チームに近い位置で働きます。エンタープライズの原則を特定のソリューションに対する具体的な技術設計に変換します。高レベルの戦略とコードの間の橋渡しをします。
🏃♂️ アジャイルアーキテクト
一部の組織では、アーキテクトをアジャイルチームに直接配置しています。これらの人物は、開発のスピードを維持しつつ、広範な戦略と整合する意思決定をチームが行えるように支援します。スプリント計画やバックログ精査に参加します。
🧭 プロダクトオーナー
プロダクトオーナーはビジネス価値を代表します。技術的制約がビジネス目標の文脈で理解されるように、アーキテクトと協働します。ユーザー・ストーリーとともに、アーキテクチャの促進要因を優先順位付けします。
🚧 避けるべき一般的な落とし穴
しっかりとした計画があっても、特定の落とし穴を無視すれば統合は失敗する可能性があります。これらの一般的なミスに気づいていれば、大幅な時間とリソースの節約が可能です。
- 過剰設計：すべての将来のシナリオに備える設計を試みることは、肥大化したシステムにつながります。拡張性を意識して、現在の要件に基づいて設計してください。
- 未充分設計：アーキテクチャの制約を無視すると、管理不能な技術的負債が生じます。非機能要件（パフォーマンス、セキュリティ）が対応されていることを確認してください。
- コミュニケーションのギャップ： アーキテクトと開発者はしばしば異なる言語を話す。チーム全体が理解できる図やモデルを使用する。
- 技術的負債を無視する： アジャイルチームはしばしば新機能の開発をリファクタリングよりも優先する。スプリントの一定割合は技術的負債の対処に割り当てるルールを設ける。
- ツールの過剰使用： 訓練が必要な複雑なモデル化ツールに頼らない。ドキュメントはシンプルに保ち、開発ワークフローと統合する。
📊 成功の測定
統合が機能しているかどうかはどうやって知るか？アーキテクチャの健全性とデリバリー速度の両方を反映する指標が必要だ。
📈 アーキテクチャ健全性の指標
- 準拠率： 定義された基準に準拠しているソリューションの割合。
- 技術的負債比率： リファクタリング作業と新機能開発作業の比率。
- 再利用性： 異なるプロジェクトで共有して使用されているコンポーネントの数。
🚀 デリバリー指標
- リードタイム： リスクからデプロイまでの時間。
- デプロイ頻度： コードがリリースされる頻度。
- 変更失敗率： デプロイのうち、障害を引き起こすものの割合。
これらの指標を追跡することで、リーダーシップはアーキテクチャへの投資や制約の緩和の場所をデータに基づいて判断できる。
🤔 よくある質問
❓ TOGAFはスクラムと併用可能か？
はい。ADMの段階はスプリントサイクルにマッピングできる。例えば、段階BとCは複数のスプリントにわたって検討できる。重要なのは、ADMを線形のウォーターフォールではなく、発見のサイクルとして捉えることだ。
❓ どのくらいのドキュメントが必要か？
ドキュメントはシステムの維持に十分であるべきだが、過剰であってはならない。1ページに収まる図は、50ページのドキュメントよりも良いことが多い。保守を助ける価値のあるドキュメントに注力する。
❓ ビジネス要件がスプリント途中で変更されたらどうするか？
これはアジャイルの基本原則である。アーキテクチャは変更に対応できるほど柔軟でなければならない。抽象化レイヤーやインターフェースを活用してコンポーネントを分離し、ある領域の変更が全体のシステムを破壊しないようにする。
❓ SAFeのような別々のアジャイルフレームワークが必要か？
必ずしもそうとは限りません。SAFe（スケーラブル・アジャイル・フレームワーク）のようなフレームワークは大規模な組織に構造を提供しますが、TOGAFはフルスケールのフレームワークを採用せずに適応できます。選択は組織の規模と複雑さに依存します。
❓ レガシーシステムはどう扱うのですか？
レガシーシステムはしばしば異なるアプローチを必要とします。新しい機能をレガシーシステムの周囲に構築し、段階的に置き換える「ストレンジャーフィグ」パターンを採用する必要があるかもしれません。TOGAFは、レガシー状態からターゲット状態への移行を可視化するのに役立ちます。
🔍 主なポイント
TOGAFをアジャイルと統合することは、片方を選ぶことではありません。構造と機動性のバランスを見つけることが重要です。アーキテクチャ開発プロセスを反復的に行い、軽量なガバナンスを採用し、役割を明確にすることで、組織は安定性とスピードの両方を達成できます。
成功は、コミュニケーション、柔軟性、そして目標に対する共有理解にかかっています。アーキテクチャチームと開発チームがパートナーとして協力するとき、品質やコンプライアンスを損なうことなく市場の変化に適応できる強靭な企業が生まれます。
小さなステップから始めましょう。1つのチームでアプローチを試行します。結果を測定し、プロセスを調整し、繰り返します。このアーキテクチャに対する反復的なアプローチは、支援しようとしているアジャイル哲学そのものを反映しています。
