テクニカルソリューションのCSMが考慮すること- 「カスタマーサクセス・プロフェッショナル」 読書メモ

先日発売された、「カスタマーサクセス・プロフェッショナル」を読んでいる。

これまで最前線で実務にあたってきたCSMのノウハウがぎっしり詰まっていて、これまで概念を学びつつ実務の構築に試行錯誤してきたCSMには大変参考になる書籍で、これからカスタマーサクセスの次なる必読書としてリストされていくだろう。

書かれているノウハウはどれも魅力的であるため、読みながら早く実践してみたくてたまらなくなる。 ただし、同時に以下のような感想も抱く。

書籍の訳者あとがきにも、これが一つの実践"例"であってゴールではない、ということが丁寧に念押しされている。

誤解しないでほしい。リアルなストーリーが溢れていることの価値は、事例の数が多ければその中から自社の正解が見つかるから、ではない。では新の価値は何か?それは、自社のカスタマーサクセスの正解は最終的に自分たちで見つけなければならない上で、多様な事例を知るほど、自社の正解を見つけるためのヒントがつまった引き出しが充実するからだ。芸術の世界で例えよう。ソリストとして名を残す音楽家は、まずは優れた先人を真似て楽譜の解釈や表現法を自分の引き出しにためることから始める。しかし「うまく真似る」ことがゴールではない。引き出しの先例を糧に、自分なりの独自の表現法を見出すことが最終ゴールだ。カスタマーサクセスの実践はそれににている。

(「カスタマーサクセス・プロフェッショナル」 p3 訳者まえがき)

このブログでは、カスタマーサクセス・プロフェッショナル 3章〜4章の事例から発想した、自社プロダクトMackerelのカスタマーをどう考えるかという一つのアイディアについて書く。

CSMが対峙する登場人物

CSMがコンタクトを取る対象の例として以下のように書かれている(p105 コラム「カスタマーと連絡を取る際は必ず準備せよ」)

  • 役員クラスの支持者
  • 意思決定者
  • 責任者
  • ヘビーユーザー
  • 管理者

つまり、自社のプロダクトをもってして、カスタマーの成功を導こうと思ったら、導入部署の責任者や現場のコアユーザーだけでなく、ビジネスの意思決定者とも目的に応じてコンタクトを取っていくべきということだ。現場のヘビーユーザーに好まれたとしてもビジネスの意思決定者が首を立てに振らなければ導入はうまく進まないし、もちろんその逆もある。

テクニカルソリューションの導入を意思決定するキーマンは誰か?

Mackerelは、顧客となる企業でプロダクトを開発・運用する技術者が利用するテクニカルソリューションである。技術者が利用するテクニカルソリューションの導入はどのように意思決定されているのだろうか。

私が、複数の企業とコミュニケーションをしたことや、自身が企業に所属した経験から感じていることは、企業に対して、有償のテクニカルソリューションの導入や継続について意思決定の登場人物は非常に多いということだ。自社に技術者が所属して開発を行っている企業では、CTOやVPoEといった技術について責任を持つ役割がビジネスに責任を持つ役割とは別に設けられていることが多い。R&D部門などが自社の技術選択に影響力を持つ場合もある。

つまり、Mackerelでは、登場人物以下のようになる。

必ず全員が登場するわけではない。企業と事業が1:1のような企業では、企業の長と事業の長が同じで、現場と最終的な意思決定者(決決裁者)の距離が非常に近い組織もある。

その企業でどのような意思決定がなされれているのかということはヒアリングによって丁寧にキャッチアップしていく必要がある。

ビジネスのキーマン

  • 役員クラスの支持者
  • 意思決定者(事業責任者、部門長)
  • 責任者(プロダクトマネージャー)

