PoCの検証方法、項目をシステム開発会社が詳しく解説

プロジェクトの成功確度を高める手法として、PoC開発の需要が高まっています。しかし、PoC開発は企業ごとに少し解釈が違い、取り組む内容もケースバイケースなので「具体的に何をすれば良いのか」が分からない方も少なくありません。まずはPoC開発の目的と検証する項目を把握したうえで、対象となるプロジェクトでは何を検証すべきかを考えるようにしましょう。

本記事では、PoCで検証する項目をまとめて紹介します。この記事を読みながら、ご自身が担当するプロジェクトでは何を検証すべきか、どのように検証すべきかを考えてみましょう。

PoCで検証する項目とは

PoCでは、主に「実現可能性」「市場における有用性」「システムの具体性」の3つの項目を検証していきます。検証項目を把握するのは、適切なゴール設定やスケジュール設定に欠かせません。また、PoCを経てプロジェクトを成功させるには、確認すべき項目を漏れなく検証する必要があります。以下では、PoCで検証する3項目について詳しく解説していきますので、これからPoCをする方は参考にしてください。

実現可能性

PoCにおいて必ず確認するのが「実現可能性」です。具体的には、以下のようなポイントを確認していきます。

実現可能性に関してチェックすべきポイント

• 技術要件の整理
• アーキテクチャの検討
• 実装の検証
• 性能検証
• コスト検証

実現可能性の検証は、PoCにおいて特に重要なポイントです。以下でチェックすべき5つのポイントをそれぞれ解説しますので、ぜひ参考にしてください。

技術要件の整理

まず、技術要件を整理します。技術要件とは、プロジェクトを成功させるために必要な技術のことです。技術要件が整理できていないと、リスクの想定や検証すべき項目、検証方法が定まりません。

アーキテクチャの検討

アーキテクチャについての検討もPoCにおいて欠かせません。そもそもアーキテクチャにはいくつかの意味合いがあります。本来はCPUの基本設計を意味するのがアーキテクチャでしたが、現在では以下3つの意味があります。

アーキテクチャの意味

• インテグレーション・アーキテクチャ：システム間の統合・連携に関する構造
• アプリケーション・アーキテクチャ：アプリケーションの設計・構築手法
• インフラストラクチャ・アーキテクチャ：ITインフラ環境の基盤設計

PoCにおいては、インテグレーション・アーキテクチャの検討が重要になります。まずSaaS・PaaS・APIの既存サービスで活用できるものがないか、それぞれをどのように連携するのかといった内容の検討です。また、新たにアプリケーションを開発する場合はアプリケーション・アーキテクチャに関する検討も必要になります。

実装の検証

本番環境で実装可能かどうかの検証も重要です。本番に近い環境でプロトタイプを動かして検証します。技術的な問題がないか、動作に問題がないか、既存サービスに影響を与えないかなどを確認します。本番に近い環境を用意し、仕様通りのプロトタイプを用意することがポイントです。

性能検証

仕様を満たす性能があるかどうかも、実現可能性の検証において必ずチェックしましょう。本番に近い環境でプロトタイプを導入し、意図した動作をするか、想定通りの性能を発揮するか、連携ツールが新プロダクトの性能に影響を与えるかなどを検証します。

ただし、性能については範囲を広げすぎるとPoCの目標からずれる可能性があるため注意が必要です。また、「技術的に実現可能か」を検証するのがPoCの目的なので、定量的な指標を設けて検証しないケースもあります。性能検証の範囲や指標設定については、適宜検討しましょう。

コスト検証

PoCでは、プロダクト開発にかかるコストやリターンなどを検証することもあります。広義の意味でのPoCでは、PoV（価値実証）やPoB（ビジネス実証）を含む検証を行うことがあります。PoVはユーザーへの提供価値を検証するプロセスを、PoBは経営戦略に基づいてプロジェクトを評価したり、費用対効果や利益構造などを検証したりするプロセスを指します。ユーザーへの提供価値や市場状況などを検討した上で、想定される利益や損益分岐点などを検討し、どのくらいのコストがかかるかを検証します。

市場における有用性

PoCでは、プロトタイプをユーザーに利用してもらいPoV（価値実証）を検証する場合もあります。市場における有用性に関しては、以下のようなポイントをチェックします。

市場における有用性についてチェックすべきポイント

• 顧客インタビュー
• ユーザーテスト
• 市場調査

PoVのみならず、PoB（ビジネス実証）を評価するためにも、市場における有用性の把握はとても重要です。以下では、市場における有用性についてチェックすべきポイント3つを解説します。

顧客インタビュー

