AI時代の受託開発は「人月」ではなく「意思決定の代行」に値段がつく

こんにちは、大平です。

最近、受託開発の見積もりについて相談されることが増えました。 AIで実装が速くなるなら、開発費も単純に安くなるのではないか、という話です。

結論から言うと、安くなる部分はあります。ただし、受託開発の価値が消えるわけではありません。むしろ価値の中心が、手を動かす時間から、「何を作り、何を作らず、どこまで責任を持つか」を決める力へ移っています。

なぜ人月モデルが苦しくなっているのか

人月モデルは、実装にかかる時間が価値の中心だった時代には説明しやすい価格体系でした。何人が何か月動くのかを積み上げれば、顧客も社内稟議も通しやすかったからです。

しかしAIで実装速度が上がると、この説明は弱くなります。 3日で書けるコードに1か月分の単価を乗せることは難しい。一方で、要件整理、仕様の切り分け、運用設計、リスク説明、関係者調整はほとんど短縮されません。 人月で売っていた会社ほど、価値の説明を作り直す必要があります。

AIで縮む工数と、まったく縮まない工数

AIで縮むのは、主に実装と初期ドラフトです。 CRUD画面、テストのたたき台、リファクタリング候補の洗い出しなどは、明らかに速くなっています。

しかしそれだけでは終わらないのがシステム開発という業務。

どの要件を捨てるか、どのリスクを許容するか、リリース後にどのような体制で誰が運用するかは、AIが代わりに決めてくれません。

ここは組織の事情、顧客との契約、事業上の優先順位が絡みます。 縮む工数と縮まない工数を分けずに見積もると、必ず期待値がズレます。

顧客が本当に買っているのは実装時間ではない

顧客が受託開発会社に払っているのは、厳密にはコードを書く時間だけではありません。失敗確率を下げること、社内で説明できる材料を作ること、知らない落とし穴を先に潰すことにもお金を払っています。

特にAI時代は、見た目だけ動くものは簡単に出せます。

だからこそ、顧客は「これは本番で運用できるのか」「法務やセキュリティに耐えられるのか」「半年後も直せるのか」という不安を持ちます。

売上が上がっていても、人は解消されない不安に対して耐えられないものなのです。

この不安を引き受けて「安心に変える」ことが、受託側の価値のコアになっていくでしょう。

見積は「作業量」ではなく「責任範囲」の時代へ

従来の見積業務では、画面数、API数、その機能の複雑さ、実装難易度などについて、それらの見積が積み上げ式で作られているという傾向がありました。

しかしこれからの時代ではこれだけでは不十分です。

むしろ、要件定義、仕様策定、テスト設計、セキュリティ確認、運用引き継ぎ、リリース後の改善支援といった責任範囲を明確にする必要があります。

顧客にとって重要なのは、何時間働くかより、どこまで任せられるかです。ここを見せられる会社は、AIで実装単価が下がっても価格競争に巻き込まれにくい。

顧客は「苦労して作る作業工程の賃金」よりも「業務上の不安が解消された状態」に対してお金を払う傾向はますます高まるでしょう。

受託開発の値付けは、作業量の販売から意思決定支援の販売へ移っています。

経営としてまずやるべきこと

まずやるべきなのは、見積もり項目を『作業』ではなく『判断』と『責任』に分解することです。

画面を作る、APIを作る、テストを書くという項目だけでは、AI時代の価値を説明しきれません。

たとえば、要件の優先順位を決める、リリース条件を定義する、障害時の責任分界を整理する、運用担当へ引き継ぐ。これらを見積もりに明記すると、顧客も何にお金を払っているのか理解しやすくなります。受託側も、単なる工数削減競争から抜け出しやすくなります。

なぜ今、この論点を避けられないのか

正直、今自社やクライアントワークの見積もりってすごく難しくなっていると思います。

背景には、AIによって「作ること」だけが急激に安く、速くなったことがあります。

以前は実装の重さが自然な制約になっていました。作る前に会議をし、仕様を固め、見積もりを出し、ようやく実装に入る。

その遅さ自体が、ある意味では過剰な変更を防ぐブレーキにもなっていました。

