良いアーキテクチャ戦略・悪いアーキテクチャ戦略

良いアーキテクチャ戦略・悪いアーキテクチャ戦略について、設計原則とトレードオフ、実践的な適用方法を詳しく解説します。

Read in: en
良いアーキテクチャ戦略・悪いアーキテクチャ戦略

アーキテクチャ戦略を書いても、機能しないケースがある。形だけの戦略になってしまったり、実行に移されなかったりする。

この記事では、良い戦略と悪い戦略の違いを整理する。

良い戦略の要点

良い戦略は、課題分析→方針→施策の3要素を持つ。これは良い戦略、悪い戦略で定義されている「カーネル(戦略の核)」を、アーキテクチャ戦略の文脈で解釈したものである。

この3要素が揃っていれば、何をすべきかが明確になり、リソースの最適な配置ができる。優先度の決定、手段の選択、スコープの決定、技術選定、組織設計、人員配置、予算配分など、様々な意思決定において選択と集中が可能になる。

悪い戦略の特徴

良い戦略の裏返しとして、悪い戦略には以下の特徴がある。

これらは、課題分析→方針→施策の3要素のいずれかが欠けている状態とも言える。

悪い戦略になってしまう原因

戦略における課題分析の重要性

良い戦略の3要素のうち、最も重要なのは課題分析である。方針や施策は課題分析の結果から導かれるため、ここを間違えると全てが間違う。

課題分析で意識すべきこと:

問いを正しく立てる

「どうやってマイクロサービス化するか」ではなく「なぜシステムの変更に時間がかかるのか」のように、手段から入らない。手段から入ると、その手段が本当に必要かどうかの検証ができず、本質的な課題を見落とす可能性がある。

例:マイクロサービス化ありきで進めたが、実際の問題はモジュール間の依存関係の複雑さだった。サービスを分割しても依存関係は解消されず、分散システムの複雑さが加わっただけだった。

課題を構造化する

表面的な症状と根本原因を区別し、課題の関係性を整理する。表面的な症状に対処しても根本原因が残っていれば再発する。また、課題の関係性が見えないと優先順位を正しく判断できない。

例:「デプロイに時間がかかる」という症状に対し、原因を探ると「テストが不安定」「CIパイプラインが非効率」「モノリスで全体ビルドが必要」など複数の要因が絡んでいた。これらの関係性を整理することで、どこから手をつけるべきかが見えてくる。

本質的な課題を特定する

すべてに対処しようとせず、最もインパクトのある課題を見極める。リソースは有限であり、すべてに対処しようとすると分散してどれも中途半端になる。

例:「パフォーマンス問題」「技術的負債」「スケーラビリティ」「開発者体験」など複数の課題が挙がった。ビジネスへの影響度と対処の難易度を評価し、まずパフォーマンス問題に集中することを決めた。

良い戦略・悪い戦略の例

同じテーマでも、書き方によって戦略の質は大きく変わる。以下にビフォーアフターの例を示す。

悪い戦略の例(Before)

戦略:マイクロサービス化

我々はモノリシックなアーキテクチャから脱却し、マイクロサービスアーキテクチャへ移行する。これにより、スケーラビリティと開発効率を向上させ、競争力を高める。

良い戦略の例(After)

戦略:デリバリー速度の改善

課題分析

現在、機能リリースに平均4週間かかっている。主な原因は以下の3点である。

最も影響が大きいのはモジュール間の依存であり、これが他の2つの原因にも波及している。

方針

モジュール間の依存を減らし、チームが独立して変更・デプロイできる状態を目指す。

やること:

やらないこと:

施策

まとめ

良い戦略は、課題分析→方針→施策の3要素を持つ。この3要素が揃っていれば、何をすべきかが明確になり、リソースの最適な配置ができる。

悪い戦略は、これらの要素が欠けている状態である。課題分析が不十分だったり、難しい決断を避けたり、目標と戦略を混同していたりすることが原因となる。

特に課題分析は重要である。問いを正しく立て、課題を構造化し、本質的な課題を特定する。ここを間違えると、方針も施策もすべてが間違った方向に進んでしまう。

Tags: アーキテクチャ戦略 アーキテクチャ 設計
Share: 𝕏 Post Facebook Hatena
✏️ View source / Discuss on GitHub
☕ サポート

このブログを応援していただける方は、以下からサポートをお願いします。いただいたサポートはブログ運営・技術研鑽に活用します。


関連記事