日本でもっと “カスタマーサクセス” を盛り上げよう!! Japan Customer Success Community（JCSC） #11 に参加してみた

今日は 「日本でもっと “カスタマーサクセス” を盛り上げよう!!　Japan Customer Success Community（JCSC） #11」に参加してきました。

jcsc11.peatix.com

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

SmartHRさんの セミナールームで行われました。すてきな会場ですね。

https://twitter.com/mur_ms_/status/1198898200607768580

ご飯も豪華でした。ありがたや......

今日のテーマ

登壇タイトルは「顧客を成功に導くオンボーディングの削ぎ落とし方とは？〜トレタが辞メタ、4つのポイント〜」。

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

詳細 ■当日は、こんなお話をする予定です ・オンボーディングで４つのことを辞めたら、オンボーディング卒業率がUPした！？ ・再オンボーディングはやっぱり難しい。だから初回オンボーディングは外せない！ ・自社だけではなく、パートナー企業を巻き込んでできるサクセスは？ 　等

テーマは、"オンボーディング"。

登壇されたのは、トレタ株式会社　カスタマーサクセス部　部長　鈴木 高太郎 さん もともとはセールス出身で、トレタの7番目のメンバーなんだそうです。いろいろなご経験がある方ですね。 第二回 カスタマーサクセス天下一武闘会 - CS HACK #20 でも登壇されていらっしゃいました。

cshack.connpass.com

お客さまにサクセスしてもらうためにはやりたいことはたくさんあるし、むしろやり過ぎてしまっていることもある。けれど、敢えてやらないことを決めることでオンボーディングの成功率を高めるという目から鱗の登壇内容でした。

鈴木さんの携わっておられるトレタは、トレタは顧客台帳・予約台帳・Web予約をiPadから操作可能なものとして提供しているSaaS。

toreta.in

CS1人あたりの担当店舗が1,000店舗超え。 トレタは飲食店に特化しているバーティカルSaaS。店舗のアイドルタイムである、14:00-17:00の3時間のみでどこまでできるかがポイントになる、とのこと。

オンボーディングの歴史

• オンボーディング完了の定義は、以前まで使っていた予約台帳がなくなったこと。紙台帳を使っていた人がきちんとすべてiPadでできていること。紙からコピーしていたらそれはNG。
• それができているかを電話して確認している。
• Metabase でちゃんと使っているかどうかをみている。
• 定着率については別の指標でみている（今日はテーマからそれるのでこの話はしない

www.metabase.com

Metabase。知らなかった。 そして、そもそもまずすべてのユーザーをオンボーディングされておられる。オンボーディングの成功率を計測できている。すごい......

機能説明をしないということへの決断

• みんなのやり方がバラバラな時期にした決断
• 人は7つまでしか覚えられないのでそもそもたくさん説明できない
• お客さまは、細かい機能より、現状のオペレーションにフィットするかが不安
• 機能説明は、日々の業務で疲れ切ってるお客さまは聞いていて寝ちゃう
• ハイパフォーマーとローパフォーマーの違いがある
  • ハイパフォーマーは、顧客の状況に合わせて柔軟に対応している
  • ローパフォーマーは、すごく丁寧に機能の説明をしている
• 合わせるためには？
  • スクリプトは柔軟性が失われる。ディスカッション形式にした
  • 機能説明 60分->15分 とした。45分は質問対応
    • 相手のオペレーションに必要なコミュニケーションだけになる
  • 便利機能は一切説明しない
  • ちなみに〜〜できます。を全て排除
    • このボタンでいけますが、ちなみにこのボタンからもいけますよ。みたいなのは無し
• 信頼関係が構築しやすくなった
• 当たり前の質問への回答が早くなって、お客さまからの重箱のすみをつつく質問がなくなった
• ちなみに〜、ちなみに〜、とはじめの段階から言っているとお客さまからも「ちなみに〜〜もできますか？」と聞かれて「いや、それはできないんですよ」みたいな話がはじまってしまう
• 便利機能は2タッチ目にお伝えしている
• 成果
  • ローバフォーマーが底上げされた
• 最終的には、機能説明などはパートナーさんにお願いするというチャレンジもされているとのこと

お客様のところに行かないという決断

