このページでは、我々が取り組む課題の解決策を定義します。課題の原因とはなにか、プロダクトにはどんな成果が必要か、課題に対する解決策とは何か、MVPで何から取り組むか。Problem-Solution Fitとは、課題の原因を分析し、解決策を定義するフェーズです。
- 課題の明確化
- 課題の構造分析 / 原因分析
- 成果の定義
- 解決策の条件定義
- 解決策案
- MVP設計
- 課題と解決策の検証
課題の明確化
Problem Discoveryより、解決すべき課題は次と定義している。
開発チームの多くが、ユーザーのニーズや声をプロダクトに反映できておらず、お金が払われる、払われ続けるプロダクトに成長することができず、困っている。
開発チームとユーザーの繋がりや関係性が薄く、エンゲージメントが低い。ユーザーとの対話と分析が不足している。
課題の構造分析 / 原因分析
課題について、5-Why分析を行い、課題の構造と原因を明らかにする。次の課題に対し、なぜそれが起きているかを再帰的に言語化する。
開発チームの多くが、ユーザーのニーズや声をプロダクトに反映できておらず、お金が払われる、払われ続けるプロダクトに成長することができず、困っている。
🤔 なぜ、開発チームのプロダクトの多くが、お金が払われる、払われ続けるプロダクトに成長することができないのか？
開発チームとユーザーの繋がりや関係性が薄く、エンゲージメントが低い。ユーザーについて得られる情報が乏しく、ユーザーのニーズや声をプロダクトに反映できていないから。
🤔 開発チームとユーザーとの関係性やエンゲージメントという観点において、なぜ、Problem Discovery, Problem-Solution fit~MVP検証, Solution-Product fit, Product-Market fit, SecondPMF以降がうまくいかないのか？
分析方法の詳細を次に示す。
5-Why分析方法の詳細
概要
課題に対し、なぜその課題が発生したのか、その原因とは何かを問い続け、5回繰り返すことで分析する手法である。 ここでは5回にこだわらず、課題が起きる原因が抽象的になるか、自分が対処可能な範囲を超え始めたら、深堀りを終了することにしている。
5-Why分析の流れ
「なぜ、開発チームとユーザーの繋がりや関係性が薄く、エンゲージメントが低いのか」をプロダクトをつくるための課題発見から解決策案の定義、開発、リリース、改善、グロースまで、各開発フェーズごとに分析を行う。
- Problem Discovery
- Problem-Solution fit ~ MVP
- Solution-Product fit
- Product-Market fit
- Second PMF以降
まずはある程度自身で課題を分析し、その後の解決策案と課題の検証にて、実際に市場で確認できた課題を色分けする。 市場で確認ができたと判断したソースを、その課題のリーフに記載する。
課題カテゴリの定義
課題カテゴリの定義
次の検討に活用するため、各課題をカテゴリで分けることにした。
- 解決策の成果定義、解決策の提案
- 最初期で取り組む課題、MVPでフォーカスする課題
- 解決すべき課題の重要度や優先順位の決定
心理的要因
感情・信頼・安心感・不安など、人の“気持ち”に起因する障壁。属人性が高く、再現性・定量化が難しい。 影響は非常に大きいが、言語化・認識されにくく、可視化されづらい。
初期フェーズでは「気まずさ・自信のなさ・恥ずかしさ」などがユーザー接点を妨げる。 だからこそ、心理的ハードルを下げる体験設計（ex. フォーム、Slack、アバター、非同期など）がSaaSの価値になりやすい。
MVPとの相性は中〜高である。
実務的要因
工数・時間・スキル・プロセス・情報量など、“作業としての困難さ”。 可視化しやすく、業務フローやUXの中で特定しやすい。 一見解決できそうに見えるが、持続可能性が問われる。
MVPで解決しやすく、「最初のソリューション」にしやすい。 ただし表層的な課題だけだと、解決しても“課題の熱量”が上がらないことも多い。
MVPとの相性は高である。
環境的要因
法制度、業界構造、商習慣、チーム構成、レガシーシステムなど「個人では変えにくい外部環境」。 再現性は高いが、変化に時間がかかる・影響が大きい。
「マーケットの構造課題」として、大きなビジネスチャンスの根になりうる。 一方で、短期でMVP→PMFには不向きなことも多い。
MVPとの相性は低〜中である。
ユーザーの行動心理
「気づかない」「探さない」「諦めた」「興味を持たない」などの“行動に移らない理由”。 潜在課題の温度を測る上で非常に重要。ユーザー自身も自覚していないことが多く、気づきを与える仕掛けが必要。
このカテゴリは、まさに「見えない市場」を掘り起こすためのキー。 「課題はあるけど探してない人」が多い市場ほど、強いプロダクトをつくるチャンスがある。
MVPとの相性は高である。
課題の分析結果
5-Why分析で発見した課題について、実際に市場で確認できたものを次に示す。
心理的要因
Problem-Solution fit~MVP検証, Solution-Product fit
- 多くのユーザーは、開発チームからのフィードバック依頼に無関心で、協力しようとしない
実務的要因
Problem Discovery
- アイデアの完成度やクオリティが低く、見ている人がフィードバックを送信する気にならない
Problem-Solution fit~MVP検証, Solution-Product fit
- 解決策案 / MVP / プロダクトに対し、ユーザーがフィードバックを送信しない
- ユーザーのフィードバックから、解決策案 / MVP / プロダクトを改善することができない
- フィードバックの送信者が人物像が分からないため、フィードバックをどれほど真に受けてよいのかが分からない
- 問題点ばかりを指摘し、どのように改善をすればよいのかの具体例を挙げてくれない
- フィードバックが表面的で具体性に欠けている
我々がこれから解決に取り組むことに決定した課題を次に示す。
- 多くのユーザーは、開発チームからのフィードバック依頼に無関心で、協力しようとしない
- ユーザーのフィードバックから、解決策案 / MVP / プロダクトを改善することができない
解決策が満たすべき成果の定義
5-Why分析、解決策案と課題の検証結果から、この課題の解決策は次の成果を満たす必要があると考えた。
フィードバックの収集数
無関心で非協力的なユーザーが、関心をもつ協力的なユーザーに変化し、フィードバックを送信するようになる
この解決策によって、無関心で非協力的であったユーザーが、関心をもつ協力的なユーザーに変化し、フィードバックを送信するようになる。 サンプルサイズの計算式に基づき、フィードバック対象のペルソナに該当するアクティブユーザーの内、次に示す人数からフィードバックを得られることを成果とする。
- 小規模なユーザー数（100人以下）: 90%以上の方から、フィードバックを収集できる
- 中規模なユーザー数（1000人以上）: 35%以上の方から、フィードバックを収集できる
- 大規模なユーザー数（1000人以上）: 350人以上の方から、フィードバックを収集できる
サンプルサイズ計算式の各パラメータは次のとおり。
- N = フィードバック対象のアクティブユーザー数
- Z = 95%の信頼水準
- P = ユーザーがフィードバックを提供する割合の推定。サンプル数が最も増える0.5を設定する。
- E = 5%の許容誤差
母集団とサンプルサイズの相関から、大まかに必要なユーザー数を算出している。必要に応じて、都度計算する。
フィードバックの質とユーザー理解度
ユーザーのフィードバックから、直接的にプロダクトを改善できるようになる
解決策が収集するフィードバックは、プロダクトの改善に直接つながる、質の高い深い情報をもつようになる。 開発チームが、改善計画の意思決定に自信と確信を持つようになり、次の設問にYesと答える開発チームが95%以上になることを成果とする。
得られたフィードバックに基づく改善計画を実行することで、より良いプロダクトになることに自信と確信がありますか？
開発チームが、ユーザーを深く理解することができるようになる
解決策がもたらすユーザーとの対話を通して、開発チームはユーザーを深く理解できるようになる。 次の設問に対し、Yesと答える開発チームが95%以上になることを成果とする。
プロダクトの各ユーザー層について、彼らが今プロダクトに対してどんな改善を求めているか、そのユーザーストーリーを明確に言語化できますか？このユーザーストーリーが本当に正しいかどうかについて、自信と確信はありますか？
「彼らは、この課題に困っているため、次の機能を強く求めている。それにより、次の事項を達成したい。」
解決策が満たすべき条件
市場分析に基づき、次の事項が解決策には必要である。
無関心期のユーザーを関心期に変化させる
行動変容ステージモデルに基づき、無関心期のユーザーを関心期に変化させる
開発チームにフィードバックを送信することに対して無関心なユーザーを、「フィードバックを送信するほうがいいな」と考えを変えるようになるプロダクト体験がある。始めの一歩には、協力・貢献した感覚が一切なく、戦略的に関心期に移る設計がされている。
行動の容易さ
ユーザーが実施する一つ一つの行動が容易である
“行動の難しさ"によって行動が中断したり、離脱することがない。ユーザーが実施する一つ一つの行動が容易になっているプロダクト体験がある。全体でみると難しい大きな貢献であっても、一つ一つのステップが明確で簡単にされており、少しずつ着実に進められる設計がされている。
自己利益に繋がる
開発チームへの協力がユーザーの自己利益に繋がる
ユーザーの送信したフィードバックが、開発チームの役に立っていることを明確に実感できるプロダクト体験がある。 開発チームからの感謝だけでなく、他のユーザー同士で共感しあえ、承認欲求を満たすことができる。
ただ単なるフィードバック送信アプリではなく、利用することで複数の自己利益に繋がるプロダクト体験がある。
内発的動機づけを根付かせる
ユーザーが自主的に利用し、フィードバックを送信する
ユーザーに内発的動機づけを根付かせ、プロダクトに対する感動と感謝を動機に、真摯なフィードバックを送信するようになる。感情に任せた文句や不満、クレームが動機ではなく、プロダクトと開発チームに対する感謝が動機でなければならない。
また、開発チームに協力したいという動機だけでなく、複数の内発的動機づけを根付かせるプロダクト体験がある。
解決策案とMVP設計
改めて課題は次のとおりである。
開発チームの多くが、ユーザーのニーズや声をプロダクトに反映できておらず、お金が払われる、払われ続けるプロダクトに成長することができず、困っている。
開発チームとユーザーの繋がりや関係性が薄く、エンゲージメントが低い。ユーザーとの対話と分析が不足している。
多くのユーザーは、開発チームからのフィードバック依頼に無関心で、協力しようとしない。 ユーザーのフィードバックから、解決策案 / MVP / プロダクトを改善することができない。
課題を解決する解決策を次と定義した。
開発チームとそのユーザーが、お互いを深く理解することができるプラットフォームが解決策となる。
開発チームに対して無関心なユーザーを、関心をもつ協力的な姿勢に変化させ、双方が対話できる土台をつくる。 お互いが理解し、両者が共創してプロダクトを成長させることができるようになる。
開発チームとユーザーの繋がりは深くなり、エンゲージメントも高くなる。開発チームはユーザーを深く理解し、喜んで課金される便利でクールなプロダクトに成長させることが、再現性がある形で可能になる。
MVPの目的と内容
ここでのMVPは、次に関する現状の問題点を気づかせ、理想的な開発アプローチを認識できる体験を提供しなければならない。
- 開発チームとユーザーの関係性の薄さ、エンゲージメントの低さ
- ユーザーからのフィードバック内容
我々のプロダクトを利用するBeforeの姿として、次の現状の代替策を採用する。Afterとなる新しい開発体験は、Beforeと比較して非常に優れていると認識でき、成果を達成できるものでなければならない。
- Redditでのフィードバック依頼
- XやBlueskyでのフィードバック依頼
- プロダクトに付随するフィードバック取得機能
課題と解決策の検証
課題が市場に本当に存在し、解決策が適しているかどうかを確かめるため、次の検証を行った。
- XとBlueskyのBuildInPublicコミュニティで、フィードバック協力相手の公募（自分が、相手のプロダクトやアイデアに対してフィードバックをする）とビジョンに関する投稿を行い、反応を分析する
- Redditのr/startupコミュニティでのWeekly Feedbackスレッドにて、理想的なフィードバックを実際に送信し、反応を聞く
- 行動変容ステージモデルに基づいて、実際に行動が変わった人物の具体例を分析する
各検証の結果は次のとおりである。我々が取り組む課題は市場に明確に存在しており、解決策は適していると判断した。
X/Blueskyでの投稿結果
BuildInPublicコミュニティで、フィードバック協力の公募とビジョンに関する投稿を行い、反応を分析する
こちらの投稿を行った。投稿開始から45分で、Xでは次のアナリティクスを得ることができた。
- インプレッション: 23
- エンゲージメント: 16
- 詳細のクリック数: 11
- ポジティブな返信: 1
インプレッション数こそ少ないものの、ニッチですぐにタイムラインが流れてしまうBuildInPublicコミュニティにおいて、エンゲージメントと詳細のクリック数が非常に高いことが分かる。 ペルソナに該当するユーザ層に届いている可能性が高く、投稿を見た人が強い関心を引いていることが分かる。
しかし、残念ながら実際にフィードバックの協力依頼が来ることはなかった。これを次のように分析した。
- 元々ユーザーでない方でかつ、信頼関係のない人物にわざわざフィードバックを依頼することはない
- BuildInPublicにいる人物の多くに、趣味や自己学習を目的にプロダクトをつくっている方々がいる。フィードバックを頼む強い理由がない。
Redditでのフィードバック検証結果
Redditのr/startupコミュニティでのWeekly Feedbackスレッドにて、理想的なフィードバックを実際に送信し、反応を聞く
Redditのr/startupコミュニティでは、プロダクトのFeedbackを送信し合うスレッドが存在する。 先のBuildInPublicとは異なり、比較的本気で売ろうとするプロダクトが集まる。ここでフィードバックを募集している方に対し、非常に協力的で真摯なフィードバックを送信し、解決策を検証した。
こちらのスレッドで、2件のフィードバックを送信した。フィードバックに対する反応を次に示す。
- 2件とも非常に好評で喜ばれた
- 彼らが求めるフィードバックの観点に対し、的確に返信し、具体的でかつポジティブな意見を送信した。改善の具体例も含めた。改善につなげることができると言ってくれた。
- 背景情報や自身の情報を含めている点が秀逸と答えてくれた。このフィードバックをどのように受け止めるべきかが明確になっていた。
自身の開発者としての経験も交え、課題は市場に明確に存在し、解決策は非常に喜ばれると判断した。
行動変容の分析結果
行動変容ステージモデルに基づいて、実際に行動が変わった人物の具体例を分析する
人間の行動変容には科学があり、有名なもので行動変容ステージモデルというものがある。人間の変化は、次のように段階的に進むという理論である。
- 無関心期（Precontemplation）
- 関心期（Contemplation）
- 準備期（Preparation）
- 実行期（Action）
- 維持期（Maintenance）
このモデルに基づいて、実際に行動が変化した具体例をいくつか見つけ出し、共通する本質を分析した。具体例のケースは次のとおりである。
- 自身のGoogle Map口コミを利用するようになった事例
- 友人がアイスの口コミを書くようになった事例
- Counter-Strikeコミュニティが自主的にフィードバックやディスカッションをする事例
- Steamのゲームレビューを自主的に送る事例
各事例を分析し、次の共通点があることを発見した。
- 無関心期から関心期に変わるポイントが必ず存在する
- 実際に行動するかは、その行動の容易さに影響を受ける
- 単純なボランティアではなく、自己利益に繋がることが長く続くコツである
- 内発的な動機は人の行動に大きな影響を与えている
解決策の条件定義に対し、非常に重要な情報を得ることができた。