「PoCをやってみよう！」の危うさ

PoCを直訳すると「概念実証」。もともとは、医薬品業界・映画業界・IT業界で使われてきた用語だが、昨今ではビジネスの世界でも広く流通する用語になってきており、この時期はビジネスにおけるDXの必要性が叫ばれ始めた頃に重なると考える。そのためか、PoCの意味するところを「事業開発の場面で、デジタル技術を利用した製品・サービスのプロトタイプをテストすること」としているケースが多い。したがって、本稿でもこれをPoCの定義として、以降の議論を展開していくことにする [1]。

ビジネスの世界で広く流通するようになってきているPoCだが、実際には十分な成果を得られず、プロジェクトをPoC以降のフェーズに進めることができずにいるケースも少なくない。このようなケースについて、PoCの現場では図1のような共通した流れがあると捉えている。すなわち、「目新しいデジタル機器に心を奪われ、一般的に言われる“DXで実現できること”をそのまま自社に取り入れてしまい、『弊社もPoCをやってみよう！』と始めて、その結果として出てきた大量の事象や意見を一つ一つ潰すことに躍起となり、関係者の体力が尽きた時にプロジェクトが停止する、または責任者が痺れを切らせた時に『大した成果はなかった』という結末を迎える」といったものである。

図1 ：PoC現場での検討実態(代表例)

このようにプロジェクトが停止したり、大した成果を得られずに結末を迎えてしまったりする原因の一つとして、「『PoCで何をテストするか』が曖昧で絞れておらず、関係者間で共通認識が醸成されていない状態でPoCに入っている」ことが挙げられると考えている。こうした場合、PoCから得られる結果の多くは「この機能では、今の弊社と同じレベルのサービスを提供できない」「こういう機能もあると、これまでできなかったことが簡単にできるようになる」といった技術批評に偏る傾向があるのも特徴だ。PoCが「製品・サービスのプロトタイプをテストすること」だとすると、この情報だけでは不十分である。

PoCでテストすることが曖昧なままで、「PoCをやってみよう！」という"ノリ"で開始するのは危ういのだ。それでは、どうしたらよいのか。事業開発の場面において、「PoCで何をテストするか」を定めるために必要なことを考察していく。

「PoCで何をテストするか」を定めるために必要なこと

1. 「PoCで何をテストするか」をどう定めるのか

PoCで何をテストするか。換言すると、何をテスト項目とするか。残念ながら、これに対する画一的な答えはない。なぜなら、PoCでのテスト項目は、「何のためにPoCを行うのか」というPoCの目的にもとづいて設定することになるためだ。

それでは、PoCの目的とは何か。簡単に言うと、「プロトタイプが、立案した事業戦略を実現する製品・サービスになっているか」を検証することである。つまり、事業戦略の検証だ。これを検証するためには、当然ながら事業戦略自体が煮詰まっている必要がある。例えば、事業戦略で定めた以下のような要素を足掛かりとして、PoCのテスト項目を設計していくことになる。

• ターゲット顧客
• 提供する顧客体験、ブランディング
• それを実現する製品・サービス

それでは、事業戦略自体はどうやって検討していくのか。「環境分析、ターゲット特定、戦略立案」といったタスクがすぐに思い浮かぶだろう。もちろん、これも必要な要素だが、その前工程として「その新規事業は、自社にとって何のために行うのか」を明確にしておく必要があると考える。これは、ビジネスコンセプトを定めておくことに相当する。これがないと、事業戦略を検討している際に「無数の選択肢の中から、どれを採用するか」で迷走してしまうし、それを考えているだけで疲弊してしまう（この点で苦悶している取り組みも、また多く見かける）。したがって、事業戦略を検討する際の「選択肢を絞る」「選択で迷わない」ようにするためには、ビジネスコンセプトを定めておくことが必要となる。

つまり、ビジネスコンセプト・事業戦略を詳細まで詰めておかないと「PoCで何をテストするか」を定めることができないのである。

2. 事業開発の検討プロセスとPoCの位置付け

ここで、事業開発の検討プロセスを確認しておきたい。一般的には図2のようになっている。

図2： 事業開発の一般的な検討プロセス

本稿のPoCの定義である「事業開発の場面で、デジタル技術を利用した製品・サービスのプロトタイプをテストすること」をこのプロセスに当てはめると、PoCは検証の一手段と位置付けることができる（なお、検証としてテストマーケティングがよく用いられるが、PoCもテストマーケティングの一種と考える）。そして、事業戦略立案は検証よりも前工程であり、ビジネスコンセプト考案は先頭のプロセスである。

