顧客が書いた答えと、機械が持っている事実
一言でいうと
インテークの回答は顧客の記憶であり、システムは事実です。最初の1週間の仕事は、回答を信じることではなく、項目ごとに照合して、食い違う項目と回答のない項目を一覧にすることです。
なぜ必要なのか
現場に入る前には、たいてい質問票を送ります。バージョンは何か、ログを何日保管しているか、どこと連携しているか、バックアップはどれくらいの間隔で動いているか。回答が返ってくると、それを前提にスケジュールとアクセス権限と移行計画を組みます。ところが、入ってみると半分ほどが違っています。
嘘をついたわけではありません。回答を書いた人はたいてい3年前にそのシステムを導入した人で、その後、誰かが保存期間を短くし、誰かが連携を1つ追加し、バックアップの間隔は障害のあとに変わっています。回答はその人の頭の中にあるシステムであり、私たちが向き合うのは現在のシステムです。文書はシステムより遅れて古くなります。
問題は食い違いそのものではなく、食い違いを知らないまま計画を立てることです。ログが30日分残っていると信じて「2週間前のインシデントを再構成します」と約束したのに、実際の保存が14日だったなら、その約束はすでに破れています。破れたことを知るのが着手初日なのか報告の前日なのかが、この仕事の成否を分けます。
どう動くのか
照合を目で行うと、必ず漏れが出ます。項目が20を超え、ある項目は「だいたい合っている」ように見え、ある項目は測る方法がなくて飛ばしてしまいます。そこで、照合はルールをコードに固めて機械に実行させます。ルールは、項目ごとに「どう比較するか」を1つ決めるだけです。
- 完全一致(exact): バージョン文字列やタイムゾーン名のように、1文字違うだけで別の値になる項目です。
- 範囲内(range): 顧客が最初から範囲で回答した項目です。「80日から100日まで」と回答していたなら、測定値がその中に入るかどうかだけを見ます。
- 概数の許容(tolerance): 顧客が「1日1,200件くらい」と回答した項目です。何パーセントまでを同じものとみなすかを、数字で決めておきます。この数字はルールファイルに書いてある必要があり、書いていなければ、それは判定ではなく気分です。
- 一覧の比較(set): 連携先のように、順序に意味がない項目です。順序を入れ替えて書いたからといって、間違いではありません。
ここまでは、合っているか間違っているかの話です。実際の現場でより重要なのは、残りの2つです。
- 回答なし(unanswered): 質問票のその項目が空欄です。測れるかどうかにかかわらず、その項目を決める人が誰なのかを、まず探さなければなりません。
- 確認不能(unverifiable): 回答はあるのに、システムで確認する場所が見つかりません。復旧目標時間(RTO)、待機要員、契約上のSLAなどがここに入ります。
この2つを「一致」にも「不一致」にも書かないことが核心です。確認できていないものを合っていると書けば、あとで誰もその項目を見直さなくなり、間違っていると書けば、顧客と無用な争いになります。わからないものはわからないと書いてこそ、一覧に残ります。
답변 칸 하나
├─ 답이 없다 → unanswered (누가 정하는 값인지부터 묻는다)
├─ 답은 있는데 잴 자리가 없다 → unverifiable (어디를 보면 되는지 묻는다)
└─ 답도 있고 잰 값도 있다
├─ exact 같으면 match_exact
├─ range 범위 안이면 match_in_range
├─ tolerance 허용 오차 안이면 match_in_range
└─ set 집합이 같으면 match_exact
아니면 전부 mismatch
ルールに優先順位を付ける理由も同じです。回答が空で、測る場所もない項目は、両方に当てはまります。このとき何と書くかを事前に決めておかないと、人によって書き方が変わります。このラボでは、回答がないほうを先に見ます。測れないという事実より、「この値を決める人がいない」という事実のほうが危険だからです。
現場での姿
1つ目に、照合結果を指摘の一覧にすると、関係が悪くなります。12項目が間違っているという表を持っていくと、顧客はまず守りに入ります。同じ内容を質問に変えて出すと、会話になります。「ログの保存期間は30日と書いていただきましたが、現在のサーバーには14日分があります。どちらが正しい値でしょうか。」この文は判定ではなく確認であり、答える人も守る必要がありません。そこで、このラボでは照合ツールに質問文まで作らせます。
2つ目に、測定値には根拠が付いている必要があります。「ログ14日」がどこから出たのかが書かれていないと、顧客が「アーカイブにも保管しています」と答えたときに、会話が止まります。根拠が「site/logsディレクトリのファイル名の範囲」と書かれていれば、すぐ次の質問に移れます。アーカイブはどこにあり、そこでは何日分を見られるのか。
3つ目に、1回照合して終わりでは意味がありません。回答はプロジェクトの途中でも更新されます。ルールと照合ツールをファイルとして残しておけば、2週間後に同じコマンドをもう一度実行して、その間に何が変わったかを見られます。目で行った照合は、もう一度実行できません。
4つ目に、許容誤差を使わないと、表が真っ赤になります。「1日1,200件」という回答と「測定値1,104件」を不一致と書くと、本当の問題であるバックアップ間隔(24時間と回答したのに実際は6時間)が、同じ色に埋もれます。概数の項目に誤差を認めるのは大目に見ることではなく、シグナルを活かすことです。
実務で本当に大切なこと
- 回答は証拠ではありません。回答は、どこに尋ねるべきかを示す地図であり、証拠はシステムで測った値です。
- 判定ルールを先に決めてから照合します。照合しながらルールを決めると、自分が見たい結果が出ます。
- わからない項目を一覧に残します。確認不能は結論ではなく、次の質問の置き場所です。
- 結果は質問文で出します。表は私たちが見て、顧客には質問を渡します。
次のラボですること
(架空の)ハンビッ物流のインテーク回答9項目と、その会社の実際のシステムを手にします。システムを自分で測定して事実ファイルを作り、項目ごとに判定ルールを決めてファイルに固め、照合ツールを作って、完全一致・範囲内・不一致・回答なし・確認不能の5つで判定します。採点ツールは、毎回違う値で作った回答と事実を、作成した照合ツールに入れて実際に実行し、判定を1つずつ照合します。最後に、食い違った項目ごとに再度尋ねる質問を機械に作らせ、その結果をレポートの4つの節にして出します。