第14回 AI時代にSIerの人月モデルはどう変わるのか 〜生産性向上が利益を破壊する矛盾〜

AIで開発は速くなる。本来それはSIerにとって追い風のはずだ。にもかかわらず、人月モデルのままでは、速く作れる会社ほど売上が下がる。 AIが生産性を上げるほど、なぜSIerは苦しくなるのか。本稿で問いたいのは、人月モデルの是非ではない。AIによって価値の単位が変わるとき、SIerは何に対して価格をつける会社へ変わるべきか、である。この連載では、第11回で現場定着、第12回で若手育成、第13回で品質保証を扱ってきた。今回はその延長として、AI時代に人月モデルがどう変わらざるを得ないのかを考えたい。私自身、個人開発「FootballSync」をアーキテクト兼プログラマーとして進めるなかで、同じ機能をAIで一気に作れてしまうほど、「この仕事の値段は何で説明できるのか」と考えさせられてきた。その実感を下敷きにしている。

第1章　AIで生産性が上がるほど、なぜSIerは苦しくなるのか

AI駆動開発によって、開発現場の作業速度は確実に変わり始めている。実装、テストコード作成、調査、ドキュメント作成、レビュー補助、障害調査の初動。これまで人が時間をかけて行っていた作業の一部は、生成AIによって短時間でたたき台を作れるようになった。

もちろん、AIがすべてを正しく判断してくれるわけではない。生成されたコードや設計案をそのまま本番品質として扱うことはできない。業務理解、非機能要件、セキュリティ、保守性、責任分界といった領域では、依然として人間の判断が必要である。それでも、開発の一部が高速化していること自体は、もはや否定しにくい。

一見すると、これはSIerにとっても明確な追い風に見える。より速く作れる。より少ない人数で対応できる。提案のたたき台も、設計資料も、テスト観点も、従来より短い時間で準備できる。顧客から見ても、開発期間の短縮、コスト抑制、変更対応の高速化、改善サイクルの短縮といった期待がある。つまり、AIによる生産性向上は、顧客にとっては基本的に歓迎すべき変化である。

しかし、ここにSIer特有の難しさがある。人月を前提に売上を作っているSIerでは、生産性向上がそのまま利益向上につながるとは限らない。

なぜなら、人月モデルでは、売上の根拠が「成果の大きさ」ではなく「投入した人数と時間」に置かれやすいからである。開発が速くなるということは、必要な工数が減るということでもある。そして工数が減るということは、人月を売上の根拠にしている会社にとっては、請求できる工数そのものが小さくなることを意味する。

顧客から見れば、同じ成果物をより短期間・少人数で作れることは望ましい。だが従来型SIerから見ると、それは売上期間の短縮であり、投入人数の減少であり、請求できる工数の縮小でもある。つまり、顧客価値の向上と、従来型SIerの売上最大化が、同じ方向を向かなくなる。

もちろん、人月モデルそのものが直ちに不要になるわけではない。要件が不確実な案件、探索的なプロジェクト、顧客側の意思決定が流動的な初期フェーズでは、投入時間を価格の根拠にする考え方が残る場面もある。問題は、人月を唯一の利益源泉として扱い続けることにある。速く作れるにもかかわらず従来通りの工数を前提に見積もり続ければ、顧客からの信頼を失う。一方で、その速さを単なる工数削減として還元するだけでは、売上は縮小する。

では、SIerは何を売る会社であるべきなのか。人を増やして売上を増やす会社なのか。作業時間を積み上げて価格を説明する会社なのか。それとも、少人数でも高い判断価値と開発能力を提供する会社へ変わるのか。第14回では、この問いを出発点に、AI駆動開発と人月モデルの衝突を整理していく。

AIは作業時間を減らす。しかし人月モデルは、その作業時間を売上に変えている。だから生産性向上は、人月のままでは利益ではなく売上縮小として表面化するのである。

第2章　人月モデルとは、何を売っているモデルなのか

人月モデルは、単に「人数×時間」で価格を決める仕組みとして語られることが多い。何人が、何か月稼働するのか。そこに人月単価を掛け合わせて案件金額を算出する。SIerの世界では、非常になじみのある考え方である。

しかし、人月モデルを「人の時間を売るモデル」とだけ捉えると、本質を少し見誤る。実際の見積では、いきなり人数と期間を決めるわけではない。その前段には、ソフトウェアの規模を見積もるプロセスがある。画面数、帳票数、バッチ数、インターフェース数、機能数、STEP数、ファンクションポイント、類似案件との比較。こうした指標でまず作るものの規模を見積もり、その規模をプログラマの生産性や工程別の標準工数に当てはめ、必要工数へ変換する。

