知らない機能に迷子にならない調査術 ー AIがコードを書く今、調査力は人間の武器になる

こんにちは、しがないエンジニアの k_y16 です。

はじめに

入社したばかりや大きなサービスに関わると、「触ったことない機能を調べて」と言われることがよくあります。
正直ビビりますよね。でも大事なのは知識量やカンではなく、順序を飛ばさず事実を積み上げることです。

焦っていると、とりあえずDBを直接開いたり、関連しそうなコードを片っ端から読んでしまったりしがちです。あるいは社内のドキュメントや古いWikiを参考にするけれど、今はもう違う仕様で「全然関係なかった…」ということも多い。
そんな時こそ「順序を守る」ことが一番の近道になります。

---

1. 仮説を無理に立てない

知らない領域では「たぶんこうだろう」と考えても外れることが多いです。
古い仕様や謎ルールが残っていて、経験則が役に立たないこともしばしば。

だから最初は仮説より事実。
事実を並べるだけで報告になるし、後から仮説を立てる方が正確です。

---

2. 順序を飛ばさない

調査は「クライアント → サーバー → データ」の順番で追うのが鉄則です。

• クライアント：ユーザーがどんな操作をしたかを観察する
• サーバー：その操作でどの処理が呼ばれたか、入口から順にコードを追う
• データ：最後に、状態がどう変わったかを確認する

たとえばユーザーがボタンを押したとき、まずは画面側からどのAPIが呼ばれているかを確認します（クライアント）。
次に、そのAPIをGUIツールやcURLなどで再現し、レスポンスを実際に見ます（サーバーの入口を確認）。
※ただし、POST や PUT などデータを変更するリクエストは不用意に叩かないこと。ステージング環境で確認するか、コードやログを読む形で事実を押さえるのが安全です。

そこからコードを ルーティング → コントローラー → ユースケース（サービス） という順に追い、どの条件分岐を通って結果が返っているのかを一歩ずつ辿ります。
最後に、その処理で参照・更新されるテーブルやフラグをチェックし、状態がどう変化しているかを確認します（データ）。

このように「呼ばれるAPI → 実際のレスポンス → コードの経路 → データの変化」と段階を飛ばさずに進めると、仮に途中で迷っても「どこまで把握できているか」がはっきりし、報告しやすくなります。

---

3. 良い事実とは？

良い事実には3つ条件があります。

• 再現できる：誰がやっても同じ結果になる
• 裏付けがある：コードや状態の変化で根拠を示せる
• 条件が明確：どのユーザーで、どの環境で、いつやったのか

逆に「たぶんキャッシュだと思う」みたいな推測は事実ではありません。
特に調査初期は「推測禁止」を合言葉にするくらいがちょうどいいです。

---

4. ありがちな迷子パターン

• いきなりコードの奥から読み始めて迷子になる
• 「昔はこうだったらしい」に引っ張られる
• 条件を書かずに「動きません」とだけ報告する

全部、順序と事実を押さえれば回避できます。
逆に言えば、順序を飛ばすと必ず迷子になるということです。

---

5. 報告は事実だけで十分

「再現手順」「観察した結果」「どこまで追えたか」を揃えて報告すれば、仮説ゼロでも価値があります。
先輩や詳しい人が「じゃあ次はここを見よう」と導いてくれるからです。

報告の基本は「誰でも追試できること」。自分だけのメモではなく、チーム全員が同じ状況を再現できる形で残すのが理想です。

---

6. AI時代だからこそ調査力

AIはコーディングを代替してくれます。コードを書くスピード勝負では人間は勝てません。
だからこそ調査力が武器になります。

もちろん調査にもAIは使えます。コードの流れを要約させたり、知らないドメインの全体像を整理させたり。ただし順序を飛ばすような使い方をすると、証拠抜きで謎の結論に飛びついてしまう危険もあります。

実際、「この関数はここから呼ばれてるはず」とAIが答えてくれたのに、調べてみたら別の経路から呼ばれていた、なんてことはよくあります。
AIの提案は便利ですが、それを事実で裏付けるのが人間の役目です。

AIはあくまで補助輪。ハンドルを握るのは自分自身です。

---

まとめ

未知のドメインに挑むときに必要なのは勇気ではなく手順。
仮説を無理に立てず、クライアント → サーバー → データの順で事実を積み上げていけば、必ず前に進めます。

AIが助けてくれる時代だからこそ、人間は焦らず、順番通りに“コードを追う力”を磨きましょう。