デプロイの最終責任者は誰か
どのデプロイも良い意図から始まります。開発者がコードを書き終える。QAがステージング環境でのテストを承認する。セキュリティ部門が許可を出す。プロダクトマネージャーが機能の準備完了を確認する。全員が自分の役割を果たしています。
そして本番環境にデプロイした途端、アプリケーションの応答が遅くなる。ユーザーから苦情が殺到する。チームは慌てふためく。
開発者はコードに問題はないと言う。QAはステージングでテストは通ったと言う。DevOpsはインフラは正常に動作していると言う。誰もが自分に非がない正当な理由を持っている。そして誰も修正する責任を感じていない。
このシナリオは、あらゆる規模のチームで発生します。問題は技術スキルや意図の悪さではありません。明確な所有権（オーナーシップ）の欠如です。
全員が所有すると、誰も所有しない
複数のロールがデプロイに関わると、責任は薄く拡散しがちです。各人は自分の担当範囲に集中します。開発者はコード変更を気にする。QAはテストカバレッジを気にする。DevOpsはインフラの安定性を気にする。セキュリティはコンプライアンスを気にする。
これらはすべて重要な関心事です。しかし、何か問題が発生したとき、全体像を最初から最後まで把握している個人はいません。難しい決断を下せる者もいません。結果に対して説明責任を感じる者もいません。
責任の共有は協力的に聞こえます。実際には、しばしば「自分の問題ではない」になります。デプロイは孤児になります。全員が貢献したが、誰も所有していないのです。
一人の人間、一つの決定点
すべてのデプロイには、最終責任を持つ一人の人間が必要です。チームではありません。部門でもありません。一人の名前です。
この人物がすべての作業を行うわけではありません。開発者、QAエンジニア、プラットフォームチームを置き換えるものでもありません。しかし、難しい決断が必要なとき、その決断を下すのはこの人物です。何かが壊れたとき、最初に呼ばれるのはこの人物です。ロールバックするか、そのまま修正を進めるかの判断が必要なとき、この人物が決断します。
この概念はDRI（Directly Responsible Individual、直接責任者）と呼ばれることがあります。堅苦しい用語ですが、考え方はシンプルです。本番環境に送られるすべての変更に対して、自分が説明責任を負っていると認識している人物が一人いなければなりません。
誰がオーナーになるべきか
適切なオーナーは、変更の種類とチームの構成によって異なります。
アプリケーションコードの変更の場合、通常はそのコードを書いた開発者が最適です。何が変更されたか、どのような副作用が発生する可能性があるか、問題を迅速に修正する方法を理解しています。自分でインフラを操作する必要はありませんが、変更が本番環境で正しく動作することを確認するために立ち会うべきです。
インフラストラクチャの変更や環境設定の場合、DevOpsエンジニアやプラットフォームエンジニアの方が適していることが多いです。本番環境でのシステムの振る舞いや、異常が発生した場合の対処法を理解しています。
データベース変更の場合、DBAまたはデータベースに関する深い知識を持つ開発者がオーナーシップを取るかもしれません。データベースマイグレーションには特有のリスクが伴い、オーナーはスキーマ変更と実行時の振る舞いの両方を理解している必要があります。
重要なのは役職名ではありません。明確さです。すべてのデプロイには、自分が責任を負っていると認識している人物が一人いるべきです。開発を離れてから本番環境で安定するまで、変更に寄り添い続ける人物が一人いるべきです。
オーナーシップは非難ではない
これは最も重要な区別です。単一のオーナーを割り当てることは、問題が発生したときに罰する相手を見つけることではありません。コントロールを掌握する人物を確保することです。
健全なチーム文化では、デプロイの失敗は学習の機会です。チームは何が起こったのかを調査し、根本原因を見つけ、プロセスを改善します。オーナーはその調査を主導し、改善を推進します。スケープゴートではありません。
この区別がなければ、チームはオーナーシップを避けます。何かが壊れたときに非難される人物になりたい人はいません。そのため責任は曖昧なままで、問題は解決が難しくなります。
オーナーシップが非難ではなくコントロールとして捉えられると、人々はより積極的に名乗り出るようになります。チームからのサポートがあることを知っています。目標がシステムを改善することであり、責任の所在を明らかにすることではないと理解しています。
オーナーシップがワークフローをどう変えるか
明確なオーナーシップは、チームの日々の運用を変えます。実際の様子は次の通りです。
開発者が機能を完成させ、デプロイを準備します。この変更のオーナーは開発者です。QAと連携してテストが完了したことを確認します。プラットフォームチームにインフラの準備ができているか確認します。プロダクトマネージャーにタイミングが適切かを確認します。
デプロイが始まると、開発者はロールアウトを監視します。メトリクスを確認します。ログをチェックします。変更が安定するまで待機します。
何か問題が発生した場合、開発者が判断を下します。すぐにロールバックすべきか？ホットフィックスを適用できるか？開発者は会議を待ったり、複数の人を経由してエスカレーションしたりすることなく、迅速に判断するためのコンテキストを持っています。
他のチームメンバーもそれぞれの仕事を続けます。QAは依然としてテストを行います。プラットフォームチームはインフラを監視します。セキュリティは変更をレビューします。しかし、不確かなことがあった場合に誰に聞けばよいか、全員が知っています。最終決定権を持つ人物を全員が知っています。
不明確なオーナーシップのコスト
明確なオーナーシップがないチームは、見えにくいコストを支払っています。それは時折発生するデプロイの失敗だけではありません。信頼とスピードが徐々に損なわれていくことです。
誰もデプロイを所有していないと、決断が遅れます。人々は来ることのない承認を待ちます。誰が決断すべきかを決めるための会議が開かれます。早期に対処する責任を感じる者がいないため、小さな問題がインシデントに発展します。
何かが壊れたとき、チームは問題を実際に修正するよりも、誰が対応すべきかを決めることに多くの時間を費やします。責任のなすり合いが始まります。信頼が損なわれます。人々はより慎重になり、率先して行動することをためらうようになります。
時間が経つにつれて、デプロイプロセスは遅く官僚的になります。チームにスキルが不足しているからではなく、物事を前に進める明確な権限を持つ者がいないからです。
デプロイオーナーシップのためのシンプルなチェックリスト
すべてのデプロイの前に、以下の点を確認してください。
- この特定の変更に対するオーナーとして一人の人物が指名されている
- オーナーが最初から最後まで自分が責任を負っていることを認識している
- オーナーがロールバックまたは修正継続の判断を下す権限を持っている
- チームの他のメンバーが誰がオーナーかを知っている
- オーナーがデプロイを監視するために必要なツールと情報にアクセスできる
このチェックリストは30秒で完了します。何時間もの混乱を防ぎます。
まとめ
次回のデプロイには、それを所有する一人の人物が必要です。委員会ではありません。共有責任ではありません。結果に対して説明責任を負っていると認識している一人の人物です。その人物がすべてを一人で行うわけではありませんが、決断が重要となる時点でのコントロールポイントとなります。
デプロイする前に、その人物を指名してください。何かが壊れた後ではなく。