つまり人月モデルとは、規模を見積もり、生産性で割り、必要工数に変換し、その工数を人月として価格化する、という一連の構造である。この構造によって、ソフトウェア開発の価格は説明されてきた。本連載の第1回で扱った多重下請け構造も、突き詰めれば、投入人数と工数を価格の根拠にするこの人月モデルの上に成り立っていた。

ここには、AIが登場する前から大きな矛盾があった。たとえば、同じ機能を実現するプログラムで、ある会社は冗長なコードで1万STEPを書き、別の会社は設計を整理して5千STEPで実現したとする。本来、後者の方が技術力は高い可能性がある。コード量が少なく、保守しやすく、変更にも強く、バグの混入余地も小さいかもしれない。少ないコードで同じ価値を実現できることは、むしろ優れた設計・実装能力の証明である。しかし、STEP数を規模の根拠にすると、後者の方が「小さい仕事」に見えてしまう。効率的に作れる会社ほど、見積上は安く見えるのである。

この矛盾の根は深い。本来、ソフトウェアの価値は、書かれたコードの量で決まるわけではない。顧客の業務をどれだけ改善したか。売上や利益にどれだけ貢献したか。業務リスクをどれだけ下げたか。将来の保守性や変更容易性をどれだけ高めたか。そうしたもので価値は決まるはずである。

しかし、それらの価値を事前に測定し、顧客と合意し、価格に変換することは難しい。業務改善効果は顧客側の運用に依存する。売上向上は市場環境や営業活動にも左右される。保守性や変更容易性の価値は将来にならなければ見えにくい。リスク低減の価値も、問題が起きなかったことの価値として測りにくい。だから業界は長く、価値そのものではなく、その代理指標を使って価格を説明してきた。機能数、画面数、STEP数、工程別工数、人月単価。これらは、本来測りたい価値そのものではなく、価値を直接測れないために使われてきた代理指標である。

もちろん、この構造を単純に批判することはできない。人月モデルが今日まで残ってきたのは、SIerが古い商習慣に固執してきたからだけではない。人月以外の価値算出方法を、業界が十分に発明できていないからでもある。成果報酬は理想的に見えるが、成果の定義は難しく、外部環境の影響も受け、効果測定にも時間がかかる。成果物単位の価格設定は、仕様変更に弱く、スコープ定義が難しく、責任分界も曖昧になりやすい。だからこそ、最も説明しやすく、最も合意しやすい指標として、人月が残り続けてきた。

AI駆動開発が突きつけている問題は、まったく新しい問題ではない。以前から、効率的に作れる会社ほどSTEP数や工数が少なくなり、価格が低く見えやすいという矛盾は存在していた。AIは、その矛盾をさらに極端にしただけである。人が数週間かけて作っていたものをAIで数日で作れるようになったとき、成果物の価値は下がったのだろうか。本来は下がっていない。むしろ、顧客により早く価値を届けられる能力は高まっている。だが、人月で価格を説明すると、短時間で終わった仕事は小さな仕事に見えてしまう。ここに、AI時代のSIerが直面する根本的な価格算定問題がある。

人月モデルは、人の時間だけを売っているのではない。ソフトウェアの価値を直接測れないために、規模と工数を代理指標として売ってきたモデルなのである。

第3章　AIは工数を減らすだけではなく、価値の単位を変える

AIがまず短縮しているのは、作業時間である。実装のたたき台を作る。テストコードを生成する。調査結果を要約する。ドキュメントの初稿を作る。既存コードを読み解く。レビュー観点を洗い出す。これらは従来、人が一定の時間をかけて行っていた作業であり、その一部は明らかに短時間で処理できるようになった。

ここで重要なのは、工数が減ることと、価値が減ることを分けて考えることである。AIを活用して1週間かかっていた機能を1日で作れるようになったとき、その機能の価値は5分の1になったのだろうか。本来はそうではない。その機能が顧客の業務を改善し、ミスを減らし、意思決定を速くするのであれば、顧客にとっての価値は作業時間だけでは決まらない。むしろ、早く使えるようになることで、価値提供のタイミングは前倒しされる。減ったのは価値ではなく、価値を届けるまでに必要だった作業時間である。前章で述べたとおり、工数は価値そのものではなく、価値を説明するために使ってきた代理指標にすぎない。

