【この記事の超概略サマリー】
✓カスタマーサクセスのためには、プロダクトだけでなくサービスも重要。
✓「機能改善」と「運用回避」の両立は決して容易でなく、組織的な問題（＝カスタマーサクセスのジレンマ）が潜んでいる。
✓カスタマーサクセスのためには、短期的に必要な支援を行いつつ、長期的な視点で構造改革にも取り組むべき。
✓特に、「アクアライン的ソリューション」は見落としがちであるため、これを議論するプロセスを組織に組み込むべき。

1. カスタマーサクセスとは

　カスタマーサクセスとは「顧客を支援し、顧客が求めている成果を、顧客に実現して頂くこと」だ。ここで顧客に対する「支援」の内容は、「プロダクト」と「サービス」の二つに大別されることが多い。したがって、多くの場合においてカスタマーサクセスは「顧客に提供するプロダクトやサービスについて、顧客にとってのROIを最大化すること」などと言い換えてもよい。

　カスタマーサクセスはSaaSの事業成長における至上命題であり、SaaSベンダーにとって「顧客の成功こそが自社の成功」だという考え方・思想は、既に一般化していると思われる。

　そして、Gainsight CEOのニック・メータ氏が言うように、カスタマーサクセスの思想自体はあらゆるビジネスにおいて重要な要素であると考えられる。実際に多くのビジネスにおいて、パレートの法則（概ね上位2割の顧客が、概ね売上の8割を占めるという経験則）や、人口減少社会における内需縮小を背景に、LTV最大化やリピーター育成の重要性が一層増しており、「売り切りではなく継続支援」という基本スタンスが求められているだろう。

　特に、BtoBのSaaSに関しては、以下で示す通り、カスタマーサクセスの重要性をいくら強調しても強調し過ぎることはない。以降では、BtoBのSaaSにおけるカスタマーサクセスを前提として議論を進める。

2. 業務改革を通じた課題解決

　前述の通り、顧客が求めている成果を創出することこそが、カスタマーサクセスだ。その前提に立てば、自ずとカスタマーサクセスは決してSaaSベンダーの支援のみでは実現し得ないことが分かるであろう。顧客と共同して顧客にとっての成果を創出する姿勢が欠かせない。

　そして、顧客にとってSaaSツールの導入・活用は、「業務改革を通じた課題解決」のための手段だ。当然、単にツールを導入するだけでは業務改革を為し得ない。前提としての最適なビジネスプロセスやオペレーションのデザイン、業務改革のプロジェクトマネジメントとチェンジマネジメント、システム連携や情報セキュリティ対策など、顧客が業務改革を成功させるために取り組むべきテーマは多岐に渡る。ツール導入の先に業務改革が、さらにその先にカスタマーサクセスがある。カスタマーサクセスのプロセスは、顧客にとっての課題解決プロセスそのものである。

3. サービスがプロダクトを補完し提供価値を増強する

　だからこそ、顧客にとって必要な支援は、基本的にプロダクトのみでは完結しない。業務改革を成功させるためには、前述の通り「プロダクトの適切な使い方」や「プロダクト導入の適切な進め方」などプロダクトの外にある領域も重要となるが、これらは明らかにプロダクトの仕様や他社事例を熟知しているベンダー側で支援すべきだ。すなわち、ここはベンダー側のサービス提供が欠かせない。

※ちなみに、顧客へのサービス提供方法は、ハイタッチにしろテックタッチにしろ、体制や内容などに応じて適切なものを選択すればよい。この記事では触れないが、テックタッチなどの方法論について詳しく知りたい方は以下の藤島さんの記事など非常に分かりやすいので参照されたい。

　また、顧客への提供価値を高めたり、関係性を深めたりするためにもサービスは不可欠だ。SaaSに限らず一般に、サービスの独自化・先鋭化が、企業の競争優位につながっている事例は枚挙に暇がない。

　つまり、プロダクトだけではなく、サービスも重要である。プロダクトの価値を増大させるためにも、プロダクトだけでは成し得ないことをサービスによって補完し、カスタマーサクセスに繋げる。

4. カスタマーサクセスに必要なサービス提供

　カスタマーサクセスにコミットするためには、顧客の成果を最大化するために必要な意思決定とアクション実行を、顧客に行っていただく必要がある。そのときに顧客だけでは完結できない部分や、そもそも顧客には想定できていない部分こそが、ベンダー側が提供すべきサービス内容だ。

