AI駆動開発 2026年8月22日

人月で稼ぐSIerは、あと数年で詰む——「作る会社」から「保証する会社」へ

何の話か：「作る工数」が売れなくなる時代

SIerのビジネスモデルが、構造的に成立しなくなる——。

そういう話は以前からあった。ただ、「いつか」の話として処理されてきた。自律型AIエージェントの実用化が進む今、その「いつか」に具体的な期限が迫りつつある。

シンプルな話だ。SIerはこれまで、必要な人数と期間を見積もり、その工数を「人月」として売ってきた。10人月の仕事なら10人月分の売上になる。ところが、AIによって同じ仕事が3人月で完成できるようになれば、請求できる工数は減る。開発生産性の向上が、そのまま売上の減少につながる。これが人月モデルの根本矛盾だ。

ツールを入れ替えれば解決する話ではない。問題は収益の構造そのものにある。

「SaaSの死」はSIerへの予告でもあった

2026年2月、SaaS関連銘柄から48時間で約2,850億ドルの時価総額が消えた。引き金は、自律型AIエージェントが複数ステップからなる業務ワークフローを最後まで完遂できることが広く実証されたことだった。これが「SaaSの死」として報じられた出来事だ。

ただ、SaaSそのものが消えるわけではない。変わるのは「SaaSを誰が、どのように使うか」だ。人間が画面を操作することを前提に発展してきたSaaSは、今後、AIエージェントが利用することも前提に設計し直す必要がある。

ここで重要なのは、この変化がソフトウェアを「使う側」だけの話ではないという点だ。現在、すでにシステム開発の工程にもAIが組み込まれている。AIは、ソフトウェアを「利用する工程」と「開発する工程」の両方に入り込んでいる。

前者はSaaSのように「人間が操作すること」を前提としたビジネスを揺さぶる。後者は、「ソフトウェアは人間が作るもの」を前提としてきたSIerの受託開発ビジネス全体を揺さぶる。「SaaSの死」騒動は、SIerへの予告でもあった。

人月モデルの構造的な限界

人月モデルが抱える矛盾は、シンプルだが深い。

AIによって開発生産性が上がれば、顧客にとっては開発期間が短くなり、コストも下がる。一見いいことだ。しかしSIerにとっては、請求できる工数が減る。生産性を上げれば上げるほど、売上が下がる構造になっている。

これは単に「効率が上がった」という話ではない。ビジネスモデルの根幹が、AI活用と真っ向から衝突しているということだ。

さらに厄介なのは、現場がAIで生産性を高めようとしても、会社の評価制度や営業の価格設定が「どれだけ人を投入したか」を前提にしていれば、AIを使うほど社内で不利になるという逆説が生まれることだ。現場の努力が、組織の仕組みによって無効化される。

ここからは見方だが——構造として何が起きているか

この問題を「AIを使えるかどうか」のスキル論として捉えると、本質を見誤る。

問われているのは、AIが前提の収益構造に変えられるかどうかだ。ツールを導入して「やっている感」を出しながら、人月で請求する構造は何も変えない——これが最も危ういパターンだ。

そして、ここには皮肉な逆説がある。人月ビジネスに最適化してきた仕組み——多くの開発者を抱えること、工数を正確に管理すること、外注先を確保すること——は、その当時は合理的だった。問題は、AIによって開発の前提が変わった後も、その「合理性」をそのまま持ち込もうとすることにある。

かつての強みが、変革の障害になる。これはSIerに限った話ではないが、人月への依存度が高い業態ほど、この構造的な摩擦は大きくなる。

SIerが獲得すべき4つの新しい価値

では、「作ること」の価値が下がるなら、何を売ればいいのか。元記事では4つの軸が整理されている。

1. 人月ではなく、成果で稼ぐ

業務時間をどれだけ短縮したか、コストをどれだけ削減したか、売上や生産性をどれだけ高めたか。開発にかかった工数ではなく、顧客に生み出した事業価値で稼ぐモデルへの転換だ。これは収益の再設計であり、営業・契約・評価制度の全体に影響する。

2. 実装ではなく、仕様定義とアーキテクチャで差がつく

コード生成やテストをAIが担うようになれば、「どう実装するか」だけでは差がつきにくくなる。一方で、顧客の曖昧な要求を整理し、AI・SaaS・既存システムをどう組み合わせるかを設計する能力の重要性は高まる。上流への移行は以前から言われてきたが、AIによってその必要性は加速する。

3. AIを安全に使う仕組みを提供する

AIが業務の一部を担うようになれば、「何ができるか」だけでなく「何をさせてよいか」が重要になる。どのデータへのアクセスを許可するか、どこまで自律的な操作を認めるか、AIの判断をどう監査するか。AIガバナンスの設計は、単なるセキュリティ対策ではなく、新しい上流の仕事として立ち上がりつつある。

4. 責任そのものを価値にする

AIによって顧客企業自身がシステムを作りやすくなっても、すべてのリスクを自社で引き受けられるとは限らない。障害が起きたとき、データ漏洩が起きたとき、AIが誤った判断をしたとき——誰が対応し、説明するのか。法人としての信用と責任を引き受けることが、価値になる。AIそのものは、この責任を取らない。

変えなければならない「古い合理性」

新しい能力を身につけるだけでは足りない。人月を前提として最適化されてきた仕組みそのものを問い直す必要がある。元記事では、見直すべき領域として「人員構成」「組織・ビジネスモデル」「開発環境」の3つが挙げられている。

人員構成については、「多くの人を配置して開発する」こと自体の価値が下がる。少人数で設計し、AIを使って実装する組織への転換が必要になる。工数・進捗管理を中心とした管理職の役割も、成果物の品質やAI活用を判断できる能力へのシフトが求められる。

組織・ビジネスモデルについては、営業での工数ではなく成果への価格設定、評価制度での稼働率ではなく少ない工数で大きな成果を出した人材への評価、そして多重下請け構造から少人数チームによる開発体制への移行が必要だ。

開発環境については、セキュリティ要件を理由に閉じた開発環境を維持してきた現場では、AI活用そのものが妨げられるケースがある。安全性を維持しながらAIを利用できる環境への再設計が必要になる。

重要なのは、これらを「古いから捨てる」という話として捉えないことだ。前提が変わった後も合理的かを問い直す、という姿勢の問題だ。

実務的な示唆：誰が何を考えるべきか

エンジニア・開発者の視点から言えば、「コードを書けること」の差別化力は確実に下がる。問われるのは、AIを使って少ない工数で設計から実装まで回せること、顧客の業務を理解して仕様に落とし込めること、そして生成されたコードの品質を判断できることだ。上流とAI活用の両方に足を置ける人材は、相対的に希少になっていく。

プロジェクトマネージャー・PMの視点からは、「工数管理」から「成果管理」へのシフトが迫られる。進捗をフェーズ単位で管理するモデルは、AI駆動の開発では機能しにくくなる。何をもって「完了」とするか、顧客との合意の仕方そのものを変える必要がある。

経営層の視点からは、最も難しい問いが待っている。人月を前提に積み上げてきた評価制度・営業構造・パートナー関係を、どのタイミングで、どのように解体・再設計するか。現場が変わっても、仕組みが変わらなければ矛盾が積み上がる。

次に注目すべき論点は「成果連動モデルの契約設計」だ。成果で稼ぐという方向性は正しいとして、「成果をどう定義し、どう測定し、誰が責任を持つか」という契約・法務・会計の問題は、まだほとんど整理されていない。ここが埋まらないと、実務レベルでの移行は進まない。