では、AIによって価値が下がるのは何か。それは、判断をほとんど伴わない作業時間である。仕様をそのままコードに写す。既存パターンに沿ってテストケースを並べる。調査結果を要約する。定型的なドキュメントを整える。既知のエラーに既知の対応を行う。こうした作業はなくならないが、人が長時間をかけること自体の価値は下がっていく。

一方で、価値が高まる領域もある。何を作るのか。何を作らないのか。どの技術を選ぶのか。どの品質リスクを許容し、どのリスクは許容しないのか。どこまで自動化し、どこから人間が確認するのか。顧客に対して、どこまでを責任範囲として説明するのか。これらは、AIが作業を速くするほど、むしろ重要になる。AIは実装案を出し、テスト観点を並べ、設計方針の候補を提示できる。しかし、その中から何を採用し、何を捨て、どのリスクを受け入れ、どこに責任を持つのかは、人間が判断しなければならない。

AI生成物を使うほど、判断責任は軽くなるのではなく、むしろ前面に出てくる。そのコードは業務要件を満たしているのか。非機能要件に耐えられるのか。セキュリティ上問題ないのか。既存システムと整合しているのか。障害が起きたときに説明できるのか。AIが作ったから仕方ない、とは言えない。顧客に納品する以上、最終的な説明責任と品質責任は人間側に残る。AIによって作業は軽くなるが、判断の重さはむしろ増していく。

つまり、AIは工数を減らすだけではない。開発における価値の単位を変えている。これまで価格の根拠になりやすかったのは、作業量、工数、稼働時間だった。しかしAI時代には、価格に反映すべき価値が作業量の外側へ移っていく。価値の中心は、判断、設計、統合、責任へ移る。人間側に残る価値は、何を作るべきか、どう作るべきか、どこまで責任を持つべきかを決める力に集約されていく。

ここで、人月モデルとの衝突が起きる。人月モデルは作業量を価格に変換するモデルである。一方、AIは作業量を減らし、価値を意思決定側へ移していく。

AIが減らすのは工数であって、価値ではない。AI時代の開発価値は、作業時間ではなく、意思決定の質に宿るのである。

第4章　速く作れる会社ほど売上が下がるという逆説

AIをうまく使える会社ほど、同じ成果物をより少人数で、より短期間に作れるようになる。本来であれば、これは大きな競争優位である。顧客にとっては、開発期間が短くなり、コストも下がり、早く使い始められ、投資回収も早まる。しかし人月モデルでは、この生産性向上がそのまま売上増につながるとは限らない。むしろ、従来の価格モデルのままでは、売上縮小として表面化する。

たとえば、従来なら10人で6か月かかる案件があったとする。工数は60人月であり、人月単価を基準にすれば、この60人月が売上の根拠になる。ところがAI駆動開発によって、同じ成果物を5人で3か月、15人月で作れるようになったとする。顧客から見れば、これは明らかに良い話である。半分の人数と期間で成果物を得られ、システムを早く使い始められる。しかし人月モデルのSIerから見れば、60人月で売上化できていた仕事が15人月に圧縮される。単価が同じなら、売上は4分の1になる。ここで起きているのは、顧客価値とSIer売上の分離である。顧客価値は上がっている。しかし、人月売上は下がっている。

私自身、FootballSyncで、以前なら設計から実装、テストまで数日かけていた機能を、AIを使って半日ほどで形にできたことがあった。動くものは同じで、むしろ設計は整理され、テストも付いている。だが、もしこれが受注案件で、従来の工数見積のまま請求していたら、と考えると落ち着かなかった。速く作れたことは、この成果物の価値が下がったことを意味しない。にもかかわらず、人月で説明しようとした瞬間、それは「小さな仕事」に見えてしまう。個人開発ですらこの違和感があるのだから、顧客と工数で価格を合意する受注開発では、ズレはもっと鋭く表れる。

さらに厄介なのは、工数が4分の1になっても、責任が4分の1になるわけではないことである。AIを使って短期間で作ったとしても、顧客に納品する以上、要件を満たす責任、品質を担保する責任、非機能要件を満たす責任、セキュリティ上の問題を防ぐ責任、障害発生時に説明する責任は残る。プロジェクト管理も、顧客調整も、リリース判断も、リスク管理も不要にはならない。むしろAI生成物を使うほど、どの成果物を採用し、どこまで人間が確認し、どのリスクを許容するのかという判断は重くなる。

