デリバリーパイプラインにおけるハンドオフの隠れたコスト
コードをプッシュし、チケットを発行して待つ。QAチームは別のスプリントの作業で忙しく、あなたの変更は2日間キューに滞留する。ようやくテストが始まると、軽微な修正が必要な問題が見つかる。あなたはすでに別の機能に移っているため、先週書いたコードに再び頭を切り替えるのに1時間を費やす。修正して再プッシュし、同じサイクルを繰り返す。今度はデプロイチームが手一杯で、さらに1日待つ。ようやく本番環境に変更が反映されたときには、何をテストしたのか、なぜその判断を下したのか、誰も正確に覚えていない。
このシナリオは、多くのエンジニアリング組織で痛いほどよく見られる光景だ。問題は、人材が悪いとか意図が悪いということではない。ハンドオフ（引き継ぎ）に伴う目に見えないコストが原因なのである。
ハンドオフが高くつく理由
作業が一人または一つのチームから別のチームに移るたびに、コストが発生する。これらのコストが追跡されることはほとんどないが、すべてのデリバリーサイクルを通じて累積していく。
次の図は、単一の変更が複数のハンドオフを経てどのように遅延を蓄積するかを示している。
最も明白なコストは待ち時間だ。 開発者がコードを完成させてQAに引き渡すと、そのコードはキューに入る。QAは別のテストサイクルの終了、会議への出席、本番環境の問題対応などで忙しいかもしれない。キューは数時間から数日続く可能性がある。その待ち時間の間に、開発者は他の作業にコンテキストスイッチしている。QAがようやく問題を見つけたとき、開発者は数日前に書いたコードのメンタルモデルを再構築しなければならない。この再方向付けには時間がかかり、リスクも伴う。
コミュニケーションの行き違いが遅延を悪化させる。 開発者は何が変更され、どの部分に注意が必要かを正確に把握している。しかし、QAに引き渡す際に、その知識は完全には伝わらない。QAは間違ったシナリオをテストしたり、重要なエッジケースを見逃したり、実際には問題ではないものの修正を要求したりする可能性がある。バグがすり抜けるのは、テストする人が構築する人の考えを理解していないからだ。
コンテキストはハンドオフのたびに失われる。 単一の変更が、開発者、QA、セキュリティレビュー担当者、DBA、デプロイエンジニアの5人を経由することもある。本番環境で問題が発生した場合、原因を追跡するのは探偵ゲームのようになる。各人はパズルの自分のピースしか知らない。なぜ変更が行われたのか、何が考慮されたのか、何がテストされたのかという全容は、会話、チケット、記憶に断片化される。
本当のコストは時間だけではない
これらのコストは、単に速度を低下させるだけではない。チームの行動そのものを変えてしまう。ハンドオフが摩擦を生むと、人々はそれを回避し始める。開発者はハンドオフの回数を減らすために変更をバッチ化し、その結果、各リリースはより大きく、よりリスクの高いものになる。QAはキューが長いことを知っているため、不完全なテストを受け入れ始める。セキュリティレビューは形骸化し、誰もすべての変更を徹底的にレビューする時間がなくなる。
システムはハンドオフに適応するが、その適応の仕方はデリバリーを悪化させる方向に働く。
役割を排除せずにハンドオフを減らす
解決策は、QA、セキュリティエンジニア、DBAを排除することではない。これらの役割には正当な理由がある。解決策は、彼らがデリバリープロセスに参加する方法を変えることだ。
セルフサービスが最も効果的なパターンである。 別のチームが何かをするのを待つのではなく、各チームが他者が提供するツールとサービスを使って自分たちの作業を行う。開発者は、QAに手動テストを依頼することなく、パイプラインで自動テストを実行する。QAは、DevOpsの設定変更を待つことなく、パイプラインに新しいテストケースを追加する。セキュリティエンジニアは、毎回手動レビューを行うことなく、すべての変更が自動的にチェックされるようにルールをパイプラインに組み込む。
ここでプラットフォームチームの価値が発揮される。プラットフォームは、自動テスト、セキュリティスキャン、データベースマイグレーションのステップを含む標準化されたパイプラインを提供する。開発者がコードをプッシュすると、パイプラインが自動的に実行される。QAはダッシュボードでテスト結果を監視する。セキュリティエンジニアはスキャンレポートをレビューする。誰も他の人を待つことはない。誰も手動で作業を引き継ぐことはない。
自動化がハンドオフを置き換える。 パイプラインが、ステージからステージへと作業を移動させるメカニズムとなる。キューで待つことはない。コンテキストを忘れることもない。すべてのステップ、すべての判断、すべての結果を記録する。何かが失敗した場合、パイプラインはどこでなぜ失敗したかを正確に示す。
それでも人間の関与が必要なもの
すべてのハンドオフを自動化できるわけではない。いくつかの判断には、真に人間の判断力が必要である。本番リリースの承認、複雑なアーキテクチャ変更のレビュー、インシデント発生時のデプロイロールバックの判断などは、人間のコンテキストと経験の恩恵を受ける。
目標はハンドオフをゼロにすることではない。目標は、価値を生まないハンドオフを排除することだ。自動チェックがルーチン的な判断を処理する。人間は、機械にはできない例外、トレードオフ、判断を要する事項に集中する。
ハンドオフ削減のための実践的チェックリスト
次のリリースサイクルの前に、チームで以下の質問を確認しよう。
- 現在のプロセスにおいて、純粋に管理的なハンドオフ（チケットの移動、ステータスの更新、通知の送信）はどれか？
- 手動テストのステップを、パイプライン内の自動テストに置き換えられるか？
- セキュリティチームはすべての変更をレビューしているか、それとも機密領域に触れる変更のみをレビューしているか？
- 開発者は、別のチームを待たずに自分たちでテスト環境をプロビジョニングできるか？
- パイプラインは、誰でも変更の履歴を追跡できるように、判断と結果を記録しているか？
チーム内で最も待ち時間や混乱を引き起こしているハンドオフを一つ選び、次のリリースまでに自動化するか、セルフサービス化しよう。
まとめ
ハンドオフは、よく構造化されたプロセスの証ではない。それらは、デリバリーを遅らせ、コンテキストを侵食し、リスクを生み出す摩擦点である。確実にデリバリーを行うチームは、役割を排除するのではない。彼らは、人間のキューを通じて作業を渡すことなく、各役割が貢献できるようにするパイプラインとプラットフォームを構築することで、待ち時間、コミュニケーションの行き違い、失われたコンテキストを排除する。自動化したハンドオフは、二度と行う必要がなくなった判断である。