DXを丸投げすると失敗する理由｜コンサル・ベンダー任せで社内に残らないものと発注側が決める4項目

「契約が終わったら、このルールは誰が直すんですか」。DXの支援を1年任せた外部の会社との最終報告会で、経営にこう聞かれ、推進担当も情報システム部門（以下、情シス）も答えられない。報告書とシステムは受け取ったのに、判断の条件を説明できる人が社内にいません。

外部に任せきりにする発注は、経済産業省が2018年の「DXレポート」から繰り返し指摘してきた課題です。丸投げが失敗に終わるのは、支援が終わった後に、業務を直すための文書と人が社内に残らないためです。

この記事を読み終えると、コンサルやシステム開発会社（以下、ベンダー）に発注する前に、自社で決めておく4項目が分かる。後半には、発注書に書く内容を決めるチェックリストを表で載せました。

委託先の選び方はDXコンサルの選び方で整理しています。この記事は、選ぶ前に発注側が持つ役割に絞って扱う。

DXの丸投げとは目的と判断の基準を決めずに外部へ任せること

DXの丸投げとは、目的と判断の基準を自社で決めないまま、企画から運用までを外部に任せることです。ここでのDXは、システムの刷新や生成AIの導入を含む、デジタル技術を使った業務の見直しを指す。

外部に頼むこと自体は丸投げではありません。何を変えるか・どの条件で判断するか・何をもって完了とするかを発注側が決めていれば、業務の委託になります。

経済産業省のDXレポートとIPAの調査が示すベンダーへの丸投げ

経済産業省は、2018年9月の「DXレポート」以降の報告書で、発注する企業（ユーザー企業）からベンダー企業への丸投げを繰り返し取り上げてきた。

報告書（公表）	丸投げについての記述
DXレポート（2018年9月）	「そもそも何を開発するかをベンダー企業に決めてくれと言っていることと同じである」
DXレポート2（2020年12月）	「ユーザー企業が事業とITを結び付けられないことからベンダー企業丸投げとなりがち」
DXレポート2.1（2021年8月）	「ITをベンダー企業任せにすることでIT対応能力が育たない」

3つの報告書はいずれも、何を作りどう判断するかを発注側が外部に任せていることを問題にしています。

2025年の調査でも、日本企業は外部に開発を任せる前提に立っている。情報処理推進機構（IPA）の「DX動向2025」は、日本・米国・ドイツの企業にDXの取組を尋ねた調査で、2025年2月から3月に実施されました。

システム開発の内製化の状況を尋ねた設問では、「外部開発を今後も利用予定であり、内製化は進めていない」が日本29.3%、米国6.5%だった。内製化を進めている日本企業でも、課題の1位は「人材の確保や育成が難しい」（82.3%）です。

回答した日本企業の約3割は今後も外部に開発を任せる前提で、内製を進める企業も人材が足りていません。任せ続けるなら、社内に何を残すかを先に決める必要がある。

DXの丸投げが起きる4つの理由

外部に頼む判断は、専門の人材がいない会社にとって合理的です。それが丸投げに変わる理由は、目的・人材・成果物・終了の条件の4つ。前の2つは発注側の体制、後の2つは契約の書き方の問題です。

理由1　DXをすること自体が目的になり対象の業務が決まらない

1つ目は目的です。経営会議で「うちもDXを進める」と決まり、推進担当や情シスが委託先に何ができるかを尋ねる。返ってくる提案はツールの導入計画になりやすく、どの業務の何時間を減らすかは書かれません。

DXレポートも、経営者から明確な指示がないまま「AIを使って何かできないか」といった指示が出され、試行（PoC）を繰り返しても改革につながらないケースも多いと指摘している。同じ失敗は生成AI導入が失敗する理由でも扱いました。

理由2　業務とITの両方が分かる担当者がいないためDXの要件定義を外部に任せる

2つ目は人材です。情シスは業務の例外を知らず、業務部門はシステムでの扱い方を知らない。両方が分かる人がいなければ、要件定義で出せる要望は今と同じ機能を保証してもらうことだけになり、DXレポートが書く「現行機能保証という条件」での委託になります。

