OpenCode 、Cursor 、Claude Code ——AIコーディング支援ツールを使っていると、ふと気づくことがあります。「この作業、昔なら2日かかってたな」と。

生産性が上がるのは良いことです。しかし、見積もりの現場では厄介な問題が起きています。「人月」という単位が、いよいよ機能しなくなってきたのです。

50年前の予言が現実になった

Fred Brooks の「人月の神話 」（1975年）は、「人月」という単位の問題を50年前に指摘していました。「人と月は交換可能ではない」——有名な一節です。

同書には「銀の弾丸はない 」というエッセイも収録されています。ソフトウェア開発の生産性を劇的に（10倍以上）向上させる「魔法の解決策」は存在しない、という主張です。構造化プログラミング、オブジェクト指向、アジャイル——様々な手法が登場しましたが、いずれも「銀の弾丸」にはなりませんでした。

しかし正直なところ、これらは長らく「理論上の話」でした。現場では人月ベースの見積もりが当たり前に使われ、それなりに回っていた。少なくとも、致命的な破綻は起きていなかった。

AIがその状況を変えました。

皮肉なことに、AIコーディング支援は「銀の弾丸」に近い存在になりつつあります。特定のタスクにおいて、生産性が10倍どころか100倍になるケースすらある。Brooksが「ありえない」と言った世界が、現実になりつつあるのです。

そして、それが「人月」という見積もり手法を根本から揺るがしています。

人月が破綻する瞬間

従来の見積もりは、こういう計算式でした：

見積もり = エンジニア単価 × 工数（人月）

この計算式は、「1人月の作業量はだいたい同じ」という暗黙の前提に依存しています。ベテランと新人で差はあれど、10倍も違うことはないだろう、と。

AIコーディング支援は、この前提を崩壊させました。

これは誇張ではなく、実際に現場で起きていることです。同じ成果物を作るのに、10分の1以下の時間で済むケースが珍しくなくなりました。

では、見積もりはどうすればいいのか？

• 従来通り人月ベースで請求すると：クライアントは「2時間で終わる作業に2日分払わされた」と感じる
• 実作業時間で請求すると：今まで300万円だった案件が30万円になる。開発会社として成り立たない

後者について補足すると、開発会社の経営は「案件単価 × 案件数」で回っています。AIで効率が10倍になったからといって、案件数を10倍にできるわけではない。営業コスト、コミュニケーションコスト、品質管理——実作業以外の部分は効率化されていないからです。

「効率が上がったから値下げしろ」は、一見フェアに見えて、実際には開発会社を破綻させる論理です。

どちらも不健全です。

これが、多くの現場エンジニアが今まさに直面しているジレンマではないでしょうか。

人月の構造的な問題

AI以前から、人月には構造的な欠陥がありました。AIはそれを顕在化させただけとも言えます：

• 生産性の個人差を無視: 同じ1時間でも、エンジニアの経験やスキルで成果は大きく異なる
• ツールの進化を吸収できない: 新しいツールで効率が上がっても、人月単価は変わらない
• 成果物の価値と乖離: 労働時間と、システムが生み出す価値には相関がない

そして現場では、こんな慣習も横行しています：

予算逆算型の見積もり

営業「お客様の予算はいくらですか？」
→ 予算を聞いてから工数を調整する
→ 実際の開発規模とは無関係

相見積もり対策

「受注したいから安く見せる」
→ 後から追加費用を請求

タイムチャージへの逃避

「事前見積もりは難しいので時間単価で」
→ リスクを全てクライアントに転嫁

エンジニアなら一度は経験したことがあるのではないでしょうか。これらは発注者と受注者の間に不信感を生み、業界全体の健全性を損なっています。

「成果物の規模」という考え方

では、どうすればいいのか。

一つの方向性として、「労働時間（Input）」ではなく「成果物の規模（Output）」を基準にする考え方があります。

建築業界では「坪単価」という概念があります。職人が何時間働いたかではなく、建物の規模で価格が決まる。ソフトウェアでも同様のアプローチが取れないか——これは古くから議論されてきたテーマです。

ファンクションポイント法 やユースケースポイント法 といった手法が提案されてきましたが、計測の手間や専門知識の必要性から、広く普及するには至っていません。

私たちの試み：SpecTalk

この問題に対する私たちなりの試みとして、SpecTalk というサービスを作りました。

やっていることはシンプルです：

1. AIとの対話で要件を整理する
2. ユースケースポイント法をベースに、システムの「規模」を算出する
3. 規模に基づいて概算見積もりを出す

見積もり = システム規模 × 規模単価

エンジニアが何時間働くかではなく、どのくらいの規模のシステムを作るかで見積もる。AI時代には、こちらの方がフェアではないかと考えています。

技術的には、従来のユースケースポイント法をWeb3やAI開発に対応できるようカスタマイズしています。詳細は見積もり手法の解説 に書きました。

これが正解かはわからない

正直に言えば、これが「正解」かどうかはわかりません。

ソフトウェアの規模を正確に測定することは難しい。要件は変わるし、技術的な不確実性もある。人月ベースの見積もりが生き残ってきたのは、それなりの理由があるからです。

ただ、AIによって生産性が10倍になる時代に、従来の人月ベースをそのまま使い続けるのは無理があると感じています。何かしらの変化が必要で、私たちはその一つの方向性を模索しているところです。

現場の声を聞かせてください

同じような問題意識を持っているエンジニアの方は多いのではないでしょうか。

• AI時代の見積もり、どうしていますか？
• 人月以外のアプローチを試したことはありますか？
• クライアントへの説明で困っていることはありますか？

SpecTalkは公式サイト から試せます。フィードバックをいただけると嬉しいです。

この問題に対する「業界標準」のような答えはまだ存在しません。だからこそ、現場のエンジニア同士で知見を共有していくことが大事だと思っています。

参考リンク

• SpecTalk
• AI時代のフェアなシステム開発見積もり - 問題意識の詳細
• 見積もり手法の解説 - 技術的なアプローチ
• 人月の神話（Wikipedia）
• ユースケースポイント法（Wikipedia）