CI/CD改善が忙しいだけに終わる理由とその対策

成熟度評価が終わりました。チームは6つの次元でスコアを獲得しました。ダッシュボードはカラフルです。誰もが行動を起こす準備ができています。

そこでプラットフォームチームはセルフサービスのプロビジョニングを構築し始めます。ガバナンスチームは新しいポリシーを策定します。データベースチームはマイグレーションを自動化します。誰もが忙しく、誰もが変更をリリースしています。しかし3か月後、デリバリーは依然として遅く、リリースは依然として苦痛です。実際に効果のあった改善を指摘できる人は誰もいません。

これは、成熟度評価の後によくある落とし穴です。つまり、すべてを一度に改善しようとすることです。

本当の問題は低スコアではない

成熟度モデルにおける低スコアは問題ではありません。それらは症状です。本当の問題は、他の部分がうまく機能していても、デリバリープロセスを遅くするボトルネックです。

ボトルネックとは、デリバリーフロー全体の中で最も遅い単一のポイントです。他のすべてがどれだけ速くても、1つのステップに数日かかれば、プロセス全体に数日かかります。

以下は、ボトルネックを可視化するためのシンプルなデリバリーパイプラインの図です。

ボトルネックの見つけ方は次のとおりです。チームはアプリケーションを5分でデプロイできます。しかしその前に、手動承認に2日間待つ必要があります。その承認がボトルネックです。パイプラインは完璧に動作しています。しかし、ステージング環境のプロビジョニングに3日かかります。インフラストラクチャチームにチケットを発行する必要があるからです。このプロビジョニングステップがボトルネックです。アプリケーションのデプロイは完全に自動化されています。しかし、すべてのリリースでDBAが手動でデータベースマイグレーションを実行する必要があります。この手動データベースステップがボトルネックです。

すべてを一度に改善しようとすると、誰もブロックしていない領域にエネルギーを分散することになります。ボトルネックはそのまま残り、デリバリーは遅いままです。そして、誰も実感できない多くの作業を行った結果、チームは burnout してしまいます。

本当のボトルネックを見つける方法

6つの次元（デリバリー、インフラストラクチャ、プラットフォーム、データベース、ガバナンス、テスト）にわたる成熟度プロファイルを確認してください。次に、チームに1つの簡単な質問をします。「どの次元が、リリースが遅れる原因として最も多いですか？」

パイプラインが途中で失敗し、誰も理由がわからない場合、ボトルネックはデリバリーにあります。環境が必要なときに準備ができていない場合、ボトルネックはインフラストラクチャまたはプラットフォームにあります。データベースの変更に常に数日かかる別のプロセスが必要な場合、ボトルネックはデータベースにあります。承認に、対応できない人からの複数のサインオフが必要な場合、ボトルネックはガバナンスにあります。

推測しないでください。実際に作業を行っている人に聞いてください。彼らはどのステップが最も痛いかを正確に知っています。

1つのことに焦点を当てたロードマップを作成する

ボトルネックがわかれば、ロードマップはシンプルになります。1つの次元を選びます。1つの現実的な目標レベルを設定します。期間を設定します。他のすべては現在のレベルに置いておきます。

実際の例を示します。

評価の結果、デリバリーはレベル3ですが、データベースはレベル1です。すべてのリリースが手動のデータベース変更によってブロックされています。今後3か月のロードマップ：データベースをレベル1からレベル2に引き上げ、破壊的でないスキーマ変更のマイグレーションを自動化します。これだけです。ガバナンスには触れません。プラットフォームには触れません。デリバリーをレベル4に押し上げようとはしません。

または、評価の結果、デリバリーはレベル3ですが、ガバナンスはレベル1です。すべてのリリースは、2日かかる複数ステップの承認プロセスを待ちます。今後6か月のロードマップ：ガバナンスをレベル1からレベル2に引き上げ、ステージングを通過した変更については承認を1つのステップに簡素化します。他のすべてはそのままです。

これは居心地が悪く感じられます。低いスコアをそのままにしているように感じられます。しかし、それがポイントです。無視しているわけではありません。今日、実際にデリバリーを速くする唯一のことに優先順位を付けているのです。

これが機能する理由

1つのボトルネックに集中すると、すべてのチームメンバーが同じ目標を認識します。プラットフォームチームは、なぜデータベースマイグレーションを自動化しているのかを理解します。ガバナンスチームは、なぜ承認を簡素化しているのかを理解します。テストチームは、なぜ今すぐすべてのテストスイートを書き直すように求められていないのかを理解します。

誰もが理由を理解しています。ロードマップはプロジェクトのリストではありません。それは、彼らが毎日感じている問題に対する解決策です。

これを代替案と比較してください。すべてを改善しようとすると、各チームは孤立して作業します。プラットフォームチームは、データベースチームがまだ手動マイグレーションを行っているため、誰も使用しないセルフサービスのツールを構築します。ガバナンスチームは、すでに正常に機能しているパイプラインを遅くするポリシーを作成します。テストチームは、決してボトルネックではなかったプロセスにさらに多くのチェックを追加します。誰もが忙しい。何も変わらない。

次のロードマップのための実用的なチェックリスト

次の改善サイクルを開始する前に、チームと一緒にこのチェックリストを実行してください。

• リリースを遅らせる原因として最も多い単一の次元を特定します。ダッシュボードではなく、チームに聞いてください。
• その次元に対して1つの目標レベルを設定します。最高レベルではありません。次の現実的なレベルです。
• 期間を定義します。3か月または6か月。無期限ではありません。
• すべてのチームに理由を伝えます。計画だけでなく、理由も伝えます。
• 他のすべての次元は現在のレベルに置いておきます。ボトルネックが解決されるまで、それらには触れません。
• 6か月後に次の評価をスケジュールします。ボトルネックは変化します。新しいボトルネックを見つける必要があります。

定期的に再評価するが、行動した後にのみ

成熟度は一度きりの測定ではありません。それはサイクルです。ボトルネックを見つけます。それを修正します。デリバリーが速くなります。すると、別の場所に新しいボトルネックが現れます。再びそれを見つけます。再び修正します。

これが、6か月ごとに再評価する必要がある理由です。スコアが上がったかどうかを確認するためではありません。ターゲットにしたボトルネックが実際に解決されたかどうかを確認し、現在チームをブロックしている次のボトルネックを見つけるためです。

成熟度モデルはトロフィーケースではありません。それは鏡です。どこで立ち往生しているかを確認するためにそれを見るのであって、どれだけ進歩したかを賞賛するためではありません。

具体的なポイント

すべてを改善しようとするのをやめてください。チームを実際に遅くしている1つのことを見つけてください。それを修正してください。次に、次の1つを見つけてください。これが、チームを忙しくすることなくデリバリーを速くする唯一のロードマップです。