アーキテクチャ戦略を書いても、機能しないケースがある。形だけの戦略になってしまったり、実行に移されなかったりする。
この記事では、良い戦略と悪い戦略の違いを整理する。
良い戦略は、課題分析→方針→施策の3要素を持つ。これは良い戦略、悪い戦略で定義されている「カーネル（戦略の核）」を、アーキテクチャ戦略の文脈で解釈したものである。
この3要素が揃っていれば、何をすべきかが明確になり、リソースの最適な配置ができる。優先度の決定、手段の選択、スコープの決定、技術選定、組織設計、人員配置、予算配分など、様々な意思決定において選択と集中が可能になる。
良い戦略の裏返しとして、悪い戦略には以下の特徴がある。
これらは、課題分析→方針→施策の3要素のいずれかが欠けている状態とも言える。
良い戦略の3要素のうち、最も重要なのは課題分析である。方針や施策は課題分析の結果から導かれるため、ここを間違えると全てが間違う。
課題分析で意識すべきこと：
問いを正しく立てる
「どうやってマイクロサービス化するか」ではなく「なぜシステムの変更に時間がかかるのか」のように、手段から入らない。手段から入ると、その手段が本当に必要かどうかの検証ができず、本質的な課題を見落とす可能性がある。
例：マイクロサービス化ありきで進めたが、実際の問題はモジュール間の依存関係の複雑さだった。サービスを分割しても依存関係は解消されず、分散システムの複雑さが加わっただけだった。
課題を構造化する
表面的な症状と根本原因を区別し、課題の関係性を整理する。表面的な症状に対処しても根本原因が残っていれば再発する。また、課題の関係性が見えないと優先順位を正しく判断できない。
例：「デプロイに時間がかかる」という症状に対し、原因を探ると「テストが不安定」「CIパイプラインが非効率」「モノリスで全体ビルドが必要」など複数の要因が絡んでいた。これらの関係性を整理することで、どこから手をつけるべきかが見えてくる。
本質的な課題を特定する
すべてに対処しようとせず、最もインパクトのある課題を見極める。リソースは有限であり、すべてに対処しようとすると分散してどれも中途半端になる。
例：「パフォーマンス問題」「技術的負債」「スケーラビリティ」「開発者体験」など複数の課題が挙がった。ビジネスへの影響度と対処の難易度を評価し、まずパフォーマンス問題に集中することを決めた。
同じテーマでも、書き方によって戦略の質は大きく変わる。以下にビフォーアフターの例を示す。
戦略：マイクロサービス化
我々はモノリシックなアーキテクチャから脱却し、マイクロサービスアーキテクチャへ移行する。これにより、スケーラビリティと開発効率を向上させ、競争力を高める。
戦略：デリバリー速度の改善
課題分析
現在、機能リリースに平均4週間かかっている。主な原因は以下の3点である。
最も影響が大きいのはモジュール間の依存であり、これが他の2つの原因にも波及している。
方針
モジュール間の依存を減らし、チームが独立して変更・デプロイできる状態を目指す。
やること：
やらないこと：
施策
良い戦略は、課題分析→方針→施策の3要素を持つ。この3要素が揃っていれば、何をすべきかが明確になり、リソースの最適な配置ができる。
悪い戦略は、これらの要素が欠けている状態である。課題分析が不十分だったり、難しい決断を避けたり、目標と戦略を混同していたりすることが原因となる。
特に課題分析は重要である。問いを正しく立て、課題を構造化し、本質的な課題を特定する。ここを間違えると、方針も施策もすべてが間違った方向に進んでしまう。