復旧手順が1人の頭にしかない事業

事業の売買で、技術まわりの質問がひととおり終わりかけた頃に、買い手が思い出したように尋ねる項目があります。「障害が起きたときの復旧手順書はありますか」。この問いに返ってくる答えは、驚くほど高い確率で同じ形をしています。

「手順書というものは特にないんですが、私がやれば30分くらいで戻ります」

売り手はここで嘘をついていません。むしろ極めて正直です。実際にその人がやれば30分で戻るのでしょうし、過去に何度もそうしてきたのでしょう。それでも、この一文が買い手側のエンジニアの手を止めます。いま目の前で宣言されたのは、この事業の復旧能力が、事業ではなく目の前の人間に付いているという事実だからです。

そして、ここからが本題です。この状況を「属人化させた売り手の怠慢」として処理すると、構造を完全に読み違えます。手順書が無いことは症状であって、原因ではありません。原因はもっと厄介な場所にあって、しかもその厄介さの核心は、その手順が、手順を持っている本人にすら見えていないという点にあります。

「私がやれば30分」は、正直であるがゆえに致命的

まず、この答えが買い手に何を伝えてしまったのかを分解します。

「30分で戻ります」という発言は、技術力の高さの表明として口にされています。実際そのとおりで、障害を30分で収束させられる運営者は普通に優秀です。ただ、買い手の耳にはまったく別の意味で届きます。「この事業には、あなたが居ないと戻せない状態が存在する」という意味です。

買い手が買おうとしているのは、コードとサーバーとドメインとユーザーの集合ではありません。それらが「動き続ける状態」です。動き続けるとは、壊れないことではなく、壊れたときに戻ることを指します。壊れない事業は存在しないので、事業の継続性は結局のところ復旧能力とほぼ同義です。

その復旧能力が売り手本人に紐づいているなら、引き渡しの瞬間にそれは事業から抜けていきます。サーバーは移管できます。ドメインも移管できます。頭の中身は移管できません（当たり前の話ですが、この当たり前が査定の現場では驚くほど軽く扱われます）。

ここで多くの取引が採る解決策が、「引き渡し後3ヶ月は売り手がサポートする」という条件です。悪くない緩衝材ですが、これは問題を解いていません。3ヶ月後に同じ障害が起きたらどうするのか、という問いが手つかずで残っているからです。サポート期間は、暗黙知を移すための時間ではなく、暗黙知の不在に気づくのを先送りする時間として消費されがちです。引継ぎマニュアルを用意する話がここで持ち出されるのも、だいたいこのタイミングです。

手順書を書かなかったのは、読者が一度もいなかったから

ここで、売り手を弁護しておく必要があります。というより、弁護ではなく事実の確認です。

手順書というのは、自分以外の誰かに読ませるために書く文書です。目的は情報の保存ではなく、伝達です。ということは、読者が存在しない場所では、書く動機が原理的に発生しません。

1人で運用してきた事業を思い浮かべてください。障害が起きます。直します。直せます。誰にも渡さないので、渡すための文書が要りません。翌月また同じ障害が起きます。前より速く直せます。手順は書かれるのではなく、身体に沈んでいきます。これを何年も繰り返した先に、いまの「30分で戻ります」があります。

この経路のどこにも、怠慢が入り込む隙間がありません。むしろ逆で、手順書を書く時間を機能開発と集客に回してきたからこそ、その事業は生き残って、いま売買のテーブルに載っています。手順書が無いことは、その事業が1人の裁量で高速に回ってきたことの副産物であって、運営が雑だった証拠ではない。ここを取り違えると、売り手は防御的になり、買い手は疑い深くなり、交渉は本題に入る前に空気が悪くなります。

「属人化」という言葉は便利ですが、便利すぎて、この構造を全部潰してしまいます。属人化させたのではなく、人が1人しかいなかった。それだけの話です。批判すべき対象がどこにもない現象に、批判の語彙を当ててはいけません。

暗黙知は、本人にも見えない

さて、ここからが本題です。手順書が無い理由が「書く必要がなかったから」だとすれば、いま必要になったのだから書けばいい、という結論になりそうです。ところが、そうなりません。