技術選択のキーマン

  • 技術に関する役員クラスの意思決定者(CTO、VPoE)
  • 技術開発・選択を牽引するR&D部門の責任者
  • プロダクトの技術責任者(プロダクトマネージャー、テックリード
  • ヘビーユーザー(技術者)
  • 管理者(技術者)

最終的な意思決定者はビジネスの責任者である場合もあれば、技術に関する責任者である場合もある。もしくは、その両方の承諾を得なければ決裁が通らない場合もある。

トップダウンか、ボトムダウンか、はたまたバランスタイプか

また、テクニカルソリューションに関する意思決定には、もう一つ特徴があると考えている。 (テクニカルソリューションに限らないかもしれない)

その企業がトップダウンの性質を持つか、ボトムアップの性質を持つか、ということである。

たとえば、非常にタレントがあって、影響力の強いCTOやVPoEが明確なビジョンを組織に浸透していくようなスタイルの場合もあれば、開発に携わるチームが自立して技術選択について意思決定できることを重視する組織も存在する。

企業の成長のステージ応じてもそれは様々に変化する。たとえば以下のようなイメージだ。

  • トップとボトムが境がないケース:ベンチャー企業としてスタートしたばかりで、少数のメンバーの密なコミュニケーションによって技術選択が行われている。
  • トップダウンのケース:事業が成長し、メンバーも増えるが、CTOを中心としたコアメンバーによって強いビジョンが示されている。
  • ボトムアップのケース:企業の急成長に伴い、新しいサービスが次々とローンチされ、ビジョンが行き届かず事業やプロダクト毎に技術選択がなされるようになっている。
  • トップダウンボトムアップがバランシングしているケース:CTOを中心としたチームや、R&D部門が技術選択に関して影響力を持ち、ある程度ガバナンスやビジョンを共有した形で各プロダクトに技術選択の権限を委ねていく。

トップダウンの色が強い企業であれば、CTOに自社に有益なプロダクトとして認められれば、導入は比較的スムーズに進むだろうし、ボトムアップの企業では、たとえCTOや事業責任者と信頼関係が築けてビジョンを共有し合うことができたとしても、実際に影響力を持つ現場の技術者に支持されなければそもそも稟議が役職者のもとにあがることがない。

カスタマーサクセスの文脈では、キーマンの退職や入れ替わりはチャーンリスクである、ということはよく言われるが、その企業がどのような意思決定の特性を持っているかによって、テクニカルソリューションの場合は、ビジネスのキーマンだけでなく、技術選択のキーマンとなりうるCTOの入れ替わりも、ヘビーユーザーの技術者の退職も、利用継続を左右する大きなリスクになる。

Mackerelのようなテクニカルソリューションの特性はやはり、先にも述べたようにビジネスのキーマン、技術選択のキーマン、両方の心を掴む必要があるということだろう。

そのため、担当するCSMが持つ専門性も幅広くなくてはならない。ビジネスのキーマンの心を掴む場合と、技術選択のキーマンの心を掴む(信頼を得る)場合では、必要となる専門性やノウハウは異なる。前者はCSMのスキルでもセールスやアカウントマネージャーにつながる専門性であるが、後者は技術者としての専門性が求められる。カスタマーサクセス組織のリソースが潤沢で、それぞれの専門家を採用できている場合は幸運だろうと思うが、一部の大企業を除いて、そこまで専門性の違いを理解した上で、体制や業務範囲が整理できている企業は少ないのではないかと思っている。

まとめ:テクニカルソリューションのCSMが考慮すること

自分が対面している人物がビジネス・技術どちらのキーマンであるかを整理する

もしテクニカルソリューションのCMSを担当している場合、自分が対面している人物が、ビジネス、技術、どちらの意思決定により影響力がある人物なのかを意識してみることをおすすめしたい。また、ケアすべきいずれかのキーマンをないがしろにしていないか、という点も見直してみるとよい。

技術の意思決定フローを含めた顧客企業の理解・ジャーニーマップを作成する

また、ジャーニーマップを作る際も、それぞれのキーマンごとのジャーニーを思い描いてみてはどうだろうか。 ミッションの異なるぞれぞれの意思決定者は異なる価値観に基づいて、自社や自身の成功を思い描いているかもしれない。 もし企業の成功が根本としては、売上の増加、コスト削減などに向かっていたとしても、そこに至る中間指標やロジック、乗り越えるべき自社の課題をどう捉えるかは異なっているだろう。

  • ビジネスのキーマンはいつどのように意思決定するのか。何を自社・自身の成功と捉えているか。
  • 技術選択のキーマンはいつどのように意思決定するのか。何を自社・自身の成功と捉えているか。

カスタマーサクセスをユーザーの行動を変えるという視点から考える - 「行動を変えるデザイン」 読書メモ

背景

ここ1年くらいカスタマーサクセスについて学んだり、実践したりということを行ってきたが、未だにカスタマーサクセスの具体的な活動をうまく設計できていないという課題感がある。失敗しているわけではなく、舞い込んでくるものに全力を尽くしているという感覚で、組み立てられているという感じではない。

カスタマーサクセスの本を読んでいると、カスタマーサクセスという概念の重要性や、KPIの置き方、ミッションの置き方、組織のつくり方、顧客の成功を設計する重要性、顧客について理解する(カスタマーヘルススコアなど)ことの重要性、などについては学べるが、現場で実際にどういう施策を立てて、どう活動するとより効果的かという実務の部分がこれらの書籍からだけではイメージできていない。

そこで、これまではカスタマーサクセスの本にプラスして、ユーザーインタビューや、カスタマージャーニーマップ、マーケティングやセールスなど、業務に関わりそうな本をぺらぺらと眺めては唸っていたのだが、活かせるものは確かにあるものの、何か芯を食ってないような気がしていた。

その模索の一貫で読んだ行動心理学をベースにした本がなかなか参考になった、ということを紹介していこうと思う。

行動を変えるデザイン

この本では行動心理学を応用し、Webサービスなどのプロダクトによってユーザーの行動を変容するためデザインの方法論について書かれている。

行動変容デザインは探索プロセスと呼ばれるサイクルを小さく早く回していくことで改善されていくとされている。不確実性に立ち向かう開発手法や仮説検証の考え方とリンクする。本の中でもアジャイルやリーンを開発手法として選択している現場での実践を念頭に置いて書かれているように思う。それもあってか、実際の現場の様子を想像しながら、本で語られる知見がどう取り入れられるのかをイメージできるので非常にわかりやすい。

ケースや例としてあげられるプロダクトも主にサブスクリプションモデルのBtoCサービスが念頭に置かれていることが多い(もちろんそれ以外の例もある)ので、開発手法や自分が携わるプロダクトの性質が似ている、という人は読みやすいだろう。

探索プロセスは以下のようなものである。キーワードをまとめるので詳しくは本文を参照されたい。

探索プロセス

  • 理解する
    • 意思決定の仕方
    • CREATEアクションファネル
    • 行動変容のための戦略
  • 探索する
    • 成果
    • アクター
    • 行動
  • デザインする
    • ビヘイビアプラン
    • ユーザーストーリー
    • インターフェースデザイン
    • プロダクト
  • 改善する

探索プロセスの「理解する」の箇所では人がどのように意思決定しているのか、その認知メカニズムが行動を変えることにどのように影響するのか、ということが行動心理学に基づき説明されている。その後の「探索する」「デザインする」「改善する」の部分ではそういった行動心理学のエッセンスを活用して、どうプロダクトをデザインし、実装し、改善していくかのプロセスについて事例を交えて説明されている。各所に行動心理学の理論や事例がちりばめられつつも、最終的にはそれをどうプロダクトのデザインに活かすか、という実践の話が徹底して書かれているところがこの本の面白さであり、ためになる部分だと思う。

開発手法の知識に寄りすぎるわけでもないので、非エンジニアの方でも読みやすいのではないだろうか。

補足

カスタマーサクセスを生業とされる方向けに補足すると、この本の中でデザインされるものはユーザーインターフェースなどプロダクト自体の開発・改善なので、対面のコミュニケーションが重要になるハイタッチよりは、テックタッチの施策に参考になる。

ユーザーの声(VoC)をプロダクトの機能改善にどうフィードバックするかといった施策を設計することを担当にされている方にはドンピシャだろう。

また、プロダクト本体の改善以外にも、ヘルプページやFAQ、サポートの改善、スタートガイドやハンズオンなどトレーニング手法の設計など、広義でのプロダクトとユーザーのインターフェースになりうるものには応用できる考え方だと感じた。

ハイタッチがメインの方が、参考にする行動心理学の本としては、以下のような本が役に立つだろう。名著としてよく取り上げられるので読んだことのある方は多そう。

人を動かす 文庫版

人を動かす 文庫版

ターゲットアウトカム(成果)を明確にする

この本は、学びが多く、物理本でしか手に入らないので物理本を読んでいたのだが、付箋だらけになってしまった。

この読書メモとしては、自分が今ここにいるだろうと思われるプロセス「探索する」について、またその中でも「ターゲットアウトカム(成果)を明確にする」ことについてまとめる。

私自身が今いる状況は、以下のようだと想像してほしい。

  • 施策のアイディアや、アイディアの種はたくさんあし、そのどれかを選んで実行してもよいし、実際にいくつか試しているしている。
  • アイディアはユーザーから得られる要望の中にもたくさんあり、これまで蓄積されてきた数百の要望がリストとしてすでに並んでいる。

こういう状況で、よくやってしまうのは、そのアイディアや要望のリストを眺めながら実現可能性と緊急度、最終的には主観からピックアップしたものをとにかく実行してしまうこと。 選んだ施策に対して、指標は置き、計測はする。 そうすると、いちおう一定の成果はあげられるものの、施策が完了してから翻って何が目的だったのか、本当に上位レイヤーのKPIに対して影響のある施策だったのか、仮説が検証されたのかがおぼろげになる。

このままでは、成果をきちんと評価できないし、組織の納得感も得られにくく、協力も受けにくくなってしまうのではないかというのが今の課題感であり、危機感だ。

この本では、ターゲットアウトカムを定義して、そこから施策のデザインにブレイクダウンする流れが紹介されている。また、定めた成果が実施するに値するものかどうかを見極める方法についても書かれている。

ユーザー中心のアプローチ or 企業の中心(company-centric)のアプローチ

この本では主に、ユーザーにフォーカスし、ユーザーのためにプロダクトが何ができるかを考えるという開発プロセスについて語られているが、もう一つの方法として企業中心の目的設定の方法についても語られている。

2つのアプローチの違いは以下のように説明されている。

  • ユーザー中心:プロダクトがユーザーにもたらす利益にフォーカスすることで、結果として自社の収益にもつながらう、というアプローチ
  • 企業中心:プロダクトが自社にもたらす恩恵にフォーカスし、その手段としてユーザーに価値提供する、というアプローチ

企業中心アプローチの場合、プロダクトのビジョンが以下のようになる。

  • このプロダクトによって、自社の魅力を新市場に拡大したい
  • このプロダクトによって、収益を向上させたい
  • このプロダクトによって、自組織が新たなプロジェクトを引きつける専門性や能力があることを示し、新たな資金援助を手に入れたい
  • このプロダクトによって、自社に対する認知度や関心を向上させたい

ユーザー中心アプローチでデザインのコンセプトを構築していく場合に比べて、企業中心アプローチではプロセスが1つ増える。

  • ユーザー中心: プロダクトビジョン → ユーザーにとっての成果 → 行動 → アクター
  • 企業中心:プロダクトビジョン → 経営目標 → ユーザーにとっての成果 → 行動 → アクター

企業中心のアプローチは、プロセスも増えて、ユーザーに向き合っていない、カスタマーサクセスではない方法のようにも見える。 ただ、この本ではたとえプロダクトのビジョンが収益を向上させたい、というような企業中心から始まるアプローチだったとしても、プロダクトはユーザーに価値提供することで対価を得るので、結局はその後のデザインの過程ではユーザーを中心とした行動変容の探索プロセスを踏んでいくことになると説明されている。

ターゲットアウトカムを明確にする際にやることは以下の通り。

  • プロダクトが達成すべき現実世界の成果を定義する。心理状態を目標に置くのは避け、プロダクトの正否を判断できる測定可能な成果にフォーカスする。
  • 自社固有の目標(例えば利益向上)を、ユーザーが本当に関心を持つ現実世界の成果に翻訳する。
  • プロダクトの目指す成果実現のために人々が取りうる行動についてブレインストーミングをして洗い出す。
  • それぞれの行動を実現可能な最小限のアクションにまで削ぎ落とす。

カスタマーサクセスは、どちらかというとまさにユーザー中心のアプローチで、プロダクトのミッションから顧客の成果を定義して、それが達成されるために活動する役割(や考え方)だと解釈できる。

ただ、同時にビジネスマンでもあるわけで、その先には(前には?同時に?)必ずといっていいほど、ビジネスのゴールが控えている。やりたい施策がユーザーに感謝される施策だからといって、それがどうKPIに貢献するのか?というのは常に答えを求められる可能性がある。

この本では、どちらのアプローチをとっていても結局はユーザーの行動変容とユーザーの成果に焦点を当てることになっていて、どちらから始める手法もフラットに方法論が語られているところが、現実に寄り添われていてよい。

陥りそうなこととして以下があげられている。

  • プロダクトの目指す成果について、企業内部で合意できない。
  • 企業自身が求めるものはわかっているが、ユーザーの関心に合致するものを提供できない。

プロセスの前半部分が滞って、ユーザーにとっての関心や成果の話になかなか進めない状況というのは想像がつくし、先にも紹介した自分の危機感、ユーザーの関心や成果について探索ばかりしていて、翻って企業のビジョンにどうフィードバックされているか説明できず、企業の納得感や協力を得にくくなるのでは、というのもまさにここで言われていることの例だろう。

達成したい成果が定まったら、次は成果を達成するためのユーザーのアクションを選択していく。

選択は以下のような流れで行っていく。

適切なターゲットアクションを選択する

  • ターゲットユーザーを調査する
  • 理想的なターゲットアクションを選択する
  • 成功と失敗を定義する

自分の状況が探索プロセスのどこにあたるのか、課題感がケースのどこにあたるのかがわかって、いろいろすっきりした。私は今「探索する」プロセスを試行錯誤しながらいったりきたりしている。この本から得られた知見でプロダクトに合う方法論は少しでも試して、次のステップである「デザインする」「改善する」に足を踏み出したい(地に足のついた形で)。

プロダクトの企画、デザイン、カスタマーサクセスのテックタッチ、マーケターなどなど、ユーザーにどう行動して、どう成果を得てもらいたいかということについて考えたり、取り組んでおられる方にこういった行動心理学をベースとした本を読むことは(ロールによって優先度は変わりそうだが)かなりおすすめしたい。

ためになったエッセンスのリスト

  • プロダクトの正否を判断できる測定可能な成果にフォーカスする。
  • 「ユーザーが満足する」「ユーザーが喜ぶ」といった心理状態を目標に置くのは避ける。(測定が困難だから)
  • 自社固有の経営上の目標をユーザーが関心を持つ現実世界の成果に翻訳する。

日付を指定してMackerelのアラート一覧を取得するスクリプトを書いた

Mackerel Advent Calendar 2020 17日目の記事です。

こんにちは。株式会社はてな MackerelチームでCREをしています。 今回はよくユーザーの方からお問い合わせをいただいていることについて素朴にbashを書いてみたというお話です。

モチベーション

アラートの一覧をCSVなどでダウンロードできませんか?というようなお問い合わせをユーザーの方から受けることが度々あります。 用途としては、直接Mackerelを参照しない上司や、企画・開発チームへ運用チームから定期的にレポートを提出する際に週や月のアラート件数を掲載したい、などの場合です。

それ以外にも様々な状況から最終的に「アラートの一覧をCSVなどでダウンロードしたい」という要望になっているのだろうと想像しますが、たとえば、アラートが多すぎてそれに対する調査や分析をしたいとき、なんだかんだでアラート一覧をスプレッドシートExcelを使ってごにょごにょしたい、ということはありそうだな、と思っています。メモを書いて分類したり、関数やピボットテーブルを使って件数などを調べたり...数分でぱぱっとやりたいということもありそうですよね。

今回はbashでこのケースに答えられるようなスクリプトを書いてみました。 ユースケースは定期的なレポートへの利用を想像していたので、日付を指定してその期間のものだけを取得できるようにしました。

できたものその1:日付を指定してアラート一覧を取得するスクリプト

実際のコード

実際のコードはgistに置いてあります。

get-alerts-list-date-range.sh · GitHub

(同じような処理を2回書いているので、もっとスリム化できるかもしれません...)

長くなってしまったのでここに全行を載せるということはしませんが、かいつまんでポイントになっていそうなところをご紹介していきます。 このスクリプトの中では、Mackerelのアラート一覧を取得するAPIを実行しています。 詳しい仕様はヘルプページに記載があります。 APIを実行している箇所を抜き出すとこのような形です。

MACKEREL_APIKEY=<YOUR_MACKEREL_APIKEY>
LIMIT=100

curl -GsS \
     -X GET \
     -H 'X-Api-Key: '${MACKEREL_APIKEY} \
     -H 'Content-Type: application/json' \
     -d withClosed=true \
     -d limit=${LIMIT} \
     https://api.mackerelio.com/api/v0/alerts

オプションとして指定しているwithClosedlimitはそれぞれ以下のようなものです。

  • withClosed:クローズ済みのアラートも合わせて取得されます。
  • limit:最大で100まで指定できます。一度のAPIリクエストで取得するアラート件数を指定できます。

これをこのまま手元で実行してみても結果が返ります。

{
  "alerts": [
    {
      "monitorId": "3fRvMzJdWgA",
      "hostId": "3y8DxzS6Y6W",
      "id": "42fDeqZZTqL",
      "type": "connectivity",
      "status": "CRITICAL",
      "openedAt": 1599188103
    },
    {
      "monitorId": "3gvaG3eP4cN",
      "id": "42fCW1JANsU",
      "type": "external",
      "message": "net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)",
      "value": null,
      "status": "CRITICAL",
      "openedAt": 1599187945
    }
  ],
  "nextId": "42fyMXWiWK3"
}

結果はJOSN形式で返るので、それをjqコマンドで整形していきます。

整形後の区切り文字はカンマ(CSV)ではなくタブ(TSV)にします。 なぜかというと、messageの値に,が含まれる可能性があるためです。

echo "${JOSN}" | jq -r '.'| jq -r '.alerts[]|[.id,.status,.monitorId,.type,.hostId,.value,.message,.reason,.openedAt,.closedAt] | @tsv'

整形するとこんな感じになります。このスクリプトでは指定した期間内のアラートを以下のようなTSV形式で出力するので、これをファイルなどに書き込めば、スプレッドシートExcelで読み込むことができます。

42fDeqZZTqL  CRITICAL    3fRvMzJdWgA connectivity    3y8DxzS6Y6W             1599188103  
42fCW1JANsU CRITICAL    3gvaG3eP4cN external            net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)        1599187945

