PoC開発の会社選びは、技術力だけで決めると失敗する

PoC開発を依頼する会社を探すと、「おすすめ◯選」という形式の記事が数多く見つかります。ただ、そこに並ぶ会社を技術力や実績数で比べても、自社に合う相手は絞り込めません。

会社ごとに得意とする型が違い、型が違えば比較すべき軸も変わるからです。この記事では、PoCを本開発に繋げるための選定基準を整理します。

PoC開発の会社選びは、技術力だけで決めると失敗する

先に結論を書きます。PoCの依頼先を選ぶ基準は、技術力ではなく検証を本開発に繋げられるかです。

技術力は前提条件であって、差がつく要素ではありません。PoCで扱う技術の多くは既に確立されており、実装できる会社は複数あります。それでもPoCが失敗するのは、技術以外のところに原因があるためです。

失敗の形はほぼ一つです。動くものはできたが、本番に進める判断ができない。 そして次のテーマに移り、また同じことが起きます。

なぜPoCは本開発に繋がらないのか

原因は、PoCを始める前の設計にあります。

検証の目的が「作ること」になっている

「まずPoCで試してみよう」という始まり方をすると、作ること自体が目的になります。完成したときに何をもって成功とするかが決まっていないため、判断できません。

技術的に動いたかどうかと、事業として進めるべきかどうかは別の問いです。前者だけを確認して終わると、投資判断の材料は増えないままです。

成功基準が実装後に議論される

つくってから「これは成功なのか」を話し合うと、判断が主観に流れます。精度が何%なら使えるのか、どれだけ短縮できたら導入するのか。この線引きは実装前に決めておかないと、後から動いてしまいます。

本開発への接続が考慮されていない

検証だけを目的に作ると、そのままでは本番に使えない構造になることがあります。結果として、本開発でゼロから作り直しになり、PoCにかけた費用と時間が判断材料以外には残りません。

検証で終わらせないためには、最初から本開発を視野に入れた設計が要ります。 これは実装力ではなく、設計の判断です。

「おすすめ◯選」だけでは選べない理由

比較記事に並ぶ会社は、同じ「PoC開発」という言葉で括られていても、実際には別の仕事をしています。

技術的な実現可能性を確かめることを主とする会社、仕様どおりに素早く形にすることを主とする会社、事業として進めるべきかの判断材料を作ることを主とする会社。どれも正しいPoCですが、成果物も進め方も違います。

リスト記事は会社名と実績数を横並びにしますが、この型の違いまでは整理されていないことが多くあります。だから「実績が多い会社を選んだのに噛み合わなかった」という事態が起きます。

比較すべきは会社の優劣ではなく、自社の検証テーマがどの型に当てはまるかです。

依頼先の3つの型と、向いているケース

	技術検証型	受託開発型	事業検証型（YOLOはここ）
主な問い	技術的に実現できるか	仕様どおりに作れるか	事業として進めるべきか
前提	検証したい技術が決まっている	作るものが決まっている	何を確かめるべきかから決める
成果物	技術検証の結果	動くシステム	判断材料と、次の打ち手
成功基準	動作すること	仕様を満たすこと	投資判断ができること
本開発への接続	別途設計が必要	別途見積もり	最初から前提に含める
向いているケース	新しい技術の適用可否を確かめたい	要件が固まっている	何から検証すべきか決まっていない

技術検証型は、扱う技術が明確で、それが動くかどうかが最大の不確実性である場合に適しています。受託開発型も、作るものが決まっているなら費用対効果の高い選択肢です。

問題は、新規事業やプロダクト開発のPoCがそのどちらでもないことが多い点です。技術は既にあり、作るものはまだ決まっていない。この状態で技術検証型や受託開発型に依頼すると、「何を作るか」を発注側が決めなければならず、そこが決まらないまま実装が始まります。

発注前に聞くべき5つの質問

PoC開発の依頼先の型を見極めるには、実績数を聞くより次を尋ねるほうが確実です。

このPoCの成功基準は、どう決めますか

実装前に数字で決める前提が返ってくるか。「動いてから判断しましょう」なら、判断は先送りされます。
検証の結果、進めないという判断になった場合はどう扱いますか

やめる判断も成果として扱えるか。ここが曖昧だと、続けることが前提の進行になります。
本開発に進む場合、このPoCの成果はどこまで使えますか

作り直しになる範囲を先に把握できます。答えられない場合、本開発が視野に入っていません。
要件がまだ固まっていないのですが、どこから始めますか

「要件をいただければ」と返る会社は受託開発型です。悪いわけではなく、噛み合わないだけです。
検証を自社で回せるようにしたいのですが、可能ですか

内製化を前提に進められるか。ここを引き受けられる会社は多くありません。

このうち1と3が最も差が出ます。どちらも実装力ではなく、設計と経験に依存する問いだからです。

YOLOがPoCで検証設計から入れる理由

進め方を掲げるだけなら誰にでもできます。実行できるかどうかは体制で決まります。

YOLOは開発会社ではなく、UXデザインとプロダクトマネジメントに専門性を持つProduct Evolution Studioです。メンバーは事業会社で自社プロダクトの開発とグロースを経験しており、発注側として投資判断をしてきた人間が設計に入ります。

これが効くのは、次の場面です。

成功基準を決める場面 — 事業側の判断材料として何が要るかが分かるため、実装前に線を引ける
やめる判断をする場面 — 続けることを前提にしないため、撤退も成果として扱える
本開発に繋ぐ場面 — 作り直しになる範囲を織り込んで設計できる
引き渡しの場面 — 内製化を前提に、判断の基準ごと渡せる

実際の支援でも、株式会社フォトシンス様では入退室管理システムの新規Webアプリケーション開発とあわせて、新規事業の検証を推進する初期ユーザーの獲得まで担当しました。株式会社LabBase様では、内製化を意識して社内のPMの方と伴走しています。ほかの事例はプロダクト開発のページに掲載しています。

つくって納めるだけでは、事業の判断材料は増えません。検証が回る状態にすることが目的です。

AIを対象としたPoCの具体的な進め方はAI PoCの進め方に、検証範囲の決め方が費用に与える影響はMVP開発の費用にまとめています。社内に検証を進める人がいない場合の考え方は、PdM不足と求人票の問題で扱っています。

まとめ

PoCの依頼先を選ぶ基準は技術力ではなく、検証を本開発に繋げられるか
会社には型がある。自社の検証テーマがどの型に当てはまるかで選ぶ
見極めるには、実績数より成功基準の決め方と本開発への接続を尋ねる

何を検証すべきかがまだ決まっていないなら、会社を探す前にそこを決める段階が残っています。