PoC開発

PoCの意味と、新規事業での位置づけ

PoCは「概念実証」と訳されます。アイデアや技術が、考えたとおりに成り立つかを、本番より小さな規模で確かめる取り組みです。IT・製造・医薬品・サービスなど、業界を問わず使われます。

新規事業の工程の中では、アイデアを出して仮説を立てたあと、プロトタイプやMVPで顧客に出す前に置かれます。この段階で確かめたいのは「作れるか」だけではありません。作ったものが事業として成り立つ前提（顧客が困っているか、払う理由があるか、費用が見合うか）のうち、机の上では答えが出ないものを、実物で確かめます。

PoCの成果物は、動くデモではなく「次に進むかを決められる証拠」です。動いたかどうかより、何が確かめられ、何がまだ確かめられていないかを残すことが、この工程の仕事です。

PoC開発で作るもの・作らないもの

PoC開発で作るのは、確かめたい前提を測るのに必要な最小の仕組みです。画面が粗くても、計測の仕込みと、本番に近い条件で動かす部分は手を抜きません。逆に、ログイン・管理画面・大人数での同時利用への備えなど、確かめたい前提と関係の無い部分は作りません。

PoCのために作ったものを、そのまま本番に使うかどうかは、始める前に決めます。捨てる前提なら速さを優先し、育てる前提なら本番に残す骨組みを最初の1本だけ通します。この宣言をしないまま進めると、動いたデモを見た経営層から「これを本番化しよう」と言われたときに、作り直しが必要だと説明できなくなります（記事「PoC疲れ」で扱った実例です）。

不確かさが大きいほど、作る前に確かめる価値が上がる

既存事業の改善と違い、新規事業には「顧客が本当にいるか」「その価格で払うか」「その技術で必要な品質が出るか」といった、答えの分からない前提がいくつも重なっています。全部を一度に本番の規模で作ってから確かめると、外れたときの損失が大きくなります。

PoCは、その前提を一つずつ、外れても損失が小さい規模で確かめるための工程です。前提の誤りに早く気づけるほど、同じ予算で試せる回数が増えます。

作る費用が下がり、判断の速さが問われるようになった

生成AIや既製のクラウドサービスの普及で、動くものを作る費用と時間は下がりました。その結果、PoCそのものは以前より気軽に始められます。一方で、作った結果をもとに社内で判断する速さは変わっていません。

作るのが速くなった分、PoCが積み上がって判断が追いつかない状態（PoC疲れ）が起きやすくなっています。PoCの数を増やすより、1本ごとに判断まで終わらせる設計が必要になっています。

社内の決裁と予算の条件を、検証の前に整理する

大企業の新規事業では、検証の結果が良くても、決裁の単位が大きく次の予算が付くまで時間がかかることがあります。PoCを始める前に、誰が次の判断をするか、判断に何が必要か、予算がいつ付くかを確認しておくと、検証が終わったあとに止まりません。

PoCと実証実験の違い

PoCは「成り立つか」を確かめ、実証実験は「実際の現場で運用が回るか」を確かめます。実証実験は、自治体や交通、医療など、実際の利用者や地域を巻き込んで一定期間運用してみる取り組みを指すことが多く、PoCより規模も期間も大きくなります。PoCで前提を確かめ、実証実験で運用を確かめる、という順に並ぶのが一般的です。

PoV（価値実証）・PoB（事業実証）との関係

PoCを細かく分けて、PoV（Proof of Value／価値実証：顧客にとって価値があるか）とPoB（Proof of Business／事業実証：事業として利益が出るか）と呼ぶことがあります。技術が成り立つか（狭い意味のPoC）、顧客が価値を感じるか（PoV）、事業として回るか（PoB）の順に確かめる考え方です。

言葉を分けること自体より、いまの検証がどれを確かめているかを一文で言えることが大切です。技術のPoCに成功しただけで「価値も事業も確かめた」と扱うと、次の段階で同じ検証をやり直すことになります。

PoC開発とアジャイル開発の違い

アジャイル開発は、短い区切りで作っては直すことを繰り返す「作り方」です。PoCは「何を確かめるための工程か」を指す言葉です。両者は対立するものではなく、PoCの中でアジャイル開発の進め方を使うこともよくあります。違いは終わり方で、アジャイル開発は製品を育て続けるのに対し、PoCは判断が出た時点で一度終わります。

PoCからMVPへ渡すもの

PoCが終わったら、確かめられた前提・確かめられなかった前提・残っている課題を、次の工程（プロトタイプやMVP）に渡します。PoCで作ったものを捨てる場合も、計測の結果と学びは捨てません。PoCで技術の前提が確かめられた範囲だけを、MVPで顧客の行動として確かめる、という分担にすると、同じことを二度確かめずに済みます。

メリットは「条件つき」で効く