見落とされやすいのは、業務の判断を文章にする作業まで委託先に渡っていることです。「差額が1,000円以上なら差し戻す」のような条件を委託先が文章にすれば、その知識は委託先に残る。DXレポートも、開発の委託が主の場合は「ベンダー企業側にノウハウが蓄積される」と書いています。

理由3　丸投げの契約では業務マニュアルとルール表が納品されない

3つ目は成果物です。納品物の欄が報告書一式やシステム一式だけなら、受け取れるのは、コンサルならスライドの報告書、ベンダーなら動くシステムになる。

業務の手順と判断の基準を書いた業務マニュアル、判定の条件を一覧にしたルール表、画面の操作マニュアルは、契約書に名前が書かれていなければ受け取れる保証がありません。

理由4　人月の契約に終了の条件がなく丸投げの支援が更新され続ける

4つ目は終了の条件です。システムの開発もコンサルの支援も、人数と期間で金額を決める人月の契約が多い。月2人月の支援を12か月、と書いた契約には、何ができたら終わるかが書かれていません。

この契約では、発注側が自分で運用できるようになるほど、受託する会社の売上が減ります。DXレポート2は、開発費用が労働量の対価であるため、生産性を上げると売上が下がる「構造的なジレンマ」があると指摘した。

DXレポート2.1も、受託型のベンダー企業が支援先の内製化を手伝うと、売上規模が縮小するジレンマを挙げています。

受託する会社の誠実さとは別に、終了の条件は、発注側が書かない限り契約に入らない。

DXを丸投げすると業務マニュアル・ルール表・直す担当者が社内に残らない

4つの理由が重なったまま支援が終わると、社内に残るのは報告書と動くシステムです。業務を直すための次の3つは残らない。

社内に残らないもの	具体例	起きること
業務の手順と判断の基準を書いた文書	業務マニュアル・例外の判断記録	担当者の交代で業務が止まる
判定のルール	支給の対象や差し戻しの条件を並べたルール表	条件を1つ変えるたびに見積もりが要る
運用して直す担当者	ルール表と業務マニュアルを更新する人	保守の契約が続き費用が下がらない

文書が残らないと、担当者の交代がそのまま業務の停止になります。委託先の担当が替われば業務を一から説明し直し、自社の担当が異動すれば窓口ごと知識が失われる。

ルールが残らないと、手当の新設や対象範囲の変更のたびに外注が発生する。ルールがシステムの中にしか書かれていなければ、1行の変更も見積もりの依頼から始まります。契約の要件はベンダーロックインを避けるAI導入で8項目に整理しました。

直す人が残らないと、外部に払う費用は下がらない。更新する人がいなければ、ルール表が手元にあっても変更は保守の契約で頼むことになります。

DXの丸投げを防ぐ4項目は目的・判断基準・成果物・終了条件

発注前に決める項目は4つで、4つの理由に上から順に対応しています。

DXの目的と対象業務は業務名と減らす時間で書く

1つ目は目的と対象業務で、理由1の目的のあいまいさを外す。「業務を効率化する」ではなく、対象の業務名と減らす時間で書き、対象に含めない業務も書き添えます。

DXで使う判断の基準は業務部門が確定する

2つ目は判断の基準で、理由2の、判断の知識が委託先に残る問題を外す。聞き取りと文書化は委託先に任せてよく、条件と例外の扱いは業務部門が確定して、記録を社内に残します。DXレポートが「要件を確定するのはユーザ企業であるべき」と書いた役割です。

DXの成果物に業務マニュアル・判定ルール表・操作マニュアルを含める

3つ目は成果物で、理由3の成果物のあいまいさを外す。納品物の欄に3つの文書を名前で書き、自社で編集できる形式（ExcelやWordなど）で受け取ると決めます。生成AIを使う案件では、判断の中身がAIへの指示文（プロンプト）にも書かれるため、指示文も加える。

