第15回 AI Native Deliveryという新しいSIerモデル 〜受託開発はプロダクト型サービスへ近づく〜
前回（第14回）で、AIによって開発生産性が上がるほど、従来の人月モデルと矛盾が生じることを整理した。生産性が上がるほど売上が減る——このねじれから、AI時代のSIerは逃げられない。ではその先で、SIerは何を売るのか。本稿の答えを先に置く。AI時代のSIerが売るべきものは、人の稼働でも作業量でもない。顧客が変わり続けるための「変化対応力」である。 この一点を、提供価値・契約・内製化支援・提供体制の順に、AI Native Deliveryという新しいモデルとして描いていきたい。
第1章 人月モデルの先に、SIerは何を売るのか
これまでのSIerにとって、人月モデルは分かりやすい収益構造だった。何人を、何ヶ月、どの単価で投入するか。その積み上げで見積もりが作られ、契約が結ばれ、売上が立つ。顧客にとっても開発規模を人数と期間で把握でき、一定の納得感があった。大規模な基幹システムや複雑な業務システムでは多くの人手が必要で、要件定義から保守まで各工程に人が張り付く。その前提の中では、人月モデルは合理的なモデルだった。
しかしAI駆動開発はこの前提を揺さぶり始めている。実装もテストもドキュメントも調査もレビューも障害解析も、これまで人が時間をかけていた作業の多くが圧縮されていく。もちろんAIがすべてを自動化するわけではなく、判断・設計・レビュー・責任は依然として人間が担う。だが、同じ成果物に必要な作業量は確実に減る。
ここで問題が生じる。同じ成果を半分の人数・期間で出せるなら、人月を基礎にする限り生産性向上はそのまま売上減少の圧力になる。だからAI時代のSIerは、次の問いから逃げられない。速く作れるようになったSIerは、何で利益を出すのか。少人数化した開発チームは、何を価値として売るのか。顧客は、これからも「何人が何ヶ月働いたか」に対価を払い続けるのか。
私は、ここにSIerの大きな転換点があると考えている。売るべきものは、人の稼働でも作業量でもない。顧客が変化し続けるための開発能力である。ここで言う開発能力とは、単にプログラムを書く力ではない。AIを前提に業務を分析し、仮説を立て、素早く実装し、検証し、改善していく力であり、必要なときに作り、必要に応じて作り替え、変化に合わせて進化させ続ける力である。
顧客側の期待も変わる。これまでは「このシステムを作ってほしい」が中心だった。しかしAI時代には、顧客の業務も市場も必要なシステムも変わり続ける。納品時点で完成していることよりも、変化に合わせて改善し続けられることの方が重要になる。そう考えると、SIerの価値は消えるのではなく、置き場所が変わる。人をどれだけ投入できるかではなく、どれだけ速く変化に対応できるか。どれだけ作業を請け負えるかではなく、どれだけ顧客の意思決定と改善を支援できるか。
これからのSIerは、「作業量を売る会社」から「変化対応力を提供する会社」へ変わっていく。
では、従来のSIは何を前提にしていたのか。次章では、まず従来型SIが前提としてきた納品モデルを整理する。
第2章 従来型SIは「納品」をゴールにしていた
従来型SIは、基本的に「納品」をゴールにしたモデルだった。顧客が要望を出し、SIerが要件として整理し、設計・開発・テストを経て成果物として納品する。納品後は保守契約の範囲で障害対応や軽微な改修、安定稼働を支援する。この流れ自体は不自然ではない。開発には多くの人手が必要で、変更には大きなコストがかかり、品質を担保するには工程ごとに責任を分け、確認ポイントを設ける必要があった。契約上も、何を、どこまで作り、どの状態で検収するかを明確にする必要があった。
このモデルでのSIerの責任は「合意された範囲のものを、計画どおりに作ること」に置かれていた。検収されればプロジェクトはいったん完了し、その後はシステムを壊さず維持することが中心になる。つまり価値の中心は「変化し続けること」ではなく「決められたものを正しく作ること」にあった。業務要件が比較的固定され、開発速度に限界があり、顧客に十分な開発力がない状況では、これは十分に合理的だった。
しかしAI時代にはこの前提が変わる。AIによって実装・テスト・ドキュメント・調査・レビュー・設計支援が高速化するだけでなく、顧客側の業務もAI活用によって変化しやすくなる。人手の業務がAI Agentに置き換わり、業務フローが変わり、意思決定の速度が変わる。そうなると、システム要件は最初に決めたまま固定されるものではなくなる。納品時点で正しかった仕様が数ヶ月後には最適でなくなり、セキュリティやガバナンスの要件もAI利用の拡大とともに更新され続ける。
この環境では、納品時点で完成していることだけでは足りない。重要なのは、納品後も変化に合わせて作り替えられることだ。業務の変化を捉え、機能を見直し、AI Agentやワークフローを改善し、データやガバナンスを継続的に整えていく。そうした変化対応力こそが、AI時代の開発における価値になる。
従来型SIは「決められたものを、決められた範囲で、決められた期日までに作る」モデルとして合理的だった。だがAI時代には、納品をゴールにするだけでは足りなくなる。
では、納品をゴールにしないSIerの提供モデルとは何か。それが、次章で扱うAI Native Deliveryである。
第3章 AI Native Deliveryとは何か
納品をゴールにしないSIerの提供モデルを、私はAI Native Deliveryと呼びたい。これは単にAIで開発を効率化することではない。AIで実装・テスト・ドキュメント・レビュー・障害解析を圧縮するのは重要な変化だが、それだけなら従来型SIを少し速く回しただけで、提供モデルそのものは変わらない。第1章で述べた「速く作れるようになった後、何を売るのか」への答えにはならない。
AI Native Deliveryとは、AIでシステムを作るだけでなく、顧客がAIを使って継続的に業務・プロダクト・システムを進化させるための開発能力を提供するモデルである。ここで重要なのは、AIを後付けの補助ツールとして扱わないことだ。従来型SIの工程の一部にAIを差し込み、設計書作成や実装やテストを「少し速くする」のは、既存プロセスの中にAIを配置する発想にすぎない。AI Native Deliveryでは、最初からAIを前提に開発プロセスを設計する。要件整理では業務課題や論点をAIで構造化し、設計では複数の実現案を高速に比較し、実装では人間とAIが短いサイクルで作って直し、テストでは異常系や境界値や非機能観点をAIで広げ、レビューではAIが網羅性を補助して人間が業務価値と責任の最終判断を行う。AI Native DeliveryにおいてAIは補助ツールではなく、開発プロセスそのものの前提である。
そのため、従来型のPMとは異なる役割も要る。私はそれをAI PMと捉えている。AI時代の開発では、進捗や課題の管理だけでは不十分になる。どの業務にAIを適用するか、どこまで自動化してよいか、どの判断を人間が担うか、AIの結果を誰がどの基準で評価するか、顧客の内製とSIerの責任範囲をどう切り分けるか。従来のPMが計画・進捗・課題・コスト・品質を管理する存在なら、AI PMはそれに加えて価値・不確実性・意思決定・責任境界を管理し、顧客の業務部門、開発チーム、Platform、Governanceをつなぐ。
さらにAI Native Deliveryは開発チームだけでは成立しない。共通Platformが要る。ここで言うPlatformとは単なるクラウド基盤ではなく、AI開発環境、Agent実行基盤、プロンプト管理、テスト自動化、ナレッジ管理、CI/CD、モニタリング、再利用可能なテンプレート群を含む開発能力の土台である。案件ごとにゼロから環境を作るのではなく、SIer自身が再利用可能な基盤を持ち、その上で顧客ごとに適用する。同時にGovernanceも最初から組み込む。速く作れるほどリスクも増えるからこそ、セキュリティ・品質・監査・権限管理・責任境界を後付けにしない。速く作ることと安全に使い続けることを分けて考えないのがAI Native Deliveryである。
そしてゴールは納品ではない。納品後も顧客が業務・プロダクト・システムを変え続けられる状態を作ることがゴールだ。業務プロセス、AI Agent、プロンプト、ワークフロー、データ品質、セキュリティルールを改善し続け、顧客の内製チームが自らAIを使って業務を変えられるよう支援する。この意味でAI Native Deliveryには顧客内製化支援も含まれる。従来のSIer視点では内製化は脅威に見えやすかったが、AI時代はむしろ逆で、顧客が自走できる状態を作ること自体がSIerの新しい価値になる。
AI Native Deliveryが提供するのは開発作業ではない。顧客がAIを使って、業務・プロダクト・システムを変え続けるための開発能力そのものである。
では、これは従来型SIと具体的に何が違うのか。次章で対比して整理したい。
第4章 AI Native Deliveryは、従来SIと何が違うのか
AI Native Deliveryという言葉は「AIを使った開発手法」と受け取られやすい。しかし違いは、AIツールを使うかどうかではない。従来型SIでも、設計書作成、コード生成、テストケース作成、議事録、調査にAIを使える。それらは有効だが、工程の考え方も、契約の単位も、責任範囲も、納品をゴールにする構造も変わらないなら、それは「AIを使った従来型SI」にすぎない。違いは、何を価値として提供するかにある。
従来型SIの価値の中心は「作ること」にあった。要件を整理し、仕様に落とし、設計・開発・テストして納品する。重要なのは成果物、スコープ、工数、納期、品質、検収条件であり、顧客の関心も「いつ・いくら・何人・要件どおりか・品質は担保されるか」に置かれていた。一方、AI Native Deliveryが提供するのは、顧客がAIを使いながら業務・プロダクト・システムを変え続けられる状態である。ここで重要なのは作業量ではなく変化対応力だ。業務も市場もAI活用も利用者の行動もデータの意味もガバナンス要件も変わる。その変化にどれだけ速く、安全に、継続的に対応できるか——そこに価値の中心が移る。
整理すると、両者の違いは次のようになる。
特に重要なのは、価値の源泉、ゴール、顧客との関係の3つだ。価値の源泉は、人月や工数から、顧客が変化に対応し・業務価値を見極め・優先順位を判断し・AIを安全に活用し・運用後も改善を続ける能力そのものへ移る。ゴールは納品から改善サイクルの開始点へ変わる。システムを使い始めて初めて見える業務課題、AI Agentを運用して初めて分かる改善点、利用データで初めて見えるプロセスの歪みを継続的に改善することまでが提供価値になる。顧客との関係も、発注者と受託者から共創パートナーへ近づく。顧客自身がAIで業務を見直し内製的に改善する力を持つとき、SIerは代わりにすべてを作る存在ではなく、顧客が変わり続けるための開発能力を一緒に作る存在になる。
この変化は契約や収益にも及ぶ。「この範囲を、いつまでに、いくらで作るか」から、継続改善、Platform利用、AI Agent運用、ガバナンス支援、内製化支援、レビュー・監査支援といった単位へ。一度作って終わりではなく、顧客が継続的に変化できる状態を維持し拡張することが価値になる。
AI Native Deliveryは従来型SIの効率化ではない。中心価値が「計画どおりに作ること」から「顧客が変わり続けられる状態を作ること」へ移る、モデルそのものの転換である。
この転換は、受託開発をプロダクト型サービスへ近づけていく。次章で詳しく見たい。
第5章 受託開発はプロダクト型サービスへ近づく
従来の受託開発は、顧客ごとの個別最適を前提にしていた。業務も既存システムも組織文化も承認フローもデータ構造もセキュリティ要件も顧客ごとに違うため、案件ごとに要件を整理し、設計・開発・テストして納品する形を取ってきた。社内に過去案件のノウハウや標準テンプレートはあっても、顧客に提供する中心価値はあくまで個別案件の成果物だった。このモデルでは、要望を仕様に落とし、人員を集め、計画どおり作り切る力が重要になる。
しかしAIを前提にすると、これまで案件ごとに個別に行っていた作業の一部を共通資産として再利用しやすくなる。コード生成・レビュー・テスト・ドキュメント・調査を支えるAI開発基盤は案件ごとにゼロから考える必要がない。要件整理・設計レビュー・テスト観点抽出・障害分析のための標準プロンプトも案件を超えて蓄積できる。セキュリティ・性能・保守性・業務整合性・権限管理・監査対応といったレビュー観点にも共通部分が多い。単体・結合・業務シナリオ・異常系・回帰といったテスト自動化テンプレートも、セキュリティ基準やガバナンスチェックリスト、業務分析フレーム、Agent活用パターン、開発プロセス標準も、SIer側の共通資産になっていく。
重要なのは、これらが単なる社内ノウハウにとどまらないことだ。AI Native Deliveryでは、こうした共通資産そのものが顧客への提供価値になる。従来型SIが主に売っていたのは要件定義・設計・開発・テスト・保守という作業だった。作業は今後もなくならないが、それだけを売るモデルではAI時代の価値を表現しきれない。SIerは「人を投入して作る会社」から「開発能力をサービスとして提供する会社」へ変わっていく。
ただしサービス化とは、受託開発がそのままSaaSやパッケージになるという意味ではない。業務も既存システムもデータも組織文化も規制要件も顧客ごとに異なり、個別性は必ず残る。重要なのは、共通化できるものと個別に適用すべきものを切り分けることだ。共通化できるものはSIer側の資産としてプロダクト化し、顧客固有のものはその資産を前提に個別適用する。たとえばAI Agentによる問い合わせ対応でも、業務やデータや権限は顧客ごとに異なるが、Agent設計の考え方、ログ監査、回答品質の評価方法、プロンプト改善のサイクル、エスカレーション設計は共通資産として蓄積できる。
こう考えると、AI時代のSIerの競争力は、案件でどれだけ人を投入できるかではなく、どれだけ質の高い共通資産を持っているかで決まる。AIツールを使えること自体はいずれ差別化要因ではなくなる。差がつくのは、AI前提の開発プロセスをどれだけ磨き込み、品質・セキュリティ・ガバナンスをどれだけ標準化し、顧客業務への適用知見をどれだけ蓄積し、Agent活用や継続改善の仕組みをどれだけ再現性のある形にできているかだ。競争力の源泉は、人員投入力から、組織として蓄積された開発能力へ移っていく。
顧客が買うものも変わる。従来は「何人で、何ヶ月で、いくらで作れるか」を問うことが多かったが、AI時代に顧客が本当に知りたいのは、どれだけ速く業務を変えられるか、AIを安全に使える状態を作れるか、納品後も改善し続けられるか、自社の社員もAIを使えるようになるか、将来的に内製化や共創につなげられるかだ。顧客は単なる開発チームではなく、自社がAIで変化し続けるための開発基盤を買うようになる。
受託開発はプロダクト型サービスへ近づく。ただしそれは個別性を無視することではなく、個別性に応えるために、SIerがより強い共通基盤を持つということである。
提供価値がこう変わるなら、契約のあり方も変わらざるを得ない。次章で継続改善型契約を考えたい。
第6章 継続改善型契約が重要になる
従来の受託開発では、契約の中心は「何を作って、いつまでに納品するか」だった。作る範囲・納期・工数・金額・成果物・検収条件を決めてプロジェクトが成立し、納品後は安定稼働の維持を中心とする保守契約に移る。障害対応、問い合わせ対応、軽微な改修、監視、定期メンテナンス——これらは重要な仕事であり、保守契約は従来型SIに欠かせない役割を担ってきた。
しかしAI Native Deliveryでは、納品後の意味が変わる。納品はゴールではなく改善の出発点になる。実際に使って初めて分かることがある。業務フローとのズレ、現場で使われない機能、AI Agentの回答品質、プロンプトの曖昧さ、データ品質の問題、権限設計の不備、例外処理の抜け漏れ、利用部門ごとの習熟度の差。これらは事前の要件定義や設計だけでは見切れない。特にAIを組み込んだ業務システムでは、運用後に改善すべき論点が必ず出てくる。回答精度を高め、プロンプトを調整し、ワークフローを見直し、人間とAIの役割分担を変え、データ品質を改善し、セキュリティルールを更新する——こうした活動は、従来の保守とは性質が違う。
この違いは、契約として整理すると分かりやすい。
もちろん保守が不要になるわけではない。安定稼働はどの時代でも重要で、障害対応や監視が軽視されてよいはずがない。しかしAI Native Deliveryでは、保守だけでは価値が足りない。顧客が求めるのは、システムが止まらないことだけではなく、業務が変わったときにシステムも変えられること、AI活用度を上げられること、現場の使い方に合わせて改善できること、新しい業務課題を次の開発テーマにつなげられることだ。継続改善型契約が扱う対象は、業務プロセス、AI Agent、プロンプト、ワークフロー、データ品質、セキュリティ・ガバナンスにまで及ぶ。単なる追加改修の定額契約ではなく、これらを継続的に改善するための契約である。
この契約モデルはSIerの収益構造も変える。大きなプロジェクトを受注・納品し保守へ移る形だけでなく、Platform利用、AI Agent運用支援、継続改善支援、ガバナンス支援、レビュー・監査支援、内製化支援、教育・伴走支援が、新しい継続収益の源泉になる。ただし注意点もある。成果物を定義するだけでは足りず、活動範囲・判断権限・責任境界を明確にする必要がある。AI Agentの出力責任は誰が持つのか、顧客が変更したプロンプトは誰がレビューするのか、内製チームが改修した部分の品質をどう担保するのか、監査対応はどこまで契約範囲か。これらを曖昧にしたままでは、継続改善は単なる作業追加になってしまう。だからこそ、何を作るかだけでなく、どのように改善し続けるか、誰が判断し誰が責任を持つかまで含めて、契約そのものを設計しなければならない。
そして継続改善を成立させる鍵は、顧客自身の参加である。SIerだけが改善を担うのではなく、業務部門も情報システム部門も現場の利用者もAIを使って改善に参加する。顧客がAIを使えるほど改善サイクルは速くなり、業務課題を自ら言語化できるほど開発の精度は上がり、小さな改善を内製で回せるほどSIerは高度な支援に集中できる。
保守は守り、継続改善は攻めである。そして顧客の内製化は、SIerの仕事を奪うのではなく、継続改善の価値を高める前提になる。
次章では、従来は脅威に見えた顧客内製化が、なぜAI時代には新しい商品になるのかを考えたい。
第7章 顧客内製化支援は、SIerの敵ではなく商品になる
従来型SIerにとって、顧客の内製化は脅威に見えやすかった。顧客が自分たちで要件を整理し、小さな改修や業務アプリを作り、自ら改善を回せるようになれば、依頼される仕事は減る——少なくとも人月モデルで見ればそう見える。顧客が自走するほど外部委託の範囲が狭まり、人月売上が減り、収益が落ちる。この構造では、顧客を自社に依存させた方が短期的には売上を維持しやすい。
しかしAI時代には、この考え方が大きく変わる。AIによって顧客側も開発や改善に参加しやすくなるからだ。業務部門はAIで業務課題を言語化でき、情報システム部門は要件のたたき台を作れ、現場担当者は業務フローを整理でき、簡単なプロトタイプは短時間で作れ、プロンプトを調整しながらAI Agentの使い方を改善できる。顧客は単なる発注者ではなく、自ら業務を見直し改善案を作り小さな変更を試す存在になる。AI Native Deliveryを前提にするなら、業務を最もよく知る顧客が改善に参加しない方がむしろ不自然だ。どの業務を変えるべきか、どの判断を自動化してよいか、どのデータを使ってよいかといった判断には、顧客側の業務知識が不可欠である。
これは他人事ではない。私自身、週末のサッカーコーチとして18人の子どもの出欠と出場時間の管理に困り、FootballSyncというアプリを作った。Flaskのデプロイも、さくらのサーバの制約（FreeBSD／Python 3.8）も、LINE Messaging APIも、本業で日常的に触るものではない。それでも、作りたい機能を言葉で伝えるとAIがコードの骨格を返す——いわゆるVibe Coding——で、チーム運営に実際に使えるところまで立ち上がった。このとき腹の底で理解した。「動くものを作る」の主導権は、専門技術ではなくドメインの深さのほうへ移りつつある、と。顧客もまた、自分の業務ドメインを誰よりよく知っている。足りなかった技術の壁をAIが下げている以上、「顧客が自分で作れるようになる」は精神論ではない。
ただし誤解してはいけない。顧客がAIを使えても、すべてを顧客だけで完結できるわけではない。プロトタイプや簡単な自動化、業務課題の整理は速くなるが、本番運用に耐えるシステムには、全体設計、既存システム連携、権限管理、セキュリティ、監査ログ、データ品質管理、障害時の責任分界、AI Agentの出力品質評価、ガバナンス・コンプライアンスとの接続が要る。つまりAI時代の内製化とは、顧客だけで全部作ることではない。顧客が自分たちで改善できる領域を広げ、そのうえでSIerが高度な設計・基盤・ガバナンス・運用・監査・共創領域を支えるモデルである。
ここに、SIerの新しい役割がある。従来型SIerは、顧客が分からない・作れない・運用できないことを自社側で抱え込み、その依存を売上につなげてきた面がある。しかしAI時代には、依存を維持するだけのSIerは弱くなる。顧客もAIで調査し整理し試作し改善できるからだ。取るべき方向は、顧客の自走を妨げることではなく、顧客が自走できる状態を設計することである。AI活用を教育し、業務部門の要件整理を支援し、市民開発のルールを設計し、内製チームの役割やプロセスを整え、AI開発Platformを提供し、生成物やプロンプトをレビューし、難易度の高い領域は共同で開発する。これが、AI時代の自走支援型SIerである。
重要なのは、内製化支援そのものが商品になる点だ。AI活用教育は単なる研修ではなく、業務部門や情報システム部門がAIを安全かつ実務的に使えるようにする支援である。内製チーム立ち上げ支援は、役割分担・開発プロセス・レビュー体制・品質基準・運営ルールまで設計する支援である。市民開発ガバナンスは、現場が小さく改善できる状態を保ちながらセキュリティ・品質・監査・責任境界を守る仕組みである。Platform提供は、AI Agent・ナレッジ・プロンプト・テスト・ログ・監査を含め、顧客が継続的に改善するための基盤である。レビュー・監査支援は、顧客が自走しながらも本番運用に耐える品質と安全性を維持するための支援である。
顧客が自走するほど、SIerは低付加価値な作業から離れ、より高度な領域に集中できる。業務課題の初期整理や簡単なプロトタイプ、小規模な自動化、日常的なプロンプト改善は顧客が担い、SIerは業務・技術・AIを統合した全体設計、本番運用に耐えるアーキテクチャ、基幹連携、データ品質とセキュリティ、AI Agentの品質評価、ガバナンス設計、MLOps／AIOps、レビュー・監査、継続改善の仕組みづくりに集中する。つまり顧客が自走するほどSIerの価値が下がるのではなく、担うべき領域が高度化する。
もちろん、すべてのSIerがこの変化に対応できるわけではない。単に人を出すだけ、依存で売上を維持してきた、標準化されたPlatformやGovernanceを持たない、AI活用を顧客に教えられないSIerにとって、顧客内製化は確かに脅威になる。一方、AI Native Deliveryを提供できるSIerにとって、内製化支援は新しい商品になる。
顧客内製化は、SIerの仕事を奪うものではない。顧客が自走できる状態を作ること自体が、AI Native Deliveryにおける重要な提供価値である。
では、この提供モデルを実現するには、SIer側にどんな機能が必要になるのか。次章で提供体制を整理したい。
第8章 AI PM・Platform・Governanceを含む提供モデルへ
AI Native Deliveryは、単なる開発チームの提供ではない。従来型SIでは案件ごとにPM・PL・SE・PG・テスター・インフラ・運用担当を集め、開発体制を組むのが中心だった。AI Native Deliveryでも開発チームは必要だが、それだけでは足りない。提供するものが単なる開発作業ではなく、顧客がAIを使って業務・プロダクト・システムを変え続けるための開発能力だからだ。必要になるのは、AI PM、AI Product Engineering、Platform、MLOps／AIOps、AI Governance、Educationを組み合わせた総合的な提供体制である。
中心になるのはAI PMだ。従来のPMが進捗・課題・コスト・品質・スコープを管理していたとすれば、AI PMはそれに加えて価値・不確実性・意思決定を管理する。どの業務にAIを適用するか、どの判断をAIに任せてよいか、どこに人間の確認を残すか、どの改善テーマを優先するか、どこまでを顧客が内製しどこからをSIerが担うか、AI Agentの出力責任やPlatform・Governanceとの接続をどう設計するか。AI PMは単なる進捗管理者ではなく、業務価値・AI活用の可能性・技術リスク・組織的制約を見ながら開発全体の意思決定を支える存在である。
次にAI Product Engineeringは、AI前提で価値を実装する機能だ。合意された仕様を設計・実装・テストすることは今後も必要だが、それだけでは足りない。業務価値を短いサイクルで検証し、AIでプロトタイプを素早く作り、顧客と動くものを見ながら改善し、AI生成コードを評価・修正し、テストやレビューやリファクタリングをAIと協働で進め、プロトタイプを本番運用に耐える形へ育てる。単なる実装部隊ではなく、顧客の業務改善テーマをAI前提で動く価値へ変換する機能である。
これを属人的な力にしないためにPlatformが要る。AI開発環境、Agent実行基盤、プロンプト管理、ナレッジ管理、テスト自動化、CI/CD、モニタリング、ログ管理、データ連携、標準テンプレート、レビュー観点、開発プロセス標準——これらがなければAI Native Deliveryは案件ごとの個別対応に戻ってしまう。Platformは、SIerの開発能力を属人知から再利用可能な組織資産へ変える土台である。
運用と改善を担うのがMLOps／AIOpsだ。AIを組み込んだシステムは作って終わりではない。AI Agentが期待どおり使われているか、回答品質は十分か、どんな質問で失敗するか、どの業務フローで滞留が起きるか、プロンプトは業務変化に追随しているか、データ品質や性能・障害の兆候はどうかを見続け、モデル・プロンプト・ワークフロー・データ・運用ルールを改善していく。これは第6章の継続改善型契約を支える実行基盤でもある。
AI活用が広がるほどリスクも増える。そこで要るのがAI Governanceだ。これはAI活用を止めるものではなく、安全に広げるためのガードレールである。AI利用ルール、データ利用ルール、権限管理、監査ログ、セキュリティ・品質基準、AI出力のレビュー基準、責任分界、コンプライアンス対応、市民開発の統制、顧客内製化範囲の管理。誰がAIの出力を確認するのか、どのデータを使ってよいのか、どこまで自動判断してよいのか、どの変更にレビューが要るのか——こうした問いに答える仕組みがGovernanceであり、速く作る力と安全に広げる力のうち後者を支える。
最後にEducationだ。第7章で述べたとおり、AI時代には顧客内製化支援そのものが商品になり、そのためには顧客がAIを使って改善に参加できる状態を作らねばならない。顧客社員へのAI活用教育、業務部門向けの要件整理トレーニング、情報システム部門向けのAI開発・運用教育、市民開発ルールの定着、プロンプト改善やAI Agent運用の教育、内製チームの立ち上げと継続改善サイクルの定着支援。Educationは顧客をSIerから切り離すためではなく、顧客とSIerがより高度な共創を行うための土台である。
これら6機能は、どれか一つでは足りない。AI PMがいても実装する力がなければ価値は生まれず、Product Engineeringが強くてもPlatformがなければ属人対応になり、PlatformがあってもGovernanceがなければ安全に広げられず、MLOps／AIOpsがなければ納品後の改善が続かず、Educationがなければ顧客は改善に参加できない。
AI Native Deliveryは個別機能の寄せ集めではない。顧客の変化能力を支えるために、6つの機能を統合した提供モデルである。
次章では、この議論を全体の結論としてまとめたい。
第9章 これからのSIerは、顧客の変化能力を提供する会社になる
第14回では、AI時代に人月モデルが抱える矛盾を整理した。AIで生産性が上がるほど、人を多く長く投入して売上を作るモデルは成立しにくくなる。しかしそれはSIerの価値がなくなるという意味ではなく、売るべき価値が変わるということである。第15回では、その先の新しい提供モデルとしてAI Native Deliveryを考えてきた。AIでシステムを速く作るだけでなく、顧客がAIで継続的に業務・プロダクト・システムを進化させるための開発能力を提供するモデルである。
この回で見てきたことを振り返る。SIerは作業量ではなく変化対応力を売る会社になる。納品をゴールにするだけでは不十分で、納品後も変化に合わせて作り替えられることの方が重要になる。受託開発はプロダクト型サービスへ近づき、AI開発基盤・標準プロンプト・レビュー観点・テスト自動化テンプレート・セキュリティ基準・ガバナンスチェックリスト・Agent活用パターン・開発プロセス標準がSIer側の共通資産になり、それを顧客ごとに適用・調整・改善することが新しい価値になる。契約の考え方も変わり、保守が「壊れないように維持する契約」なら、継続改善型契約は「顧客の業務能力を高め続ける契約」になる。そして顧客内製化支援も新しい商品になる。顧客を囲い込むのではなく自走できる状態を作り、そのうえでSIerは高度な設計・Platform・Governance・MLOps／AIOps・レビュー・監査・継続改善を担う。この関係は、発注者と受託者というより共創パートナーに近い。
それを実現するには提供体制も変わらなければならない。優秀なエンジニアを集めた開発チームだけでは足りず、AI PM、AI Product Engineering、Platform、MLOps／AIOps、AI Governance、Educationが組み合わさって初めてAI Native Deliveryは成立する。
この流れは連載全体のテーマにつながる。第1回ではAIによってSIerの多重下請け構造がどう変わるのかを、第14回では人月モデルそのものの矛盾を整理し、第15回ではその先の新しいSIerモデルとしてAI Native Deliveryを提示した。ここで見えてくるのは、SIerの役割が「作る会社」から「変わり続ける力を提供する会社」へ移るという変化である。
もちろん、システムを作る力は今後も必要だ。設計する力も、実装する力も、品質を担保する力も、運用する力も要り続ける。しかしそれだけでは十分ではない。AI時代に重要になるのは、顧客が自ら業務を見直し、AIを使い、改善に参加し、必要に応じてSIerと共創できる状態を作ることである。
AI時代にSIerが売るべきものは、人の稼働でも単発の納品物でもない。顧客が変わり続けるための能力である。これからのSIerは、システムを納品する会社ではなく、顧客の変化能力を提供する会社になる。
本記事は「AI Native時代の開発組織論」シリーズの一部です。全記事は以下のマガジンにまとめています。
AI駆動開発に最適な組織についての考察