PoCのメリットとしてよく挙がる「コスト削減」「リスクの低減」「意思決定の円滑化」は、どれも自動では得られません。外れたと判断する線を先に決めていなければ、前提が外れても検証が続き、費用はむしろ増えます。表の右の列が、それぞれのメリットが効くための条件です。

いちばん大きなデメリットは、PoCの目的化

情報漏えいや費用の増加は、契約と上限の設定である程度防げます。防ぎにくいのは、PoCを実施したこと自体が成果として扱われ、次の判断が先送りされることです。報告会で「感触は良かった」と締めくくられたPoCは、ほぼこの状態です。PoCの最終日に、事業化・再検証・撤退のどれかを決める会議を、始める前から予定に入れておくことが一番の対策です。

作らずに確かめられるなら、作らない

顧客の需要を確かめたいだけなら、紹介ページと申込みボタン、聞き取り、手作業でのサービス提供など、作らずに確かめる方法のほうが早く安く済むことがあります。PoCは「作らないと確かめられない前提」を確かめるときに使います。

外部に相談したほうがよい場面

新しい技術を使いたいが実現の方法が分からないとき、本開発に投資するかの判断材料が欲しいとき、要件が固まっていないとき、過去の開発で失敗した経験があるときは、PoCの設計から外部に相談すると、検証の範囲を絞りやすくなります。

「具体性」の検証：現場で本当に使えるか

上の3つに加えて、実際の現場の業務や顧客の流れに組み込めるかも確かめます。数字が出ても、どの画面で使うのか、誰が結果を受け取るのか、例外が出たら誰に回すのかが決まっていなければ、本番では使われません。PoCの段階で一度、現場の担当者に実際の手順で触ってもらうことを勧めます。

比べる相手（いまのやり方）を先に測る

新しい仕組みの数字だけでは、良いか悪いかを判断できません。いまのやり方での処理時間や手戻りの割合を、PoCを始める前に測っておきます。比べる相手が無いPoCは、終わったあとに「良くなった気がする」以上のことを言えません。

PoCで確かめられることは、3つの層に分かれる

記事「AI PoCの進め方」で整理したとおり、PoCで確かめられることは、精度などの性能（第1層）、業務に乗るか（第2層）、運用が続くか（第3層）に分かれます。第1層は道具がそろっていて測りやすく、第2層は実データを流せば見えますが、第3層はPoCの期間内には見えません。PoCで「確かめた」と言えるのは第1層と第2層までで、第3層は本番に移ってから測る前提で計画します。

いちばん飛ばされるのは「終わり方」

計画書の中で最も書かれないのが、最後の「終わり方」です。判定会議の日を始める前に予定に入れておくだけで、PoCが報告会で終わる失敗のかなりの部分が防げます。会議には、次の予算を決められる人に出てもらいます。

データと検証の環境の用意

PoCの期間を最も左右するのは、技術ではなくデータの準備です。使えるデータがあるか、量と質は足りるか、使う権限があるかを、作り始める前に確かめます。データを集めるところから始めるPoCは、期間の見通しが立ちません。また、きれいに整えたサンプルだけで動かすと、本番の入力で崩れます。本番に近い、乱れたデータで一度は動かします。

AIを検証の手段に使う場合に、追加で決めること

AIを使う場合は、正答の割合だけでなく、処理の速さ、1件あたりの費用、例外が出たときの扱いまでを合格の条件に入れます。正答の割合が高くても、処理に1件30秒かかれば現場では使えません。また、AIに入力してよい情報の範囲と、データの送信先（どの国の、どのサービスか）を、作り始める前に決めます。

結果が線に届かないとき

結果が合格の線に届かないとき、機能を作り足すのは多くの場合誤りです。まず、前提そのものが間違っていたのか、測り方に問題があったのかを分けます。前提が外れていたなら再検証か撤退、測り方の問題なら測り方を直して、期限の範囲で測り直します。

業務を変える権限を持つ人を入れる

PoCの結果が良くても、業務の流れを変える権限を持たない部署が担当していると、本番に進めません。PoCの対象を選ぶ段階で、結果が出たときに業務を変えられる人を体制に入れておくことが、本番に進むための条件になります。

見積もりの内訳の見方

PoCの見積もりは、おおむね「設計（前提・検証項目・計画）」「データの準備」「作る工程」「測って判定する工程」に分かれます。金額の大小より、測って判定する工程が見積もりに入っているかを確認してください。作る工程だけの見積もりは、動くものは手に入っても、判断の材料が手に入りません。

記事「PoC止まりの正体」で書いたとおり、見積書に「残りの例外を誰が扱うか」の行が無いことが、本番で止まる原因になることもあります。

期間の目安と、延びる理由

確かめる前提を絞った場合、設計に2〜4週間、作って測る工程に1〜2か月が目安です。期間を決めているのは、技術よりデータの準備状況と、社内の判断の速さです。期限と延長の条件は計画書に書き、延長は判定会議で決めます。

費用の上限は、撤退の線とセットで決める

