止める決断は実行前だけが安い
一言でいうと
異常の兆候を見て止めるかどうかは、実行中には決められません。そのときには、すでにかけた時間と半分だけ変わった状態が「続ける」側へ押すので、止める場所は実行前に紙に書いておく必要があります。
なぜ事前に決めるのか
変更を半分ほど適用した状態で、対照群の数字が計画と違って出たとしてみましょう。いま必要な判断は「止めるか」の1つだけですが、その判断を下す人の条件は、30分前とはまったく違います。
すでに2時間を使い、顧客企業の担当者が画面の横に座っていて、データは半分だけ変わった状態です。この状態で人は、ほとんどいつも続ける側に傾きます。「ここまで来たのだから、終わらせてから見よう」「今止めたら、状態がもっとおかしくなる」。どちらの文もその瞬間には合理的に聞こえ、あとで事故報告書で読み返すと、どちらも言い訳です。
そのため、止める場所は、まだ何も変えていないとき、つまり止めるのにコストがまったくかからないときに決めておきます。実行中の自分は、その文を書き直す人ではなく、その文を守る人です。
どう動くのか
使える中止基準には、3つが全部入っていなければなりません。
관측할 수 있는 지표 무엇을 보고 판단하는가. 느낌이 아니라 세어지는 것.
넘으면 안 되는 값 그 지표가 얼마가 되면 이상인가. 부등호와 숫자로.
그때 할 행동 멈추고 무엇을 하는가. 되돌린다 / 보류하고 보고한다.
3つのうち1つでも欠けると、実行中に解釈の余地が生まれ、解釈の余地はいつも「続ける」側に使われます。「異常があれば止める」は、中止基準ではなく覚悟です。
部分適用の状態が、最も危険です。変更前の状態と変更後の状態はどちらも説明できますが、半分だけ変わった状態は、どのドキュメントにもありません。そのため、止めるというのは「その場に立ち止まる」ではなく、たいてい「元に戻す」ことです。元に戻せなくてその場に立ち止まるしかないなら、その事実自体をただちに知らせるところまでが、中止の行動です。
時間も基準です。変更ウィンドウが60分なら、適用は60分ちょうどに終わるのではなく、元に戻すのにかかる時間と、戻したあとに確認する時間を差し引いて終わらなければなりません。元に戻す時間がない状態でウィンドウを超えると、そのあとは中止基準があっても、実行する手段がありません。
そして最もよい方法は、元に戻せない変更を作らないことです。削除の代わりに削除マークを残し、猶予期間のあとで消すようにすれば、元に戻せない1回が、元に戻せる2回に分かれます。列を削除する代わりに、まず書き込みを止めて1周期見守るのも、同じ方式です。こうして分けられるかを先に問うことは、中止基準をうまく書くことより優先されます。
現場での姿
実行の直前に、依頼者から条件を1か所だけ変えてほしいと言われることがよくあります。「あ、その注文は外してください」の一言で済むように聞こえますが、条件が変わると、範囲の算定もドライランもバックアップも、すべて別の条件の上で行ったものになります。正しい対応は、その1か所を反映して前の段階をやり直すことであり、時間がなければ、元の条件で実行したあと、差分を別の変更として扱うことです。その場で条件だけ直して実行するのが、最もよくある事故の経路です。
もう1つ、中止を実際に実行したあとは、止めたという事実そのものが報告の対象です。元に戻したから何もなかったことにして済ませると、顧客企業はあとでログからその痕跡を見つけ、私たちが隠したと受け取ります。止めた理由と元に戻した範囲、そして再試行する条件を、その日のうちに書いて送るところまでが、1サイクルです。
中止基準の書き方
「異常があれば止める」は、基準ではありません。実行中にそれを判断する人はすでに緊張しており、曖昧な文は、そのとき何の助けにもなりません。使える基準は、数字と比較対象を持っています。
悪い例 対象が想定より多ければ止めます
使える例 対象が依頼書の120件と違えば止めます
より良い例 対象が120件でなければ止めて、実際の件数を出力します
3種類に分けて書きます。開始前に確認すること(範囲・バックアップ・権限)、進行中に見ること(不変条件・エラー率・速度)、そして終わったあとに確認すること(合計・サンプルの照合)です。3つを混ぜて書くと、実行中に何を見るべきかがぼやけます。
不変条件を、必ず1つは入れます。「合計は変わらない」「状態がAの件は0になる」「他の顧客の行は1件も変わらない」のように、真でなければならない文です。これがないと、件数だけ合っていて内容が違う事故を捕まえられません。
止める方法も、一緒に書きます。どうやって止めるのかわからない基準は、基準ではありません。1件ずつ処理する作業なら、次の件に進まないことで足りますが、一度にすべて変える作業なら、トランザクションの中で行わなければ止められません。止められない形で組んでおいて中止基準を書くのが、最もよくある無駄骨です。
そして前に述べたとおり、元に戻せない変更を分けられるかを、先に問います。分けられるなら、中止基準の重みは半分に減ります。基準をうまく書くより、基準の重要度を下げるほうが、いつもよい方法です。
次のラボですること
依頼書が120件と言っていた変更の実際の対象が、480件だった現場を受け取ります。中止基準を紙に書くだけで終わらせず、コードに執行させます。
採点ツールがスクリプトを3つの依頼で直接実行し、実行前後のデータを照合します。範囲基準に引っかかるべき依頼、途中で不変条件が壊れて元に戻すべき依頼、そして通るべき依頼です。
最後が重要です。止めるだけで仕事が進まないなら、それも失敗です。