AI開発で人月の考え方はどう変わる？工数で測れない部分

AI駆動開発が広がると、「人月」で開発の規模や見積もりを考える方法は成り立つのでしょうか。この記事では、人月が何を測る単位なのかを整理し、AIを使った開発で工数では測りにくくなる部分と、人の時間として残る部分を分けて説明します。新規事業で開発会社の提案を見るときの確認点も扱います。

人月とは何を測る単位か

人月とは、1人が1か月働いたときの作業量を1人月とする単位です。たとえば3人で4か月かかる開発なら12人月と数えます。システム開発の見積もりや要員計画、契約の場面で、長く使われてきました。

人月が使われてきた理由は、見積もりの根拠を示しやすいことです。必要な人数と期間を掛け合わせれば規模の目安が出ます。発注側も受注側も、同じ物差しで話せる利点があります。この物差しは、「作業量は人が手を動かす時間にほぼ比例する」という前提の上に成り立っています。

人月の限界は以前から指摘されていた

人月という考え方の限界は、AIが登場する前から知られていました。1975年に出版されたフレデリック・ブルックスの『人月の神話』は、人と月は単純に交換できないと指摘した古典です。遅れているプロジェクトに人を追加しても、教育や意思疎通の負担が増えて、かえって遅れることがあります。いわゆる「ブルックスの法則」です。

発注側から見ると、もう一つ難しい点があります。人数と期間で決まる見積もりは、完成物の姿が見えないまま判断することになりがちです。どれだけ人が働いたかは分かっても、事業に役立つものができるかどうかは別の話です。AI駆動開発は、この「工数と成果の距離」をさらに広げる可能性があります。

AI駆動開発で変わる作業と変わらない作業

AI駆動開発は、設計や実装、テストなどの工程でAIを活用し、人とAIが役割を分担して進める開発の考え方です。全体像は「AI駆動開発とは｜AIと人の役割分担と発注側の要点」で詳しく整理しています。ここでは人月との関係に絞って、作業を二つに分けてみます。

AIが担う部分が増えている作業

• コードの作成や、既存コードの修正案の提示
• テストコードやテストケースの下書き
• 設計書や仕様書の叩き台づくり
• 画面やデータ構造の初期案の作成

これらは、以前は人が時間をかけて手作業で行っていた部分です。AIが下書きを出し、人が確認して直す流れに変わりつつあります。

人が担い続ける作業

• 何を作るのか、何を作らないのかを決めること
• 事業の仮説と、システムの形を結びつけること
• 出てきたものが目的に合うかを判断すること
• 品質や安全性についての最終的な確認

この二つを比べると、変わっているのは「手を動かす時間」の部分で、「決める・確かめる」部分は残っています。その結果、人が作業した時間の合計と、できあがる成果物の量や価値が、比例しにくくなります。人月で測りにくくなる理由はここにあります。

工数で測れなくなる4つの部分

AIを使った開発で、人月の物差しが当てはまりにくくなる部分を、四つに分けて見ていきます。

実装量と作業時間の関係

従来は、機能が多ければ実装の時間も増え、見積もりも大きくなるのが自然でした。AIが実装の下書きを担うと、機能の数と人の作業時間の対応が緩みます。同じ機能数でも、AIが得意な種類の処理かどうかで、かかる人の時間は変わります。

反対に、AIが苦手とする独自のルールや複雑な業務の流れでは、人の判断と手直しが多くなります。機能の数だけで規模を測ると、実態からずれやすくなります。

試行錯誤の回数

AIの助けで下書きが早く出てくると、「一度作って、見て、直す」という往復を増やしやすくなります。作り直しの負担が小さくなるぶん、一度で正解を決めなくても進められます。

この往復の回数は、人月の見積もりには現れません。事前に仕様を固めて、その通りに作る前提の見積もりだからです。AI駆動開発では、何回確かめられるか、確かめた結果をどう反映するかが、成果を左右する要素になります。

判断と確認の質

AIが出したコードや設計は、そのまま信頼してよいとは限りません。内容が目的に合っているか、セキュリティ上の問題がないか、後から保守できる形になっているかは、人が見て判断します。この確認の深さは、時間の長さだけでは測れません。

三十分の確認で本質的な問題を見つけられる場合もあれば、数時間かけても見落とす場合もあります。確認の質は、経験や基準に左右されるためです。品質に人の確認が必要な理由は「AI開発でも品質には人の確認が必要な理由」で、安全面の確認点は「AI生成コードのセキュリティ｜確認点と人の役割」で扱っています。

基盤と蓄積された知見

AIをどう使うかは、開発会社ごとに違います。AIに工程ごとの役割を与える仕組み、レビューの基準、過去の経験の取り込み方などが、成果に影響します。これらは人数や期間に表れにくい要素です。

LLM（大規模言語モデル）だけで開発する場合と、開発工程を組み込んだ仕組みを使う場合の違いは「AI開発フレームワークとは｜LLMだけの開発との違い」にまとめています。同じ人数・同じ期間でも、基盤の違いで成果物の安定度が変わる点は、人月では説明できません。

人月はなくなるのか：残る部分と比重が増える部分

ここまでの話から、「人月は不要になる」と考えるのは早計です。AIが担う部分が増えても、人の時間が必要な部分は残るからです。むしろ、比重が大きくなる部分もあります。

