人月商売の終わり
——人月単価の仕組みとSIer多重下請け構造の崩壊

システム開発の見積書に並ぶ「◯人月×単価」。この人月商売は、「かけた工数がそのまま価値になる」という前提と、SIerの多重下請け構造の上に成立してきました。しかしAIが実装工数を桁違いに圧縮し始めた今、工数と成果の比例関係そのものが壊れつつあります。本稿では、人月単価が決まる仕組み、多重下請けのマージン構造、そして人月モデルから成果モデルへの移行がなぜ不可避なのかを、順に解きほぐします。

人月単価の仕組み——見積書の「◯人月×単価」はこう決まる

「人月」とは、エンジニア1人が1か月働く作業量を表す単位です。従来のシステム開発の見積もりは、想定工数（人月）×人月単価という掛け算で組み立てられます。単価はエンジニアの役割（PM・SE・プログラマ）とスキルランク、そして「どの階層の会社に発注するか」でおおむね決まります。同じ人が同じコードを書いても、大手元請け経由なら高く、下請けに直接頼めば安い。単価の差の多くは技術力の差ではなく、商流の差です。

この方式の本質は、ベンダーが売っているものがソフトウェアではなく人の時間だという点にあります。見積書のどこにも「このシステムが生む価値」は登場しません。登場するのは「何人を何か月動員するか」だけです。金額の内訳がどう積み上がるかはシステム開発の見積もり相場と金額が決まる仕組みで詳しく解説していますが、価格の根拠が最初から成果ではなく人数に置かれている——これが人月商売の出発点です。

「工数=価値」という前提の矛盾

人月モデルには、構造的な矛盾が埋め込まれています。早く作るほどベンダーの売上が減るのです。優秀なチームが3か月の仕事を1か月で終わらせると、請求できる金額は3分の1になります。逆に、作業が長引き、仕様変更が重なり、体制が膨らむほど売上は増える。つまり人月商売では、売り手の利益と買い手の利益が構造的に逆を向いています。

この逆インセンティブは、業界全体の生産性投資を抑え込んできました。生産性を10倍にする道具を導入したベンダーは、理屈のうえでは売上が10分の1になります。だからこそ、開発を劇的に効率化する動きは人月商売の内部からは起きにくく、外側——つまりAIという外圧から起きているのです。工数がかかることは本来コストであり、誇るべきものではありません。工数=価値という等式は、売り手の会計上の都合にすぎませんでした。

SIer多重下請け構造——マージンは何段重なっているか

人月単価をさらに押し上げているのが多重下請け構造です。多くの案件は元請けSIerから二次請け・三次請けへと再委託され、各層が中間マージンを取ります。公正取引委員会が2022年に公表した「ソフトウェア業の下請取引等に関する実態調査報告書」では、最大6次下請として案件に参加した技術者の事例が報告され、回答事業者の15.7%が「買いたたき」を経験したと回答しています。また、実質的な役割を果たさないいわゆる「中抜き」事業者の存在を感じたことがあると答えた最終下請事業者は33.5%にのぼります。

出典: 公正取引委員会「ソフトウェア業の下請取引等に関する実態調査報告書」（2022年6月）

発注企業が支払う金額のうち、実際に手を動かすエンジニアに届くのは一部です。残りは各階層の管理費とマージンに吸収されます。しかも階層が深くなるほど、仕様は伝言ゲームで劣化し、責任の所在は曖昧になり、現場の裁量は失われます。高いのに遅い——日本のシステム開発への典型的な不満は、個々の会社の怠慢ではなく、この構造の必然的な出力です。

それでも人月商売が続いてきた理由

矛盾を抱えながらも人月商売が半世紀近く続いてきたのには理由があります。発注側にとって人月は比較しやすく、稟議を通しやすい単位でした。「50人月・単価100万円」という見積もりは、中身が分からなくても他社と並べて査定できます。また、大人数の体制はそれ自体が「何かあっても対応してもらえる」という安心感を売っていました。

さらに、レガシーシステムの保守運用が大量の人手を恒常的に必要とし、人月ビジネスの安定した収益基盤になってきた側面もあります。経済産業省のDXレポートは、老朽化したシステムを放置した場合、2025年以降最大で年間12兆円の経済損失が生じる可能性を指摘しました（出典: 経済産業省「DXレポート〜ITシステム『2025年の崖』の克服とDXの本格的な展開〜」サマリー）。発注側は比較のしやすさを、受注側は安定収益を得る。人月商売は一種の均衡として維持されてきたのです。ただし、それは工数と成果が比例している間だけ成り立つ均衡でした。

