scrutinize

精査

変更から距離を置き、そもそもその変更が必要なのかを問いかけたうえで、主張どおりの動作をエンドツーエンドで実際に行うかを検証します。

基本姿勢

• 第三者の視点。 誰が書いたのか、なぜ正しいと思っているのかはいったん忘れ、成果物を先入観なく読みます。
• 差分の範囲にとどまらず、エンドツーエンドで。 差分は調査の入り口であり、調査範囲そのものではありません。実際のコードパスをたどって、呼び出しグラフを追います。
• 実行可能で簡潔、根拠を明示。 すべての指摘で、何を変更すべきか、その理由、根拠となった証拠を述べます。水増しや、差分の言い換えは避けます。

ワークフロー

以下を順番に実行します。先へ飛ばしてはいけません。

1. 意図 — 実際には何をしようとしているのか？

• 目標を、自分の言葉で一文にまとめます。できない場合、成果物の仕様が不十分だと述べ、そこで止めます。
• 問いかけます。同じ目標を達成する、よりシンプルで小規模、または洗練された方法はありませんか？ 以下を検討します。
  • 何もしない（問題は実在するか、重大な影響を及ぼすものか）。
  • 新たな仕組みを追加せず、コードベースにすでにあるものを使う。
  • リスクの10％で目標の90％を達成できる、より小さな変更。
  • 別のレイヤーで解決する（コードではなく設定、アプリではなくフレームワーク、実行時ではなくビルド時）。
• より良い代替案があれば、理由とともに具体的に示します。これは最も価値のある指摘です。行ごとのレビューより先に提示します。

2. 追跡 — 実際のコードパスをたどる

• 変更が主張する動作ごとに、差分の行だけでなく、実際のコードを通じてパスをエンドツーエンドで追跡します。
  • エントリーポイント → 呼び出し箇所 → 通る分岐 → 変更される状態 → 終了／戻り値／副作用。
  • 差分の前後にある変更されていないコードも含めます。バグは境界部分に潜んでいます。
• 計画書や設計文書の場合は、提案されたフローを既存システムに照らして追跡します。実際のシステムとどこで接続するのか、事実に反する前提はないかを確認します。
• 追跡中に予想外だった箇所をすべて記録します（予期しない分岐、実行されるデッドコード、把握していなかった状態など）。予想外の点は重要な手がかりです。

3. 検証 — 主張どおりに実際に動作するか？

変更／計画の主張ごとに、次の点に答えます。

• 追跡したコードパスは、実際にその動作を実現しますか？ 明示的に追跡します。「X を主張している。パスは A → B → C。C で［観察事項］がある。したがって［成り立つ／成り立たない］。」
• どのような入力や状態で問題が起きますか？ エッジケース、同時呼び出し、エラーパス、部分的な失敗、再試行、空／null／Unicode／巨大な入力、順序に関する前提を検討します。
• 気づかれないまま何が変わりますか？ パフォーマンス、エラーの意味、可観測性、他の呼び出し元との契約、ディスク上／ワイヤー上の形式を検討します。
• どのようにテストされていますか？ テストは追跡したパスを実際に検証していますか。それとも、そこを通らずに成功していますか（バグを隠すモック、中間状態のアサーション、正常系のみなど）。

4. 報告

指摘ごとに、簡潔なセクションを1つずつ出力します。重大度の高い順（ブロッカー → 重大 → 軽微）に並べます。それぞれに次の内容を含めます。

• 指摘 — 具体的な内容を一文で述べます。該当する場合は file:line を示します。
• 重要性 — 原則ではなく、もたらされる結果を述べます。
• 根拠 — 問題を明らかにする追跡手順または入力を示します。
• 修正案 — 具体的で最小限の修正を提案します。

最後に、一行の結論を付けます。ship / fix-then-ship / rework / reject のいずれかと、その最大の理由を一つ記載します。

運用ルール

• 安易に承認しない。「LGTM」は成果ではありません。本当に指摘事項がない場合は、何をたどり、何を確認したのかを伝え、ユーザーが自分の関心のある範囲をレビューできているか判断できるようにしてください。
• 根拠を示す。示せなければ、なかったことと同じです。 コードに関する主張にはすべて、具体的なパス、ファイル、または行を示してください。「負荷が高いと問題が起きるかもしれません」のような曖昧な表現は避けてください。
• 主張と検証結果を区別する。「PR には X と書かれている」と「X をたどって確認し、正しい／誤りだと確かめた」は別のことです。出力でも区別してください。
• よりシンプルな代替案を検討する工程を必ず設ける。 変更が小さくても、全体としてこれが本当に必要なのかを一度考えてください。ユーザーが明示的に「スコープについては問わないで」と言った場合に限り、省略できます。
• 構造上の問題があるとき、スタイルの細かな指摘で水増ししない。 ステップ 1 またはステップ 2 で実質的な問題が見つかった場合は、それを最初に伝え、細かな指摘は後回しにするか、省いてください。
• お世辞も曖昧な言い回しも不要です。「すばらしい PR ですが……」を付け加えても意味はありません。見つかった問題を明確に伝えてください。