• 決める時間：AIは「何を作るか」を代わりに決めてくれません。作るものが曖昧なままでは、速く作れても方向がずれます。要件を整理する流れは「AI要件定義で変わること｜AIが整理し人が決める範囲」で解説しています。
• 確かめる時間：AIの出力をレビューし、テスト結果を読み、目的に合うか判断する時間です。作る時間が減っても、確かめる時間は簡単には減りません。
• 発注側の時間：実物を見て判断し、フィードバックを返す時間です。発注する側の判断が遅いと、開発がどれだけ速くても全体は遅れます。発注側の役割は「発注側のプロダクトオーナーとは｜役割と判断のしかた」にまとめています。
• 作った後の時間：保守や改修、機能追加は、納品後も続きます。AIで作ったコードでも引き継ぎや改修が必要で、確認点は「AI生成コードの保守は可能か｜引き継ぎと改修の確認点」にあります。

つまり、人月が消えるのではなく、「人が手を動かした時間」から「人が判断した内容」へ、価値の中心が移っていきます。物差しが一本では足りなくなる、と考えるほうが実態に近いでしょう。

人月で見積もられた提案を見るときの確認点

AI駆動開発をうたう会社でも、提案書が従来どおりの人月で書かれていることがあります。それ自体が問題とは限りません。私たちは、次の点を確かめると、提案の中身が見えやすくなると考えています。

• 何に対する人月なのか：設計・実装・テスト・確認など、どの作業に何人月が割り当てられているのか。内訳が分かると、AIで変わる部分と人が担う部分を区別して話せます。
• 完成したものの姿を、途中で確認できるか：人数と期間だけでなく、動く実物を見て判断できるかどうか。成果物が見えるほど、工数への依存は小さくなります。
• AIを使うことで何が変わるのかの説明があるか：AIの活用が提案の前提に入っているか、単に「AIを使います」と書かれているだけなのか。工程ごとの役割分担が説明されていると安心です。
• 品質の確認を誰がどう行うのか：AIの出力を、誰が、どんな基準で確認するのか。人の最終判断の位置づけが示されているかを見ます。
• 途中で仕様が変わったときの扱い：新規事業では、進めるうちに要望が変わるのが普通です。変更の扱いは「システム開発の仕様変更への対応｜追加要望の扱い方」で整理しています。
• 納品後の対応範囲：不具合の修正や機能追加がどこまで含まれるのか。

依頼前に確かめたいことの全体像は、「AI受託開発に依頼する前に確かめたい6つのこと」でも扱っています。

たとえば「10人月」という提案を見たとき

仮に、ある提案書に「10人月」とだけ書かれていたとします。これだけでは、どの作業にどれだけの時間がかかり、AIがどこまで関わるのかは分かりません。10人月のうち、手を動かす実装の割合が高いのか、判断と確認の割合が高いのかでも、中身の性質はまったく違います。

数字を見るときは、「この人月は、どんな成果物と確認の工程に対応しているのか」と問い直すことが有効です。数字そのものより、数字の裏にある作業の中身が判断材料になります。

新規事業で「成果物で測る」考え方が合う理由

新規事業の開発では、作るものの仕様が最初から固まっていないことが多くあります。その段階で人数と期間を先に決めると、あとから「作りたいものが違った」と気づいたときに、方向を直しにくくなります。工数を先に固める見積もりは、仕様が確定している開発には向いていますが、事業の仮説を確かめながら進める新規事業とは相性がよくありません。

AIで試作の負担が軽くなると、先に動く実物を作って確かめてから、本格的な開発を判断する進め方が現実的になります。小さく作って確かめる投資判断の進め方は「新規事業の開発は小さく作って確かめる投資判断の進め方」で解説しています。プロトタイプとMVP（最小限の機能で市場に出す試作品）の違いは「プロトタイプとMVP・モックの違いを整理｜新規事業の使い分け」が参考になります。

成果物で測るときに気をつけたいこと

成果物ベースで考える場合にも、注意点があります。

1. 範囲をはっきりさせる：成果物で合意するなら、何を作り、何を作らないのかを先に決めておく必要があります。範囲が曖昧だと、工数基準とは別の形で認識がずれます。
2. 確認の基準を決めておく：どうなれば「できた」と見なすのか、事業としての判断基準を用意します。
3. 次の判断につなげる：作って終わりではなく、続けるか、変えるか、やめるかを決める材料にします。

最初に作る範囲の考え方は「MVP開発の機能の絞り方｜最初に作るものと後回しの基準」も参考になります。

まとめ

AI駆動開発で、人月の考え方はなくなるのではなく、使い方が変わります。この記事の要点は次のとおりです。

• 人月は「作業量は人の作業時間に比例する」という前提で成り立つ物差しで、この前提はAIの活用で弱まる。
• 工数で測りにくくなるのは、実装量、試行錯誤の回数、判断と確認の質、基盤と知見の蓄積の四つ。
• 一方で、何を作るかを決める時間、確かめる時間、発注側の判断の時間は残り、比重も増える。
• 人月で書かれた提案は、数字そのものより、内訳・実物の確認方法・AIの役割・品質確認の担い手・変更時の扱い・納品後の対応を確かめる。
• 仕様が固まっていない新規事業では、動く実物で確かめながら成果物で判断する進め方が合いやすい。

私たちJustFitは、株式会社LEGAREAが運営する受託開発サービスです（JustFitのサービス紹介）。「先に作って、後から決める」という考え方で、構想をもとに約1ヶ月で動くプロトタイプを開発し、実物を見てから契約を判断していただけます。独自の開発基盤「LAF」では、複数の専門AIが要件定義から設計、実装、テスト、レビューまでをチームとして進め、人は「何を作るかを決めること」と「品質の最終判断」を担います。LAFは、人月商売ではない新しい構造をメリットのひとつに掲げています。仕様がまだ固まっていない段階でも相談できますので、詳しくはご相談ください。