「1on1で話すことがない」へのシンプルな解決策
日常のマネジメントの仕組みとして1on1を取り入れている企業は増えましたが、 「1on1で話すことがない」というのは、大変よく見る「あるある」です。
教科書的には「1on1は、部下の時間」であり、「部下がアジェンダ設定する」のが原則です。
が、部下からすると「何を話したら良いかわからない」と。それどころか「話すことなくて苦痛だ」と。笑
そこでおすすめしているのは
- ①今週やったこと
- ②その中で思ったことや困ったこと
- ③来週やる予定のこと
だけを部下に一覧化しておいてもらうやり方です。
「1on1で話すことがない」のはどんな人か
そもそも、ある程度自立している人材であれば、部下側が自分で1on1のアジェンダを設定できるはずです。
例えば、自立した管理職同士（課長と部長）の1on1で「話すことがなくて困ってる」って場面は想像つかないですよね。
なので、「1on1で話すことがない」に対する処方箋は、ちょっとジュニアなメンバーを前提に組み立てなくてはならない。
そう考えると、「話したいことなんでもいいんだよ」とオープンに投げすぎるのはあまり良くない。多分うまくアジェンダ設定できない。
じゃあ、「例えば、こういうことを話して欲しい」と具体例を示せば良いかというと、実はいまいち。なぜなら、ジュニアなメンバーに具体例を示すとそれに引っ張られてしまい、本人が本当に話したいことが話せないリスクがあるから。
「やったこと」「思ったこと」「次やること」を書く
「やったこと」は誰でも書けるし中立
でも、「今週やったこと」なら誰でも書けるし、事実なので中立。
それに加えて、やったことがあれば「思ったこと/困ったこと」ひとつくらいかけるものです。
思ったことの記載があれば、部下がどんなこと考えているかの相互理解になる。そして、「来週やること」があれば、懸念を先に潰すことができる。
ポイントは、1on1のアジェンダそのものではなく、アジェンダ選定の元になる事実（と本人の主観である感想）だけを簡単に書いてもらうということです。
やったこと/これからやることの一覧を二人で眺めながら「何から話す？」「どれ大変だった？」とかってアジェンダ選定から始めると、割とうまく話が弾みやすくなると思います。
「これ大変だったよね。お疲れ様でした。」と大変だった今週の業務への感謝から始まるのもよいと思います。（1on1のアジェンダがうまく引き出せないケースは、上司側もこういう雑談が得意でないケースが少なくないと思います。）
「来週やること」があるので行動で終われる
また、1on1の原則の一つに「最後は行動で終わる」というのがあります。
これが意外と難しいのですが、「来週やること」の欄があれば、半ば強制的に来週の行動で1on1が終わるようになります。
また、ログ的に同じファイルで管理していけば1on1で「来週やること」は翌週の「今週やったこと」に入ってくるはずなので、差分のチェックも用意になります。
中期はいったん捨てる
このフォーマットは「今週」「来週」をベースにしているので、中期での会話はしにくいです。
が、それはいったん意識的に捨てています。
なぜなら、「1on1でアジェンダ設定できない」ジュニアなメンバーについては、まず目の前の業務をスムーズに進めてもらうことが大切だと思うからです。
中期的な話は、目標設定面談とかでちゃんとやっておく。その上で、日常の1on1で「今日時間余ったから、目標設定シートちょっと見てみようか」たまに触れたりするのもいいと思います。
—
1on1というのは、基本的にいい仕組みだと思うのですが、上司も部下もそれなりに苦労しながら運用しているのも実態だと思います。
なるべく汎用的かつ具体的な解決策として「やったこと」「思ったこと」「来週やること」を一覧化する、というのが良いと思っています。
「嫌われる勇気」を仕事に活かせる4冊｜アドラー心理学
言わずと知れたベストセラー「嫌われる勇気」は、
心理学の三大巨頭の一人であるアドラーの心理学を対話形式で紹介した名著です。
キャッチーなネーミングだけでなく、内容もとても面白く分かりやすい本だと思うのですが、ビジネスパーソンが仕事に活かそうとすると、ちょっと工夫が必要な気もします。
例えば、「第四夜 対人関係のゴールは共同体感覚」では
『自分のことを「行為」レベルで考えず、まずは「存在」のレベルで受け入れていく』
というコンセプトが示されるのですが、ありのままの自分を受け入れちゃって、この競争社会、会社員人生大丈夫なんだっけ？部下への注意しなくちゃいけない場面は具体的にどうしたらいいんだっけ？とか。
そこで、「嫌われる勇気」と日々の仕事の間を埋めるのに役立ちそうな本をご紹介します。
もしアドラーが上司だったら
名前の通りの本です。
自分が上司の立場の人にも、部下の立場の人にもおすすめ。
「嫌われる勇気」は会話形式・物語形式で書かれていますが、
「もしアドラーが上司だったら」も、日本の会社を舞台にした物語形式で書かれています。
文体・ストーリー的にも、「嫌われる勇気」よりずっと平易だと思います。
なので、「普段あまり本を読まないけど『嫌われる勇気』は読んでみた」という人には特におすすめ。
もちろん、それ以外の人も軽く読めるのでおすすめです。
平易なだけでなく、例えば
-
仕事の中での「課題の分離」とは具体的にどういうことか
-
「共同体感覚」を仕事の中でどう醸成するか
-
「行為ではなく存在レベルで受け入れる」と目先のビジネスをどう両立するか
といった課題に対して具体例が示されており、日々の業務に役立つと思います。
なぜ人と組織は変われないのか
組織・人材改革についての堅めの名著です。
組織・人材マネジメント理論との繋ぎという観点からの紹介です。
この本のメイン主張の一つを大雑把に意訳すると
人と組織はなぜ変われないのか。それは、実は変わりたくないからだ。
です。
「嫌われる勇気」の後に読むと、
と発想を展開していく触媒として大活躍する一冊だと思います。
そもそも、この本自体が（それなりに厚め・難しめにもかかわらず）組織・人材マネジメント領域のベストセラーですので、アドラー云々にかかわらず単体でも大変有意義な一冊です。
「7つの習慣」「人を動かす」
そもそもアドラーが最近日本で広く話題になった理由の一つは、
だったら、「嫌われる勇気」の後に、
「人を動かす」「7つの習慣」を読んでみれば理解が深まるじゃん、という。
この2冊は元々国内外のビジネスパーソンに広く親しまれている本ですので、実際の仕事への繋ぎとしては大変役に立つと思います。
「嫌われる勇気」は、キャッチーなネーミングだけでなく、内容も充実していて、出版から10年近くが経っても未だにamazonで上位にランクインし続けています。
他方で、「昔読んだけど、実際何か変わったっけ？」「改めて読んでみたけど、明日から何か変わるんだっけ？」という方もいる気がします。そんな時、今回ご紹介したような本を読むのもアリなのではないかと思います。
50年続くコミュニティタッチの大成功事例：TKC全国会｜ユーザーコミュニティ
昨年くらいから、カスタマーサクセス界隈では「コミュニティタッチ」が取り上げられることが増えてきた気がします。
ハイタッチ / ロータッチ / テックタッチ に連なる第四のタッチモデルで、
ユーザー同士をコミュニティとして結びつけながらロイヤルティを上げていく手法です。
コミュニティ・タッチツールのベンダーさんもいますし、
最新の方法論は色々なところで語られています。
が、実は日本には50年の歴史を持つユーザー・コミュニティの大成功事例があることは、あまり語られる機会がない気がします。
それは「TKC全国会」です。
<目次>
TKC全国会って？
TKCグループHP には、以下の記載があります。
実は、税理士向けシステムベンダーの"株式会社TKC"が設立した団体です。
TKCという会社は面白くて、
会社HPには
とあります。
栃木計算センター・・・？
その後、自治体からの税務計算業務受託や伝票の開発などを経て、
税理士向けシステム提供などの業務も開始し
1971年に「TKC全国会」が結成されます。今からなんと50年前の話！
TKCグループのホームページには
ここでポイントは
-
元々は、税理士が始めた「計算センター」であること
-
そこに、税理士をクライアントとした様々な事業が付加されていったこと
だと思います。
「TKC全国会」を聞いたことがあったり、あのロゴを見たことがあっても、
それが栃木の情報システム会社によって設立・運営されているコミュニティだということは知らず「経営支援をする税理士の集まり」くらいに思っていた人もいるのではないのではないでしょうか？
TKC全国会は何をしているのか
TKC全国会のHPを見てみると、
TKC全国会に加入することで、以下のような課題に対するソリューションを受けることができると記載されています。
各ソリューションの詳細ページを見てみると、それぞれの課題について、良い意味でシステマチックに体系化されたソリューションが用意されているように見えます。（当然、そのソリューション群は株式会社TKCが提供するシステムと密接に連携します）
システムの使い方にとどまらず、
まさに「税理士事務所経営の成功」という顧客の成功にコミットしている団体なのです。
想像ですが、TKC全国会は上記のようなソリューションに加えて人脈などの価値も加わり
「もはやコミュニティ自体がプロダクトの一部」のような状態が出来上がっているのではないかと思います。
さらに
"プロダクト・フィードバック・ループ"なんて横文字がない時代から、
ユーザー中心の意思決定を前面に出し、それを実際に可能にする仕組みを持つ会社が、日本の栃木県にあったのです。
本当に研究の価値ある事例
コミュニティタッチは、効率的な運営が難しいので、ツールは確かに重要です。
が、コミュニティそのものの在り方の先行事例として、「TKC全国会」は大変参考になると思うのです。
もちろん、時代背景が違うのでそのまま転用は難しいかもしれません。
でも、50年やり続けている事例なので重みが違う。
実際、HPを見ているだけでも「ウチの事業でもこういうコンテンツ提供したら顧客が喜んでくれそう」というアイデアが湧いてきます。
これらをやりきれたのは、創業者自身がユーザーと同じ公認会計士・税理士出身のカリスマであるなどの事情もあるかと思いますが、それにしても50年前に栃木の会社でこれに着目してやり続けるのはホントすごい。
1本論文書けるくらいの研究価値ある事例だと思います。
参考図書
TKC創業者の故・飯塚毅氏は、事務所に国税の税務調査が入って所長以外の4名の職員が法人税法違反教唆の容疑で逮捕起訴→のちに無罪確定など、色々ドラマチックな人生を送られたようです。その辺を経済小説家の高杉良がまとめた小説。
その創設者の仲山さんの本です。
楽天大学は最初から有料のコミュニティとしてスタートした（その方がコンテンツが磨かれるという三木谷さんの考えだったらしい）などの特徴を持ちます。
楽天大学がどういう軌跡を辿っているかは、これからコミュニティをやる方に示唆を与えてくれると思います。↑の本は楽天大学の運営そのものについて書かれたものではありませんが、楽天大学を設立して軌道に乗せたコミュニティマネージャーが何を考えていたかが理解できる本です。
（関連）
プロダクトの提供価値が下がる時、カスタマーサクセスができること
本当に「プロダクトは良くなる一方」なのか
カスタマーサクセスの教科書「青本」も第6原則で「本当に拡張可能な差別化要因は製品だけだ」と謳う通り、
カスタマーサクセスにおけるプロダクト自体の価値の重要性は、色々なところで語られている通りです。
実際に、多くのカスタマーサクセスがプロダクトフィードバックに力を入れ、プロダクトの価値の向上に取り組んでいます。
なので、なんとなく「プロダクトの提供価値は上がる一方」というのがカスタマーサクセスの前提になっているような気がします。
しかし、カスタマーサクセスをしていると稀に
「プロダクトの価値が下がる時」というのに遭遇する気がします。
が、あまりそれについて語られない気がする。
そこで以下では
-
プロダクトの価値が下がるパターン
- カスタマーサクセスとしてできること
について整理を試みたいと思います。
プロダクトの価値が下がるパターン
「プロダクトの価値が下がる」と言ったとき、大きくは2つのパターンがあると思います。
-
絶対的価値の低下
-
相対的価値の低下
です。
絶対的価値の低下
ここで「絶対的」は、「他社と比較することなく」という意味です。
「顧客の成功」とは、「顧客の集客における成功」であることは容易に想像がつきます。
なので、サイト経由での送客数(ないしCPA)などの指標が、ヘルススコアの一つとして採用されているはずです。
しかし、きっとこういった集客サイトからの送客数は、月単位・年単位で結構上下しているはずです。
というのも、集客サイトの送客数は例えば
「(A)消費者の飲食店利用回数×(B)うち、当該サイトを利用する率」と因数分解できますが
-
(A)飲食店利用回数 ▶︎例えば景気や感染症の状況などによって上下する
からです。
「競合と比べて、送客数(≒提供価値)で負ける」のではなく
「自社の送客数自体が減る」事態が発生するのです。
そして、サイト全体としてその瞬間の送客の総量は決まっているはずなので、カスタマーサクセスの努力しても事業全体では基本的にゼロ・サムゲームとなり（誰かへの送客が増えれば誰かへの送客が減るので）、全員は救えません。
これ以外にも、例えば
-
マーケット自体が変わる（例：在宅勤務が進み、オフィス勤務を支える各種ツールの価値が下がる）
-
ツールの前提が変わる（例：法改正に対応しきれず、顧客が一部作業をExcelですることになり、これまで提供していた業務効率化の効果が落ちる）
-
プロダクト自体の経年劣化（例：コードが最新ブラウザに対応できない / スパゲッティ化してバグで止まることが多くなる / デザインが古い感じなってなんとなく使いにくくなる）
みたいなケースもあると思います。
そんなわけで、プロダクトや状況によっては、
大した仕様変更とかしていないのに「プロダクトの価値が絶対的に低下する」ということがあります。
相対的価値の低下
ここで「相対的」は、「他社と比較して」という意味です。
競争力の低下と言った方が適切かもしれません。
例えば、
- 月額3万円が相場の市場に、月額数千円で後発企業が参入してきた
- 機能は若干劣るが、価格が1/10レベル。
- 先行企業を参考にしているので、UI・UXはいい意味でシンプルに仕上がっている。
こうなると、高機能・多機能が必要ない顧客は一気に後発企業に流れてきます。
同価格帯で高機能のプロダクトに参入された場合も同様です。
元々その市場にいるプレイヤーから見ると、
一切プロダクトの仕様とか変えていなくて、顧客のヘルススコアも大して変わっていないはずなのですが、チャーンだけがグッとあがる現象が発生している、
そんな感じに見えるかもしれません。
プロダクトの価値の低下にどう向き合うか
具体的な方向
具体的な方向として、例えば、以下が考えられると思います。
1)従量課金に寄せる
例えば、先ほどの集客サイトの例で行けば、
送客数に応じた課金にすれば、顧客の離脱自体は防げるかもしれません。
提供する成功の量が増えれば自社の売上も増える構造になるので、カスタマーサクセスの理念にも沿っているように思います。
他方で、ビジネスとしては売上・成長の安定性は失われますし、価値が下がる局面でこの手を打つと、実質的には次の「値下げ」と同じくなることが多いと思います。
2)値下げ
これは基本的には悪手となることが多いですね。
既存プロダクトの値下げはもちろん、
既存プロダクトの下位に「ライトプラン」を出すオプションも失敗に終わることが多い気がします。
以前いた業界で、競合がこの「ライトプランによる顧客囲い込み」戦略を採用したことがあるのですが、結果は
-
顧客流出も獲得も大して変わらない
-
むしろ既存顧客のダウンセルが大量発生して、顧客単価が大崩れ
-
結果として決算大崩れ
と散々なものでした。
3)プロダクト改善
なので、提供価値を上げる取り組みとしてプロダクト改善が重要になります。
これは王道ですね。
が、特に「絶対的な提供価値の低下」のパターンのうちマーケット自体の変化等を伴うケースはこれでは対応できないですね。（例えば、在宅勤務でオフィスツールのニーズが下がってる局面で、既存プロダクトを改善しても限界がある。）
4)複合プロダクトを目指す
そこで考えられるのが、複合プロダクトを目指すことです。
例えば、集客サイト(ホットペッパー)単体で見れば提供価値は下がることもあるかもしれないが、
などのサービスを複合的に（できればパッケージとして）提供することで、単価も顧客も維持する戦略です。
最近、この戦略を採用する企業が増えてきたような気がします。なんとなくですが。
複合プロダクトは、値上げによる単価向上とセットで検討されることが多い戦略な気がしますが
カスタマーサクセス観点で見ると
「サービスの中でポートフォリオを組んで、一時的にどれかのサービスの提供価値が下がっても他でカバーすることで解約率を下げる」みたいな働きをすることがあると思います。
カスタマーサクセスに何ができるか
こうやってみると、「商品の提供価値が下がる時」に必要なのは事業戦略レベルの見直しであり、
カスタマーサクセス単体でできることってあまりないような気がしますが、どうでしょうか？プロダクトフィードバックくらい？
ただ、
商品の価値が下がる予兆があるときにいち早くそれに気付き、
プロダクトや経営陣に適切な情報を提供をすることは、カスタマーサクセスの責任だと思います。
プロダクトフィードバックに乗せる事はもちろん、
-
従来の解約理由区分だとわかりにくいが、実は在宅勤務移管に起因する解約がこの半年でXX件発生している。さらに〜〜社の調査だと在宅勤務「検討中」がまだ30％も残っている。このまま世の中の在宅勤務がX％まで進むと、チャーンがこれくらい悪化する可能性がある。（ので、それを前提に予算組み直した方がいい）
-
解約のうち、新規参入のX社への乗り換えが、前年比較でXX%->XX%まで増えた。乗り換え顧客の主な意思決定理由は〜〜〜であり、そこの部分へのテコ入れが必要。
みたいな、戦略に有意義な示唆を与えるレベルまで情報を深堀・整理して、プロダクトや経営に提供する責任があるんじゃないかと思います。
そのためには、目の前の顧客に向き合うことはもちろん（←これは得意な人が多いのがCS）
ビジネス一般や競合情報への感度、ビジネス的な数字の扱い能力（←これは苦手な人もいるのがCS）を高めておく必要もあるのかな、なんて思います。
(おまけ)
・・・なんて記事を書いていたら、「青本」原著者のN.メータ氏が「10の原則」をアップデートして、2021年版の 10の原則では
だそうです。3.Constantly Drive More Value, Or Expect Churn（価値を常に磨け、さもなくば解約）
停滞はもはや価値が落ちるのと同じってことかもしれませんね。
カスタマーサクセスからプロダクトマネージャーを目指すなら読んだ方が良さそうな本
「将来的には、プロダクトマネージャーになりたい」というのは、
比較的若いカスタマーサクセス職からよく聞くキャリア展望です。
とはいえ、漫然とCSやっていてもプロダクトマネージャーへの道は拓けない、というのも事実。
そこで、取っ掛かりの一つとして、カスタマーサクセスからプロダクトマネージャー/プロダクトオーナーになりたいという方が読んでおいた方が良さそうな本をまとめました。
「プロダクトマネジメントのすべて」
網羅的な良書です。比較的新しいですが、個人的にはとりあえず1冊だけ読むならコレかなぁ、と思う。
目次を紹介するだけで、魅力は十分伝わると思います。
うーん、改めて網羅的良書。
この「プロダクトマネジメントのすべて」で全体像作りながら、気になるところは他の本も読むのがいいと思います。
「INSPIRED」「プロダクトマネジャーの教科書」
いずれも充実した内容で、読んでいるプロダクトマネージャーは多いと思います。オススメされる頻度も高い2冊。
「INSPIERED」は、IT企業でのプロダクトマネジメントを念頭に書かれています。網羅的かつ実務的な内容で、「とりあえずコレ読め」的に1冊目としてお勧めされることも多い本だと思います。若干読みづらいという声も聞きますが、例えば、ユーザーの声の集め方や質問リストの作り方など、細かなテクニックも紹介されていて良書だと思います。特に新規プロダクトに関わりたい方は、読んでおいて損はないと思います。
「プロダクトマネジャーの教科書」は、メーカーとかも視野に入ったちょっと硬めの本。昔よりはスタートアップ界隈で言及される機会が減った気もしますが、普段スタートアップやSaaS寄りのインプットが多い人には逆に新鮮かも。硬めの本ではありますが、これくらい硬め・重めの本もサクッと読める方がプロダクトマネージャーとしてのキャリアは拓け易い気もします。
「リーン・スタートアップ」「Running Lean」
検証による学びをベースにした、スタートアップの方法論の教科書です。
若干古典になりつつありますが、カスタマーサクセスの知識・経験をプロダクトレベルまで視点を飛ばして捉え直す良い触媒になると思います。
例えば、カスタマーサクセスの青本の第一原則「正しい顧客に売ろう」は、CS職の方なら誰でもご存知だと思います。
で、青本をよく読むと「正しい顧客とは、プロダクト・マーケット・フィットを満たす顧客である」と書いてあるわけです。
じゃあ「『プロダクト・マーケット・フィット』って何？」って話は、この辺の書籍を読むとしっかり理解できるわけです。
カスタマーサクセスで言ったら、「リーン・スタートアップ」 が青本、「Running Lean」が実行戦略、みたいな感じでしょうか。
「ビジネスモデル・ジェネレーション」「バリュー・プロポジション・デザイン」
リーンスタートアップの方法論を、視覚的にまとめた姉妹本です。
最近あまり言及されない気がしますが、本エントリでこの2冊を勧めるのは、カスタマーサクセスの日々の感覚をビジネスレベルに昇華する良いきっかけ・触媒になり得ると思うからです。
「バリュー・プロポジション・デザイン」→「ビジネスモデル・ジェネレーション」の順で読むのが良いと思います。
「バリュー・プロポジション・デザイン」の中で触れられる「バリュー・プロポジション・マップ」は、顧客の課題(ジョブ)・痛み(ペイン)・利得(ゲイン)と自社製品の価値提案を対応させるもので、
「目の前の顧客の成功に向き合う」というカスタマーサクセスの思考を、「プロダクトレベルでの価値提案」まで視点を昇華してくれるきっかけになると思います。
-
カスタマーサクセス職が理解しやすい「顧客への価値提供」を中心に吸えている
-
それでいて、コスト構造や収益の流れやチャネルなど、カスタマーサクセス職をなんとなくやっているだけだと思い至らない視点を提供してくれる
そんなわけで、昔ほど見ることは減った気がしますが両方ともおすすめです。
そのほか、いろいろ
以上7冊紹介しましたが、正直、全然十分じゃない。
CS→プロダクトへのキャリアチェンジには、実際にはもっと色々なインプットが必要だと思います。
例えば、
UI/UXの領域として、「ノンデザイナーズ デザインブック」「UXデザインの法則」とか、
いろいろな企業の自伝・ケーススタディ的な本を読めと言う人もいると思います。
そもそも、世のプロダクトマネージャーって総じてインプット量が多いですよね。
強い知的好奇心を持って、本・人・新聞・ネット・SNS・・・様々なチャネルから大量のインプットを得る。それを自分の中で有機的につなげてプロダクトという形で世の中に問う。プロダクトマネージャーの仕事ってそんな側面もあるのかな、と思います。
なので、ここで挙げたような本は既に読んでいたり、
取っ掛かりとして上記のような本（それ以外でも）を読んでみて、それなりにスイスイ読み進められ、それに加えて自身の問題意識に従ってさらにインプットを広げたり深めたりしていけるような方は、カスタマーサクセスからプロダクトマネージャーへの道も拓けやすいのかなぁ、と思います。
あるいは、こういう本をインプットしておくと、普段のプロダクトフィードバックの質がちょっと変わって一目置かれて、結果として社内でプロダクトマネージャーへの道が拓かれ易くなるかもしれません。
ラインナップとしては全然不十分だと思いつつも、そんな気持ちで、取っ掛かりになればと思い「カスタマーサクセスからプロダクトマネージャーを目指すなら読んだ方が良さそうな本」をまとめてみました。
目標に、正しさより覚えやすさを
本やコンサルが教えてくれない目標設定の隠れたTipsに
「覚えやすい」
というのがあると思います。
経営企画やコンサル出身者は理屈をこねて目標設定します。
例えば、
-
昨年度実績がXX件、これに市場成長率のXX％を掛けて、そこに全体の受注率がハイパフォーマー水準まで上がるとすると...
-
全社計画の売上が3年後でXX億円、そのうちこの商材は6%だが、10%くらいのプレゼンスを出したい。そのためには....
- KPIツリーを因数分解していくと、XX部が追う指標はAとBとCとDで...
とか。
それはそれで正しいと思うのですが、
ある局面ではシンプルに「覚えやすい」が重要ということがある、と学んだ出来事がありました。
根拠なく"盛られた"目標設定
以前、とあるプロダクトのオーナーをしていたときのことです。
-
昨年実績
-
市場の拡大予想
-
今後の生産性UP期待分
とか、いくつかパラメーターを設定してシミュレーションして、
自分が出したのは、確か288件という目標値でした。
それを当時の上司に提出したところ、
数週間後に
「333件で予算通しておいたよ。
288からの差分の根拠？期待だよ、期待w」
みたいな感じで、割増されて予算が返ってきました。
無茶ぶりですが、
ここまでは、まぁ成長企業でよくある話だと思います。
で、私はこの目標をメンバーに落とす時、どうにも理屈で説明がつかないので、
もう正直に
「正直、290件くらいまでは見えてるんだけど、最後◯◯さん（上司）の愛で333件になりました。
これから達成する方法を必死に考えるんで、皆さんよろしくお願いします！」
と伝えました。
すると、あるメンバーが言いました。
「333！ゾロ目で覚えやすい！ゾロ目作戦ですね！行きましょう！」
と。
その場は「あぁ、根拠ないのにポジティブに受け止めてくれてありがとう」くらいにしか思っていませんでした。
具体の数字が日々の会話に
ところが、1-2ヶ月経って、それまでと会話にちょっと違いが出ていることに気付きました。
-
「このままのペースで333件行くんですか？」
-
「こうすれば、333件行くんじゃないですか？」
-
「このまま行ったら333行けるね！ゾロ目超えちゃう！」
と、【333】という目標数字が強烈にチーム内で意識されていることに気づいたのです。
「目標に行かない」ではなく「333件に行かない」と具体的な数字が出るのです。
あまりに皆がいろいろなところで言うので、他のチームの人までウチのチームの目標数値を知っていたくらいです。
なんでだろうと思ったのですが、思い当たるのは
「【ゾロ目・333】という数字が覚えやすい」
ということくらいなのです。特に前年からやり方とか変えていないし。
ただ、ストレッチされた目標をしっかり意識するので、みな知恵が出るし体も動きます。
そんなこんなで、チームは当初自分が立てた288件という数値目標を上回るペースでパフォーマンスを発揮していきました。
単純に「覚えやすい」目標の破壊力を知った出来事でした。
そんなに簡単じゃないけど、「覚えやすい」はいくつかの局面では有効なオプション
もちろん、覚えやすいだけで達成できるほど、簡単な物事ばかりではありません。
目標にはそれなりの根拠・正しさが必要。設定後のマネジメントも大切。
ただ、目標というのはそれなりにストレッチするから設定の意味があるわけです。
ストレッチするからには、皆が意識して取り組まないと達成できません。
なので例えば、
-
メンバーの数字への意識足りない
-
メンバーが目標と成り行きの差分から発想できない
-
というか、ぶっちゃけ目標数字自体、誰も覚えてすらいない
みたいな時、シンプルに「覚えやすい」というのは、意外と威力を発揮するかもしれません。
あるいは、ぶっちゃけ目標なんて、ロジックで正しさ積み上げても、最後は数字鉛筆舐めて気合で数字いじることが多いワケです。
そんな時、細かい正しさを追求するのは放棄して
「どうせだったら覚えやすい数字」
というのは、覚えておいて損はないオプションだと思います。
単純な数字以外の面でも同じで、「覚えやすい」というのは大切。
例えば、「KPIツリーを因数分解して行くと、目標は次の7つです！」とか、ロジック的に正くてもメンバー覚えられない。
メンバーに意識させることが目的なので、その手段は「リーダーが繰り返し目標を唱える」とかでもいいですが、それにしても目標自体覚えやすくした方が効果は高いと思います。
（おまけ・後日談）
ちなみに、この【333】という目標、実は達成できなかったんです。
最後どうしても333に届かず、確か310くらいで着地したと記憶しています。
ただ、うまく説明できませんが、多分元々自分が立てた【288】を目標にしていたら、
まず300を超えることはなかったと、今でも思います。
正直288も怪しかったと思います。
その意味で、未達ながらも大きな飛躍の経験とともに
根拠のない【333】というゾロ目から得た学びは、自分の中で今も生きています。
カスタマーサクセスと障害対応
日本でも、「カスタマーサクセス」という名を冠する組織を持つ会社が増えてきました。
カスタマーサクセスの世界では、
障害とかクレーム対応みたいな、後ろ向きな業務が語られることは少ないです。
でも、実際のところ障害は起きます。
（実際に、私が知る限りこの2年で2回はAWSで大きな障害が起きています。）
もちろん、自社起因でも障害は起きます。
SaaSの障害は基本的に全顧客に影響します。
なので、障害が起きると、カスタマーサクセス部隊はその対応に追われます。
しかも、現状日本のカスタマーサクセスはマーケや営業出身者（しかも若い人）が多く、障害対応にあまり慣れていないことも多い。
なのに、カスタマーサクセスのイベントや本で障害対応が語られることは少ない気がする。
そこで、以下では、「カスタマーサクセスの障害対応」について、
対応ステップとtipsの基本的な整理を試みたいと思います。（サポート領域も含めての話をします）
<目次>
障害対応の基本的なステップ
大枠のステップは、以下の通りです。
-
Step1.現状把握
-
Step2.第一報
-
Step3.復旧報告・事後対応
順に解説していきます。
Step1.現状把握
現状把握で押さえるべきポイントは以下です。
-
事象の概要
-
顧客影響の有無
-
復旧の目処
-
代替策・回避策の有無
-
対応体制
-
（必要に応じて）次回Mtgの日時設定
順に補足していきます。
事象の概要
まず、何が起きているかの概要を把握します。
「XX機能が使えない」とか「ログインできない」とか「表示が遅い」とか。
顧客影響の有無
次に、その事象は顧客にどのような影響があるのかを確認します。
「そもそも顧客に影響あるのか」はもちろんですが、具体的にどういったシステム上・ビジネス上の影響があるのかを確認します。
復旧の目処
その上で、復旧の目処を確認します。
30分程度で復旧するなら、いったん対応を焦ることはないかもしれません。
「わからない」なら、変にエンジニアを拘束せずに、他の項目の確認に移った方が得策かもしれません。
代替策・回避策の有無
例えば、「左メニューから印刷機能は使えないけど、[ctrl]+[P]で印刷はできる」みたいな回避策があるなら、それを確認します。
顧客への影響が大きい障害の場合、ここは重要です。
究極、自分たちのプロダクトを瞬間的に捨ててでも、顧客の成功にコミットする場面です。
顧客と顧客の業務、そして製品を深く理解しているカスタマーサクセスのバリューの発揮しどころです。
対応体制
社内の対応体制を確認します。
-
営業・CS・サポートは誰が動いているのか、エンジニアは誰が動いているのか
-
今後CSは誰に連絡すべきなのか、slackはどのチャンネルで会話すべきなのか
-
開発・営業・CS・サポートそれぞれ指揮は誰がとるのか、誰に情報を集約するのか
などを確認します。
経験上、社内チャットは、障害対応用のチャンネルを新規で立ち上げちゃうのがいい気がします。
Step2.第一報
現状把握ができてら、第一報を上げます。
これは、社内にも社外にも出します。
コンセプトは「流れている血を少しでも止める」ことです。
顧客向けの一括お知らせ
顧客向けに記載すべき事項は以下の通りです。
-
今、何が起きているのか
-
分かれば原因
-
復旧の目処
-
代替策がある場合、代替策
-
次の続報のタイミングと方法
-
お詫び
-
本件に関する問い合わせ先
これらを流す意図は、以下の通りです。
-
「状況がわからない」こと自体から来る顧客のフラストレーションを止めること
-
代替策や業務スケジュールの変更を促し、顧客ビジネスへの影響を最小限にすること
-
顧客接点への必要以上の問合せを止めること
なるべくシンプルに、素早く上記を押さえた情報を出すことが求められます。
情報が揃わない場合、事象だけでもすぐにお知らせを出し、その後追記していく方針が良いと思います。
ハイタッチ顧客への個別対応
ハイタッチ顧客については、必要に応じて個別にも連絡をします。
意外と、ドタバタでこの指示が漏れるケースもあります。組織的な指示がないと、CSMによって対応がバラついてしまう。
すぐに行動に移れるよう、常にCSMごとの顧客リストをしっかり管理しておきたいところです。
社内向けのアナウンス
社内向けも、内容は顧客向けアナウンスと大枠は一緒です。
ただし、必要に応じて、以下を追加で記載すると良いと思います。
-
社内の対応体制とエスカレ先
-
（顧客からの問合せが多い場合）謝るしかない部分と、エスカレして欲しい部分など、簡単な顧客対応の指示
-
サポートや営業以外に問い合わせが来たときの対応指示（大規模障害でサポートがキャパオーバーするケースでは、溢れた問い合わせが代表電話等に流れるので、代表電話に対応する管理部の人など関連部署に共有必要です）
その他、必要に応じて、社長などの経営陣への報告を別途行う必要があることもあると思います。
これはエンジニアのトップと一緒にやった方がいい。
Step3.復旧報告・事後対応
復旧したら、復旧した旨の連絡を行います。
一括お知らせ
顧客のビジネスへの影響度に応じて
-
軽度
-
障害の一括お知らせの冒頭に「本障害はYY/MM hh:mmに解消しました。大変ご迷惑をおかけしました。」と一言足すだけ
-
中程度
-
原因と再発防止策をセットで丁寧に上げる
-
重度
-
中程度の記載に加えて、補償についても触れる
といったイメージになろうかと思います。
中程度以上の場合、
再発防止策については顧客が納得するレベルで中身・文章共に練る必要がありますので、復旧の第一報と本格的な障害報告は分ける必要があるかと思います。
SaaSで日常的に起こる障害の多くは、軽度で済んでいると思います。
ハイタッチ顧客への対応
これは、もう個別対応です。
菓子折持っていくこともあると思いますし、個別に補償問題になることもあると思います。
放っておいて、契約更新時期に「あの障害の時、一言電話もくれなかったね」とか言われないように、リストチェックはしておいた方がいいと思います。
社内へのお知らせ
これは簡単でいいと思います。
関連部署への対応のお礼をつけると丁寧かと思います。
再発防止と振り返り
ひと段落したら、再発防止を検討します。
と言っても、技術的な再発防止はエンジニアの仕事になると思います。
カスタマーサクセスとしては、障害そのものというよりも、発生後の対応によって顧客に迷惑をかけなかったか、もっとよくするにはどうしたら良いか、という観点の振り返りをしておくべきということになろうかと思います。
tips
エンジニアの邪魔をしない
障害が起きた時は、復旧が最優先です。
なので、復旧にあたるエンジニアの邪魔をしてはいけません。
他方で、CSとしても顧客に対応するために情報が必要なのも事実です。
そこで、以下のような配慮が有効かつ必要かと思います。
-
エンジニアへの連絡窓口を一本化する
-
営業・CS側だけでなくて、エンジニア側のカウンターパートを決めておくことが大切（大体、直接的に復旧作業には当たらないエンジニアのマネージャーがこれにあたることが多い）
-
必要以上に会議でエンジニアを拘束しない
逃げない
「プロアクティブ」を是とするカスタマーサクセスですが、
障害対応やトラブルになると急に弱気になって
顧客に対して誤魔化したり、連絡来るまで知らんぷりしようとする人がいます。
が、その態度は顧客にも同僚にも伝わります。
障害時においても、カスタマーサクセスには攻める姿勢が必要です。
ぶっちゃけ、障害発生自体はカスタマーサクセスのせいではないはず。
ここで責任感を持って攻めた対応をすれば、社内は勿論、顧客にもちゃんと伝わります。
まぁ、障害対応は辛いんでやりたくないんですけど、起きちゃったものは仕方ない。攻めたほうが後で楽。評価を上げるチャンスくらいに思うしかない。
緊急対応（止血）と再発防止を分ける
障害が起きた時、考えるべきは、今発生している顧客のビジネスへの影響を最小化することです。
社内の責任論は当然後回し。原因究明や再発防止も、後回し。
とにかく、まず流れている血を止める。
顧客が正常にサービスを使える状態に戻すことを最優先すべきです。
意外と、この区別を意識的にできない人を目にします。
これは顧客接点だけでなく、「そもそも論」好きな人が多いエンジニアの議論でもよく見られることです。
一定の原因が見えた時点で
「そもそもここの構成って...」「開発プロセスの管理として...」「コード管理の仕方が...」
とか、そもそも論の議論を始めてしまうケース、見たことないですか？
カスタマーサクセスでも、顧客に被害が出ている途中で、そもそも論に入ってしまうケースをたまに見ます。
この辺は、復旧した後でゆっくりやっていただくのが良いと思います。
二次被害を生まない
ここで言っている「二次被害」は、
障害そのものではなく、
障害に関する顧客対応起因で発生する顧客の損害やクレームです。
経験上、二次被害は
-
社内の情報共有（特に、見通し）が十分でないケース
-
顧客に対して誤魔化したり、情報を十分開示しないケース
で起こりがちです。
青臭いですが、とにかく「顧客への影響を最小限にする」を最優先にマネジメントが行動し、適切な情報開示がされていれば二次被害は生まれないと思います。
マニュアル化は無理。それよりゆるい体制と強いコミットメント
障害が起きてひと段落すると、よくあがる議論が「障害対応マニュアルを作ろう」です。
が、私は「マニュアル」と呼べるレベルのものは無理だと思っています。
障害の現象は個別であり、SaaSの組織・人も変わるからです。
仮にマニュアル作ったところで、
組織やシステムが変わってもどうせ更新なんてされません。
そうすると、最新じゃない誤った情報のマニュアルが残ることになる。
実際に障害起きた時はみんな余裕なんてないわけで、古いマニュアルを見て頭の中で更新していく余裕なんてない。苦笑
むしろ大切なのは、
-
障害が発生した時に「対応の核となる人たち」を決めておくこと
-
その人たちが「どんな状況でも責任もって対応する」という強いコミットメントを持つこと
だと思っています。
ブラックっぽく言い換えると
「『障害が起きたら、例え映画の途中でも俺（CS責任者）とお前（開発責任者）はslackに反応する』というカタイ約束」
って感じでしょうか。
一言足すなら
「だから、曜日時間帯問わず、障害が疑われる事象は遠慮なく俺にエスカレしろ。」とメンバーにも落としておくと良いと思います。
それさえあれば、大体のことはうまくいくと思っています。
障害に負けるな
「顧客の成功と自分の成功を重ねる」という素敵なコンセプトに惹かれたカスタマーサクセスにとって、障害対応は辛い仕事です。
でも、そこで障害対応から逃げちゃうと、なんとも後味の悪さが残ります。
楽しくはない、辛い仕事なのですが、ぶっちゃけ障害はどの会社に行ってもある程度起きます。
だったら、先に腹を括って攻めて取り組んだ方が、精神衛生上も良い気がします。
