MackerelのCREがカスタマーサクセスをいま学ぶ理由─3年間の試行錯誤をぜんぶ話そう

こんにちは。Mackerel CREサブディレクターのid:missasanです。

はてなにCRE（Customer Reliability Engineer）という職種が誕生して3年3ヶ月、私がCREとしてジョインしてから2年半が経ちました。当時は2人だったCREも、今では5名体制になっています。その間、私たちにとって大きな変化がいくつもありました。

CREのような新しい職種が一つの企業の中でどのように変化しているか？それを新鮮なうちにシェアしておくことは、CREを立ち上げようと考えている方や、今まさにCREで業務やチームの改善に励んでいる方、これからCREになろうという方の参考になるかと思い、この記事で紹介させていただきます。

また記事の後半では、世界そして日本でどのようにCREが広まってきたかを振り返り、さらに企業でCREの導入に取り組んでいる方に向けたヒントをまとめました。こちらも参考にしてみてください。

2人だったCREが独立したチームになるまで

CREの定義に悩んだ立ち上げ期

はてなのCREの歴史は、2017年7月頃に始まります。もともとセールスエンジニアとしてジョインしたid:a-knowが、テクニカルサポートやリリースブログの執筆、OSSのコードを書くなど活動の幅を大きく広げたことから、実情に合わせて職種名をCREに変更しました。

私がジョインした2018年3月には、セールスとCREをまとめたビジネスチームがちょうど立ち上がったばかりでした。ビジネスチームが当初から特に注力しているのは、新しくMackerelを使ってくれるユーザーをどれだけ増やせるかということです。まだセールスメンバーも少なかったので、CREであっても新規案件の商談を主担当として任されました。

サービスを説明し、技術の問い合わせに答え、ハンズオンをして、契約手続きもして、導入支援もするという状況です。あまりにもやることが多岐に渡るため、CREの主要な業務内容やKPIを定義することの難しさを感じていました。ビジネスチームとしてやったほうがよいことが無限にあるなか、CREとしてやっていることはどれで、どれが支援にあたるのか？どう優先度をつけていくべきか？迷いがありました。

そこで始めた取り組みが、隔週でブレストをする「CREについて考える会」です。ここでは自分たちのミッションの定義、業務の優先度、KPIなどについて理想から実情まで洗い出し、アウトプットとしてまとめていきました。

活動を改善するためカスタマーサクセスを学ぶ

1年もするとセールスのメンバーも徐々に増えて、CREが単独でセールスすることは少なくなりました。 CREのメンバーもid:tukaeluがジョインして3名になり、テクニカルサポートの体制面が強化されました。

これにより、立ち上げ期に構想していた業務の優先度づけや、KPI設計にも少しずつ取り掛かる余裕が出てきました。テクニカルセールス、既存ユーザーのフォローアップ、テクニカルサポート、その他ビジネスチームのタスクというように、業務の分類や分担にも意識が向けられるようになりました。

ただ、3人になったとはいえ、すべてのタスクをこなすにはまだまだ人が少なく、すべてのユーザーをフォローすることはできなかったため、自分たちのアクションがKPIにインパクトを与えられるよう、活動を絞り、より精度を高めていく必要性があることを課題として感じていました。

この頃、以前からCREの活動と共通点があるように感じていたカスタマーサクセスについて、チーム内で読書会を開催したり社内向けに発表したりと、本格的に勉強を始めました。

データ活用による分析とアクションの試行錯誤期

カスタマーサクセスの文脈では、データを活用する重要性が語られます。その考え方を参考に、できる範囲で顧客の情報をまとめて分析し、効果的なアクションを考えるインプットとして活用することを始めました。 Mackerelのさまざまなデータを取り扱うにあたっては開発チームの協力も得ていましたが、これをきっかけにデータ基盤の技術に明るいid:syou6162と一緒にデータを見ることが多くなりました。

syou6162は、機械学習を使った機能の開発を担当するアプリケーションエンジニアでした。Mackerelのロール内異常検知機能のリリースが一段落した頃で、カスタマーサクセスの読書会にも参加し、CREの課題意識にも共感してくれていました。半年ほど一緒にデータ分析を行った後、2020年2月に正式にCREとしてジョインしました。

これでCREは4名になり、私はサブディレクターとして、より多様になったCREの業務をとりまとめることになりました。

それからはデータ基盤の構築を本格的に進め、分析してアクションする試行錯誤を繰り返しました。そうしたサイクルによって、活動をブラッシュアップすること自体にはある程度の価値を見出しつつも、まだまだ「これが完成」とか「正解」と言えるところまでは至らなかったと思います。

個人技からチームとしてのアウトプットへ

2020年8月、ディレクター（他社でいうところのマネージャー）にMackerelのプロダクトマネージャーでもあるid:wtatsuruを迎えて、CREは公式の組織図上でも独立したチームとなりました。

