PoCの具体的な進め方や注意点をシステム開発会社がわかりやすく解説！　

「PoCという言葉をよく聞くけど、具体的な進め方が分からない」と悩む方は少なくありません。PoCはシステム開発前に行うプロセスで、プロジェクトの成功確率を高めるのに重要とされています。しかし、状況によって具体的な進め方が異なるのもあり、どうやってPoCを行うのが正解なのかと疑問に感じる方が多いのです。PoCの進め方が分からない場合は、まず一般的な流れを知ったうえで、自分のプロジェクトに合わせてカスタマイズしていきましょう。

本記事では、PoCの具体的な進め方や注意点をわかりやすく解説します。各フェーズにおいて注意すべき点だけでなく、PoC全体で注意すべき点も解説しますので、この記事を読めばPoCを適切に行えるようになるはずです。ぜひ、この記事を参考にしてPoCを行ってみてください。

PoCの重要性と課題

PoC（ポック/ピーオーシー）とは、企画の初期段階で、プロジェクトにおける新技術やアイデアなどが実現可能なのかを検証するプロセスです。広義な意味では、PoV（価値実証）やPoB（ビジネス実証）も含めた検証をPoCと呼ぶ場合もあります。

PoCは、プロジェクトの成功確率を早い段階で明らかにするために重要なプロセスです。技術的に実現できるのか、顧客ニーズが本当にあるのか、想定通りの利益が見込めるかといった点を検証しておけば、プロジェクトが失敗したり、途中で停滞したりするのを防げます。

ただし、慎重になってPoCをやりすぎた結果、PoCにコストやリソースを割きすぎてしまう事態に陥る場合もあります。PoCをしている段階では製品開発が進まないので、適切な範囲内で行うのが重要です。

PoCの具体的な進め方、手順について

PoCの進め方は、検証内容によって異なります。具体的には「ゴール設定→範囲設定→計画策定→リソース確保→実施→評価とFB」といった流れで行うのが一般的です。以下ではPoCの基本的な流れについて解説しますが、必ずしも以下の流れで行わなくても構いません。プロジェクトの検証内容に合わせてアレンジしながら、適切なかたちで検証を進めてください。

目的と目標の明確化

まず始めに、目的と目標を明確にします。どこを目指すのかが定まっていないと、PoCの終わりが見えなくなり、課題が絶えず見つかり続けたり、無駄に長期化する原因になります。「何を知りたいのか」「何を達成すればよいのか」を明らかにし、効率的にPoCを進めましょう。

目的の特定

まずは目的の特定です。目的の特定では「何のためにPoCをするのか」を決めていきます。技術やアイデアの実現性を確認するのか、PoVやPoBの検証に重きを置くのかを考えます。多くの場合、実現可能性の検証が主になりますが、顧客への価値提供や損益分岐点などを検証するケースもあります。何を実証したいのかを明らかにすると、その後のフローは全て「目的達成のために何をすべきか」という一つの軸に沿って進められます。

目標の設定

目標の設定では、PoCでは定量的な指標を用いないケースもありますが、特にPoBの検証が含まれる場合は定量目標が必要になります。PoBは、損益分岐点や利益率、費用対効果などを検証するプロセスです。提供価値をPoVで検証した後に、ビジネスとして想定通りの利益が上がるかを検証します。目標は「技術面」「移行・導入」「費用・工数」「計画」「メンバースキル」などの項目に分けて考えます。全ての指標を設定する必要はなく、検証したい内容に合わせて指標を考えます。

計画と範囲の策定

ゴール設定ができたら、範囲と計画の策定を行います。「どの範囲をどんな流れでやるか」が、範囲と計画の策定です。範囲を適切に定めること、そして無理のない計画を立てることは、PoCを成功させるために重要になってきます。逆に、範囲や計画が不適切だと、PoCが失敗する可能性が高まります。以下では、範囲と計画の策定について詳しく説明します。

範囲の定義

PoCの範囲とは「このプロジェクトにおけるどの部分を検証対象とするか」という意味です。PoCが失敗する主な要因として「範囲を広げすぎる」といったケースがあります。PoCはあくまで新規プロジェクトの実現可能性を「可能・不可能」で評価するのであって、プロジェクト全体を通して「良い・悪い」を検討するものではありません。そのため、目的に定めた内容を把握するのに最低限な範囲で、検証を行えるようにしましょう。

計画の作成

無理のない計画を立てるのも、PoCの成功において重要です。計画は、範囲の広さ・指標の多さ・メンバーの人数やスキルなどによって左右されます。また、必ず意識したいのが「PoC自体の費用対効果」です。PoCをしている間は利益が生まれず、人件費や設備費といったコストのみが発生していきます。そのため、プロジェクト全体を通じて「PoCをどのくらいの期間、どの程度のコストをかけて行うのが適切か」を考えないといけないのです。PoCにリソースを割きすぎないように注意しつつ、適切なかたちで計画を立てましょう。

リソースとチームの確保

PoCでは、検証したい内容に合わせてチームを編成する必要があります。PoCでは簡易的なプロトタイプを作成したり、本番に近い環境を用意したりするので、ある程度のスキルがあるメンバーを確保しなければなりません。また、しっかりと検証・評価ができるようにリソースを確保するのも重要です。検証が不十分な状態で終わったり、検証方法が不適切だったりすると、プロジェクトが失敗してより大きな損失が発生する可能性もあります。プロジェクトの成功可否を確実に判断するために、余裕をもってリソースとチームを確保しましょう。

実施とモニタリング

