PSFとは？課題に対して正しい解決策を提示できている状態
PSF（プロブレムソリューションフィット）とは、企業が解決しようとしている課題に対して、正しい解決策を提示できている状態のことをいいます。ビジネスの基礎として「解決するべき課題が存在すること」「課題を抱えた顧客が存在すること」「課題に対して最適な解決策を提案していること」の3つがそれぞれ欠かせない要素となるため、これらを大きな資金を投入する前に検証するべきであるというのが、PSFの根底にある考え方です。
特に市場の存在が不明確なスタートアップビジネスにおいては、事業の初期段階で、課題・顧客・課題へのアプローチを正しく把握することは大変重要です。これらを見誤ってしまうと、のちにどんなにプロダクトを改善しても成果が出ないというような事態に陥ってしまいます。そもそも顧客にとって重要な課題を解決しようとしているかどうかという問題は、UXデザインの改善について考える前段階として、確実に検証しておきたいものです。
PMFとの違い・関係性
PMF （プロダクトマーケットフィット）は、PSFと並んでスタートアップビジネスの初期段階に検証するべきものとしてよく知られています。PMFとは、顧客の課題を解決する手段としての「プロダクト」と「価格」がユーザーのニーズにマッチしている状態を表す言葉で、PSFの後工程となります。つまり、スタートアップビジネスの初期フェーズとして、まずはPSFの検証、これが完了したのちPMFの検証を行います。
根本的な市場ニーズの検証（PSF）とプロダクト自体の検証（PMF）を分けて考えることで、軌道修正が必要な場合により早い段階で行うことができるようになります。また、たとえPMFで躓いても、PSFが検証できていれば、事業を白紙に戻す必要はなく、プロダクトの方向性のみ再検討することで問題を解決できるかもしれません。
スタートアップのビジネス検証フェーズ全体
さらに視野を広げて、スタートアップビジネスにおけるビジネス検証フェーズ全体についても確認しておきましょう。リーンスタートアップの実践書「Running Lean 実践スタートアップ」において、著者であるアッシュ・マウリャ氏は次のように述べて います。
PMF前は、学習とピボットに集中します。PMF後は、成長と最適化に集中が移動します。
Running Lean 実践スタートアップ
つまり、スタートアップにおいて、PMFが検証される前のフェーズはすべてビジネスプランの模索を行うフェーズであると言うことができます。PMFが検証され、資金を投下することで成長できることが明確になって初めて、ビジネスの拡大やオペレーションの最適化を行うのです。PSFとPMFを行う初期フェーズをさらに細かく分割すると以下のようになります。
課題と顧客を正しく捉えられているか？（Customer Problem Fit）
課題に対する解決策は適切か？（Problem Solution Fit）
解決策を提供するプロダクトにビジネス的価値はあるか？（Product Market Fit）
これらのそれぞ れのフェーズにて、「検証と改善」を繰り返すのがスタートアップの初期フェーズです。言い換えると、小さなピボット（軌道修正）を行いながら、うまくいくプランを見つけることがこのフェーズでの一番の目的です。初めに決めたプランでやり切ることが目的ではない点に注意が必要です。興味深い事実として、成功しているスタートアップの2/3は、創業当初のプランを途中で大幅に変更しているのです。つまり、この初期フェーズにおける検証の繰り返しで、うまくいくプランを見つけることができるかどうかがその後の成功に繋がると言っても過言ではないことがわかります。
PSFしている状態とはどのような状態？
PSFとは、あくまで課題と解決策が検証された状態であるため、まだ手元に実際のプロダクトなどは存在しません。そのため、PSFの達成は、月間アクティブユーザー数などの目に見える数値として実感できるものではないのです。では、PSFを達成している状態とはどのような状態になるのでしょうか？
後に詳しく紹介しますが、PSFの検証は主に顧客となりそうな人たちに直接話を聞くことで行います。PSFがうまくいくと、このように話を聞いた潜在顧客から、「それはいつから使えるの？」「実際にリリースしたらすぐに教えてほしい」というような反応が返ってくる ようになります。このような状態は、潜在顧客が今すぐにでも解決したいほどの問題を抱えており、解決策があれば今すぐにでも利用したいと考えていることを表すため、PSFを達成した際に実感する一つの反応として挙げられます。逆に、このような反応が返ってこないのであれば、インタビューにて好意的な反応があったとしても、実際にサービスを利用してくれるほどの大きなニーズではないのかもしれません。顧客に「喉から手が出るほど欲しい」と感じさせるものを見つけることが大切です。
PSFの検証・分析手法を４つ紹介
では、実際にPSFを検証する際の手法にはどのようなものがあるのでしょうか？ここでは、前述の「Running Lean 実践スタートアップ」の中で、アッシュ・マウリャ氏が推奨するインタビュー手法を初め、デザイン思考的なプロトタイピングや、Googleも導入するFake Door Testを紹介します。
課題インタビュー: 課題と顧客を正しく捉えられているか？」
「Running Lean 実践スタートアップ」の中で、アッシュ・マウリャ氏はスタートアップの初期仮説検証にはインタビューが最も適していると述べています。なぜなら、アンケートなどの調査では選択肢をリストアップする必要があり、スタートアップが解決しようとしている課題のような「未だ表面化していない課題」を発見するには向いていないからです。インタビ ューの中でも「課題と顧客を正しく捉えられているか？」を検証するインタビューを「課題インタビュー」と呼びます。単純化すると、課題インタビューで検証するべき問いは一つ、「課題と顧客セグメントに関する仮説の検証」です。とはいえ、初めからあまりに直接的な質問をしてしまうと、インタビュー相手の回答を誘導してしまいかねません。インタビューの質問は、少しずつスコープを絞りながら行なっていくと良いでしょう。
たとえば、「ITエンジニアたちは、スキルアップのために就労時間外の多くの時間を技術関連の勉強に割く必要があることに悩んでいる」という仮説を検証するためには、まず初めに対象となるであろうITエンジニアを招き「自身の仕事に関して大きな悩みを3つ挙げて下さい」という質問をします。この質問に対して、自身の仮説を実証するような回答が得られない場合には、「自身のワークライフバランスに関して悩みはありますか？」などと質問のスコープを狭めていきましょう。こうすることで、質問相手を誘導することなく、実際に相手が課題と感じているもののみ引き出すことができます。また、このように幅広く課題を聞いておくことは、初期化説が正しくなかった場合に別の課題へと軌道修正する際にも大変役立ちます。
また、インタビュー対象となる「顧客セグメント」に関してもいくつかの仮説グループに分けて、最もその課題を抱えている割合の大きいセグメントを特定できるようにします。例えば、上記の例であれば「ITエンジニア」というセグメントをさ らに分割し、「モバイルアプリエンジニア」「サーバーサイドエンジニア」「フロントエンドエンジニア」などのカテゴリーに分けて回答を分析します。すると、フレームワークや技術の更新頻度が高く、常に新しい情報にキャッチアップする必要があるフロントエンドエンジニアの方が、成熟したプログラミング言語を利用するサーバーサイドエンジニアよりも多くの時間を最新情報の勉強に割いていることなどがわかるかもしれません。
プロトタイピングによる低コストでの検証（ソリューションインタビュー）
顧客と課題が特定できたら、次は「解決策（ソリューション）」の検証です。これには、プロトタイプやデモを利用したインタビューが効果的です。目の前に具体的なものがない状況で、「こんなものがったらどう思いますか？」と言われても大抵の人はイメージが湧かないでしょう。そこで、解決策のイメージが伝わる「 最低限の何か」を準備して、顧客に意見をもらうのがソリューションインタビューです。
この「最低限の何か」は、紙に書いた図でも十分かもしれません、もしくはデザインモックアップや動画などでも良いです。とにかく、時間をかけすぎないことと、最終的な製品のイメージが湧くことのバランスを取りながらプロトタイプの手段を決めましょう。また、もう一つプロトタイプの手段を決める際に重要な点は、「更新しやすいかどうか」という点です。PSF検証のフェーズでは、ソリューションインタビューの結果に合わせて何度もこのプロトタイプを修正して、顧客にとって最適な課題解決となるように調整していく必要があります。そのため、簡単に内容を修正できる方法であることもプロトタイプにとって重要な要件となります。
プロトタイプの準備ができたら、課題インタビューにて特定した顧客セグメント（実際にその課題を持っている人たち）に対して、その解決策で課題を解決できそうか聞きに行きましょう。この段階ではあくまでプロダクト自体の検証ではなく、「解決策の検証」であることを念頭に、細かい機能までは気にせず、「問題解決の方法として最も優れた手段を見つけること」に集中します。また、この段階で顧客がソリューションに興味を持ってくれた場合、「いくらなら払うか」という点についても聞いてみましょう。具体的な価格に関しては、PMFのフェーズで調整していくことにはなりますが、大まかな収益性の検討をつけてビジネスの実現可能 性の評価を行うことができるようになります。
顧客インタビューから学習した内容をアンケートで検証
顧客インタビューにて、「課題」「顧客セグメント」「解決策」が明確になったら、その情報の統計的有意性を把握しておくと良いでしょう。一般的に、同じセグメントの5 ~ 6人にインタビューを行うとある程度の傾向は見えると言われておりますが、可能であれば「この段階で明確になった情報が、顧客セグメント全体にも当てはまるかどうか？」を検証しておきたいところです。これには、対象を絞ったアンケートを使ってみても良いでしょう。インタビューの結果分かった課題や解決策の有効性について、同じセグメントに属する多くの人に「はい・いいえ」で答えてもらえば、その情報が統計的にも有意義なものかどうか検証できるでしょう。
Fake Door Test（フェイクドアテスト）
もう一つ、PSFのための面白い手法があります。それが、Fake door test（偽物のドアによる実験）です。フェイクドアテストとは、実際には存在しない機能へのリンクやボタンを準備しておき、クリック率を計測することで、どれくらいのユーザーがその機能を欲しているかを調べるという手法です。フェイクドアテストはPMFのフェーズでも使える手法ですが、PSFフェーズにおけるフェイクドアテストでは、機能を提供するボタンやリンクというよりは、サービス自体のランディングページを作って検証するという方法が一般的です。具体的には、プロトタイプで作ったようなプロダクトの提供価値や機能を伝えるランディングページを作り、どれくらいの人が登録してくれるかを計測するなどです。ここでは、完全にフェイクのページにしてしまうというよりは、Beta版の先行登録ページとして作成し、実際にプロダクトをリリースした際にはここで登録したユーザーに使ってもらえるような工夫をすると良いでしょう。このようなBeta版への登録を行うユーザーは「アーリーアダプター」的な特性を持っていることが多く、初期のプロダクト改善に大変有意義なフェードバックをもらえることが期待できます。
新規ドメインでランディングを作ると、簡単には検索結果ページに出てこないという問題があります。このような場合はGoogleの検索結果に表示されるリスティング広告を利用するなどして、ある程度ページへのトラフィックが確保できるように工夫しましょう。Beta版の先行登録ページとして作る場合には、BetaListなどのベータ登録ページのキュレーションサイトにサイトを投稿するのも一つの手です。
PSFを達成したらPMFの検証に移行
PSFを達成し、見つけた課題に対して、顧客から「喉から手が出るほど欲しい」と言われるような解決策を見つけることが出来たら次は、PMF検証のフェーズとなります。実際にその解決策を提供できる最低限の機能を持ったプロダクトであるMVP（ミニマム・バイアブル・プロダクト）を作り、実際に利用してくれるユーザー（特にアーリーアダプター）からのフィードバックや分析指標をもとに、プロダクトとしての状態で市場ニーズのあるものを完成させるために実験と改善のループを繰り返すこととなります。PMFについては別の 記事で詳しく解説しているので、ぜひ参考にしてみて下さい。
まとめ
今回は、スタートアップの最も初期のフェーズでありながら、その後の成長可能性に大きく影響するコンセプトであるPSFについて、その重要性や実際の検証手法について紹介しました。これらの検証フェーズでは、何度も繰り返しながら時にはピボットを行い、最良のビジネスプランを見つけることが目的となります。新たにスタートアップ企業に参加するときに、その企業が今どのフェーズにいるのかの指標としても役立つコンセプトですので、ぜひ参考にしてみて下さい。
