エッジコンピューティングはまだまだ新しい概念で、これからPoCを経て導入を検討するというユーザーも多いと思います。ところで、皆さんはPoCという言葉を聞いたことがあるでしょうか？インターネットで検索をかけると出てきますが、一般にはあまりなじみのない言葉かもしれません。しかし、製品開発やシステム開発の分野などでは、今後使われる機会が増えることも予想される言葉です。ここでは、PoCの定義や、PoCと試作・プロトタイプとの違い、PoCの必要性とメリット、そしてPoCの検証作業の流れについて解説します。
PoCとは
PoCとはProof Of Conceptの略で、日本語では「概念実証」と訳します。新しい製品やシステムのプロジェクトを立ち上げる前に、製品やシステムの有効性を検証することを指します。たとえば、新製品を開発する際に、本格的な販売の前にテスト販売や顧客へのモニターを行って、実際に売れるかどうかを検証すること。あるいは、システム開発において、最低限の実装を行いテスト的に運用してみるなどを指します。
PoCと今までの検証作業の違い
PoCの考え方のうち、実際に作ってみたり、使ってみたりするという考え方自体は昔からある製品開発における「試作」や、システム開発における「プロトタイプ」などが挙げられます。この「試作」や「プロトタイプ」によってプロジェクトの進み具合や、開発における不具合などをチェックしているわけです。開発プロジェクトの流れは、「構想→計画→開発→テスト→運用・販売」の流れで行われますが、「試作」や「プロトタイプ」は開発フェーズ、またはテストフェーズのなかで随時行われていました。
これに対して、PoCは構想フェーズの段階の次、つまり構想と計画フェーズの間にあることが多いです。また、試作やプロトタイプが、開発の出来栄えの確認的な位置づけなのに対して、PoCの結果次第では、開発の方針が大きく変更することや、場合によっては、開発を断念することもありえます。つまり、本格的な開発プロジェクトが動き出す前に概念設計が適切かどうか検証することといえるでしょう。
PoCの必要性とメリット
近年、顧客ニーズの多様化や製品のライフサイクルの短期化に伴って、開発の不確実性が増大しています。また、システム開発でも、IoTや人工知能など新しい分野に挑戦することが多くなっており、ここでも不確実性が高くなるといえるでしょう。わかりやすくいえば、こうした不確実性によって開発の狙いが外れるリスクが高くなっているのです。
今までの開発の流れでは、構想段階でこれらのリスクを予測し、それをあらかじめ取り込んで開発に取り組むことが行われていました。この場合には、構想段階でのリスク予測がとても重要です。ところが、先に挙げたような変化によって、予想できないリスクが発生することも多くなってきているのです。開発が進んでからこのリスクが顕在化した場合、それまでの開発過程がすべて無駄になることもありえます。
こうした事態は、より早い段階でリスクを把握することで回避が可能です。そこで、とりあえず構想がまとまった段階で、製品やシステムを小規模で作り、実際に顧客に使ってみてもらうことが考えられます。売れ行きや不具合を取り込んで構想を修正していき、そのうえで本格的な開発を行えば、途中ですべてがダメになるようなリスクは下げられるでしょう。
また、このようなPoCによってコンセプトをブラッシュアップしていくので、開発方針がより明確になり、プロジェクトの進行がスムーズに進むというメリットもあります。言い方を変えれば、PoCとは本格的な開発を行う前に、構想をよりユーザーのニーズにマッチするように修正すること、さらには、小規模なテスト販売やテスト運用であらかじめユーザーのニーズを取り込んでいくことともいえるでしょう。
PoCを行う一例としては、人工知能の開発が挙げられます。ここでは、もっとも重要な人工知能のエンジン部分のみをとりあえず完成させ、ユーザーと協力しながら学習をさせブラッシュアップさせていくことが考えられます。このように、本格的なシステム開発の前に重要な部分だけをユーザーと協力しながらブラッシュアップしていくスタイルもPoCといえるでしょう。
ただし、構想段階でユーザーに使ってもらうため、商品やシステムのコンセプトが外部に流出し、最悪の場合には競合がその情報を入手してしまう、といったデメリットが考えられるので、注意が必要です。
PoCの検証の流れ
さまざまなメリットのあるPoCですが、やみくもに行っても効果は出ません。効果的な検証の流れについて見てみましょう。
- 効果・効用の検証
まず、対象となる製品やシステムが達成しようとしていることがユーザーのニーズにマッチしているかの検証を行います。つまり、意図したニーズへの効果を実現しているかどうか見極める、ということです。たとえば、新薬の臨床試験では、安全性が確保された新薬候補を実際に被験者に投与して、意図した効果があるかどうかを確認します。販売される前に、販売された場合よりもはるかに少ない被験者の数で試験が行われるために、PoCといえます。 - 技術的実現性の検証
次に、そのコンセプトが机上の空論ではなく、実際に実現が可能であるかどうかの検証を行います。少し意外な例では、短編映画が挙げられるでしょう。これは、長編映画を製作する前に、小規模な作品を作ることで、必要な技術的課題が実現できるかどうかを検証するという目的があります。なお、PoCで行いがちなのは、効果・効用の検証よりも技術的実現性の検証を先行させてしまう場合がよくあります。つまり、技術が先行してしまうということですが、その結果として対象とするニーズが満たされているかどうか検証が不十分なまま開発が進む可能性もあるのです。PoCではあくまでも、目的とする効果・効用を実現するための手法であることを意識しておくべきでしょう。 - 具体性の検証
そして、コンセプトが要求する仕様や検討課題を洗い出して、それらが具体的なものであるかどうかを確認する検証を行います。これは、市場調査の結果や、実際に使ってみたユーザーの声をくみ上げて、開発に生かしていくということです。
以上の検証を経てコンセプトを修正し、修正したコンセプトに基づいて製品やシステムを試作、さらにユーザーに使ってもらい、再び検証を行っていきます。これを繰り返すことで、「効果・効用」「技術的実現性」「具体性」を達成しうるコンセプトにブラッシュアップできるのです。ブラッシュアップが十分に行われた段階で、次の計画フェーズへと移っていきます。
大切なことは、実際にユーザーに使ってみてもらうことです。これにより、完成品がユーザーが求めるものとかけ離れたものになってしまうリスクを回避できます。また、検証の規模をあまり大きくしないことも大切です。これは、コンセプトの確立に必要な作業のコストを下げることだけではなく、開発のコンセプトを極力外部に流出させないというリスクヘッジにもつながります。
PoCはメリットの大きい手法
構想段階でユーザーの意見を聞くPoCを行うことは、コンセプトのブラッシュアップや開発リスクの低減、プロジェクトのスムーズな進行、といったメリットにつながります。ただし、検証の規模や回数を多くしすぎると、コストの増大やコンセプトの外部流出を招く危険性があることは、デメリットとして注意が必要です。
なお、副次的なメリットとして、仮にPoCの結果、開発を断念したとしても、実際にユーザーの意見をデータとして収集できているので、PoCの過程で得られた知見は無駄になることはありません。次回の開発に生かすことができるのです。その意味でも、PoCはメリットの大きい手法といえるでしょう。
