子育て中でも K-POP カムバ初速を観測したいので、Mackerel にメトリックを送ってみた

Mackerel

Mackerel Advent Calendar 2025 5日目の記事です。

先週ちらっと確認したらまだ 1 週目が埋まっていなかったので、「小ネタでもいいから何か書くか…」と思い、以前からやってみたかった K-POP カムバ初速のメトリック取得に挑戦してみました。 飴玉一つ入ってたくらいの感じでお読みください。

K-POP が好き。だけど時間がない

私は K-POP が大好きで、基本的に何でも聴く雑食タイプです。

入門は TWICE。その後各種オーディション番組にはまり、ENHYPEN を主に推していました。最近は（KPOPではないけど）XG、ゆるめに LE SSERAFIM、ILLIT あたりも追いつつ、今はいろんなグループの動向を眺めています。いろいろありましたが、NewJeans も曲が好きでよく聴いていました。

ただ、子どもが生まれてからはまとまった時間が取れなくなってしまい、活動としては「新曲が出たら観る」「24 時間でMVどのくらい伸びたかな〜とチェックする」くらいのうすい活動が限界に。

なので、この初速の観測を自動化できたら楽しそうだなと思ったのが今回のモチベーションでした。

やりたかったこと

  • カムバ直後の再生数の伸びを見たい
  • 複数グループを並べて観測したい

バイブコーディングにがっつり頼り、いろいろと試しながら形にしていきました。

指標選びでつまずいた話

Google トレンドは使えなかった

最初は「人気度＝Google トレンド」でメトリック投稿しようと思ったのですが、Google トレンドは以下の仕様により断念しました。

  • 取得した1 週間内での最大値を100とした相対評価になる
  • 複数グループを指定するとグループ間の相対評価になる

つまり、絶対値として毎時間メトリックを取る用途には向かなかったのでやめました。

YouTube MV 再生数に切り替え

そこで MV の再生数を使うことにしたのですが、これがまた地味に難しい。

  • リリース直後の MV をどう特定するか
    • MV はリリースされるまで URL がわからないので、「最新 MV を探す仕組み」が必要。
  • グループの公式チャンネルに出ない問題
    • グループ公式チャンネルではなく、レーベル公式チャンネルに MV が出ることが多く、他グループのものもあるので検索に工夫が必要。
    • 「グループ名 + MV」で検索するようにしました。
  • MV っぽいけど MV じゃない動画が多い
    • teaser / remix / dance practice などが出てくるので除外フィルタを追加。
    • さらに ILLIT は ショート動画が本編 MV とまったく同じタイトルで出てくる という運用がされていることがわかりました。
      • 60 秒以内の動画を排除するようにしました。

手順の全体像

  • レーベル公式チャンネルから最新検索結果 50 件を取得
  • 条件に合う最新 MV があれば再生数を取得
  • 1時間ごとに View 数の 絶対値 と 前回との差分 をメトリックとして投稿
  • 新しい MV が出たら自動的にそちらに切り替わる（無限に対象が増えない）

穴のある仕組みではありますが、まず動かすことを優先しています。

補足

後から気付いたんですが、今回はコード側で差分値を出して投稿しているんですが、サービスメトリックには、グラフ定義側で差分値を出す機能がありました...

グラフ定義の設定画面

プログラムでとった差分と雰囲気の違うグラフが出るので、裏の仕様は気になるところですが、調べるところまで間に合いませんでした。

左がグラフ定義の差分値、右がプログラムの差分値

YouTube API クォータ問題との戦い

メトリック取得までは順調だったのですが、翌朝見ると 2 時以降エラーで止まっていました。 原因は YouTube API のクォータ exceeded。

そこで最新動画検索のタイミングを、K-POP の MV がよく公開される

  • 13 時
  • 18 時

の ＋1時間後（14時・19時） に限定しました。

クォータ計算的にも十分余裕があるのを確認し、この運用に落ち着きました。

スケジュールと実行は GitHub Actions に任せていますが、これが10〜30分くらいの幅でスケジュールがズレるし、なんならたまにキューから漏れるので差分値が不安定になる（取得間隔が短いと少なく、長いと多く見える）のは悩ましいところです。

観測対象グループ

最初は以下の 4 グループを対象にしました。

  • IVE
  • aespa
  • LE SSERAFIM
  • ILLIT

