PoCとMVP、まず何を確かめる？
ソフトウェアの構想を相談すると、本格的な開発の前にPoCやMVPを提案されることがあります。どちらも範囲を絞ってアイデアを確かめる方法ですが、答えたい問いは異なります。それぞれの目的を理解すると、何を試し、どの結果を投資判断に使うかを整理できます。
1. PoCとは？
PoCはProof of Conceptの略で、日本語では「概念実証」と呼ばれます。簡単にいえば、考えている方法で実現できるかを、範囲を絞って試すことです。ソフトウェア開発では、製品全体を作る前に、不確かな技術上の点を確認するために使われます。
例えば、社内の古いシステムで予定を管理している企業が、Web予約を始めたいとします。Webサイトを作る前に、そのシステムから空き時間を取得できるかを確認する必要があります。PoCでは、すべての画面や帳票を作らず、接続、空き枠の読取り、変更の反映に絞って試せます。以下では、この架空の例を使って説明します。
結果には、確認できたことと残る制約を記載します。空き枠を読めても、二人が同時に選んだ際に枠を確保できるかは別の確認です。試験環境で接続できても、本番利用の権限や条件が整ったとは限りません。未確認の点を残し、システム全体を使えると誤解されないようにします。
2. MVPとは？
MVPはMinimum Viable Productの略で、必要最小限の範囲で利用者に提供し、実際の行動からニーズを確かめるための製品です。「そのアイデアは良いと思うか」と聞くだけでなく、使ってもらった結果から学ぶことを重視します。
予約の例なら、一つのサービスと一部の顧客に限定して提供する方法があります。顧客が日時を選び、情報を送り、確定か確認待ちかを把握できるようにします。予約を完了できるか、どこで困るか、なぜ電話が必要になるかを見て、改善や拡大を検討します。
「最小限」とは、確かめたい行動ができないほど機能を減らすことではありません。予約を最後まで行えるかを知りたいなら、紹介ページとボタンだけでは答えが出ません。一方、裏側の一部を担当者が手作業で処理する方法はあります。その場合は、結果を正しく読み取り、利用者の情報も適切に扱う必要があります。
限定した提供でも、合意した利用条件に応じた情報保護、エラー対応、利用者への支援が必要です。担当者が多くの手順を代行しているなら、その作業も記録します。予約が完了したことと、同じ方法で多数の顧客に対応できることは分けて考えます。
3. PoCとMVPをどう使い分ける？
判断の軸は、プロジェクトの成否に関わる未確認事項です。接続や処理、必要な技術条件を満たせるかが不明なら、PoCでその点を調べます。新しいサービスを利用者が必要とし、実際に使い、価値を感じるかが主な問いなら、MVPを通じた確認が適しています。
古いカレンダーから空き時間を取得できても、顧客が電話の代わりにWeb予約を選ぶかは分かりません。反対に、担当者が毎回予定を確認し予約を手伝えば、需要を探る材料にはなっても、自動連携を実現できたとはいえません。
必ずPoCを行ってからMVPへ進むわけではありません。技術が十分に分かっていて、利用ニーズが主な不確実性なら、独立したPoCが不要な場合もあります。未確認の接続が前提条件なら、それに依存する機能へ投資する前に確かめるとよいでしょう。
4. 始める前に何を決めておく？
開始前に、答えたい問い、実施範囲、期間、予算、結果を確認する人を決めます。予約のPoCでは空き枠を読むだけか、枠の確保まで試すかを明確にします。MVPでは参加する顧客と、どの段階を予約完了とするかを決めます。
データ、アクセス権、支援する担当者も準備します。実際のカレンダーを使えないなら、試験用データとの違いや、まだ判断できない点を記録します。結果を使う人が、その前提条件を理解できることが必要です。
目的に合う試行を提案してもらうには、現在の業務、想定する利用者、接続が必要なシステムを伝える必要があります。何から整理すればよいか迷う場合は、ソフトウェア開発プロジェクトの前に何を準備すべきかが参考になります。機能の一覧だけで話を進めず、業務上の目的を共有するために準備したい情報を紹介しています。
接続できるかだけでなく、空き枠がどのくらい早く更新されるか、接続が切れたときにどうなるかも確認が必要な場合があります。その条件と測り方は、試す前に決めておきます。非機能要件とは？機能以外に決めておきたいことでは、速度や安定性など、機能とあわせて整理する運用上の要件を説明しています。
5. 結果をもとに次の進め方を決める
結果を受け取ったら、最初の問いに戻ります。PoCの報告では、できたこと、できなかったこと、残る条件を確認します。予約のMVPでは、完了状況、利用者が困った点、担当者の支援量を見ます。「デモは動いた」「使いやすいと言われた」だけでは、これらの情報を置き換えられません。
接続が要件を満たさないなら、別の方法や、それに依存する範囲の縮小を検討します。希望する空き枠がなくて離脱するなら、画面の問題と決めつけず提供体制を見直します。完了しても担当者の代行が多ければ、拡大前に運用負担を検討します。
次の判断は、継続、修正して再確認、現在の案の中止などです。試行が成功しただけで計画全体を承認せず、理由と必要な作業を残します。
追加投資を決める際は、ほかに対応を待っているIT施策とも比較する必要があります。ITロードマップ、何から着手する？では、業務上の必要性と実施条件を踏まえた優先順位の考え方を説明しています。試行の結果が良かったという理由だけで、着手順を決めないための参考になります。
本格的に広げる前に、再利用できる部分、作り直す部分、残る試験、運用担当を確認します。PoCのコードをそのまま本番で使えるとは限らず、MVPも試した範囲を超える規模への対応を証明するものではありません。分かっている制約と必要な準備を踏まえて、次の投資を決めます。
ソフトウェアの案はあるものの、何から試すべきか迷っている場合は、改善したい業務と不安な点をFenixへご相談ください。問いを明確にすることで、PoC、MVP、あるいは別の確認方法から、目的に合う進め方を整理できます。