しかし今は、初期実装だけならすぐ形になります。だからこそ、人月で説明していた価値が、実装時間から責任範囲へ移るという視点が欠かせません。

作れるから作る、安いから作る、速いから進める、という判断では、リリース後の運用・品質・責任分界で必ず詰まりますし、そこで働く人はプロマネもエンジニアもみんな疲弊してしまうでしょう。

AI時代の開発では、作る前の判断が以前より重くなっています。

現場でよく起きる誤解。AIならゼロコストで出せるという錯覚

現場でよく見るのは、AIで安くなる部分だけを切り出して、要件定義・運用・説明責任を無料扱いしてしまうことです。これは悪意があって起きるというより、AIで見た目の進捗が出やすくなったことで、見えていない仕事が過小評価されるために起きます。

特に経営層と開発現場でズレやすいのは、「画面が動く」と「事業で使える」の距離です。画面が動くことは大事ですが、業務フローに乗る、例外に耐える、監査できる、担当者が引き継げる、顧客に説明できる、という条件を満たして初めて本番の価値になります。

会社で本当に価値検証フェーズにあるのであれば、ただ動くものを高速でリリースすれば良いのかもしれません。

しかし例えば、上場を見据えたベンチャー企業やすでに上場している大企業の場合、システム監査に耐える要件を設計していることは必須になります。そうでないと、そのシステムを継続使用することは不可能という結論になってしまいます。

この距離を見積もりに入れられるかどうかで、プロジェクトの成否は大きく変わります。

判断を間違えると、何が起きるか

判断を間違えると、短期的には速く進んでいるように見えます。打ち合わせではデモが動き、関係者も盛り上がり、社内では「AIでここまでできるならいける」と感じます。問題は、その後です。

本番データを入れた瞬間に例外が出る。権限設計が足りず、運用開始前に作り直しになる。問い合わせ対応の担当が決まっておらず、開発者がずっと呼ばれる。こうした問題は、コード量だけでは解決しません。むしろAIでコード量が増えるほど、説明できない範囲が広がることもあります。

だから、最初に決めるべきなのは「どこまで作るか」だけではありません。「どこまで責任を持つか」「どこから先は作らないか」「何が確認できたら次に進むか」まで含めた判断です。

経営・開発責任者が確認すべきチェックリスト

最低限、次の観点は最初に確認しておくべきです。

この取り組みの目的は、売上増加、コスト削減、品質改善、学習のどれなのか
成功条件は、誰が見ても判断できる形で書かれているか
リリース後の運用責任者は、名前で決まっているか
AIが生成した成果物を、誰がレビューし、誰が説明責任を持つのか
失敗した場合の撤退条件やロールバック方法はあるか
初期開発費だけでなく、保守・改善・問い合わせ対応の予算があるか
外部に任せる範囲と、社内に残す判断が分かれているか

このチェックリストを埋めるだけでも、プロジェクトの解像度はかなり上がります。すべて完璧に決める必要はありません。ただし、未定の項目を未定として認識することが重要です。未定を見ないふりして進めると、後で必ず現場の負荷になります。

小さく始めるなら、どこからか

いきなり全社導入や本番リリースを狙う必要はありません。まずは影響範囲の小さい業務、失敗しても顧客影響が小さい領域、既に担当者がオーナーシップを持って取り組める領域から始めるのが現実的です。

小さく始めるときも、単なるお試しで終わらせないことが大事です。目的、成功条件、改善すべきこと、責任者、次の判断タイミングを決めてください。

失敗しても「学び」が残ることが重要です。

逆に、何となく試しただけでは、良かったのか悪かったのか判断できず、次につながりません。

具体的なケースで考える

見積もり会議で「AIを使うならもっと安くなるはず」と言われた場面を想像すると、この論点は一気に現実味を帯びます。会議室では、AIで作ったデモが動いています。画面はきれいで、操作もできる。関係者の反応も悪くない。ここで「もうほとんどできていますね」と言いたくなる気持ちは分かります。