PoCの費用の上限は、新規事業全体の撤退基準（累積の赤字の上限）から逆算すると決めやすくなります。上限に達した時点で何を判断するかを、事前に決めておきます（記事「新規事業の撤退基準」で計算の手順を扱っています）。

ARCHECOの契約の形

ARCHECOで選べる契約の形は、このページの下の「ARCHECOの契約モデル」にまとめています。検証の範囲がまだ固まっていない段階でも、ご相談いただけます。

小さく始め、早く外す

最初のPoCは、確かめる前提を1つ、対象の業務や顧客を一つに絞ります。複数を同時に確かめると、結果が出たときに何が効いたのか分からなくなります。外れることを前提に、外れたときに失うものが小さい範囲で始めます。

本番に近い条件で測る

整えたサンプルデータと、決まった手順で触る担当者だけでは、本番で起きることが見えません。実データ、実際の現場の担当者、例外が起きる状況を、PoCの中で一度は通します。

線と期限を、判断する人と合意する

合格と不合格の線、期限、費用の上限を、作る人どうしではなく、次の判断をする人と合意します。合意した線は、PoCの途中で動かしません。動かす場合は、判定会議で理由を残して決め直します。

捨てるか育てるかを、最初に宣言する

PoCで作ったものを捨てる前提か、本番に育てる前提かを、始める前に決めます。育てる前提なら、本番に残す骨組みを最初に1本だけ通します。捨てる前提なら、期限を切って捨てます。

PoC疲れ・PoC止まり・PoC死・PoC貧乏の違い

PoC疲れは、PoCを何度も繰り返しても事業化に進まず、組織が消耗している状態を指します。PoC止まりは、個々のPoCが成功しても本番に進まない状態を指します。PoC死・PoC貧乏も、ほぼ同じ状態を指す言葉として使われます。呼び方は違いますが、原因はほぼ共通していて、検証と次の判断がつながっていないことです。

すでにPoCが積み上がっている組織の立て直し

過去のPoCを責めるところからは始めません。いま宙に浮いているPoCを「捨てる」「育てる」「保留」に仕分けし、捨てるものには期限をつけます。そのうえで、次に始める1件だけでよいので、始める前に前提と出口を文章にします。1件でも最後まで通ると、組織の進め方が変わります。

判定会議の進め方

判定会議では、決めた線と結果を並べ、3択のどれかを決めます。「もう少し様子を見る」は選択肢に入れません。続ける場合は、何を、いつまでに、いくらで確かめるかを決め直します。撤退も成果で、やめると分かったことで、次の検証に予算を回せます。

本番に進むときに、追加で必要になるもの

PoCで確かめられなかった層（運用が続くか）は、本番に移ってから測ります。本番では、例外の行き先、データの更新、利用者の問い合わせ、監視と障害対応など、PoCでは作らなかった部分が必要になります。発信元（ARCHECO）の自社開発の記録では、5か月の開発で機能の追加808件に対して修正728件、データベースの構造の変更が188回ありました。PoCで動いたものを本番に持っていく過程で、作ったのとほぼ同じ量の修正が発生します。この距離を見積もりと予定に入れておきます。

実例：大手旅行会社との共創事業

大手旅行会社との共創事業では、5週間で正式版に近い水準のMVPを作り、実際のホテルの利用者と管理者に提供しながら検証を進めました。検証の後半では、部屋への案内とドアノブに吊るチラシで接点を2つ変えたあと、後半11日間で受注が17件（前半13日間の2件に対し期間比850%）になりました。作る工程より、顧客との接点を変えたことが数字を動かした例です。

選ぶときに確認すること

提案の場で、確かめたい前提の中身を質問してくるかを見ます。要件を渡したらそのまま作る会社は、通常の開発では正しくても、PoCでは前提そのものを疑わずに作ってしまいます。あわせて、同じ領域での実績、データの扱いの決まり、本開発に進む場合に引き続き頼めるか、自社に知見を移してくれるかを確認します。

依頼する前に用意するもの

確かめたい前提の一文、合格と不合格の線の案、予算の上限、使えるデータの一覧があれば、複数の会社から比べられる提案を受けられます。依頼書（RFP）にこの4つを書き、2〜3社から提案を受けて比べることを勧めます。

情報漏えいと権利

PoCでは、社内のデータや未公開の構想を外部と共有することがあります。共有する情報の範囲、保管と削除、外部のAIサービスに送ってよいかを、契約と計画書の両方に書きます。作ったものと知見の権利がどちらに属するかも、始める前に決めます。

期待を上げすぎない

PoCの結果は、限られた条件での結果です。小さな環境で動いたことを、本番の規模や顧客の需要まで確かめたことにはしません。報告では、確かめた前提と、まだ確かめていない前提を必ず分けて書きます。

費用が膨らむのを止める

前提が外れたときに作り足して取り返そうとすると、費用が膨らみます。上限に達したら、作り足す前に判定会議を開くことを、計画書に書いておきます。