戦略や戦術が明確に定義されていないケースは多い。その有用性や必要性が十分に認識されていないことが一因かもしれない。
「戦略を書く時間があるなら手を動かしたい」「書いても読まれない」という意見もあるかもしれない。しかし、戦略がないまま進めると、様々な問題が発生する。
この記事では、戦略がないとどうなるか、いつ戦略を書くべきかを整理する。
戦略がないまま進めると、以下のような問題が発生する。
各チーム・各フェーズで異なる技術を採用してしまう。例えば、サービスAはRedis、サービスBはMemcached、サービスCは独自実装といった具合だ。
結果として、スキルが分散し、メンテナンスコストが増大する。統一的な方針がないため、その時々の判断で選定が行われてしまう。
「DB分割」「キャッシュ導入」「非同期化」など、複数の改善案が並行して議論される。しかし判断基準がないため、声の大きい人の意見や、直近の障害に振り回される。
結果として、どれも中途半端になったり、着手順序が非効率になったりする。
「マイクロサービス化」が目的になり、なぜやるのかが曖昧になる。チームによって解釈が異なり、「独立デプロイしたい」「スケーラビリティを上げたい」など、期待がバラバラになる。
結果として、分割粒度がバラバラになり、期待した効果が得られない。
「今は機能開発優先」が常態化する。いつ・どの負債を返すかの判断基準がなく、負債は積み重なる一方だ。
結果として、負債が臨界点を超えてから慌てて対応することになる。計画的な返済ができず、開発速度の低下を招く。
1〜3年程度の中長期的なプロジェクトでは、戦略を書くべきである。半年程度のプロジェクトでも、簡易的なものがあると良い。
理由は、そのくらいのスパンでアーキテクチャを進化させる際に、方針がないとブレてしまうからだ。前述のような問題が発生しやすくなる。
また、方針があれば状況に応じて柔軟に更新することもできる。方針を変えること自体は問題ではない。しかし、方針がなければ「何を変えたのか」すら分からなくなる。方針を持ち、必要に応じて更新していくことが重要である。
戦略を書いても、機能しなければ意味がない。形骸化させないためのポイントを挙げる。
意思決定の拠り所として使う
実際の意思決定で戦略を参照する。「この方針に沿っているか？」という問いかけを習慣化することで、戦略が判断基準として機能する。
定期的に見直す
状況は変化する。戦略も固定ではなく、定期的に見直して更新する。四半期ごと、あるいは大きな変化があったタイミングで振り返りを行う。
関係者と共有する
戦略は書いた人だけのものではない。関係者に共有し、共通認識を持つことで、チーム全体の判断がブレにくくなる。
戦略がないまま進めると、場当たり的な技術選定、優先順位の迷走、手段の目的化、負債対応の先送りといった問題が発生する。
1〜3年程度の中長期的なプロジェクトでは戦略を書くべきである。半年程度でも簡易的なものがあると良い。
戦略を機能させるには、意思決定の拠り所として使い、定期的に見直し、関係者と共有することが重要である。