Share
「人月商売」からの脱却｜AI時代に開発の対価を再設計するための構造論
人月商売が限界を迎えている。 そのこと自体は、もう多くの人が感じています。
AIが開発効率を劇的に変える中で、 「エンジニアの稼働時間＝対価」という前提が崩れ始めている。
効率化するほど売上が減る。
請負開発では、ベンダーがどれだけ良いものを作っても、作った「時間」と「工数」でしか価値が評価されない。
この矛盾に気づいていない人は、もう少ないはずです。
問題は、その先にあります。
「限界はわかった。では、どうすればいいのか」。
人月商売に代わるモデルとは何か。 発注者として、見積もりや契約の考え方をどう変えるべきか。 受注者として、何を売り、何で評価されるべきか。
この問いに対して、評論家の立場から語ることはできません。
私たちRabiloo（ラビロー）は、ベトナムの開発現場で 人月商売の中に身を置きながら、そこからの脱却を設計し、 実行している当事者です。
この記事では、人月商売の構造的な限界を簡潔に整理した上で、 その先にある「価値の再設計」の考え方と、 Rabilooが現在進行形で取り組んでいる実践を共有します。
人月商売の構造的限界──「効率化するほど損をする」矛盾の正体
AI時代に矛盾が加速するメカニズム
発注者が「見積もりの読み方」を変えるための視点
Rabilooが実践する、人月商売からの脱却の設計
「人月商売」とは何か──長く機能してきた理由とその構造
人月商売の問題を語る前に、 まずこのモデルがなぜ半世紀にわたって機能してきたのかを整理します。
「人月商売とは、エンジニアの稼働時間を単位として売上を立てるビジネスモデル」です。
エンジニア1人×1ヶ月＝1人月。見積もりの仕組み
仕組みはシンプルです。
エンジニア1人が1ヶ月間フルタイムで稼働すること。 これを「1人月」と呼びます。
開発の見積もりは、この人月を基本単位にして組み立てられます。
エンジニア3人 × 2ヶ月 ＝ 6人月
1人月あたりの単価が80万円なら、6人月 ＝ 480万円
投入する「人数」と「期間」が決まれば、 コストが自動的に算出される。 発注者にとっても受注者にとっても、非常にわかりやすい計算式です。
エンジニアの人月単価はどのように決まるのかについて詳しくは以下の記事で解説しています。
▶︎エンジニア1人月単価の相場とは？工数単価の内訳と見積もりの考え方を解説
予測しやすく、拡大しやすい。人月商売が広まった合理性
このモデルが日本のIT業界に深く根づいたのは、 単なる慣習ではなく、構造的な合理性があったからです。
発注者にとっての合理性：
コストが事前に予測できる（人数×期間×単価）
社内稟議が通しやすい（数値で説明可能）
ベンダー間の比較が容易（単価の横並び比較）
受注者にとっての合理性：
売上の見通しが立てやすい（稼働人数＝売上）
事業拡大の方程式が明快（人を増やせば売上が伸びる）
契約がシンプルで管理コストが低い
予測可能で、管理しやすく、スケールしやすい。
大量のシステム開発需要を、大量のエンジニアで処理する。
高度経済成長期から続く日本のIT産業の成長と、
このモデルは見事に噛み合っていました。
「単価の安いエンジニアを確保すれば、コストを下げられる」。
その論理から、人件費の低い海外のエンジニアを活用するオフショア開発にも注目が集まりました。
人月モデルと、コスト競争力のあるオフショア開発は、構造的に相性のよい組み合わせでした。
しかし、このモデルには構造的な前提があります。
「エンジニアの生産性は、おおむね一定である」という前提です。
1人のエンジニアが1ヶ月でできることが大きく変わらない限り、 人月は価値の「物差し」として機能します。
ところが「AI」
が、この前提を壊し始めています。
人月商売はなぜ「限界」なのか──3つの構造的矛盾
人月商売の限界は、単なる時代遅れの話ではありません。
「人月商売の限界とは、モデルの内部に組み込まれた3つの構造的矛盾が、AI時代に無視できなくなったこと」です。
多くの方がすでに感じている違和感を、 ここで構造として整理します。
矛盾① 生産性を上げるほど、売上が減る
人月商売では、売上は「稼働時間」に比例します。
つまり、技術力を磨いて作業を速く終わらせるほど、 売上は減る。
たとえば、同じ機能を開発するのに、 あるチームは6人月かかり、別のチームは2人月で完成させた。 生み出した「価値」は同じです。 しかし人月商売では、6人月のチームの方が3倍の売上を立てます。
この構造の下では、受注者には 「速く終わらせない」インセンティブが暗黙に働きます。
もちろん、意図的にサボるという話ではありません。 しかし、効率化への投資が利益に結びつかない構造がある限り、 組織として生産性向上に本気で取り組む動機は生まれにくい。
これは人の問題ではなく、モデルの問題です。
矛盾② どんなに良いものを作っても、評価基準は「時間」だけ
人月商売では、「製品の価値ではなく、製品を作った時間だけが評価の基準」になります。
どれほど優れたUI設計をしても。 どれほどビジネスインパクトのある機能を実装しても。 対価は「何時間かかったか」でしか決まりません。
この構造は、発注者にとっても不利益です。
見積もりの妥当性を判断しようとしても、 「この機能に本当に3人月かかるのか」を外部から検証する手段がない。 結果、見積もりは「信じるか、値切るか」の二択になりがちです。
本来、発注者が知りたいのは 「この投資でどんなビジネス成果が得られるか」であって、 「エンジニアが何時間働くか」ではないはずです。
矛盾③ 技術革新へのインセンティブが構造的に生まれない
矛盾①と②が組み合わさると、 業界全体に「技術革新が進みにくい構造」が生まれます。
新しいツールやフレームワークを導入して生産性を上げても、 人月商売では売上が減る。 つまり、イノベーションへの投資が経営判断として正当化されにくい。
さらに、発注者側も「時間＝コスト」でしか評価しないため、 「AIを活用して3分の1の期間で完成させました」と報告しても、 それは「3分の1の対価しか払わなくてよい」という結論に直結します。
受注者は効率化する動機を持てず、 発注者は効率化の果実を適切に評価する尺度を持たない。
これが、人月商売の限界の本質です。 そしてこの限界が、AIの登場によって一気に表面化しています。
AI時代が人月商売の限界を「加速」させている
オフショア開発が効率化したらクライアントにとって価値があるはずなのに報酬は減るのか？
人月商売の矛盾は、以前から存在していました。 しかしそれは長い間、「構造的にはおかしいが、実務上は回っている」レベルの問題でした。
AIが、このバランスを壊しました。
「AIによる生産性の変化が、人月商売の矛盾を理論上の問題から、今そこにある経営危機に変えた」。 これが、2026年の現実です。
6人月が1ヶ月に──AIが書き換えた生産性の前提
具体的な数字で考えます。
従来、オフショア開発でエンジニア3人が2ヶ月かけて開発していた機能があるとします。 6人月。単価40万円なら、240万円のプロジェクトです。
AIを活用した開発では、 同等の機能を1ヶ月で完成させるケースが現実に生まれています。
私たちRabilooの現場でも、 AIを開発プロセスに組み込むことで、 従来の工数を大幅に短縮できる領域が確実に広がっています。
人月商売の矛盾が、ここで鮮明になります。
6人月かかっていた仕事を1ヶ月で終えた。 生み出した価値は同じ。むしろ、速く届けた分だけ顧客の利益は大きい。
しかし人月商売では、対価は6分の1です。
「速く、良く作るほど損をする」。 AIによって生産性の振れ幅が桁違いに大きくなった今、 この矛盾はもはや無視できる水準ではなくなりました。
効率化と収益性のジレンマ──エンジニアリソースの切り売りは終わる
この問題を、受注者（開発会社）の経営視点で見ると、 突きつけられているのは2つの選択肢です。
選択肢 | 内容 | 帰結 |
|---|---|---|
A. 開発プロセスの最適化 | AIを活用して生産性を上げる | 稼働時間が減り、人月商売の下では売上が減少する |
B. 付加価値の創出 | 設計・提案・ソリューション提供にシフトする | 人月単価ではなく、成果物の価値で評価される必要がある |
Aだけを選べば、効率化の果実を自ら捨てることになります。 Bに進むには、ビジネスモデルそのものの転換が必要です。
どちらの道を選んでも、 「エンジニアリソースを切り売りするビジネスモデル」の延長線上には答えがない。
これは受注者だけの問題ではありません。
発注者にとっても、 人月商売のベンダーに開発を任せ続ける限り、 AI時代の生産性向上の恩恵を受け取りにくい構造になっています。
ベンダーが効率化すれば見積もりが下がる──一見よいことに思えます。
しかし人月商売という構造の下では、 ベンダーが効率化した成果をクライアントに届ける仕組みが存在しません。 対価は「稼働時間」で決まるため、効率化しても価格への反映は自動的には起きない。
人月商売の限界は、発注者と受注者の間に 「利害が一致しない構造」を生み出しているのです。
では、この構造からどう抜け出すのか。 まず、発注者側の視点から考えます。
発注者が問うべきこと──「実行するベンダー」か「提案するパートナー」か
多くの発注者は、まず複数社に声をかけて見積もりを依頼します。 いわゆる「アイミツ（相見積もり）」です。
価格帯として明らかに高ければリジェクト。 残った候補を、担当者の印象・提案の具体性・実績で絞り込む。 これは合理的な行動です。
しかし、この選定プロセスには見落とされやすい問いがあります。
「このベンダーは、依頼した仕様を実行するだけか。それとも、もっと良い答えを持ち込んでくるか」。
発注者の要件は、必ずしも最適解ではない
開発の依頼には、構造的な前提があります。
発注者は自社の業務を知っています。 しかし、その業務をどう技術で解くかについては、専門家ではありません。
つまり、発注者が作成した要件定義は「自分の視野の範囲で考えた解」です。 視野が狭いこともある。 別の切り口から考えれば、より実際的な解があることも多い。
このとき、ベンダーに2つの選択肢があります。
選択肢A：要件通りに実行する
依頼された機能を、決められた工数で、期待通りに納品する。 「クライアントの期待に応えている」という意味では正しい。
しかし、これは「言われたことをやる」という姿勢です。 クライアントが気づいていない問題や、より良いアプローチは視野に入らない。
選択肢B：要件の背景にある課題を問い直し、より良い答えを持ち込む
「なぜこの機能が必要なのか」「この要件で本当に課題が解決するのか」を考え、 必要であれば別の提案を持ち込む。 開発工程を効率化するだけでなく、 AIを活用することでクライアントのビジネス課題をより根本から解決できないかを提案する。
これは、受け取った依頼に「応える」だけでなく、クライアントの事業の長期的な価値に「貢献する」という姿勢です。
「提案を怠けない」ことが、AI時代の価値になる
人月商売の構造では、この2つの選択肢の対価は変わりません。
どちらも「工数×単価」で精算されるため、 深く考えて提案するより、言われた通りに実行する方が、受注者にとってリスクが少ない。 人月商売は構造的に、提案を怠けるインセンティブを生み出しています。
これが、発注者が長期的に受け取れる価値を制限している根本原因です。
AI時代の選定で問うべきは、この一点に絞られます。
「このベンダーは、私が気づいていないことを考えてくれるか」。
実際の選定で意味を持ち始めている軸は以下のようなものです。
業界・業務への理解の深さ（ドメイン知識があるか）
提案の質（依頼を鵜呑みにせず、課題の本質に踏み込んでいるか）
AIの活用方針（効率化だけでなく、クライアントの課題解決にAIをどう使うかを語れるか）
変化への対応体制（仕様変更や方向転換に柔軟に対応できるか）
この「変化への対応体制」は、契約形態の選択にも直結します。
仕様が変わっても、優先順位が変わっても、 柔軟に方向転換できるチームを一定期間確保する。 これがラボ型契約（準委任契約）の本質であり、 Rabilooのクライアントの約72%が、このラボ型契約を選択しています。
ラボ型契約もまた「月額×人数」で費用が発生する以上、 見かけ上は人月に近い構造を持っています。 しかし決定的な違いがあります。
ラボ型では、「何を作るか」は契約で固定されません。 発注者がプロダクトオーナーとして優先順位を柔軟にコントロールできる。 つまり、対価の対象が「時間」から「判断と対応の自由度」に移っているのです。
（※ラボ型契約と請負契約の違い、選び方の詳細は ラボ契約と請負契約の違い｜オフショア開発の契約形態の選び方で解説しています）
ただし、契約形態を変えるだけでは十分ではありません。 受注者側もまた、「何を売るか」を再定義する必要があります。
「人月商売」からの脱却──Rabilooが実践する価値の再設計
しかし本音を言えば、脱却が最も難しいのは受注者──開発会社の側です。
「人月商売からの脱却とは、売り物の再定義である。エンジニアの稼働時間ではなく、チームが生み出す価値そのものを売る構造に変えること」。
以下は、Rabilooが現在進行形で設計・実行している転換の構造です。 完成した答えではなく、当事者として現場から得られた知見として読んでいただければ幸いです。
価値競争の3ステップ（人材支援型 → 技術伴走型 → 戦略パートナー）
人月商売からの脱却は、一夜にして起こるものではありません。 Rabilooでは、この転換を3つのステップで設計しています。
ステップ1：人材支援型（信頼構築）
出発点は、エンジニアリソースの提供です。 「必要な人材を、必要な期間、確保する」。 これは人月商売そのものであり、多くのオフショア企業が今いる場所です。
しかし、ここで終わっていては脱却は始まりません。 このフェーズの本当の目的は、 顧客との信頼関係を構築し、「次のステップに進む資格」を得ることです。
ステップ2：技術伴走型
信頼を得た後、役割が変わります。 「言われたものを作る」から「どう作るべきかを一緒に考える」へ。
設計や技術選定に踏み込み、 顧客が持っていない技術的な視点を提供する。 「作業の委託先」ではなく「技術判断のパートナー」として機能する段階です。
ここで初めて、対価の基準が 「稼働時間」から「技術的な判断と提案の質」に移り始めます。
ステップ3：戦略パートナー（価値競争）
最終的に目指すのは、顧客のビジネス課題そのものに踏み込む関係です。
「なぜ作るのか」「何を作るべきか」から議論に入り、 開発を通じてビジネス成果に直接貢献する。 対価は「投入した時間」ではなく「生み出した価値」で測られる。
この段階に到達するには、 3つの能力が不可欠だと考えています。
能力 | 内容 |
|---|---|
設計・提案ができる技術力 | 顧客の要望を技術的に最適な形に翻訳し、代替案を提示できる力 |
業界理解（ドメイン知識） | 小売・物流など、顧客の業界特有の課題やフローを理解した上で設計できる力 |
AIを活用した生産性と品質の最適化ノウハウ | AIを「ツール」としてだけでなく、チームの能力を拡張する「基盤」として活用する力 |
この3つを掛け合わせることで、 人月単価ではなく、成果物の価値で評価されるビジネスモデルが成立します。
AIで強化された高品質なチームをつくる
この3ステップを実際に動かしているのが、社内でのAI活用です。
開発会社がAIをどう段階的に取り込んでいるか、 通常は外から見えにくい部分ですが、私たちの現在地をそのまま示します。
現在の取り組み（AI＝支援ツール）
個人業務の生産性向上
各部門でAIを日常業務に活用
部門ごとにAI活用領域を拡大
2026年の方向性（AI＝労働力）
CTO主導で全社的なAI transformationを推進
AI Agent / AI Employeeを業務に組み込む
業務プロセス全体にAIを統合
AIで強化されたチーム運営への進化
達成目標（AIトランスフォーメーション）
全社的な生産性向上の実現
高品質なサービス提供の維持
競争力の強化
全社生産性30%UP
重要なのは、この30%の生産性向上を 「見積もりを30%安くする」ために使うのではないということです。
AIで速くなった分を、 より深い設計、より丁寧なテスト、より高度な提案に再投資する。 つまり、「同じ時間でより高い価値を生み出す」方向に使う。
これが、人月商売の構造──「効率化＝売上減」──を 根本から反転させる設計です。
私たちの考え方はシンプルです。
AI時代の強みは、AIで強化された高品質なチームをつくること。 そして、そのチームが生み出す価値で評価されること。
この転換は、まだ道半ばです。 しかし、方向は定まっています。
よくある質問（FAQ）
Q. 人月商売とは何ですか？
A：エンジニアの稼働時間（人数×期間）を単位として売上を立てるビジネスモデルです。
「1人月」とはエンジニア1人が1ヶ月間フルタイムで稼働すること。開発の見積もりはこの人月を基本単位にして、投入する人数と期間から算出されます。日本のIT業界で長く主流となってきたモデルですが、AI時代に構造的な限界が顕在化しています。
Q. 人月商売の最大の問題点は何ですか？
A：「生産性を上げるほど売上が減る」という構造的矛盾です。
人月商売では対価は稼働時間に比例するため、AIやツールを活用して効率化し、短期間で高品質な成果を出すほど、受注者の売上が減少します。この構造の下では、技術革新や効率化への投資が経営的に正当化されにくくなります。
Q. 人月商売に代わるモデルはありますか？
A：「成果ベース」と「対応力ベース」の2つの考え方が実務で機能し始めています。
成果ベースは、投入時間ではなく実現したビジネス成果に対して対価を支払うモデルです。対応力ベースは、チームの稼働ではなく変化への柔軟な対応力を確保するモデルで、ラボ型契約（準委任契約）がこれに該当します。
Q. 発注者として人月商売から脱却するには、何から始めるべきですか？
A：見積もりの読み方を変えることが第一歩です。
「この機能に何人月かかるか」ではなく、「この投資で何が実現するか」を問う。工数の内訳を精査するのではなく、開発がもたらすビジネス成果に着目する。この視点の転換が、契約形態や体制設計を見直すきっかけになります。
Q. ラボ型契約も「月額×人数」で費用が発生しますが、人月商売と何が違うのですか？
A：対価の対象が「時間」から「判断と対応の自由度」に移っている点が決定的に異なります。
ラボ型契約でも月額費用は発生しますが、「何を作るか」は契約で固定されません。発注者がプロダクトオーナーとして優先順位を柔軟にコントロールでき、方向転換に再見積もりが不要です。対価は稼働時間そのものではなく、チームが持つ対応力に支払われています。
まとめ｜「時間を売る」から「価値を共に作る」へ
人月商売は、悪いモデルではありませんでした。
予測しやすく、管理しやすく、拡大しやすい。 日本のIT産業の成長期において、 このモデルには確かな合理性がありました。
しかし、AIがエンジニアの生産性を根底から変えた今、 「時間＝価値」という前提は成り立たなくなっています。
効率化するほど売上が減る
良いものを速く作るほど、対価が下がる
技術革新への投資が経営的に正当化されにくい
これらの矛盾は、もはや見て見ぬふりができる水準ではありません。
人月商売からの脱却とは、 このモデルを「壊す」ことではなく、 時間ではなく価値を軸にした関係へ「再設計」することです。
発注者にとっては、 「何人月か」ではなく「何が実現するか」で見積もりを読むこと。
受注者にとっては、 稼働時間ではなく、生み出す価値そのもので評価される構造を作ること。
この転換は、どちらか一方だけでは成立しません。 発注者と受注者が、対等なパートナーとして 「価値を共に作る」関係に進化する必要があります。
Rabilooは、その関係の中にいたいと考えています。
契約形態の選び方は、この「再設計」の具体的な第一歩です。 ラボ型契約と請負契約の違い、それぞれの適性については ラボ契約と請負契約の違い｜オフショア開発の契約形態の選び方で詳しく解説しています。
また、人月商売の課題を含むベトナムオフショア開発の全体像については ベトナムオフショア開発の現在地｜2026年の構造変化と選び方をご覧ください。
「見積もりの数字に、漠然とした違和感がある」。 「今のベンダーとの関係を、もう一段進化させたい」。
そのような段階から、開発の体制設計を共に考えます。 何をどう作るかが決まっていなくても構いません。 まずは、解決したいビジネス課題をお聞かせください。
Share