Mackerel CREチーム ディレクターが育休復帰3ヶ月でやったこと

Mackerel Advent Calendar 2024 2日目の記事です。

こんにちは。Mackerel CREチームのディレクターをしている id:missasanです。 ちょうど昨年のこの日は土曜日で、週明けからは産休前に有給をつかって一週間ほど前倒してお休みすることになっていました。前日の12月1日まででかいお腹でオンラインの商談に出たりしていて、今改めてカレンダーを眺めるとあの体調でこれやってたのだいぶ気合入ってたな、と我ながら感心してしまいます。あれから一年経つのかと思うととても感慨深いです。生まれた子どもも、もうすぐ1歳です。

そして今は無事復帰して再び働いているのですが、ここでは2024年9月に職場復帰してから11月までの3ヶ月でどんな仕事をしていたのかを振り返ってみます。 各社さまざまな活動をしているCREの、さらにディレクターということで少しばかりレアな職業ですが、ちょっと覗き見してやろうくらいの気持ちでお読み下さい。

9月：10周年記念イベント（Mackerel Tech Day）プロジェクト

復帰してはじめに取り組んだのは10月22日に開催されたMackerelのオフラインイベントでした。 復帰直前の上司との1on1でも何から始めましょうか、というのは相談していて、運営メンバーが大変そうだからまずは手伝ってほしいということでこのプロジェクトに入りました。

www.youtube.com Mackerel Tech Dayの様子はYoutubeのアーカイブも公開しているので、ぜひ年末年始、帰省の移動中のお供などに聞いてみてください。

CREのメンバーがコアの運営メンバーとして動いていて、イベントの企画から関連するコンテンツの制作、集客までさまざま担当していました。 私は、企画やタスクの交通整理や、細かく発生する意思決定の後押しなどをしていました。

イベント当日は、X投稿担当をしていました。

イベントの盛り上げ記事として、CREメンバーで座談会をしたブログ記事も出しました。 運営に参加するメンバーの思いがたくさん聞けたいい機会でした。

mackerel.io

次はランチタイムのオンラインイベントやるよ

connpassを公開していないので、詳細がまだお伝えできないのですが、12月半ばにオンラインイベントを企画しています。 Mackerel Tech Dayで登壇予定だったのが体調不良で不参加になってしまったプロデューサーのid:wtatsuruと、その代打として急遽登壇をまかされたTLのid:ne-sachirouとMackerel Tech Dayを振り返る会をやります。ランチタイムにながら聞きできるものになる予定です。

10月：Mackerelの価格改定に伴う契約見直しのプロジェクト

Mackerelでは、11月1日におおきな価格改定がありました。

mackerel.io

イベントのお手伝いが落ち着いた後は、11月1日の価格改定にむけて、既存のお客さまにご提供している特別契約の見直しを行うプロジェクトにフォローとして入りました。 もともとこのプロジェクトは、開発、ビジネス、CREのメンバーが集まって進められていたのですが、いよいよ11月1日が迫ってきてスピード感を出したいということもあり、私も参加してまたも交通整理やお客さまへのご連絡を一部巻き取ったりしてお手伝いしていました。お客さまにもご協力いただき、無事に11月1日を迎えることができました。

11月：新規機能開発に関わるさまざまなプロジェクト

11月に入り、価格改定の作業も落ち着いてきた頃、今度は新機能開発に伴うあれこれに着手し始めました。 もともと、これこそが今期の最優先トピックでもあったのですが、イベントや価格改定があり、復帰2ヶ月経ってやっと本腰を入れ始められたというところです。

Mackerel Tech Dayでも触れていたのですが、現在MackerelはAPM機能の企画開発に取り組んでいます。 最近のOpenTelemetryへの対応やVaxilaの利用開始なども含めた、オブザーバビリティプラットフォームを目指すという、この規模の大きい意思決定は、私が入社してからだと、2019年のmackerel-container-agentの開発とそれに伴うマイクロホスト概念の誕生、同じ年の機械学習によるロール内異常検知などが思いあたります。 当時も、Mackerelの新しいコンセプトの理解、機能の理解、お客さまに説明するための資料作成、機能のβ版利用に向けた申込み方法の整備など、やることがたくさんあったことを覚えています。

mackerel.io

Mackerelが大きく変化するとき、それをお客さまに伝えていくCREの仕事も大きく変化したりミッションが変わったりします。ようは「出番が増える」ことになります。これが個人的にはとてもワクワクします。復帰していきなりこの状況に身を置けるのは幸せなことです。