つまり、減っているのは主に作業時間である。減っていないのは、判断価値であり、品質責任であり、顧客に対する説明責任である。ここに人月モデルの限界がある。減った作業時間は価格に反映されやすい。実装工数が減った、テスト作成工数が減った、だから必要人月も減る。ここまでは説明しやすい。しかし、残った判断責任や品質保証責任は価格に反映されにくい。高度な業務理解、技術選定、アーキテクチャ判断、AI生成物の検証、顧客との合意形成。これらは作業時間としては短縮されても、価値として消えるわけではない。むしろ、少人数・短期間で高品質な成果を出すには、より高い判断力が必要になる。

AI駆動開発に成功する会社ほど、少人数・短期間で成果を出せるようになる。だが人月モデルのままでは、その能力は売上拡大ではなく、売上縮小として表面化する。問題は生産性向上そのものではない。生産性向上によって生まれた価値を、従来の人月モデルでは利益に変換しにくいことにある。では、この矛盾は契約形態を変えれば解決するのか。次章では、準委任、請負、成果報酬という観点から整理したい。

速く作れる会社ほど、従来の人月モデルでは売上が下がる。減っているのは作業時間であって、判断価値でも品質責任でも説明責任でもないのである。

第5章　準委任・請負・成果報酬はこの矛盾を解決できるのか

ここまで読むと、当然こう考えたくなる。人月モデルがAI時代に合わないのであれば、契約形態を変えればよいのではないか。準委任ではなく請負にする。あるいは成果報酬にする。作業時間ではなく、成果物や成果に対して価格をつける。そうすれば、AIで工数が減っても価値に対して対価を得られるのではないか。この方向性は間違っていない。しかし、契約形態を変えればすべて解決するかというと、話はそれほど単純ではない。

まず準委任である。準委任は、不確実性の高い開発とは相性がよい。要件が固まりきっていない、顧客側の意思決定が変わる、途中で優先順位が変わるといった状況では、最初から成果物を固定し価格を決め切ることは難しい。特に日本のSIでは、顧客の業務要件が開発開始時点で完全に整理されていないことも多く、開発を進めながら要件を詰めていく準委任には一定の合理性がある。しかし準委任は、価格説明が「何人が何か月稼働したか」に引き戻されやすい。作業が速くなっても、稼働時間を根拠にする限り人月モデルの矛盾は残る。作業時間が減れば請求工数も減り、売上を維持しようとすれば本来必要のない稼働を前提にせざるを得なくなる。つまり準委任は、不確実性には強いが、AIによる生産性向上を利益に変換しにくい。

次に請負である。請負は一見AI時代と相性がよい。成果物に対して価格を決めるため、短期間で作れる会社は生産性向上分を利益として取り込みやすい。従来60人月かかっていた成果物を15人月で作れるようになっても、価格が成果物単位で合意されていれば、短縮された工数分は受注側の利益になる。しかし請負にすればすべて解決するわけではない。仕様変更、責任分界、品質保証、非機能要件、受入基準の曖昧さといったリスクが残る。特に、要件が十分に固まっていない案件を請負化すると、受注側が過大なリスクを抱えやすい。AIで速く作れるとしても、何を作るべきかが曖昧なままでは、短期間で間違ったものを作るだけになる。早く作ったことは、責任が軽くなることを意味しない。請負は、生産性向上を利益化しやすい一方で、責任リスクを受注側に寄せやすい。

では成果報酬はどうか。成果報酬は最も理想に近いように見える。工数ではなく、顧客にもたらした成果に対して価格をつける。売上が上がった、業務時間が削減された、リードタイムが短縮された、障害件数が減った。こうした成果に対して対価を得られるのであれば、人月ではなく価値に基づいた価格設定に近づく。しかし成果報酬にも難しさがある。まず成果の定義が難しい。売上が上がったとして、それはシステムの効果なのか、営業施策の効果なのか、市場環境の影響なのか。業務時間が減ったとして、それはシステムの効果なのか、運用変更や現場努力の効果なのか。システム開発だけで成果が決まるわけではなく、顧客側の業務改革、教育、現場定着にも大きく左右される。また、成果をどの期間で測るのかという問題もある。受注側だけで成果をコントロールできない以上、成果報酬は理想的である一方、実務上の設計が難しい。