目標や計画などが策定できて、リソースが確保できたら、いよいよPoCを実施していきます。実施において重要なのは、環境の整備です。本番と近い環境が用意できていなかったり、適切なモニタリング環境がなかったりすると、得られたデータや分析結果も意味がなくなってしまいます。以下の内容を参考にして、適切なデータを得られるように取り組みを進めていきましょう。

プロトタイプの開発とテスト

検証内容によって異なりますが、最低限の機能を備えたプロトタイプを開発してテストをする場合もあります。プロトタイプを開発する必要があるのは、既存サービスと新システムを連携させるといったプロジェクトの場合です。また、実際にユーザーに試用してもらいたい場合にもプロトタイプを開発する場合があります。プロトタイプについては、検証に必要な最低限の機能を搭載していれば問題ありまません。しかし、UIに関するテストが入る場合は、ある程度の開発期間を設けたほうが良いでしょう。

進捗の監視と調整

プロトタイプを開発したら、PoCを実施しつつ進捗の監視および調整を行っていきます。検証の実施および進捗の監視では、なるべく本番の環境に近い状態で行うように心がけてください。また、大幅な調整が必要な場合は、一旦データとしてまとめ分析をした後、PoCを最初からやり直さないといけない場合もあります。進めていくなかでスケジュールに調整が必要になった場合には、原因を明らかにしたうえで、一旦データをまとめるのか、検証を続けるのかを検討しましょう。

データ収集と分析

PoCを実施したら、データ収集および分析を行います。データ収集をする際は、必ず指標に基づいて行ってください。また、目的からブレがないよう再度確認をしておくのも重要です。データ収集をしていくうちに、目的達成に必要なデータを取りこぼしたり、範囲がどんどん広がってしまったりする場合があるので注意しましょう。分析では、最終的にプロジェクトの実現性について評価ができるようにデータをまとめます。実現が困難だった場合、どのようにすれば改善できるかも分析段階で考えておきましょう。

結果の評価と次のステップ

データ収集および分析ができたら、結果の評価をしましょう。評価のフェーズでは「指標を達成できたかどうか」が重要な評価軸になります。データ収集において想定外のことが発生したら、原因を探りましょう。微調整で済むようであれば問題ありませんが、技術的に大きな問題があった場合、顧客への提供価値が想定より低かった場合などは、企画について根本的な見直しが必要になります。次にどういったステップに進むかまで明らかにしたら、次の「報告とフィードバック」に入ります。

報告とフィードバック

結果がまとまったら、報告およびフィードバックを行います。PoCを通じてプロジェクトの技術・アイデアについて実現可能かを報告するのが、報告・フィードバックで行うべき内容です。もし実現が困難だった場合には、改善のうえ再度PoCを実施するのか、プロジェクト自体を中止すべきかについても報告をします。再度PoCを行う場合は、損益分岐や利益率などPoBの部分に変更が加わるので、新たに試算をして分析・評価・報告を行ってください。

PoCを進めるときの注意点

PoCはプロジェクトの成功可否を早期に判断するのに役立つ一方で、PoC自体にコストがかかってしまったり、長期化しやすかったりといった課題点もあります。しかし、注意点を把握したうえで対策を考えておけば、より適切にPoCを実施できるでしょう。以下では、PoCを進めるときの注意点を3つ紹介します。解決策についても合わせて紹介するので、これからPoCを行う方はぜひ参考にしてください。

クイックに実施する

PoCを行うのにとても重要なのが、迅速性です。プロジェクトが良いものであればあるほど「実現性は低そうだが、どうにか改善できないか」とPoCを繰り返す事態に陥りやすくなります。しかし、PoCの目的はあくまでプロジェクトが実現できるかどうか、顧客ニーズを満たし想定通りの利益を上げられるかを判断することです。PoCをどれだけ長くやっても、プロジェクト自体が飛躍的に良くなることはありません。また、PoCが長期化するほどプロジェクトのコスト回収が困難になっていきます。PoCは適切な期間で行い、長期化しそうであればそもそもの企画案自体を根本から見直すようにしましょう。

PoCを目的化しない

PoCが目的になってしまって、長期化するケースも非常に多くあります。PoCが、PDCAのように「プロジェクトをどんどん改善するためのもの」といった認識になってしまうのです。しかし、PoCは開発プロセスではないので、開発するプロダクトをより良くする効果はあまりありません。PoCの最中にプロジェクトの効率化について検討することはありますが、プロダクトの機能を高めることは基本的にないのです。PoCはあくまで「実現可能性の判断プロセス」として捉え、PoCを行うこと自体が目的化しないよう注意してください。

本番運用と条件を揃える

PoCは技術・アイデアに関する実現可能性を検証するプロセスであるため、出来る限り本番に近い環境で行うようにしましょう。本番運用と条件が揃っていないと、実際にプロトタイプや製品を開発し始めてから技術的な問題が生じやすくなります。PoCは、プロトタイプ開発や製品開発を始めるよりも前に、早期に問題点を把握するのも役割のひとつです。開発に入ってから問題が発覚するといったことがないように、本番運用と条件を揃えたうえでPoCを実施しましょう。

まとめ

PoCはプロジェクトが成功するか、想定通りに進むかを判断するのにとても有益な開発方法です。しかし、PoCは製品開発手法ではなくあくまでプロジェクトの評価手法なので、適切な範囲と期間で行うよう注意しましょう。プロジェクトのリターンを踏まえて、コストやリソースをかけすぎずに行うのがポイントです。

本記事で紹介した方法でPoCを行えば、必要なデータを揃えた状態でプロジェクトの評価ができます。しかし、PoCの進め方は検証したい内容によって異なるので、本記事の内容はあくまで一例として考えてください。まずは目的と目標を定めたうえで、それらを達成できるよう取り組み方法を考え、PoCを実施していきましょう。