外注の手間で、
自分で作れてしまう。

SIer 委託は、これまで合理的だった。ソフトウェアを作るには、多分野にわたる優秀なソフトウェアエンジニアが要る ── 設計、データベース、フロントエンド、インフラ、セキュリティ。それを一社一社が社内に抱えて維持するのは、現実的でなかった。人材を一か所に集めて作る ── SIer に集中させるほうが、効率的だったのだ。

だが、その前提は反転した。優秀なエンジニアを、いまや AI として雇える。そして、顧客自身がビルダーになれる ── 1-05で示したとおり、汎用は OSS、足りない自社固有のロジックだけ AI と作ればよい。本章はその裏面 ── なぜ「SIer に頼んで楽になる」が幻想なのか ── を、委託プロセスの工程に分解して見ていく。

本章の眼目は、コストよりも構造にある。外注しても、上流の判断は顧客に残る。そのうえ委託は、責任と技術を空洞化させる。

SIer 委託モデルの罠

そもそも工程は、要件定義から始まらない。その前に、事務処理そのものをどう改善するかを考えねばならない ── 業務の流れ、承認のしかた、紙やルールの見直しまで、システム化以前の部分を含めて。何をシステムにすべきかは、その後で決まる。ここは顧客にしか分からず、SIer に丸投げできない。

しかも、その事務処理の改善は、システムで何ができるかを理解していなければ、うまくいかない。何を自動化でき、どこがデータで繋がるかが見えて初めて、業務の組み替え方が決まる。上流の判断ほど、システムの理解を要する ── だから、その理解こそ、社内に持たねばならない。

上流から実装までは、直線では進まない。作っては試し、見えたことで業務を組み替え、また作る。ループで回すしかない。

SIer には、これができない。一周ごとに予算の承認と契約が要り、普通は年単位になるからだ。業務システムをアジャイルで回せている現場が、ほとんどないのもそのためだ。予算と契約のゲートが、ループを禁じる。

だが、AI を使えば、このループを高速に回せる。実装はすぐ返る。時間がかかるのは、テストのほうだ。テストは、全部を自動化できない。動くかは自動で測れても、「本当に欲しかったものか」「業務に合うか」は、人が確かめるしかない。この検証こそ、外に出せない顧客の判断だ。

それでも一周は、SIer の一周(年単位)より桁違いに短い。何度でも回せる。これができるのは、AI を手元に持つ内製だけだ。

そのうえで、SIer 案件を一つ動かすには、こういう工程が要る:

• 要件定義 / RFP 作成 ── 顧客側で数週間〜数ヶ月。何を作るか、どのレベルで作るか、外部に出せる形に整理する作業
• ベンダー選定 ── 複数社の提案を取り寄せて比較、数週間〜数ヶ月
• 契約交渉 ── 法務、調達、SI 側との折衝、数週間
• プロジェクト管理 ── 案件期間中ずっと続く、顧客側 PM + SIer 側 PM の二重体制
• 検収・受入テスト ── 納品物が要件を満たすかの確認、数週間
• 運用保守の引き継ぎ ── 仕様の口頭伝達、ドキュメント授受、継続

これが本来の姿だ。だが現実には、この工程を省いて「SIer に任せた」で済ませてしまう。要件も、検収も、判断も、丸ごと相手に預ける。楽に見えて、ここから無責任化が始まる ── 後半で見るとおり、これが委託の最も深い問題だ。

委託は、責任を消し、技術を空洞化させる

委託の最も深い問題は、手間でもコストでもない。委託は、責任を消す。作る側と任せる側が分かれた瞬間、「これは誰の責任か」が宙に浮く。任せた側は「専門家に任せた」と言い、任された側は「仕様どおり作った」と言う。誰も、結果の全体を引き受けない ── これが無責任化だ。

そして無責任化は、技術の空洞化を呼ぶ。誰も責任を負わないものは、誰も育てない。作る力を外に出し続ければ、技術は自分の中に育たず、やがて出てきたものの良し悪しを見抜く力まで失う。

その最も高価な実例が、GitHub Copilot だ。Microsoft は AI の中核を自社で作らず、OpenAI に委ねた ── 作る力は OpenAI、製品の責任は Microsoft と、責任が二社に割れた。そしてその間、CEO のナデラは自社の基礎研究を細らせていった。Microsoft Research は産業界で最も権威ある基礎研究所の一つ ── チューリング賞受賞者を擁した ── だったが、CEO 就任初年の 2014 年に MSR シリコンバレー研究所を閉鎖(約 50 名)、2023 年には AI 倫理チームを丸ごと解体し、OpenAI のモデルを「最速で顧客に届ける」ことを優先した。長期の研究は、速度に置き換えられた。

技術が空洞化した組織は、初歩的な失敗を止められない。Copilot は、公開された GitHub のコードで学習した ── そこには優れたコードもあるが、 ゴミのようなコードも大量にある。何を学習させるかが出力を決めるのは機械学習の常識中の常識だが、それを見抜き、優良なコードを選ぶ研究者は、もう判断の中心にいなかった。

結果は、危険なコードに出た。

• スタンフォードの対照実験(Perry, Boneh ら, ACM CCS 2023, 47名、 Codex 使用)── AI 補助を与えられた開発者は、有意に安全でないコードを書き、しかも自分のコードを安全だと誤認した("false sense of security")。
• NYU の初期研究("Asleep at the Keyboard?")── Copilot 出力の 約 40% が脆弱性を含む(C は約 50%)。
• 企業評価では、AI 生成コードの 78% に検出困難な脆弱性。Copilot リポジトリは secret 漏洩が 40% 高い。

世界最大のソフトウェア企業が、責任を散らし、技術を空洞化させた末に犯した失敗だ。だが、責任を散らしても、責任は消えない。最終決定を下すのは CEO だ ── この失敗の責任は、ナデラにある。SIer 委託も、規模が違うだけで、同じ構造を持つ ── 顧客は「SIer に任せた」、SIer は「仕様どおり作った」。責任は宙に浮き、顧客は ソフトウェアを活用する能力を失う。委託が深いほど、空洞は深くなる。

だから答えは、内製 ── 顧客自身がビルダーになることだ(1-05)。判断と技術を自分の手元に握り直すことだけが、無責任化と空洞化を止める。

SIer 委託モデルの消滅は、必然だ

委託のコストは内製と同等になり、委託は無責任化と空洞化を生み、ループを回せるのは内製だけだ。ここまで来れば、SIer 委託モデルの消滅は必然である。

大半の仕事 ── AI が書ける標準的なもの ── は、顧客側に移る。残る専門領域 (真に新しい技術、専門規制、スケール起因の設計)も、もはや「多年の運用委託」では支えられない。時間契約のコンサルティングに変わるか、顧客の内製チームに吸収される(3-05)。どちらも、SIer 委託モデルそのものではない。

転換の速度、日本固有の事情(多重下請け構造)、雇用流動性は、3-06と 3-07で扱う。

次の章へ

本章で、SIer 委託モデルの消滅は必然だと示した。だが、消滅が必然でも、顧客がすぐに動けるとは限らない ── 既存の委託関係が、ロックインとして残るからだ。

次の章では、このロックインを扱う。

関連記事

• 1-01: AI は、世界で最も難しいコーディング問題を解く
• 1-04: ビルダーという役割
• 1-05: 顧客がAIと協働して開発する時代
• 構造分析08: 企業ITの税を引く
• 構造分析12: AIと個人事業
• ブログ Fable 5 が戻ってきたら、すぐやるべきこと ── 検証が無料になった日、「検証されない前提」で作られた委託の納品物が露呈する(本章の応用・緊急版)