チームとして切り出されたことで、CREへの期待がより明確になり、チームとしてのアウトプットを求められるようになりました。また、はじめはCRE業務の効率化を目的にしていたデータ基盤構築ですが、CREの枠を超えて広くMackerelの事業戦略の側面からも期待されるようになりました。

これまではビジネスチームの中で、CREという職種を持った個人が、それぞれの得意分野で最善を尽くすという側面が強かったですが、これからはその高いスキルと多様性を持った個人が集まって、チームとしてのアウトプットの質を高めたり、Mackerelの事業への効果を最大化することを求められるフェーズに来ているなと感じています。

先のことはわかりませんが、ここを乗り越えて、チームとして新しい成長ができれば、CREがチームとしてもっとスケールしていく未来があると考えています。

世界から日本へ CREはどのように広まったか

ここで少し目線を変えて、CREの広がりを見ていきます。この記事を書くにあたって、世界そして日本におけるCREの実践事例を改めて見渡してみました。

こういった情報は立ち上げ期によく調べていたのですが、ここ最近はあまり詳しく見ることができていなかったので、どのような変化があったか？その中で自分たちの立ち位置はどうなっているか？などが気になったのです。

なお、これはきちんとした調査ではなく、私がインターネットで観測できた範囲の情報です。偏りがある可能性もありますので、ご了承ください。

海外におけるCREの実践事例

そもそもCREという職種は、2016年にGoogleが先駆けて提唱したものです。

海外の事例を見てみると、ほかにもMicrosoft、VMware、Palo Alto Networksなど、多くのテクノロジー企業でCREを採用していました。

これらは顧客の体験価値の向上を目的とし、顧客企業内のSRE*1チームやDevOpsチームと協力して、ソリューションアーキテクトや改善プロジェクトの推進などの役割を果たす職種と位置付けられています。

なお、SREやDevOpsチームが利用するサーバー監視ツールであるMackerelを提供するはてなでも、Googleに共感して、2017年7月頃にセールスエンジニアの名称をCREに変更しました（経緯の詳細は前述した通りです）。

日本におけるBtoC企業の事例

日本で、はてなと同時期にいち早くCREを立ち上げたのは、意外にもXFLAGやメルカリといったBtoCのサービスを提供する企業でした。

その目的は、Googleをはじめとする海外のBtoB企業が自社のプラットフォームやプロダクトで稼働する顧客のアプリケーションのSREを支援しているものとは、少し趣が異なります。

BtoC企業におけるCREは、自社サービスのユーザーが安心して利用できることに焦点がおかれており、カスタマーサポート業務の改善や、ユーザーから得られたフィードバック（VoC=Voice of Customer）を活かした開発を行う職種として立ち上げられるケースが多いようです。

Googleが言う「Customer Reliability（顧客の信頼性）」から発想し、エンジニアリングやエンジニアキャリアの可能性を広げた素晴らしいアイディアだったのではないかと思います。

日本におけるBtoB企業の事例

BtoB企業でははてなのほかに、Repro、Givery、Classiなどの企業でCREが立ち上げられました。

BtoB企業の場合は、海外事例と同様にソリューションアーキテクトなどの役割を担うケースのほか、プロアクティブなテクニカルサポートや、BtoC企業で見られたVoCの分析・活用も担うケースなど、より多様な事例が見られました。

また最近では、はてなもそうですが、カスタマーサクセスの考え方を取り入れて、顧客の信頼性だけではなく、顧客の成功をKPIとする職種として定義されるケースも見られます。 CREとオーバーラップするような役割でCSE（Customer Success Engineer）という職種が設けられているAutifyのケースもあります。

広がりを見せる日本のCREの傾向と分類

このように日本では、企業のビジネスモデルや抱えている課題などに応じてCREが担う役割や業務内容もさまざまで、海外事例とはまた違った広がりを見せています。

これを私なりに、ビジネスモデルが「BtoB」か「BtoC」か、活動のベクトルが「ユーザー課題に向き合う」ものか「プロダクトに向き合う」ものかで分類してみました。

興味深いのは、BtoC／BtoBに限らず多くの企業で、CREがVoCの分析・活用を役割として担っていることです。海外事例でも同様にプロダクト改善にもコミットすることが責任範囲に含まれるケースがありましたが、顧客の課題を解決することがミッションであるCREが、ユーザーとプロダクトの間に入ってこういった役割を担うことは、自然の流れのように思えます。

CREを立ち上げる CREになる

最後に、CREを導入するときのヒントを私なりにまとめておきます。

なぜCREが組織に必要なのか？

CREがいることで得られる一番のメリットであり、また特徴となることは、ユーザーの目的実現をKPIに持った専門のエンジニアがいるということです。

エンジニアがユーザーの動向をくまなく観察し、実際にコミュニケーションすることで、ユーザーの目的を正しく把握し、目的にあった正しい使い方をユーザーに促し、ときにはプロダクトオーナーや開発者としてプロダクト自体の改善も行う。そしてまた改善されたプロダクトをユーザーに届け、新たなフィードバックを得る。

