2026/5/9

「PoCで始めましょう」と言われた瞬間、経営者が決めるべきDXの境界線

PoCの勢いで本番運用に突入する案件が増えている

とりあえずPoCで始めましょう」というベンダー提案を受けて、軽い気持ちで合意した案件が、半年後に「もう止められない」状態になっている。これがDX現場で起きているもっとも厄介なパターンだ。PoC(実証実験)は本来、「本番投資すべきかを判断するための小さな実験」だ。だが運用が続くにつれ、実際の業務がPoCの仕組みに依存し始める。撤退判断が技術的な判断ではなく、業務継続性と関係者の政治の問題になっていく。

PoCを止められない案件には共通する構造がある。開始時点でKPI・撤退基準・本番移行条件のどれかが決まっていない。「決まっていない」のではなく「言語化されていない」場合がほとんどだ。担当者の頭の中にはあるが、稟議書にも契約書にも書かれていない。決裁者は本番化のタイミングを判断できないまま、PoCが日常業務になっていく。

本記事では、経営者がPoC開始時に必ず決めるべき3つの境界線と、PoC契約書に必ず入れる4項目を整理する。

なぜPoCは撤退できなくなるのか

PoCがなし崩しに本番化する構造的な理由は3つある。

  • 業務が依存し始める:PoCの集計データやワークフローを、現場が「便利だから」と日常で使い始める
  • 関係者が増える:他部署や経営会議でPoCの存在が共有されると、撤退すると「あれ、結局やめたの?」と問われる
  • 決済者が判断軸を持っていない:「ここまで来たし、もう少し続けよう」と「ROIが出ないから止めよう」を分ける数字が、最初に決まっていない

3つ目が最も致命的だ。判断軸がないまま続けると、関係者の温度感や予算消化の流れに案件が引きずられる。投資判断のはずが、組織内政治の問題になっていく。

境界線1: KPI(成功と判断する数値、成功しなかった場合の数値)

PoC開始時に決めるべき1つ目は、何が起きたら成功と判断するかだ。「業務効率化を確認する」「使えるかを試す」では境界線にならない。具体的な数値が必要だ。

  • 処理件数:1日あたり何件処理できれば成功とするか
  • 処理時間:従来比で何%短縮できれば成功とするか
  • ユーザー受容:実際に使う現場のうち何人が「継続使用したい」と回答すれば成功とするか
  • 業務影響:PoC期間中の業務停止・差し戻しが何件以下なら成功とするか

同じくらい重要なのが、「成功しなかった場合の数値」を決めることだ。「処理件数が想定の50%未満」「現場アンケートで継続使用希望が30%未満」など、これを下回ったら撤退、という閾値を最初に決める。決裁者が「数字で判断する」材料を、開始前に握る。

境界線2: 撤退基準(PoC続行が無理になる条件)

2つ目は撤退の条件だ。KPI未達は撤退条件のひとつだが、それだけではない。

  • 運用合意ライン:PoC期間中に発生した運用工数が想定を超えた場合(例:月間20時間を想定→実績40時間で打ち切り判断)
  • 予算ライン:当初予算を超える追加費用が必要になった時点で再決裁を必須とする
  • 外部条件:ベンダー側の体制変更、関連法規の変更、社内の組織変更などで前提が崩れた場合
  • 期日ライン:PoC期間が当初計画から○ヶ月延長された時点で打ち切り判断を必須とする

撤退基準を決めるときに重要なのは、「誰が撤退判断を出すか」を同時に決めることだ。担当者が判断するのか、部長が判断するのか、決裁者が判断するのか。これを決めずに「状況を見て」と言うと、誰も判断しない。

境界線3: 本番移行条件(PoC→本番の決済プロセス)

3つ目は、PoCが成功した場合の本番移行プロセスだ。これを最初に決めておかないと、PoCのまま運用が始まり、本番投資の意思決定が抜け落ちる。

  • 決裁プロセス:本番移行は誰が起案し、誰が決裁するか。PoC開始の決裁経路と同じか、上位の決裁が必要か
  • 本番移行時の追加投資額の上限:PoC費用に対して何倍まで追加投資を許容するかの目安
  • 本番化の前提条件:セキュリティ監査の通過、法務確認、運用体制の整備、現場トレーニングの完了など
  • 本番開始日の目安:PoC終了後、何ヶ月以内に本番開始するか。ここを切ると一度撤退する

本番移行条件を決めておくと、PoCが惰性で続くことがなくなる。「PoC成功→そのまま運用」ではなく、「PoC成功→本番移行の決裁→本番開始」という明示的なステップが入る。

PoC契約書に必ず入れる4項目