DX支援の終了条件と引き継ぎ先を発注前に書く

4つ目は終了の条件と引き継ぎで、理由4の終わりのない契約を外します。終了の条件は期間ではなく、自社の担当者ができるようになることで書き、引き継ぐ相手と期間も決めておく。

4項目を、発注前に埋めるチェックリストにしました。空欄の項目は、発注書や提案依頼書（RFP）を書く前に決めます。

項目	発注前に決めること	決める人	発注書に書く例
目的と対象業務	業務名・減らす時間・対象外の業務	経営・業務部門長	経費精算の差し戻し確認を月80時間から40時間にする。支払処理は対象外
判断の基準	基準を確定する担当者と記録の保管先	業務部門長	差し戻しの条件は経理課長が確定し、判定ルール表で管理する
成果物	納品物の名前と形式	DX推進責任者	業務マニュアル・判定ルール表・操作マニュアルをWordとExcelで納品する
成果物	契約終了後の使い方	情シス・法務	納品物は契約終了後も自社で改変して使える
終了の条件	支援を終える到達点	経営・DX推進責任者	自社の担当者2名がルール表の変更を単独で反映できる
引き継ぎ	引き継ぐ相手と期間	DX推進責任者	最後の1か月は自社の担当者が操作し委託先は確認する

決める人の欄に委託先の名前が入る項目があれば、そこが丸投げになっています。すでに委託している場合は、契約更新の前に同じ表を埋めると、次の契約に書き足す項目が分かる。

目的と終了の条件を書くには、対象業務の時間と支援の金額を数字で持つ必要があります。見積もりを取る前に押さえる費用相場と、ROIの試算方法を整理したのが、資料『DXやAIによる業務効率化の費用とROI』です。

システム開発やコンサルに丸投げせず社内に残す判断・受け入れ・更新

4項目を決めて発注しても、途中の判断を委託先に任せれば同じことが起きる。工程ごとに、任せてよい作業と自社に残す役割を分けておきます。

工程	委託先に任せてよい作業	自社に残す役割
企画	他社の事例と技術の選択肢の提示	目的と対象業務の決定
業務の整理	聞き取りの進行と文書の書式づくり	判断の基準と例外の確定
設計と構築	技術の選定・構築・セキュリティの設計	受け入れの基準の決定と確認
運用	障害の対応と基盤の保守	ルール表と業務マニュアルの更新

委託先に任せてよいのは、専門の知識が要り、自社の業務を知らなくても進められる作業です。技術の選定やセキュリティの設計は、自社で担当を育てるより専門の会社に頼むほうが確かです。委託先の種類ごとの得意な領域はDXコンサルとはで比較しました。

自社に残すのは判断・受け入れ・更新の3つ。リデザインワークのAX支援では、判定ルール表・業務マニュアル・AIへの指示文の集まりを社内の資産として納め、社内で更新できる状態にしてから支援を終えます。

支援した給与計算の結果チェックでは、約100項目を人手で二重に確認し、月に約150時間かかっていた。判定ルール表を作って月3〜5時間規模まで減らし、3つの文書を社内に残しています。

人事の発令に関わる業務でも、変換ルール表・辞書マスタ・フロー図を残し、年約2,000時間の削減を見込んだ体制を作りました。どの業務を自社で作れるようにするかは、生成AI活用の内製化で変更の頻度・業務知識の所在・使う頻度の3つの軸から整理しています。

DXの丸投げは任せる作業の量ではなく決める役割で起きる

DXの丸投げは、委託した作業の多さで起きるものではありません。目的・判断の基準・成果物・終了の条件を誰も決めないまま発注したときに起きる。

4項目を自社で決めて発注すれば、支援が終わった翌月も、社内の担当者がルール表と業務マニュアルを更新できます。進め方の全体像は生成AI導入の進め方で扱っています。

手元の契約書の納品物の欄に、業務マニュアルと判定ルール表の名前が書かれているか。最初に確かめるのは、この1点です。