コードリーディングは「信じるアクセル」と「疑うブレーキ」で9割速くなる

---

この記事は カオナビ Advent Calendar 2025 5日目です。

---

こんにちは。

今日はコードを信じるべきか疑うべきなのかについてジュニアエンジニアなりに言語化し開発中に意識していることを記事にしました。

背景

ある日、先輩とのモブプロ中に既存コードの調査をしていると、こう言われました。

「コードは疑いながら読んだほうがいいよ」

しかしその数分後、別の箇所を読んでいると、

「そこはコードを信じて読んだほうがいいよ」

と言われました。

（……結局、疑うのか信じるのかどっちなんだ？）

その時は混乱しましたが、数週間コードと向き合う中で、ある仮説に辿り着きました。

疑うか信じるかの切り替えは、「時と場合」や「勘」といった曖昧なものではなく、
「読む目的」によって明確に使い分ける必要がある説。

結論

コードを信じるか疑うかは、「知る」ことを目的とするか、「書く・検証する」ことを目的とするか、で切り替えるべきというのが自分なりの答えです。

	目的	読み方
信じる	知る（理解・全体像の把握）	命名やファイル構造を信じ、不要な情報の解読をスキップし、最速でコンテキストを掴む。
疑う	書く・レビュー・検証	自分のコード、外部入力、既存ロジックの脆さを疑い、堅牢性と品質を担保する。

コードを信じろ＝コードを知るための技術

「知る」ことを目的としたコードリーディングでは、とにかく認知負荷を下げ、ロジックの全体像を速く掴むことが最優先です。

命名という「道標」を信じる

コードを速く読む人は、コードを「記号の羅列」ではなく「意味のある文章」として読んでいます。これは、変数名や関数名という「開発者が残したメッセージ」をそのまま受け取る（信じる）ことから始まります。

命名を信じるメリット：脳内コンパイルを避ける

例えば、以下のコードのロジックがあったとします。

const canEdit = (user.id === post.authorId) || (user.role === 'ADMIN');

• 命名を信じる人： 変数名が canEdit だから、編集権限のチェックをしているんだな。
  -> コードの意味や役割をすぐに理解できる
• 命名を無視する人： IDの比較、ロールのチェック、論理和……これは何を達成している？
  ->（脳内コンパイルが始まり、？？？になる）

コードの命名を信じることで、実装の流れや意味を容易に理解できます。

ファイル名という「大きな命名」を信じる

この原則は、ファイル構造にも適用できます。
たとえば、コンポーネントディレクトリ内によくある**index.tsx**は、単なる親ファイルではなく「目次（Index）」という命名になります。

index.tsx を目次として読むことで、親ディレクトリということを考えず、脳の認知負荷を下げた状態で、知りたい（読みたい）機能にコードジャンプで直行できるようになります。

「信じる」ことがバグ検知の感度を高める

逆説的ですが、命名を信じる（意図を尊重する）ことは、バグ発見の精度を高めることにも繋がります。
なぜなら、「命名（意図）」と「実装（事実）」のズレこそがバグの正体だからです。

まず命名を信じて「これは〇〇をする処理だ」という正解を作ります。

その前提で実装を見た時、もしロジックが異なっていれば、
「意図と実装が矛盾している」という違和感に即座に気づくことができます。

// 関数名（意図）：成人かどうか判定する
const isAdult = (age: number) => {
  // 実装（事実）：20歳以上判定
  // 違和感：「あれ？法律が変わって18歳になったはずなのに、実装が古いぞ？」
  return age >= 20; 
}

最初から「実装」だけを見て（疑って）いたら、「20以上かどうかの判定か、なるほど」でスルーしてしまうかもしれません。「成人判定である」と信じて読むからこそ、実装の誤りに気づけるのです。

コードを疑え＝書く・レビュー（検証）のための技術

コードを疑うことは、品質と堅牢性を担保するために、徹底的にwhyをもつ必要があります。

（余談） なぜ「コードを疑え」は耳にタコができるほど言われるのか

「コードを疑え」は、特にジュニアエンジニアが陥りやすい3つの過ちを防ぐために、シニアエンジニアは強調して言うのではないかと考えています。

過ち	具体的な行動	疑うべき観点
過信	既存コードやAIの出力を、検証せずにコピペする。	「このコードに副作用はないか？」
盲信	先輩のコメントを、背景を考えずに愚直に実装する。	「この設計の意図は何か？他の選択肢は？」
品質軽視	「動けばOK」と、エッジケースや可読性を無視する。	「このコードは半年後に保守できるか？」

疑うべき対象と具体的な行動

1. 外部からの入力を疑う

• APIレスポンス: TypeScriptの型定義を信じ過ぎず、型定義は嘘をつくかもしれないと疑う
• Props/ユーザー入力: undefined や null が渡される可能性を必ず考慮する

2. 自分の実装と知識を疑う

• 書いたロジックに対し、「正常系で動いているが、異常系（ネットワークエラー、配列が空、権限不足）ではどうなるか？」と問う
• 先輩のアドバイスに対し、「なぜこの設計が良いとされるのか？」と、背景にある設計思想やトレードオフを理解できるまで問い直す

3. 既存の仕組みとテストを疑う

• バグ修正を行う際、「なぜこのバグが発生したのか？ 既存のテストでなぜ検知できなかったのか？」と根本原因を深く掘り下げる
• 「これが数ヶ月後、別のチームメンバーに引き継がれた時、この命名やコメントで伝わるか？」という可読性を疑う

まとめ

「コードを疑え」と「コードを信じろ」。
これらは相反する二元論ではなく、アクセルとブレーキのようにセットで使い分けるべき技術でした。

「知る」ために読む時： 命名という抽象化を信じ、コンテキストを最速で把握する（アクセル）。

「書く・検証する」時： 副作用と不確実性を疑い、堅牢性と品質を担保する（ブレーキ）。

この意識的な切り替えを行うようになってから、コードリーディングの速度と、実装時の品質確認の精度、その両方が向上したと実感しています。

最後まで読んでいただきありがとうございました。