現場のコードレビューで、こう聞かれたとします。
「ここ、なんでこのライブラリ使ったんですか?」
で、口から出てきた答えが、これ。
「えっと……AIが提案してくれたので……」
これ、現場で一番信頼を失うパターンなんですよ。
AIで開発するのが当たり前になった今、エンジニアの評価を分けてるのは、コードが書けるかどうかじゃないんです。
AIが書いたコードを、自分の言葉で説明できるかどうか。
今日は、この話を書きます。
AIは悪くないんですよ
先に言っておくと、AIを使うこと自体は何も悪くないです。
CodexとかClaude Codeが出してくるコードって、パッと見きれいなんですよね。
構文は正しいし、動くし、丁寧にコメントまでついてたりする。
で、動くから「まあ大丈夫やろ」って、そのまま出しちゃう。
中身をちゃんと理解しないまま。
問題はここなんです。
AIが書いたことじゃなくて、説明できないまま出してること。
レビューで見られてるのは、コードの正しさじゃない
レビューで先輩やリードエンジニアが質問してくる時って、コードが合ってるかどうかを聞いてるんじゃないんですよ。
見られてるのは、これです。
「この人は、このコードの意図を理解してるのか?」
だから、AIが書いたかどうかは、正直どうでもいい。
出した本人が説明できるかどうか。
ここが全てなんです。
で、説明できないとどうなるか。
「この人は、何も考えずにコードを出す人なんだ」って印象が、一回つく。
そうなると、次から些細な変更でも「これ、本当に理解してます?」って注意深く見られるようになるんですよ。
一回こうなると、めちゃくちゃ効率が悪い。
自分も、相手も。
僕はこれを「理解負債」って呼んでます。
AIに任せて速く書けた分、理解をサボったツケが、後からまとめて来るんです。
直し方は、「なぜ?」を3回聞くだけ
じゃあ、どう防ぐか。
AIが出してきたコードに対して、「なぜ?」を3回聞く。
これだけです。
たとえば、AIがバリデーション処理を書いてきたとします。
1回目。なぜ、この層に入れたのか?
このチェックは入力の形式を見てるだけなのか、ビジネスルールまで入ってるのか。
後者なら、コントローラーじゃなくてサービス層に置くべきものじゃないのか。
2回目。なぜ、このライブラリを選んだのか?
zodを使ってるけど、プロジェクト内でほかのバリデーションライブラリと統一されてるのか。
3回目。なぜ、このエラーハンドリングにしたのか?
例外を投げてるけど、このAPIのクライアント側は、どういうエラーを期待してるのか。
この「なぜ」を3回やるだけで、コードの理解度が全然変わります。
で、大事なのはここです。
この「なぜ」に自分で答えられなかったら、それはまだ理解できてないってこと。
AIに聞き返していいんですよ
「そんなの、答えられないことのほうが多いよ」って思うかもしれないですけど。
答えられなかったら、AI本人に聞き返していいんです。
「なんでこの実装にしたの?」って。
ただ、条件が1個だけあります。
AIの説明を、自分の言葉で言い直せるかどうか。
AIの説明を丸暗記して、レビューでそのまま横流しする。
これはバケツと一緒で、頭を全く使ってないんですよ。
そうじゃなくて、「あ、これってこういうことね」って自分の言葉に変換できたら、それは理解できてるってこと。
ここまでやっておくと、レビューで何を聞かれても答えられます。
だって、自分で理解してるから。
続けると、AIの間違いに自分で気づけるようになる
でね、この「なぜ」の習慣がつくと、面白いことが起きるんですよ。
AIが出してきたコードの中の、おかしい部分に、自分で気づけるようになる。
「ここ、なんでこうしたんだろう?……あれ、これ間違ってるわ」って。
AIって、プロジェクト固有のルールとかチームの慣習とか、そういう文脈を完全には理解してないので、それを無視した実装を出してくることが結構あるんですよね。
そのズレに気づけるかどうか。
これがAI時代のコード理解力の本質だと、僕は思ってます。
鍛え方は3つ
じゃあ、この力をどう鍛えるか。
3つだけ書きます。
1つ目。AIのコードを、必ず一度読む。
当たり前に聞こえるかもしれないですけど、意外とみんなやってないんですよ。
動いたからそのままコミット、が一番危ない。
最低限、差分を1行ずつ見て、「この行は何をしてるのか」を頭の中で日本語に翻訳する。
これだけでかなり変わります。
2つ目。レビューで聞かれる前に、自分で自分に聞く。
プルリクを出す前に、「もしここを聞かれたら、なんて答える?」って自分でシミュレーションするんです。
答えられない箇所が、たぶん出てきます。
それがまさに、理解できてない箇所です。
そこを埋めてから出す。
これだけでレビューの質が全然変わるし、コードの全体像も見えてくるので、自分のレベルアップに直結します。
3つ目。データの流れを追う。
ユーザーがボタンを押す。
APIにリクエストが飛ぶ。
バックエンドで処理が走る。
データベースに保存される。
レスポンスが返る。
この流れを、AIが書いたコードに対しても、自分でトレースするんです。
AIのコードって、部分的に見るときれいなんですけど、全体として見ると不自然なところが結構あるんですよ。
「ここでデータ取ってるけど、この先の処理で使われてないぞ?」とか。
「このエラー、ここでキャッチしてるのに呼び出し元でもキャッチしてて、二重になってるぞ」とか。
こういうのは1箇所だけ見てても気づけないんです。
データの流れを追って、全体を見るから気づける。
まとめると、たった1個なんですよ
で、この3つ、まとめると1個になります。
AIのコードを、他人のコードだと思って読む。
先輩のコードをレビューする時って、「なんでこうしたんだろう?」って自然に考えますよね。
AIのコードも、同じです。
AIを自分の手の延長じゃなくて、チームメンバーの1人として扱う。
この感覚でいると、放っておいても理解が深まっていきます。
コードが書ける人は増える。説明できる人は、増えない
最後に、これだけ言わせてください。
「なぜそうなってるのか?」を考えられる力って、AIのコードに限った話じゃないんですよ。
先輩が書いたコード。
OSSのコード。
ドキュメントには書いてないけど、現場では当たり前になってるルール。
こういうものに「なぜ?」を立てられる力は、僕が現場で見てきた中で、単価が高いエンジニアに共通してる能力です。
コードが書ける人は、たくさんいます。
AIのおかげで、これからもっと増えます。
でも、「なぜこのコードなのか」を説明できる人は、実はそんなに多くない。
ここに気づけるかどうかで、これからのキャリアはかなり変わってくると思いますよ。
コードの読み方と現場での立ち回りは、無料メルマガで深掘りしてます
こういう話、僕の無料メルマガで書いてます。
今日の話は「なぜを3回聞く」の枠組みだけ。
コードの読み方そのものとか、現場でどう立ち回れば「この人は理解してる」って信頼が積み上がっていくのかは、メルマガで深掘りしてます。
「レビューで聞かれるのが怖い状態を、終わらせたい」
「AIのコードを、ちゃんと読める側になりたい」
「AI時代に、信頼されて単価が上がる側にいきたい」
って人だけ、下から登録しといてください。
ほな、また。
コメント