実際に手をつけているのは以下のようなことです。

KPIや活動方針の見直し

新機能開発は不確実がことが多いです。特にお客さまとやりとりするCREは、不確実ながらも先を見据えて進む必要があります。まずは今期、とにかく先に進むための軸になるようなKPIや活動方針を整理しました。すでに復帰前に設定された目標はありましたが、あらためて精緻化したりどう解釈して進めるのかをメンバーと話し合ったりしました。

ユーザーインタビューの企画

不確実なことが多いですが、それをただ待つだけじゃなく、開発チームと一緒に解像度を上げていく仕事もしています。

プロダクト企画の詳細を詰めるためには、実際にお客さまの声を聞いて、解決したい課題がなんなのかを分析していく必要があります。 インタビューはPdMがメインとなって進めますが、ペルソナを精査してインタビュー先を検討したり、インタビュー項目を作成したり、お客さまに実際にインタビューをお願いするところはCREも入って進めています。プロダクトとお客さまの橋渡しであるCREならではの仕事です。

Mackerel オブザーバビリティホワイトペーパーをつくる

というお題目でプロジェクトを進めていますが、アウトプットがほんとうにホワイトペーパーの体裁を取るのかはまだわかりません。 プロダクト企画の中ででてきたメッセージングなどを拾って、お客さまに届きやすい形に再構成するというところをCREが旗を振りながら進めています。 ホワイトペーパーにするならこれを書きたい、という項目を出し、足りないところはプロデューサー、PdM、開発者などにヒアリングしながら内容を埋めていっています。 これが最終的には、CREやフィールドセールスがお客さまにMackerelが考えるオブザーバビリティや、MackerelがつくるAPMがどういうものなのかを説明するためのひとつのベースになっていくと考えています。

APMに関する利用実態調査アンケートの企画

企業のAPMに関する課題や期待を調査するためのアンケートを準備しています。ここで得られた情報はよりよいプロダクト開発やサービス改善に活かしていく予定です。こちらも近日中に公開予定なので、もしお手元にアンケートのお願いが届いた際はご協力をいただけるとうれしいです。

Mackerel APMの「ちょうどいい」を定義しよう

MackerelはいわばAPMの分野においては後発隊です。今から開発してAPMに期待されるすべての機能を揃えていくにはそれなりの時間がかかると予想されます。なので、今のMackerelやMackerelのお客様にとっての「ちょうどいい」ものとはどういうものなのか、というのをみんなで考えていくという少し抽象度の高い活動を、直近開発する具体的な機能の企画と並行して行っています。これもPdMの id:RyuGoo と一緒に、ワークショップの企画などを進めています。チームで丁寧に対話を進めながら抽象的な概念に共通の像を結んでいくような、チームビルディングとしての役割もある活動になると思っています。

おわかりでしょうか。CREは普段お客さまをサポートする仕事、と思われることも多いですが、このようにPdMの仕事を一部担うようなことも、お客さまとのやりとりと並行して、ばりばり行っています。 特に新機能が開発されるシーンでは際立ってその傾向が顕著になります。

結局、何をしていたのか？

こうして振り返ってみて、結局自分はこの3ヶ月CREチームのディレクターとしてどういう役割を担っていたのか？ということを考えてみました。

まず感じたのは、私の仕事は概ね「交通整理」と「考える仕事」に集中しているな、ということです。そしてこれは、だいぶうまくいっている状態だと思っています。

産休に入る前は、ディレクターと言いながら、かなり現場仕事にも手を出しつつ、一緒に走ってくれるメンバーのすぐ横にびったりひっついて伴走する、みたいな動きをしていました。というかしてしまっていました。「してしまっていた」というニュアンス通り、これはあまりよくなかったと思っていて、思いつつ改善できずに苦しんでいたところでした。マネージャーが現場から手を離せられないという典型例だったと思うし、手伝っているようでメンバーの自由を奪う足かせにもなっていたんじゃないかと思っています。今もそのけが完全になくなったとは言えませんが、それでも、前よりかは改善しているんじゃないだろうかと思います。

それにはやはり産育休で無理やり仕事を剥がされたというのが大きくて、もしかすると私の思いで無理に形を変えることになっていたかもしれないものが、メンバーが動きたいように動いた結果おさまりのよい形になったような部分が少なからずあるんじゃないかと思っています。 今はその形を大事にしつつ、チームのために自分こそがやったほうが良いことを見つけたり、進めるたりというのをなるべく意識してやっていきたいです。

