BLOG

PoCとMVPの違いとは ― 目的・期間・進め方の比較

「まずPoCをやりましょうと言われたが、MVPとどう違うのか」「PoCは成功したのに、その先に進まない」。新規事業やAI導入のご相談で、この2つの言葉の取り違えから始まる行き違いをよく見ます。

PoC(Proof of Concept、概念実証)は「その方式で作れるか」を確かめるもので、MVP(Minimum Viable Product、実用最小限の製品)は「作ったものが使われるか」を確かめるものです。確かめる問いが違うので、期間も、進め方も、終わり方も違います。

この記事では、PoCとMVPのそれぞれの目的、期間と進め方の違い、PoCで止まってしまう理由、どちらから始めるかの選び方、そして契約の形との関係を、両方を支援している当社の視点で整理します。

PoCは「作れるか」を社内で確かめる技術の関門、MVPは「使われるか」を実際のユーザーで確かめる事業の関門。いま一番大きい不確実さがどちらにあるかで選ぶ

言葉の使い分けとして、PoCは「概念実証」、MVPは「実用最小限の製品」と訳されますが、実務ではどちらも「小さく作って確かめる」と説明されるため、違いが見えにくくなっています。何を確かめるのかで区別するのが、いちばん確実です。

この記事を書いた人

wesionaryTEAM 編集チーム

株式会社wesionaryTEAMのプロジェクトマネージャーとエンジニアで構成する編集チームです。業務システム開発、AI導入支援、DX推進の案件で日々得ている知見をもとに、検討中の方が判断に使える情報を、事例と数字を添えてお届けします。

PoC(概念実証)とは

PoCは、ある方式や技術で目的のことが実現できるかを、小さく作って確かめる取り組みです。手書きの伝票をAIで読み取れるか、既存の基幹システムからデータを取り出せるか、必要な速さで処理できるか、といった技術的な問いに答えます。

使うのは社内の担当者や限られた協力者で、作るのは検証したい部分だけです。画面の見た目や運用の仕組みは作り込みません。終わり方は「できた・できなかった」と、その条件(精度、速さ、費用)の記録です。

期間は数週間から2、3か月が目安です。問いが一つに絞れていれば短く、絞れていなければ長引きます。

MVP(実用最小限の製品)とは

MVPは、事業の仮説を確かめるために必要最小限の機能だけを備えた製品を作り、実際のユーザーの反応で判断する進め方です。この言葉を広めたエリック・リースは2009年に、MVPを「最小の労力で、顧客についての検証済みの学びを最大限に集められる、新製品のバージョン」と定義しました。IPA(情報処理推進機構)のモデル契約書でも、MVP開発は実用最小限の製品を開発することと説明されています。

使うのは実際のユーザーで、作るのは価値が届く最小限の製品です。見た目や運用は最小限でも、使い続けられる品質までは作ります。終わり方は、使われたかどうかの数字と、続ける・変える・やめるの判断です。

期間は、範囲を絞れていれば数週間から3か月程度が目安です。伸びる主な原因は実装量より、仕様が決まらない待ち時間です。進め方の詳細はMVP開発とは何かにまとめています。

目的・期間・進め方の比較

PoC(概念実証)MVP(実用最小限の製品)
確かめる問い作れるか使われるか
誰が使うか社内の担当者実際のユーザー
作るもの検証したい技術部分だけ価値が届く最小限の製品
終わり方できた・できなかったの記録数字と、続ける・変える・やめるの判断

見た目や操作の流れを確かめるプロトタイプは、この2つとはまた別で、動かない画面で社内の関係者と確認するものです。

PoCとMVPの進め方

PoCは、次の4つの手順で進めます。

  • 問いを一つに決める。「手書き伝票を読み取れるか」のように、答えがはっきり出る問いにします。
  • 成功の基準を先に書く。精度、速さ、費用の数字と、達成したら何を判断するかを決めます。
  • 本番に近いデータで試す。きれいなサンプルではなく、現場のデータと量を一部でも使います。
  • 結果と条件を記録する。できたかどうかだけでなく、どの条件でできたかを残し、次の判断に渡します。

MVPは、検証したい仮説を一つに絞ることから始めます。その仮説を確かめるのに要る機能だけを選び、使い続けられる品質で作り、実際のユーザーに使ってもらいます。計測の仕組みを最初から入れ、数字をもとに続ける・変える・やめるを判断します。

どちらも、期間と費用を決めているのは作る量より「問いが一つに絞れているか」です。問いが複数あると、作るものも確かめることも増え、期間が伸びます。

PoCで止まってしまう理由

