アーキテクチャに関するドキュメントを書く際、「これは戦略に書くべきか、戦術に書くべきか、それとも設計ドキュメントに書くべきか」と迷うことがある。
それはおそらく、戦略・戦術・設計の定義が曖昧であることや、書き分けに明確な基準がないことが原因だろう。
この記事では、戦略・戦術・設計の3層構造と、5W1Hを使った書き分けの指針を紹介する。
戦略・戦術・設計の3層構造
アーキテクチャに関するドキュメントは、以下の3層に分けて整理できる。
- 戦略：Why/What（なぜ取り組むのか、何を達成したいのか）
- 戦術：How/When/Where/Whoの大枠（どのような施策で、いつ、どこで、誰が）
- 設計：具体的なシステム設計（インターフェース、データモデル、技術選定の詳細など）
抽象度でいえば、戦略が最も抽象的で、設計が最も具体的である。戦略で方向性を決め、戦術で施策の大枠を決め、設計で具体的な実装方針を決める。
なお、実際に策定する際は3層を横断的に見通して考える必要がある。しかし、ドキュメントを書き分ける・考えを整理する際には、この3層構造で分けて考えると整理しやすい。
戦略・戦術を書く前に
書き分ける前に、前提となるインプットを整理しておく必要がある。以下はアーキテクチャ戦略を考える上で大抵必要になるものだ。
1. ビジネス戦略・ビジョンの確認
- ビジネス目標・戦略の理解：アーキテクチャがどのようにビジネスに貢献するか
- ビジネスドライバー：事業成長の鍵となる要素、競争優位性の源泉
- ステークホルダーの特定：経営層、開発部門、事業部門などが求める要件・制約・期待
2. 要件の整理
- 機能要件：システムが満たすべき機能
- 非機能要件：パフォーマンス、可用性、セキュリティ、保守性など
3. 現状のアーキテクチャ（As-Is）の把握
- 現行システムの調査：システム構成、データフロー、利用技術、運用プロセス
- 課題・リスクの抽出：ボトルネック、技術的負債、属人化、運用負荷など
4. 制約条件の確認
- リソース制約：予算、人員、期限
- 組織構造・チーム体制：誰がどの領域を担当するか
これ以外にも、規制・コンプライアンス要件、外部依存関係、過去のアーキテクチャ決定記録など、状況に応じて必要なインプットは様々だ。戦略を策定する前に、ある程度の情報収集を済ませておくことが重要である。
これらが曖昧なまま書き分けを行っても、形だけのドキュメントになってしまう。手法に囚われず、まずインプットの整理から始めることが肝要だ。
よくある混乱パターン
戦略と戦術の書き分けで、よくある混乱パターンを2つ挙げる。
1. 戦略に手段（How）を書いてしまう
例えば「マイクロサービス化する」という記述が戦略に入ってしまうケース。マイクロサービス化は手段であり、本来は戦術に書くべき内容だ。
戦略に書くべきは「なぜマイクロサービス化が必要か」という目的の部分。例えば「チーム間の依存を減らし、独立したデリバリーを可能にする」といった記述になる。
2. 手段が前提になり、目的を見失う
マイクロサービス化という手段を念頭に方向性を考えてしまうと、「なぜマイクロサービス化すべきなのか」という目的が曖昧になる。
手段を戦略から分離することで、戦略の抽象度と方針としての固さを維持できる。
5W1Hによる書き分け基準
5W1Hを戦略と戦術に割り当てると、以下のように整理できる。
戦略に書くべき要素
- Why：目的、動機、ビジネス価値。なぜこのアーキテクチャ変更が必要なのか
- What：達成したいゴール、解決したい課題。何を実現したいのか
戦術に書くべき要素
- How：施策の大枠。どのようなアプローチで実現するか
- When：タイムライン、フェーズ、優先順位
- Where：適用範囲、システムのどの部分に適用するか
- Who：担当チーム、ステークホルダー
設計に書くべき要素
- Howの詳細：具体的な技術選定、インターフェース設計、データモデル
- 要件・制約の詳細：非機能要件の具体的な数値、技術的制約
- トレードオフの検討：採用した設計と代替案の比較
この整理により、戦略は「方向性」を、戦術は「施策の大枠」を、設計は「具体的な実装方針」を示すという役割分担が明確になる。
判断に迷うグレーゾーン
すべてが明確に分類できるわけではない。例えば、戦略の中でto-beとなるコンテキストレベルのアーキテクチャを書くケース。
「モノリスから分散アーキテクチャへ移行する」といった抽象度の高い記述は戦略寄りだが、コンテキストレベルの図として具体的なシステム境界を示すと、戦術的な要素も含まれてくる。
判断基準：「手段が前提になっていないか？」
迷ったときは、その記述が手段を前提としていないかを確認する。手段が前提になっていると、目的を見失いやすくなる。
戦略から手段を分離することで、方針としての固さを維持できる。状況によって手段は柔軟に変えられるが、目的はブレにくくなる。
戦略・戦術・設計の策定例
3層構造で書き分けた例を示す。
なお、戦略のWhy/Whatは課題分析から論理的に導かれる必要がある。課題分析が曖昧だと、Why/Whatも根拠のないものになってしまう。
課題分析
現在、機能リリースに平均4週間かかっている。主な原因は以下の3点である。
- モジュール間の依存が強く、1つの変更が広範囲に影響する
- 全体をまとめてテスト・デプロイする必要があり、待ち時間が発生する
- リリース調整に複数チーム間の合意が必要で、コミュニケーションコストが高い
最も影響が大きいのはモジュール間の依存であり、これが他の2つの原因にも波及している。
ビジネスへの影響
リリース遅延により、過去1年で3件の大型案件を競合に奪われた。営業からは「機能追加の見通しが立たず提案しづらい」との声が上がっている。
ビジネス戦略との適合性
全社戦略では「市場変化への迅速な対応」が掲げられており、デリバリー速度の改善はこれに直結する。
戦略（Why・What）
Why：なぜ取り組むのか
機能リリースに平均4週間かかっており、市場変化への対応が遅れている。競合は2週間でリリースしており、このままでは競争力を失う。全社戦略「市場変化への迅速な対応」を実現するために、デリバリー速度の改善は最優先課題である。
What：何を達成したいのか
モジュール間の依存を減らし、チームが独立して変更・デプロイできる状態にする。これにより、デリバリー速度を現状の2倍に改善し、機能リリースを平均2週間以内にする。
戦術（How・When・Where・Who）
How：どうやって実現するか
- 受注サービスをモノリスから分離し、独立デプロイ可能にする
- 在庫サービスをモノリスから分離する
- サービスごとにCI/CDパイプラインを構築する
When：いつまでに、どの順序で
- Q1：受注サービスの分離
- Q2：在庫サービスの分離
- Q3：CI/CDパイプラインの整備と効果測定
Where：どこに適用するか
- 対象：受注・在庫領域（依存関係が最も複雑な領域）
- 対象外：その他の領域は次フェーズで検討
Who：誰が担当するか
- 受注サービス：受注チーム + プラットフォームチーム
- 在庫サービス：在庫チーム + プラットフォームチーム
設計
受注サービスの設計概要
- 通信方式：モノリスとの連携はREST APIで行う。将来的には非同期メッセージングへ移行を検討
- データ分離：受注データは専用DBに移行。移行期間中は双方向同期を実施
- インターフェース：受注API v1として公開。後方互換性を維持するバージョニング方針を採用
アーキテクチャ図・ユースケース・シーケンス
（図は割愛）
- アーキテクチャ図：受注サービスとモノリス、外部システムとの関係を示す
- ユースケース：受注登録、受注照会、受注キャンセルなどの主要ユースケース
- シーケンス図：受注登録時のモノリスとの連携フロー
非機能要件
- 可用性：99.9%（月間ダウンタイム43分以内）
- レスポンスタイム：p95で200ms以内
- スループット：ピーク時1,000リクエスト/秒
トレードオフ
- 同期通信 vs 非同期通信：初期はシンプルな同期通信を採用。複雑性を抑え、早期にリリース可能とする
- 共有DB vs 専用DB：専用DBを採用。データ整合性の課題はあるが、独立デプロイを優先
まとめ
戦略・戦術・設計を書き分けることで、それぞれの役割が明確になる。
- 戦略には Why・What を書く。目的と達成したいことに集中する
- 戦術には How・When・Where・Who の大枠を書く。施策の方向性を示す
- 設計には Howの詳細 を書く。具体的な技術選定や実装方針を示す
- 迷ったときは「手段が前提になっていないか？」で判断する
手段を戦略から分離し、詳細を設計に委ねることで、それぞれのドキュメントが適切な抽象度で維持できる。