しかし、実際にはこの時点で確認できているのは、かなり限定された条件です。きれいな入力、想定通りの操作、限られたユーザー、短時間の確認。この外側に、本番業務で本当に問題になる領域があります。権限、例外、データ移行、監査、問い合わせ、改善要望、障害対応。これらはデモの場では見えにくいですが、運用開始後には必ず表に出ます。

たとえば、請求書承認ワークフローを考えると分かりやすいです。 AIを使えば、請求書一覧、承認ボタン、コメント、通知メールのような画面や処理はかなり速く作れます。デモだけなら、数日で「それっぽく動くもの」が出てくるかもしれません。

しかし本番で必要なのは、それだけではありません。月末締め後に差し戻された請求をどう扱うのか。承認者が不在のとき、誰が代理承認できるのか。金額修正の権限は現場にあるのか、経理にあるのか。会計システム連携に失敗した場合、誰が復旧し、どこまでログを残すのか。誤った値を連携した場合に、どの手順で修正・再連携するのか。

こうした論点は、AIがコードを速く書けるようになっても消えません。むしろ、画面がすぐできるからこそ、業務上の判断が後回しになりやすくなります。

だからこそ、受託開発の値付けでは「動いたか」ではなく「運用できるか」を見る必要があります。動いたものを否定する必要はありません。むしろ、動いたからこそ次の判断に進めます。ただし、その判断は祝勝会ではなく、本番に向けた棚卸しであるべきです。

だからこそ、リリースをゴールにせず、運用に載せるまでの準備を見積もりと計画に含める必要があります。

90日で整えるなら、何から始めるか

最初の30日は、現状把握に使うのが現実的です。既存の業務フロー、責任者、利用データ、外部サービス、手作業で吸収している例外を洗い出します。この段階では、無理に作り込まない方がいいです。作る前に、どこに判断の穴があるかを見ることが重要です。

次の30日は、小さな範囲で試します。対象部署を絞り、機能を絞り、失敗しても影響が限定される形で動かします。このとき、要件整理・受け入れ条件・運用引き継ぎ・説明責任を別項目にすることを必ず入れてください。 AIを使った開発では、試す速度は上がりますが、試した結果を次に活かす設計がなければ学習が残りません。

最後の30日は、継続運用に載せる準備です。担当者、レビュー手順、障害時の対応、改善要望の受付、予算枠を決めます。ここまで決めて初めて、AIで作ったものが一過性のデモではなく、組織の仕組みに近づきます。

社内で合意しておくべき言葉

プロジェクトが揉めるときは、言葉の定義が揃っていないことが多いです。「完成」「リリース」「内製」「AI活用」「保守」「責任」といった言葉を、関係者が別々の意味で使っています。

たとえば、経営層にとっての完成は「顧客に見せられる状態」かもしれません。開発現場にとっての完成は「異常系や監視まで含めて運用できる状態」かもしれません。このズレを放置すると、どちらも悪くないのに衝突します。

早い段階で、完成とは何か、誰が承認するのか、どこから保守フェーズなのかを言葉にしてください。これは面倒ですが、後の手戻りを大きく減らします。 AI時代は作る速度が上がった分、言葉のズレがそのまま大量の手戻りになります。

発注側と開発側で分担すべきこと

発注側が持つべきなのは、業務の目的、優先順位、責任者の決定です。ここは外部に丸投げできません。外部の開発会社や顧問は整理を手伝えますが、最終的に何を優先し、どのリスクを受け入れるかは発注側の判断です。

開発側が持つべきなのは、技術的な実現方法、リスクの提示、選択肢の整理です。ただ作るだけでなく、この進め方だとどこが危ないのか、別案にすると何を失うのかを説明する必要があります。

この分担が明確になると、AIは強力な道具になります。逆に、分担が曖昧なままAIだけ入れると、誰の判断なのか分からない成果物が増えます。 AIの出力は速いですが、責任の所在まで自動で整理してくれるわけではありません。

まとめ

AIで実装工数は縮むが、意思決定や責任分界は縮まらない
人月モデルだけでは、受託開発の価値を説明しにくくなる
見積もりでは作業量より責任範囲を明確にすべき

AIで開発の前提は変わりましたが、最後に問われるのは組織として何を判断し、どこに責任を置くかです。自社の現在地を一度整理してみてください。