【2023年版】概念実証（ poc ）の次は何か？

プロダクトアイデアの検証とテストは、PoCプロセスの間だけに行うべきではありません。企業や組織は、プロダクト開発プロセスがさらに進むにつれて、仮説を疑問視し、検証し続ける必要があります。本記事はPoCの次にどんな目的で何をするか解説していきます。

1. 背景 このトピックを読み始める前に

プロダクトの背後にいるチームが、顧客が実際に欲しがっているものやお金を払っても構わないと思っているものに注意を払わずに、プロダクトのアイデアだけにこだわると、プロダクトは失敗する傾向があります。

ビジネスを成功させるには、顧客をできるだけ早く理解する必要があります。

今日のデジタル経済では、企業や新興企業は、プロダクト開発プロセス全体を通じてプロダクトのアイデアをユーザーの前に提示して、仮説をテストし、顧客に利益をもたらす必要な反復を行うことができます (またそうすべきです)。

これこそまさに、クライアントがデジタル製品を構築するのを支援したい方法です。

多くの場合、彼らはプロダクトのアイデア、要件、概念実証PoCを持ってから

1. 次は何か？
2. 概念実証PoCの次に来るものは何ですか?
3. このプロダクトのアイデアやアプリの初期バージョンを市場に投入できるものにするにはどうすればよいか?

と悩んでいる方がいるかもしれません。

理想的には、初期のプロダクトのバージョン (概念実証PoCの段階であっても) で、プロダクトのアイデアが機能する可能性があるかどうか、現実的に実装できるかどうか、経済的に実行可能かどうかを示すことができます。

ただし、プロダクトアイデアの検証とテストは、PoCプロセスの間だけに行うべきではありません。企業や組織は、プロダクト開発プロセスがさらに進むにつれて、仮説を疑問視し、検証し続ける必要があります。

本記事はPoCの次にどんな目的で何をするか解説していきます。

2. 概念実証 – PoCの概要と目的

概念実証 – PoCは、デジタル製品の非常に初期のバージョンであり、プロダクトのアイデアに関する仮定を検証するのに役立ちます。PoCはまだ技術的に開発されたソリューションではありません。概念実証は単なるアウトプットとしてではなく、プロダクトのアイデアそのものに関する仮定をテストする検証方法として見なされるべきであることに留意することが重要です。

広範な調査とテストは、ビジネスアイデアに市場の可能性があるかどうかを判断するのに役立ちます。

実際、PoCを開発する主な目標は、プロダクトが実際の顧客の問題に対処すること、および提案されたソリューションが技術的に実現可能であることを検証することです。最終的に、この検証プロセスの目的は、問題と解決策の適合性を探すことです。

概念実証 – PoCは、プロダクト開発の旅のどの段階にあるか、またはチーム内で利用できる人材に応じて、さまざまな形で提供されます。最も一般的な形式は、ワイヤーフレーム、プレゼンテーション、スクリーンショット、スケッチ、またはドキュメントです。理想的には、PoCプロセスはこれらの組み合わせを生成する必要があります。

参考：PoCとは？5つのStepでソフトウェア開発を成功させるコツを解説

3. 次の即時ステップ：PoCレポートのドラフト

繰り返しますが、PoC開発を単なるアウトプットとしてではなく、方法論またはプロセスとして考えることが不可欠です。PoCのイテレーションを作成する際に、企業はそのアイデアが実行可能かどうかを健全なデータ (定性的、定量的、またはその両方) に基づいて評価する努力をしなければなりません。

PoCの出力を見て、すぐにプロトタイプに反復するだけでは十分ではありません。なぜプロダクトのアイデアをさらに追求する必要があるのか、それをどのように改善する必要があるのか 、正当な理由がある場合は、それがうまくいかない理由と方法を楽しませる必要があるため、データに基づいた明確で十分な洞察を提供できなければなりません。

これらの洞察をプロダクトチームのメンバー間の考えや議論として残すのではなく、概念実証 – PoCレポートを作成することで、チームが洞察と次のステップを明確にすることを余儀なくされ、プロセスを充実させることができます。

このレポートには、研究、PoCアーティファクト (ワイヤーフレームやスケッチなど)、および演習から生成された可能性のあるデータを含める必要があります。

PoCレポートには、次の情報も含まれている必要があります。

• 仮定
• 発見
• 機会
• 危険因子
• その他の議論のポイント

ソリューションの技術的な実現可能性を実証するために、PoCは、プロダクトの主要な機能および技術仕様を説明するドキュメントによってサポートされている必要があります。

さらに、このレポートは形式や最終文書として扱われるべきではなく、プロダクトのアイデアの実現可能性と今後の市場機会について利害関係者を調整するためのアンカーとして扱われるべきです。

これにより、プロダクトチーム、創業者、意思決定者、およびその他の利害関係者が、プロダクトのアイデアを進めるかどうかについて、情報に基づいて慎重に検討した決定を下せるようになります。

