すべてのデリバリーから学ぶ：改善ループを閉じる

リリースを出荷したとしよう。パイプラインはグリーン、デプロイはスムーズ、ユーザーは満足している。あるいは、大惨事だったかもしれない。マイグレーションの失敗、午前2時のロールバック、「プロセスの問題」を原因とするポストモーテム。いずれにせよ、リリースは終わった。さて、次はどうする？

多くのチームはリリースの終了をゴールテープと見なす。次の機能、次のスプリント、次の火消しに移る。しかし、すべてのリリースには——成功しても失敗しても——貴重な情報が含まれている。新しいバージョンが動作するかどうかだけでなく、デリバリープロセス自体がどのように機能したかについての情報だ。どのステップが遅かったか？どのチェックが繰り返し失敗したか？どのルールが実際には無関係だったか？この情報を取得して活用する仕組みがなければ、デリバリーモデルは現在の成熟度で凍結されたままになる。

すでに持っているデータ

リリース後、学習を始めるために派手なダッシュボードは必要ない。いくつかの基本的な質問への答えが必要だ。

  • 最初のコミットから本番環境に到達するまでにどれくらいの時間がかかったか？
  • その過程でいくつのビルドが失敗したか？
  • 承認ゲートでチームが待機した時間はどれくらいか？
  • 自動化できたはずの手動ステップはあったか？
  • リリース後にインシデントは発生したか？

このデータは通常、CI/CDツール、インシデントトラッカー、チームのチャット履歴に散在している。最初のステップは、これらを1か所に集めることだ。洗練されたレポートである必要はない。共有ドキュメントやシンプルなスプレッドシートで十分だ。重要なのは、数字を正直に見ることだ。

改善すべき3つのレイヤー

データが揃ったら、どこに焦点を当てるかを決められる。改善は3つのレイヤーにわたって機能する。

以下の図は、改善ループがリリースを3つの改善レイヤーにどのように結びつけるかを示している。

flowchart TD A[Release] --> B[Collect Data] B --> C[Analyze] C --> D[Identify Improvements] D --> E[Implement Changes] E --> A subgraph Layers F[Process] G[Platform] H[Policy] end C --> F C --> G C --> H D --> F D --> G D --> H

プロセスは、チームの働き方をカバーする。パイプライン内のステップの順序、意思決定の方法、誰が何を承認する必要があるか、チーム間のハンドオフの方法などだ。

プラットフォームは、ツールとインフラストラクチャをカバーする。CI/CDシステム、テスト環境、デプロイスクリプト、監視ツールなどだ。

ポリシーは、ルールをカバーする。ガバナンスゲート、検証基準、リリースを進める前に満たさなければならない条件などだ。

リリースが遅いのは、プロセスの問題（手動承認が多すぎる）、プラットフォームの問題（ビルドサーバーの性能が不足している）、ポリシーの問題（無関係なものをチェックするゲート）のいずれかである可能性がある。多くの場合、これら3つすべての組み合わせだ。

失敗からだけでなく、成功からも学ぶ

失敗に焦点を当てるのは自然なことだ。壊れたリリースは注意を要求する。しかし、成功も同様に教訓に富んでいる。

リリースがスムーズかつ迅速に進んだときは、その理由を問う。変更が小さく焦点が絞られていたのかもしれない。チームに適切なテストが整っていたのかもしれない。ステージング環境がようやく本番環境に近いものになったのかもしれない。理由が何であれ、それは強化する価値のあるパターンだ。

リリースがうまくいかなかったとき、ゲートやチェック、承認ステップを増やしたくなる。しかし、問題は制御が少なすぎることではなく、多すぎることにある場合もある。実際の問題を決して捕捉しないゲートは、遅延を追加するだけだ。常にパスするテストは誤った自信を与える。改善ループは、うまくいかないものを剪定すべきであり、うまくいくかもしれないものを追加するだけではない。

チームとプラットフォームの間のループを閉じる

多くの組織では、ソフトウェアをデリバリーするチームと、ツールを構築するプラットフォームチームの間にギャップがある。プラットフォームチームは仮定に基づいて機能を追加する。デリバリーチームは黙って制限を回避する。改善ループはこのギャップを埋める。

デリバリーチームがパイプラインのステップが一貫して遅いことを発見したら、プラットフォームチームに報告する。プラットフォームチームは調査し、インフラストラクチャやツールを修正する。プラットフォームチームが新機能をロールアウトするとき、デリバリーチームはそれをテストし、実際に役立つのか、それとも複雑さを増すだけなのかを報告する。

この双方向のフィードバックにより、プラットフォームは関連性を保つ。これがなければ、プラットフォームチームは誰も使わないものを作り、デリバリーチームはニーズに合わないツールに苦しむことになる。

別のミーティングではなく、リリースの一部にする

改善ループは、デリバリーサイクルの外にある月次のレトロスペクティブであってはならない。すべてのリリースに組み込まれるべきだ。

各本番デプロイの後、短いレビューをスケジュールする。正式なミーティングである必要はない。関係者との15分間のチャットで、データを見て、次のリリースに向けて1つか2つの変更に合意すれば十分だ。鍵は一貫性だ。重大なインシデントの後にのみレビューを行うと、時間とともに積み重なる小さな改善を見逃してしまう。

次のリリースレビューのための実用的チェックリスト

次のリリースをクローズする前に、以下の質問を確認しよう。

  • コミットから本番環境までの総リードタイムはどれくらいだったか？
  • いくつのビルドが失敗し、その理由は何か？
  • リリースを遅らせた手動ステップはあったか？
  • 実際の問題を捕捉できなかった検証ゲートはあったか？
  • 実際には何も有用なチェックをせずにパスした検証ゲートはあったか？
  • リリース後にインシデントはあったか？もしあれば、もっと早く捕捉できたか？
  • 予想以上にうまくいったことは何か？その理由は？
  • 次のリリースをより速く、またはより安全にするために、どのような変更を1つ行うか？

このリストから1つの項目を選び、次のリリースの前にそれに基づいて行動する。すべてではなく、1つだ。

まとめ

すべてのリリースはデータポイントである。改善ループは、そのデータをより良いプロセス、より良いプラットフォーム、より良いポリシーに変える。大規模なイニシアチブや専任チームは必要ない。必要なのは習慣だ。すべてのデリバリーの後、何を学んだかを問い、その答えに基づいて1つの小さな変更を行うことだ。

デリバリーモデルは静的であってはならない。すべてのリリースとともに成長すべきだ。大規模な変革を計画するからではなく、各デリバリーが教えてくれることに注意を払うからだ。