• オプションが増えてオンボーディング対応が増えた時期にした決断
• オプションが増えるとすぐに売上が増える、反面CSは対応する対象が全体の10%増える
• お客さまは、すぐに問題を解決したい。早く使いたい。それなのにCSの対応が契約から2ヶ月待ち。CSで対応しきれなくなってセールスに助けを求めることに
  • 地方対応も......
• CSが獲得のボトムネックになる。効率化しないと未来がないと思った
• 逃げ場がない環境設定
  • しきりをつけて、リモートで打ち合わせ対応できるようにした
  • CS担当とお客さま両方の心理的なハードルを下げた
    • CS担当には、行ってもいいけど一回リモートでやってみて、という
    • お客さまには、一回リモートでやってダメだったら行かせてくれ、という
    • チームに訪問未経験なメンバーを混ぜる。訪問慣れしている人は訪問した方が楽
• 成果
  • オンボーディング成功率が5%上がった
  • 2タッチ-> 4タッチになった。7x4=28つの情報をお客様が得られるようになった
  • オンボーディング期間も短縮された。28日間->14日間

人が説明しないという決断

• お客さまどんどん欲求が高まってしまう。オンボーディングが完了したら、もっともっと活用したいという気持ちになる
• メンバーの8割がオンボーディング業務になってしまった。カスタマーサクセスやりたいのにやれない
• 顧客ごとにカスタマイズしていない部分は動画にした
• 動画はタッチポイントのたびにプッシュする
  • 何度もプッシュしよう
• 大事なのは、動画をみてもらうだけでなく、宿題を出すこと
  • ちゃんと入力をしてくださいね、というところまで宿題を出す
  • 平均オンボーディング成功率4％アップ
• 成果
  • 14日間->7日間
  • 全員がサクセス活動できるようになった

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

動画をみてもらうだけでなく、宿題を出すこと

私のチームでは動画コンテンツを作るところまではできていないですが、ハンズオン後の対応としても同じことがいえると思いました。ハンズオンをしたお客さまに向けてきちんと宿題を出す、というのは明日からでもやりたい！

レポートは以上です。 登壇でお話いただいた内容から参加者の方々からの質問までしっかり中身の詰まったイベントでした。 次回も参加したい！！

こども哲学ハンドブックという本を書きました。

2018年5月頃から（と記憶しております）、1年以上に渡りコツコツ執筆していた本がついに発売されることになりました。本日8/21より書店に配本される予定です。 著者名は所属する団体名となっていますが、本を開いていただくと、奥付に執筆者の一人として私の名前を見つけていただくことができるかと思います。

Amazonからも購入可能です。

こども哲学ハンドブック 自由に考え、自由に話す場のつくり方

なぜITのあの字もないような本を書いていたかというと、私は実は平日日中帯のお勤め以外のプライベートの時間を一部費やして「こども哲学 おとな哲学 アーダコーダ」（以下、アーダコーダ）という特定非営利活動法人で理事をしています。 （お仕事の繋がりの方が、この活動もしているというのをあまりお伝えできていない気がしたので、こういう書き方をしてみました。哲学畑で知り合った方の方が普段はITの人というのをご存知かもしれない）

この本は、その団体が年に3-4回のペースで開催する講座（ワークショップ）の内容を文字やイラストに起こしてまとめたものです。

どんな内容かをざっくりご紹介すると、「哲学」という、これまでアカデミックな場でしか触れる機会がなかったものを、日々のくらしの中や、身近なコミュニティで楽しむことをおすすめしたり、そういう場をつくりたい人にいろいろな方法や、楽しむためのコツをお伝えするための本です。 しかも、それを幼稚園から中高生くらいまでのこどもと一緒にやることを念頭にしています。

なので、内容もたとえばプラトンやアリストテレスの議論や文献をおさらいしたり、哲学の歴史をたどるようなものではありません。 日々こどもが触れる何気ない問い、ただし、「答えが1つとは限らない、答えがすぐには出ない、あるいは答えがないかもしれない」ような哲学の文脈でも扱われるような問いについて、おとなが答えをこども教えてあげるのではなく、なんとかして一緒に取り組んでいくための本になっています。 そういったことに興味がある、哲学っぽいアプローチで問いを解決していくことを試してみたい方向けの（学術書ではなく）実用書です。

