← エピソード一覧に戻る Episode 133 Chapter 1
Chapter 2
Chapter 3
Chapter 4
Chapter 5
0:00 / 0:00
スクリプト
Chapter 1 オープニング ― 作る前に疑うべきもの
タカシ
皆さんこんにちは、タカシです。今日は SaaS 立ち上げでかなり重要なのに、つい機能開発の陰に隠れがちなテーマ、課題仮説を扱います。実は多くの失敗は、作る力より先に、解く問題の見立てで起きるんです。
ミカ
ミカです。課題仮説って、なんとなく難しそうな言葉ですね。でも言われてみると、創業者ってつい『何を作るか』から考えがちです。『何に困っているのか』を後回しにすると、そんなに危ないんでしょうか。
タカシ
かなり危ないです。課題仮説は、誰が、どんな場面で、どれくらい痛みを感じ、今は何でしのいでいるかを言語化した仮説です。言い換えると、プロダクトの前に置く『痛みの設計図』ですね。ここが曖昧だと、機能は増えても刺さらない。
ミカ
なるほど。つまり『便利そうだから作る』ではなくて、『この人たちは、この業務のここで、本当に困っている』まで絞る必要があるんですね。ふわっとした共感レベルでは、まだ仮説として弱い、ということか。
タカシ
その通りです。今日は、良い課題仮説に何が必要か、Vanta や Rupa Health がどう見つけたか、そして経営者がどこで見誤るかを順番に見ていきます。皆さんの事業でも、今の仮説は本当に痛みを捉えているか、考えながら聞いてみてください。
Chapter 2 基本 ― 課題仮説は「痛みの設計図」
タカシ
Steve Blank は、スタートアップではまず創業者の顧客課題仮説を検証し、その後で最小の解決策が効くかを見るべきだと整理しています。順番が大事なんですね。最初にやるのは機能集めではなく、本当にその問題が存在するかの確認です。
ミカ
でも顧客に話を聞くと、要望ってたくさん出てきますよね。あれも欲しい、これも欲しい、と言われると、つい『ニーズがあるんだ』と思ってしまいそうです。課題仮説って、要望のリストとは何が違うんですか。
タカシ
大きな違いは、優先順位と行動です。良い課題仮説には、誰が困るのか、どの仕事の流れで詰まるのか、現状の代替手段は何か、その問題はどれだけ頻繁で、時間損失か売上損失かリスクか、そこまで入ります。単なる不満と、今すぐ解きたい痛みは別物です。
ミカ
たしかに『困ってます』だけだと弱いですね。毎月一回しか起きない面倒ごとと、毎日チーム全員が時間を失う問題では、同じ困りごとでも重さが違います。しかも、今は何でしのいでいるかまで見ないと、乗り換え理由もわからないですね。
タカシ
その視点が重要です。Y Combinator の Michael Seibel も、スタートアップは仮説を立て、テストし、学び、更新する科学的な姿勢で進めるべきだと述べています。つまり課題仮説は、思い込みではなく、会話と観察で壊しにいく前提の仮説なんです。
Chapter 3 事例 ― Vanta と Rupa が見つけた本当の課題
タカシ
まず Vanta です。Christina Cacioppo は最初から SOC 2 自動化にたどり着いたわけではありません。いくつかの案が響かなかった後で、一度『何も作らずに人と話す』と決め、顧客候補の仕事ぶりを徹底して聞き始めました。
ミカ
何も作らない、は勇気がいりますね。創業者って、手を動かしていないと不安になりそうです。でも、そこを止めて観察に振ったからこそ、表面の要望じゃなくて、本当に詰まっている仕事が見えてきたんでしょうね。
タカシ
そうです。彼女は相手にカレンダーを開いてもらい、直近の仕事で何が重かったかを聞きました。そこで繰り返し出てきたのが、SOC 2 を取りたいのに、準備作業が重すぎて後回しになる、という痛みです。解きたいのは認証そのものより、準備の泥臭さだったんですね。
ミカ
なるほど。『セキュリティは大事です』みたいな抽象論ではなくて、『忙しいスタートアップ経営陣が、認証準備の手作業で前に進めない』まで落ちたから、課題仮説が sharp になったわけですね。これはかなり実務的です。
タカシ
しかも最初の形はスプレッドシートでした。それでも進んだのは、解決策の完成度より、課題仮説の強さが勝っていたからです。2019 年初頭には、ほぼ案内のないサイトでも口コミだけで週に 2〜3 件の問い合わせが来たそうで、市場の痛みが自然に引っ張っていたとわかります。
Chapter 4 深掘り ― 反応の良さより、優先順位を見る
タカシ
もう一つの例が Rupa Health です。最初は統合医療のマーケットプレイスを 1 年ほど試しましたが、 traction は伸びませんでした。そこで自分たちでバーチャルクリニックを運営してみたところ、検査手配が現場の最大ボトルネックだと見えてきたんです。
ミカ
面白いですね。頭で考えた市場機会ではなくて、自分たちが業務を回して初めて、どこで時間が溶けるかが見えたわけですね。しかも『少し困る』じゃなくて、仕事が止まるレベルの詰まりだから、優先順位が上がる。
タカシ
そこで彼女たちは完成形を売り込まず、『ラボ検査の発注や説明の面倒をまとめて処理できたら価値がありますか』と、まず問題をぶつけました。すると、それまでの案では見られなかった強い反応が返ってきた。課題仮説が当たると、会話の熱量が変わるんです。
ミカ
ここで大事なのは、反応がいい理由ですよね。機能が派手だったからではなく、自分たちの頭痛の種を正確に言い当てられたから、相手が前のめりになった。課題仮説って、営業メッセージや価格設計の土台にもなりそうです。
タカシ
まさにそうです。SaaStr では、課題が『売上を増やす』『コストを下げる』『リスクを減らす』のどれに効くかまで掘れ、と整理しています。ここまで落ちないと、顧客は共感しても優先しません。うなずきより、予算や稟議が動く理由を探すべきなんですね。
Chapter 5 クロージング ― 明日からの検証手順
タカシ
よくある失敗も整理しておきましょう。一つ目は、AI や自動化みたいな解決策から逆算すること。二つ目は、顧客の共感を緊急度と勘違いすること。三つ目は、一社の大きな声を市場全体の課題だと思い込むことです。
ミカ
刺さりますね。『それ、あるあるです』と言われると前進した気になりますけど、実際には紹介も試用も支払いも起きないこと、ありますよね。反応の良さと、行動が変わるほどの痛みは別だと覚えておいた方がよさそうです。
タカシ
明日からの実務では、まず課題仮説を一文で書いてみてください。誰が、どの業務で、何に困り、今は何でしのぎ、何が起きると導入を急ぐのか。面談では『見せてください』『直近二週間で一番面倒だったのは何ですか』と、観察ベースで聞くのが有効です。
ミカ
そして、判断材料は感想より buy sign ですね。紹介してくれるか、試してくれるか、払う意思があるか、社内の決裁者につないでくれるか。そこまで動かないなら、機能を足す前に仮説自体を疑った方がいい、と。
タカシ
今日は SaaS 立ち上げの課題仮説を見てきました。作る前に、まず疑う。これが遠回りに見えて最短です。皆さんの今のアイデアも、『その問題は本当に今日困っているのか』という視点で、ぜひ一度点検してみてください。それではまた次回。