PoCが成功したのに本番に進まない、いわゆるPoC止まりには共通する原因があります。

  • 技術の問いしか立てていない。読み取れることと、現場が使い続けることは別の問いです。PoCの計画に「成功したら誰が何を判断するか」が書かれていないと、成功しても次が始まりません。
  • 成功の基準を後から決めている。精度が何%なら進めるのか、費用がいくら以内なら成り立つのかを、始める前に決めておく必要があります。後から決めると、結果に合わせて基準が動きます。
  • 本番の条件を外している。きれいなサンプルデータで試し、実際の現場のデータでは動かない、というずれです。PoCの段階で、本番に近いデータと量を一部でも使います。
  • 現場を巻き込んでいない。情報システム部門だけで進めたPoCは、成功しても現場の業務に入る段取りがありません。PoCの段階から、実際に使う部署の担当者に試してもらい、本番で誰が運用するかを決めておきます。
  • PoCを繰り返してしまう。一つ終わるたびに次の技術を試し、事業の問いにいつまでも進まない状態です。技術の不確実さが十分に下がったら、次はMVPで事業の問いに移ります。

どちらから始めるか

いま一番大きい不確実さがどこにあるかで選びます。

  • 技術に不確実さがあるなら、PoC。前例のないAIの精度、外部システムとの接続、処理の速さが成り立つか分からないときです。
  • 事業に不確実さがあるなら、MVP。技術的には作れると分かっていて、使う人がいるか、使い続ける理由があるかが分からないときです。
  • 両方あるなら、PoCを短く終えてからMVPへ。PoCの期間は最小限にし、事業の問いに早く移ります。
  • どちらもないなら、どちらも要りません。作るものが決まっているなら、通常の開発に進みます。

多くの業務システムでは、技術的には作れることが分かっているため、PoCを省いてMVPから始めるほうが早く答えに着きます。AI導入では技術の不確実さが残ることが多く、短いPoCを置く価値があります。

契約の形との関係

PoCもMVPも、結果によって次に作るものが変わります。そのため、決めた成果物の完成を約束する請負契約より、業務の遂行に対して報酬を支払う準委任契約が実態に合います。IPAのモデル契約書(アジャイル開発版)も、準委任契約を前提にしています。

検証を終えて作るものが固まった段階で、本開発を請負に切り替える進め方が一般的です。契約の違いは準委任契約とはと請負開発とはで整理しています。

AIで変わったこと

AIを使った開発で、実装にかかる時間は短くなりました。PoCは数日で結果が出ることも増え、MVPも以前より小さな体制で作れます。

その結果、重みが増したのは「何を確かめるか」を絞る判断です。作れてしまうからこそ、確かめる問いを一つに絞り、成功の基準を先に決める作業が、以前より結果を左右します。当社は事業共創パートナーとして、この問いを絞るところから一緒に関わっています。

よくあるご質問

PoCとMVPは両方やる必要がありますか?

ありません。技術に不確実さがなければPoCは省けますし、作るものが決まっていればMVPも要りません。いま一番大きい不確実さがどちらにあるかで選びます。

PoCとプロトタイプの違いは何ですか?

PoCは技術的に実現できるかを確かめるもので、プロトタイプは見た目や操作の流れを社内で確認するための試作です。プロトタイプは動かないこともあります。

PoCの成功の基準はどう決めればよいですか?

本番で成り立つ条件から逆算します。精度は何%以上、1件あたりの処理は何秒以内、費用は月いくら以内、というように、進める・やめるを判断できる数字で決めます。

MVPで作ったものは、そのまま本番で使えますか?

使える場合と、使えない場合があります。MVPは検証が目的なので、利用者数の増加や止まってはいけない度合いへの備えは最小限にしていることが多く、検証を通過した後に作り替える部分を決めます。

PoCやMVPは、どの契約の形で依頼すればよいですか?

結果で次に作るものが変わるため、準委任契約が実態に合います。作るものが固まった本開発から請負に切り替える進め方が一般的です。

まとめ

PoCは「作れるか」を社内で確かめる技術の関門、MVPは「使われるか」を実際のユーザーで確かめる事業の関門です。問いが違うので、期間も進め方も終わり方も違います。

どちらから始めるかは、いま一番大きい不確実さで決めます。何を確かめるべきかの整理から、無料見積相談で担当PMにご相談ください。PoC・MVP開発の進め方はPoC・MVP開発でも紹介しています。

関連する記事とページ

出典

この記事の監修者

永田 一郎代表取締役

ヤフー(Yahoo! JAPAN)のエンジニア出身。スタートアップ、大手事業会社にて18年以上にわたり、toC/toB向けの新規事業開発、業務DX化など、多種多様なプロジェクトに従事。エンジニアとして自ら開発に携わる一方、体制構築やマネジメント、事業設計、仮説検証にも関わり、事業の立ち上げとグロースを幅広く体得。これまでに三回の事業売却を経験。共創でより効果的にプロダクトをつくり、アイディアをマーケットで検証できることを確信し、共創プラットフォームを提供するため wesionaryTEAM を創業。