契約形態の議論とは別に、もっと単純な問いも成り立つ。契約はそのままに、人月単価そのものを引き上げればよいのではないか、という問いである。60人月が15人月に圧縮されるなら、単価を4倍にすれば売上は数字の上では維持できる。しかしこれは、価格の対象を作業時間のままにして、その数字だけを大きくする発想にすぎない。AIがさらに進化し工数がさらに減るたびに単価を上げ続けることはできず、いずれ市場が受け入れる単価の天井にぶつかる。しかも、顧客が自社でCopilotなどを使い始め、AIによる効率化を実感し始めている状況で、「速くなったので単価を上げます」という説明は通りにくい。速さの恩恵を顧客が一切受け取れないまま単価だけが上がれば、信頼を損ないかねない。単価が結果として上がることがあり得るとすれば、それは投入する人材の構成が変わり、定型作業を担っていた層が減って判断業務を担う層の比率が増えたときである。しかしそれは単価を引き上げたのではなく、売っているものの中身が変わった結果にすぎない。次章以降で扱う意思決定価値への価格移行と、実質的に同じ話である。

こうして見ると、準委任は不確実性に対応しやすいが稼働時間に戻りやすい。請負は生産性向上を利益化しやすいが仕様変更や品質保証のリスクを抱える。成果報酬は顧客価値と価格を結び付けやすいが成果定義と測定が難しい。単価そのものを引き上げる発想も、代理指標の数字を大きくするだけで、顧客交渉と持続可能性の両面で限界がある。つまり、問題は契約名だけではない。どれか一つを選べば、AI時代の価格問題が自動的に解決するわけではない。

本質は、何を価値と定義し、何に対して価格をつけるかである。AIによって短縮される作業時間ではなく、AI時代にも残り続ける判断価値、設計価値、品質責任、説明責任、成果創出能力をどう価格化するのか。価格をつける対象を変える必要がある。実装量ではなく意思決定支援。作業時間ではなく設計責任。稼働体制ではなく品質保証。単なる人員提供ではなく、AIを前提にした開発能力そのもの。契約形態を変えることは確かに必要になる。しかしそれだけでは足りない。それができないまま人月売上を守ろうとすると、AI活用そのものが歪み始める。次章では、その組織的な副作用を整理したい。

契約形態を変えることは必要だが、それだけでは足りない。価格の根拠を作業時間から価値へ移さない限り、人月モデルの矛盾は別の形で残り続けるのである。

第6章　人月モデルを守ろうとすると、AI活用は歪む

前章で述べたように、契約形態を変えるだけでは矛盾は解決しない。重要なのは契約名ではなく、何を価値と定義し、何に対して価格をつけるかである。しかしその価値定義を変えないまま従来の人月売上を守ろうとすると、AI活用そのものが歪み始める。工数削減が売上削減として表面化するため、組織には自然に人月売上を守ろうとする力学が働く。これは個人の善悪の問題ではない。売上構造が変わらない限り、組織としては合理的にそう動いてしまう。

まず起きるのは、過剰な体制である。AIを使えば3人で進められる仕事に、従来と同じように5人、7人を配置する。工程ごとに担当者を分け、役割を細分化し、稼働率を維持する。短期的には、それで売上を守れるかもしれない。しかし顧客から見れば、本当にその人数が必要なのかという疑問が生まれる。

実際、現場では顧客側の変化も始まっている。顧客が自社でCopilotやChatGPTを使い、簡単なコードや調査資料を作るようになると、見積の人数や期間に対して「AIを使えばもっと少なくできるのではないか」「なぜ従来と同じ工数がかかるのか」という問いが自然に出てくる。顧客がAI活用に慣れるほど、この違和感は強くなる。この問いに答えられないまま従来の体制を組み続ければ、信頼は少しずつ削れていく。

次に起きるのは、AI活用を限定的にすることである。AIツールは導入する。個人の作業効率化には使う。しかし、見積、契約、体制、工程設計には反映しない。その結果、AIは開発プロセスを変えるものではなく、現場の努力で工数を吸収するための補助ツールに閉じ込められる。AIを使っているのに、プロジェクトの組み方も、見積の考え方も、顧客に提供する価値の定義も変わらない。これはAI導入ではあっても、AI前提の開発ではない。

さらに、工数削減が現場努力として吸収される。AIで作業が速くなっても、その削減分が価格設計や契約に反映されなければ、現場には同じ期間、同じ体制、同じ契約金額のまま、より多くの成果が求められる。生産性が上がったはずなのに、現場は楽にならない。むしろ「AIを使っているのだからもっとできるはずだ」という圧力が増えていく。本来、AIによる生産性向上は、設計を見直す時間、品質を確認する時間、顧客と議論する時間、若手に判断経験を積ませる時間を生み出すはずである。しかし人月売上を守る構造のままでは、その余力は追加対応に吸収される。AI活用が、組織能力の向上ではなく、現場負荷の増加につながってしまう。