　成果創出のために必要なことは全て提案し切るというのが基本スタンスだ。その中でも特にベンダー側が支援すべき領域として、多くの場合において検討すべき典型的なテーマを示すと下図のポイントが挙げられる。

　また、上図のうち特に「機能設定」と「運用方法」については、別の観点でのケアが必要になる。それは、プロダクト開発時に想定している「標準的な顧客の業務プロセス」と「実際の個社ごとの業務プロセス」との間には一定のズレがあるという点だ。それがゆえに顧客からはプロダクトに対して「必要な機能が備わっていない」といった評価を受けてしまうことさえある。最悪の場合、解約事由にもなりうる。

5. 運用回避と追加サービスによるリカバリー

　このような事態を避けるためにも、顧客が実現したいことや現行のオペレーションを丁寧に傾聴し、事実としての仕様はきちんと伝えた上で代替案を提案するコミュニケーションがベンダー側に求められる。プロダクトだけでは解決できない部分を「運用回避」のアイデアによって乗り越えるということである。「現状はできないです、すみません。機能改善をお待ちください。」などと伝えるだけではプロダクトの価値を毀損してしまうばかりで、当然カスタマーサクセスも実現できない。

　以下の馬田さんのスライドで紹介されている通り、実際に大きな成長を遂げたプロダクトについて、特に初期段階ではプロダクトで不足する部分を運用回避や追加サービスによってリカバリーされている。

※Takaaki Umada (2015年)「カスタマーサポートのことは嫌いでも、カスタマーサクセスは嫌いにならないでください」p.87より（https://www.slideshare.net/takaumada/startup-customer-success-support）

6. カスタマーサクセスのジレンマ

　しかし、いつまでも「運用回避」を続けてはいけない。サービスは仮にどんなに標準化を進めても属人的な側面を完全に排除することはできない。プロダクトはスケール出来ないし、顧客への提供価値も一定の水準以上には高められないし安定もしない。「運用回避」が当たり前になると、本来必要なプロダクト改善を見失ってしまうことさえある。

　顧客としては、iPhoneのように説明書不要で直感的に利用できることが最も望ましいし、わざわざ「運用回避」せずとも思い通りに運用できることが本来の理想だ。プロダクト改善によって不要にできるサービスなのであれば、そのサービスはそもそも存在しない方が良いのだ。

　だが、ここにスタンスとしてのジレンマがある。カスタマーサクセスのジレンマだ。概要は以下ツイートで記載の通り。

　一見すると、単に両立すれば良いため「ジレンマではないのでは？」と思われるが、意外と簡単ではなくスタンスとして対立している。喩えると、「高速レジ打ちの技術を磨いた人」が、「レジの自動化」を発想することが難しいという話に近い。これは専門家と門外漢の対立だ。

7. 専門家と門外漢の対立

　まず、顧客に対して適切な「運用回避」を提案できるようになるためには、前提としてプロダクトの専門家である必要がある。すなわち、プロダクトの仕様や一般的な利用方法を熟知し、現段階におけるプロダクトの限界やその対応策について精通していなければ、適切な「運用回避」は提案できない。

　そして、そのようにプロダクトの専門家と言えるレベルに知識が成熟していれば、「運用回避」ではどうにも解決できないプロダクト課題（以降、これは欠陥仕様と呼ぶ）についても理解している。すると、専門家は欠陥仕様を優先的に解決すべきだと主張したくなり、運用回避で対応できている（と思っている）プロダクト課題を見過ごしてしまうことが多い。未解決の問題こそ優先的に解決したいと考えるためだ。しかし、これはあくまで一面的な評価であり、本質的な優先順位付けではない。

　一方で、門外漢の方が「そもそも論」としての課題には気付きやすい。門外漢は、初めて利用するユーザーの目線で、プロダクトとして分かりにくい点や使いにくい点を感じ取りやすいからだ。しかし、その門外漢が気付いた課題を組織的に吸い上げて改善実行に移すことは、実は容易でない。門外漢は、「あくまでも自分が勉強不足だから課題に感じているだけ」と解釈したり、「自分がすぐに気付けるような点は考慮された上で、何かしらの事情があるだろう」と忖度したりする場合がある。しかも、門外漢が社内の人間だとすると、専門家よりも社歴の浅いメンバーであるので、発言力も強くないだろう。この問題の構図をあえて極端にシンプルに表現すると下図の通りだ。

