AIにコードを書かせる時代でも、エンジニアに一番必要なことは変わってなかった

この記事でわかること

• AIがコードを書く時代の「新しい遅延」の正体
• 「コードを書く前に話を聞く」習慣がなぜ重要か
• 15分の確認が2週間の後始末を防ぐ具体例

コードを書くスピードだけが上がった

agentic codingを始めてから、コードを書くスピードは間違いなく上がった。AIに指示を出せば、以前なら30分かかっていたコンポーネントが5分で出てくる。これでもう大丈夫かと思った。

だが実際は、コードが速く出てくるぶん、それをどこにどう組み込むかの判断が追いつかなくなった。業務の流れを理解しないままコードだけ量産しても、あとで手戻りが増えるだけだと気づいた。

5分で書いたコードの後始末に2週間かかった

先週の話。顧客から「ダッシュボードに絞り込み機能が欲しい」と要望が来た。営業の課長が言うので、要望としては正当だ。Claudeに投げたら、15分で動くプロトタイプが出てきた。気持ちよかった。

翌日の朝、課長に見せたら「ああ、これですね」と言われた。が、現場の人が使う段になって、誰も開かない。サポートに問い合わせが来た。「この画面、どう使えばいいんですか」。使い方がわからない。そもそも、現場の人はExcelで管理しているので、画面を開く習慣自体がなかった。

気づいたのは2週間後だった。絞り込み機能を作る前に、15分かけて現場の人に話を聞いていたら、必要だったのは「ExcelからCSVインポートするボタン一個」だったかもしれない。2週間の後始末を、15分で防げた。

業務フローを理解しないまま書くと、どう壊れるか

自分がやっている「聞かない」癖

実は自分、聞かない癖がある。学生時代から「まず調べて、わからなかったら人に聞く」というのが信条だった。それが今では「まずAIに投げて、動かなかったら人に聞く」になっている。AIが答えてくれるから、人に聞く前にコードが出来上がってしまう。

これが悪循環だ。コードが先に出てくるから、要件の確認が後回しになる。要件の確認が後回しになるから、作ってから「あ、違った」になる。

あの絞り込み機能の件で、自分は鉄則を一つ作った。AIに何かを書かせる前に、必ず「この機能を使う人の名前」を書き出す。名前が出なければ、その機能は作らない。名前が出れば、その人に話を聞く。15分かけて聞くのがだるいのはわかる。でも2週間の後始末より、だるくない。

結局、エンジニアとして大事なことは変わってなかった。何を作るべきか理解し、周りと息を合わせ、一人で抱え込まない。AIがどんなに速くなっても、この三つが抜けるとどこかで詰む。むしろ昔よりシビアになった気がする。

自分の立ち位置を外から検証する手段としてカンファレンスにプロポーザルを出すのも一つの手だ。自分のやってきたことが市場でどう評価されるか、プロポーザルは正直な鏡になる。コードを書く速度より、責任を取れる状態を維持することがエンジニアの新しい価値になっていく。