4. 概念実証 – PoCの次は何か？

概念実証PoCが有望なソリューションを示していると判断した後でのみ、アプリの構築をさらに進める必要があります。同時に、これは、PoCをコーディングするためにエンジニアを呼び込む必要があるという意味ではありません。

PoCの演習で肯定的な結果が得られたら (ただし、完全な生産に入る前に)、次にプロトタイプを開発し、その後で実用最小限の製品（MVP）を開発することを検討してください。制限を含め、状況に合わせてアプローチを調整することを忘れないでください。

4.1. プロトタイプ開発

プロトタイプは、視覚的な形を示し、ユーザーエクスペリエンス (UX) をシミュレートし、主要な機能を選択して実装することにより、機能とデザインコンセプトを評価するために開発されたプロダクトの初期バージョンです。

プロダクトのアイデアを概念実証PoCからプロトタイプに昇格させることには、多くの目的があります。プロトタイプは、プロダクトチームがアプリケーションの最も重要なワークフローとそれを可能にする機能を明確にするのに役立ちます。また、UXとデザインコンセプトを紹介し、検討することも目的としています。

プロダクト開発の過程でプロトタイプを作成できるようになるまでに、ソリューションとしての製品の望ましさ、およびその外観と感触の両方を評価できるようになっている必要があります。

PoCでプロダクトとソリューションの適合性が検証された場合、プロトタイプはプロダクトと市場の適合性を検証し始めます。これを行うには、プロトタイプは主に、使いやすさと望ましさという2つの前提条件をテストする必要があります。顧客はそれを使用できますか？ 消費者はそれを望んでいますか？

プロダクトチームは、プロトタイプを構築する際に次の領域に焦点を当てる必要があります。

・代表的なユーザーが製品とどのようにやり取りしているか、および彼らが提供するフィードバック。
・対象となる顧客またはユーザーのニーズと問題 (PoCプロセスからの洞察に基づいて構築および検証)
・プロダクトワークフローのテストと検証
・実際の対象顧客との主な機能の評価
・デザインコンセプトとユーザーインターフェース (UI) に関するユーザーのフィードバックの取得

プロトタイプは、多くの場合、代表的なユーザーだけでなく、社内の同僚にも見せられたり、デモンストレーションされたりします。プロトタイプのアーティファクトは通常、モックアップやノーコードのプロトタイプなどのユーザーインターフェースの形で提供されますが、バックエンドやメカニズムとはまだリンクされていません。

プロダクトチームは、これらのプロトタイプを選択した顧客の前に置いて、たとえば、ワークフローをナビゲートしたり、特定のタスクを達成したりできるかどうかを確認できます。

4.2. 実用最小限の製品 (MVP)

最小限の実行可能な製品 (MVP)は、限られた数の顧客が使用できるようにするのに十分な機能を備えた、意図された実動対応アプリケーションの初期バージョンです。MVPは、想定されたプロダクトのより単純なバージョンであることを意図しています。

初期のユーザーでテストする場合、プロダクトのロードマップですべての機能を提供する必要はありません。実際、開発チームはMVPの主要な機能に集中する必要があります。

企業は、MVPを作成することを決定した場合、完全なテストを行わずに完全な製品を市場にリリースする場合に発生する可能性がある、長くて費用のかかる変更を後で行う必要を回避できます。MVPは、Minimum Viable Prototype と呼ばれることもあります。個人的には、常にアイデアの検証モードにいる必要があることを思い出させてくれるので、より良い見方ができます。

最小限の実行可能な製品（MVP）をリリースする主な目的は、アプリの主な機能をテストし、その実行可能性と望ましさを評価し、配布チャネルをテストすることです。

通常、MVPの発表にはまだ完全な製品の発売は含まれていませんが、それを市場開拓 (GTM) 戦略の重要な部分と見なす必要があります。PoCやプロトタイプとは異なり、MVPをリリースすると、顧客やユーザーを獲得するために適切なマーケティングおよび流通チャネルを選択したかどうかを検証するのに役立ちます。

プロトタイプが製品市場適合性を検証する場合、MVPは製品市場チャネル適合性を検証します。これを行うには、消費者が製品を使用したいかどうかをテストするだけではいけません (つまり、価値仮説)。また、収益性の高いビジネスモデル (つまり、成長仮説) を解き放つために十分な牽引力を生み出すことができるかどうかもテストする必要があります。

MVPは、ローコード製品または範囲が限定された実装済みソリューションのいずれかの形で提供されます。 

・市場投入可能な製品（MMP：Minimum Marketable Product）
・市場に出せる最低限のフィーチャー(MMF：Minimum Marketable Feature)
・Minimum Loveable Product (MLP) 

など、検討できるMVPの種類がいくつかあります。