　以上の通り、現実には組織的なしがらみも絡まって、本質的に解消すべきプロダクト課題が見過ごされてしまう構図がある。しかも、意識していなければ、この問題、すなわち「カスタマーサクセスのジレンマ」に気付くことすらできないだろう。

8.「 アクアラインをつくろう」が言える場を設ける

　では、どうすれば良いのか？

　ベンダーが、カスタマーサクセスのジレンマに上手く対応するためには、一人一人がプロダクトの専門家として「運用回避」を含めたその時のベスト提案を顧客に提供するのを基本として、定期的に「そもそも論」の見直しを行うプロセスを構築することが重要だ。「運用回避」を含めたサービス提供については既に詳しく触れてきた通りだが、「そもそも論」の見直しは少し補足しておきたい。

　あえて極端な例え話として、東京湾アクアラインを挙げる。

※東京湾アクアラインとは
1997年に開通した東京湾の中央部を横断する全長15.1kmの自動車専用の有料道路で、木更津と対岸の川崎を約15分で結ぶ。それまで木更津ジャンクションから羽田空港までの移動は、湾岸線ルートを通って約65分所要する必要があったが、東京湾アクアラインのルートを活用すると同区間を約20分で移動できるようになった。
https://www.pref.chiba.lg.jp/doukei/aqualine/aqualinegaiyou/
https://www.e-nexco.co.jp/assets/pdf/pressroom/data_room/regular_mtg/h29/0802/02.pdf

　もし仮にあなたが、アクアラインが建設される前の時代に生きていたとして、その時にもし「川崎から木更津まで最速で行けるようにしたい」という相談を受けていたとしたら、どのような解決策を考えただろうか？「東京湾を横断するアクアラインをつくろう」という発想に至っただろうか？仮に思いついたとして、それを提案しようとするだろうか？できない理由はごまんとある中で、推進しようと思えただろうか？

　そもそも論の見直しとは、第一原理（ゼロベース）での発想だ。前の例に倣ってアクアライン的ソリューションと名付けよう。流石にアクアラインのプロジェクトは壮大過ぎるかもしれないが、発想としてはこういうことである。そもそも論で、あるべき顧客体験・あるべき社会像を構想し、それを実現するための具体的な仕様を検討するのだ。以下ツイートの「レンガの家の提案」も、アクアライン的提案の一例だ。

　アクアライン的ソリューションは、そもそもなかなか思いつくことが簡単ではない、さらに思いついてもなかなか言おうと思わないテーマだ。逆に、このような実現性が高くない話ばかりしていても、目の前で困っている顧客への提供価値は最大化できない。アクアライン的ソリューションはあくまでも長期的な目線での話だ。

　その上で組織の仕組みとして、定期的にアクアライン的ソリューションを議論する会議体など設けることが現実的な対応策であろう。これは顧客の声をそのまま反映させるだけのプロセスからは生まれない。

9. ベンダーに求められる短期的対応と長期的対応

　繰り返し述べてきたように、ベンダーは短期的には個社への支援を最大化しカスタマーサクセスに繋がるサービス提供をすべきだ。その上で、長期的な視点でプロダクト自体を最適な状態に改善すること、並びに第一原理の発想で本来あるべき顧客体験の実現方法も検討すべきだ。

　そして、このような対応方針はプロダクト改善に限ったものではない。顧客コミュニケーションやサービスメニューに関しても同様だ。まとめると以下の表の通りである。

　行動経済学の理論になぞらえて言えば、プロダクトはユーザーを「ナッジ」する。だからこそ、どういう方向にリードしたいのか、どんな顧客体験を提供したいのか、どんな社会を実現したいのか、ベンダーにはその思想が問われる。カスタマーサクセスのデザインこそが重要だ。

こちらの記事は以上となります。長文でしたが最後までお読みいただきまして、本当にありがとうございます。

少しでもご参考いただけた部分はありましたでしょうか。
あなたの思考の整理や、お仕事のヒントになる部分があったら幸いです。

少しでもご参考になる部分がございましたら、「いいね」や「シェア」など頂けたらとても嬉しいです。

改めまして、最後までお読みいただきありがとうございました。