変わったのは「最初の一歩」の速さ
AIコーディングでもっとも大きく変わったのは、ゼロから動くものが立ち上がるまでの時間です。以前なら要件定義から設計、初期実装まで数ヶ月かかっていた工程が、数時間から数日で形になります。
この差が効くのは、スピードそのものよりも「早い段階で実物を見ながら議論できる」ことです。文字だけの仕様書で合意したつもりでも、実際に画面を見ると認識が違っていた。こうした手戻りが、実物を先に出すことで大幅に減ります。
変わっていないのは「何を作るか」を決める仕事
一方で、変わっていない部分もはっきりしています。
- 現場の業務を聞き出し、どこが本当のボトルネックかを見極めること
- 例外処理をどう扱うか決めること
- AIに任せる範囲と、人が判断する範囲を線引きすること
- 既存システムとの連携方式を選ぶこと
これらは要件が曖昧なまま指示を出しても、曖昧な答えしか返ってきません。AIは「何を作るか」が決まっていれば速いのですが、「何を作るべきか」は決めてくれません。
AIの提案を鵜呑みにできない理由
AIは数学的に効率のよい構造を提案します。データの持ち方も、画面の構成も、理屈としては正しい。ただし、それが実際に使う人に合うとは限りません。
たとえば、入力項目を減らして効率化した画面が、現場では「確認のために結局別の資料を開くことになった」ということがあります。理屈の上での効率と、手を動かす人の効率は一致しないことがある。ここを埋めるのは、いまのところ人の仕事です。
もうひとつの変化 ― 作り直しのコストが下がった
従来のシステム開発でいちばん厄介だったのは、改修のたびに構造が複雑になっていくことでした。継ぎ足しの改修を重ねた結果、小さな変更にも大きな費用がかかるようになる。
AIによる生成が前提になると、この前提が変わります。仕様変更があったときに継ぎ足すのではなく、変更後の仕様でもう一度ゼロから生成し直せるためです。結果として、システムはいつも整合の取れた状態に保たれます。
「作り直しは高くつく」という常識が崩れたことは、スピード以上に大きな変化かもしれません。
これから重要になるスキル
コードを書く速さの価値は相対的に下がりました。代わりに価値が上がったのは次のような力です。
- 業務を聞き出して、要件として言語化する力
- AIが出した設計を読み、妥当かどうか判断する力
- セキュリティと運用を最初の設計に織り込む力
- 実際に使う人の動線を想像する力
どれも従来のエンジニアリングの延長線上にありますが、比重が変わりました。
まとめ
AIコーディングが変えたのは、初期構築の速さと、作り直しのコストです。変えていないのは、何を作るべきかを決める仕事と、使う人に合わせて調整する仕事。この2つが残っている限り、開発は人とAIの共同作業であり続けます。