実現性検証とテーマが決まっているPoCにアジャイルは関係しない

Poc（Proof of Concept）についてはどのくらいのエンジニアが知っているだろうか。例えば、実現したいシステム化要件があり、それが本当に実現できるか小規模な環境を作り、そこで実現方式が実装できるか実装し、評価する。

その結果を踏まえた上で、本格的にプロジェクト化するかを意思決定するのである。

つまり、PoCは委託側のリスク対策として行う。

ところが、である。

　PoCをいくら実施しても、その先が続かない。ベンダーに対価を支払って支援を仰ぐのであれば、リターンを得るどころかお金が出ていくばかり。これがPoC貧乏の実態だ。こうした状況は珍しくないと、講演者は強調する。

tech.nikkeibp.co.jp

その点から言えば、引用している記事は間違いである。間違いはいくつかある。

PoCは委託側の都合で行う

冒頭にも書いたが、PoCは委託する側がいきなりプロジェクト化して失敗するリスクを識別しているからPoCを行うのであって、ベンダ側の都合ではない。

意思決定するのはどんな場合でも、最終的には発注する委託側である。

ベンダ側もPoCを提案することがあるが、それは、要件が曖昧だとか、要件での実装をしたことがないためとか、起因は委託側の要件である。その要件をベンダのソリューションで実現するには確信が持てないからPoCを提案して、ベンダ側のリスクを下げようとするのである。

その後が続かないと書かれているが、それはPoCで期待する結果が得られていないからではないのか。

つまり、PoCとしての成果である実現性検証はできているのである。ただ、結果は本格的なプロジェクトに進めてはいけない結果になったからPoCでおしまいにするのである。

もし、PoCで期待する結果を得られたなら、本格的なプロジェクト化のための予算を確保し、PoCをやったベンダに特命で発注するか、競争入札すれば良いのである。

PoCはコンセプトが実現できるかを検証するのであって、必然的に最小の論理的には本番と同じ構成にするのが望ましいが、スピードと小さな予算で行う（条件付きで制限を設けることがある）ため、環境に制限を設けることが多い。

タスクも実証できるかテーマを決めるので、検証のスコープは決まっている。

これを実現したいのか、ではなく、技術検証として確かめたいテーマを実装できるか、できたところで期待する動作をするかを確かめるのである。

よって、全くアジャイルは必要ない。

この記事はPoCの考え方を知る上で、お勧めできない。