直近リリースがあるわけではなかったので変化は少なく横ばい気味です。 そこで、12/1 にソロアルバムを出した 少女時代 TAEYEON も追加しました。

結果（グラフ）

絶対値のほうは大きな動きがなくて少しさびしいのですが、差分値は若干動きがあっていい感じです。この1時間で少なくとも4万人の人がKPOPのMV観てるんだな〜とファンダムの規模感を感じられて嬉しい。

3日ほど動かしてみたグラフ

毎日10-12時あたりの視聴数が多いように見えます。みんな午前中にMV観るんだ〜と思っていたら、これがよく見ると、9時台と11時台のスケジュールが毎回スキップされていることに気がつきました（画像からはわかりずらくてすみません）。2時間分の差分になってしまっているのであたかも高い値に見えてしまっています。とても残念。

10-12時あたりが跳ねているように見える

TAEYEONだけに絞ると、MVのリリース直後にぐっと視聴が伸びているのがわかって楽しいです。

TAEYEONだけに絞るとこんな感じ

グラフ描画で困ったところ

今回はシンプルに サービスメトリック として投稿しました。 サービスメトリックはAPIでシュッと投げるだけでいいので、投稿は楽なのですが、グラフの描画方法を自由に操作できるわけではないので、物足りなさがありました。

  • メトリック名でグラフの所属が決まるので、後から「このグループだけ別グラフにしたい」などの変更が難しい
  • 絶対値と差分値で同じグループでも色が揃わない

後から好きに組み合わせられる ラベル付きメトリック にしておけばよかったなと後悔しています。

もっと遊ぶなら

他にもいろいろ追加したいものなど、妄想が進みます。

  • グループ数をもっと増やす（ヨジャだけでなく、ナムジャも見たい。クォータと相談しつつ）
  • MV 再生数以外の指標（SNS の盛り上がり、音源のランキングなど）
  • メトリック投稿とは別に、デビュー情報・カムバ情報の通知

閾値を越えたり下回ったりしたら通知するとか、新MVが追加されたら通知するなど監視ルールも整備して、普段ならネットサーフィンして集めているような情報を自動で Slack や LINE に流せるようにしたいです。

おわりに

今回の試みは趣味活ではありますが、実際にやってみると監視基盤をどう設計するかという観点で、思った以上に学びがありました。

1. 「何を計測したいか」を決めることの難しさ

Google トレンドを断念し、YouTube 再生数に切り替えるまで、 “値として安定して蓄積できる指標とは何か” を考えることになりました。

  • 相対値か絶対値か
  • 時間軸で値の意味が変わらないか
  • 外部サービス依存の揺らぎを許容できるか

といった初期設計の重要性をあらためて感じました。

2. 制約が監視設計そのものを変えていく

実際の現場でも上記のような“外側の事情”が、そのまま監視ロジックの形を決めてしまうことがあると思います。

  • API の実行コスト
  • データ転送量
  • ストレージ費用
  • レートリミット

私も今回、YouTube API のクォータに合わせて実行頻度を下げざるを得なかった、という「使うものの制約に監視設計が引っぱられる」という体験ができました。

加えて今回は 差分監視 を行っているため、GitHub Actions のスケジュール揺れやドロップがあると、差分の意味自体が変わってしまう問題にも直面しました。

趣味活なら「まあいいか」で済みますが、仕事でこれが起きていたら確実にストレスになりそうで、データ品質をどう担保するかが監視設計において本質的なテーマだと再認識しました。

今回ひさびさにこういった、ちょっとした趣味メトリックを投稿するということをやってみましたが、思いがけない学びも多く、やっぱり楽しいかったです。

忙しい中で推し活をしている方、気が向いたらぜひ皆さんも “推しのメトリック” を投稿して遊んでみてください。

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を担当している場合、自分が対面している人物が、ビジネス、技術、どちらの意思決定により影響力がある人物なのかを意識してみることをおすすめしたい。また、ケアすべきいずれかのキーマンをないがしろにしていないか、という点も見直してみるとよい。

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

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

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

カスタマーサクセス・プロフェッショナル――顧客の成功を支え、持続的な利益成長をもたらす仕事のすべて

カスタマーサクセス・プロフェッショナル――顧客の成功を支え、持続的な利益成長をもたらす仕事のすべて