哲学なんて勉強したことがないからよくわからん、という方でも関係なく読める本になっています。日々のくらしで哲学するってどういうこと？と気になった方はぜひ読んでみてフィードバックください。

最後に

団体が発足したての頃に一番によせられれていた声は、こどもがいるおとなや、学校の先生が、こどもと哲学をやりたいというものでした。学習指導要領の改訂や、アクティブラーニングという言葉への関心の広まりも追い風になって、今ではこども哲学は全国で、有志のコミュニティだけではなく、学校の中でも実施されています。

実はジョインした当時の私の個人的なモチベーションは、友達とボードゲームで遊ぶように、哲学っぽい対話を日々のくらしに持ち込みたい、哲学っぽい対話で遊べる仲間を増やしたい、というところにありましたが、数年をかけて、私の思惑や想像をはるかに超えた活動になっています。

私が団体にジョインした2014年ころは、今とはまた別の会社でめちゃくちゃ時間を使って仕事ばかりをしていて、かつその環境では、とにかくビジネスにとってメリットのある答えをいかに早く出せるか、ということが重視されていました。 大学時代に哲学講座に所属して、日がな抽象的な話をさかなに安酒を飲んでいた学生時代がなつかしくなっていた時期でもありました。会社員になって数年経って少しそういうことを懐かしむ余裕がでてきた頃だったんだと思います。その頃、学生時代の友人に声をかけたら、ちょうどこの団体が発足される間近だったので、私自身はしばらく哲学から離れてしまっていたのでが、無理をいって立ち上げメンバーに混ぜてもらったのでした。

そこから数年して、このような執筆の機会をいただけるようになったのは、チャレンジする機会を持たせてくれてサポートしてくれた力強いメンバーのみなさまのおかげと思っています。すごく感謝しています。

カバレッジモデルを導入してよかったことと感じた課題

前回の記事で最後に、次はNPSについて書きたいと言っていたのですが、NPSをはじめる重要なきっかけとなったカバレッジモデルについて先に触れることにします。

カバレッジモデルとは？

カバレッジモデルは、青い本では、ハイタッチ、ロータッチ、テックタッチという3つのモデルに分けて触れられています。 顧客をいくつかのセグメンテーションに分け、CRE（特にカスタマーサクセス）としてどのようなものをユーザーに対して提供するか（内容や頻度）を戦略的に決めるためのモデルです。 Mackerel では、青い本を参考に、ざっくりと以下のように定義しています。

• ハイタッチ
  • 四半期〜半期に一度はお伺いしてコミュニケーションする
• ロータッチ
  • 一年に一度はお伺いしてコミュニケーションする
• テックタッチ
  • メールや電話、公式イベントなどでコミュニケーションする

上に行くほど、1つのユーザーへのコミュニケーションの頻度や深さが高まり、下に行くほど対象となるユーザー数が増えるというピラミッドの構造になっています。

なぜ導入したか

Mackerel の CRE チームはまだまだ小さいチームなので、残念ながら全てのユーザーにハイタッチを行うことはできません。 Mackerel は BtoB のサービスですが、サーバー台数をベースとした従量課金で少額でもはじめられるため、個人で使っていただいているユーザーもいます。ユーザーによって、1台から数千台と、利用状況はさまざまです。サーバーが1台の環境と、数千台の環境では、システムのアーキテクチャはもちろん、使う人の体制や使っている機能、監視に期待することなども大きく違います。 そういった背景から、すべてのユーザーがハイタッチを求めている、とは限らないだろう、という仮説もありました。

私たちには、ハイタッチないしはロータッチができるユーザーを選択していく必要がありました。 そこで、私は、顧客を売上や利用機能、過去のコミュニケーションの状況などを可能な限り洗い出して一定のルールに従ってセグメンテーションし、カバレッジモデルを導入することにチャレンジしました。 主に私はロータッチを担当し、そのユーザー群に対して、1年に1回は最低でもお会いすること、ということを目標に訪問を続けました。

カバレッジモデルを取り入れるよさ