結果、今私には、関係者が多かったりタスクが複雑なプロジェクトの「交通整理」をしてまたメンバーに戻す仕事や、目に見える成果より、目に見えなかったり、長期的な効果があるようなことを「考える仕事」が残ったし、これをやるべきなんだな、と最近は思っています。

ちなみに、以前自分の記事で書いた図でこんなものがあります。この中のtoBの部分がMackerelのCREの主な仕事です。CREチームのディレクターである自分は今ここを全然やっていません。 通常の業務として設計されて、チームメンバーがごりごり進めてくれています。それによって私はほんとうに上に書いた2つに集中できています。チームメンバーに感謝でいっぱいです。

https://developer.hatenastaff.com/entry/2020/10/30/093000 より

この図を書いたのもだいぶ前になってしまったので、今は変わってきていることがないかなども考えたいですね。

CREは仲間を探しています

最後つい、宣伝で締めたくなってしまうのですが、CREは仲間になってくれる人を探しています。 APMの利用経験があったり、オブザーバビリティに関心がある方とお話したいです。 気になった人はぜひお声がけください。XのDMも歓迎です。

hatena.co.jp

明日の Mackerel Advent Calendar 2024 は同じくCREの id:do-su-0805 の記事です。お楽しみに。

terraform-provider-mackerel で既存環境をimportするときのTips

Mackerel

この記事では、terraform-provider-mackerel で既存環境をはじめてimportするときに気になりそうな、ささやかなTipsをまとめます。 importについては、Terraformに慣れない人でもぱっと試せるように簡単な手順も記載します。

terraform-provider-mackerel とは？

Terraform Registry に Mackerel 用の Terraform Provider を公開されています。 これを利用するとMackerelのWebコンソールの設定をIaC化することができます。

mackerel.io

実際の Terraform Registry はこちらです。

既存環境をIaCに移行するにはimportを使う

おそらく、既存の設定を持っている人がほとんどだと思うので、ここでは既存環境をIaCに移行することを想定したTipsを書いていきます。 既存環境の移行には、基本的にはimportを使っていくことになります。

importの流れ

terraformの設定を書いていくディレクトリと、main.tfを作成します。

> mkdir terraform-mackerel-settings
> touch main.tf

main.tfに以下のようにterraform、terraform-provider-mackerelのバージョンを記載します。

terraform {
  required_version = ">= 1.1.0"

  required_providers {
    mackerel = {
      source  = "mackerelio-labs/mackerel"
      version = ">= 0.0.1"
    }
  }
}

importコマンドを実行します。 監視ルールの例を記載します。

> terraform import mackerel_monitor.connectivity <monitorId>

一回目は以下のようにエラーが出力されます。

Error: resource address "mackerel_monitor.connectivity" does not exist in the configuration.

Before importing this resource, please create its configuration in the root module. For example:

resource "mackerel_monitor" "connectivity" {
  # (resource arguments)
}

exampleに従って、main.tfに以下のように空のresourceを追記します。

resource "mackerel_monitor" "connectivity" {
  # (resource arguments)
}

再度importを実行します。

❯ terraform import mackerel_monitor.connectivity <monitorId>
mackerel_monitor.connectivity: Importing from ID "<monitorId>"...
mackerel_monitor.connectivity: Import prepared!
  Prepared mackerel_monitor for import
mackerel_monitor.connectivity: Refreshing state... [id=<monitorId>]

Import successful!

The resources that were imported are shown above. These resources are now in
your Terraform state and will henceforth be managed by Terraform.

terraform state showコマンドを実行すると設定の中身が見られるので、それを参考にmain.tfに設定を追記します。

❯ terraform state show mackerel_monitor.connectivity
# mackerel_monitor.connectivity:
resource "mackerel_monitor" "connectivity" {
    is_mute               = false
    name                  = "connectivity"
    notification_interval = 0

    connectivity {
        exclude_scopes = []
        scopes         = []
    }
}

terraform planを実行し、差分がなければimport成功です。

❯ terraform plan                           
mackerel_monitor.connectivity: Refreshing state... [id=<monitorId>]

No changes. Your infrastructure matches the configuration.

Terraform has compared your real infrastructure against your configuration and found no
differences, so no changes are needed.

