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

この記事では、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環境つくったりしてましたが、あらためて前から積んでいた以下の書籍読んでいろいろ理解が深まりました。

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

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

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

行動を変えるデザイン

この本では行動心理学を応用し、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をこれからはじめる、またははじめたてのユーザーの方々に向けてオンラインセミナーを開催させていただいたりもしています。