本番インフラ移行のカットオーバー判定は、エンジニアだけで下してよいか

まとめ

• 「コードを変更していない」はテスト範囲を狭める根拠になる。判定権を狭める根拠にはならない
• 判定に入らない人へ説明責任だけを乗せる配分は成立しない。権限と説明責任は同じ側に置く
• 巻き込みの是非を関係者の議論で決めようとすると平行線になる。権限を渡される本人に聞いたほうが早い

判定を誰が出すか

本番環境を丸ごと別基盤へ移す。

切り替えてよいかの最終判定を、エンジニアだけで出す形にできるか。

表1: 判定の出し方を決めるフロー

手順	判断すること	結果
1	サービス停止やデータ不整合が利用者に到達しうるか	到達しないならエンジニア単独で可
2	障害時に外部へ説明する主体がエンジニア以外にいるか	いるならその主体を判定に含める
3	上のどちらにも当てはまらない	エンジニア単独で判定する

既定はビジネスオーナーを含めた判定になる。

本番の移行は、手順1でほぼ必ず引っかかるからだ。

手順1で落ちるのは、ステージング以下の環境に閉じた作業。ここは単独でよい。

本番を特別扱いしているのではなく、利用者に届くかどうかで切っている。

「ソース変更なし」はどこまで効くか

インフラだけを入れ替える移行では、アプリケーションのコードに一切手が入らないことがある。

このとき「変更点が明確なので確認範囲も絞れる」という主張が出る。

フレームワークのバージョンアップのように影響範囲が読めない変更なら、変わった箇所を特定できないので広くテストするしかない。

環境の入れ替えはどこが変わったかわかっているので、そこを厚く見れば足りる。全面的な受入テストを敷かない判断には、それなりの根拠があると思う。

問題は、この根拠が効く先だ。効くのは確認の範囲であって、判定を誰が出すかではない。

切り替えてよいかの判断には、停止を何分許容するか、障害が出たときにどこまで受け入れるかが含まれる。

そこはエンジニアの担当ではない。

「どこが変わったか知っているのはエンジニアだけだ」という主張はその通りで、だから確認の実行はエンジニアが持つ。

そこから判定も持つ、へは繋がらない。範囲の話で権限の話まで決めてしまうと、議論は噛み合わなくなる。

2つの配分を比べる

表2: 判定権と説明責任の配分

観点	エンジニア単独で判定	ビジネスオーナーを含めて判定
確認作業の実行	エンジニア	エンジニア
確認観点の提示	エンジニア	双方
切り替え実行の判定	エンジニア	双方の合意
障害時の外部説明	ビジネスオーナー	ビジネスオーナー
停止許容時間の決定	明示されない	ビジネスオーナー
ビジネスオーナーの稼働	ほぼゼロ	判定と観点提示の分

左の列は、外部説明の行だけが他と揃っていない。

判定に入っていない人が、結果の説明だけを引き受ける形になる。

停止許容時間が「明示されない」に落ちるのも同じ理由で、決める人がいないまま当日を迎える。

右の列がただしいわけでもない。

ビジネスオーナーの稼働は希少で、巻き込みを増やすほど良いという性質のものではない。

判定と観点提示だけを渡し、確認作業そのものは渡さない。そのあたりが落としどころだと思っている。

議論で決まらないときの抜け方

この論点は、関係者の間で議論しても収束しにくい。

巻き込むべきだと考える側は「観点が漏れる」を根拠にし、必要ないと考える側は「観点を出せる人がいない」を根拠にする。

どちらも確認の話をしていて、権限の話に入っていない。だから何度やっても同じところへ戻る。

自分の場合は、同じやり取りを複数回繰り返して、そのたびに同じ結論に着地した。同席していた別のメンバーが同趣旨を述べても変わらなかった。

言い方を変えれば通る、という前提はここで捨てた。

抜け方は、議論の相手を変えることだった。

判定に入るかどうかを判断する権利は、もともとビジネスオーナー本人にある。

責任分界の説明を本人にして、「判定に入らないまま説明だけするのは困る」と言われれば、その場で論点は終わる。何も言われなければ、少なくとも当事者間では合意が成立している。

どちらに転んでも、関係者の平行線からは出られる。

権限の配分で社内の意見が割れたときは、配分される側に聞くのが最短になる。

割れている当人同士は、相手を説得する材料を持っていない。持っているのは、その権限を渡される本人だけだ。