null/undefinedの罠から学んだ、ジュニアエンジニアの多段AIデバッグ術

筆者は営業部門の出身で、開発チームに異動するまで実務のコーディング経験がまったくなかったフロントエンド開発チームの高見氏である。異動からわずか2か月で「CSVダウンロード」という新規機能の実装を任されたという。もちろん手厚いレビュー体制があってこその成長だが、その急速なキャッチアップを支えたのが、AIをコード生成ツールとしてではなく、思考を深める家庭教師として使う勉強法だったと語られている。今回の記事は、あるバグ調査を例に、「限定情報型」と「全体検証型」という2つの役割を使い分ける方法を紹介する。題材はnullとundefinedの扱いという、経験者でも足をすくわれやすい落とし穴である。

AIの鬼として膝を打つのは、AIを答えの自動販売機ではなく、問いを返してくる相手として位置づけ直している点だ。「AIにコードを書かせれば未経験者でも開発できる」という語り方は、半分しか当たっていないと考える。コードを生成させるだけでは、動く物を手に入れた時点で理解が止まる。営業出身の人間が「なぜこの値はnullなのか」と問い続けた先にだけ、コードの読み方が身につく。AIを使うほど頭が空っぽになるのか、逆に鍛えられるのかは、ツールの性能よりも、使う人がどんな問いを立てるかで決まるというのが本音である。

中小企業の現場では、社内の若手や事務担当者にAIでスクリプトを組ませる場面が増えている。そのとき効くのは「書いてもらう」ではなく「なぜこうなるのかを説明させる」という指示の出し方だ。明日から、AIが出したコードに対して「このエラーの原因を3つ挙げて、どれから確かめるべきか」と尋ねるだけでも、理解の深さは変わる。丸投げを減らし、説明を求める。それが属人化を防ぐもっとも手軽な方法である。