哲学者のマイケル・ポランニーが残した有名な指摘に、「人は語れる以上のことを知ることができる」というものがあります。自転車に乗れる人は、自転車の乗り方を説明できません。「バランスを取ります」以上のことを言えない。実際には倒れかけた方向へハンドルを切るという物理法則に従った操作をしているのですが、乗っている本人はそれを知りません。知らないまま、完璧に実行しています。

障害対応も、まったく同じ構造をしています。

「サイトが重い」という一報が入った瞬間、経験のある運営者の頭の中では、最初の数秒でこういうことが起きています。今日は何曜日の何時か。バッチが動く時間帯か。広告の配信が始まる時刻か。直近でデプロイしたか。誰かが管理画面から何かを触ったか。先月の同じ症状は何が原因だったか。重いのは全ページなのか特定のページだけなのか。外部のどのサービスが今日ざわついているか。

これは全部、判断です。しかも数十本の可能性を数秒で刈り込む、高度な判断です。ところが本人の自覚に残るのは、たった一言です。

「なんとなくDBかなと思って、DBを見ました」

本人の記憶はここで終わっています。DB以外の数十の可能性を、瞬時に、無意識に、捨てている。その刈り込みは意識に上らないので、記憶にも残りません。記憶に残っていないものは、当然、書けません。

つまり、この売り手が持っている資産のうち最も価値が高い部分は、本人が「持っている」と認識していない部分です。本人は自分のことを「何もしていない」と思っています。実際には、事業を1本支えるだけの判断を毎回やっている。この認知のズレが、この論点のすべての難しさの出どころです。

一番見えないのは「これはおかしい」と気づく力

暗黙知の中でも、群を抜いて移しにくいものがあります。異常を異常だと察知する能力です。

何年も同じ事業を見てきた運営者は、正常の形を知っています。火曜の午前はアクセスが落ちる。月末は問い合わせが増える。この画面のこの数字は、だいたいこのくらいの幅で動く。土曜の深夜にエラーが数件出るのは昔からで、あれは無視していい。

この「正常のベースライン」は、監視ツールのどこにも保存されていません。何千回も同じダッシュボードを見てきた人間の目の中にしかない。だからこそ、その人は数字を一瞬見ただけで「今日はおかしい」と分かります。閾値を超えているからではなく、形が違うから分かる。

買い手には、この目がありません。引き渡された直後の買い手にとって、すべてのグラフは初見です。初見のグラフを見て「これは異常だ」と判断することは、原理的に不可能です。比較対象が無いので。

ここから、地味で、しかし相当に重い帰結が出てきます。障害は「起きたとき」ではなく「気づかれたとき」に始まるということです。気づかれない障害は、障害として存在しません。存在しないまま、数字だけを静かに削っていきます。

引き渡しから3ヶ月ほど経って、買い手が「なんとなく数字が落ちている」と言い出す。調べても原因が分からない。実際には、2ヶ月前から特定の導線が壊れていて、旧オーナーなら1日で気づいた種類の壊れ方をしている。しかし買い手にはそれが「そういうものだ」としか見えていない。これは引き渡し後の事故の中でも最も発見が遅い型で、遅い理由はシンプルに、誰も探していないからです。

監視が足りないという話に見えますが、少し違います。監視は「知っている異常」しか教えてくれません。アラートの条件は、過去に痛い目を見た人が設定するものだからです。売り手の頭の中には、まだアラートになっていない異常のカタログが入っています。移せていないのは、そのカタログです。

「手順書を書いてください」では、絶対に取り出せない

ここまでを踏まえると、標準的な処方箋が効かない理由がはっきりします。

引き継ぎのために手順書を書いてください、と依頼する。売り手は誠実に机に向かう。数日後に出てくる文書が、これです。

1. サーバーにSSHでログインする
2. ログを確認する
3. 原因を特定して修正する
4. 動作を確認する

買い手はこれを見て「手を抜かれた」と感じます。しかし売り手は1ミリも手を抜いていません。本人にはこう見えているのです。ここで不誠実だと解釈すると、この後の交渉は全部間違った前提の上を走ることになります。

復旧の知識は、だいたい3つの階層に分かれています。

