PoC開発

PoCは、本格的に開発する前に仮説が成り立つかを小さく確かめる工程です。新規事業では需要・技術的な実現性・費用を含む事業の成り立ちを検証し、次へ進むための判断材料を作ります。

技術が動いても、市場の需要や社内の判断が確認できていなければ事業化には進めません。作り込む前に、不確かな前提を確かめる必要があります。決裁や予算の条件も検証の前に整理します。

PoCは仮説や技術的な実現性を、プロトタイプは見た目や操作感を、MVPは実際の顧客の行動を確かめます。目的に合わせて使い分け、検証結果と残る課題を次の工程へ渡します。

小さな検証で前提の誤りを発見できれば、大きな開発への投資を判断しやすくなります。一方、判定基準や期限が無いと検証だけが積み上がります。動くものを作ること自体を成功にしないことが必要です。

需要があるか、技術的に作れるか、費用を含めて成り立つかを分けます。仮説ごとに測る項目・データ・合格と不合格の線を決めます。品質や速度の測定だけで顧客の需要まで確かめたことにはしません。

確かめる仮説を選び、検証項目と判定基準を決め、必要な技術とデータを用意します。小さく作って測り、事業化・再検証・撤退を判断します。AIを検証の手段に使う場合も、実データで品質・速度・費用を測り、入力できる情報と送信先を先に決めます。

確かめたい仮説の数、実データの整備状況、セキュリティの要件で工数が変わります。確かめる仮説を絞った場合、設計は2〜4週間、実装は1〜2か月が目安です。次の工程は結果を見て別に判断します。

本番に近い環境と実データで測り、始める前に判定基準と期限を合意します。小さく始め、結果が基準を満たさない場合は、追加実装の前に仮説を見直します。誰が次の判断をするかも決めます。

検証の成功が「動いた」だけで決まり、その先の意思決定と繋がっていないと、成功した検証も事業化に進めません。判定基準・期限・引き取る担当を決めずに検証を増やすことが、PoC疲れやPoC止まりに繋がります。

最初に決めた線と計測結果を突き合わせます。前提が成り立つなら事業化へ、追加で確かめる必要があれば再検証へ、成り立たないなら撤退へ進みます。段階をまたぐ審査では、未検証の前提も判断する人へ渡します。

自社事業ohbagや自社プロダクトFAM BOXではPoCから本番運用へ進めました。金融と旅行の共創サービスでは仮説設計・検証計画・プロトタイプを扱い、複合事業会社では社内新規事業の仮説検証を行ってきました。業務自動化や社内文書検索の導入とは対象を分けています。

動くものを作れるかだけでなく、検証項目と判定基準を一緒に決められるかを確認します。検証の成果物、データの扱い、次の工程で引き取る範囲を契約前に確かめます。

機密情報の入力範囲と送信先、権利の扱い、検証にかける費用の上限を決めます。小さな環境で動いた結果だけで、本番の規模や顧客の需要まで確認できたとは扱いません。