Idの取得方法

importの実行にはMackerelの設定に払いだされている各種Idが必要になります。

各種IdはMackerelの公開APIを利用すると取得することができます。 例えば、監視ルールのIdを取得したい場合は以下のようにcurlなどを実行します。

> curl -GsS \
     -X GET \
     -H 'X-Api-Key: '<YOUR_MACKEREL_APIKEY> \
     -H 'Content-Type: application/json' \
     https://api.mackerelio.com/api/v0/monitors | jq '.monitors[] | [.name,.id]'

取得したIdをimportコマンドに渡してあげれば実行することができます。

> terraform import mackerel_monitor.example <monitorId>

その他必要なId類は以下APIで取得できます。

terrafomerを使うこともできる

社内でつくったという話は聞いてないし、terraformerないだろうなと思いながら念の為探したらありました。 見ると、Mackerelユーザーの方がつくってくださったようです。ありがたい！

これを利用すると、tfファイルなどが生成されますし、もしそのまま使わないとしてもAPIで一つずつIdを集めてくるという手間が不要になるので、だいぶ楽ができそうです。

github.com

通知グループでチェック監視の通知先振り分けを行っている場合の注意

通知グループでチェック監視を通知対象として指定している場合、設定チェック監視のIdを指定する必要があります。 既存環境の移行の場合は、通知グループのimportを行うと現在指定されているチェック監視のIdは設定に含まれるので困ることはありません。

ですのでこれは、IaCでの運用が始まって新しいチェック監視を通知グループに指定したい場合などのTipsです。

チェック監視はその他の監視ルールと違い、監視ルールの一覧APIの結果には含まれません。

チェック監視のIdは、監視ステータスの一覧API で取得することができます。 このAPIは該当のチェック監視が設定されたホストIdを指定して実行することができます。

curl -GsS \
     -X GET \
     -H 'X-Api-Key: '<YOUR_MACKEREL_APIKEY> \
     -H 'Content-Type: application/json' \
     https://api.mackerelio.com/api/v0/hosts/<hostId>/monitored-statuses | jq '.monitoredStatuses[] | select(.detail.type == "check")'

（ただし、結果にはチェック監視名が表示されませんので、messageの内容で識別するなど工夫が必要です。残念ながらmonitorIdを指定して、チェック監視名を取得するAPIなどは現在用意されていません。）

サービス・ロールをIaCにする際は注意が必要

サービス・ロールは、Webコンソール以外にもmackerel-agent.conf上でも以下のように指定することができます。

roles = [ "My-Service:app", "Another-Service:db" ]

mackerel.io

オートスケールする環境など、頻繁にイメージからサーバーを作り直す環境などでは、こうした指定を行っている場合もあります。 この状態で、Webコンソールの設定をIaCにしてしまうと、mackerel-agent.confを修正した場合に、設定に差分が出てしまう場合があります。 Webコンソール以外でもサービス・ロールを管理している場合は、無理にIaC化をしないことも選択の一つです。

チェック監視同様、設定がサーバー上にある類のものは、IaC化が難易度が高い部分です。 IaC化を優先するのであれば、なるべくサーバー上に設定を持たない工夫が必要になります。

以上です。 Terraformの玄人の方や、Mackerelの設定を含めバリバリIaC化されている方はもっと有益なTipsをお持ちだと思うので、ヒアリングできる機会があればそういった情報もシェアしていければよいなと思います。

参考にしたもの

自分がTerraformまだまだなのでいつも雰囲気でHandson環境つくったりしてましたが、あらためて前から積んでいた以下の書籍読んでいろいろ理解が深まりました。

実践Terraform　AWSにおけるシステム設計とベストプラクティス (技術の泉シリーズ（NextPublishing）)

実践Terraform　AWSにおけるシステム設計とベストプラクティス (技術の泉シリーズ（NextPublishing）)

Amazon

よいNPSの活用方法について学ぶ

カスタマーサクセス

自社プロダクトでNPSを取得しはじめて随分経つが、まだまだ正しく活用できていると言えない。 送付方法やスコアの結果ごとにプレイブックを作成するなど、実践的な方法が書かれているブログ記事を紹介する。

www.useriq.com

NPSの送付方法

  • NPSの調査　メールの場合の返答率は 5〜15%
  • アプリケーション内展開の場合は 60%以上 （ほんとうに？）

