システム開発の
PoCとMVPの違い
- PoC（Proof of Concept） —
「技術的に 実現できるか」 「その 方法で 効果が 出るか」を 確かめる 試作。 使うのは 社内の 限られた 人だけ - MVP（Minimum Viable Product） —
「実際の ユーザーが 使うか」を 確かめる 最小限の 製品。 本物の ユーザーに 使って もらいます
どちらも
小さく作るべきケース・そうでないケース
向いているケース
- AI・
自動化など、やってみないと 精度が 技術を分からない 使う - 社内に
前例が なく、 要件を 文章で 固めきれない - 投資判断
（経営会議・稟議）の ために 説得材料が 必要 - 複数の
やり方が あり、 どれが 現場に 合うか 決めきれない
向いていないケース
- 要件が
明確で 前例も 多い 定型システム （勤怠・経費精算など） — 既製の SaaS導入が 先です - 法令
対応など 「やるかどうか」に 選択肢が ない もの
PoCの進め方（2〜4週間が目安）
- 確かめたい
仮説を —1つに 絞る 「AIで 請求書の 仕分けが どこまで 自動化できるか」のように 具体的に。 仮説が 3つ あるなら PoCを 3回に 分けます - 成功の
目安を —先に 決める 「精度90%以上」 「処理時間を 半分に」など、 終わった ときに 判断できる 基準を 書面にします - 本物の
データで — サンプルデータでの試す デモは 仮説検証に なりません。 実データ・実業務で 確かめます - 「進める
・ — やめる変える ・やめる」を 判断する 判断が できた PoCは 失敗ではなく、 数千万円の 損失を 数十万円で 回避した 成功です
「PoC貧乏」を避けるために
一方で、
発注時の注意点
- PoCの
成果物の — ソースコードと権利を 確認する 検証データが 自社に 残る 契約に なっているか - 本開発の
概算を — PoCのPoC終了時に 出して もらう 結果を 踏まえた 見積もりは 精度が 段違いです - 作り捨て
前提の — PoCは部分を 明示して もらう 速度優先で 作る ため、 本開発で 作り直す 部分が あるのは 健全です。 それが 最初から 示されている ベンダーは 信頼できます
まとめ｜大きな契約の前に、小さな検証を
シャノンの