生成AI時代、SIerは人月ビジネスからどう脱却するべきか
工数販売の限界と、新たなビジネスモデルへの転換を本気で考える
はじめに
生成AIの進化によって、SIerを取り巻く環境は大きく変わりつつあります。
コード生成、設計支援、テストケース作成、ドキュメント要約、問い合わせ対応など、従来は人手を前提としていた作業の多くが、AIによって高速化・省力化できるようになりました。
一見すると、これはSIerにとって追い風に見えます。
しかし、ここにひとつ大きな矛盾があります。
人月ビジネスを前提としたままでは、生産性が上がるほど売上が下がるという矛盾です。
この問題は、単に「AIをどう使うか」という話ではありません。
本質的には、SIerがこれまで何に対してお金をもらってきたのか、そしてこれから何を価値として売るべきなのかという、商売の根本に関わる問いです。
この記事では、生成AI時代においてSIerが直面する構造変化を整理しながら、従来の人月ビジネスの限界と、その先にある新しいビジネスモデルの方向性を掘り下げていきます。
人月ビジネスの問題は、AIによって初めて生まれたわけではない
まず押さえておきたいのは、人月ビジネスの問題は生成AI登場以前から存在していたということです。
従来のSIerは、多くの場合「何人を何ヶ月アサインするか」によって売上が決まる構造でした。
このモデルでは、成果物の価値よりも、投入した工数の大きさが取引の基準になります。
この構造には、以前から次のような問題がありました。
- 価値ではなく投入量で課金するため、成果との対応が曖昧になる
- 効率化すると売上が減るため、生産性向上へのインセンティブが弱い
- 再利用や標準化よりも、個別対応のほうが売上を作りやすい
- 顧客は完成物ではなく「大手が多人数で関わっている安心感」にお金を払いやすい
特に最後の点は見落とされがちです。
多くの顧客は、システムの中身を完全に評価できるわけではありません。
そのため、「大手SIerが何十人も体制を組んでいる」という事実そのものが、安心材料として機能してきました。
つまり人月ビジネスとは、単なる課金方式ではなく、不確実性を吸収するための“安心パッケージ”でもあったわけです。
だからこそ、単純に「人月をやめて成果報酬にすればいい」という話にはなりません。
顧客が人月に求めていた安心・責任分散・変更吸収の機能を、別の形で再設計しなければならないからです。
生成AIはSIerの何を壊し、何を残すのか
生成AIによって、SIerの価値の置き所は確実に変わります。
生成AIで相対価値が下がるもの
まず、以下のような領域は今後どんどん価値が圧縮されていきます。
- コーディングそのもの
- ドキュメント作成のたたき台づくり
- 調査・要約・パターン適用
- 初級〜中級SEによる単純作業の時間売り
- テストケース案や設計書の雛形作成
これらは完全に不要になるわけではありません。
ただし、希少性が下がり、単価が維持しにくくなるのはほぼ確実です。
むしろ価値が増すもの
一方で、生成AI時代でも、むしろ重要性が増す領域があります。
- 問題設定
- 要件の構造化
- 業務モデル設計
- アーキテクチャ設計
- 品質保証
- セキュリティ・監査・統制設計
- 複数部門・複数システム横断の調整
- 顧客組織への導入・定着支援
- 導入後の継続改善
要するに、これから価値が高まるのは、単に作る力ではなく、決める力・つなぐ力・背負う力です。
生成AIが得意なのは、既に定義された問題に対して候補を大量に出すことです。
しかし、そもそも何を解くべきか、どの要件を優先すべきか、どこで責任を持つべきかまでは自動で決まりません。
その意味で、生成AI時代のSIerに求められるのは「開発会社」であることよりも、複雑な変化を設計し、業務成果に接続できる実装責任者であることです。
人月からの転換先は「成果報酬」だけではない
このテーマになると、よく「人月ビジネスをやめて成果報酬に移行するべきだ」という意見が出ます。
しかし、これはかなり雑な議論です。
現実には、人月と成果報酬の間にはさまざまなモデルがあり、案件特性や顧客成熟度によって適切な形は異なります。
生成AI時代において、SIerが取り得る新たなビジネスモデルは、大きく分けると次の5類型に整理できます。
1. 高速受託型
AIと標準化で短納期・固定価格を実現するモデル
もっとも分かりやすい転換先がこれです。
生成AIを活用して、要件整理、設計、実装、テストを効率化し、従来よりも短納期・低工数で開発する。
そのうえで、固定価格で案件を受け、効率化による差分を利益に変えるモデルです。
ただし、ここで勘違いしてはいけません。
AIを入れただけでは固定価格型は成立しません。
固定価格で利益を出すには、以下の条件が必要です。
- スコープが比較的明確であること
- 類似案件の再利用資産があること
- 変更管理ルールが強いこと
- 技術的不確実性が低いこと
- 顧客の意思決定が速いこと
つまり、このモデルで勝つにはAIだけでなく、標準化・契約統制・営業段階での見極めが必要です。
営業が何でも受け、現場が都度吸収する文化のままでは、固定価格化はただの赤字請負になります。
2. アセット提供型
共通部品や基盤を商品化し、再利用で稼ぐモデル
多くのSI案件には、実は毎回似たような部品や課題があります。
- 権限制御
- ログ管理
- ワークフロー
- マスタ管理
- AIの監査対応
- プロンプト管理
- RAGの権限制御
- テスト設計支援
- 仕様差分チェック
こうした「どの会社でも困る共通の面倒くささ」を、モジュールやサービスとして切り出して販売するのがアセット提供型です。
このモデルの魅力は、案件ごとの労働投入ではなく、再利用できる資産そのものが売上の源泉になることです。
ただし、このモデルにも罠があります。
SIerは個別案件文化が強く、短期売上に引っ張られやすいため、プロダクト投資が後回しになりがちです。
また、「何を共通化すべきか」の見極めが甘いと、顧客固有の業務を無理に商品化しようとして失敗します。
商品化に向いているのは、業務のど真ん中よりも、周辺の共通課題です。
ここを見誤ると、作っただけで売れない“社内自己満足プロダクト”になります。
3. 運用伴走型
AIを導入して終わりではなく、育て続けるモデル
生成AIは、一度入れて終わりのシステムとは相性がよくありません。
導入後も、
- ナレッジの鮮度維持
- 回答精度の評価
- ガードレール調整
- 利用ログ監査
- ユースケース追加
- プロンプト改善
- モデル選定見直し
など、継続的な改善が必要です。
ここに着目すると、SIerの価値は「導入」よりも、導入後の運用・改善支援に移っていきます。
これは従来の保守運用と似ているようで、本質的には違います。
従来保守が“現状維持”中心だったのに対し、AI運用は価値を伸ばし続けるための運用だからです。
このモデルの強みは、ストック型の収益になりやすいことです。
一方で、責任分界を曖昧にすると危険です。
例えば、AIの誤回答による業務事故が起きたときに、どこまでがSIer責任で、どこからが顧客責任なのか。
ここを契約と運用ルールの両方で明確にしておかないと、継続収益どころか継続炎上になります。
4. 内製化支援型
顧客の自走を前提に、標準化・統制・難所を支援するモデル
AI時代になると、顧客はスピードを求めて一定の内製化を進めます。
これはほぼ避けられません。
ここでSIerが「内製化されたら仕事が減る」と考えるなら、それは人月依存の発想です。
本来考えるべきは、顧客が自走するほど、より高度な課題で選ばれる存在になれるかです。
このモデルでSIerが提供する価値は、単なる教育ではありません。
- CoE立ち上げ支援
- AI活用ガイドライン整備
- 標準アーキテクチャ策定
- 利用審査フロー整備
- 難易度の高い案件への伴走
- 品質・統制の仕組みづくり
つまり、「全部作る」ではなく、顧客が安全に速く自走できる仕組みを設計することに価値が移ります。
教育研修だけで終わると収益性は弱いですが、統制基盤と高度案件支援を組み合わせることで、十分に戦えるモデルになります。
5. 業務代行高度化型
BPOとAIを組み合わせて、業務処理そのものを請けるモデル
もう一段踏み込んだ進化先として、BPOとAIを組み合わせる形もあります。
たとえば、
- 問い合わせ一次受付
- 見積書作成支援
- 契約チェック補助
- 文書分類・登録
- マニュアル検索支援
- 業務オペレーション支援
など、特定業務の一部をSIer側が請け負い、その中にAIを組み込んで効率化するモデルです。
これは開発受託よりも顧客成果に近く、高付加価値化しやすい一方で、責任も重くなります。
業務品質、SLA、誤判断時の責任など、設計難度は高いです。
そのため、すべてのSIerに向くわけではありません。
ただ、業務理解が深く、運用体制を持てる会社にとっては有力な方向性です。
なぜ多くのSIerは転換できないのか
ここまで読んで、「方向性はわかった。でも現実にはなかなか変わらない」と感じた人も多いはずです。
その感覚は正しいです。
なぜなら、人月依存は単なる意識の問題ではなく、組織設計の問題だからです。
多くのSIerでは、次のような構造が根強く残っています。
- 営業は受注額で評価される
- 現場は稼働率で管理される
- 個別案件対応のほうが短期売上を作りやすい
- 標準化投資は短期損益を悪化させる
- 優秀な人ほど火消し案件に投入される
- プロダクトや事業責任者のキャリアが弱い
- 契約・購買・法務も従来型に最適化されている
この状態で「AIを活用して変革しよう」と言っても、現場は結局、人月を最大化する行動に戻ります。
つまり本当の課題は、AI活用不足ではなく、AI時代に適した事業構造へ組み替えられていないことです。
顧客は何を買っているのかを見直す必要がある
SIerが次の商売を考えるうえで重要なのは、顧客が本当に買っているものを見誤らないことです。
顧客は、単にシステムを作ってほしいわけではありません。
特にAI領域では、次のようなものを求めています。
- 失敗しない導入設計
- 社内説明や合意形成の支援
- 安全とスピードの両立
- 導入後に成果へつながる運用
- 責任の線引きが明確な支援体制
つまり顧客が買っているのは、「AI」そのものではなく、AIを使える状態にし、その状態を維持・拡張できることです。
この理解がないまま「AI受託開発サービス」を売っても、差別化は難しくなります。
生成AI時代にSIerが変えるべきKPI
ビジネスモデルを変えたいなら、当然KPIも変えなければなりません。
従来の「受注額」「稼働率」「人月消化」だけを見ている限り、現場は旧来型の行動を続けます。
これから重視すべき指標は、たとえば以下のようなものです。
営業KPI
- 粗利率
- ストック売上比率
- PoCから本番化への転換率
- 既存顧客での横展開件数
- 再利用資産活用率
開発KPI
- 標準化率
- 再現性ある生産性改善
- 品質事故率
- 本番定着率
- ナレッジ資産化件数
経営KPI
- 人月売上依存度
- ストック売上比率
- 高付加価値案件比率
- 顧客LTV
- 共通資産再利用率
測るものを変えない限り、行動は変わりません。
そして行動が変わらない限り、ビジネスモデルの転換は起きません。
では、どこから着手すべきか
最後に、実行の優先順位を整理します。
全部大事に見えるテーマですが、順番を間違えると失敗します。
生成AI時代にSIerが本気で転換するなら、優先順位は次の通りです。
1. どの進化先で戦うか決める
高速受託型なのか、運用伴走型なのか、アセット提供型なのか。
全部やろうとすると、結局どれも中途半端になります。
2. 捨てる案件を決める
標準化不能、責任分界不明、変更管理不能な案件を減らさなければ、構造は変わりません。
3. 再利用資産を作る
AI活用の小技ではなく、実際に案件で使い回せるテンプレート、評価基盤、監査仕組み、標準プロセスを整備します。
4. 契約と価格体系を変える
準委任一本ではなく、固定価格、共同運用、サブスク、成果連動ボーナスなどを組み合わせて設計する必要があります。
5. 営業と評価制度を変える
受注額至上主義のままでは、現場は旧来案件を取り続けます。
6. 人材育成を作り変える
AIの使い方研修だけでは足りません。
業務設計、レビュー、品質、統制、全体設計を教える必要があります。
まとめ
生成AIはSIerの仕事を奪うのではなく、価値の低い仕事を選別する
ここまでの内容を一言でまとめるなら、こうなります。
生成AIは、SIerの仕事を奪うのではない。価値の低い仕事しかしていないSIerを選別する。
従来の人月ビジネスは、AIによって初めて問題化したわけではありません。
もともと抱えていた構造的な弱点が、生成AIによって一気に露呈しただけです。
だから必要なのは、単なるAI導入ではありません。
- 何を価値として売るのか
- どこまで責任を持つのか
- 顧客の何を支援するのか
- どの形で継続収益に変えるのか
- そのために組織とKPIをどう変えるのか
ここまで踏み込んで初めて、SIerは次の時代に適応できます。
今後、SIerに残る価値は「工数の提供」ではなく、
複雑さを制御し、変化を設計し、成果へつなげる責任を引き受けることです。
人月ビジネスの延命を続けるのか。
それとも、AI時代にふさわしい商売へ進化するのか。
問われているのは、技術力だけではありません。
商売そのものを変える覚悟があるかどうかです。
おわりに
生成AI時代のSIerは、単なる“開発会社”のままでは厳しくなります。
一方で、問題設定、業務設計、統制、導入定着、継続改善まで担える会社には、むしろ大きな機会があります。
これから必要なのは、「AIを使って速く作ること」だけではありません。
AIを前提に、顧客の変化能力そのものを設計することです。
この視点を持てるかどうかが、今後の分かれ目になるはずです。
WRITTEN BY
コメント