AIで実装が爆速になったら、「仕様決定待ち」のタスクばかり増えてきた
最近、仕事をしていて妙なことに気づいた。
「仕様決定待ち」のタスクが増えてきた。
以前から仕様待ちはあった。客先に確認を投げて、「回答待ち」のまま数日止まる。IT業界では珍しくもない光景だ。
ただ、最近はその比率が明らかに高くなった。
原因を考えてみると、AIだった。
AIを本格的に開発へ使うようになって、実装がとにかく速くなった。以前なら半日かかっていた修正が短時間で終わる。テストコードも書かせ、そのまま実行して、失敗すれば原因を調べて直すところまでAIがやる。
こちらとしては非常にありがたい。
ところが、実装が速くなればプロジェクト全体も同じ割合で速くなるかというと、そうはならない。
AIが猛烈な勢いでタスクを片付けた結果、最後に残ったのが、
「で、これはどういう仕様にするんですか?」
という、人間側の問題だった。
コードは速く書けても、仕様は勝手に決められない
たとえば、ある機能について二つの実装方法が考えられるとする。
技術的にはどちらでも実装できる。
昔なら、まず一方を作るだけでも時間がかかった。設計して、コードを書いて、テストして、不具合を直す。その間に客先との仕様調整も進んでいたので、実装と意思決定の遅さが混ざっていた。
ところがAIを使うと、このバランスが崩れる。
「A案ならできます」
「B案でもできます」
「どちらにしますか?」
ここまで到達するのが異常に速い。
そしてAIもエンジニアも止まる。
客が決めるまで、やることがない。
高性能なエンジンを積んだ車を用意したところで、右へ行くのか左へ行くのか決まっていなければ走れない。
AIはアクセルを強烈にした。
しかし、ハンドルを握っているのは相変わらず人間である。
自社サービスなら、まだ速くできる
ここは自社サービスと受託開発でかなり事情が違う。
自社サービスなら、意思決定する人間が比較的近くにいる。
「この画面、こうした方がよくない?」
「じゃあ、それでやってみよう」
これで進められる。
AIに実装させて、その日のうちに動かしてみる。ダメなら戻す。別案を作る。
実装コストが下がったことで、「とりあえず作って試す」という選択肢が現実的になった。
問題は受託開発である。
客先にボールが渡った瞬間、AIは無力になる
受託開発では、開発側だけで仕様を決められない。
「この場合はAとB、どちらの動作にしますか?」
と確認する。
ここからが長い。
担当者だけでは決められない。
上司に確認する。
関連部署にも確認する。
場合によっては、そのシステムを実際に使う別部署やエンドユーザーにも話を通す。
会議が開かれる。
Aがいいという人がいる。
Bがいいという人がいる。
「そもそも前提から見直した方がいいのでは」という人まで出てくる。
そして数日後、
「社内で引き続き検討します」
となる。
この間、AIがどれだけ賢くなっても何もできない。
Claudeが次世代モデルになろうが、ChatGPTがさらに賢くなろうが、客先の会議を勝手に終わらせて仕様を決定することはできない。
コードを書く速度は何倍にもなったのに、人間同士が合意する速度は昔のままなのだ。
実は昔から何も変わっていない
考えてみれば、「仕様が決まらないから開発が止まる」という話自体は何十年も前からある。
ウォーターフォールの時代にもあった。
アジャイルになってもあった。
クラウドになってもあった。
そして生成AIが登場しても残った。
ソフトウェア開発の難しさは、プログラミングだけではない。
「何を作るのか」
「この場合はどう動くべきなのか」
「誰の要求を優先するのか」
「問題が起きたとき誰が責任を持つのか」
こうしたことを人間が決めなければならない。
AIによってコードを書く部分だけが猛烈に高速化された結果、むしろ昔から存在していた問題がはっきり見えるようになった。
以前は、実装にも時間がかかっていたので、仕様決定の遅さだけが目立つことはなかった。
高速道路全体が渋滞していれば、どこが本当のボトルネックなのかは分かりにくい。
ところがAIによって実装部分だけが突然10車線になり、猛スピードで車が流れるようになった。すると、その先に昔からあった一つの料金所に車が全部詰まり始めた。
その料金所が「仕様決定」である。
料金所が以前より遅くなったわけではない。そこへ到達するまでが速くなりすぎた結果、昔からあったボトルネックが露出しただけなのだ。
だったらAIを「仕様を決めるため」に使えばいい
ただ、ここで「客が決めてくれないから仕方ない」で止まるのも面白くない。
AIによって実装が安くなったのなら、その力を仕様決定にも使える。
たとえば、文章だけで、
「A案では、このボタンを押すと確認画面へ遷移します」
「B案では、そのまま処理を実行します」
と説明しても、なかなか話は進まない。
だったら両方作ってしまえばいい。
以前なら「比較のためだけに二つ実装するなんて工数の無駄です」と言われた。
今ならAIに作らせればいい。
A案とB案の簡単なモックを用意して、
「実際に触ってみてください。どちらにしますか?」
と聞く。
人間は、存在しないものについて議論するのが苦手だ。
文章だけで画面や挙動を想像し、関係者全員が同じものを頭に描いて議論するのは難しい。
ところが目の前に動くものがあれば話は変わる。
「こっちの方が分かりやすい」
「いや、この操作だと現場では困る」
「だったらここだけ変えよう」
急に議論が具体的になる。
AIの高速実装は、単にエンジニアが楽をするためのものではない。
人間に決断させるための道具にもなる。
AI時代に価値が下がる仕事、上がる仕事
こう考えると、AI時代にエンジニアの価値がどこへ移るのかも見えてくる。
仕様書に書いてある内容を、そのままコードへ変換する能力の価値は下がる。
そこはAIが猛烈な速度で追いついてきている。
一方で、
「この要求だと、ここが決まっていません」
「この二つの仕様は矛盾しています」
「文章で議論しても決まらないので、両方モックを作りました」
「実際に触って決めましょう」
と動ける能力の価値は上がる。
つまり、コードを書く能力よりも、曖昧な話を具体的な形にして、人間に決断させる能力の比重が大きくなる。
これは少し皮肉でもある。
AIが進化すれば、IT開発はもっと機械的になり、人間臭い部分が減っていくと思っていた。
実際には逆だった。
コードを書くという機械的な部分から先にAIが片付けてしまった。
その結果、最後まで残ったのは、客に確認し、関係者の意見を整理し、曖昧な要求を具体化し、実際に動くものを見せながら意思決定を前へ進めるという泥臭い仕事だった。
最近、「仕様決定待ち」のタスクが増えたように見えたのも、仕様決定が以前より遅くなったからではない。
その手前にあった仕事をAIが爆速で片付けてしまったので、昔からそこにあった渋滞が丸見えになっただけなのだ。
……と、ここまで書いて気づいた
ここまで長々と書いてから気づいた。
これ、最近AI業界でよく聞く**FDE(Forward Deployed Engineer)**の話ではないか。
顧客の現場に入り込み、曖昧な要求を拾い上げ、AIを使って素早く形にし、実物を見せながら顧客と一緒に仕様を詰めていく。
私はここまで長々と「これからのエンジニアはこうなるのではないか」と書いてきた。
もう名前まで付いていた。
AIの進化が速いという話を書いていたら、世の中のほうが私より先に進んでいた。