100件以上のアラートを取得したいとき(nextIdについて)

上記でもご紹介したとおり、アラート取得APIでは、一度に取得できるアラートが100件までと決まっています。 100件以上のアラートを取得するには、APIの応答に含まれるnextIdをオプション指定して再度APIを実行する必要があります。

nextIdを指定したAPIの実行はこのような形です。

curl -GsS \
       -X GET \
       -H 'X-Api-Key: '${MACKEREL_APIKEY} \
       -H 'Content-Type: application/json' \
       -d withClosed=true \
       -d limit=${LIMIT} \
       -d nextId=${NEXT_ID} \
       https://api.mackerelio.com/api/v0/alerts

100件、200件と遡らないと取得したい期間のアラートがすべて取得できない場合は、取得しきるまでforwhileで繰り返し処理をする必要があります。 スクリプトでは、その処理をwhileで実行しています。

詳しくはスクリプトをご覧ください。

別に日付指定はしなくてよいという場合はmkrコマンドが圧倒的に楽

今回は、日付指定したい場合を想定していたのでbashを書いてみたのですが、日付を指定せず直近xx件のアラート一覧を見たい、という場合であればmkrコマンドを利用するのが圧倒的に楽です。

MackerelにはmkrコマンドというCLIツールがあります。

作業端末や踏み台サーバーなどにインストールしておけば、curlコマンドやスクリプトを書かなくても簡単にAPIと同様の操作を実行することができます。 ただし、mkrコマンドでは一部のAPIは実行することができないので注意が必要です。

