PoC

一言でいうと

考えた方法が実際に成り立つかを、小さく作って確かめる活動です。

提唱者と登場年

英語版 Wikipedia は、この語が1967年以降に使われているとし、1969年の米国議会の公聴会が「新しい概念の実現可能性を探り、示すために実験的なハードウェアを製作して試験する開発段階」と定義した記録を挙げています。もとは工学の領域で、作り切る前に成り立つかどうかを確かめる段階を指す言葉でした。

ソフトウェアの領域では、主に技術的・運用上の実現可能性の確認に使われます。利用者の反応を確かめることが主目的であれば、プロトタイプ検証や MVP と区別して目的を定めます。同じ記事は PoC・プロトタイプ・パイロットを区別していますが、検証する対象が違うだけで、どれをどの順で置くかは案件ごとに決まります。

何を解決するか

不確かな前提のまま本開発へ進むと、後から作り直す事態が起こります。新しい技術を使う場合、外部のシステムと接続する場合、扱うデータの量が読めない場合に、この危険が大きくなります。

PoC は、その不確かさを最初に減らします。確かめる対象を1つか2つに絞り、それだけを検証できる最小の形を作ります。

実際の進み方

先に「何が確かめられたら成功か」を決めます。この判定条件を決めずに始めると、動くものができた時点で成功とみなされ、本来の問いが残ります。

次に、判定に必要な範囲だけを作ります。判定条件に直接関係しない画面や運用機能は対象から外します。認証や運用そのものが検証の対象であれば、必要な範囲だけを含めます。

最後に結果を記録します。成り立たなかった場合も結論です。取りやめる判断ができるように、結果と判断の理由を文書に残してください。

導入でよくある失敗

• 判定条件を決めずに始め、「動いた」で終わらせる
• PoC で作ったものをそのまま本番へ持ち込む。運用と保守の設計が入っていません
• 検証の対象を広げすぎて、期間が本開発と変わらなくなる
• 取りやめる選択肢を用意せず、結果にかかわらず本開発へ進む

求人票にこの語がある場合に読み取れること

新しい技術の導入や、顧客ごとの個別検証を扱う求人で使われます。この語がある場合、仕様が固まっていない状態で技術の当たりを付ける仕事が含まれると読み取れます。応募者の経歴では、判定条件を誰が決めたか、取りやめた経験があるかを確認してください。取りやめの判断を経験している人は、検証の設計を理解しています。

隣接手法との違い