顧客から直接フィードバックを得るために、顧客インタビューが有効です。以下のような質問を通じて、開発するプロダクトの価値を見つけることができます。

顧客インタビューの質問例

• どんな機能があったら良いですか？
• このような機能を利用したいと思いますか？
• どんな場面で不便さを感じますか？

提供価値を評価するうえで重要なのは「顧客はそのプロダクトや機能を必要としているのか」「より実装する優先度の高い機能はないのか」などを把握することです。顧客インタビューを通してニーズを正確に把握し、PoVの評価に役立てましょう。

ユーザーテスト

プロトタイプを実際に利用してもらうユーザーテストも、価値を評価する有効な方法です。プロトタイプを使ってもらうことで、必要な機能や使いやすさを把握できます。ユーザーテストは、実際の導入環境に近い条件で行うことが重要です。異なる環境で実施すると、テストと実装の検証を分けて行う必要があり、また環境の違いによりユーザーの反応が変わる可能性もあります。本番に近い環境で、ユーザーの反応をテストしましょう。

市場調査

PoVだけでなく、PoB（ビジネス実証）を評価するためには市場調査も欠かせません。市場のニーズを把握しないと、費用対効果や利益の見通しが立たないためです。まず顧客ニーズや競合調査などを行って、同様のサービスが存在していないか、相場はどのくらいか、そもそもニーズがあるかなどを調べます。PoVを把握したうえで、どういった費用・スケジュールでどのようなサービスを提供すれば、どのくらいの利益が得られるのかを算出するのです。

システムの具体性

PoC（Proof of Concept）の段階では、実証実験を通じてシステムの具体性を検証することもあります。これは、プロダクトに必要なシステムの詳細を明らかにするプロセスです。

システムの具体性についてチェックすべきポイント

• システム設計
• 運用計画
• 保守計画

システムの具体性は、技術的に実現可能か、市場において有用性があるかを検証した後に考えるのが一般的です。システムの具体性の検証について、チェックすべき3つのポイントを解説します。

システム設計

システム設計では、機能仕様からUI設計まで、システムに関わる全ての仕様を検証します。ただし、全てを検証する必要はなく、実現可能性を判断すべき部分に焦点を当てて検証します。例えばUIでは、ボタンの配置やカラーリング、動作など必要な要素を検証します。技術的な部分だけでなく、業務プロセスに適したシステム設計であるか、操作性に問題がないかも検討します。

運用計画

運用計画とは、パフォーマンス管理やセキュリティ対策、アップデートのデプロイ戦略などを含む計画です。品質を維持・改善するための戦略を立てます。システムは導入後も常にトラブル対応やアップデートが必要です。デプロイ戦略やセキュリティ対策など、さまざまな観点から計画を立てます。

保守計画

保守計画は、「どのように保守を行うか」を考える項目です。監視やメンテナンス、顧客サポート、システム障害対応などに関する計画を立てます。保守計画は実現可能性だけでなく、コストや損益分岐点などにも関わる重要な情報です。保守はアウトソースするのか、自社で行うのかによって、保守計画は大きく異なります。前提条件を考慮して、保守計画を立てます。

PoCの検証後の流れについて

PoCの検証後の流れは、主に3つのパターンが考えられます。一つ目は、「問題がないため、プロトタイプまたは製品の開発に進む」というパターンです。PoCの段階でプロトタイプを作成していた場合、そのまま製品の開発に移行することもあります。

二つ目は、PoCで問題点が見つかり、再度PoCを行うパターンです。技術的な課題を解決するために、既存ツールの活用や新システムの開発などを検討し、再度技術的な可能性を検証します。ただし、課題が続出したり、PoVやPoBなどの問題が解決しない場合、PoCを繰り返す「PoC疲れ」に注意が必要です。

三つ目は、PoCの結果、プロジェクトそのものが中止になるパターンです。この場合でも、製品開発が始まってからプロジェクトが中止になるよりはコストが少なく済むため、PoC自体は成功と言えます。

PoCで検証を行い、開発失敗のリスクを低減しましょう

PoCは、技術的な課題やコスト面を検証し、プロジェクトの実現可能性を探るプロセスです。開発に進む前にPoCを行うことで、失敗リスクを低減し、無駄なコストや工程を削減できます。これにより、開発はより効率的に進行します。

本記事で触れた通り、PoCでは検証すべき項目が多いです。そのため、自分のプロジェクトでPoCを実施する際は、範囲が広がりすぎたり、検証項目が多すぎてPoCが長引かないよう注意が必要です。PoCに過度なコストやリソースを割かないように、専門家への相談も視野に入れながら進めていくことをおすすめします。