若手や下請けにも歪みが生まれる。AIによって、従来は若手や下請けが担っていた単純実装、テスト作成、ドキュメント作成、調査作業の多くは圧縮される。本来なら、若手にもAIを使わせ、生成物をレビューさせ、小さな判断を任せ、より早い段階から設計や品質の観点を学ばせるべきである。しかし人月売上や稼働率を維持しようとすると、旧来型の作業を人に残す力学が働く。単純作業を残せば稼働は作れるが、その経験はAI時代の開発能力にはつながりにくい。第12回で論じた若手育成の観点から見ても、これは深刻である。短期的には稼働を埋められても、長期的には、若手がAI前提の開発経験を積めず、下請け構造も旧来型作業に固定され、組織としてのAI Native化は遅れていく。

そして最終的には、顧客からの信頼を失う。人月売上を守るためにAI活用を限定すれば、短期的には売上を維持できるかもしれない。しかし長期的には、AIを本当に使いこなしている会社ではなく、従来の売上構造を守るためにAIを表面的に使っている会社に見えてしまう。AI活用を阻むものは、技術的な未成熟だけではない。むしろ大きいのは、収益構造である。

人月売上を守ろうとするほど、AI活用は本来の方向から歪む。これはAI技術の問題ではなく、生産性向上を収益に変換できない収益構造の問題なのである。

第7章　SIerの利益源泉は、作業量から意思決定価値へ移る

では、SIerは何を利益源泉にすべきなのか。結論から言えば、作業量ではなく、意思決定価値である。前章までに見たとおり、AIが相対的に価値を下げるのは判断を伴わない作業時間であり、価値が高まるのは判断を伴う領域である。何を作るべきか。どの技術を選ぶべきか。どの品質リスクを許容すべきか。どこまでをSIerの責任範囲として顧客と合意するべきか。AIが作業を速くするほど、こうした意思決定の価値はむしろ高まる。

まず価値が高まるのは、業務理解と要件整理である。AIは文章を要約し、仕様案を作り、議事録から論点を抽出できる。しかし、顧客の業務のどこに本当の問題があり、何をシステム化すべきで、何を作らないべきかを決めることは、依然として人間の判断である。言われたものをそのまま作るだけならAIによって価値は下がっていく。しかし、顧客の要求の背景を読み解き、業務上の制約を整理し、優先順位をつけ、システム化すべき範囲を判断する価値は下がらない。AIで実装が速くなるほど、何を作るべきかを間違えないことの重要性は高まる。

次に価値が高まるのは、システム全体設計と技術選定である。AIは実装案や設計方針の候補を出せる。しかし、システム全体としてどの構成を採用し、どの技術を選び、どのリスクを引き受けるのかは人間が判断しなければならない。特にSIerが扱うシステムでは、既存資産、運用制約、セキュリティ、監査、将来保守性を無視できない。AIが提案した構成をそのまま採用すればよいわけではない。どの技術を採用し、どこを標準化し、将来の変更容易性をどこまで担保するか。こうした判断そのものが、SIerの価値になる。

非機能要件、品質、セキュリティの判断も重要になる。コードを速く作れることと、責任を持って運用できることは別である。性能要件を満たすのか。可用性をどう担保するのか。障害時にどう復旧するのか。監査に耐えられるのか。AI生成物を使うほど、その成果物が本当に本番運用に耐えられるのかを判断する責任は重くなる。第13回で述べたように、AIが品質を確認するほど、人間は「正しい前提と妥当な判断に基づくか」を保証する側へ回る。AIが作ったから問題が起きた、とは言えない。最終的な品質責任と説明責任はSIer側に残る。

さらに、AI活用プロセスそのものを設計する価値も高まる。どの工程でAIを使うのか。どの成果物をAIで生成するのか。どこで人間レビューを入れるのか。AI生成物の品質基準をどう定めるのか。顧客データをどう扱うのか。これは単なるツール利用ではなく、AI前提の開発プロセスを設計する仕事である。そしてもう一つ、顧客組織の変革支援も重要になる。AI駆動開発はSIer側だけで完結しない。顧客が従来通りの意思決定速度のままであれば、SIer側だけが速くなっても、顧客側の判断待ちがボトルネックになる。だからSIerの価値は、単にシステムを納品することにとどまらず、顧客がAIを使いながら業務とシステムを継続的に変え続けられる状態を作ることへ広がっていく。

