AI開発発注の失敗図鑑｜発注側にオーナーがおらず丸投げする失敗（推進体制・ガバナンス）

AI開発で「開発会社に任せたのに進まない」「決まらないまま時間だけが過ぎた」という事態は珍しくない。その多くは、技術力の不足ではなく、発注側にプロジェクトのオーナーと推進体制がなく、意思決定を開発会社に丸投げしてしまったことに原因がある。

開発会社は業務の最終責任者ではない。データを出すか、どの業務を対象にするか、どこまでをAIに任せるか、こうした判断は本来、発注側が下すべきものである。その判断者が不在だと、開発は途中で止まり、納期も品質も曖昧になる。本記事では、丸投げが失敗を生む構造を整理し、発注側に必要な役割分担と最低限のガバナンスを示す。第8回で扱った現場ヒアリング不足の問題が「誰に聞くか」の話であるのに対し、本記事は「誰が決めるか」という推進体制とガバナンスの話である。

結論：AI開発はオーナーと意思決定の経路を先に決める

AI開発が丸投げで止まる最大の原因は、発注側に「最終的に決める人」と「日々動かす人」がいないことである。GXOが発注前に重視するのは、技術選定よりも先に、誰が判断し、誰が動かし、何をいつまでに決めるかという推進体制を固めることである。

• プロジェクトオーナー（最終決定者）を1人決める
• 日々の推進担当（窓口・調整役）を別に置く
• データ提供、業務判断、予算承認の決裁経路を明確にする
• 開発会社に「任せること」と「自社で決めること」を線引きする
• 意思決定が滞ったときのエスカレーション先を決めておく

この体制がないままAIだけを発注すると、開発会社が判断できない論点が積み上がり、開発は止まる。発注側の体制づくりは、技術検討と同じかそれ以上に重要である。推進体制の設計は、発注前のわずかな時間で済む割に、開発全体の進み方を大きく左右する。誰が決めるかを先に固めるだけで、後工程の停滞は目に見えて減る。

丸投げは、どこに表れるか

発注側にオーナーがいない状態は、次のような形で表面化する。いずれも初期に見落とされがちだが、放置するほど後工程での手戻りが大きくなる。

• 開発会社からの確認に回答が返らず、開発が待ち状態になる
• データ提供の可否を誰も判断できず、要件が固まらない
• 「現場に聞いてみないと分からない」が繰り返され、決定が先送りになる
• 完成しても「これは誰が責任を持つのか」が決まらず、運用に乗らない
• 仕様変更の要望が部署ごとに出て、優先順位が誰にも付けられない

これらは開発会社の能力不足ではなく、発注側の推進体制とガバナンスの欠落に起因する。AIが動くかどうか以前に、プロジェクトとして前に進まない状態である。

なぜ発注側はオーナー不在で丸投げするのか

丸投げが起きる背景には、いくつかの典型的な思い込みや組織構造がある。順に見ていく。

AI導入を「技術の話」だと捉えている

AIを技術導入だと考えると、「詳しい会社に任せれば良い」という発想になりやすい。しかしAI開発は、どの業務をどう変えるかという経営・業務の意思決定を含む。技術だけ外注しても、業務判断は外注できない。

旗振り役が兼任で、権限と時間がない

DX推進担当が他業務と兼任で、決裁権限を持たないケースは多い。窓口はいても「決められない窓口」だと、開発会社の確認はすべて保留になり、プロジェクトは停滞する。

部署をまたぐ調整役がいない

AIの対象業務は複数部署にまたがることが多い。情シス、現場、管理部門の間を調整し、優先順位を決める役割がいないと、要望は発散し、誰も全体を決められなくなる。

「失敗の責任」を誰も取りたがらない

オーナーを決めるとは、成果と失敗の責任を引き受ける人を決めることでもある。これを曖昧にしたまま開発会社へ丸投げすると、うまくいかないときに「ベンダーのせい」になり、原因の切り分けも改善も進まなくなる。

