「伝えればすむ」という誤解 — バグ対応でPdMとエンジニアがすれ違う理由
まとめ
- 既知の軽微なバグを抱えたままリリースするか、という判断で、PdMとエンジニアは根本的にすれ違う。
- エンジニアは「顧客に伝えればすむ」と考えがちだが、それは判断を顧客に丸投げしているだけで、返ってくる答えは「直してから出して」に決まっている。
- PdMは基幹ドメインを「確率に関わらず越えてはいけない一線」として見ている。エンジニアはその一線の高さが見えず、発生確率で語ってしまう。
- 事後に「リスク管理はできていた、結果オーライ」と総括できてしまうこと自体が、エンジニアが最後まで一線を見ていない証拠になる。
きっかけ
あるリリース計画のふりかえりを観測していて、バグ対応の判断基準をめぐるPdMとエンジニアの温度差がきれいに出ている場面に出くわした。題材は「事業の根幹をなす基幹機能（契約処理のようなもの）に、既知の軽微なバグがある状態でリリースしてよいか」という話だ。せっかくなので、そこで見えた非対称を整理しておく。
なお登場人物・製品名は伏せ、構造だけを取り出している。
起きたこと
時系列にすると、こういう出来事だった。
- 基幹機能に、特定の操作をするとエラーになるバグがあった。
- 別件の調査中に、前日の夜たまたま見つかった。
- 実ユーザーへの実害は出ない軽微なバグと判断された。発生すること自体は分かっていた。
- 顧客に伝えれば「直してからリリースして」と言われるのが分かっていたので、伏せてリリースした。
- ところが顧客側が検証中にたまたま見つけてしまい、エラーが表面化した。
- 翌朝、緊急リリースで対応して収束した。
結果としては大きな事故にはならなかった。だからこそ、判断の善し悪しが曖昧なまま流れてしまう。
「伝えればすむ」という誤解
エンジニア側の発想には「事前に伝えておけば緊急事態にならなかったのに」という後悔がにじむ。ここに落とし穴がある。
伝えるという行為を、エンジニアは「事実を1つ共有するだけ」だと捉えている。でも実際には、伝えた瞬間に「出す/止める」の判断を相手に握らせている。しかも相手が基幹機能のバグに対して返す答えは決まっている。「直してから出して」だ。
つまり伝えることは問題の解決ではない。判断を顧客に預けているだけで、預けた先の答えは最初から見えている。だから伏せたわけで、その意味では伏せた判断のほうが筋が通っている。「伝えればすむ」は、伝えた先で何が起きるかを想像できていないから出てくる発想だと思う。
ここまでは、エンジニアの中でも経験のある人なら気づける。伝えても止められて終わる、という実務的な観察はできる。
確率の言語と、一線の言語
問題はその先だ。「なぜ顧客は必ず止めると言うのか」を、どこまで理解しているか。
PdMや事業側の人間にとって、基幹ドメインが正しく動かないことは、顧客がどう受け取るか以前の問題だ。そこは事業の根っこで、壊れてよい場所ではない。だから「そのバグが顕在化する確率が高いか低いか」は論点にすらならない。低かろうが、越えてはいけない一線がある、という感覚で見ている。
一方エンジニアは、この一線の高さが見えていない。だから「ほぼ出ないから」「クリティカルじゃないし」と、発生確率で語ってしまう。確率で最適化しようとしている対象を、相手は絶対禁止の領域として扱っている。同じ土俵に乗っていないから、議論が噛み合わない。
これは能力の話ではなくて、見ているものが違うという話だ。エンジニアは機能をリスクの集合として見て、期待値で管理しようとする。事業側はドメインを、守るべき一線として見る。低い確率をいくら積み上げても、超えてはいけないラインの内側には入れない。
事後評価が、いちばんの証拠になる
この件でいちばん引っかかったのは、事後のふりかえりだ。
技術側の総括は「リスク管理はできていた」「想定していたリスク以上のものは出なかった」「結果オーライだった」というものだった。「こういう判断はしたくない」と後味の悪さは口にしていたが、それは手触りの問題であって、評価の枠組みそのものは最後まで「軽微・実害なし・確率が低い」というリスク管理の言語で閉じていた。
事前に伏せた判断も、事後の「結果オーライ」という評価も、どちらも「発生確率が低い軽微なバグ」という同じ前提の上に乗っている。つまり事前も事後も一貫して確率で語っていて、一線の言語には一度も切り替わっていない。後になってさえ「基幹が壊れる時点で確率に関わらずアウトだった」とは考えていない。
だから、事後に「結果オーライ」と総括できてしまうこと自体が、エンジニアが最後まで一線を見ていなかったことの証拠になる。見えていれば、確率がどうであれ「あれは出してはいけなかった」という評価になるはずだ。
どうすればよかったのか
犯人探しをしたい話ではない。構造の問題だと思う。
PdMや事業側が持っている「ここは確率に関わらず守る一線だ」という感覚が、暗黙知のままエンジニアに渡っていない。言語化されて共有されていないから、エンジニアは確率で最適化してしまうし、それを止める基準が現場に無い。
だとすると打ち手は2つだ。ひとつは「誰が最終的に出す/止めるを決めるのか」を曖昧にしないこと。この件では、開発チームの見解のままリリースが進み、責任者が曖昧なまま流れていた。もうひとつ、そしてより本質的なのは「どのドメイン・どの機能は、確率に関わらず一線として扱うのか」を先に定義しておくことだ。ここを言葉にしておかないと、確率の言語と一線の言語は次もまたすれ違う。
「伝えればすむ」の背後には、一線が見えていないという、もっと根の深い非対称がある。伝え方を工夫する前に、まず何が一線なのかを共有する。順番はそっちが先だと思う。