このページでは、我々が取り組む課題の領域を定義します。最終的につくられるプロダクトがどんな課題を解決するのか、その課題は本当に市場に明確に存在し、痛みを伴うものなのか。Problem Discoveryとは、課題を発見し、検証するフェーズです。
- 課題の発見と仮説の立案
- ペルソナの定義
- 課題仮説の検証
課題の仮説
ソフトウェアサービスを提供する開発チームの多くが、次の課題を抱えていると仮説を立てた。
開発チームの多くが、ユーザーのニーズや声をプロダクトに反映できておらず、お金が払われる、払われ続けるプロダクトに成長することができず、困っている。
開発チームとユーザーの繋がりや関係性、エンゲージメントが薄く、対話と分析が不足している。
この課題は、開発チームに次の問題を引き起こしている。
- どの機能を実装するべきかを判断することができない
- 実装した機能がどのように使われているかを知ることができず、機能の改善案を考えることができない
- ユーザーが喜んで課金し、価格よりも価値を感じるプロダクトになれず、PMFを達成できない
この課題を、以降の取り組みでの最上位の課題としていく。この課題の範囲を超えたものは、解決策やプロダクトに含まれることはない。 課題の仮説はここでは深堀りせず、Problem-Solution Fitのフェーズで深堀りしていく。
課題発見の過程
1. 大まかな市場性・課題の調査
はじめに、知人・友人の開発者に対し、どんな課題を抱えているかについて、市場性と課題のインタビューを行った。次の質問を行い、どんなことに普段困っているかを聞いた。
- 開発チームの仕事に満足しているか？
- 開発チームでの仕事で、直近で強くストレスに感じた出来事を教えてくれますか？
3名に確認し、どの方も仕事自体に満足していると回答した。 ストレスに感じた出来事についても回答を得たが、一貫性や共通点はなかった。この聞き方では、回答が発散してしまい、課題の分析につなげるのは難しいと感じた。
2. 自身の経験から課題の手がかりを考える
自分自身に対しても上記の質問を問いかけ、自己分析をしてみた。結果は次のとおり。
- チームでの仕事に満足していない
- 自分が真剣に取り組み、時間と労力をかけて生み出した製品が全く使われないことにストレスを感じた（このとき、私は製品に対する大きな方針を決定できる立場ではなかった。エンジニアとして、自分ができる最大限のことをやっていたということ。）
原因を分析し、次の事項によって「時間と労力をかけて生み出した製品が全く使われない」状態になったと考えた。
- 構想初期や開発途中で、ユーザーに市場性の確認を徹底していない
3. 市場性・課題の再調査
特に日本において、ユーザーと会話する文化はあまり馴染みがない。ほとんどの開発チームは、ユーザーと深く会話していないのではないか？と、ここで考え始めた。 これを検証するため、市場性と課題のインタビューの設問内容を次に変更し、再度確認を行った。
- 最近、開発チームで「手間がかかる」「面倒だな」と感じた作業やプロセスはありますか？
- 「本当にユーザーが求めているものを作れているか」という点について、あなたの感覚に近いものを選んでください。
- プロダクトの方向性や意思決定について、チームで感じていることがあれば教えてください。
2名に確認し、次の情報を得ることができた。
- スタートアップに所属する方は、ユーザーが求めるものを作れていることに自信を感じていると答えた。大企業に所属する方は、合っていると思うが確証はないと答えた。
- スタートアップに所属する方であっても、機能が実際にどう使われているのかまでは把握しきれていない
- 2人とも「作る機能が明確に決まっており、迷うことがあまりない」と答えなかった
この結果と自身の過去の経験から、開発チームとユーザーの間に何らかの課題があると考え、この課題を分析することにした。
4. ターゲットユーザーに到達することが難しい
課題分析をするため、先の2名以外の他の開発者からインタビューを伺うことにした。特に、友人・知人にいないスタートアップ・ベンチャー企業に所属する開発者にコンタクトをとろう考えた。
しかし、次の施策を試したが、ターゲットの開発者とつながることが全くできなかった。
- XやLinkedinのソーシャルアカウントに対し、DMでFormの回答依頼を行う
- ほとんどの人がDM機能を無効にしている
- 直近に資金調達を行ったスタートアップ企業に、コーポレートサイトの問い合わせ経由でFormの回答依頼を行う
- 問い合わせページの本来の使い方ではない。倫理的にアウトか、目的外利用禁止の文言がある。
- スタートアップが好きそうなテックイベントに参加し、懇親会で知り合いになり、インタビューを行う
- 自然な参加をすると、普通は連絡先交換まで至らない。 2-3回の参加が必要になる場合もある。コアユーザーになる確度が低く、時間のコストと見合っていない。
ここで、次の情報を得ることができた。
- ユーザーとつながることに時間と労力がかかりすぎる
5. 開発チームとユーザーのつながりが薄い
ターゲットユーザーに到達する他の施策として、次があると考えた。
- QiitaとZennに投稿を行い、開発チームとユーザーの間に課題を感じる人とつながる。投稿の内容に、Slackコミュニティへの案内を記載し、密につながる環境をつくる。
- ターゲットユーザーが集まりそうなイベントを主催する。集まったユーザーにコンタクトをとり、コミュニティメンバーに誘い込む。
Slackコミュニティづくりを試していると、次に気づくことができた。
- 呼び込むまでは可能かもしれないが、持続的に密で熱意のあるつながりを維持するには、多くの工夫が必要
- 協力してくれる人に「自分事感」を与え、ともに製品をつくるように感じさせる運用が必要
- 協力してくれる人にインセンティブを与える仕組みが必要
- Slackを普段使わない人であれば、LINEで別途通知するなどの工夫が必要
- みんなが活発に意見を出せるように、場を回すような運用が必要
- 参加者が増えても、誰でも気軽に発言できるように、心理的安全性の確保が必要
ユーザーとつながることに時間と労力がかかるが、つながったあとも大変な労力がかかることを理解し始めた。開発チームがユーザーに便利でクールな製品を生み出すには、ユーザーの声が必須である。しかし、ユーザーとつながることも、その後のつながりを維持することも実際はとても大変である。
また、開発チームが持続的に、ユーザーに便利でクールな製品を届けるためには、次の開発アプローチが必要ではないかと気づいた。
- 開発チームとユーザーがひとつのチームとなる、Community-drivenな共創型のプロダクト開発
オープンソースプロジェクトのように、ユーザーがissueを起票したり、活発に意見したり、と開発チームとユーザーが密にコラボレーションすることが、便利でクールな製品を生み出す解決策になるのではないかと気づいた。これを課題の仮説に立て、検証していくことを決めた。
ペルソナの定義
我々は、初期のターゲットユーザーとして次のペルソナに決定した。
WebベースのSaaSを提供し、MVP開発中〜PMF達成のフェーズにいるスタートアップ企業の開発チームに所属する、チームの決裁権を持つCEOやCTO、Tech-Lead Manager、Tech-Lead、Managerの人物でかつ、開発チームとユーザーの繋がりや関係性、エンゲージメントに課題を感じている方をターゲットにする。
ペルソナの詳細
企業種別
WebベースのSaaSを提供している企業。企業のうち、どちらかというとスタートアップ・ベンチャー企業を優先するが、大企業も含めていく。
自分たちが今持つ知識を活用できるよう、WebベースのSaaSを提供する企業とした。 導入や意思決定にスピード感のある、スタートアップやベンチャー企業に所属する開発チームを基本的なターゲットにしている。
業種
toCを優先し、toBは優先度しない。
toCのほうがユーザーとの関係を構築することが難しく、課題に感じやすいためこのようにした。
開発チームのフェーズ
MVP開発中〜PMF達成のフェーズにいる開発チームをターゲットにする。
このフェーズの開発チームが、ユーザーとの繋がりや関係性、エンゲージメントを最も必要とするからである。
特にアプローチする人物像
チームへの製品導入を決定できる、重要な役割を担う次の人物をターゲットとする。
- CEOやCTO
- 開発チームのTech-Lead Manager, Tech-Lead, Manager
課題に対する温度感
ユーザーとの繋がりや関係性、エンゲージメントについて、中〜大の課題感を感じている方をターゲットにする。
課題仮説の検証
課題仮説が、市場で “明確に存在し”、かつ “痛みを伴っている” 課題であると確信できるかを調査する。次の3点が明らかになっていることが、そのサインである。
- “具体的なエピソード” と “感情の痛み” を複数のユーザーから引き出せている
- その課題に対して “既に行動している” か、あるいは “行動したがうまくいっていない” 証拠がある
- 課題が “意思決定や行動” に影響していることがわかる
次のチェックリストで7点以上と判断できるなら、Problem-Solution Fitへ進む。
| 検証項目 | 基準 | スコア |
|---|---|---|
| 感情的痛み | 明確なエピソード＋言語化された感情あり | 3 |
| 行動実績 | 明確な打ち手を既に実行 or 試行した証拠あり | 3 |
| 意思決定への影響 | 経営/プロダクト/実装方針に1つ以上影響 | 3 |
| 合計点 | 9点満点中7点以上なら真の課題 | – |
3観点の補足
1. “具体的なエピソード"と"感情の痛み"を複数のユーザーから引き出せている
- ただ「困ってる」と言うのではなく、実際に“失敗した” or “損失を出した”エピソードが語られているか？
- それが個別の現象ではなく複数人に共通しているか？
- そのときの**感情（イライラ、もやもや、悲しみ、恐怖など）**を覚えていたか？
例：「ユーザーの声を聞かずに機能を出したら、リテンションが一気に落ちた。営業からも怒られて、チームの士気が下がった。」
2. その課題に対して"既に行動している"か、あるいは"行動したがうまくいっていない"証拠がある
- ユーザーが自分なりに工夫や回避策をとっているか？（Slackでユーザーグループを作っている、Notionでログをとっている、など）
- その解決手段に満足していない、あるいは「うまくいっていない」ことを認めているか？
例：「Notionでユーザーの声を記録してたけど、全然見返さなくて形骸化してるんです…」
3. 課題が"意思決定や行動"に影響していることがわかる
- その課題がチームの方向性のブレや開発ミス、優先度判断ミスなどに繋がっているか？
- 「この問題があるから、○○ができない」と言っているか？
例：「ユーザーの本音がわからなくて、どの機能を次に作るか決められず、結局上司の一声で決めるようになっている」
課題検証のプロセス
次のステップで多くのユーザーと会話し、課題を検証することにした。
- ペルソナに該当する、課題に共感するユーザーとの接点を獲得する
- ユーザーと対話を行い、3観点の確認を行う
30名との対話を目標とした。接点獲得には、課題のストーリーに対する共感から接点を得る投稿型のアプローチを採用している。
戦略の詳細
1. ペルソナに該当する、課題に共感するユーザーとの接点を獲得する
Zenn, noteのプラットフォームで、課題に対して激しく共感できるストーリーを投稿する。投稿に書かれた連絡先やコメントから、ペルソナに該当するユーザーとの接点を獲得する。SuperhumanのRahul Vohraさんの投稿などを参考にする。
2. ユーザーと対話を行い、3観点の確認を行う
はじめに、ペルソナに該当するユーザーであるかどうかを確かめる。
- 現在開発されているプロダクトについて教えてください
- 現在の開発フェーズは何でしょうか？正式リリースされていますか？
- 企業種別と開発チームでの役割を教えていただけますか？
ペルソナに該当する方と分かれば、インタビューのアポイントメントを取る。その際、インタビューの背景と目的、主な聞きたいことを伝える。
私は今、プロダクトをつくる多くの開発チームが 「ユーザーとの繋がりの薄さ」に、課題を感じていると予想しています。 「開発チームとユーザーの距離感が遠い」ことで、開発チームに次のような問題を起こしていると考えました。
- ユーザーに対し、どんな機能を実装すればよいかが分からない
- PMFを達成するプロダクトに成長できない
もし、この課題を解決できる製品があれば、〇〇さんのプロダクトを大きく成長できるきっかけをつくれると確信しています！ ぜひ30分ほどお話させていただき、次のことをお聞きしたいです。
- ユーザーとのフィードバックループを構築していますか？ユーザーの意見をどのようにプロダクトに反映しているかをお聞きしたい。
- 現状のフィードバックループの仕組みに不満を感じませんか？仕組みを変えようとしたことはありますか？
- ユーザーの声や意見が、あなたの会社やチームに どれほど影響を与えていますか？ それぞれ、大中小でお答えください。
- 会社の全体目標、経営戦略や経営計画 → CEOやCTOの経営層レベル
- プロダクトの方針やロードマップ、開発計画 → TLMやTL, Managerのリーダーレベル
- UIやUX、デザイン、詳細の実装方針 → エンジニアやデザイナーなどのチームメンバーレベル
上記のストーリーに沿って対話を進め、課題検証のゴールである次についてをユーザーから聞き出す。
- “課題が原因で発生する問題の具体的なエピソード” と “そのときの感情の痛み”'
- その課題に対して “すでに行動している” か、あるいは “行動したがうまくいっていない” 証拠があること
- 課題が “意思決定や行動” にどれほど影響しているかがわかる
これにより、「開発チームとユーザーとの繋がりが薄い」 という課題が、次の内容であるかを確認することができる。
- 市場に明確に存在し、ユーザーにとって大きな痛みを伴うものであるかが分かる
- 既存の解決手段では課題の解決が難しい、または満足できないものであるかが分かる
- 課題が、経営層レベル、リーダーレベル、チームメンバーレベルに、どれほど影響を与えているかが分かる
上記3つの確認ができることで、はじめて取り組むべき課題かどうかを判断することができる。
検証結果
結果は6.5点だった。感情的痛みが1.5、行動実績が3、意思決定への影響が2である。
この課題は重要視されていない、開発チームにとって痛みを伴う自覚のないものと分析した。対話と自身の経験から、開発チームとプロダクトに大きな影響を与えているものだと確信した。この課題は"困っているが、困っていない"と答える課題である。
この課題でProblem-Solution Fitのフェーズに進むと決めた。 “課題に気づく"モックを作成し、課題を再検証を行う。そこで、この課題が本当にユーザーにとって課題でないかを確認し、取り組むかどうかを決定する。
検証過程
1. ペルソナに該当する、課題に共感するユーザーと接点を獲得する
課題について共感できる内容を書いた記事をZennとnoteに投稿し、投稿型検証を行った。 結果は次のとおり、惨敗だった。
- 全く読まれない。ペルソナユーザーが読む機会がない。
- 一日あたり2いいね、コメント0だった
投稿内容がそこまでひどいとは考えておらず、ChatGPTや友人に率直なレビューを依頼していたこともあり、それなりのクオリティはおそらくある。 Zennは他の人の投稿頻度がかなり多く、投稿から2時間ほどで完全に埋もれてしまい、記事を見つけることがほぼ不可能になってしまった。
また、コメントについても強くお願いし、具体的にどうコメントしてほしいかまで依頼したが、残念ながらコメント0だった。Zennではコメントをする文化がなく、他の記事もほぼコメント0である。「見て終わり」のプラットフォームであり、課題仮説の検証に不向きだと思われる。
次のアクションとして、Mediumに英語翻訳版の投稿やIndie HackersやProductHuntのForum、Redditでのスレッド投稿を考えた。次の事項を懸念し、課題の重要性に気づくことができるMVPをつくり、それを見せながら課題仮説を検証するアプローチを採用することにした。
- 英語ユーザーが多く、最終的な深いインタビューで言語の壁ができてしまう。深く聞けるかの自信がなかった。
- スレッドでの会話で、相手の連絡先をもらい、インタビューを依頼するまで導くことがかなり難しく、戦略を立てられなかった
- ProducHuntや#Buildinpublic, Indie Hackers, Zenn, 友人・知人でプロダクト開発事例をみると、Build Firstでプロダクトを作っている方が多く、課題の重要性を軽視しているように感じた
2. ユーザーと対話を行い、課題検証ゴールの確認を行う
前のとおり、多くの方への確認はできなかったが、友人・知人のペルソナに近い人物3名から話を聞くことができた。 次に大まかな対話内容を示す。詳細までは記載しない。
課題が原因で発生する問題の具体的なエピソードとそのときの感情の痛み
- Aさんは、課題感をあまり感じていなかった
- Bさんは、具体的エピソードと強い感情の痛みがあった
- Cさんは、課題感を感じていなかった
気になる点や分かったこと
- PMF前のプロダクトを開発しているチームは比較的課題に共感でき、PMF後のプロダクトを開発しているチームは課題にあまり共感しない
- 3名とも課題に対し、直接強い課題感を感じる人はいない。困っているといえば困っているが、うーんという感じ。
- 2名はBuild Firstの哲学で、1名はLean Startupの哲学で動いている
- 3名とも、その機能をユーザーが望んでいることに確信や自信はあるか？と聞くと、それが分からないからリリースして確かめると回答した
その課題に対して既に行動しているか、あるいは行動したがうまくいっていない証拠があること
- 3名とも行動している。3名とも、現状うまくいっていると回答した。
気になる点
- うまくいっていると回答するが、「分からないからリリースして確かめる」とも言う
課題が、意思決定や行動にどれほど影響しているかがわかる
3名とも、チームリーダーレベルとエンジニアレベルだった。 経営層レベルも少なからず影響はしている模様。