受注する側から「丸投げでは成果が出ない」という趣旨の発信が出てきたとすれば、それは道義の話ではなく、丸投げのままでは成立しない領域へ仕事が移ったという意味になる。
IT Leadersは2026年8月7日、日本タタ・コンサルタンシー・サービシズ（日本TCS）の同年8月5日の事業戦略説明会について、日本企業がAIを実装する際には丸投げ型の多重下請け構造から脱却し、自らの「IT主権」を取り戻す必要があるとの趣旨が示されたと報じた。あわせて、ITパートナーや顧客との「共創モデル」への移行、および人材不足を補い内製力を高めるための拠点としてのGCC（Global Capability Center）の位置づけが伝えられている。
**ここで留保をひとつ置く。**本稿執筆時点で、この説明会の内容を確認できる日本TCSの公式資料は確認できていない。以下の記述は上記報道に基づく要約であり、発言の原文や文脈を一次資料で照合したものではない。同社が公表している一次情報として確認できたのは、サティシュ・ティアガラジャン氏が代表取締役社長であること、および同社がGCC事業を展開していることである。報道で言及された経営数値については一次確認ができなかったため、本稿では扱わない。
GCCを設置できるのは相当な規模の企業に限られる。しかし主権を失っている構造そのものは、規模を問わず共通している。「IT主権」を年商数十億から数百億円規模の会社に当てはめると、具体的に何を意味するのか。
この記事を読むべき人
- システム開発をすべて外部に委託しており、社内に技術判断ができる人がいない会社
- 見積もりが妥当かどうかを、他社と比べる以外の方法で判断できない会社
- 「開発会社を変えたいが、変えられない」と感じている経営者
- 情報システムの担当が、実質的にベンダーとの窓口業務だけになっている会社
- AIの活用を検討しているが、どこから手をつけるかをベンダーに聞いている会社
RESTAURANT DX
店長の経験と勘を、仕組みで再現できる店舗にしませんか？
発注／シフト／予約／FLコストを標準化する多店舗飲食特化のDX。食材ロス削減・インバウンド対応まで概算費用をその場で示します。
「IT主権を失っている」とはどういう状態か
抽象的な言葉なので、判定できる形にする。次の7項目のうち、当てはまるものがいくつあるかを数えてほしい。
- 自社システムの仕様を説明できる資料が、自社の手元にない
- 見積もりの妥当性を、相見積もり以外の方法で判断できない
- 現在の開発会社を変えると、システムが維持できなくなる
- 新しい要望を出すとき、実現可能かどうかを相手の回答でしか知れない
- 障害が起きたとき、原因の説明を受けても正しいか判断できない
- システムに関する意思決定の起点が、常にベンダーからの提案である
- 自社のデータがどこにどう保管されているかを、社内で説明できない
**この7項目はGXOが独自に整理した確認リストであり、該当数に検証済みの基準があるわけではない。**点数として扱うのではなく、仕様、データ、アカウント、検収基準、移管手順のうち何が欠けているかを個別に見てほしい。該当が多いほど、意思決定の起点が社外に移っている可能性が高い、という程度の目安である。
ここで誤解を避けたいのは、これは開発会社が悪いという話ではないという点である。多くの場合、こうなったのは自然な経緯による。技術者を雇う余裕がなく、任せるほうが安く、任せた結果として社内に情報が残らなかった。どの段階でも合理的な判断だった。
問題は、その状態でAIやデータ活用の話が来たときに起きる。**これらは「何を作るか」を自社で決められないと成果につながらない領域だからだ。**業務のどこにAIを当てるか、どのデータに価値があるか、どこまで自動化して人が判断すべき境界はどこか。これらはベンダーには決められない。決めようとすれば、ベンダーが提供できるものに合わせた提案になる。
日本TCSの指摘が「AIを実装する際に」という文脈で出ているのは、この構造を指していると読める。従来型のシステム開発なら、仕様を渡して作ってもらう分業が成立した。AIの活用では、その仕様を書くこと自体が最も難しい部分になる。
全内製は目標にならない
「主権を取り戻す」と聞くと、内製化、つまり自社で技術者を雇って作る話に見える。だが年商数十億から数百億円規模の会社にとって、これは現実的な目標ではない。
理由は3つある。**技術者の採用市場で大手と競合すること。採用できても、業務量が一定しないため常時稼働させられないこと。そして一度採用すると、その人が扱える技術に自社が縛られること。**内製化を進めた会社が数年後に「特定の社員がいないと何も直せない」状態になるのは珍しくない。それは外部への依存が社内への依存に置き換わっただけで、主権の回復ではない。
では何を目指すのか。作る能力ではなく、判断する能力を取り戻すことである。具体的には次の3つに絞られる。
**能力1：要件を書ける。**何を作りたいかを、業務の言葉で、曖昧さなく書ける。技術的な設計は不要で、「誰が、どういう状況で、何をできるようになるのか」「今と何が変わるのか」「何が変わってはいけないのか」が書ければよい。
**能力2：検収できる。**納品されたものが要件を満たしているかを、自社で判定できる。動作確認の手順を自社で作り、合否を自社で決められる状態を指す。ここをベンダー任せにすると、「仕様どおりです」という説明を受け入れるしかなくなる。
**能力3：切り替えられる。**必要になったとき、別の会社に引き継げる。そのために必要なのは、技術力ではなく、資料とデータとアカウントが自社の手元にあることである。
**この3つは、いずれも技術者を雇わなくても持てる。**そして3つ揃うと、外部への委託は「依存」ではなく「選択」になる。同じ会社に頼み続けることになっても、その関係の性質が変わる。
順番にも意味がある。能力3（切り替えられる）は資料とデータの保管が中心なので、今日から着手できる。資料が手元に揃っていれば追加費用はほとんどかからないが、存在しない資料を新たに作る必要がある場合は、その分の費用が発生する。能力1（要件を書ける）は次の案件から練習できる。能力2（検収できる）は、能力1で書いた要件があって初めて成立する。**つまり実務上は、3→1→2の順に手をつけるのが最短になる。**多くの会社が「まず要件定義の研修から」と考えるが、資料が手元にない状態で要件だけ書けるようになっても、切り替えの選択肢は増えない。
多重下請けの何が問題なのか
「多重下請け」への批判は、しばしば単価や労働環境の文脈で語られる。それも重要だが、発注側の経営にとっての問題は別のところにある。情報が階層を降りるたびに劣化し、上がってくるときにも劣化することである。
自社が元請けに要望を伝える。元請けが二次請けに伝える。二次請けが三次請けに伝える。この過程で、業務上の背景や「なぜそれが必要か」は落ちていく。実際に手を動かす人に届くのは、作業の指示だけになる。
すると何が起きるか。**指示どおりに作られたものが、業務では使えない。**要望を出した部署は「こういう意味ではなかった」と言い、開発側は「指示どおりです」と言う。どちらも嘘をついていない。落ちたのは、その間にあった背景である。
逆方向でも同じことが起きる。実装中に見つかった問題——「この処理は現行と矛盾している」「このデータは想定した形式で入っていない」——が、階層を上がる過程で丸められる。発注側に届く頃には「順調です」になっている。そして納品直前に、まとめて問題が表面化する。
**したがって、階層の深さは費用の問題である以上に、判断の遅れの問題である。**問題が早く伝わるほど、対応の選択肢は多い。遅れるほど、選択肢は「延期するか、妥協して受け入れるか」の二択に狭まる。
自社の案件が何階層になっているかは、聞けば分かる。「実際にプログラムを書いているのは、どちらの会社の方ですか」。この質問に明確に答えられない場合、階層が深い可能性がある。階層が深いこと自体を否定する必要はないが、深いなら、情報の劣化を前提とした確認の仕組みを自社側で持つ必要がある。
「共創」を契約条件に翻訳する
共創、パートナーシップ、伴走といった言葉は提案書によく登場するが、そのままでは何も担保しない。契約と成果物の形に落として初めて意味を持つ。落とし込むべき項目を挙げる。
横にスクロールして確認できます
| 「共創」の中身 | 契約・成果物での表れ方 |
|---|---|
| 判断の材料が自社に渡る | 設計資料・構成情報を納品物に含める |
| 検収を自社ができる | テスト項目と判定基準を発注側と合意して作る |
| 途中で方針を変えられる | 段階ごとの見直し時点を契約に置く |
| 知識が自社に残る | 定例で技術的な説明の時間を設ける |
| 切り替えが可能である | データの出力形式と移行手順を事前に定める |
| 自社の人が関与する | 発注側の担当者と作業時間を明記する |
**最後の行が抜けている「共創」は成立しない。**発注側が誰も時間を出さない体制で、相手だけが歩み寄る形は、丸投げと構造が同じである。共創を求めるなら、自社の誰が週に何時間関わるのかを先に決める必要がある。
ここは経営が決める話になる。現場は通常業務で手一杯であり、放っておけば「打ち合わせは月1回、あとはお任せ」に落ち着く。共創モデルが機能するかどうかは、ベンダーの姿勢より、発注側が人の時間を出せるかで決まる。
中堅企業版の「取り戻し方」の順序
一度に全部は変えられないので、着手の順序を示す。上から順に、費用が小さく効果が早い。
**第一段階：手元に何があるかを確認する。**契約書、仕様書、設計資料、アカウント情報、データのバックアップ。これらが自社の管理下にあるかを確認する。ないものは、開発会社に依頼して受け取る。**既存資料の引渡しが契約の範囲に含まれるか、新たに作成する費用が必要かは、契約書と納品物一覧で確認する。**資料がそもそも存在しない場合、再作成の費用が発生し得る。
**第二段階：次の案件から、要件を自社の言葉で書く。**完璧である必要はない。A4で1〜2枚、業務の言葉で「何がどう変わるか」を書き、それを提案依頼の起点にする。ベンダーの提案書に自社が合わせるのではなく、自社の要件に提案が答える形にする。この順序が逆になっていることが、丸投げの実体である。
**第三段階：検収の基準を自社で作る。**納品前に「これができていれば合格」という項目を、業務の言葉で列挙する。技術的な項目は不要で、実際の業務手順をなぞって確認できる形にする。
**第四段階：定例で説明を受ける時間を作る。**月1回30分でよい。今どこを作っていて、何が難しく、何を判断してほしいのかを聞く。これを続けるだけで、社内に判断の材料が蓄積していく。
**第五段階：第二の相談先を持つ。**現在の開発会社とは別に、提案や見積もりの妥当性を相談できる相手を確保する。これは相見積もりとは違う。発注前後を通じて、発注側の立場で助言を受ける関係を指す。
多くの会社が、第五段階から始めようとして止まる。「セカンドオピニオンを頼むと、今の会社との関係が悪くなるのでは」と考えるからだ。だが第一段階から第四段階は、現在の関係を何も損なわずに進められる。しかも第四段階まで済んでいれば、第五段階で相談する内容も具体的になる。
要件を「業務の言葉で書く」とはどういうことか
第二段階で挙げた「自社の言葉で要件を書く」が、実務上いちばん難しく感じられる部分だと思う。技術用語を使わずに書けと言われても、何を書けばよいか分からないという声が多い。
書くべきは、次の5つだけである。
**1. 誰が使うのか。**部署名と、想定する人数。役職や習熟度も書けるとよい。同じ機能でも、毎日使う3名向けと、月1回使う50名向けでは作りが変わる。
**2. いま、その業務をどうやっているか。**現状の手順を、使っている道具（紙、表計算ソフト、既存システム、電話）まで含めて書く。**ここが最も重要で、最も省略されやすい。**現状が書かれていない要件は、提案側が想像で埋めることになる。
**3. 何が困っているか。**時間がかかる、間違いが起きる、確認に手間がかかる、休むと止まる。困りごとを具体的に書く。「効率化したい」では、どこを直せばよいか決まらない。
**4. どうなったら成功か。**作業時間が何分になれば、間違いが月何件以下になれば、といった判定できる形にする。ここが後の検収基準になる。
**5. 何を変えてはいけないか。**現行の帳票の形式、取引先とのやり取りの方法、法令で定められた記録の残し方。この項目があると、提案側が余計な提案をしなくなり、見積もりが下がることがある。
**5項目を書くのに、技術的な設計の知識は要らない。**必要なのは業務の知識であり、それは自社にしかない。逆に言えば、これを書かずに発注するということは、自社にしかない情報を渡さないまま作ってもらうということになる。
**完璧を目指すと着手できないので、粗くても書いて相手に見せ、質問を受けながら精度を上げるほうが早い。**質問される項目が、次回から自分で書ける項目になる。
なお、この5項目だけで発注できるという意味ではない。性能や可用性の要件、扱うデータの制約、法令上の要件、既存システムとの接続条件は別途必要になる。5項目は、発注側にしか書けない部分を先に埋めるための出発点であり、要件定義の全体ではない。
内製化で失敗する3つのパターン
主権の回復を「内製化」と読み替えて着手した会社が陥る型も挙げておく。
**型1：作れる人を採用したが、決める人がいない。**技術者を雇っても、何を作るかを決める人が不在なら、その人は指示待ちになる。優秀な人ほど早く辞める。
**型2：既存システムを理解する前に新しく作り始める。**現行の業務ルールが何十年分か積み上がっていることを軽視すると、作り直したものが業務に合わず、結局旧システムが残る。二重管理が発生し、コストは増える。
**型3：内製した結果、新しい属人化が生まれる。**社内の1名しか触れないシステムができあがる。外部依存が社内依存に変わっただけで、リスクの構造は同じか、むしろ悪い。外部の会社なら組織として引き継げるが、社員1名は退職すればゼロになる。
**この3つを避ける方法は共通している。作る主体を変えるのではなく、判断と資料を自社に残す仕組みを先に作ることである。**それができていれば、実装を誰が担っても構わない。
経営が最初に確認すべきこと
最後に、経営として今日できることを挙げる。情報システムの担当者、または開発会社との窓口担当に、次の4つを聞いてみてほしい。
1. いま動いているシステムの仕様資料は、どこにあるか。「開発会社が持っている」という答えなら、能力3が欠けている。
2. 直近の見積もりについて、金額が妥当だと判断した根拠は何か。「他社と比べた」以外の根拠が出てこなければ、能力1と2が弱い。
**3. 今の開発会社が対応できなくなったら、次はどうするか。**具体的な手順が出てこなければ、切り替えの選択肢がない。
4. 次に何を作るかは、誰がどう決めているか。「先方からの提案を検討している」が続いているなら、意思決定の起点が外にある。
**この4問への回答は、担当者を評価するためのものではない。**答えられない状態を作ってきたのは、その体制を選んできた経営の側である。確認の目的は、いまどこに穴があるかを知り、前節の第一段階から埋めることにある。
よくある質問
Q. 今の開発会社に不満はない。それでも変える必要があるか。 A. 会社を変える必要はない。この記事が扱っているのは、委託先を変えることではなく、判断の材料を自社に持つことである。良い関係が続いているなら、その相手と一緒に第一段階から第四段階を進めるのが最も早い。誠実な会社であれば、資料の提供にも定例の説明にも応じる。
Q. 資料の提供を依頼したら、追加費用を請求された。 A. 契約内容による。納品物として定めていなかった場合、新たに作成する工数が発生するのは不当ではない。判断すべきは、その費用と、資料がないまま続けることのリスクを比べてどちらが大きいかである。次回以降の契約では、納品物に含める形にしておく。
Q. GCCのような拠点は、自社規模では作れない。 A. 作れない。GCCは相応の規模と、継続的に一定量の開発需要があることを前提とした仕組みである。中堅企業に相当するのは、拠点を持つことではなく、この記事で挙げた3つの能力を社内に置くことになる。人数で言えば、専任1名でも成り立つ。
Q. 社内に情報システムの担当がいない。誰が3つの能力を持つのか。 A. 専任である必要はない。要件を書くのは、その業務を最もよく知っている現場の管理者が適している。検収も同じ人が担える。切り替えの備え——資料とアカウントの保管——は、総務や経営企画でも扱える。**技術者が必要になるのは、技術的な設計と実装であって、この3つの能力ではない。**むしろ技術者がいない会社ほど、この3つを業務側の人が持つ形にしたほうが、実態に合う。
Q. 相談する第二の相手を持つと、費用が二重にかかるのではないか。 A. 発注前の整理と提案の検証にかかる費用は、開発費に比べれば小さい。そして効果が出るのは、不要な機能を削れたとき、要件の曖昧さによる追加費用を防げたとき、そもそも作らない判断ができたときである。**最も費用対効果が高いのは、作らないほうがよいと分かった場合である。**この判断は、作る側からは出てきにくい。
Q. AIの活用について、何から決めればよいか分からない。 A. 「何を作るか」の前に、「どの業務のどの作業に時間がかかっているか」を自社で把握するところから始まる。ここはベンダーには分からない領域であり、同時に、自社にしか答えられないという意味で主権の中核でもある。
提案の妥当性を確認したいとき
発注前の整理、提案内容の確認、見積もりの読み解きは、作る側に相談しても中立の答えが返りにくい。ここは発注側の立場に立つ第三者が要る領域である。
現在のシステムと契約の状態を確認し、判断の材料が自社にどれだけ残っているかを整理したい場合は、システム開発・DX推進の相談で受け付けている。既に提案や見積もりを受け取っていて、その内容を第三者の視点で読み解きたい場合も同じ枠組みで対応する。
自社の現在地と、どこから着手すべきかの優先順位を整理したい段階であればDX成熟度診断、AIの活用可能性を投資判断の前に評価したい場合はAI導入アセスメントが該当する。現在の開発会社との関係を変えずに進められる範囲から扱えるので、お問い合わせから状況を知らせてほしい。
なお、元請け・下請けの費用と責任の分界はプライムベンダー方式の判断ガイド、SES契約の商流確認はSES単価と契約の確認項目で別途整理している。本稿は、発注側が社内に残すべき判断能力に焦点を絞っている。
参照した情報
- IT Leaders「IT主権を再び掌中に、『共創』と『GCC』でAIネイティブへの進化を支援」（2026年8月7日、日本タタ・コンサルタンシー・サービシズの2026年8月5日事業戦略説明会の内容）: https://it.impress.co.jp/articles/-/29668
2026年8月5日の説明会の内容は上記報道の記述に基づく二次情報であり、**本稿執筆時点で対応する日本TCSの公式資料は確認できていない。**報道で言及された経営数値（売上高、採用人数、平均年齢、AIトレーニング実施人数）は一次確認ができなかったため、本稿では引用していない。発言の趣旨を業務判断の根拠に用いる場合は、同社の公式資料または広報への確認を経てほしい。また本稿は「大手SIer全体の傾向」を示すものではなく、報道で伝えられた1社の発信を出発点にしている。IT主権のチェック7項目、3つの能力、着手の5段階、内製化の失敗3パターン、経営が確認すべき4問はGXOが第三者の立場から言語化したものであり、日本TCSの提唱する枠組みではない。