つまり、事業開発の先頭のプロセスから順を追って定めておかないと、「PoCで何をテストするか」を決めることはできないのである。言い換えると、PoCの前工程までが詳細に詰まっていない状態でPoCから何かを得ようとするのは無理があるのだ。逆に、先頭のプロセスから順を追って定めずに「PoCで何をテストするか」を設計すると、目の前にあるプロトタイプに思考が引っ張られてしまい、出てきた結果（事象・意見）をどう料理したらよいか（取捨選択・構造化・優先順位付け）が分からなくなってしまう、という現象に陥るのである。

3. PoCで何をテストするか

前項までは、「PoCのテスト項目を設計する場合、結局は事業開発の先頭のプロセスであるビジネスコンセプトから順を追って詳細に詰めていく必要がある」ことを述べてきた。ここからは、PoCのテスト項目の設計方法について、例を交えながら述べていきたい。

PoCのテスト項目は事業戦略を足掛かりに設計するため、当然のことながら「どのような事業戦略（遡ると、ビジネスコンセプト）を描いているか」によって、何をテスト項目とするかは大きく異なってくる。

例えば、コスト削減を掲げる新規事業であれば、その実現可能性を測る（テストする）必要がある。そのためには、もちろんコストの削減規模が事業戦略立案の時点で明確になっていることが前提となる。また、新しいマーケットを狙うのであれば、売上・利益（既存マーケットと同じ売上・利益が得られるのか、あるいはそれより多いのか、少ないのか）のシミュレーションが、事業戦略を立案する時点で必須となる。

一方で、特定の製品・サービスを新しいフラッグシップと位置づけたいのであれば、「ターゲット顧客がそのように認知してくれるコンテンツになっているか」を測る（テストする）必要がある。このような場合は、コストのことはそれほど意識しなくてもよいと考えられ、場合によっては「赤字でも実施する」という選択肢もあり得る。こうした投資対効果の許容範囲についても、事業戦略立案の時点で定めておく必要がある。これらを明らかにした状態で、初めて実現可能性についてPoCで検証するという議題に入ることができる。

また、PoCのテスト項目を設計する上では、「今回行うPoCの位置付け」も明確にしておく必要がある。例えば、初版のプロトタイプのテストなのか、第2版のテストなのか、上市前の最終テストなのか。この位置付けによっても、テスト項目は異なってくるし、出てきた結果の合否判定も異なってくる。「今回行うPoCの位置付け」が曖昧なままだと、判断基準が曖昧な状態と同じであるため、出てきた結果の「取捨選択」「構造化」「優先順位付け」もできなくなる。

なお、PoCは、ビジネスコンセプト・事業戦略の実現性をテストする場であるため、描いたビジネスコンセプト・事業戦略にできるだけ近い条件で行う必要がある（ターゲット顧客・場所・時間帯・場面、等々）。もちろん、全ての条件を揃えることができない場合もあるだろう。その場合は、出てきた結果の取捨選択を注意深く行う必要がある。その際の"物差し"となるのが、ビジネスコンセプト・事業戦略というわけだ。それらが定まっていない状態だと、PoCの結果を「今後の取り組みに活かすべきか」「気にしなくてよいか」を判断することができなくなるのだ。例えば、プロトタイプを体験した被験者のうち、ネガティブな反応をしたのが、中核のターゲット顧客でなかった場合は、気にせず進めてよいという判断もあり得る。

事業開発のPoCでつまずかないために

本稿では、事業開発がPoCでつまずかないために、「PoCで何をテストするか」を定めるために必要なことを紐解いてきた。その結論とした「ビジネスコンセプト・事業戦略を煮詰めて、そこから導出する」という示唆は、一見基本的なことと思われるかもしれない。

しかし、実際にはビジネスコンセプト・事業戦略が曖昧なままで、「何はともあれ、PoCをやってみよう」と突き進んだ結果、行き詰まってしまったり、ビジネスコンセプトの検討からやり直すことになってしまったりするケースを多く見てきている。「進めながら考えよう。必要があれば遡ればよい」という考え方もあり、それ自体は否定されるものではない。ただ、その結果として行き詰まり、前工程に遡ることになると、その事業開発の取り組み自体にネガティブな印象を与えることになる。仮に、社内に一定数の反対派がいれば、これをきっかけとして事業開発の屋台骨を揺るがす事態に発展しかねないし、そもそも事業開発の参画者も疲弊して疑心暗鬼になってしまう（最悪の場合は、参画者から反対派が出てくる）。とは言うものの、実際のビジネスの現場ではさまざまな背景・事情・利権・しがらみ等が複雑に絡み合って、「基本に立ち返る」ことが難しい局面も多々あるものと理解している。読者がそういった局面を迎えた際に、本稿が一助になれば幸いである。