ルームメイト問題から学ぶ、コードレビューの信頼設計

Frankee Groveという女性の話を読んだ。2025年1月、彼女はロサンゼルスの山火事が燃え広がる中、月5,100ドルの家賃を一人で払えなくなり、Facebookでルームメイトを探した。見つけたのはSabrina Mollisonというフィットネスインフルエンサー。インスタのリールは小綺麗で、DM越しの印象も悪くなかった。でも実際に住み始めてから、状況は最悪な方向に転がっていった。

これを読みながら、自分はずっとコードレビューのことを考えていた。

「見える範囲」だけで人を信頼するリスク

GroveはSabrinaのSNSプロフィールとFaceTime越しの会話だけで判断した。それ以上の情報源がなかった。自分たちのコードレビューも、似たような構造になってないか、と思う。PRのdiffだけ見て「LGTMっす」って承認する流れ、チームに絶対ある。

でもdiffは「変更された部分」しか見せない。そのコードが呼ばれるコンテキスト、過去の負債、設計上の前提——そういうものはdiffに出てこない。SNSのフィードと同じで、見えているのはハイライトだけだ。

自分が最近意識しているのは、PRの説明欄に「なぜこう書いたか」と「他の選択肢として何を検討して捨てたか」を必ず書くこと。レビュアーにdiff以上の文脈を渡すためだ。これをやるだけで、レビューのコメント質がわかりやすく変わった。

「すぐ入居できます」は警戒サインかもしれない

Sabrinaは「いつでも移れる」と言った。GroveはJanuary 24に入居してほしかったので、それが好都合に見えた。でもそのスピード感は、後から振り返れば警戒すべきサインだった可能性がある。

ライブラリ選定でも同じ罠がある。「導入が簡単」「すぐ動く」は確かに魅力的だ。でも自分がここ最近で痛い目を見たのは、LLMのAPIラッパー系ライブラリをサクッと入れた後、内部の抽象化が厚すぎてエラーハンドリングを自前で書けなかったケースだ。

「Trust the process」というキャプションをSabrinaはよく投稿していたらしい。でもプロセスを信頼するためには、そのプロセスが実際にどう動くか理解していないといけない。ブラックボックスの上に乗っかることと、信頼することは別物だ。

問題が見えてから動くと、コストが跳ね上がる

Groveは問題が起きてから、監視カメラの設置、警察への相談、退去法の調査——と対処を重ねていった。後手に回った分、消耗した。

これはシステム設計でも本当によくある。モニタリングを後付けで入れる、ロギングは問題が起きてから整備する、認証まわりのリファクタは「あとでやる」になる。問題が顕在化してからの修正コストは、最初から設計に組み込んだ場合の何倍にもなる。

自分は最近、新しいコンポーネントを書くときに「これが壊れたらどうやって気づくか」を先に決める習慣をつけ始めた。ログの設計とアラートの閾値を先に考えてから実装に入る。Groveが最初から入居審査のプロセスを厳しくしていたら、みたいな話と同じだと思っている。

コードもルームメイトも、「なんとかなるだろう」で始めると、なんとかならないときの撤退コストがえぐいことになる。この話から言えることは、入り口の設計をケチると、出口で全部回収されるってことだと思う。