事業機会の魅力度の検証
市場規模をざっくり推計します。このステージでは、スピード優先で、ざっくり、さくっと出すというのでよいでしょう。事業機会の市場規模が、数億の桁なのか、数十億の桁なのか、百億の桁なのか、または千億の桁なのかを認識することが大切です。
そして、同じニーズをターゲットしている、類似サービスのベンチマークを通じて競争の厳しさを計ります。思いきり意図して同じニーズをターゲットとしているサービス、図らずとも副次的なそのニーズを部分的に満たしているサービスの両方をベンチマークし、彼らがそのニーズを満たすうえで、何をうまくやって、何が不足しているのか、そして、彼らに対して持続可能な競争優位性が築けそうかを把握します。
プロダクトの開発
ユーザ層、ニーズが特定され、それが事業機会として魅力的だと検証されたら、いよいよプロダクトとして作り込んでいくことになります。大まかに、コンセプト開発→要件定義→実装→αテスト→βテスト→正式リリースと進めていくわけですが、その中で気をつけるべきポイントを挙げていきたいと思います。
1. ユーザ・ニーズを起点にすべてを作り込む
プロダクトを開発していて陥りがちな罠は、「こんなアイディア面白くない？」「こんな機能もいいね」とやっているうちに、最近の家電のようにありとあらえることができるものを作ってしまうことです。しかし、「なんでもできる」は「なにもできない」に等しいです。たとえば、匿名で誰にも言えない秘密をコミュニティ上で吐露したいユーザにとって、実名で実生活の友人とオープンにコミュニケーションを取れるということは、まったく求めておらず、むしろ秘密を吐露することを躊躇してしまうかもしれません。
ターゲットとなるユーザ・ニーズを、ただひたすら最も純度高く叶えるようにプロダクトを作り込むことこそが必要なのです。
それを実践するフレームワークとして、M- F-T：Market（市場・ニーズ）-Function（機能）-Technology（テクノロジー）というものがあります。事業機会として特定されているニーズに対して、そのニーズを叶えるために、「必要な機能は何か？」「そのニーズをよりうまく叶える機能は何か？」という問いをベースに、プロダクトが備えるべき機能を定義するのです。そして、定義されたそれぞれの機能に対して、「この機能を実現するにはどのような技術は必要か？」「この機能を最も効率的に実現するにはどのような技術がベストか？」という形で詰めていきます。
備える機能を定義し、使用技術を決める過程で、それぞれブレスト的にアイディア出しをすることになりますので、「こんな機能も備えたらどうか」「こんな技術も使ってみたい」と、どんどん膨らんでいくことでしょう。
しかし、原点に立ち返り、ユーザ・ニーズを起点に、本当にそのニーズを叶えるために必要な機能に絞り、そしてその機能を実現するベストな技術のみを使うべきなのです。プロダクトを開発の中でおのずと起こる、「発散と収束」を意識的に管理して、ユーザ・ニーズを叶えるために必要十分な機能・技術に絞るという“引き算の発想”でプロダクトを作り込むことこそが重要なのです。
2. ディレクター機能とプロデューサー機能で品質とコスト・納期のバランスを取る
また、プロダクト開発のプロセスの仕組みがきっちり固まっていないベンチャーが陥りがちな罠は、いいものを出そうと作り込んでしまうがあまり、大幅に予算をオーバーしてしまったり、リリースが大きく遅れてしまり、また逆に予算やリリース日を守ろうとするがあまり、ユーザに支持されるにはまったく不十分なものを出してしまったりすることです。
この問題は、プロダクト開発におけるＱＣＤ：Quality（品質）、Cost（コスト）、Delivery（納期）の最適なバランスを取るのに失敗しているということです。一般的にQ(品質)とCD(コスト、納期)はある程度のトレードオフの関係にあります。クリエーター的視点でどこまで品質を追求するか、ビジネス的視点でコスト、納期をどこまで厳守するか、これはプロダクト開発における永遠の悩みで、どこを落とし所にするかの正解ははっきり言ってひとつではありません。だだし、正解の“範囲”みたいなものはあり、この範囲を逸脱すると前述のように過剰品質になったり、拙速なリリースになってしまったりします。
この問題の難しさは、品質とコスト・納期という背反する、ビジネス上の命題を両立して満たさなければいけない点であり、人間の性（さが）として一方を気にしだすとついついそちらに没頭してしまい、もう一方をおろそかにしてしまう点にあります。そう言った意味では、
（1）品質を管轄するディレクターと
（2）そのプロダクトの最終ＰＬ責任（売上、利益の予算達成責任）をもちコスト・納期を管轄するプロデューサー
の二つに、少なくとも機能的には明確に分けることが、お互いに牽制しあいバランスを取るうえでは有効です。
“少なくとも機能的には”と述べたのは、質的にも量的にも人材に余裕があれば、ディレクターとプロデューサーそれぞれに別の人を任命するのがベストです。ただし、ベンチャー、特に一つ目のプロダクトを開発しているベンチャーではなかなかその余裕はないでしょう。ですので、ディレクターとプロデューサーを一人の人が兼ねるとしても、両者を完全に別の機能として意識して、この場面はどちらの立場で考えているか、発言しているかを意識すれば、多少なりともバランスはとりやすくなるでしょう。
また、きっちりしたモノづくりをビジネス的な成果に繋げるために重要なのは、プロダクト開発の現場にもＰＬ責任を持たせ、さらには明確に人事評価に結びつけることです。
3. 冷徹なGreen Lightingの仕組みの導入
また、リソースに制限のあるベンチャーにとって大切なのは、全体のプロダクト開発コストを効率化する意味でも、そして何よりも、最も貴重なリソースであるプロダクト開発のキーマンの活用効率をあげることです。特に、0→1ができるクリエーターで、ヒットを出せる所謂天才型の人材は超が付くほど戦略的かつ貴重なリソースなはずです。彼らを、キャッシュや在庫同様に回転率的な考え方で、”人材回転率”の概念を導入し、見込みがなくなった開発プロジェクトからは外し、常にヒットを狙うプロダクト開発プロジェクトにアサインし続けることが重要です。
そのためには、コンセプト開発→要件定義→実装→αテスト→βテスト→正式リリースの、新プロダクト開発のすべての段階で、次段階に進めるための基準を事前に明文化し、合意しておく必要があります。その際には、運用上は杓子定規とも言えるくらい厳格に基準を適用することがミソです。
物理的、精神的なコストを掛けプロダクトの開発を始めると、愛着がわいてきて、そのプロジェクトを続けるほうにどうしても情がわいてしまい、なかなか冷静な判断を下すのが難しくなってしまいます。また、組織にしても、慣性が働きますので、それまでやっていることを途中で止めることは容易ではありません。だからこそ、事前に基準を決め、その基準を満たさない場合は冷徹に切る仕組み=”Green Lighting（英語で青信号はGreen Lightのため、前に進めるの意）”の仕組みが必要になってくるのです。
本来は「例外はない」と言い切りたいくらいなのですが、現実にはどうしても戦略性の高いプロダクトや思いっきりハイリスクだがハイリターンなプロダクトなどは、例外措置として救い上げることも必要なプロダクトもあり得ます。その場合は、例外措置として救う意思決定をプロダクト開発の現場から引き離し、経営レベルにまで持ち上げる必要があります。
経営レベルの、プロダクト開発に携わっていないメンバーも含めた、複数人による会議体で救い上げるようなプロセスに設計するのがよいでしょう。冷徹にダメなプロダクトを途中で切ることを可能とするGreen Lightingの仕組みを形骸化しないためには、そもそもその会議体に上程すること自体を難しくする、会議体で例外として承認されるには全会一致とするなど、相当ハードルを高くするのがよいでしょう。
そして、次に述べますが、実は常にユーザの声に耳を傾け、壁打ちしながら開発をすすめるのも非常に大事なポイントになります。