ただし、意思決定価値とは単なる助言ではない。この設計でよいと判断する。この技術を採用すると決める。この品質基準ならリリースできると説明する。このリスクは許容できると顧客と合意する。そこには責任が伴う。SIerが利益を取るべきなのは、この判断と責任のセットである。AI時代には、作業量ではなく、意思決定密度で価格を考える必要がある。同じ10人日でも、単純な作業を積み上げる10人日と、重要な設計判断や品質判断を行う10人日では、価値がまったく違う。AIによって単純作業の時間が短縮されるほど、この差はより大きくなる。人月モデルは、この違いを十分に表現しにくい。では、この意思決定価値をどのように価格へ反映すべきなのか。次章では、AI時代の価格設計の方向性を整理したい。

AI時代のSIerの利益源泉は、作業量ではなく意思決定価値である。少人数でも高い判断価値を提供できる会社が強くなり、作業量だけを売る会社は生産性向上を利益に変換できないのである。

第8章　AI時代の価格設計はどう変わるべきか

まず前提として、人月を完全に否定する必要はない。要件が不確実な初期フェーズ、探索型のPoC、一定稼働が必要な運用保守では、人月的な考え方が残る場面もある。問題は、人月を使うことではなく、利益の中心を人月だけに置き続けることである。AI時代に変えるべきなのは、価格をつける対象である。従来は、実装工数、テスト工数、設計工数、稼働人員、契約期間が価格説明の中心になりやすかった。しかしAIによって、これらの作業時間は圧縮されていく。その一方で、意思決定支援、設計責任、品質保証、AI生成物の検証、AI活用プロセス設計、継続改善能力といった価値は残る。だから、価格をつける対象を作業時間から価値単位へ移していく必要がある。方向性は五つある。

一つ目は、月額伴走型である。これは単なる月額人月ではない。一定人数が一定時間稼働することへの対価ではなく、継続的な意思決定支援に対して価格をつける考え方である。顧客の優先順位を整理し、技術判断や品質判断を支援し、AI活用プロセスを改善し、業務とシステムの改善サイクルを回す。AI時代には、一度作って終わりではなく、業務とシステムを継続的に改善する価値が高まる。月額伴走型は、その継続的な判断支援に価格をつけるモデルである。

二つ目は、成果物単位・価値単位の価格設定である。AIによって短期間で作れるようになった成果物に対して、単純な工数ではなく、業務価値や再利用価値を含めて価格をつける。業務アプリ、自動化ツール、AI Agent、データ連携基盤、テスト生成基盤、標準プロンプト、標準Agentなどである。これらは作成にかかった時間だけで価値が決まるわけではない。顧客業務にどれだけ効くのか、複数案件で再利用できるのか、開発速度や品質をどれだけ改善するのか。そうした価値も価格に反映すべきである。ただし、成果物単位にすればすべて解決するわけではなく、仕様変更や品質保証の範囲も含めて設計する必要がある。

三つ目は、開発能力提供型である。これは人を提供するのではなく、AI前提の開発能力そのものを提供するモデルである。開発チーム、開発プロセス、標準テンプレート、品質保証の仕組み、AI活用ルール、Agent環境、レビュー基準、CI/CD、テスト自動化、継続改善の運営方式。こうしたものを組み合わせて、顧客が継続的にシステムを改善できる能力を提供する。従来の人月モデルでは人を何人出すかが中心だったが、AI時代に重要なのは、その人数がどのような開発能力を持ち、どのようなプロセスと基盤で成果を出せるかである。

四つ目は、AI活用基盤とガバナンス込みの提供である。AI時代には、単に速く作るだけでは足りない。安全に使えるか。再現性があるか。監査に耐えられるか。顧客データを適切に扱えるか。特に日本企業向けのSIでは、この領域の価値は大きい。共通プロンプト、Agentテンプレート、開発標準、レビュー基準、セキュリティルール、監査ログ、AI利用ガイドライン、品質保証プロセス。こうした基盤とガバナンスは、単なる付帯作業ではなく、AIを業務システム開発に組み込むための前提条件であり、価格に含めるべき価値になる。

五つ目は、継続改善契約と内製化支援である。AI時代には、顧客自身もAIを使って業務やシステムを改善するようになる。そのときSIerは、すべてを代行する会社ではなく、顧客の開発能力を高める会社へ変わる。顧客内製チームの立ち上げ、AI開発プロセス教育、開発標準整備、AI活用トレーニング、技術顧問的な支援。従来のSIerから見ると、顧客の内製化支援は自社の開発工数を減らす脅威に見えるかもしれない。しかしAI時代には、顧客の開発能力を高めること自体が価値になる。顧客が自走できる領域を増やし、SIerはより高度な判断、設計、品質保証、ガバナンス支援へ移っていく。それは工数を失うことではなく、価値の階層を上げることである。

