← エピソード一覧に戻る Episode 145 Chapter 1
Chapter 2
Chapter 3
Chapter 4
Chapter 5
0:00 / 0:00
スクリプト
Chapter 1 オープニング ― 顧客は機能ではなく前進を買っている
タカシ
皆さんこんにちは、タカシです。今日は SaaS プロダクトの最初の土台として、ジョブ理論を扱います。実は顧客は機能一覧を買っているのではなく、今より前に進むための手段としてプロダクトを選んでいるんです。
ミカ
ミカです。ジョブ理論って、聞いたことはあるけど少し抽象的です。要するに『この人はどんな仕事を片づけたくて、その SaaS を雇ったのか』を見る考え方で、機能比較より先にそこを見る、という理解で合っていますか。
タカシ
はい、その理解でかなり近いです。役職や業種だけではなく、なぜ今日乗り換えたのか、何に不満があったのか、導入後にどんな成果を出したいのかを見る。そこを外すと、機能は増えるのに売れ方も定着率も鈍るんですね。
ミカ
たしかに SaaS って、便利そうな機能は多いのに、現場で定着しないことがありますよね。今日はそのズレがなぜ起きるのかと、経営者がどう見抜けばいいのかを経営目線で整理したいです。
Chapter 2 基本 ― ジョブ理論は乗り換えの文脈を読むフレーム
タカシ
Bob Moesta は、顧客は何かを買うことで progress、つまり前進を得ようとしていると説明します。SaaS でも同じで、顧客は機能そのものより、業務が速くなる、不安が減る、成果が出るといった進歩を買っています。
ミカ
すると『人事部長向け』『従業員三百人企業向け』みたいな属性の切り方だけでは足りないわけですね。同じ人事部長でも、採用を楽にしたい人と、稟議を通しやすくしたい人では、雇う理由も切り替える緊急度も違いそうです。
タカシ
その通りです。ジョブ理論が強いのは、競合の見え方まで変えることです。相手は同じカテゴリの SaaS だけではありません。Excel、メール、人手運用、外注、その全部が『今の代替手段』として比較対象になります。
ミカ
なるほど。『競合調査をしたのに勝ち筋が見えない』のは、比較表の相手が違うからかもしれませんね。本当は Excel と担当者の根性に勝たないといけない、みたいな話になってくる。そこを見落とすと全部ずれそうです。
タカシ
まさにそこです。だからインタビューでも『どんな機能がほしいですか』では弱い。直前まで何でしのいでいたのか、何が限界だったのか、なぜ今日サインアップしたのかを時系列で聞く必要があります。そこに job の輪郭が出ます。
Chapter 3 具体例 ― Intercom は十五人の顧客から四つの仕事を見つけた
タカシ
Intercom の事例は象徴的です。共同創業者の Des Traynor は、二〇一三年に十五人の顧客へインタビューした結果、Intercom は一つの製品でも、実際には四つの異なる仕事で使われていると分かったと語っています。
ミカ
四つですか。同じプロダクトでも、顧客の頭の中では別の用途になっていたんですね。開発側は一つの製品として見ていても、買い手の頭では別カテゴリみたいに扱われていた。どんな仕事として見つかったんですか。
タカシ
『ユーザーを理解したい』『ユーザーから話しかけてもらいたい』『素早く対応したい』『適切なタイミングで正しい行動を促したい』の四つです。Intercom はその学びを基に、サイトや価格の見せ方まで仕事別に整理し直しました。
ミカ
面白いですね。機能を増やしたより、『自分たちは何のために雇われているのか』を言い直したことで、売り方まで変わったわけだ。これはプロダクト戦略と営業、さらには価格の見せ方まで一本でつながっています。
タカシ
もう一つ、Bob Moesta は Basecamp の利用実態として『Help me think it through』という job を挙げています。利用者はタスク完了より、関係者を集めて考えを整理するために使っていた。ここを見誤ると、改善の方向がずれます。
Chapter 4 失敗パターン ― 要望収集だけではロードマップが壊れる
タカシ
よくある失敗の一つ目は、ペルソナで安心してしまうことです。属性を細かく切っても、乗り換えの引き金が分からなければ、優先順位は決まりません。誰かより、どんな状況で困っていて何を変えたいのかのほうが重要です。
ミカ
たしかに『三十代の部長』までは言えても、なぜ今お金を払うのかまでは別問題ですね。プロフィールは書けるけど、購買理由は書けない、みたいな状態は危なそうです。会社規模だけでは導入の引き金までは見えませんよね。
タカシ
二つ目は、顧客要望をそのまま job だと誤解することです。顧客は欲しい機能は言えても、背後の不安や制約までは言語化していないことが多い。だから feature request を並べても、芯のあるロードマップにはなりにくいんです。
ミカ
声の大きい顧客に引っぱられて、個別要望の寄せ集めになるわけですね。それだと短期売上には効いても、標準プロダクトとしての深さは育ちにくそうです。結果として導入後の説明も複雑になりそうです。
タカシ
三つ目は、アンケートだけで済ませることです。Bob Moesta も、最初の一歩はサーベイではなく『なぜ今日サインアップしたのか』を深掘る電話インタビューだと話しています。切り替えの瞬間には、数字だけでは取れない感情があるんですね。
Chapter 5 クロージング ― 仕事の言葉で語れると SaaS は強くなる
タカシ
実務では、直近で導入した顧客十人前後に、直前の代替手段、限界が来た瞬間、比較した選択肢、導入後に得たい成果を時系列で聞くところから始めるのが有効です。三十分でも四十五分でもいいので、時系列で深く掘ることが大事です。
ミカ
その上で、営業資料もトップページも『機能紹介』ではなく『どんな前進を助けるのか』の言葉に直すんですね。機能を売るより、仕事が進む未来を売るほうが SaaS らしいですし、オンボーディングの設計にもつながりそうです。
タカシ
はい。ジョブ理論は、プロダクト、価格、営業、オンボーディングを一本につなぐ土台です。皆さんの SaaS も『誰が何のために雇っているか』を一度言い直してみてください。それだけで次の打ち手がかなりクリアになります。
ミカ
今日はジョブ理論でした。次にプロダクトを見るときは、機能一覧より『この顧客はどんな仕事を片づけたいのか』から考えてみます。そうすると競合の見え方も、売り方も、優先順位もかなり変わりそうです。ミカでした。
タカシ
タカシでした。また次回、SaaS プロダクトを経営の言葉で分解していきましょう。お聴きいただきありがとうございました。