カバレッジモデルを取り入れて一番変化したのは、ユーザーの訪問が、これまで、少なからず過去の経緯や担当者の感覚に頼って判断して行われていたものが、他の人にも説明しやすい仕方で（とはいえ、ゆるやかに）ルール化されて、一人でも判断して進められるようになったということでした。 また、そもそもこのカバレッジモデルを立てるために行った、ユーザー状況の精査ということによって、自分たちの顧客にはどういった人がいるのか、どういう課題を抱えているのか、ということを知ることができました。 精査する際は、以下のような項目を洗い出しましたが、かなり地道で時間のかかる作業でした。それでも、やってよかったと思っています。

• 顧客窓口
• 利用深度
• 運用・監視の課題
• 次のステップ --- など

カバレッジモデルを取り入れても解決できなかった課題

カバレッジモデルを取り入れることで、悩まずにユーザーを訪問できるようになりました。ただ、このあたりから私の中で、いくつかの新しい課題が芽生えはじめました。 それは、こちらからアポイントメントをとって訪問するタイミングが、ユーザーにとってほんとうにうれしいタイミングとは限らないのではないか？という疑問です。 というのも、訪問していろいろとヒアリングしていると、以下のようなことをおっしゃるユーザーの方もおられました。

• 困っていたことがあったけど忘れてしまった
• 困っていたけど、なんとか自分で解決した（ほかのツールで解決した）
• 今後頼るかもしれないが、今はまだ困っていることはない --- など

これらのコメントをもらう度、わたしの中には以下のようなことが浮かんでいました。

• 訪問するタイミングが遅いのではないか？
• もっとユーザーが求めるタイミングでコミュニケーションできたほうが、有意義なのでは？

訪問のような濃い、かつお互いのコスト（時間）がかかるようなコミュニケーションをしているのに、ポイントをはずしているのではもったいない、という気持ちになりました。

NPSへのモチベーションの高まり

こういうことがあって、私の中で、NPSを取得することへのモチベーションがじわじわと上がっていきました。つまり、ユーザーの状況を正しく理解して、ちょうどよい、痒いところに手が届くタイミングで訪問したい、という気持ちが高まったのです。NPSが顧客の状況を正しく知るための、一つの指標になりうると考えはじめました。

実際には、Mackerel のユーザーの状況を正しくつぶさに知るための指標は、これ以外にも多くあります。じゃあなぜNPSからはじめたの？ということろをお話したいのですが、今日はこの辺りまで。次の記事に続きます。

カスタマーサクセスのKPIについて考えはじめたころに参考にしたもの

前回ブログの続きです。カスタマーサクセスの仕事について考えていこう！となったとき、ちょうど発売されたのがこの本でした。

カスタマーサクセス――サブスクリプション時代に求められる「顧客の成功」10の原則

見てみると、発売されたのが 2018年6月 とのことなのでちょうどわたしが入社してから3ヶ月たったころのことだったので、これはうおお、みたいな感じで購入して読みました。 もともと取り組んでいた人からすると原文を読んでいて、やっと日本語訳されたか、という感じなのかもしれない。

Customer Success: How Innovative Companies Are Reducing Churn and Growing Recurring Revenue

カスタマーサクセスの本は、ちょうど私が感じていた以下のような課題についてけっこう答えを書いてくれているように思います。

• カスタマーサクセスが仕事として責任をもつことは何なのか？
• 他のカスタマーサクセスではどういったことをやっているのか？

カスタマーサクセスが持ちうるKPIが何なのか、というのはこの本がわかりやすかったという記憶は実はあまりなく、ネットで「カスタマーサクセス KPI」とかで調べた記事を読み漁っていました。あと当時感じていたこととしては、結局カスタマーサクセスの指標を調べようとして見ていたものはSaaSのKPIでもあるんですよね。 HiCustomerさんの記事や、前田ヒロさんの記事には特にお世話になりました。

media.hicustomer.jp

hiromaeda.com

今、前どんな記事見てたかな、と思いながら同じキーワードで検索してみたら良さそうな記事が1年前よりめちゃくちゃ増えている印象があって驚きました。自分が興味がある分野について世間も関心が高いというのは大変ありがたい。 というわけで、新しく見つけたこちらの記事が網羅的でとてもわかりやすいと思ったので、リンクを貼らせていただきます。