NPSを依頼するタイミング

  • ワオモーメントの直後
  • 電話でのフォローアップがうまくいった後
  • オンボーディングの最終ステップとして

以下が目的となっていない場合、調査を行うのが最善の方法かどうかを再度検討しよう。

  • わからないことを明らかにするため
  • 仮説を検証するため
  • 受信者に自分の信念を再確認してもらうため

NPSデータの使用方法

DETRACTORS: 0-6

まだ解約していないが、これから解約する可能性のある顧客。

  • NPSに残した自由形式のコメントと、最近のアカウントアクティビティを確認する
  • フォローアップミーティングをスケジュールして、次のステップと最善の行動プランを決定する
  • カスタマーヘルススコアを監視し、状況が修正されていることを確認するために緊密に連絡を取り合う

PASSIVES: 7-8

Detractorに対するように前のめりになりすぎないように注意。適切な対応を行っていれば自然とPromoterに移行する。

  • 満たされていないニーズを明らかにする。フィードバックを求め、長期的な目標をよりよくサポートする方法を学ぶ
  • ニーズに対応する。
  • アドボカシーに向けて。ニーズを満たすことでPromoterに変化することをカスタマーヘルススコアから観測する

PROMOTERS: 9-10

DetractorやPaasiveのほど注意を払う必要はない。アドボカシーを高める対象が誰かを明らかにするとよい。

以下のような方法でプラットフォームを提供する。

学び：次に何をする？

これを読むと次のステップとして必要そうなことは以下だなと思った。

  • NPSの送付方法を見直す
  • NPSを送付するタイミングを考える（何を仮説検証したいかを明らかにする）
  • 結果ごとにどういうアプローチをするかプレイブックを作成し、運用に落とし込む

Product Led Growth を実現するための5つの要点

カスタマーサクセス

昨日の記事でまとめきれなかったので引き続き OpenView の Product Led Growth についてのブログ記事を紹介する。

昨日の記事はこちら。

missasan.hatenablog.com

紹介する記事はこちら。

openviewpartners.com

Product Led Growth を実現するには、いくつかの要点があるとのことで、ブログから気になった点をピックアップした。

  • デザインだけでなくエンドユーザーのペインを解決する設計が重要
    • 今やデザインは差別化要因からテーブルステークス（最低限必要なもの）に格下げされた
    • 成功するソフトウェア製品は、主要なベルソナとペインに合わせて調整されている
      • エンドユーザーペイン：煩わしいタスクを自動化または簡素化したい
      • エクゼクティブペイン：パフォーマンスの低いKPIを改善することでROIを向上させたい
  • ユーザーが住んでいる場所にプロダクトを配布する
    • エンドユーザーにプロダクトを配布するとき、彼らをビジネスマンとして考えるのではなく、たまたま仕事をしている一消費者として考えること
    • 営業担当はSalesforceに、オンラインでものを売る人はShopifyに、知識労働者はChromeかSlackに住んでいる
    • Chromeに住んでいるならChromeウェブストアから、SlackならSlack AppDirectory、スマホならAppStoreから配布する
  • 簡単に始められるようにする
    • セルフサービスのサインアップとオンボーディング
    • 人間を介す（NG）
      • デモリクエスト、セールスとの会話、契約手続き、オーダーフォームなど
    • 人間を介さない
  • 支払い情報の登録の前に価値を提供する
    • アハモーメント（ユーザーの苦痛を解決する最初の瞬間）は購入以前に
    • それ以前に購入処理を入れるとコンバージョン率は低下する
  • 最後にセールスを雇う（適切なタイミングで雇えということ？）
    • 今、最初に必要なのはサポート。自動化できないものやコミュニティに任せることができないものについてエンドユーザーを支援する
    • 製品自体は使用量の増加、バイラルループ、コラボレーション、口コミを通じて拡大を促進する。利用が個人からチームに拡大するにつれ、新しいユースケース、統合を経て請求書払いのチームアカウントへの切り替えについて支援が必要になる
    • 製品の新機能やリリースを最大限に活用できるよう積極的に支援する必要があるため、サクセスチームを雇うのに最適な時期がくる。サクセスチームが拡大に貢献し、製品が価格とコストで問題になるようになる
    • 最終的には、予算の承認、エグゼクティブスポンサー、調達、法務などともやりとりする必要が出てくる。ここがセールスチームを雇う絶好の機会