ただし、正直に認めておくべき弱点がある。ここで挙げた意思決定価値もまた、成果報酬と同じく、事前に測定して顧客と合意することが難しい。「あなたの判断にいくら払えばよいのか」という問いには、簡単な答えがない。鋭い発注側なら「結局それも値付けできないのではないか」と返すだろう。その指摘は正しい。だからこそ、月額伴走型や開発能力提供型が持つ意味は大きい。これらは、単発で測りにくい判断価値を、継続的な関係の中で少しずつ価格化していく緩衝策になる。一度で値付けできない価値を、時間をかけて信頼と実績に変え、そのうえで価格へ反映する。人月が一回の見積で価値を確定しようとしたのに対し、AI時代の価格設計は、関係の継続の中で価値を確定していく方向へ寄せる必要がある。

AI時代に価格化すべきなのは、作業時間ではない。意思決定価値、品質保証、AI活用プロセス、開発能力、継続改善、内製化支援であり、それらは継続する関係の中で価格へ変えていくものなのである。

第9章　SIerは「人を増やす会社」から「開発能力を提供する会社」へ変わる

第14回では、AI時代にSIerの人月モデルがどう変わるのかを考えてきた。ここまでの流れを、最短で振り返っておきたい。

出発点は、AIで生産性が上がるほど、なぜSIerは苦しくなるのかという問いだった。人月モデルは、価値そのものではなく、規模、工数、稼働時間という代理指標を価格の根拠にしてきた。AIはその代理指標を揺さぶる。作業時間も必要工数も減り、少人数・短期間で同じ成果物を作れるようになる。しかし工数が減っても、顧客に提供する価値やSIerが負う責任まで同じように減るわけではない。その結果、速く作れる会社ほど従来の価格モデルでは売上が下がるという逆説が生まれる。契約形態を変えるだけでは解決せず、人月売上を守ろうとすればAI活用そのものが歪む。だからSIerは、利益源泉を作業量から意思決定価値へ移し、価格をつける対象を作業時間から価値単位へ変えていく必要がある――ここまでが本稿の骨格である。

この変化を一言で言えば、SIerが「人を増やす会社」から「開発能力を提供する会社」へ変わる、ということである。従来のSIerは、人を集め、期間を確保し、稼働率を高め、工数を積み上げることで売上を増やしてきた。その構造は人月モデルと相性がよかった。しかしAI時代には、少人数で高い成果を出せる会社ほど強くなる。人を増やすことそのものは、もはや競争力ではない。むしろ、少人数でも高い判断価値を提供できること、AIを前提にした開発プロセスを持っていること、品質保証とガバナンスを組み込めることが競争力になる。

これからSIerが提供すべきものは、人員そのものではなく、開発能力である。少人数でも成果を出せるチーム、AIを前提にした開発プロセス、品質保証とガバナンスの仕組み、Platform、MLOps、AI Governance、AI PMやAI Product Engineering、顧客内製チームとの連携、継続改善の運営方式。これらを組み合わせて、顧客がAIを使いながら業務とシステムを変え続けられる状態を提供することが、AI時代のSIerの価値になる。SIerは、作業代行業から、開発能力提供業へ変わっていく。

もちろん、人月モデルが明日から消えるわけではない。不確実性の高い初期フェーズ、探索的なPoC、運用保守、顧客常駐支援では、人月的な考え方が残る場面もある。人月を完全に否定する必要はない。しかし、人月は利益の中心ではなくなる。人月だけを利益の中心に置くモデルは、AIによる生産性向上を収益に変換できないからである。

最後に、この記事を読んだあなたへ一つだけ問いを残したい。自社は、人月以外に何を価格の根拠にできるのか。難しく考える必要はない。まずは手元の案件を一つ選び、「この仕事の価値は、投入した人数と時間以外の言葉で説明できるか」を書き出してみてほしい。意思決定価値も、品質保証も、開発能力も、言語化できなければ価格にはできない。その一文を書くことが、人月から抜け出す最初の一歩になる。

では、開発能力を提供する会社は、具体的にどのような開発の形を取るのか。人月を前提としない開発は、現場でどう回るのか。次回は、その具体像である「AI Native Delivery」を取り上げ、AIを前提にした開発の届け方そのものを考えたい。

AI時代のSIerは、人を増やして売上を増やす会社から、少人数で高い意思決定価値を提供する会社へ変わる。売るべきものは、人員ではなく、開発能力なのである。

本記事は「AI Native時代の開発組織論」シリーズの一部です。全記事は以下のマガジンにまとめています。
AI駆動開発に最適な組織についての考察