mkrで何ができるかを確認するには一度インストールして、mkr --help を見てみるのが手っ取り早いです。

mkrのインストール方法などはヘルプページに記載があります。

mackerel.io

mkrコマンドでアラート一覧を取得するコマンドは以下です。

mkr alerts list -w -l 1000

-wAPIで言うところのwithClosed-llimitに当たります。

見てお気づきかもしれませんが、mkrコマンドでは、limitに100件以上の件数を指定することができます。 コマンド内で繰り返しの処理を行ってまとめて出力してくれるので自分で処理を書く必要がありません。 ここでは1000件取得するコマンド例を記載しています。

他にもオプションによって、取得する対象のサービスを絞ることなどもできます。

実行結果はこのような形です。

42fDeqZZTqL 2020-09-04 11:55:03 CRITICAL  connectivity missasan-wp poweroff [missasan-blog:db,web]
42fCW1JANsU 2020-09-04 11:52:25 CRITICAL  wp-url http://<URL> 0.00 msec, net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)

APIを実行した際にIdで出力されていたホスト名や監視ルール名なども表示されていて、わかりやすいです。

区切り文字がスペースなので、出力結果から列を抜き出したい場合などには少し工夫が必要そうです。

できたものその2:アラート件数をサービスメトリックとして投稿するスクリプト

せっかく一覧が取得できるようになったので、アラートの件数をサービスメトリックとしてMackerelに投げてみるということも試してみました。

作成したスクリプトは以下2つです。

  • get-alerts-list-1day.sh
    • コード:get-alerts-list-1day.sh · GitHub
    • 使用方法:get-alerts-list-1day.sh > /path/to/logfile
    • 実行すること:現在から過去1日分のアラートを取得する
  • post-mackerel-alerts-count.sh

これら2つをcronなどで定期実行すると、get-alerts-list-1day.sh の出力結果をファイルに書き出し、post-mackerel-alerts-count.shでそのファイルを読み込んで件数をサービスメトリックとして投稿する、という処理が動き、こんな感じでアラート数がグラフとして記録されていきます。

cronの記載例はシンプルですが、こんな感じです。

* * * * * /path/to/get-alerts-list-1day.sh > /path/to/logfile
* * * * * /path/to/post-mackerel-alerts-count.sh

あまり稼働しておく時間をとれなかったので平坦なグラフになってしまいましたが、イメージは伝わるかと思います。

f:id:missasan:20201216113639p:plain:w600

過去1日で、チェック監視(check)が226件、ホストメトリック監視が33件のアラートが起票されたことがわかります。

最後に

あらためてポイントをまとめます。

  • APIでアラートを取得するときは、1リクエストにつき最大100件まで
  • nextIdを指定して100件以上のアラートを取得する
  • mkr alertsは便利

以上です。

アドベントカレンダーらしく、日々のちょっとした気になりごとを実際に試してみました。 アラート取得APIでもまだまだいろいろと遊んでみることができそうです。




お知らせ