自社のDX推進体制が今どの段階にあるかを把握しておくと、こうした穴に気づきやすい。現状の整理にはDX成熟度の診断のような客観的な棚卸しが役立つ。組織のどこに推進体制の弱点があるかを発注前に言語化できると、その後の役割分担の議論が一気に進む。

丸投げ型と推進体制がある型の違い

右側の状態を発注前に作っておくと、開発会社は判断を待たずに前へ進める。体制は完璧でなくてよいが、「誰が決めるか」だけは曖昧にしてはならない。表の左側に一つでも心当たりがあれば、その項目が発注後に止まる場所になると考えてよい。

発注側に最低限必要な4つの役割

役割は人数ではなく機能で考える。小さな組織なら1人が複数を兼ねてもよいが、機能としては次の4つを揃えておきたい。

• プロジェクトオーナー：対象業務、予算、本番化の可否を最終決定する。経営または事業の責任者が望ましい。
• 推進担当（窓口）：開発会社との日々のやり取り、社内調整、論点の整理を担う。回答を返せる権限の委譲を受けておく。
• 業務側キーパーソン：対象業務を実際に行う現場の代表。例外や運用の実態を判断する。
• 情シス・セキュリティ担当：データ提供、権限、ログ、社内システム連携の可否を判断する。

この4機能のうちどれかが欠けると、その領域の確認がすべて滞る。たとえば情シスが関与しないと、データ提供とセキュリティの判断が止まり、開発は要件定義から進めなくなる。RAGやAIエージェントのように社内データや社内システムに触れる開発（社内システムと連携するAIエージェント開発）では、この役割分担が特に効いてくる。逆に役割が揃っていれば、開発会社は確認のたびに止まることなく、要件定義から本番化まで一貫して走り切れる。

発注前に確認すべきこと（チェックリスト）

• プロジェクトオーナー（最終決定者）を1人決めたか
• 日々の推進担当を置き、回答できる権限を委譲したか
• 業務側キーパーソンと情シス・セキュリティ担当を体制に含めたか
• データ提供の可否を誰が判断するかを決めたか
• 予算と追加費用の決裁経路、上限を決めたか
• 意思決定が滞ったときのエスカレーション先を決めたか
• 開発会社に任せることと、自社で決めることを線引きしたか
• 本番化・継続・停止の判断を、いつ、誰が下すかを決めたか
• 対象業務が複数部署にまたがる場合、調整役を決めたか

この9項目のうち、前半5つが埋まっていないまま発注すると、開発は早い段階で止まりやすい。技術要件より先に、この体制を固めておきたい。発注判断を社内で説明する段階では、システム開発の稟議・ROI診断の観点で、体制と費用と効果を1枚に整理しておくと通しやすい。

GXOに相談する前に整理しておくとよい情報

• 改善したい業務と、その業務に責任を持つ部署・人
• 現時点で「決められる人」が誰か（オーナー候補）
• 日々の窓口を担える人と、その人が持つ権限の範囲
• データ提供やセキュリティの判断ができる担当者の有無
• 予算規模と、追加費用が出たときの決裁の流れ
• 過去にDXやシステム開発が止まった経験と、その原因

これらが整理されていると、技術提案の前に「この体制で進められるか」を一緒に確認できる。体制の穴が見えれば、発注前に埋めておける。整理が不十分でも相談は可能であり、改善したい業務と決定者候補が見えていれば、推進体制の設計から一緒に進められる。技術面の実現可否を見極めたい場合は、AI導入可否のアセスメントで対象業務とデータの状態を先に診断しておくと、体制の議論と並走させやすい。

補足：実務上の注意点

推進体制は「立派な組織図」を作ることではない。重要なのは、論点が来たときに止めずに決められる経路があるかどうかである。次の点に注意したい。

第一に、オーナーは兼任でもよいが、判断の時間は確保しておく。週に短時間でも論点を裁く場がないと、確認は滞留する。第二に、推進担当には「ここまでは自分で回答してよい」という権限の範囲を明示する。すべてを上に確認していては開発の速度が落ちる。