koni.hateblo.jp

これらを見ながら当時、私が注目した、取ってみたいと思ったKPIは以下のようなものです。

MRR Churn Rate

当月失ったMRR(月次収益) / 先月末時点でのMRR(月次収益)

一般的に、顧客数でChurnを測るCustomer Churn Rateと月次収益で測る MRR Churn Rate があります。両方見るのが本来的にはよいそうですが、Mackerelの売上は顧客数ではなく、顧客がMackerelに登録するサーバー数などに紐づいて増加するので、その要素も含んだ月次収益をまずは見始めるのがよいと思いました。

Negative Churn

Net MRR Churn Rate がマイナスである状態 （当月失ったMRR ー アップセル分のMRR ー 休眠顧客からの復活MRR） / 先月末時点でのMRR

既存ユーザーのアップセルだけで収益アップできている状態であれば値がマイナスになる。算数が苦手な私には直感的には理解しにくい値。アップセルの売上を目標にすると、特定顧客へのアプローチ(商談)によるものだけが対象になりがちですが、CREが実施している既存ユーザーに向けたイベント開催や、ドキュメントの作成、リリースブログの更新など広くマスにアプローチする活動も影響している Negative Churn をCREが見る指標とする方がより今の活動に即していると思いました。今どう思っているかはさておき。

顧客満足度

これも、当時のMackerelチームではみるすべがありませんでした。どうやって顧客満足度を集計するか、ということについてはその後検討されて、NPSを取ろう、ということになります。CREのそもそものミッションである顧客の信頼性を高めるということのダイレクトな指標になると思いました。

こんなことを 2018年8月頃 考えていて社内にフィードバックしていたようなので、じりじりとではありますが、着実に前に進んでいるな、と振り返って思います。

この後、実際に私が取り組んだのは、まずはKPIを整理して見られるようにしようということでした。 MRR Churn Rate、Negative Churn はすでにある値を成形するだけで見られたのですぐにやりました。 顧客満足度についてはNPSを取る準備からはじめました。

実は、カスタマーサクセスの文脈で、けっこう重要視される継続率やLTV(顧客障害価値)については当時触れていません。 というのも、Mackerelというサービスの特性上難易度が高い部分があるからです。 これについてはこれからちょっとずつちゃんとやりたいと思っている部分だし、どういう難しさがあるのか、ということもどこかでまとめてみたいです。

次は、たぶんNPSについての記事を書くかなあという気持ちです。

Mackerel CRE の仕事の4軸と私がカスタマーサクセスに重心をおくに至った経緯について

はてなに入って1年がすぎました。 最近、ここ1年くらいでやってきたことをきちんと記録としてアウトプットしておきたいな、というモチベーションが出てきたので、つらつらとブログに残していこうと思っています。 徒然なるままにまとめているので、情報が足りないところやはしょられているところが出てきてしまいそうな気がしますが、質問などはSNSなどから直接いただけたらうれしいです。

はてなのCREでは、カスタマーサクセス担当というような雰囲気で仕事をしている私ですが、ここではそこに至った経緯のようなところを簡単にまとめてみました。

Mackerel のCREでは今、自分たちの仕事を4つの軸で表現しています。 ちなみに、これはあくまで"今"そうなっているだけなので、これからチームやプロダクトの状況によっては変わっていくことももちろんありえます。

• カスタマーサクセス
• テクニカルサポート
• テクニカルアシスト
• テクニカルコミュニケーション

2018年3月に入社したとき、Mackerel チームではちょうどsoudaiさんという偉大なCREが退職されて、a-knowさんというこれまた偉大なCREが開発チームやその他の職種の人と協力しながらほぼ一人でその業務を担っていました。

当時JOINしたての私には、その姿は脅威的で（今でもそれは変わらないけど）、営業同行などのいわゆるテクニカルセールスの分野から、展示会出展の準備のようなマーケティング分野、日々のテクニカルサポート業務、告知ブログ（ニュースレター）の更新、エバンジェリスト活動などなどあらゆる業務を目にも留まらぬスピードでこなしておられました。当時の私からするとCREという職種がいろいろな分野にひらけた魅力的なものあると感じると同時に、まだすべてをこなすほどの力がない自分がどういう軸で仕事を選びとっていけばよいのか困惑したのも本当です。