普段は、Mackerelをこれからはじめる、またははじめたてのユーザーの方々に向けてオンラインセミナーを開催させていただいたりもしています。

強めマッサージ好きが本当にオススメする家で使えるマッサージアイテム

みなさんはマッサージは好きですか?わたしは、大好きです。

マッサージで「強さはいかがいたしますか?」ときかれたら食い気味に「強めで」と答えるくらい好きです。

仕事をしているとたまに、めちゃくちゃ疲れがたまった感じがして、筋肉が緊張して、血流が無みたいになるときがあります。 そういうときは、そもそも体が硬くなるし、運動すると腰を痛めたり、首を痛めたりするので本当に疲れているときは運動する気になれません。

そこまで疲れてしまったときの私の強い味方は、マッサージです。

特に大好きなマッサージのお店は、下北沢にある、アロマヒーリングです。

beauty.hotpepper.jp

このお店には、痩身インドエステ、というメニューがあります。

痩身インドエステで全身を揉みほぐすメニューです!セル脂肪を熟練の手技でグイグイ揉み解す!終わった後のスッキリ感は癖になる。女性限定♪

目的には 痩身 はとありますが、あったまるタイプのベットの上でほかほかになった全身を、屈強な女性スタッフが、足先から頭まで、凝りも駄肉もパンかと思うほどこねくり回して伸ばして流して徹底的にマッサージしてくれます。最後は汗だくになって終わります。

めちゃくちゃ痛いんですが、最終的には強制的に血流が回復されて、よっしゃいっちょ運動でもしてやるか、というところまでコンディションと気力が回復します。 マッサージって相性が悪いと、終わった後「?」ってなること多いのですが、ここのはめちゃくちゃやってやった感を得られます。

しかし、問題は、めちゃくちゃ高額ということです。 誕生日プレゼント並に高額なので庶民の私は本当にたまの本気のご褒美としてしか自分に与えてあげることができません。 この店でなくもう少し価格帯が低くても、マッサージは全体的に結構高くて、都内で安心できるところなら60分6,000円〜が相場ではないでしょうか。

頻繁に行けない、となると、家で自分で何かできるものはないかと考えるようになります。 こういうご時世ですので、家でできるとうれしいことはたくさん。

そこで今日は、強めマッサージ好きが本当にオススメする家で使えるマッサージアイテムを紹介します。

やわこ

  • 筋肉をほぐす系
  • テニスボール2個分
  • ねころがって体の下に置いてぐりぐりする
  • お尻の下や、脇の下、太腿、肩など自分の好みのツボを押せる!

トリガーポイント

  • 棒状
  • 直径:14cm 長さ:33cm
  • この上に寝転がって、太腿やふくらはぎ、腰まわりをグリグリする
  • ツボではなく、全体的に筋肉を圧迫してほぐす
  • やわこより手軽じゃないけど、こっちの方が効く気がしてます

Matty式シリーズ

解毒こぶし

Matty式解毒こぶし

Matty式解毒こぶし

  • 作者:Matty
  • 発売日: 2017/10/02
  • メディア: 単行本

  • Mattyさん(マッサージ師)の拳の形を模したもの
  • これをメリケンサックのように掴んで、肩、首、足、顔とにかくどこでもグリグリする
  • 力をかけずに確実に凝りを捕らえられます
  • ただのプラスチックなので、お風呂場でもどこでもパッと使えます
  • 掌サイズなので場所もとらない

解毒棒

  • Mattyさん(マッサージ師)がリンパを流すときの手の形を模したもの
  • ふくらはぎ、ふともも、二の腕、脇の下、などリンパをながしたいところをざっざっと流すようにマッサージする
  • 摩擦があるのでマッサージオイル的なもの必須です
  • むくみが取れて細くなる
  • ダイエットのお供に
  • 使い方は玄人向け
  • 痛い

YA-MAN 電動頭皮ブラシ

  • お店でうけるようなヘッドマッサージを再現できる
  • 海洋生物っぽいくうようよ動く足で頭皮を揉みほぐす
  • 眼精披露とかにも効くし、頭皮をほぐすと顔のリフトアップにも効くそうです

最後に

  • みなさん作業環境が変わったり、あつ森やり過ぎたり、凝りの多い日々をお過ごしのことと存じます
  • ツールも使いこなして、いい感じにリラックスして過ごしていきたいですね

テックブログカンファレンス に参加してみた

今日は 「テックブログカンファレンス」に参加してきました。

connpass.com

レポートとして自分なりの理解をメモしました。内容や理解が間違っている、というところを見つけた方がおられたらぜひお知らせください。

開催はIIJさんのオフィスへ。 ノベルティにマスクをいただき安心。

今日のテーマ

以下はイベント詳細より。

<テックブログカンファレンス>

技術に関する様々な情報を発信する「テックブログ」

その担当者に「なぜ、テックブログをはじめたのか?」と問えば、いろいろな答えが返ってくるかと思います。自社サービスを知ってもらうため、採用のため、技術に対する純粋な愛...などなど。

そして、そこにはたくさんの悩みがあることでしょう。

どうやって運営すれば良いの?運営体制は?長く続けるコツは?というか、楽しみながら書いてもらう仕組みとか作れないかな...。そんな悩みやテックブログ運営に関するTipsをこのイベントで語り合いませんか。

風穴さん(サイボウズフリーランス編集者)「techブログを続けるために大事にしてること」

speakerdeck.com

  • フリーランス編集者として活動しつつ、サイボウズさんで「コネクト支援チーム」として活動されている
  • コネクト支援チームは
    • 5年後、10年後のエンジニア採用をやりやすくするための活動」をされている
    • チームは4名

blog.cybozu.io

blog.kintone.io

  • ほぼ毎週記事投稿されている。すごい!

techブログのためにやったこと やってないこと

  • SEO / ノルマ管理 / 特別報酬

techブログのために(意識して) やったこと

  • 繋がる / いいね! / Enjoi!
  • 「読みたいドリブン」
    • 社内の人とあって話して、面白いことやってるね、あれいいね、という何らかのリアクションをたくさんされた
    • 宣伝のミッションを持たず、周囲の読みたいという気持ちを書く人のモチベーションに変えている
  • 気軽にブログアップできるように、チェックフローをなくした
    • 不安だったら周りの人にみてもらってくださいね、くらい限りなくハードルを下げた
  • 「編集者とは」

(われらが) 井上さん「サーバー監視サービス・Mackerel のブログ記事ができるまで」

speakerdeck.com

blog.a-know.me

  • 10年以上続けている。すごい!

mackerel.io

  • こんな流れで書いている。
  • 一番難しいのは冒頭の時効の挨拶
  • あとがきも難しい!個性を出せるのすごい。
  • ユーザーの立場に立って有益な情報をちゃんと考える
  • 自分もユーザーであり続ける意識
  • ブログ書いて投稿する作業をトータル1時間でできる。すごい!