第三に、開発会社への丸投げと「適切に任せること」は違う。要件定義や技術選定を任せるのは正しい分業だが、業務判断やデータ提供の可否まで委ねてはいけない。任せる範囲を契約と議事録で明文化しておくと、後の責任の押し付け合いを防げる。

第四に、ガバナンスは重くしすぎない。意思決定の経路を増やすほど安全に見えるが、承認段階が多いと開発は止まる。決める人を絞り、エスカレーション先を1つ決める方が、実務では速く安全に回る。AIの推進体制づくりは、AI開発やDX・システム開発のプロジェクトを止めないための土台であり、技術検討と同じ優先度で扱う必要がある。なお、体制が固まらないうちに全社へ一気に広げると別の失敗につながるため、スモールスタートとロールアウトの設計とあわせて検討したい。

第五に、推進体制は一度決めて終わりではない。プロジェクトの段階が進むと論点の性質が変わり、必要な判断者も変わる。検証段階では情シスの関与が薄くても進むが、本番化が近づくとセキュリティと運用の判断が一気に重くなる。最初に決めた役割を、節目ごとに見直す前提で組んでおくと、後半で体制が追いつかない事態を避けられる。判断の前提となる自社の現状を客観的に押さえたいときは、再度DX成熟度の診断で棚卸しをかけ直すと、体制の過不足が見えやすい。

開発会社選びの段階でも、体制づくりに伴走してくれるかは見ておきたい観点である。発注側の弱い部分を一緒に補強できる相手かどうかは、開発会社選びの実務チェックの視点で確認できる。技術的な実現性そのものに不安が残る場合は、AI導入可否のアセスメントで対象業務とデータを切り分けてから体制設計に入ると、議論の手戻りが減る。

関連記事

• AI開発発注の失敗図鑑｜現場ヒアリング不足で要件がずれる問題
• AI開発発注の失敗図鑑｜PoCで終わる会社の共通点
• AI開発発注の失敗図鑑｜スモールスタートせず一気に全社展開して失敗するロールアウト
• 特集トップ：AI開発発注の失敗図鑑

よくある質問

Q1. 小さな会社でも、オーナーと推進担当を分ける必要がありますか

機能として分けることが望ましいが、人を分けられないなら1人が兼ねてもよい。重要なのは、最終決定の責任と日々の調整の役割の両方を、誰かが確実に担っている状態を作ることである。兼任でも、判断の時間と権限が確保されていれば機能する。

Q2. 開発会社に任せる部分と、自社で決める部分の線引きはどう考えればよいですか

技術選定、設計、実装、要件定義の進行は開発会社に任せてよい。一方、どの業務を対象にするか、どのデータを出せるか、どこまでAIに任せるか、本番化するかどうかは発注側が決める。業務の最終責任に関わる判断は外注できないと考えると線引きしやすい。

Q3. DX推進担当が兼任で時間が取れません。どうすればよいですか

すべての論点を担当者が抱える必要はない。オーナーが裁く論点、担当者が即答してよい論点、現場や情シスに振る論点を分けると負荷は下がる。週に短時間でも論点を裁く場を設け、滞った確認を放置しない仕組みを作ることが、兼任でも開発を止めないコツである。

Q4. 体制を整える前に、まず技術検証から始めても問題ないですか

小規模な検証から始めること自体は有効だが、検証の合否を誰が判断し、次に進めるかを決める人は最初に決めておきたい。判断者が不在だと、検証は終わっても「で、どうするのか」が決まらず、PoCで止まる典型に陥る。技術検証と最低限の推進体制は、並行して準備するのが現実的である。

発注前チェックリスト（全30項目・無料）：本連載の30類型を1枚で点検できるチェックリストを無料ダウンロードできます。発注前の社内確認・稟議の添付資料にご利用ください。

AI開発を丸投げにせず、自社の推進体制から一緒に整理したい場合は、無料相談で対象業務と決定者の整理からご相談いただきたい。