アーキテクチャに関するドキュメントを書く際、「これは戦略に書くべきか、戦術に書くべきか、それとも設計ドキュメントに書くべきか」と迷うことがある。
それはおそらく、戦略・戦術・設計の定義が曖昧であることや、書き分けに明確な基準がないことが原因だろう。
この記事では、戦略・戦術・設計の3層構造と、5W1Hを使った書き分けの指針を紹介する。
アーキテクチャに関するドキュメントは、以下の3層に分けて整理できる。
抽象度でいえば、戦略が最も抽象的で、設計が最も具体的である。戦略で方向性を決め、戦術で施策の大枠を決め、設計で具体的な実装方針を決める。
なお、実際に策定する際は3層を横断的に見通して考える必要がある。しかし、ドキュメントを書き分ける・考えを整理する際には、この3層構造で分けて考えると整理しやすい。
書き分ける前に、前提となるインプットを整理しておく必要がある。以下はアーキテクチャ戦略を考える上で大抵必要になるものだ。
1. ビジネス戦略・ビジョンの確認
2. 要件の整理
3. 現状のアーキテクチャ（As-Is）の把握
4. 制約条件の確認
これ以外にも、規制・コンプライアンス要件、外部依存関係、過去のアーキテクチャ決定記録など、状況に応じて必要なインプットは様々だ。戦略を策定する前に、ある程度の情報収集を済ませておくことが重要である。
これらが曖昧なまま書き分けを行っても、形だけのドキュメントになってしまう。手法に囚われず、まずインプットの整理から始めることが肝要だ。
戦略と戦術の書き分けで、よくある混乱パターンを2つ挙げる。
1. 戦略に手段（How）を書いてしまう
例えば「マイクロサービス化する」という記述が戦略に入ってしまうケース。マイクロサービス化は手段であり、本来は戦術に書くべき内容だ。
戦略に書くべきは「なぜマイクロサービス化が必要か」という目的の部分。例えば「チーム間の依存を減らし、独立したデリバリーを可能にする」といった記述になる。
2. 手段が前提になり、目的を見失う
マイクロサービス化という手段を念頭に方向性を考えてしまうと、「なぜマイクロサービス化すべきなのか」という目的が曖昧になる。
手段を戦略から分離することで、戦略の抽象度と方針としての固さを維持できる。
5W1Hを戦略と戦術に割り当てると、以下のように整理できる。
戦略に書くべき要素
戦術に書くべき要素
設計に書くべき要素
この整理により、戦略は「方向性」を、戦術は「施策の大枠」を、設計は「具体的な実装方針」を示すという役割分担が明確になる。
すべてが明確に分類できるわけではない。例えば、戦略の中でto-beとなるコンテキストレベルのアーキテクチャを書くケース。
「モノリスから分散アーキテクチャへ移行する」といった抽象度の高い記述は戦略寄りだが、コンテキストレベルの図として具体的なシステム境界を示すと、戦術的な要素も含まれてくる。
判断基準：「手段が前提になっていないか？」
迷ったときは、その記述が手段を前提としていないかを確認する。手段が前提になっていると、目的を見失いやすくなる。
戦略から手段を分離することで、方針としての固さを維持できる。状況によって手段は柔軟に変えられるが、目的はブレにくくなる。
3層構造で書き分けた例を示す。
なお、戦略のWhy/Whatは課題分析から論理的に導かれる必要がある。課題分析が曖昧だと、Why/Whatも根拠のないものになってしまう。
現在、機能リリースに平均4週間かかっている。主な原因は以下の3点である。
最も影響が大きいのはモジュール間の依存であり、これが他の2つの原因にも波及している。
ビジネスへの影響
リリース遅延により、過去1年で3件の大型案件を競合に奪われた。営業からは「機能追加の見通しが立たず提案しづらい」との声が上がっている。
ビジネス戦略との適合性
全社戦略では「市場変化への迅速な対応」が掲げられており、デリバリー速度の改善はこれに直結する。
Why：なぜ取り組むのか
機能リリースに平均4週間かかっており、市場変化への対応が遅れている。競合は2週間でリリースしており、このままでは競争力を失う。全社戦略「市場変化への迅速な対応」を実現するために、デリバリー速度の改善は最優先課題である。
What：何を達成したいのか
モジュール間の依存を減らし、チームが独立して変更・デプロイできる状態にする。これにより、デリバリー速度を現状の2倍に改善し、機能リリースを平均2週間以内にする。
How：どうやって実現するか
When：いつまでに、どの順序で
Where：どこに適用するか
Who：誰が担当するか
受注サービスの設計概要
アーキテクチャ図・ユースケース・シーケンス
（図は割愛）
非機能要件
トレードオフ
戦略・戦術・設計を書き分けることで、それぞれの役割が明確になる。
手段を戦略から分離し、詳細を設計に委ねることで、それぞれのドキュメントが適切な抽象度で維持できる。