そういう悩みをa-knowさんに打ち明けたところ、a-knowさんはa-knowさんで、CREという新しい仕事を社内外に向けどう打ち出して認知してもらうか、というようなところを課題としてもっておられたので、a-knowさんの懐の広さによって受け入れてもらって、隔週で「CREについて考える会」というのを二人で開催することに至りました。

「CREについて考える会」はその名の通り基本的にはフリーディスカッションをしながら、次回に向けてアウトプットの宿題を設けたり、持ち寄ったアウトプットをその場で組み替えたり整理したりを繰り返しました。半年くらいは続けたと思います。

そこで様々なディスカッションを経て、生まれたのがこの4軸なのです。

ここでは、この4軸がそれぞれどのような仕事なのかまで詳しく触れないですが、ひとつ大事なことをお伝えしておくと、私はこの4軸はCREの仕事の中にあるミッション・ビジョン・バリューの一部ようなもので、目の前の取り掛かろうとしていることがCREの仕事か？自分のやるべきことか？を判断するときの軸だと思っているということです。もともとつくりはじめたモチベーションもそういうところでした。そういう意味では今はすごく私を支えてくれている4軸です。

仕事を完全にきれいに分類するための便利な切り口というわけでもないし、CREの中の役職や肩書きというわけでは、少なくとも今はまだなっていないです。今後CREが爆増するようなうれしいことが起きたときには、これらをもとにサブ的な肩書きをつけたりすることもあるかもしれませんが、まだそのような体制にはなっていません。

developer.hatenastaff.com

Mackerel CREチームの KPI from Misa Miura

www.slideshare.net

この4軸が腹落ちしたころ、私はその他の業務とのうまくバランスをとりつつ、実は入社前から一番興味のあった「カスタマーサクセス」に自分の重心を置くことを決めました。

よっしゃカスタマーサクセスやっていくぞ、とこころに決めたわたしの次なる課題はカスタマーサクセス業務をどのように作っていき、どのように評価したり分析したりするのか、というところになるのですが、そろそろ京都に着きそうなので（今は京都出張の新幹線の中）また次のブログにまとめたいです。

Mackerel アドベントカレンダー（全部CRE）やってみた

この記事は、Mackerel アドベントカレンダー（全部CRE）の24日目の記事です。

クリスマスイブですね。

さて、Mackerel CREチームでは、この度全部CREでアドベントカレンダーをやってまいりました。

ブログという形で、日々文章を書いてアップし続けた経験ははじめてです。 最後は、アドベントカレンダーをやってみた感想をつらつら書いて終わりたいと思います。

まずはやってみる

はじめにid:a-knowさんに「今年も全部CREやろうと思うんだけどどう？」と言われたときは、いやー無理だろうと思いました。 Mackerelのアドベントカレンダーといえば、毎年すごいエンジニアの人が手を変え品を変え、面白い記事をアップしているものだし、前年のid:Soudaiにいたっては、毎日Mackerelのプラグインについて解説を書くというとんでもない所業をしでかされていた後だったので。 でも無理と思うようなこともできたらいいなと思うことはまずはYESと言ってみる、というスタイルで暮らしているところがあるので、今回もまずはトライしてみたという次第です。

実際にお題を考えたり、ブログを書き貯めたりすることはけっこう大変でしたが、最初に思考停止してYESと言ったおかげで、この体験をやってみることができてかつ最後までこれたのでよかったです。

2日に1回ブログ投稿する

高頻度のブログ更新のためにやったことはこんな感じ。

お題は先に決める

2日に1回ブログを投稿するために、まずは目次を書き出しました。 その日その日にお題を決めていくのは、難しいと持ったので、はじめにあたりをつけておく作業です。 自分が普段こういうものまとめたいなーとか、自分のなかで一度きちんと整理したいなーとか思っていたことを書き出しました。 それが、精査されて、アドベントカレンダーの記事になっています。