MVPの種類	開発スピード	特徴	コスト	準拠
MVP 英：Minimum Viable Product	最も速い	アイデアをテストするための最小限の機能	一番安い	プロトタイプ
MMP 英：Minimum Marketable Product	速い	プロダクトを販売またはマーケティングするための最小限の機能	安い	改訂された MVP
MMF 英：Minimum Marketable Feature	速い	顧客にすぐに価値をもたらす重要な機能に焦点を当てる	機能による	機能の仕様
MLP 英：Minimum Lovable Product	速い（MVPより遅い）	「驚き」をもたらす最低限の機能	機能による	改訂された MVP

4.3. プロダクション開発

プロダクト開発は反復的で動的なプロセスであるため、アプリが完全に公開される準備ができているかどうかを判断することは困難です。アプリがMVPから本番環境に移行する準備ができているといつ言えるかという厳格なルールはありません。

しかし、企業は市場の声に耳を傾け、顧客が必要とし、望んでいるものを提供することで成功を収めてきました。自分の最善の判断で、アプリがまだ限られた顧客向けにしか構築されていなくても、アプリを一般に使用する準備ができている場合は、プロダクトを本番環境にデプロイするときです。

技術的な意味では、アプリケーションは、対象となる顧客の意図された使用のために運用に展開されたときに、本番環境にあると見なされます。ただし、概念実証 PoC、プロトタイプ、および MVPとしての以前のイテレーションに基づいて、市場で検証された製品である場合にのみ、アプリを実稼働の準備ができていると見なす必要があります。

これは、すべての主要な機能と特性が実装されるまで待つ必要があるという意味ではありません。それは、あなたがそれを世界に見せることができ、準備ができていて、喜んでいるということです。

すぐに運用できるアプリケーションは、市場で検証されたソリューションを通じて特定の問題や実際の問題を解決できる実用的な製品である必要もあります。それは、より広範な一般、限られた市場、または早期にサインアップした人だけに向けて販売またはリリースすることができます。生産の初期段階 (アルファリリース、ベータリリースなど) では、プロダクト、市場、シャネルの適合性を引き続き検証する必要があります。

同時に、実稼働中のアプリは、必ずしも完全にリリースされた製品とは見なされません。 これが、適切な流通およびマーケティングチャネルを引き続きテストし、正式な発売に間に合うように製品をさらに最適化する必要がある理由です。目標は、製品発売の準備状況と早期の市場牽引力をテストすることです。

引き続きユーザーからのフィードバックを収集して、製品の市場性、成長軌道、および収益化モデルを検証します。ビジネス面に注意を払いながら、製品をおろそかにしないでください。特に、新しいユーザーの問題点を発見し、反復または新しい製品機能を通じてそれらを解決します。

5. 迅速に構築し、迅速に失敗する反復プロセス

プロダクト開発プロセスは動的で流動的であることを繰り返します。たとえば、概念実証PoCまたはプロトタイピングプロセスが、プロダクトを方向転換する必要があることを示している場合は、方向転換する必要がある理由と方法の証拠を調べます。

プロダクトエンジニアリングに関する重要な作業を開始する前に、最小限の実行可能な製品MVPに至るまで、発見から十分なデータと洞察を得るように努める必要があります。 また、プロダクトがすでに運営されている場合でも、この市場検証の規律は、何度も繰り返さなければならない方法です。

使用するフレームワーク、方法、またはプロセスに関係なく、プロダクト開発のすべての段階で、あなたとプロダクトチームが簡単に観察できるこれらの単純な手順に要約されます。

・仮定を特定する (特に最もリスクの高いもの)
・これらの仮定をテストするための実験を実施します (実験がどれほど単純であっても)。
・実験の結果を軌道修正に適用する
・繰り返す

これを行う唯一の方法 (自分の仮定をテストする唯一の方法) は、できるだけ早くプロダクトを実際のユーザーの前に置くことです。革新的なプロダクトを生み出すには、間違いにいち早く対応できる人が勝ちます。この「構築は迅速、失敗は迅速」という哲学は、製品開発の中核にあります。

仮定を認識し、それらをテストし、新しい洞察に基づいて製品を反復することで、次のようなソリューションを提供できます。

・ビジネス目標に沿っている
・ユーザーの問題を解決できる
・顧客中心である
・データインフォームド
・「最愛の人を殺す」（顧客が実際に望んでいるものを支持して、あなたにとって「最愛の人」であるアイデアやプロジェクトを放棄する）
・お客様の本当の思いを明らかにします
・実行可能なビジネスモデルを持っている
・倫理的である
・持続可能

プロダクトのアイデアに取り組んでいる場合、または概念実証PoCの初期段階にある場合、是非とも次の段階をMiichisoftにご相談ください。

Miichisoftはスタートアップ企業と初期段階からプロダクトを運用した後でも開発支援していますので、是非ともノウハウを活用し、提案させていただきます。

ご連絡お待ちしています。
よろしくお願い致します。