はじめに

　既にクラウドが広く普及しており新技術が次々に誕生する近年では、新しいサービス企画や新技術導入の際、事前に実現可能性や期待する効果が本当に得られるのかを検証する事を目的にPoCを実施するケースが増えてきました。
　私は実際にPoCに参画はしたことがありますが、PoC実施計画を立てた経験がありませんでした。
そのため、どんな観点で何に留意して進めるのが適切なのか、そもそもPoCとは何かをきちんと理解せずに、なんとなく参画していました。お恥ずかしい…...
　そこで、「PoCとは何か」今一度、整理したので執筆します。
同じようにPoCに何かしら関わる方々のために、PoCへの理解を深めるのにお役に立てれば幸いです。

PoCの語義

　用語の定義は以下の通り。

用語(略)	原語	読み	和訳
PoC	Proof of Concept	ポック,ピーオーシー	概念実証

　PoCとは「新しいシステムの構築に用いる新しく導入する概念やアイデアについて、必要最小限で実現化を検証する作業」を指す。
　PoCの結果を以て、実現可能性や実用性が「有る」と判断されれば、次の段階に進むことができる。
　_{※ 次の段階とは、例えば、実プロジェクトのシステム要件決定やプロトタイプ開発等が想定される。}

　プロトタイプ(試作品)は完成品に近づけることを目的に検証サイクルを回しているのに対し、PoCはあくまで実現可能性判断や実現方式の確立のために検証サイクルを回す点が異なる。
　_{※ プロトタイプの前段階にPoCが必要となる例もある。}