このような感じでこの記事は、基本的な要点がおさえられつつ、SlackやSalesforceなど馴染み深いプロダクトが各所に例として挙げられていて非常にわかりやすいのでPLGについてとりあえず読む記事としておすすめ。

Product Led Growth 〜 エンドユーザーがソフトウェア購入の意思決定者となる時代

カスタマーサクセス

Product Led Growth という言葉を耳にすることが増えた。

少し調べてみたところ、OpenViewというアメリカのベンチャーキャピタルが提唱した概念ということがわかったので、OpenView の blog に公開されていた基本概念について書かれた記事をいくつか読んでみた。

openviewpartners.com

Product led growth とは

Product led growth is an end user-focused growth model that relies on the product itself as the primary driver of customer acquisition, conversion and expansion.

Product led growth とは、エンドユーザーを中心とした成長モデルであり、顧客の獲得、コンバージョン、拡大の主な原動力として製品そのものに頼ることです。

「エンドユーザーを中心とした成長モデル」なのが Product led growth らしいが、これだけだと少しわかりにくい。

ソフトウェアの歴史 〜 CIO Era、Exec Era、End User Era の3つの時代

次の記事にかかれていた3つの時代の変遷を読むと、どのようにしてソフトウェア購入の意思決定がエンドユーザー主導に移り変わってきたのかがイメージしやすいので紹介する。

openviewpartners.com

  • CIO Era
    • 物理センターに物理サーバーが導入されていた。モノリス
    • 非常に高価
    • CIOが気にするのはITの互換性。既存の環境で動作するかどうか
    • フィールドセールスがCIOを豪華なステーキディナーに連れて行く
    • “sales-led growth”
  • Exec Era
    • 2000年代に始まった
    • 仮想化技術の台頭。シングルインスタンス、マルチテナント
    • 高価なソフトウェアを購入する必要はなく、安価に借りることができるようになった
    • 技術者以外のエグゼクティブが新しい購入者となった
    • 意思決定の基準はROIとKPI
    • “marketing-led growth”
  • End User Era
    • 今ここにきている
    • インフラは弾力性（Elastic）を持ち柔軟に拡張できる。開発者はAPIやモジュラーツールを活用できる
    • 製品はこれまでになく安価（通常は無料）
    • ソフトウェアの購入はエンドユーザーにまで民主化した
    • 意思決定の基準は個人の生産性
    • “product led growth”

ソフトウェア購入の意志決定がエンドユーザーに委ねられつつある

この時代の流れは、感じるところがある。Mackerelの導入を支援していても、エンジニアが利用するツールの意思決定が現場に委ねられているケースは多い。 自分も以下のブログでソフトウェア購入の意思決定の種類についてまとめている。

missasan.hatenablog.com

わたしのブログではボトムアップというふうに表現しているが、この「現場の評価をえられなければ稟議にあがることもない」という直感というか経験に基づいて実感されたものはまさに End User Era の世界観という感じだ。

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

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

Product led growth と カスタマーサクセス の関係は？

プロダクトがいかにエンドユーザー個人の生産性を上げることができるかにプロダクトの成長がかかっているというのが Product led growth らしい。 セールスよりカスタマーサクセスによるハイタッチよりプロダクト自体がもっとも効果的にすばやく顧客に価値を届けるという考えにリンクしていて、興味深い。

speakerdeck.com

Product led growth 視点での、カスタマーサクセスや、カスタマーサクセスとプロダクトの繋がりに関する記事などを見つけたらまたレポートしたい。

テクニカルソリューションの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の置き方、ミッションの置き方、組織のつくり方、顧客の成功を設計する重要性、顧客について理解する（カスタマーヘルススコアなど）ことの重要性、などについては学べるが、現場で実際にどういう施策を立てて、どう活動するとより効果的かという実務の部分がこれらの書籍からだけではイメージできていない。

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

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

行動を変えるデザイン

行動を変えるデザイン ―心理学と行動経済学をプロダクトデザインに活用する

行動を変えるデザイン ―心理学と行動経済学をプロダクトデザインに活用する

  • 作者:Stephen Wendel
  • 発売日: 2020/06/11
  • メディア: 単行本（ソフトカバー）

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

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

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

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

探索プロセス

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

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

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

補足

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

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

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

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

影響力の武器[第三版]　なぜ、人は動かされるのか

影響力の武器[第三版]　なぜ、人は動かされるのか

人を動かす 文庫版

人を動かす 文庫版

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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