みんな頑張っているのに、なぜデリバリーが遅いのか
あなたのチームには有能なエンジニアが揃っている。彼らはコードを書き、テストを実行し、アップデートをリリースする。別のチームはサーバー、ネットワーク、データベースを管理している。プラットフォームチームは内部ツールを構築している。誰もが忙しく、誰もが有能だ。それなのに、リリースのたびに危機が訪れる。
小さな変更が本番環境に届くまでに何日もかかる。開発者はインフラの準備が整うのを待つ。インフラチームは次のリリースがいつ来るのか知らされていない。QAチームには、すでに期限を過ぎたバージョンが渡される。何かが壊れたとき、誰が何を修正すべきか誰もわからない。リリース会議は責任のなすり合いになる。
これは人の問題ではない。オペレーティングモデルの問題だ。
サイロ化がもたらす真のコスト
各チームが独立して動くと、それぞれが自分の世界を最適化する。アプリケーションチームは自分たちに最適なCI/CDツールを選ぶ。インフラチームは別のデプロイツールを選ぶ。プラットフォームチームは、他の誰のワークフローとも接続しないパイプラインを構築する。
どのツールも単体では機能する。しかし、それらは連携しない。データはチーム間を流れない。リリースステータスは、それを必要とする人々から見えない。何か問題が発生すると、チームは誰が情報を持っているかを探すのに時間を浪費する。
次のフローチャートは、チームが互いに接続されていないツールを使用し、リリースステータスを共有していないために、各ハンドオフで作業が停滞する様子を示しています。
この問題は、アプリケーションに実際のユーザーがいる場合に顕著になる。小さな変更にも複数のチーム間の調整が必要になる。ハンドオフのたびに遅延が発生する。承認ステップごとにキューができる。プロセス全体は遅く感じられるが、全体的なスピードに責任を持つ個人は誰もいない。
オペレーティングモデルの真の役割
オペレーティングモデルは、ほとんどのチームが正式に取り組んだことのない基本的な質問に答える。
- 誰が、いつ、何をするのか？
- どのツールを使い、それらはどのように連携するのか？
- コードから本番環境まで、どのように作業が流れるのか？
- リリースが健全かどうかをどうやって知るのか？
これは堅苦しい手順書ではない。全員が同じ方向に進むための共有フレームワークだ。明確なオペレーティングモデルがあれば、アプリケーションチームはインフラがいつ準備できるかを推測する必要がなくなる。インフラチームはリリースがいつ行われ、何を準備すべきかを把握できる。プラットフォームチームはどの機能を優先すべきかを理解できる。
全員が同じ地図を見ている。
見えなければ改善できない理由
オペレーティングモデルがなければ、改善はほぼ不可能だ。各チームは互いを非難する。アプリケーションチームはインフラが遅すぎると言う。インフラチームはアプリケーションチームが先を見越して計画していないと言う。プラットフォームチームは誰も自分たちのツールを正しく使っていないと言う。
オペレーティングモデルがあれば、ワークフローが見える化される。コードコミットから本番環境までの時間を測定できる。どこでキューが発生しているかがわかる。自動チェックが不足している箇所を特定できる。全体像を見ている人がいなかったために誰も気づかなかったボトルネックを見つけられる。
この可視性が、非難をデータに変える。誰が遅いかで議論する代わりに、数値を見る。デプロイパイプラインは、どこで時間が失われているかを正確に示す。監視データは、どの変更が問題を引き起こすかを示す。メトリクスが次に何を修正すべきかを教えてくれる。
硬直化の反対
一部のチームは、官僚主義を恐れてオペレーティングモデルに抵抗する。形式的なプロセスが速度を低下させると心配する。しかし、優れたオペレーティングモデルはその逆を行う。リリースのたびに役割と責任を再交渉する必要性をなくすことで、スピードのための余地を生み出す。
こう考えてみよう。リリースのたびに、誰が承認するのか、誰がデプロイするのか、誰が監視するのか、誰がロールバックするのかについて同じ議論が必要なら、デリバリーではなく調整に時間を浪費していることになる。オペレーティングモデルは、それらの決定を一度だけ行う。チームは自分の役割を知っている。意思決定の方法を知っている。許可を待たずに問題を修正する方法を知っている。
結果は硬直化ではない。予測可能性だ。チームは毎回基本を理解する必要がないため、迅速に動ける。
オペレーティングモデルがない場合の結果
オペレーティングモデルがなければ、すべてのリリースは冒険だ。スムーズに進むか、炎上するかはわからない。成功は、たまたま誰が対応可能か、誰が正しい手順を覚えているか、運が味方するかどうかに依存する。
これは持続可能ではない。チームが成長し、アプリケーションのユーザーが増えるにつれて、亀裂は広がる。新しいチームメンバーは、暗黙のルールを学ぶのに何ヶ月もかかる。リリースはよりストレスフルになる。顧客が望むものと、提供できるものとのギャップは拡大し続ける。
オペレーティングモデルがあれば、リリースは測定可能で、制御可能で、改善可能なプロセスになる。コードから本番環境への道のりは、もはや記憶や運に依存しない。意図的に設計されたシステムに依存する。
実践的なチェックリスト：オペレーティングモデルが必要な兆候
以下のパターンに心当たりがあれば、チームはオペレーティングモデルを定義することで恩恵を受けられるだろう。
- リリース会議が常に「最新のステータスを持っている人は？」から始まる
- チームが同じジョブに統合されていない異なるツールを使っている
- 新しいチームメンバーがリリースの仕組みを学ぶのに何ヶ月もかかる
- 事後分析で毎回同じ調整の失敗が明らかになる
- エンドツーエンドのデリバリー時間を誰も測定できない
- チームが遅延の責任を互いに押し付け合う
- ロールバックに複数人の手動調整が必要になる
まとめ
問題はチームではない。共有されたオペレーティングモデルの欠如だ。誰もが自分のサイロの中で、自分のツールと優先順位で作業している限り、デリバリーは常に遅く、混沌と感じられる。オペレーティングモデルは官僚主義を追加するものではない。調整されていない作業の摩擦を取り除く。見えないものを見えるようにする。すべてのリリースを冒険から、測定、制御、改善可能なプロセスに変える。
まずは一つの質問をしてみよう。あなたのチームは、コードが開発者のマシンから本番環境に至るまで、誰が何をし、どのツールがどこで接続するかを含めて、正確に説明できるだろうか？答えが不明確なら、そこが最初の改善機会だ。