ユーザーが負荷を感じない収益モデルの設計

　収益モデルの設計においては、価格設定だけでなく、ユーザーが継続的に支払えるかどうかも重要である。収益モデルは「支払者」「支払い対象」「支払いタイプ」「支払い料金」の4つの要素で構成され、これらの要素を組み合わせて、提供する価値や課題に適したモデルを選ぶことが求められる。

　たとえば、24時間利用できるジムは、好きな時間に運動できる体験への課金に該当するため、月額課金が適している。一方、RIZAPのように目に見える成果に対して対価を支払うサービスでは、一括払いの方が適している。このように、提供価値に合った支払い方法を設計し、ユーザーの負担を最小限に抑えることが重要だ。

　収益モデルが確定した後は、KPI構造を分解して分析する必要がある。まずは価値と価値提供コストのバランスを確認し、次に顧客単位や事業単位で利益が出るか、最終的には投資単位で収益を上げ、累損回収ができるかを確認していくプロセスが求められる。

　サービス仮説を言語化する作業は、初めから完璧に行うのは難しい。だからこそ、フレームワークを活用して欠けている要素や弱い仮説を洗い出し、チームで改善を図ることが重要である。

　ビジネス寄りのチームでは机上の空論に陥りやすいため、クリエイティブな人材を補完し、顧客像を明確にすることが求められる。

　一方、技術志向の強いR&Dチームでは、技術が市場に適合するかどうかが見えていないことが多いため、ビジネス人材を補完し、事業機会に昇華するアプローチが必要である。

　また、スタートアップではクリエイティブに偏りがちで、市場性が不明確なことが多い。このような場合も、ビジネス人材を補完し、n1顧客にとっての価値をどのセグメントにとっての価値に変えるかを検討することが効果的である。

MVPはブラックボックスを検証するためのツール

　西谷氏は、MVP（Minimum Viable Product）をブラックボックスとなっている部分を検証するためのツールとして位置付ける。市場に既存のプロダクトがあり、提供する価値に自信がある部分については再検証の必要はない。不明確な部分や自信がない部分を重点的に検証することが重要であると強調する。

　例えば、ゲームにSNS機能を追加してコミュニティを強化し、継続率を高めるといった場合、こうしたSNS連携機能は他のプロダクトで既に実装されているため、改めてテストする必要はない。

　MVPの開発においても、BTCを考慮したチーム組成が重要だ。西谷氏は、リサーチにおいて100%の理解を目指すのではなく、市場や顧客について80%の理解に到達した時点でMVPの開発に着手することを推奨する。リサーチを100%に近づけるほどコストが増大し、得られるインサイトは相対的に少なくなるからだ。この段階でMVPに着手することで、時間とコストを最小限に抑えた効率的な開発が可能になる。

　また、西谷氏はリサーチ段階でエンジニアをチームに加えることの重要性を説く。エンジニアがMVPの開発イメージを共有していれば、その後の要件定義や見積もりがスムーズに進み、コスト削減につながる。ビジネス人材やクリエイティブ人材と同じレベルのインプットを得るためにも、エンジニアと共にリサーチを進め、MVPを作るタイミングを適切に見極めることが肝要であるとして、講演を締めくくった。