荒木さん(アマゾン ウェブ サービス ジャパン)「AWSデベロッパー向けに日本独自の新メディアを始めた理由」

  • AWS はブログのチャンネルがたくさんある。10以上。
  • AWS News Blogは今は70人くらいで書いている(70人!!)
  • 基本的にはみんな独自企画をしてアウトプットしている
  • 日本語訳する主要記事というのは日本では決めていなくて、1週間かかる。待っていられなくて日本のメンバーが先に記事を選別して翻訳している。
  • 日本語の独自ブログもある
  • エンタープライズ、スタートアップ、SMB、Developerまで全部がターゲット

日本向けのことを主体的にやりたい

  • 日本にいて、ブログでしかAWSと接点がない人に向けて書くべきでは、となった
  • オフラインのイベントは接点は一度きり。繋がりを活かすための継続的なコンテンツ戦略を
    • イベント中に15分に1回記事を出した
    • ソーシャルでみられて一時的に盛り上がるだけになってしまった
  • 書きたい人のモチベーションを編集する人が、投稿数を制限するようになった
  • 月間12-13個。クオリティの高いものだけを厳選するメディアを作った

aws.amazon.com

  • AWSに直接関係ないような記事まである
  • でもコンテンツとして品質が高く、継続してみたくなるようなものに厳選されている

堂前さん(インターネットイニシアティブ)「テックブログなんてやるつもりはなかった」

speakerdeck.com

  • IIJさんもたくさんブログがある
  • 今日の話題は2つ
  • 堂前さんはエンジニアから広報部に転身!

techlog.iij.ad.jp

eng-blog.iij.ad.jp

  • 会社ブログはコミュニティと同じ
  • コンテンツはコミュニティの賑わいとニワトリたまご
  • どうやって、このサイクルをまわすか?
    • 自分でかく
  • 頼みこんで書いてもらう。本人に頼む!
    • ただし、なんでもいいからは負担
  • 社内wikiのネタを見つけて、これを書いて、とお願いする
  • ヒット記事が出ると、社内の中でブログが話題になっていく
  • 編集部として何ができるか
    • ネタの発掘
    • 文章・体裁の整理
      • 書式はこだわらない
      • 場合によっては、文章の整理も提案
    • 公開記事の承認
      • 記事公開の責任を書いた人からはがすため
      • 責任を広報部でひきとる
    • 執筆者へのフィードバック
  • 盛り上がってからは、持ち込み記事が出るようになった

佐藤さん(ファインディ)「エンジニア向けにブログを書く上での考え方や信念」

speakerdeck.com

findy-code.io

  • ブログ = 論文
    • 構成がほぼ一緒
    • 教授にフィードバックをもらう視点と似てる
  • ブログも一つのウェブサービス
  • 届けたいユーザーに届いてる?
  • 想定したいユーザーから期待するアクションまで考える
  • 次のアクションを必ず作る
  • そのまま実行できるようにする
    • ブログ内に疑問を残さない
    • 読者として初心者を想定して全部丁寧に書く
  • 人やモノをディスらない、比べすぎない
  • ノウハウ集ではなく、考えや背景をセットで知りたいので、体験談やインタビューなど実情を交える
  • 正確性、公平性、論理性、流行、多少のエモさ
  • 楽しく書く!

佐々木さん(クラスメソッド)「テックブログとCI」

dev.classmethod.jp

  • 成長するためのテックブログ
  • 成長するには学習
  • 学習にはアウトプットがセット
  • その人がその技術について知っていることの印になる(評価)
  • モチベーション / 学習 / アウトプット / 評価
  • ブログを企業のカルチャーとしてうたっている
  • 企業のアイデンティティになっている
  • アクセス数もシェア数も最初は伸びないけどとにかくやり続ける
  • トップダウンで偉い人が率先して書く
  • テックブログは目的ではなく、学習やそのアウトプットが目的
  • アウトプットの内容の間違いは咎めない、アウトプットしたことをまず評価する

