PoCは「問い→範囲→合否条件→実施→判断」の順で進める
PoCの進め方を一言でまとめると、作る前に決めることを決め、終わった日に判断できる状態をつくる、ということです。順番は次の五段階です。
- 確かめる問いを決める
- 作る範囲と、作らない範囲を決める
- 評価指標と合否条件を決める
- 実施し、記録する
- 結果から次の判断をする
四番目の「実施」から始まってしまう場合もあります。技術に詳しい人がいて、試しに作ってみたら動いた、という始まり方です。それ自体は悪いことではありませんが、その試作をPoCと呼んで予算をつけるなら、一番目から三番目を後からでも埋める必要があります。そこが空いたままだと、終わった後に何も決まりません。
以下、段階ごとに、決めることと成果物を整理します。システム開発を伴うPoCを念頭に置いていますが、業務の試行など開発を伴わない検証にも同じ順番が使えます。
段階1：確かめる問いを一文にする
最初の成果物は、一文で書かれた問いです。「需要予測にAIを使えるか」のような広い問いではなく、誰が、どの場面で、何ができれば、次に何を決められるのか、が分かる文にします。
たとえば、店舗向けの発注支援サービスを検討している場合であれば、「店長が毎朝の発注作業で、提示された発注案をそのまま、または少しの修正で採用できるか」という形です。この文には、利用者（店長）、場面（毎朝の発注作業）、確かめること（提示された案を採用できるか）が入っています。
問いを書くときの確認点は次のとおりです。
- この問いに答えが出たら、何を決められるか。
- 答えが「いいえ」だった場合にも、取れる行動があるか。
- 問いが複数あるなら、どれがもっとも不確かで、外れたときの影響が大きいか。
一度のPoCで扱う問いは、もっとも不確かで影響の大きいものに絞ります。顧客が本当にその課題を持っているかがまだ不確かな段階であれば、PoCより前に確かめることがあります。事業の前提を一つずつ検証する進め方を先に確認してください。
段階2：作る範囲と作らない範囲を決める
問いが決まったら、その問いに答えるために最低限必要なものだけを作る範囲に入れます。PoCの開発プロセスで期間と費用が膨らむ原因になりやすいのが、この段階で範囲を絞り切れていないことです。
決める項目は次のとおりです。
- 対象：どの部門、どの店舗、どの顧客層で試すか。全体ではなく、結果を読み取りやすい一部に絞ります。
- 機能：問いに答えるために必要な画面と処理。ログイン、権限管理、帳票、通知など、本番では必要でも問いに関係しないものは外します。
- データ：どのデータを、どの期間分、誰が用意するか。
- 連携：既存システムとつなぐか、ファイルの受け渡しで代用するか。
- 手作業で代用する部分：自動化せず、人が裏側で処理してもよい部分。
大切なのは、作らないものを文書に書くことです。書いていない範囲は、途中で「これも必要では」という声が出たときに、判断の拠り所がなくなります。考え方はMVPの要件定義で作らない範囲まで決める方法と共通です。
段階3：評価指標と合否条件を、作る前に合意する
PoCの検証の進め方でもっとも重要なのが、この段階です。何を測り、どの水準なら次へ進むのかを、結果を見る前に決めます。
- 問いに対応する指標を選ぶ。利用者が案を採用した割合、作業にかかった時間、誤りの件数、など。
- 指標ごとに、合格の水準と不合格の水準を書く。水準の根拠（現状の値、事業として成り立つための条件など）も添える。
- 合格と不合格のあいだだった場合の扱いを決める。
- 数値にならない観点（利用者の受け止め方、運用上の支障）を、どう記録し、どう判断に使うかを決める。
- 判断する人の名前と、判断する日を書く。
水準の数字は、自社の現状と事業の条件から決めるものです。他社の値や一般論から借りてくるものではありません。現状の値が分からない場合は、PoCの前に現状を測ることを計画に入れます。詳しい設計はPoCの終了日に次の投資を決められる評価設計で扱っています。
ここまでの三段階を一枚にまとめたものが、PoCの計画書になります。
段階4：実施する。記録の取り方を先に決めておく
実施の段階では、開発と検証が並行して進みます。ここで気をつけることは三つあります。
- 短い間隔で確認する：週に一度は、発注側の判断者と開発側が同じ画面やデータを見て、範囲と進み具合を確認します。確認の場で決まったことは、その場で記録します。
- 計測を後回しにしない：利用の記録や作業時間の計測は、機能ができてから考えるのではなく、最初から組み込みます。終了間際に「測っていなかった」と気づくと、取り戻せません。
- 計画からの変更を記録する：範囲、対象、期間を変えた場合は、理由と一緒に残します。後で結果を読むときに、何が計画どおりで何が違ったのかが分からなくなるのを防ぎます。
利用者に実際に使ってもらう場合は、使い方を細かく教えすぎないことも大切です。説明がなければ使えないのであれば、それも結果の一つです。観察の方法は操作を説明しないユーザーテストの進め方が参考になります。
段階5：結果から、進む・変える・止めるを決める
終了日には、合否条件に照らして結果を整理し、判断の場に出します。資料に入れる内容は次のとおりです。
- 確かめた問いと、合否条件（計画時のまま）
- 指標ごとの結果と、計画から変更した点
- 数値にならない観察（利用者の反応、運用上の支障）
- 今回は確かめなかったこと
- 取り得る選択肢（進む、対象や方法を変える、止める）と、それぞれに必要な費用と期間
- 担当者としての推奨
結果の良い部分だけを並べた報告は、その場では通っても、次の段階で前提が崩れたときに信頼を失います。合格に届かなかった指標も、そのまま載せます。
よくある質問
Q. PoCの期間はどのくらいが適切ですか。
一律の答えはありません。確かめる問いと、利用者が実際に使う場面が何回めぐってくるかで決まります。毎日の業務であれば短い期間でも回数を確保できますが、月に一度の業務であれば、それだけ長くなります。期間から決めるのではなく、判断に必要な回数の観察が得られる期間を置き、長くなりすぎるなら問いを絞ります。
Q. システム開発のPoCでは、ウォーターフォールとアジャイルのどちらで進めるべきですか。
PoCは、作りながら分かることが多いため、短い間隔で確認と修正を繰り返す進め方が向いています。ただし、問い・範囲・合否条件は最初に固定します。変えてよいのは作り方であって、何を確かめるかではありません。
Q. 計画書は、どの程度まで細かく書く必要がありますか。
一枚から数枚で足ります。細かさよりも、問い、作らない範囲、合否条件、判断する人と日付が書かれていることが重要です。この四つが書けない状態で細部を詰めても、後で作り直すことになります。
Otsumuに相談できること
計画書の下書きには、無料のPoC計画書テンプレートを使えます。
OtsumuのPoC / MVP Sprintは、この記事の段階に沿って、検証目的・機能範囲の合意、主要画面と利用シナリオ、検証用のPoC / MVPシステム、効果測定の項目・計測設計、公開・運用に向けた引き継ぎ、検証結果と次フェーズの改善方針までを成果物としています。参考価格は税別300万円〜で、6週間を目安に設計します。機能数・外部連携・セキュリティ要件で変動し、正式な見積もりは相談後にお出しします。
テンプレートを埋めて社内で進められるなら、それがもっとも早い方法です。問いが絞れない、合否条件の水準が決められない、作る体制がない、といった場合は、30分の無料診断でご相談ください。
この記事について
Otsumu株式会社が執筆しました。統計値や他社の事例には依拠せず、進め方と判断の枠組みを中心にまとめています。記載の価格はOtsumuの税別・参考価格で、正式なお見積もりはご相談後にご案内します。法務・税務・会計・補助金などの制度は、専門家や公的窓口で最新の情報をご確認ください。
執筆：Otsumu株式会社 ／ 編集日 2026.09.21