AIが工数と成果を切り離す

2026年のいま、コーディングエージェントは設計・実装・テストの相当部分を自律的にこなします。かつて数人月を要した実装が、AIを指揮する体制なら数日で動く形になる——この変化の詳細は自律型AIエージェント時代のシステム開発で解説しています。ここで重要なのは「安くなる」ことではなく、工数と成果の比例関係が切断されることです。

同じ成果物に対して、ある体制は30人月かけ、別の体制は1週間で到達する。こうなると「何人月かかるか」は価格の根拠として機能しません。人数を数えることに意味がなくなるからです。価格の根拠は必然的に、何が納品され、何が動き、何が改善したか——つまり成果側へ移ります。多重下請けの各階層が取っていた「人を集めて右から左へ流す」機能も、集めるべき人が減れば存在理由を失います。

人月モデルと成果モデルの比較

両者の違いを整理すると次のようになります。

観点	人月モデル	成果モデル
価格の根拠	動員人数×期間×単価	納品物・稼働する機能・事業成果
売り手の動機	工数が増えるほど売上増（長期化が利益）	早く成果を出すほど利益率が上がる
仕様変更	追加工数として増額の根拠になる	成果に必要なら吸収して素早く反映
体制	多重下請けで人を集める。階層ごとにマージン	少人数＋AIエージェント群。中間層が薄い
スピード	人の稼働時間に比例。数か月〜年単位	工数に縛られない。数日で動くものを提示
買い手のリスク	完成まで成果が見えない。追加費用が読めない	早期に動くもので検証でき、撤退判断も早い

成果モデルにも注意点はあります。「成果」の定義と検収基準を曖昧にしたまま契約すると、認識のずれが後で表面化します。小さなスコープで始めて、動くものを見ながら次の範囲を決める進め方が、双方にとって安全です。

JumpStackの実践——人月に依存しない体制とは

JumpStackは「社員は、全員AI。監督は、人間1名。」という体制で受託開発とコンサルティングを行っています。設計・実装・レビュー・QAをAIエージェント群が24時間体制で担い、人間の監督者が要件の見極めと最終判断を行う。この構造では、そもそも動員人数という概念が成立しないため、人月に依存しない提案が可能です。

中核に据えているのはフォワード・デプロイド・エンジニアリング（FDE）という進め方です。お客さまの事業の現場にAIチームを配置し、課題の定義から設計・実装・運用・改善までを同じチームが担います。仕様書の完成を待たず、数日で動くものを出し、現場で直しながら進める。本来は優秀なエンジニアを一社に張り付ける贅沢な体制ですが、社員が全員AIであれば現実的なコストで提供できます。多重下請けの対極——階層ゼロ・伝言ゲームゼロの体制です。

よくある質問

人月単価の相場はいくらですか？

役割・スキルランク・商流の階層によって大きく変動するため、単一の相場を示すことにはあまり意味がありません。重要なのは、提示された単価のうちどれだけが実装の価値で、どれだけが中間マージンなのかという内訳です。相見積もりの際は金額の高低より、再委託の有無と体制の階層を確認することをおすすめします。

人月商売はすぐに消滅するのですか？

すぐには消えません。レガシーシステムの保守や、契約慣行・調達ルールが人月前提の領域は当面残ります。ただし、新規開発の競争条件はすでに変わり始めています。同じ成果を数分の一の期間と費用で出す選択肢が存在する以上、人月見積もりはその選択肢と比較されることになります。

成果ベースの契約に切り替える際の注意点は？

「成果」の定義・検収基準・スコープの境界を最初に合意することです。いきなり大型案件を成果契約にするのではなく、小さな範囲で発注し、動くものが出てくる速度と品質を確かめてから広げるのが安全です。早期に動くものが見られること自体が、発注側のリスク管理になります。

まとめ——「人数」ではなく「成果」で選ぶ

人月商売は、工数=価値という前提と多重下請けのマージン構造の上に成り立つ仕組みでした。AIが実装工数を圧縮し、工数と成果が切り離された今、価格の根拠は人数から成果へ移行しつつあります。発注側が問うべき質問はもう「何人月かかりますか」ではありません。「いつ、何が動きますか」です。この質問に日数で答えられるパートナーかどうかが、これからの選定基準になります。