3つの境界線が決まったら、それをベンダーとの契約書に落とし込む。口頭合意やメールの確認だけでは、後で揉める。

  • PoC期間と評価日:開始日・終了日・評価日を明示。評価日には決裁者を含めた合意を取る
  • 成功・撤退判定の数値基準:上で決めたKPIと撤退基準を契約書の別紙に書く
  • 本番移行に進まない場合の精算条件:データの取り扱い、引き継ぎ、追加費用の有無、ベンダー側の機密保持義務
  • 追加開発・カスタマイズの扱い:PoC期間中に追加要望が出た場合の費用負担と意思決定プロセス

4項目を契約書に入れるかどうかは、ベンダーの誠実性を測る指標にもなる。「PoC契約はもっと簡単でいいのでは」と渋るベンダーは、PoCをなし崩しに本番化する案件を歓迎している可能性がある。

境界線を決めるのは経営者の仕事

PoC開始時の境界線設定は、ベンダーや担当者ではなく、決裁者の仕事だ。担当者は本番化の責任を取る立場ではないし、ベンダーは案件を続けたい動機がある。撤退判断と本番移行判断の責任を持つ人間が、初期に境界線を引く。

  • KPI(成功・撤退の数値基準)
  • 撤退基準(運用・予算・外部条件・期日)
  • 本番移行条件(決裁プロセス・追加投資上限・前提条件・開始日)

3つを最初に握ると、PoCは投資判断のための実験として機能する。握らずに始めると、PoCは止められない日常業務になる。

関連記事:検証で終わる生成AIプロジェクトの共通点と、本番化に進める条件PoCで失敗しない:システム開発の概念実証を成功させる5つのポイントシステム開発の進め方 完全ガイド

Beekleにご相談ください

Beekleでは、生成AI/CDP/業務システムの企画・要件定義・開発・運用までワンストップで支援しています。「何を作れば成功か」の整理、検証フェーズの設計、本番化判断まで、発注側の判断材料が揃うように伴走します。費用感の概算だけでも歓迎です。

お問い合わせはこちら

関連記事

「プロジェクトの進め方」カテゴリの他の記事

失敗しないRFPの作り方|骨格テンプレートと9つの落とし穴

2026/5/3
読む

生成AI/DXの導入は「業務可視化」から始める|As-Is/To-Beで失敗しない進め方完全ガイド

2026/5/3
読む

要求定義と要件定義の違いは?要求=「やりたいこと」、要件=「満たすべき条件」

2026/4/28
読む

要件定義の進め方|実プロジェクト例で学ぶ5フェーズ実践ガイド

2026/4/28
読む

要件定義書のテンプレート・サンプル|EARS記法とユーザーストーリーの実例+Word/Markdown無料DL

2026/4/28
読む

要件定義とは?目的・進め方・要件定義書テンプレートまで完全ガイド【2026年版】

2026/4/28
読む

EARS×Gherkin|要件定義からデモ/シナリオテストまでを生成AIで一直線につなぐ

2026/4/28
読む

Gherkin入門|Given/When/Thenでシナリオテストを書く・読むための完全ガイド

2026/4/28
読む

発注側がやらなくていい2つのこと|WBSとフロー図の維持を捨ててスコープ管理に集中する

2026/4/28
読む

要件の優先順位付け: MoSCoW vs FM法 完全比較|どちらをいつ使うか

2026/4/28
読む

EARS記法とは?要件定義の曖昧さを排除する5パターンと書き方の実例

2026/4/28
読む

スコープ管理「FM法」の使い方|要件を3軸で見える化して何を作らないか決める

2026/4/28
読む

【無料テンプレート】ユーザーストーリーの書き方完全ガイド|AsA・IWantTo・SoThat の3要素を使いこなす

2026/4/28
読む

AI受託開発・生成AI開発の流れと進め方|PoCからプロトタイプ・本番化までの全工程

2026/4/27
読む

システム開発の進め方 完全ガイド|発注側のプロジェクト管理

2026/3/16
読む

システム開発の要件定義の進め方|失敗しない7ステップと発注者がやること

2026/3/10
読む

生成AI時代のシステム開発の進め方

2026/3/6
読む

システム開発「思ったのと違う」を防ぐ3ステップ|要件のズレ対策

2026/1/23
読む

生成AI受託開発のプロジェクト進行|要件定義からPoC・本番化までの全ステップ

2026/1/23
読む

システム開発を段階的に進める方法|MVP・プロトタイプ活用法

2026/1/23
読む

この知識を実践してみませんか?

現状(As-Is)と改善後(To-Be)を可視化して改善点を発見できます。

次の工程で使うツール: 要件を3軸で評価して「作る/後回し/作らない」を整理できます

いきなり試すのが不安な方は 先に相談する こともできます。