上手くいくPoCと失敗するPoCの違い。PoC開発の進め方と工程ごとのポイント

PoCでは、プロトタイプを作る前に、検証する仮説を絞ることが重要です。

この記事では、仮説の整理から本開発へ進むかの判断まで、5つの工程を説明します。

PoCの前に、検証する仮説を絞る

• 失敗するPoC。構想をそのままプロトタイプにします。結果が悪かったとき、どの仮説が外れたのかを切り分けられません
• 上手くいくPoC。プロトタイプの前に、つくらずに確かめられる仮説を減らします。プロトタイプには、プロトタイプでしか確かめられない仮説だけが残ります

たとえば「見積もり依頼メールへの返信をAIで自動化したい」という構想には、少なくとも3つの仮説が含まれています。

• 取引先は、返信が速い会社に発注する
• AIを使えば、返信を書く時間が短くなる
• 営業は、AIが書いた下書きを使う

構想をそのままプロトタイプにすると、結果が悪くても、どの仮説が外れたのか分かりません。プロトタイプの費用が下がっても、この問題は残ります。

プロトタイプで確かめる仮説は、プロトタイプでしか確かめられないものだけに絞ります。

PoC開発はどんな流れで進むのか

PoCは、次の5つの工程で進めます。

1. 現状を理解する
2. 仮説を整理する
3. 検証の範囲を決める
4. プロトタイプをつくる
5. 結果を見て、本開発へ進むか判断する

特に重要なのは、現状の業務を理解し、プロトタイプで確かめる範囲を決める工程です。プロトタイプを作る前に確かめられる仮説を除くと、開発の範囲を小さくできます。

工程ごとのポイント

1. 現状を理解する：現場の担当者にヒアリングし、オペレーションをやってみる

仮説を立てる前に、いまの業務がどう回っているかを、次の2つの方法で理解します。

• 現場の担当者に、いまのやり方を聞く。決裁者と実際に作業する担当者は異なることがあります。時間がかかる作業や、現在の手順になった理由を確認します
• 現状のオペレーションをやってみる。いま人が回している作業を、自分たちで実際にやってみます

ヒアリングに加えて、現状の作業を自分たちでも行います。担当者が意識していない手間や例外を確認し、自動化する箇所が課題に合っているかを確かめます。

2. 仮説を整理する：仮説ごとの要件を定義する

構想に含まれる仮説を1つずつに分け、仮説ごとに、確かめるために何が必要か（要件）を定義します。

そのうえで、仮説ごとに、確かめるのにかかる期間と費用を見積もります。

先ほどの見積もり返信の例なら、3つの仮説それぞれについて、確かめるのに必要なデータ・期間・費用を並べて比べます。

3. 検証の範囲を決める：仮説を減らす

整理した仮説に優先度をつけ、プロトタイプで確かめる仮説を最小限に絞ります。

優先度は、外れたら本開発をやめることになる仮説ほど高くします。工程1で現状を理解した時点で答えが出た仮説は、ここで外します。

4. プロトタイプをつくる：最小限の機能を追加する

仮説を減らしたあとも、プロトタイプに入れたい機能はたいてい多すぎます。入れるかどうかは、「その機能を確かめた結果で、本開発へ進むか止めるかが変わるか」で決めます。

• 判断が変わる機能。プロトタイプに入れます。いちばん不確かな仮説（データが手に入るか、AIの精度が足りるか等）に直結する部分です
• 判断が変わらない機能。プロトタイプから外します。ログイン、管理画面、多くの利用者が同時に使ったときの対策は、本開発で設計できます
• 人手で代わりがきく機能。プロトタイプから外します。集計やレポートは、検証の期間中は人が表計算で作れば足ります

5. 結果を見て判断する：基準を着手前に決めておく

進むか止めるかの基準は、プロトタイプをつくる前に決めておきます。結果を見てから基準を決めると、出た結果に合わせて合格にしてしまいやすいためです。基準の決め方は、生成AIのPoCが本番に乗らない理由で解説しています。

まとめ

1. 現場の作業を確認し、課題を把握します。
2. 仮説ごとに、検証に必要な期間と費用を見積もります。
3. プロトタイプで確かめる仮説と機能を絞ります。
4. 進むか止めるかの基準を、着手前に決めます。
5. 検証結果を基準と比べ、本開発へ進むか判断します。

弊社では、企画からPoC、本番リリース、保守まで対応できます。進め方に迷っている段階でも、まずはお気軽にご相談ください。