こんにちは。ろっさんです。
ビジネスの世界では、新しいサービスを生み出すことと同じくらい、既存のサービスを使い続けてもらうことが重要だと考えられています。しかし、お客様がなぜサービスを辞めてしまうのか、その本当の理由を突き止めることは、多くの場合、とても難しい課題です。
特にB2B（企業間取引）のサービスでは、「契約期間が過ぎたから」「別のツールに切り替えたから」といった表面的な言葉の裏に、もっと深い理由が隠されていることが少なくありません。この「見えない解約の影」を追うことが、サービスの改善や次の成長につながる大切な一歩となるでしょう。
今回、この見えにくい解約理由をどうやって深く理解していくかについて、ご一緒に考えていきたいと思います。具体的には、
- なぜサービスを「解雇」するのか、その本質的な「ジョブ」を捉える考え方（JTBD）
- 解約ユーザーへのインタビューをどう設計し、真意を引き出すか
- サービスの利用ログデータをどう活用して裏付けを取るか
- そして何より、安易な因果関係に飛びつかず、真の原因に迫る検証手順
といった点について、高校生の方にも分かりやすく、そして実務に役立つ視点でお伝えしていきます。
JTBD（Job To Be Done）で解約の「ジョブ」を捉え直す
お客様がサービスを解約する理由を探るとき、私たちはつい「価格が高かった」「機能が足りなかった」「競合の方が良かった」といった、サービス自体の特徴やスペックに目を向けがちです。もちろん、これらも理由の一部ではあるでしょう。
しかし、こうした表面的な理由だけでは、多くの場合、本当の「なぜ」は見えてこないものです。例えば、あるお客様が「価格が高いから解約します」と言っても、本当に価格だけが問題だったのでしょうか。もしかしたら、その価格に見合うだけの「価値」や「成果」を感じられなかった、という本質的な課題が隠れているのかもしれません。
ここで役立つのが、JTBD（Job To Be Done：片付けたい用事）という考え方です。これは、「お客様は何か特定の目的（ジョブ）を達成するために、商品やサービスを”雇う”」と捉えるフレームワークです。私たちはドリルが欲しいのではなく、「壁に穴を開けたい」というジョブを片付けるためにドリルを雇う、という例は有名でしょう。
この考え方を解約に適用すると、「お客様は、当初、あるジョブを片付けるためにあなたのサービスを雇った。しかし、何らかの理由でそのジョブが片付かなかった、あるいは別の、より重要なジョブが生まれ、あなたのサービスではそれが片付けられなくなったため、サービスを”解雇”した」と捉え直すことができます。
つまり、解約の背後にあるのは、単なるサービスへの不満ではなく、お客様が「達成したかった進歩」や「解決したかった障害」といった、より深い文脈にあるジョブの失敗、あるいは変化である、という視点を持つことが重要となるでしょう。
解約理由をJTBDで仮説立てする具体的なアプローチ
では、実際にB2Bサービスで解約理由が掴めない状況を想定し、JTBDを使って仮説を立てる例を見ていきましょう。
あるB2B向けのプロジェクト管理SaaSを提供しているA社は、顧客の解約率増加に悩んでいました。解約時のアンケートでは「契約期間満了のため」「別のツールに切り替えた」という回答が多く、具体的な改善点が見えにくい状況です。A社が提供するSaaSは、主に中小企業のチームがプロジェクトの進捗を管理し、メンバー間のコミュニケーションを円滑にすることを目指していました。
ここでA社がJTBDの視点を取り入れます。
まず、サービスを「雇った」時の状況を想像します。お客様はどのような「状況」にあり、どのような「進歩」を求めて、このSaaSを使い始めたのでしょうか。そして、どのような「障害」を乗り越えたいと考えていたのでしょうか。
- 状況（Situation）：「プロジェクトの進捗が不透明で、チームメンバー間の情報共有が滞りがちだった」「タスクの抜け漏れが多く、締切に間に合わないことが増えていた」
- 求めている進歩（Desired Progress）：「プロジェクトの全体像を常に把握し、遅延なくスムーズに完了させたい」「メンバーが各自のタスクに集中でき、かつ全体との連携を保てるようにしたい」
- 乗り越えたい障害（Obstacles）：「紙やスプレッドシートでの管理は手間がかかり、リアルタイム性に欠ける」「メールやチャットだけでは、議論の履歴が散らばり、後から追うのが難しい」
次に、サービスを「解雇」した時の状況、つまり解約理由をJTBDの観点から仮説立てします。
- 仮説1：求めていた進歩が達成できなかった
- 例：「プロジェクトの可視化はできたものの、タスクの細分化や担当割り当てが直感的にできず、結局抜け漏れは解消されなかった」
- 例：「チームメンバーがサービスを使いこなせず、結果的に情報共有の進歩が実感できなかった」
- 仮説2：別の状況変化により、より重要なジョブが生まれた
- 例：「チームの規模が急拡大し、より大規模プロジェクト向けの複雑な権限管理やリソース配分機能が必要になった（当初のジョブがスケールしなくなった）」
- 例：「他部門との連携が必須となり、部門間の連携に特化した別のジョブ（別ツール）を雇う必要が生じた」
- 仮説3：障害が解消されなかった、あるいは新たな障害が生まれた
- 例：「サービスを使うこと自体が新たな手間となり、本来のプロジェクト管理の生産性を阻害してしまった」
- 例：「既存の業務フローにSaaSが合わず、無理やり運用しようとした結果、かえって効率が落ちた」
このように、表面的な「別のツールに切り替えた」という言葉の裏に、「そのツールがどんなジョブを、なぜ、より良く片付けられたのか？」という視点で、具体的な仮説を立てていくことがJTBDアプローチの出発点となるでしょう。
定性調査：解約ユーザーへのインタビュー設計
JTBDの観点から解約理由の仮説が立てられたら、次はそれを検証し、深掘りするために、実際に解約したお客様へのインタビュー（定性調査）を行います。
インタビューの目的は、立てた仮説が正しいかどうかを一方的に確認することではありません。むしろ、お客様自身の言葉で、サービスの利用開始から解約に至るまでの「物語」を語ってもらうことで、私たちが想像もしなかったような真実や、仮説を裏付ける具体的なエピソード、あるいは全く新しい洞察を得ることにあります。
質問設計のポイント：誘導を避け、真のジョブと感情を引き出す
インタビューで最も避けたいのは、質問がお客様を特定の方向に「誘導」してしまうことです。例えば、「価格が高いと感じましたか？」と聞くと、お客様は「はい」と答えやすくなります。しかし、それが本当の理由でなかったとしても、その場の雰囲気で答えてしまう可能性があるでしょう。
そこで、以下のような質問の仕方を心がけることが重要です。
- 開始のきっかけと初期のジョブを探る質問
- 「このサービスを使い始める前、どんなことでお困りでしたか？具体的に教えていただけますか？」
- 「当時、どのような『進歩』を期待して、このサービスを導入されましたか？」
- 「他の選択肢もあった中で、なぜこのサービスを選ばれたのでしょうか？その決め手は何でしたか？」
- 利用中の体験とジョブの達成度を探る質問
- 「サービスを使い始めてみて、期待通りでしたか？どんな点が期待通りで、どんな点がそうではありませんでしたか？」
- 「特に役立った機能や場面はありましたか？逆に、使いにくかったり、もっとこうだったら、と思った点はありますか？」
- 「このサービスを使うことで、あなたのチームや仕事にどんな変化がありましたか？」
- 解約に至る経緯とジョブの変化を探る質問
- 「解約を考え始めたのは、どのようなきっかけでしたか？」
- 「解約を決断するまでの間、どんな葛藤がありましたか？他の解決策を検討しましたか？」
- 「解約後、以前抱えていた課題はどのように解決されていますか？現在、どのようなツールや方法を使っていますか？」
- 「もし、このサービスが〇〇だったら、解約しなかったと思いますか？その〇〇とは具体的に何でしょうか？」
これらの質問を通じて、お客様が「いつ、どのような状況で、何を達成したくて、何に困っていたのか」というJTBDの要素を、お客様自身の言葉で引き出すことを目指します。お客様の感情やサービスに対する葛藤に焦点を当てることで、より深い洞察が得られるでしょう。
サンプル選定と誘導バイアス回避のテクニック
サンプル選定：
解約したお客様全員にインタビューを行うのは難しい場合が多いでしょう。そのため、様々な解約パターンのお客様をバランス良く選定することが大切です。
- 解約直後のユーザー：記憶が新しく、具体的な状況を詳細に語ってもらいやすいです。
- サービス導入初期に解約したユーザー：期待値とのギャップやオンボーディングの課題が見えやすいでしょう。
- 長期間利用後に解約したユーザー：事業の変化やサービスの陳腐化といった、より構造的な問題が見えやすいです。
これらの層から数名ずつ選ぶことで、多様な視点から解約理由を探ることが可能になります。
誘導バイアス回避のテクニック：
- 中立的な姿勢：質問者は「答え」を知ろうとするのではなく、「お客様の物語」を聞かせてもらうという謙虚な姿勢で臨みます。
- 沈黙を恐れない：お客様が言葉に詰まっても、すぐに次の質問をせず、沈黙を許容することで、より深い思考を引き出すことがあります。
- 「なぜ」の連鎖：お客様が話した内容に対して、「それはなぜですか？」「具体的にはどのようなことですか？」と掘り下げることで、表面的な理由の裏にある真意に迫ります。
- ミラーリングと反復：お客様の言葉を繰り返し（例：「〜とおっしゃいましたね」）、理解を示しながら、さらに詳しく話してもらうことを促します。
- 否定的な意見の歓迎：サービスに対する不満や批判も、貴重な情報として真摯に受け止める姿勢を見せることで、お客様は安心して本音を語ってくれるでしょう。
定量分析：ログデータで行動の裏付けを探る
インタビューで得られた解約理由の仮説や洞察は、お客様の主観的な言葉に基づいています。これらを補強したり、時には反証したりするために、客観的なデータ、特にサービスの利用ログデータを活用することが非常に重要です。
データは嘘をつきません。お客様が「A機能を使いたかったが、うまく動かなかった」と話していても、ログデータを見ると「そもそもA機能にはほとんどアクセスしていなかった」という事実が判明することもあります。このように、お客様の言葉と実際の行動の間にギャップがないかを確認することで、解約理由の真実に、より深く迫ることができるでしょう。
どのようなデータを見るか
A社のプロジェクト管理SaaSの例で考えてみましょう。
- 利用頻度と継続性：
- ログイン頻度：解約直前のログイン頻度が急激に減少していないか。
- 機能利用頻度：特定の重要機能や核となる機能の利用が、解約前に停止または減少していないか。
- 特定機能の利用状況：
- 重要機能の利用状況：サービスが提供する主要な価値である「プロジェクト進捗管理機能」「タスク割り当て機能」「コミュニケーション機能」などが、どの程度利用されていたか。
- 利用機能の偏り：一部の機能しか使っておらず、サービスの全体的な価値を享受していなかった可能性はないか。
- 顧客サポートへの問い合わせ履歴：
- 問い合わせ内容：解約したお客様が、どのような機能について、どのような問題で問い合わせていたか。特定の機能への不満や、操作方法に関する疑問が多かったか。
- 問い合わせ頻度：サポートへの連絡頻度が高かったか、あるいは全く問い合わせがなかったか。
- 問題解決までの時間：問い合わせから問題解決までに時間がかかっていなかったか。
- 行動パターンの変化：
- 解約前の予兆：特定の機能の使用停止、特定のレポート閲覧の減少など、解約につながる行動の変化が見られないか。
- チーム利用状況：複数のユーザーで利用するサービスの場合、チーム全体での利用状況（特定のメンバーだけが使わなくなっていた、など）も確認します。
これらのログデータは、インタビューで得られた「物語」に客観的な数字の裏付けを与える役割を果たします。ただし、データはあくまで「何が起こったか」を示しているに過ぎません。「なぜそれが起こったのか」という因果関係を、データだけで安易に判断してはいけない、という点には常に注意を払う必要があるでしょう。
定性と定量の統合と「因果っぽい説明に飛びつかない」検証手順
インタビューによる定性的な情報と、ログデータによる定量的な情報は、それぞれが単独では見えてこない真実を明らかにするための、車の両輪のような存在です。両者を統合することで、より深く、より確からしい解約理由の洞察を得ることが可能になります。
しかし、ここで非常に重要なのが、「因果っぽい説明に飛びつかない」という姿勢です。例えば、インタビューで「A機能が使いにくかった」という声が聞かれ、ログデータでも「A機能の利用率が低かった」という事実が確認されたとします。このとき、「A機能が使いにくいから解約した」と結論づけてしまいがちですが、本当にそうでしょうか。
もしかしたら、お客様はA機能が使いにくいと感じていたものの、そもそもA機能で解決したいジョブが、お客様の主要なジョブではなかったのかもしれません。あるいは、A機能を使うべき状況自体がほとんどなく、使いにくさは解約の直接的な原因ではなかったのかもしれません。データ上の相関関係と、真の因果関係は大きく異なる場合があるのです。
「因果っぽい説明に飛びつかない」ための反証質問の導入
このような安易な結論に飛びつくことを避けるために、私たちは「反証質問」というアプローチを導入します。これは、立てた仮説を「正しい」と証明しようとするのではなく、「もしこの仮説が間違っていたとしたら？」という視点から、徹底的にその仮説を疑い、反論を試みる思考プロセスです。
科学の世界では、ある理論が正しいことを証明するよりも、その理論が間違っている可能性を探す方が、より真実に近づけると考えられています。これを「反証主義」と言い、解約理由の探求においても非常に有効です。
A社のプロジェクト管理SaaSの例に戻りましょう。
インタビューから「タスク割り当て機能が複雑で、チームメンバーが使いこなせなかった」という声が多く聞かれ、ログデータからも「タスク割り当て機能の利用率が低かった解約ユーザーが多い」という相関が見られたとします。
ここで「タスク割り当て機能の複雑さが解約の主な原因である」という仮説が生まれたとしましょう。この仮説に対して、以下のような反証質問を投げかけます。
- 「もしタスク割り当て機能がもっとシンプルで使いやすかったら、本当に全員解約しなかったと断言できますか？」
- → 他に解約に至る要因はなかったか？例えば、チーム規模が大きくなりすぎてSaaS自体が合わなくなった、など。
- 「タスク割り当て機能が使われていなかったのは、本当に『複雑だから』という理由だけでしょうか？」
- → そもそも、タスク割り当て自体を細かく行わない文化のチームだった、という可能性はないか？
- → タスク割り当てを別のオフラインツールやチャットで行っていた、という可能性はないか？
- 「この機能の複雑さについて、なぜもっと早くサポートに相談しなかったのでしょうか？」
- → 相談するほどの問題ではなかったのか？それとも、相談しても解決しないと諦めていたのか？
- → 相談するより解約する方が手っ取り早いと感じるほどの、他の不満が積もっていたのか？
- 「タスク割り当て機能が使われていない解約ユーザーと、使われていないが継続しているユーザーの間で、他に異なる行動や特徴はありませんか？」
- → 例えば、継続ユーザーは他の特定のコア機能を深く利用しているが、解約ユーザーはそれも利用していなかった、など。
このように、一つの仮説に対して多角的に「それは本当にそうなのか？」と問いかけ続けることで、私たちは安易な結論に飛びつくことなく、さらに深層にある真の解約理由に迫ることができるでしょう。
例えば、上記の反証質問を繰り返す中で、「タスク割り当て機能の複雑さは一因ではあったものの、それ以上に『このSaaSを通じて得られるはずだった、チーム全体でプロジェクトを共有し、協力して進めるという”進歩”自体が、チームの働き方と合わなかった』という、より本質的なジョブの失敗があった」という洞察が得られるかもしれません。
ログデータで利用頻度が低くても、「なぜ使われなかったのか」はデータだけでは分かりません。インタビューで「使い方が分からなかった」と聞いたとしても、それが本当にその機能が欲しかったが使えなかったのか、それとも「そもそも不要だった」のか、あるいは「他の方法で代替していた」のか、さらに深く掘り下げていく必要があります。
定性情報と定量情報を統合し、そしてその統合された情報に対しても「反証質問」をぶつけることで、私たちは「相関関係」を「因果関係」と混同するリスクを最小限に抑え、お客様がサービスを「解雇」した真のジョブを見つけることができるはずです。
まとめ：解約の真実に迫る旅路
お客様がサービスを解約する、その見えにくい理由を突き止める旅は、決して簡単なものではありません。しかし、JTBDというお客様の「片付けたい用事」に目を向け、解約の背景にある真のジョブを理解しようと努めることで、その旅路はより実り豊かなものになるでしょう。
インタビューで語られるお客様の「物語」と、ログデータが示す「行動の事実」を注意深く統合し、そして何よりも「因果っぽい説明に飛びつかない」という批判的な思考、つまり「反証質問」を常に自分自身に投げかける姿勢が求められます。
このプロセスを通じて、私たちは単に「解約率を下げる」という目の前の課題を解決するだけでなく、お客様が本当に価値を感じる「ジョブ」とは何か、私たちが提供すべき「進歩」とは何かを深く理解し、サービスの改善や新たな価値創造へとつなげていくことができるはずです。お客様の解約の裏に隠された真実を追究することは、次の成長に向けた最も大切な一歩となるでしょう。
コメント