人月モデルの限界とAI時代の開発見積｜発注側が確認すべき判断基準
AI coding agentの普及により、システム開発の見積は「何人月か」だけでは判断しにくくなっています。 この記事では、人月モデルを発注側がどう読み替え、AI利用範囲、レビュー責任、変更管理、知識移転を契約前に確認するかを整理します。
目次
結論要約
人月モデルはすぐに消えるわけではありませんが、AI時代の開発見積では作業量よりも不確実性、責任範囲、レビュー体制を分けて見る必要があります。
AIで短縮されやすいのは実装初稿、調査、テスト作成などで、要件判断、既存システム調整、品質責任、社内合意は残ります。
発注側は、人数と単価だけでなく、要件定義、レビュー、変更管理、ナレッジベース整備、AI利用ルールが見積に含まれているか確認するべきです。
請負か準委任かを選ぶ前に、成果物、検収条件、仕様変更時の扱い、AI生成物のレビュー責任を明文化する必要があります。
複数ベンダー案件では、AIを使うほど情報の散在が事故につながるため、議事録、仕様、判断履歴、課題管理を共通の知識として残す体制が欠かせません。
人月モデルとAI時代の開発見積
人月モデルとは、システム開発に必要な人数と期間を掛け合わせ、工数をもとに費用を算出する見積方法です。
たとえば、2人が3か月動くなら6人月として計算します。
発注側にとって分かりやすい一方で、要件の曖昧さ、既存システムの制約、レビューや手戻りの負荷までは読み取りにくい方法です。
まだ使える場面
人月モデルは、保守運用、既存機能の小改修、画面追加、テスト項目の消化など、作業範囲が比較的はっきりしている場面では今も有効です。
担当者の稼働量を予算化しやすく、社内稟議にも載せやすいからです。
発注側が複数ベンダーの単価や体制を比べる場合も、共通のものさしとしては悪くありません。
問題は、人月だけで開発の難しさを説明しようとする場面です。
AIを使えばコードを書く速度は上がりますが、顧客業務の理解や既存システムとの接続確認は自動では終わりません。
2026年時点の見積では、人月を残しつつ、その内訳を工程、責任、前提条件に分けて読む姿勢が必要です。
見積の主語を人数からリスクへ移す
発注側が見るべき問いは「何人で何か月か」だけではありません。
誰が要件の未確定部分を引き受けるのか。
誰がAI生成コードをレビューするのか。
仕様変更が起きたとき、追加費用にするのか、月次稼働の範囲で吸収するのか。
ここが曖昧な見積は、開始時には安く見えても、後半で調整費用が膨らみます。
つまり、AI時代の開発見積では、人月は価格の一部にすぎません。
発注側は、作業量の見積と、不確実性を管理する見積を分けて確認する必要があります。
AIで変わる工程と変わりにくい工程
IPAは、AIを用いたソフトウェア開発の活用場面として、要件定義、議事録管理、コード生成、レビュー、テストやテストデータ作成などを挙げています。
実際の開発現場でも、AIは下書きや調査、候補案の作成で効果を出しやすくなっています。
ただし、すべての工程が同じ割合で短くなるわけではありません。
短縮されやすい作業
AIで短縮されやすいのは、入力と期待結果が比較的明確な作業です。
CRUD画面の初稿、API呼び出しの雛形、既存コードに沿った修正、テストケースのたたき台、議事録の要約、仕様書の差分整理などが該当します。
GitHub Copilotの実験では、特定のJavaScript実装課題で、Copilotを使った開発者の完了時間が短くなったと報告されています。
この種の数字は、そのまま全案件へ当てはめるものではありません。
実験課題と業務システム開発では、既存データ、権限、関係者、リリース責任が違います。
発注側は「AIで何割安くなるか」よりも、「どの工程をAIで短縮する前提なのか」を見積書で確認してください。
残りやすい作業
短縮されにくいのは、判断と合意が絡む作業です。
業務部門への確認、例外処理の決定、既存システムの制約調査、セキュリティレビュー、障害時の責任分担、リリース判定は、AIが案を出しても人が決めます。
DORAの2024年レポートも、AI利用が個人の生産性や満足度に効く一方で、ソフトウェアデリバリー全体には別の影響が出る可能性を示しています。
発注側がここを見落とすと、実装は速いのに検収が終わらない案件になります。
ベンダーがAIを使うこと自体は問題ではありません。
問題は、AIで速くなった工程の後ろに、レビュー、修正、説明、承認の時間を残しているかです。
関連記事
国内の開発費上昇とAI coding agentの普及により、オフショア開発を「安い実装部隊」として使う前提は崩れ始めています。 本記事では、AIで置き換わりやすい工程と、むしろ海外チームの価値が上がる工程を分け、日本側PMとAI-nativeな海外体制の役割分担を整理します。
人月見積で見落としやすい費用
人月見積の弱点は、見積書の行がきれいに並んでいるほど、発注側が安心してしまう点です。
しかし、実際の費用は実装工数だけで決まりません。
既存システムの調査、ベンダー間の調整、仕様変更、受け入れテスト、運用引き継ぎの時間が抜けると、後から社内負荷として返ってきます。
図では、従来の「人数、単価、期間」だけの見積から、「不確実性、レビュー責任、変更管理、知識移転」を含む見積へ広げて示します。
重要なのは、AIで実装時間が短くなっても、発注側の判断時間まで消えるわけではないという点です。
見えにくい調整費
複数部門が関わる開発では、画面や機能を作る前に、誰が何を決めるかをそろえる必要があります。
営業部門は入力項目を増やしたい。
経理部門は締め処理と連携したい。
情報システム部門は権限と監査ログを確認したい。
この調整は、見積上では要件定義やPM費にまとめられがちです。
AIは議事録や仕様整理を助けますが、部門間の利害を決める主体にはなれません。
したがって、発注側はPM費や要件定義費の中に、関係者調整、意思決定支援、課題管理、判断履歴の整理が含まれるかを確認する必要があります。
レビューと検収の費用
AIが生成したコードやドキュメントは、人が読んで受け入れなければ成果物になりません。
見積にレビュー工数が薄い場合、ベンダーは「作るところ」までは速く進めても、品質確認を発注側へ寄せることがあります。
社内の担当者が夜に仕様確認を続けるような案件は、表面上の開発費が安くても総額では高くつきます。
検収条件も同じです。
画面が動くこと、テストが通ること、業務で使えることは別の判断です。
発注側は、検収時に見る項目、差し戻し回数、バグ修正の範囲、運用開始後の不具合対応を、見積段階で分けてください。
発注側が見るべき見積項目
AI時代の見積比較では、最安の人月単価を探すよりも、見積項目がどこまで分解されているかを見ます。
同じ総額でも、要件定義が薄く実装に寄った見積と、調査、設計、レビュー、移行、運用準備まで含む見積では、発注側が背負う負荷が変わります。
分解して確認する項目
次の表は、発注側が見積書で確認すべき項目です。
金額の大小だけでなく、どの項目が空白になっているかを見ると、後から揉めやすい部分が分かります。
見積項目 | 確認する内容 | 判断ポイント |
|---|---|---|
要件定義 | 未確定事項と決定者 | 誰が判断するか明記する |
AI利用 | 使う工程とレビュー方法 | 生成物を人が確認する |
品質保証 | テスト範囲と検収条件 | 業務利用まで見る |
変更管理 | 追加要望の扱い | 料金化の条件を決める |
知識移転 | 仕様・運用手順の残し方 | 社内に残る形にする |
この表にある項目が見積書にない場合、必ずしも悪い見積とは限りません。
ただし、発注側の誰かがその負荷を持つことになります。
社内にPMやテックリードがいない企業ほど、見積に含めるべき範囲は広くなります。
安い見積の読み方
安い見積には理由があります。
要件定義を発注側が担う前提なのか、AIで初稿作成を短縮する前提なのか、テスト範囲を限定しているのか、運用引き継ぎを含まないのか。
理由が明確なら、安い見積を選ぶ判断もあります。
避けたいのは、理由が分からない安さです。
人月単価が低くても、発注側が仕様整理、レビュー、受け入れテスト、社内説明を肩代わりするなら、実質的なコストは下がりません。
比較表では、総額の横に「発注側が担う作業」を1列追加すると判断しやすくなります。
関連記事
IT人材不足への対応策として外部委託を選ぶ企業は増えていますが、委託比率を高めるだけでは開発速度や品質が安定しないケースが少なくありません。 本記事では、外注依存で失敗する構造を整理したうえで、内製化と外部活用をどう切り分けるべきかを実務視点で解説します。
契約前に確認するAI利用と責任範囲
AIを使う開発では、契約前の確認事項が増えます。
AI利用そのものを禁止する必要はありません。
むしろ、AIをどう使い、どこで人が確認し、どの成果物に責任を持つかを明確にしたベンダーの方が、発注側にとって扱いやすい場合があります。
請負と準委任で変わる確認
請負契約では、成果物と検収条件の定義が重くなります。
AIで作ったかどうかにかかわらず、納品物が要件を満たすか、瑕疵や不具合が出たときにどう対応するかを確認します。
一方で、準委任契約では、稼働時間、作業範囲、報告、レビュー、意思決定の進め方が重要です。
どちらが正しいという話ではありません。
要件が固まり、成果物が明確なら請負が合いやすい。
探索や改善を含む案件なら準委任の方が扱いやすいことがあります。
ただし、契約類型だけで安心せず、AI生成物のレビュー責任、利用ツール、入力してよい情報、成果物への権利処理を確認してください。
発注前の質問
ベンダーへは、次のように具体的に聞くと、見積の前提が見えます。
抽象的に「AIを使いますか」と聞くだけでは、実務上の差が分かりません。
AIを使う工程は、調査、実装、テスト、レビュー、ドキュメントのどこですか。
AIが出したコードや仕様案を、誰がどの基準でレビューしますか。
顧客情報、ソースコード、業務データをAIツールへ入力する場合のルールはありますか。
仕様変更が出たとき、追加費用になる条件は何ですか。
納品後、社内担当者が保守できる資料は何が残りますか。
この質問に具体的に答えられない場合、そのベンダーが悪いとは限りません。
ただ、AI利用を前提にした進行管理がまだ整っていない可能性があります。
発注側は、見積金額だけでなく、回答の具体性を比較材料にしてください。
複数ベンダー案件のナレッジ管理
AI時代の開発では、知識の管理が見積の成否を左右します。
複数ベンダーが関わる案件では、要件、議事録、設計判断、API仕様、障害対応、未決事項が別々の場所に散ります。
AIを使うほど、過去の判断を参照して作業を進める場面が増えるため、情報が散ったままだと誤った前提で実装が進みます。
知識を残す単位
発注側は、成果物だけでなく、判断の履歴を残す単位を決める必要があります。
なぜこの仕様にしたのか。
どの案を採用しなかったのか。
どのAPI制約を前提にしたのか。
誰が承認したのか。
この情報が残っていないと、保守や追加開発のたびに同じ確認が発生します。
経済産業省のレガシーシステムモダン化に関するレポートでも、既存システムが新しいデジタル技術導入の障害になる問題が扱われています。
開発見積でも同じで、既存システムを知らないままAIで速く作っても、接続、移行、運用で止まります。
AI時代ほど、古い仕様と新しい実装をつなぐ知識管理が必要です。
AIに読ませる前の整理
AIにプロジェクト情報を読ませるなら、先に情報の正と権限を決めます。
最新版の仕様書、課題管理、議事録、設計資料、テスト結果がどこにあり、誰が更新するのか。
ここを決めずにAI検索や要約を始めると、古い資料を根拠にした回答が混ざります。
Phinxが複数ベンダーにまたがるプロジェクトで重視するのも、この部分です。
AIを使った進行管理やナレッジベース構築は、ツール導入だけでは成立しません。
発注側、PM、開発チームが同じ前提を見られる状態を作ってから、AIを使う方が安定します。
関連記事
生成AIやAIエージェントを業務で使うには、ツール選定より先に、自社のデータ、業務文書、会話、KPI定義、権限をAIが安全に参照できる状態へ整える必要があります。 この記事では、従来のBI・DWH中心のデータ統合基盤と、AI時代に必要なデータ・ナレッジ基盤の違いを、経営者と実務担当者の双方が判断できる形で解説します。
よくある失敗
AI時代の開発見積でよくある失敗は、見積金額の比較だけで発注先を決めることです。
特に、社内に技術判断を担う人が少ない企業では、安い見積ほど魅力的に見えます。
しかし、抜けた作業は消えるのではなく、発注側の会議、確認、差し戻し、保守負荷として戻ります。
AIで安くなる前提だけを置く
最も危ないのは、AIで実装が速くなるから総額も下がる、という前提だけで予算を組むことです。
実装初稿が速くなっても、業務部門の確認、既存データの整理、権限設計、受け入れテストが残るなら、総額は大きく下がりません。
むしろ、レビュー体制が弱いままAI生成物を増やすと、手戻りが増えることがあります。
見積段階では、AIで短縮する工程と、短縮しない工程を分けて書いてもらうべきです。
「AI活用により効率化」とだけ書かれた見積は、社内説明に使いにくい。
どの工程が何時間減り、その代わりにどのレビューが必要になるかまで聞くと、発注側も予算の妥当性を説明できます。
成果物だけで発注する
もう1つの失敗は、成果物だけを指定して、運用開始後の扱いを決めないことです。
画面、API、バッチ、管理機能が納品されても、社内担当者が仕様を理解できなければ、次の改修でまた外部依存になります。
AIを使った開発では、コード量が増える速度も上がるため、説明資料と保守方針を後回しにすると負債が増えます。
発注側は、納品物に運用手順、権限一覧、主要な設計判断、テスト観点、既知の制約を含めるか確認してください。
この項目は派手ではありませんが、半年後の追加開発で効いてきます。
まとめ
AI時代の開発見積は、人月モデルを捨てる話ではなく、人月だけでは読めない部分を分解する設計課題です。
実装初稿、調査、テスト作成はAIで短くなる一方で、要件判断、既存システム調整、レビュー、検収、運用引き継ぎは人が担います。
発注側が見るべきなのは、人数と単価だけではありません。
どの不確実性を誰が引き受け、どの成果物に責任を持ち、変更が出たときにどう扱うかです。
成功条件は、見積項目を工程別に分けること、AI利用とレビュー責任を契約前に確認すること、判断履歴と仕様を社内に残すことです。
この3つがないまま発注すると、安く見える見積ほど社内の確認負荷が増えます。
内製で判断できる企業は、ベンダーをうまく使えます。
一方で、社内にPM、テックリード、業務設計の役割が不足している場合は、見積比較そのものが属人化しやすくなります。
Phinx（フィンクス）は、課題整理、要件定義、AIを使った開発プロセス、海外開発チームを含む体制設計まで一貫して支援します。
日本側の顧客理解と、AI-nativeな開発・Global Deliveryの実務を組み合わせ、見積の妥当性を実装前から判断できる状態を作ることが、Phinxの強みです。
出典
IPA「AIを用いたソフトウェア開発」 https://www.ipa.go.jp/digital/ai/software-engineering.html
経済産業省「レガシーシステム脱却に向けた『レガシーシステムモダン化委員会総括レポート』を取りまとめました」 https://www.meti.go.jp/press/2025/05/20250528003/20250528003.html
DORA「Accelerate State of DevOps Report 2024」 https://dora.dev/research/2024/dora-report/
GitHub Blog「Research: quantifying GitHub Copilot’s impact on developer productivity and happiness」 https://github.blog/news-insights/research/research-quantifying-github-copilots-impact-on-developer-productivity-and-happiness/
Stay up-to-date
関連記事