• 第1層・書ける知識: サーバーの場所、認証情報の在り処、よく使うコマンド、管理画面のURL。これは書けば済みます。誰でも書けるし、依頼すれば必ず出てきます
• 第2層・思い出せば書ける知識: 順序と依存関係。「Aを再起動する前にBを止めないと詰まる」「この作業は先にキューを止めてから」。指摘されれば「ああ、そういえば」と書けます。ただし自発的には出てきません
• 第3層・知っていることを知らない知識: 数十の可能性の刈り込み、異常の察知、「この症状ならまずここ」という直感の中身。内省では絶対に取り出せません

「手順書を書いてください」という依頼が回収できるのは、第1層だけです。第2層は運が良ければ半分。第3層はゼロです。そして、事業の復旧能力の実体は、ほぼ全部が第3層にあります。

ここは環境構築の属人化とよく似た顔をしていますが、質が違います。環境構築は、時間さえかければ本人が思い出して書けます（第2層です）。障害時の判断は、時間をかけても書けません。記憶の問題ではなく、そもそも一度も意識に上っていないからです。存在を知らないものを思い出すことはできません。

次の障害のとき、画面を録画してください

内省で取り出せないものを取り出す方法は、ひとつしかありません。外から観測することです。

具体的には、こうです。次に何かが壊れたとき、直し始める前に画面録画を開始します。それだけです。そして、いつもどおり直します。特別なことは何もしません。

できれば、独り言を喋りながら直してください。「うーん、まずログか」「いや、これ先週のあれかも」「あ、違うわ」。喋る内容は支離滅裂で構いません。むしろ支離滅裂な方が価値があります。整理された言葉は、整理する過程で第3層が落ちてしまうからです。

復旧が終わって、コーヒーでも飲んで落ち着いた頃に、その録画を見返します。ここで初めて、面白いことが起きます。

自分が何をやっていたのかを、本人が初めて知るのです。

「なんでここでこのタブを開いたんだろう」と思う瞬間が必ず来ます。そこに理由があります。数秒考えれば思い出せます。「ああ、この時間帯だとバッチを疑うからだ」。それが第3層です。いま、意識に上りました。上がったなら、書けます。

もっと重要なのは、開かなかったタブの方です。録画を見ていると、見ていない場所が分かります。なぜそこは見なかったのか。「あそこは去年作り直したから、まず壊れない」。それも第3層です。というより、刈り込みこそが第3層の本体なので、こちらの方が情報量が多い。手順書は「やったこと」を書く文書ですが、暗黙知の大半は「やらなかったこと」の側に埋まっています。

録画を書き起こすとき、完璧な手順書を作ろうとしないでください。完璧を目指した瞬間に永久に完成しません（これは手順書に限らず、あらゆる文書に共通する呪いです）。書くのは、実際に起きたこと1件だけです。「この日、この症状で、最初にここを見て、次にここを疑って、原因はこれで、こう直した。ここは見なかった、理由はこう」。それだけで、第1層から第3層まで全部入った文書が1本できます。

そして、これを3件か4件貯めると、共通のパターンが浮かび上がってきます。その頃には、もう手順書を書こうとしなくても、書けるようになっています。順序が逆なのです。手順書を書いてから障害に備えるのではなく、障害を記録したら手順書になっていたという順序でしか、この文書は完成しません。

障害がしばらく起きないなら、演習でも構いません。ステージング環境で自分でわざと壊して、直すところを撮る。ただし正直に言えば、本物の障害の方が圧倒的に質が高いです。本物には焦りがあり、焦っているときに最初に見る場所こそが、その人の優先順位そのものだからです。落ち着いて演習すると、人は教科書どおりの順序で調べてしまいます。それは第1層の再生産にしかなりません。

コストは、録画ボタンを押す2秒です。

買い手が聞くべきなのは、手順書の有無ではない

買い手側の実務に落とし込みます。

まず、「手順書はありますか」という質問を捨ててください。この問いは情報量がほぼゼロです。答えは「ある」か「ない」の二値で、「ない」なら第3層の話に入れず、「ある」と言われても中身が第1層なら意味がありません。有無を尋ねる質問は、有無しか教えてくれない。

代わりに、こう聞きます。