感想(明日すぐやってみたいこと

  • チームに編集者ほしすぎる
  • コンテンツをストックして、編集者が厳選する。やってみたい!
    • これまで個人ブログとかに分散しているものも含めたらあらためて自社記事としてコンテンツを組み立てるとかもできるようになる?
  • ブログも一つのウェブサービスという視点で見直ししてみたい!
  • テックブログ、蓄積されたコンテンツ量とか、コンテンツを生み出すコミュニティの成熟度とかによって、どう取り組むかフェーズがありそう

レポートは以上です。

データアーキテクト(データ整備人)を”前向きに”考える会 に参加してみた

今日は 「データアーキテクト(データ整備人)を”前向きに”考える会」に参加してきました。

analytics-and-intelligence.connpass.com

レポートとして自分なりの理解をメモしました。内容や理解が間違っている、というところを見つけた方がおられたらぜひお知らせください。

今日のテーマ

以下はイベント詳細より。

データを整備・抽出・加工したりダッシュボード作ったりとエンジニアとアナリストの間にある「誰かがやらないと別の誰かが困るのに、なぜか誰もやりたがらない役割」であるデータアーキテクト(データ整備人)のスキル・ノウハウ・キャリアなどについて、恨みつらみではなく”前向き”に考えようという会です。

参加者であるわたしの状態

ほぼはじめてデータ分析に関わる勉強会に参加しました。 カスタマーサクセス話題だと10のうち6とか7くらいについてはわかった状態で、残りの特有の話題について新しく知見を得る、という感じですが、データ分析まわりについては10のうち、1とか2とかの理解で、基本的な文脈についても憶測して補いつつ、新しい文脈についても知る、という感じで、なかなか難易度が高かった……

なので今回はレポートという感じではないかも...? 念のため、これを読む方が、余計な情報に触れないように、わたしがどういう人で、どういう視点で聞いた話かを書いておきます。

  • わたしはBtoBのSaaSプロダクトのカスタマーサクセス的立場(職種名はCRE
  • カスタマーサクセス方面の関心でデータを触っている
  • データ分析については初級本を1冊読んだ
  • SQLの本、pandasの本を最近2,3冊必要に応じてペラペラ読んでみている
  • もともとは、SQLは書いたことある。むかしOracleの資格とった。けど、業務で触ったことなかった
  • 最近会社でデータ分析の勉強会なども開催されていていろんな話題に触れつつある
  • チームメンバーと言葉を合わせたい、課題感を共有したい、自走できるレベルを上げたい、というようなモチベーションで参加

登壇者の方々は以下。みなさん資料がしっかりしていて、レポートを書かずとも、資料を見たらよい!という感じでした。すごい…

お話を聞くのに必死でほとんどメモれなかったので以下は資料リンク一式と本当にわたしが気になったぽちぽち書いたキーワートやぼやきだけです…基本的には資料読み込まれることがおすすめ。

本編

しんゆうさん データアーキテクト(データ整備人)の概観とこれからの展望と課題

speakerdeck.com

  • データエンジニアという職種で働いている人は少なくて、多くは何かのエンジニアが兼務している
  • データを集めるところからデータを扱うところまでの間にある仕事=データアーキテクト(データ整備人)
  • データ整備人に向いている人
    • エンジニアは何かを作る人、なので、エンジニアではないけど、エンジニアリングのスキルもゼロではないし
    • 一方、分析の経験がないと利用者とのコミュニケーション、提案が難しくなる
  • 企業がデータを扱い始めたのは2010年代ころ

非分析者・分析者という区分けはじめて聞ききました。 データ整備人は...スキルセットを定義するのが難しそう。 アプリケーションについてもまあまあ知っていて、ビジネスについてもまあまあ知っている必要もあるし、コミュニケーション能力が必要そう(わたしのことでは!? あとは、無料で講演に来てくれるらしい。来て欲しい!!

ゆずたそさん 【永久保存版】3社の事例から学ぶ!現場で使われるダッシュボードの作り方

speakerdeck.com

  • コミュニケーション重要
  • PDCAで何度か微調整を重ねて業務で使われるようにしている
  • 5W1H(データを扱う人や目的)とPDCAが大事
  • botつかって業務の中で自然と必ずPDCAに触れる機会をつくっている(天才では
  • アジェンダPDCAが回る項目を追加している

shinaro iwaiさん データ整備業でぶつかった5つの課題・データ整備人に求められる3つのスキル

speakerdeck.com

  • Google Colaboratory
  • ipynb
  • SQLを再利用可能な状態にしておく。パラメーター変えるだけでSQLわからなくても叩けるようにしておく
    • こういう工夫で営業の人にやってもらえるようにする
    • CREATE TEMP FUNCTION 使って冒頭に書いて修正箇所が見つけやすくする
  • クエリレシピ をまとめている(私もまとめたい。今雑に書いているけどフォーマットつくろうかな
  • データ整備は組織として専任がいるわけではない
  • データを2つの形式にまとめられるのではという仮説を持っている
    • 行動分析
    • ユーザー分析

堀野将晴さん サイエンス視点からのデータアーキテクト

www.slideshare.net

  • データ活用部門が3つ
    • サービスサイド
    • サイエンス
    • データ活用推進する部隊
  • サイエンスのためにデータを使う
  • データ活用とサイエンスの違い
  • コミュニケーションは重要
  • HiveQL

すでにこの時点で知見で頭の中がいっぱいでメモも少なめですみません。また、あとでゆっくり復習しよう......

理解まとめと感想

理解まとめ

  • データエンジニア、アナリティスト、サイエンティストが抱える狭間の課題がある
  • それを解決する人に名前をつけるならデータアーキテクト(データ整備人)
  • この課題を解決するための課題
    • 誰かがやらないといけないけどやる人が決まってない、誰かがまとめてやっている
    • エンジニアスキルもヒューマンスキルも必要な立派な仕事だけど評価する仕組みがない
    • リソースが足りない......etc
  • データが求められる場面
    • サービスや業務のKPI
    • プロダクトサイドの改善
  • データに触る2つのやり方(わたしの理解
    • データ活用ぽいところ
      • 今までいろいろなところにころがっていてすぐに使えなかったデータを使えるようにして集計などを簡単にする
    • データサイエンス
      • サイエンスの力を借りて課題に対して新しい切り口を見出す(これはわたしはまだまだわからない
  • 関連しがちな部署など
    • 事業責任者や企画をしているひと
    • プロダクトを改善したい人
    • 広告収入をあげたい人
    • 日々の自分の業務を改善したい人
  • 本質的にはいろんな人がデータを見てそれぞれのKPIに沿って活用して課題解決できる
    • ただ、KPIの建てつけによって必要なデータや形式は変わる
    • だからデータ整備人は、いろいろなロールの人の意見を聞いて適切に深掘りしたり優先度づけしてデータを整備する必要がある(高スキル!!
  • 大事なこととして言われてたこと改めてまとめ
    • コミュニケーション
    • 5W1HPDCAが意識された業務フロー
    • データを取り扱いやすい形にして自動化、ユーザーが手間なく使えるように
    • データまわりはまだまだあたらしい分野。スキルセットや評価方法を定義するのが難しい(自分がなるかは別として会社のためにやっていきたい

文脈関係なく疑問におもったこと

  • いろんな人からいろんな方面で課題が集まるというコメントが多かったけど、そもそもデータ分析にとってよい課題の立て方、よい問題文の書き方、課題の絞り方ってどうやってやるの
  • データアナリティクスについてかじりたい場合は何からはじめたらいいの。今やってるpandas練習がそれか?

明日すぐやってみたいこと

  • データ活用の 5W1H はすぐ考える!
  • ゆずたそさんの資料見る。

レポートは以上です。 はあ〜〜まだまだレベルアップしないといけないことが山積みですね。

成功企業と最新事例から学ぶカスタマーサクセス最前線 に参加してみた

今日は 「成功企業と最新事例から学ぶカスタマーサクセス最前線」に参加してきました。

asobica.connpass.com

レポートとして自分なりの理解をメモしました。内容や理解が間違っている、というところを見つけた方がおられたらぜひお知らせください。

今日はVOYAGEさんのオフィスへ。めちゃくちゃおしゃれ。 最初に案内されたバーコーナー?のようなところでいただいた空腹でのコーラ最高に美味しかったです。

今日のテーマ

以下はイベント詳細より。

昨今、SaaSサブスクリプション事業者を中心に多くの企業がカスタマーサクセスに注力していますが、目まぐるしく変化する日々の中で最新の手法・ツールに対応できている企業はほんの一握りではないでしょうか。「興味はあるが何から始めたら良いのかが分からない」「立ち上げてみたものの思うように成果が上がらない」といった声が多く聞かれます。

セミナーでは、カスタマーサクセスで成果を出すために必要なことを、最新事例を用いてご紹介します。

第1部では、業界初となるカスタマーサポート特化型AI「KARAKURI(カラクリ)chatbot」を運営するカラクリ株式会社取締役の麹池氏が、カスタマーサクセスにおける効果的な手法について最新事例を交えてご紹介します。 また、freee社をはじめとした多くの成長企業が導入する、顧客成長プラットホーム「coorum」を運営する株式会社Asobica代表の今田氏が、カスタマーサクセスの本質や効果的な運用方法などをご紹介します。 第2部では、Eightコミュニティマネージャーの小父内氏をモデレーターとし、カスタマーサクセスの最前線でご活躍中の、株式会社ABEJAの丸田氏、Sansan株式会社の山田氏にご登壇いただき、カスタマーサクセスにおける工夫や現在の取り組みに関して色々お聞きする予定です。

ラクリ 麹池さん エンタープライズ向けSaaSを成功に導くスクラムCS

サクセスが何かを定義

karakuri.ai

  • カスタマーサポート特化型のAIチャットボットSaaSのカラクリさん。
  • 麹池さんはコンサルティングのバックグラウンドからカラクリのセールスのリードに従事しつつ、カスタマーサクセスの採用に取り組んでおられるとのこと。
  • エンタープライズ向けだと、
  • サービスの成長に伴い問い合わせ数も伸びるけれども、オペレーターのキャパシティは伸びないということがある
  • 例えば
    • ユーザー数が増えていても、1ヶ月でチャーンしているユーザーも......
    • 解約理由はログインがうまくいかないという初歩的なもの......
  • こういった課題を解決できるとチャーンを回避して、サービスもさらに成長できる
  • サクセスロードマップをはじめにつくる
  • 経営目標まで書いていただいているとのこと
  • 何ヶ月目までにどのような状態になっていたいかをコミットされている
  • 事業KPIや現場のKPIにまで落としこんで、目線を合わせる

データ分析

  • データオリエンティッドで改善していく
  • 提供するサービスの中で、KPIに関わるデータを測定できるようになっているとのこと。(これはすごい。便利

### 三位一体 -> スクラム

  • エンタープライズならではのカスタマイズ要件の高さ
  • お客さまも優先度づけができていない
  • サクセスロードマップにしたがってスクラムで開発していく
  • 三位一体のチーム
    • アカウントエグゼクティブ
    • CXD
    • エンジニア(Web/AI)
  • SMB向けだとここまでできないけれども、エンタープライズ向けであれば担当エンジニアを立てられる

質問

  • KPG・KPIを立ててないユーザーもいると思うけどどうするの
    • ワークショップで一緒につくる
    • ある程度イメージがある場合は素案を作る場合もある
  • 課題をどうやって見つけるの
    • お客さまが認識している課題を聞いたあとにも、実はこういうことがないですか?ということを聞いている

Asobica 今田さん "Core fan heal everything" コアファンは全てを癒す

coorum.jp

エンゲージメント向上を実現するユーザーコミュニティ構築サービス coorum
  • カスタマーサクセスに関するよくある間違い(4つあったけどまとめきれなかった......
    • 顧客の規模でサポートを変える
      • 規模が大きい、単価が高い場合にハイタッチにしようというのはちょっと違う
      • 成熟度で変えましょう
      • NPSも成熟度取得タイミングをもうけましょう
        • すると成熟度、打ち手に対するNPSがわかり、課題を洗い出す事ができる

  • セルフサービス=不親切?
    • そもそも問い合わせをしないユーザーの方がNPSが低い

  • コアファンは
    • 事例になってくれる
    • SNSで情報を提供してくれる
    • ユーザー同士のコミュティも支えてくれる
    • 製品へのフィードバックや改善もしてくれる

パネルディスカッション Sansan 山田さん × ABEJA 丸田さん × Eight 小父内さん

bizzine.jp

青本の著者の方との対談記事とのこと!

山田さんは、BIz/Zineでカスタマーサクセスのノウハウ記事を連載中。

bizzine.jp

こちらですね。

丸田さんは、人事コンサルティングのバックグラウンドが。 カスタマーサクセスは結局組織変革みたいなところに落ちていく。 AIは武器。それで強い敵を倒しにいく。そういう仕方で組織を変えていけると考えておられるとのこと。

connpass.com

丸田さんが、やっておられるCSカレッジというコミュニティはこちら。

www.slideshare.net

このスライドも印象深いですよね。

小父内さんは工事現場で働きつつ、ラッパーをしていたバックグラウンド。 ラップとCSは相性いいのでしょうか。

SanSanに入社され、今はEightでコミュニティマネージャーをされているとのこと。

ここからはパネルディスカッション。気になったキーワードをピックアップしていきます。

トークテーマ① CSの立ち上げ

  • 最初は契約しているIDがすべて使われているかどうかがもっとも重要なチャーン指標になっている(山田さん
  • 製品とお客さまの理想にギャップがあるときそれを埋めに行くのがカスタマーサクセス(丸田さん
    • それが、お客さまのリテラシーの問題なのか。それとも製品の問題なのか。
    • 洗剤を作っても、洗濯機を持ってなかったら使ってもらえない。洗濯機をもっていってあげるようなブリッジをCSがやらなければならない
  • まずはコスト削減からやろう(山田さん
    • チャーン削減、NetRevenueとかを目標にすると、目に見えるのに年単位でかかるのでやっている人のモチベが上がりにくい
    • 日々発生している、お客さまの工数を削減するように働きかける
    • お客さまのサイクルが年単位で回っているので、効果が見えてくるのも年単位
      • 1年まわさないと去年こうだったからこうしてみよう、という話がやっとできてくる

トークタイム② 他部署との連携

  • CSは板挟みになりがち??
  • 営業とCSでKPIを交換したりシェアしたりしている(丸田さん
  • 一番困るのはセールスとの連携だと思う。アドバイスできるとしたら、SanSanはクロージングブックというのを作っている。(山田さん
    • 最初のCSのタッチポイントで「クロージングブックは読みましたか?今後はこれに基づいて支援していきますね」というところから会話をはじめる
  • CSのチームは顧客の規模で分けている(山田さん

トークテーマ③ CSの"これから"

聴き入ってしまいました。

KPIについて

山田さん

  • チャーンの金額を持っている。営業と折半している。営業の動きによってチャーンが回避されたりすることもある
    • 折半=責任を共有している
  • オンボーディングの成功率を持っている
  • ヘルススコア。これは最初の2つよりは少し重要度は低め
  • オンボーディングの定義は、かなりCSのチームによって個別化する
    • 期間と定義をまずはきめましょう
    • SanSanならすべてのユーザーがログインして、一度でも名刺を取り込んでいること

丸田さん

  • チャーンレート。アップセルの金額の2つ。を見ている。

質問

  • (質問)チャーンを防ぐ施策は?
    • お客さまとの期待値コントロールを。Why、What、Howが大事。Howの部分、成功までのロードをCSを作成して提供する。(丸田さん
    • 資料はマーケがつくっている。それがよい(山田さん
  • (質問)
    • 最初は人を増やしてよい。でも10人ほどで臨界点がくる。それと平行してテクノロジーの基盤を用意しておくと立ち上がりが早い(山田さん
    • 人が足りなかった。コミュニティを作ったら、お客さま同士でサクセスされる仕組みがワークしていった(丸田さん
    • 少人数で成功できるのがコミュニティのよさ。ハイタッチで得たノウハウをコミュニティに活かす(小父内さん

感想(明日すぐやってみたいこと

  • 今やっているカスタマーサクセスジャーニーマップ。実際に利用してくださるユーザーレベルでのものになっているけど、エンタープライズに使っていただくには、KPG / KPI まで見えるように作っていかないとな......これがめっさ難しい
  • まずはユーザー/自分たちのコスト削減をCS目線でやる という切り口は自分のチームでも考えやすいかもなあ。考えてみたい

レポートは以上です。