488.生成AIと人月単価
初回：2026/9/16
生成AIで、コーディングを行ても、全体ではそれほどの効率アップにはなっていない...という話ではありません。
P子「じゃあ、どういう話なの？」※1
生成AIを使うと、爆速でシステムが出来上がると思っている素人さんが、システム開発費用を値切ろうと画策してくるんじゃないかというお話です。
P子「素人さんって、お客様の事？」
お客様もですが、他社と競合している営業さんとか、よくわからないまま、生成AIは神だと信じている上司とか...なんて思っていても言いません。
P子「ほぼ、言ってるのと同じよ」
1.コーディング比率
まず、今回のお話は、エビデンスなしの私の勝手な憶測に基づくお話です。なので、現状と違うとか、自社には合わないとかあるかもしれませんが、ご容赦ください。
前提となるのは、新規スクラッチ開発や、パッケージのカスタマイズなど、開発(コーディング)作業が含まれるケースについてです。
いずれのケースでも、設計(要件定義や仕様作成など)、開発(コーディング)、テストのフェーズがあるとします。個人的には、すれぞれが、30％づつの比率と考えています。
P子「100％にならないわよ」
残りの 10％は、ぐだぐだになった場合の予備工数です。
P子「色々な横やりとか、しがらみとか、政治的な調整とか...」
とりあえずそのあたりは、設計フェーズが 40％ としても良いです。あくまで、おおざっぱに言うと、開発(コーディング)工数は、全体の 1/3 程度という事で話を進めたいと思います。
2.生成AIで、コーディング工数は減るのか？
さて、生成AIに、設計(要件定義や仕様作成など)情報を『何も加工せずに』食わせてコーディングが完成するなら、30％ の工数削減が可能かもしれませんが、実際は開発のための環境構築とか生成AIに指示を与えるためのプロンプトの作成とか、成果物との齟齬を考慮して何度か生成しなおすとか、色々な工数が取られるので、実質的にはそれほど工数削減にはならないと思います。
さらに、生成AIで作成したコードの確認とか、テスト工数が通常開発より多めにとる必要があるとか、色々とあると思います。そうやって考えると、生成AIを使ったからと言って、全体工数は、ほとんど削減されません。... というのが私の持っているイメージです。
P子「まあ、今までと同じ開発方法では...という事でしょ」
生成AIを使用することを前提にした開発手法を用いれば、工数削減は可能かもしれませんが、そうなると生成AIの使用料が増えて、結局顧客が支払う金額は同じで、自社の取り分のいくらかが、生成AI事業者に流れるという構図になるのかもしれません。
さて、ここまで言えばわかると思いますが、個別に開発する場合には、生成AIの効果はそれほど期待できないのではないかという事です。
P子「一応、あなたの憶測でのお話でしょ」
まあ、そうなんですけどね。
さて、問題はここからで、生成AIを利用した開発でも、工数はそれほど削減できないのに、顧客や営業は、工数削減できてるだろうから、人月工数が減るので開発費用は減らせるのではないかと主張してくることが考えられます。
その場合どうすればよいのか？ というのが今回のお話の趣旨です。
P子「ここまで来るのが長かったわね」
3.人月単価から費用対効果での見積もりへ
開発側からすれば、人月工数で見積もると、生成AIを使ってるんだから、もっと安くできるだろうと要求されます。実質はそんなことはないのに。では、今まで通りの費用を請求するには、人月単価をそのままで、開発工数の代わりに何らかの工数を上積みするか、人月単価を上げてもらうしかないでしょう。
P子「人月単価を上げても、納期短縮の要求が来るかもね」
そうなると、人海戦術を取らざるを得ないでしょう。でも、そういう見積もりでは、嘘...とは言いませんが、色々と矛盾が出てくるかもしれません。
そこで、人月工数で見積もることを止めて、費用対効果での見積もりへシフトできないか？ というのが今回の趣旨の結論です。
P子「効果なんて測定したら、システム開発なんてなくなるわよ」
それは言いすぎでしょうけど、役に立たないシステムとか、以前より効率が落ちるようなリプレースとかもありますから、きちんと費用対効果を計算すれば、導入見送りのシステムなんていっぱい出てくるかもしれません。
4.まとめ
実際問題、この業界での人月見積もりはなくならないでしょう。もちろんパッケージ製品とか人月計算が不要なシステムなら、費用対効果で計算されるのかもしれませんが、それらを自社の業態に合わせてカスタマイズするとかの場合、費用対効果があろうとなかろうと発注されることがまだまだ多いと思います。
P子「パッケージに合わせて業務改革するっていう発想は、まだまだ少ないかもね」
ただ、今までのようにウォーターフォール方式で間に生成AIを入れるのではなく、生成AIでサクッと作って成果を確認しながらダメなら作り直すような、手軽な開発が、生成AIには合っている気がします。
といっても、この方式では見積もりとかできないので、なかなか難しいのかもしれません。
ほな、さいなら
======= <<注釈>>=======
※1 P子「じゃあ、どういう話なの？」
P子とは、私があこがれているツンデレPythonの仮想女性の心の声です。