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

仮説を試作品で確認し、開発・変更・見送りを判断する流れ
確かめたい仮説に必要な範囲を試作し、利用者の反応や検証結果を確認します。結果をもとに開発・範囲変更・見送りを判断します。

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

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

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

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

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

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

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

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

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

1つ目は、何が起きたら成功と判断するかだ。「業務効率化を確認する」「使えるかを試す」は境界線にならない。数値が要る。

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

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

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

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

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

撤退基準とセットで、「誰が撤退判断を出すか」も同時に決めておく。担当者が判断するのか、部長が判断するのか、決裁者が判断するのか。ここを決めずに「状況を見て」で済ませると、誰も判断しない。

境界線3: 本番移行条件(PoCから本番へ移行する際の決裁プロセス)

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

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

本番移行条件を決めておくと、PoCが惰性で続くことがなくなる。「PoC成功→そのまま運用」で流れずに、「PoC成功→本番移行の決裁→本番開始」という明示的なステップが1つ挟まるからだ。

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

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

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

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

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

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

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

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

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

まずは小さく始めてみませんか? Beekleのゼロスタートなら、最短1〜2週間を目安に(規模により変動)動く試作品を作り、「本当に業務で使えるか」を実際に触って確認してから本格開発に進めます。 ゼロスタートについて相談する

要求からGherkin、実装、動作確認まで、手でつなぎ続けていませんか?

要求からユーザーストーリー、Gherkin、実装、動作確認までをつないで管理する、Beekle自社開発のシステムです。現在ベータ版で、一般公開に向けて登録を受け付けています。

開発リソースの逼迫・難航案件の立て直し・AI活用開発の知見をお探しの開発会社/SIer様のご相談も承ります