PoCのメリットと重要性(目的）

　実プロジェクトの予算とは別に、わざわざ予算と時間を別枠で確保してPoCを実施するメリットとその重要性とは何でしょうか。様々な目的がありますが、一般例をいくつ挙げます。

新しく導入する概念やアイデアが、実プロジェクトに適用可能か、技術的確証に基づいて投資判断ができる。
課題の早期発見や解消に繋げられるため、実プロジェクトの不確実性を減らす。
より実現性や生産効率の高い手法をPoC段階で探れるため、実プロジェクトでの無理・無駄・工数削減につながる。
その後に発足する実プロジェクトの工数見積もりも、PoCの実績根拠に基づいたより精緻な見積もり数値になる。
PoCで浮き出た課題の解消が難しければ早期に撤退判断を行い、実プロジェクトに移す前段階で、失敗や損失のリスクを最小限に抑えることが出来る。
PoCで実現性があることがわかった場合は、これを周知することで会社の知名度を上げることが出来る。
_{※ 上記以外にも、実際のPoCによって目的は様々で他にもあるかもしれません。}

PoCのデメリットと注意点

　試行錯誤を繰り返して実現方式を確立していくPoCの場合、検証回数が増えるほど期間とコストが増えていく。結果的に実現性の確証が得られても、PoCにかかったコストを回収するのに想定以上に期間を要する事態になりかねない。
　これを回避してPoCのメリットを最大化するために、目的やPoCの評価項目や達成基準をあらかじめ明確に定義した上で、PoCで使える予算を明確にして費用対効果のバランスを確認しながら取り組むことが重要。

PoCの実施手順

①実施計画の策定フェーズ

PoCの目的とゴールを明確にして、ステークホルダーやメンバーの認識を一致させる。
【PoC計画書の目次構成と記載内容の例】

目次	記載内容の例
PoCの目的・ゴール	検証目的や目標ライン、達成後の動き
スコープ	PoCの中で検証対象とする機能範囲
実施内容	使用するデータや具体的な検証内容、手順、検証結果評価項目・達成基準
想定リスク	事前に想定しうるリスクや課題。予算上限枠を記載。
環境	検証用の環境、システム構成
PoCに必要な準備	事前準備や必要な契約手続きがあれば。
体制・役割	実施体制、役割分担、検証結果判断ルート
スケジュール	準備・実施・評価のスケジュール
管理・運営方法	コミュニケーション管理、進捗管理方針など

評価項目が多い場合は計画書とは別紙にして、評価項目シートにリストアップすると良い。

②実施フェーズ

計画内容に沿って、できるだけスピーディーに試行錯誤を短期間で繰り返して、実現方式の確立を目指す。
評価結果報告に添付すべきエビデンスはログや画面キャプチャやビデオ等を保存。
技術的な実現可能性とは別に、評価項目が使用感や操作感など利用者によって個人差や偏りがある項目であれば、なるべく多くのメンバーが参画して評価した方が、客観的で精度の高い検証結果につながる。

③検証結果の評価フェーズ

評価項目シートに結果を記入し、計画書と相対して評価結果のサマリー報告資料を作成する。
ステークホルダー間で審議を行い検証結果判断を経て、次のアクションへ。
💡PoC実施内容がモデルケースである場合や、社外にプレスリリースする場合等含め、きちんと資料化しておくことでナレッジ共有にも役立つ。

PoC実施におけるアンチパターン

実プロダクトにおいて何を判断するためのPoCなのか目的が見失われ、PoCで動くものを作成したり技術を導入すること自体が目的に置き換わっている。
検証目的(ゴール)が不明瞭なまま、参画メンバーが始動している。(Why×Whatが抜けてHowに固着)
一部の関係者が無視されて視野の狭い検証になっている。
評価や達成基準がなく「まず使ってみる」ことが目的となっている。
😣このようなPoCを実施してしまうとPoCの目的やメリットを最大限に享受できず、PoC疲れ、PoC止まり、PoC貧乏に陥ります。

PoCのメリットを最大限に享受するためのポイント

検証目的(ゴール)、Why×Whatを明確にする。
スモールスタート×短期間で、Howを試してサイクルを回す。（アジャイル開発の要領で）
問題発見や失敗事例もネガティブではなく有益な実験データ結果として受けとめるスタンスが重要。素早く情報共有して皆でアイデアを出し合って解決したり、方式を軌道修正して次のサイクルを回転させるスピードアップになる。(初めから成功するならPoCは要らぬ)
上記に併せ、心理的安全性の高いチーム、失敗もオープンに賞賛する文化があると尚良い。
実現性が見えなかった場合の、撤退判断のボーダーラインも明確にしておくと、無理無駄を最小化できる。
システム担当たけでなく、実際の現場の利用部門にも参画が可能ならばフィードバックを得られるため、より実プロジェクトに有用なPoC評価結果につながる。

Appendix

システム開発以外のPoCの例

医療業界

新薬の研究開発では数年～十数年のスパンで開発を行われる。第Ⅰ相試験の試験後に進む「早期第Ⅱ相試験」のことをPoCと呼んでいる。その結果、有用と安全性が認められると「PoCを取得した」として、最終段階へ進むことが出来る。

映画業界

120分の長編映像の製作費は莫大なコストがかかるため、まず短編映像を制作してPoCを行って、視聴者の反応を見るとともに資金を集めやすくする。

研究開発

研究分野では主に予算獲得のためにPoCが行われる。実現可能性が示されることで周囲の理解を得やすくなり、予算獲得につながる。
例えばバイオテクノロジーやロボット開発など様々な研究分野でPoCが行われる。

最近、話題沸騰中のAI導入に関するPoC相談の需要が高まっていくであろうことも、想像に難くありませんね🥳

用語(略)	原語	意味
PoV	Proof of Value	ユーザー視点で顧客価値があるかを検証
PoB	Proof of Business	ビジネスの視点で事業の有効性を検証
PoT	Proof of Technology	技術的な検証

用語	意味
プロトタイプ	実現性やコンセプトが確立した上でより精度の高い完成品を目指す制作物
実証実験	実用前段階に、実用化に向けた問題点を洗い出す検証
MVP開発	Minimum Viable Productの略で、訳すと「最小限の利用可能製品」。ユーザーからの反応をテストしながら改善を繰り返す手法。アジャイル開発に類似する手法だが、アジャイル開発では1～2週間の納期遵守で顧客に価値をデリバリーするのに対し、MVP開発はユーザーからの反応や検証の評価結果に重点を置いている点が異なる。

まとめ

まとめ
PoCとは
「新しいシステムの構築に用いる新しく導入する概念やアイデアについて、必要最小限で実現化を検証する作業」である。

💡ポイント
PoC実施計画の段階で、目的やゴール(What)、何故何のために(Why)を明確化
スモールスタートで短期間サイクル（アジャイル）で実施
必要最小限のコスト・期間で行い、費用対効果のバランスを意識
利用部門からの評価を得たい場合は、できるだけ多くの方に検証してもらう

以上

PoCの目的と進め方のポイント