TECH 2026.10.05

新規事業をスモールスタートで進める効果的なPoCとMVP、開発・検証現場のリアル

新規事業をスモールスタートで進める効果的なPoCとMVP、開発・検証現場のリアル のメインビジュアル

生成AIやクラウドサービスの進化により「まずは動くものを作ってみる」ことのハードルは近年大きく下がっています。ジークスでも、お客様自身がAIやクラウドを活用して、PoCまで進めたうえでご相談をいただくケースが増えてきました。そのような状況の中、新しいサービスを形にする観点で、今後の開発会社には何が求められるのでしょうか?
今回は、PoC・MVPをはじめとするさまざまな実験的開発に長年携わってきたエンジニア・酒井の経験をもとに、その答えを考えます。
酒井がこれまで向き合ってきたのは、スマートフォンとデバイスを連携させるプロダクトの検証から、センサーを活用した研究的なプロジェクトまで、まだ正解も完成形も見えていなかった開発です。中には、複数の開発会社への相談を経て、最終的にジークスへ持ち込まれた相談もありました。
数々の「まだ答えがない開発」の経験から、PoC・MVPをどう捉え、次のステップへつなげていくべきなのかを紐解きます。

01

PoCとMVPの違い、「作れるか」と「使われるか」を分けて検証する意味

PoCとMVPは、新規事業やDX推進の場面でよく耳にする言葉ですが、検証する対象に違いがあります。

PoC(Proof of Concept)は、技術面の実現可能性を確かめるための検証です。たとえば、センサーから必要なデータを取得できるのか、想定した認識精度が出るのか、デバイスとスマートフォンを正しく連携できるのか、「技術的に成立するのか」を確かめます。まさに、デジタルサービスにおけるコアの部分です。

一方、MVP(Minimum Viable Product)は、最低限の機能を備えたサービスを実際のユーザーに使ってもらい、「本当に求められているのか」を確かめるためのものです。業務システムであれば、これまで30分かかっていた作業をどれだけ短縮できたか、一般向けのサービスであれば、実際に継続利用されるのかを確認します。利用者に使われなければ、そのサービスは成立しません。

PoCが「作れるか」を確認するものだとすれば、MVPは「使われるか」を確認するものと考えると分かりやすいでしょう。

ただし、現場では必ずしも「PoC→MVP→本開発」と一直線に進むわけではありません。PoCの結果、技術的に難しいと分かればそこで終了する場合もあります。反対に、技術的な不確実性が少なければ、PoCを行わずMVPから始めるケースもあります。重要なのは決められた開発プロセスを守ることではなく、「今、何を確かめる必要があるのか」を見極めることです。ここに伴走して一緒に考えるスキルが、今後ますます開発チームに求められると考えています。

02

PoCから始まる「答えの見えない開発」

ジークスは、「そもそも、こんなことが実現できるのか」という段階でご相談をいただくことがあります。過去には、ソフトウェア開発のノウハウを持たないハードウェアメーカー様から、10社ほどに断られた後でジークスにご相談が持ち込まれたこともありました。Bluetoothで接続した自社デバイスをスマートフォンから制御したい、機器とソフトウェアを組み合わせてこれまでにない体験を作りたい、などハードルが高く「答えの見えない開発」とも言えるご要望です。

こうしたプロジェクトは、最初から完成形や実現方法が見えていません。そこでPoCを導入し、まず技術的に実現できる部分や、難しい部分を小さく確かめていきます。「できるかどうか分からないから依頼できない」のではなく、できるかどうかを確かめるところから一緒に始める、そうした実験的な開発に向き合ってきた実績は、ジークスのPoC支援の特徴のひとつです。

03

PoCで「作らない、変える、やめる」を判断、実験を前に進める熱意の大切さ

デジタルサービスのPoCだからといって、必ずしもアプリやシステムを開発する必要はありません。最初から自動化する仕組みを開発せず、人が手作業で簡易的なプロトタイプを作成し、それをユーザーに見せて反応を確かめることもできます。アプリケーションの技術検証であれば、OS標準のUIパーツを使い、デザインを作り込まずに必要な機能だけを実装する場合もあります。

PoCで重要なことは完成度の高いものを作ることではなく、主要な技術指標を達成しているか確認することです。つまり、完成度の高い試作品を作るのではなく、最小限の方法で仮説への答えを得ること。

酒井がこれまで携わったプロジェクトの中には、スマートフォンの加速度データを利用して人の「転びやすい歩き方」を分析する実験や、ビーコンの位置情報からエリア内のコミュニケーションを分析するといった研究的な検証もありました。こうした実験は、一度で想定通りの結果が出るとは限りません。

欲しいデータが取れなければ取得方法を変える、違うセンサーを試す、必要であれば仮説そのものを見直すこともあります。そこで大切になるのが、プロジェクトに関わる担当者の熱意です。

PoCはまだ世の中に存在していないものを試すことが多いため、最初の方法がうまくいかなかったときに、「次はどうすれば確かめられるか」と考え続ける人がいなければ、プロジェクトは止まってしまいます。しかし、熱意だけで続けることが正解とも言えません。

PoCを始める段階で、「認識精度がこの数値を超えたら次へ進む」「作業時間をここまで短縮できなければ見直す」といったKPIや撤退基準を設定し、期待した効果が得られないのであれば、大きな開発投資をする前にやめる判断も必要です。

粘り強く試すことと、早く見切ること。一見矛盾するこの2つを両立させることが、PoC・MVPを前に進めるうえで重要だと考えます。

データを分析しながら仮説を検証するイメージイラスト

04

AI時代のPoC・MVP、開発会社は「作る人」から「一緒に考える人」へ

生成AIやクラウドサービスの進化によって、PoCの作り方は今後さらに変わっていくでしょう。以前であれば、開発会社に依頼しなければ形にできなかったアイデアも、AIにコードを書かせたり、既存のAPIやクラウドサービスを組み合わせることで、お客様自身がある程度まで形にして検証できるようになってきました。

だからこそ、ジークスのような開発チームの価値は「システムを作る」だけではなくなっています。

「このアイデアなら、最初に何を確かめるべきか」
「本当にそこまで開発する必要があるのか」
「もっと小さな方法でPoCを実施できないか」
「この結果ならMVPへ進むべきか、それとも別の方法を試すべきか」

こうした判断を、企画の段階から一緒に考えることが重要になります。

ジークスでは、PoCからその先のMVPや製品化まで、可能な限り同じ担当者が窓口となって伴走することを大切にしています。PoCでは検証を進める中で、前提や仮説が変化することは何度もあります。

「なぜこの検証を始めたのか」
「これまで何を試してきたのか」
「なぜうまくいかなかったのか」

その背景を理解した担当者が継続して関わることで、説明や引き継ぎに時間を使わず、次の一手をすばやく考えることができます。

まだ仕様書がなくても、「こんなことができないか」というアイデアの段階でも、小さく検証して改善しながら進めることは可能です。他社では難しいと言われたアイデアも、実現方法が見えていない構想も、「何を作るか」が決まってからではなく「何を確かめればいいか」を考えるところからお客様とワンチームで伴走する。それが、AI時代のPoC・MVPでジークスが目指している開発のかたちです。

「どこから作ればいいかわからない」「検証だけで終わらせたくない」——そんなご相談も歓迎です。ぜひお気軽にお問い合わせください。

この記事を書いた人

FOCUS編集部

FOCUS編集部

デザイン力×技術力にこだわるジークスの人、サービス、カルチャーなど、ジークスを深掘りするコンテンツをお届けしています。