• 2日目 サービスとロール
• 4日目 サービスとロールが効いてくるところ
• 6日目 メトリックの種類
• 8日目 監視ルールとチェックプラグイン
• 10日目 通知チャンネルと通知グループ
• 12日目 トライアルプランで試してほしいこと
• 14日目 カスタマイズしたグラフをつくってみよう
• 16日目 オーガニゼーションあれこれ
• 18日目 API と mkrコマンド を使ってみる
• 20日目 アラートグループを設定してみる
• 22日目 CREになって考えていることや読んでいる本など。

自分が今かけるものを書く、すごい記事を目指さない

途中までは、ばくぜんとすごい記事を書かなければ、と思っていました。ところが、すごい記事とはいったい…となってぜんぜんネタが思いつきません。思いついてもそれやるには結構準備や勉強が必要で、そもそも間に合わないのではと思うものばかり。投稿日が近づいた頃、やっと、自分が今かけるものを書こう！憧れるクオリティをめざすまえにやり遂げねば！と開き直ることにしました。ここにたどり着けてよかったです。

探せばヘルプに書いてあるようなこともあるし、誰かがもっとうまくまとめていることもあるかもしれないけど、そういうことじゃないんじゃないかと。 CREは実際に対面でことばでMackerelのあれこれについて説明することが多いです。どこかに書いてあったら説明できるかということそうではないし、自分の言葉でまとめることに意味があると思いました。

毎日ちょっとずつ満遍なく書く

目次が決まってからは、一個ずつ仕上げるのではなく、全部の記事を毎日ちょっとずつ満遍なく書いていきました。

最終的には今自分が本当に書きたい、あったら便利なお題にできたので、比較的に筆が進んで、あとは週末にコツコツ書き貯めたりしてなんとか2日に1回投稿することができました。 この一連の記事、自分ではけっこう満足しています。

毎日のご飯のように書く

先日、Mackerelとはまったく別件で、自炊する話についてブログを書きました。

自炊にはまりながら、料理の本を読んでいました。

面倒くさい日も、おいしく食べたい! 仕事のあとの、パパッとごはん

この本の第１章にあたるところの最初のタイトルが秀逸です。

夕飯作りの「敗北宣言」をする

手の込んだものを作ることは大変だけどおいしいご飯は食べたい。そういう夜は、敗北宣言をして、ちょっとしたメソッドにしたがって手間のかからないご飯をつくっておいしく食べるというのがこの本のコンセプトです。私のアドベントカレンダーへのマインドに近いので、おもしろいです。

これ以外にも、うんうん頷きながら読めるフレーズがいくつも登場します。自分に刺さったエッセンスを書いておきます。本文そのままではなく、私の解釈です。

• 構成するもの少なくてもいい
• こうしとけば絶対においしい、という型をつくる
• レパートリーは少なくてよい
• 余計なことをしない

こったものでおもてなしするわけでなく、自分にとって絶対おいしいものを続けられる範囲でつくろう、というマインドがまさに今の自分にぴったりでした。 こういうことって、いろんなことに応用が聞く、なにかを続けるコツなのかもしれないな、と思いました。

というわけで、自分の晩ご飯のようにアドベントカレンダーを書いてしまいました。

最後に

ブログっていいですね。 みんが見られるところに、自分のための記事を書いていることによって、よい効能がいろいろありました。

• 自分の関心ごとがわかる、人に伝わる
• 物事への自分の理解度がわかる、人に伝わる
• 自分の周囲の人との共通言語がうまれる

いちばん新鮮だったのは、はじめてお会いするお客様に、その日の打ち合わせで時間内にどこを重点的にご紹介したらよいか、という質問に「今日集めたメンバーはブログの記事に書いておられたようなことまではなんとなく理解しているメンバーです」と言ってもらえたことです。 こんなふうに社外の人と、ブログの内容をベースに話ができるようになるのか、と目から鱗でした。

直接Mackerelには関係ない感じでラストの記事を書いてしまいました。 自分の晩ご飯のような記事を読んでくださったみなさま、最後までお付き合いいただきありがとうございました。

CREになって考えていることや読んでいる本など。

この記事は、Mackerel アドベントカレンダー（全部CRE）の22日目の記事です。

いよいよネタも尽きてきたので、今日は本当にライトなネタです。

先日、MackerelプロダクトオーナーのSongmuさんがex-KAYAC Advent Calendar 2018に向けてこんな記事を書かれていました。