このサイクルを素早く継続的に回していくことで、ユーザーとプロダクトが健全に関わり合いながら、ユーザーに価値を提供し続けていくことができます。組織の中のこういった活動に輪郭を持たせ、文化として根付かせ、より加速させることが、CREを職種やチームとして立ち上げる意義なのではないかと考えています。

ミッションを定める

CREの特性として、業務内容が多岐に渡りやすいため、自分たちなりの“CRE像”を明確にしておくことをお勧めします。メンバーが腹落ちするミッションが共有されていれば、迷ったときに立ち戻って、チームが集中していることが何だったかを思い出すことができます。

はてなの事例をもとにご紹介します。これは立ち上げ期にディスカッションしたものをベースに、チーム状況に応じて改定を重ねているものですので、記事公開時点でのものとお考えください。

MackerelのCREは、プロダクトの価値全体を最大化することを目指しています。以下はカスタマーサクセスの考え方を参考に、CREがいるプロダクトの価値を再定義したものです。

参考書籍：カスタマーサクセスとは何か

カスタマーサクセスとは何か――日本企業にこそ必要な「これからの顧客との付き合い方」

作者:弘子ラザヴィ
発売日: 2019/07/03
メディア: 単行本（ソフトカバー）

そして、その目的を達成するため、4つの軸で業務を分類し、それぞれの効果を高めていけるよう活動しています。逆にここに表現されていない事柄については、そもそも着手するべきか、やるとしても成果物の品質やスケジュールをコントロールするよう、丁寧に検討するようにしています。

それぞれの活動の詳しい内容やTipsなどは長くなってしまうのでここでは書きません。メンバーによる次の2つの記事を参考にしてください。

CREに向いている人

あくまで主観になりますが、チームのメンバーやこれまでお会いしてきたCREの方を見ていて、どういうエンジニアなのかをまとめてみます。

ユーザーの目的実現にオーナーシップを持てる強いモチベーションがある
目的に対してエンジニア的なアプローチができる
ビジネスステージによってやることが流動的でも楽しめる
ユーザーと信頼関係を築くコミュニケーションができる（したいと思って気をつけられる、目を光らせられる）

ユーザーと話したい。ユーザーが何を考えてどのようにプロダクトを使っているのかがとにかく気になる。何か不安や不満に思っていることがあるなら、どうにかしてそれを解消したい。そのため何かしらのアクションを自然と始めてしまう。

そういうエンジニアの方がおられたらCREに向いていると思います。

CREになりたい人がやっておくとよいこと

CREになるにはどういう勉強をしたらいいですか？と聞かれることがあるので、やっておくと役に立つと私が考えるものをご紹介します。

今やっている技術をしっかりと身につける
エンジニアリングによって課題を解決する経験を通して、エンジニアとしての振る舞いを身につける

基本的なことではありますが、まずはエンジニアとして今の業務や技術にしっかり向き合っておくことは、職種は変われど、強みになることはあっても無駄になることは決してありません。

自分がユーザーとしてサービスやプロダクトを使い込み、よく観察し、その結果をアウトプットする

ブログを書いたり、人に教えたり、ユーザーコミュニティに参加したり、OSSがあればプルリクエストを送ったり。とにかくユーザーとしての体験を満喫してください。それがCREとして感度を高める方法のひとつです。

MackerelのCREも、メンバーのうち2名が元Mackerelユーザーです。 Mackerelを導入する苦労も、導入した後の成功体験もよく知っています。ユーザーの苦労を低減したい、もっと成功体験を得てほしいという強いモチベーションがあり、どうしたらユーザーが信頼し、喜んでくれるのかを肌で知っています。

リテンションモデルについて基本的な知識をつける

はてなも含め、CREを立ち上げている多くの企業が、ユーザーが自社のサービスやプロダクトを使い続けることを重視するリテンションモデルを事業に取り入れている場合がほとんどです。

リテンションモデルが増えている背景や、それを支える開発の思想・手法（アジャイル・SRE・DevOpsなど）、カスタマーサクセスの考え方について基本的なことを押さえておくと、CREになった後、自分のミッションがどういうことを背景としているのか、なぜやるのかについての理解が深まります。

最後に

この記事では、はてなにおけるCREの変遷と、各社の事例、CREを立ち上げるヒントについて紹介しました。

こういった内容は、1年、2年と経つうちにアップデートされていくものです。また機会があれば、CREチームのその後をご紹介できればと思います。

ただ今、はてなではCREを積極採用中です。この記事を読んで少しでも興味を持っていただけたなら、ぜひこの機会にお声がけください！

▼採用情報はこちらです▼
株式会社はてな CRE (Customer Reliability Engineer) 職採用情報

*1:Site Reliability Engineering

Hatena Developer Blog