「直近で起きた障害を1件、最初に気づいたきっかけから復旧までを、時系列で話してもらえますか」

この問いが優秀なのは、答えている最中に、本人が意図せず第3層を漏らすからです。「まずキャッシュを疑って」と口にした瞬間に、次の質問が用意できます。「なぜ最初にキャッシュだったんですか」。ここで返ってくる答えが、この事業の復旧能力の実体です。書面には一行も存在しない部分が、雑談の形で出てきます。

もうひとつ、必ず聞くべき問いがあります。「その障害に、どうやって気づきましたか」。監視から通知が来たのか、たまたま画面を見ていて気づいたのか。後者だった場合、その「気づく目」は引き渡せません。これは前述のベースラインの話そのもので、事業に付いていないものは移管の対象になりません。

「障害は一度も起きていません」という答えが返ってきた場合の読み方も決めておく必要があります。可能性は2つです。本当に安定しているか、起きていることに誰も気づいていないか。判別は簡単で、「じゃあ直近1年で、想定と違う動きをして調べたことは何かありますか」と聞き直せば、たいてい何か出てきます。何も出てこない事業は、監視が無いか、見ていないかのどちらかです。

この検分は技術的DDの中でも、コードを読む前の段階に置く価値があります。実際に手を動かして検証する復元テストとは対になる関係で、あちらが「データを戻せるか」を確かめるのに対し、こちらは「何が起きているかを切り分けられるか」を確かめます。順序としては、切り分けが先です。何が壊れたか分からない状態からバックアップを戻す判断は下せないので。

査定への織り込みは、おおむね3段階になります。

• 監視から通知が飛び、記録された対応履歴があり、本人以外が復旧を完走した実績がある: この論点で減点する理由はありません。復旧能力が事業側にあることが証明されています
• 手順書はあるが、実際に復旧したのは常に本人だけ: 引き渡し後の初回障害が、そのまま試験になります。サポート期間の長さより、その期間中に買い手側の人間が主導で1件直せるかを条件に組み込む方が、実質的な意味があります
• 復旧が本人の頭の中にしかなく、記録が1件も無い: この場合、買い手が買っているのは事業ではなく、当面のあいだ売り手が対応してくれるという期待です。移管が不可能なわけではありませんが、移管作業そのものを取引の一部として設計する必要があります。価格の議論より先に、そこを決める話です

頭の中にあるものは、まだ資産になっていないだけ

最後に、この論点で一番言っておきたいことを書きます。

売り手の頭の中に入っているものは、無価値ではありません。むしろ、その事業に存在するあらゆる資産の中で、最も価値が高い部類に入ります。何年も、ときには10年以上かけて蓄積された、失敗と復旧の記録の圧縮物です。コードは書き直せます。サーバーは立て直せます。あの判断だけは、同じ年数をかけないと再生産できません。

問題は、それが移せないことです。そして、移せないものには値段が付かない。ここで注意してほしいのは、値段が付かないことと、価値が無いことは、まったく別の話だという点です。査定は「引き継げるもの」にしか値を付けられないという構造的な制約を持っているだけで、その人の能力を評価しているわけではありません。

だからこそ、1人で事業を回してきた人が「属人化している」の一言で片付けられる場面を見るのは、率直に言って気分が悪い。その人は、読者が1人もいない文書を書かなかっただけです。そして、書かなかった時間を全部、事業を生き延びさせることに使った。その判断は、少なくともその時点では完全に正しかった。事業が今日まで残っている事実が、それを証明しています。

ただ、売ると決めた日から、状況は変わります。読者が現れたからです。買い手という、初めての読者が。

そして幸いなことに、その人は書けない代わりに、やれるのです。書けと言われると空っぽの文書しか出てこない人が、実際に障害が起きれば30分で戻せる。ならば、書かせるのをやめて、やっているところを撮ればいい。それだけの話です。内省でたどり着けない場所へ、録画は2秒で連れて行ってくれます。

あなたの30分は本物です。ただ、その30分は今のところ、あなたの中にしかありません。次に何かが壊れた日、直し始める前に、録画ボタンを押してみてください。事業を守ってきたのが本当は何だったのかを、たぶん、あなた自身が一番驚くことになります。