blog.song.mu

その中で、MackerelのMVVについて触れられています。 そのまま引用します。

• ミッション
  • 「クラウド監視サービスを提供し、世のエンジニアの開発・運用プロセスを革新する」
• ビジョン
  • DevOps中核サービスのデファクトとして進化しつづける
  • サービス監視・運用の価値を高め、面白くする
  • 顧客のサービス成長を加速させる
• バリューズ
  • Infrastructure as Codeを体現する
  • devops文化を根付かせる
  • ドッグフーディング
  • エンジニアをワクワクさせる
  • OSSエコシステムと共生する

このビジョンのおもしろいところ、というか個人的に興味が惹かれているところは、Mackerelが冠としては「サーバー監視ツール」でありながら、バリューの中には「devops」というカルチャーについてのエッセンスが含まれていることです。

このことが気になってしょうがないので、最近はそればっかり考えているような気がします。 あまりさっと本質にたどり着ける器用な人間ではないので、いろいろな本や社内外の事例などをみたり、先輩に教えを請いながら右往左往して少しずつ頭の中に絵が描かれていっているという具合です。

ちょっと調べてアウトプットして、数日後何かを学んで見直すと、全然わかってないじゃん！というのを繰り返す日々。こういうのは楽しい。

Mackerleで、devopsを根付かせるっていったい何をどうやったらいいんだろう？というのはMackerelチームにいながらもいつも考えている課題です。

これを考えていくためには、いろいろ勉強する必要があるなあと感じています。

とはいえ、まずはdevopsそのものから。

Effective DevOps ―4本柱による持続可能な組織文化の育て方

DevOps教科書

ツールについて、カルチャーについて、いろいろな切り口があります。 先日Mackerel Drinkupを開催した際には、参加者の方と「devopsは変更に関する意思決定を早く、効果的にする手法」ということではないか、というは会話したりしていました。よりよい変更であること、それがはやくできる、ということはdevopsにとって重要なキーワードになりそうです。すごく印象に残りました。

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

SRE本は今運用ということについて考えるときに非常に学びの多い書籍です。 信頼性を高めるのではなく、コントロールする、という考え方が新鮮です。devopsということとSREということがどういった関わりをもつか、ということについてはまだまだ私の中で整理ができていないですが、「SREはdevopsを実現する具体的な手法のひとつ」とおっしゃられていた人もいるので、どちらも合わせて勉強していきたい概念です。

最近、私はMackerelでの運用設計のベストプラクティスをどうやってつくったらどうかということについてもずっと考えていて、そのための、特にモニタリングとインシデント対応については以下の本を参考にしています。

Webエンジニアが知っておきたいインフラの基本

ソフトウェアエンジニアのための ITインフラ監視[実践]入門 (Software Design plus)

どちらも私の前職の先輩方々の教えです。

そして、いよいよ発売される以下の本も非常に楽しみにしています。

入門 監視 ―モダンなモニタリングのためのデザインパターン

CREをしていて思うのは、本当にMackerelのユーザにはいろいろな人や企業がおられるな、ということです。

オンプレを運用されているところもあれば、クラウドに移行中のところもあり、クラウドを使いこなし、次はマイクロサービスをうまく運用していくことに目を向けられているところもあります。

devopsの文化に関するところついても、1つのチームで開発からインフラまですべてを見ているところもあれば、開発チームとインフラチームが別個に動いているところ、SREsがいるところ、それぞれの形態のチームが混在しているところ。様々です。

運用設計といっても、何がベストプラクティスになるのかは、こういったシステムや組織の状況によってきっと異なると思っています。

それぞれのユーザの方がどんなフェーズにおられて、今後どういう組織や運用を目指されているのか。 どんな段階を経て、その目指す姿に近づいていくのか。Mackerelというツールやチームがその変化に対していったいどんなお手伝いができるのかというのが、気になってしょうがいない今日この頃です。しかしまずは勉強ですね。

まだこのあたりのことについてきちんと自分なりのアウトプットできるところまで整理できていないので、来年またアウトプットできたらいいなと思います。

ネタがつきたといいながら、結果、来年の抱負のようなエントリーになったなあ。