この記事で分かること
- PoCが終わらず延長され続ける経路(既存記事のIBM Watson事例)
- 自社が「作らない」と結論して終えたPoCの中身
- 中止判断ができた条件
この記事で分からないこと(正直に書く)
- 自社以外の企業がPoCを終えられなかった件数・比率
- 「作らない」という判断が常に正しいとは限らない場面の切り分け
PoCが終わる2つの経路
PoCが終わる経路には、大きく2つある。1つは、中止条件が事前に定義されないまま延長が繰り返され、支出が積み上がった末にようやく終わる経路である。IBM Watson for OncologyとMD Andersonの事例では、テキサス大学監査局の報告書が、中止判断に至るまでの期間と支出が大きかった背景として、事前に定義された停止トリガーが存在しなかった点を指摘している(既存記事を参照)。もう1つは、検証の途中で「これ以上は作らない」という判断を下し、健全に終える経路である。本記事では後者について、自社が実際に下した判断の中身を扱う。
自社が「作らない」と結論した検証
自社はゲーム開発事業者向けに、開発支援AIを自社開発すべきかどうかを判断するための検証を受託した。検証では、実際に試作を組んでいる。具体的には、コンパイル結果を読んでAIが修正し直す自動ループと、エディタの再読み込みをまたいでも接続が切れない仕組みを実装し、動作を確認した(出所: 自社の運用記録、確認日2026-09-06)。試作を実際に動かした上で、既存のオープンソースのツール群と比較検討している。
何を根拠に見送ったか
比較検討の結果、この領域はオープンソースで急速にコモディティ化しており、製品としての優位は立たないと結論し、製品化を見送っている(出所: 自社の運用記録、確認日2026-09-06)。作ろうとしていた機能の多くが、無料で入手できるツールによってすでに解決または回避されており、独自の機能として差別化できる領域がほとんど残っていなかった。検証費用は、製品を実際に開発する場合の費用の数十分の一で済んでおり、検証で得た仕組み自体は捨てず、自社の開発工程にそのまま組み込んでいる。
中止判断ができた条件
この判断ができた条件は、検証の対象を実際に動く試作に限定し、既存ツールとの比較を先に行ったことにある。作る前に机上で優劣を論じるのではなく、実機で比較したうえで、差別化の余地がどれだけ残っているかを確認する手順を踏んでいた。加えて、「作らない」という結論そのものを、検証の成果物として発注元に納品する運用にしている点も、中止判断を出しやすくしている要因である(出所: 自社の運用記録、確認日2026-09-06)。
終われないPoCとの違い
IBM Watsonの事例と自社の事例を比べると、違いは検証の規模ではなく、中止条件をいつ、どう扱ったかにある。Watsonの事例では、中止条件がKPIと同じ精度で文書化されておらず、延長判断が積み重なった(既存記事の回避策1を参照)。自社の事例では、既存ツールとの比較で差別化の余地が無いと判明したら見送るという基準を、検証の設計に組み込んでいた。中止条件を検証の成功条件と同じ重さで扱えるかどうかが、PoCが終われるかどうかを分ける。
内製で検証を進める際の判断材料は内製と外注の分岐点の記事で扱っている。業種によって最初に詰まる場所は業種で見る最初のつまずきの記事を、最初に着手する業務そのものの選び方は有界かどうかを軸にした選び方の記事を参照してほしい。PoCの設計について相談したい場合は、お問い合わせから編集部まで連絡してほしい。
よくある質問
Q1. PoCが終わる経路にはどんな種類があるか
大きく2つある。中止条件が無いまま延長が繰り返されて終わる経路と、検証の途中で「作らない」と判断して健全に終える経路である。
Q2. 自社はどんな検証で「作らない」と結論したのか
ゲーム開発事業者向けの開発支援AIの検証である。実際に試作を組んで動作を確認したうえで、既存のオープンソースのツール群と比較し、差別化できる領域がほとんど残っていないと判断した。
Q3. 「作らない」という判断はどう納品されたのか
検証の成果物として発注元に納品している。検証費用は、製品を実際に開発する場合の費用の数十分の一で済んでいる。
Q4. IBM Watsonの事例と自社の事例の違いは何か
検証の規模ではなく、中止条件をいつ、どう扱ったかにある。自社の事例では、既存ツールとの比較で差別化の余地が無いと判明したら見送るという基準を、検証の設計にあらかじめ組み込んでいた。