〇〇社用みたいなコードは生み出さないように　はてなCREがユーザーからの要望ではなく背景を大事にする理由

CREはスペシャリストとジェネラリストの要素を持つ仕事

missasan氏（以下、missasan）：私は株式会社はてなで、MackerelチームCREをしています、三浦と申します。はてなidがmissasanなので、インターネット上で話かけていただく時はぜひmissasanと呼んでいただければと思います。新卒で入った会社はSIerの企業で、そこでインフラエンジニアを経験した後、MSPの企業でテクニカルセールスをやっていました。2018年3月からは今の現職で、「Mackerel」チームのCREをしています。

今日お話するトピックスは、この3点です。ここでちょっとみなさんに質問してみたいのですが、今見ていただいている方は自分のことをインフラエンジニアとかエンジニアのスペシャリストだと思うか、どちらかというとジェネラリストの部分もあるなと感じるか、どちらでしょうか？

CREは、エンジニアのスペシャリストの部分とジェネラリストの部分の要素をうまく兼ね備えた仕事です。ジェネラリストは、自分が持っている知識をうまく組み合わせて課題を解決する人、課題解決までのうまい道筋を組み立てる人というイメージを持っています。なので、もしスペシャリスト以外に何かこれから新しいことにチャレンジしてみたいなと思う人がいたら、今日のお話が少しでも参考になればなと思っています。

本編に入る前に、簡単にMackerelというプロダクトを紹介したいと思います。Mackerelは国産で開発されたSaaSで、サーバー監視サービスです。簡単に導入できる直感的なUI/UXを持っていて、これまでどちらかというとスペシャリストが少数精鋭でやっていたサーバー監視の分野を、いろいろなロールの人が協力して取り組めるように、というところをプロダクトのビジョンとして開発しています。

コアのユーザーは、インフラエンジニアやSREが多いです。

ここで、CREという職種についても簡単に紹介しようと思います。CREを略さずに言うとCustomer Reliability Engineerと言います。日本語に直訳すると「顧客信頼性エンジニア」です。もともとは2016年にGoogleが提唱した概念で、はてなでは2017年にMackerelチームで発足しました。

CREチームは、「顧客に寄り添い、顧客が抱える真の課題にフォーカスし、その課題を技術を軸として顧客と共に解決を図る」をミッションにしていて、一言で簡単に言い表すと「プロダクトを導入・活用するユーザーの課題解決をミッションとするエンジニア職」です。

組織体制はこんな感じで、ビジネスチームと開発チームが横並びで存在しているかたちで活動しています。

「導入・活用・拡大」それぞれのフェーズであるお客さまの課題

ここから本編のお話で、CREが課題をどのように解決しているのかをお話します。まずはMackerelのユーザーがどんな課題を持っているのかを簡単にイメージしてもらうために、ざっくり紹介したいなと思うのですが、Mackerelにはカスタマージャーニーの中に大きく3つのフェーズがあります。

最初は導入の時期ですね。Mackerelを使って運用設計をしたり、その設計に合わせて実装する導入フェーズです。次が活用フェーズで、実装したものを使って本格的な運用を開始したり、それに伴って必要になるMackerelの応用機能を活用するフェーズ。最後に拡大フェーズですね。それまでの活用で得られた成果を複数の事業や他の部門に展開していくフェーズがあります。

お客さまの課題は、導入・活用・拡大のそれぞれで、さまざまあります。導入だったら、なんとか早く導入してチームに馴染ませたい。チームメンバーのトレーニングをしたいという課題感だったり、活用フェーズだと、もっと具体的な課題がメインになるのですが、障害対応の時間を短縮したいとか、運用コストを削減したいとか、こういったことが課題になります。

拡大フェーズになると、導入するシステムがどんどん増えてくるので、管理が複雑にならないようにとか、横展開するスピード感と、それぞれのガバナンスのバランスをどうやってうまく両立していくかとか、いろいろな課題があります。CREはフェーズや課題に合った支援を提供するのが仕事になっています。

CREが目指すのはユーザーの自走

ではどうやって解決しているのかというところですが、CREが基本的に目指しているところは、ユーザーが自走してMackerelを使うというところです。

みなさん、ご自身のことを思い出しても納得してもらえるんじゃないかなと思うのですが、ユーザーが誰かに頼らないと導入できないツールは、恐らく面倒くさいと思うので、そこをCREが調べたり実際に操作してみせるというところで解決が楽になるようにいろいろなかたちで支援しています。

それぞれの支援の方法はここに挙げているようにいくつかあるのですが、それぞれ特性を持っています。例えばテクニカルサポートは、今の目の前の課題をとにかく早く解決するのをお手伝いするという特性がありますし、セミナーやハンズオンの場合、個々の課題解決だけだと想像できない、全体像や体系立った概念を伝える手段として有効です。

ヘルプドキュメントやブログは、これまでの課題解決の中で蓄積されたノウハウをユーザーの方々が触れやすい状態にするという手段になっています。ちなみにプリセールスをやることもあるのですが、これはユーザーがツールを使い始める前に、先にいろいろな知見をインプットするお手伝いをするという手段です。

最後にプロダクトのアップデートを挙げているのですが、私たちは、これがユーザーの方々が自走するための一番の根本解決だなと思っています。CREが実際にプロダクトを開発することは少ないのですが、課題解決の中でいただいたお客さまの声をプロダクトにフィードバックして改善に貢献するということをやっています。

このように、いろいろな手立てを適切に選択して、心地よいタイミングと速さで提供するところがCREの仕事のおもしろいところだと思っています。

CREが適切な手立てを選択する時のポイント

ここから、適切な手立てをどう選択しているかのポイントをお話ししていきたいと思います。1つ目は、ユーザーに関して理解を深めるというところです。適切な手立てを選び取るには、ユーザーに対して正しい理解があることが非常に重要です。

1つ目は「ユーザーインタビューから知る」としているのですが、お客さまと実際に打ち合わせをして、監視対象のシステムがどういうアーキテクチャで動いているか。例えばOS、ミドルウェアは何を使っているか、オンプレミスなのかクラウドなのかもインタビューしますし、どういう運用組織で運用されているのか。運用チームは社内にいるのか、それとも社外の協力会社さんが入っているのかとか、そういったところもヒアリングします。あとは中央集権型なのか、それとも権限が各チームに分散しているのか、組織の文化に関してもヒアリングするようにしています。

もう1つは「データから知る」というところですね。これはデータからお客さまがどの機能を利用しているか・していないか、どれをアクティブに使用しているかをしっかり見ることで、全体から見てお客さまがどのような特性を持っているのかを知るために非常に有効です。ユーザーの理解を深めることは、お客さまが抱えている課題の輪郭を明確にするところで非常に重要だと考えています。

次は課題を目利きする重要性です。なぜこの目利きが重要かというと、ユーザーインタビューなどを行っているとお客さまから本当にたくさんの声をいただきます。優先度が高いもの、低いものさまざま含まれているので、どれから手を付けるべきなのかをCREが判断して見極めていくのが重要になってきます。

あとは支援が必要なものと、そうではないもの。何かヒントを提供すればお客さまが自走してセットアップできることもあるので、そういったところをしっかりと見極めるようにしています。チェックポイントの例は、一般的な事例か、それともそのお客さま特有の事例か、あとはその解決したい課題がプロダクトのビジョンとマッチしているか。

要はMackerelで解決すべきものなのか、もしくはフィットする別のプロダクトがあるのか、みたいなところもCREは意識してお客さまとお話しています。Mackerelで解決できないものは、なるべくワークアラウンドに関しても提案できるようにと考えています。

簡単な分岐のイメージを書いてみたのですが、こういったことを頭の中でいろいろと考えながら、ふだんお客さまとやり取りをしています。

フィードバックするのは機能要望ではなくその背景や課題

次は、CREがどのようにプロダクトの改善に関わっているかについてお話します。繰り返しになるのですが、プロダクトの改善がお客さまにとって最高の解決方法だと私は思っています。

テクニカルサポートに問い合わせしなくても導入できるツールのほうがもちろんうれしいし、手間のかかるワークアラウンドで何かを解決しないとその機能が使えない、ということがないほうがもちろんうれしいし、あとはここが一番重要かなと思うのですが、プロダクト自体を改善すると、そのプロダクトを利用しているすべてのユーザーの体験が改善されるのが、この部分の魅力だなと思っています。

どのように関わっているかというところで、1つ目は、フィードバックのフローをきちんと用意しています。ユーザーからCREがインタビューをして、その声をプロダクトバックログとは別のバックログにリストとしてどんどん溜めています。要望管理というプロセスがあるのですが、その中で課題を抽象化したり、目利きをして整理したものを開発チームに渡しています。

実際にプロダクトの改善をやっていくぞと決まったものは、開発チームの持ち物であるGitHub上のプロダクトバックログの中で管理されます。実際に機能が開発されたら、今度はCREがそれをレビューして、告知ブログを書いてお客さまに届けます。

このサイクルがうまく回っていくと、改善した機能に対してユーザーから新しいご意見が来て、それが開発チームにフィードバックされてプロダクトがどんどん良くなっていきます。ユーザーとプロダクトの健全な関係性が構築されていくと思っています。

もう1つ、何をフィードバックするかも非常に重要だなと思っています。フィードバックには2種類あると思っていて、よくあるのは機能要望をフィードバックするというやり方です。

機能要望をフィードバックだと、「AをBにしてほしい」とか、「この画面でこの機能を使えるようにしてほしい」とか、機能要望は解決できるかもしれませんが、その機能要望の背景にあった課題にクリティカルヒットする機能にならない可能性があるなと私は考えています。

じゃあどうするかというと、機能要望の課題や背景をインタビューして、その背景自体を開発チームにフィードバックするのが一番良い方法かなと思っています。それで開発された最終的なアウトプットは、お客さまの言葉どおりの機能要望とガッツリとマッチはしていないかもしれませんが、その背景にあった本来解決したかった課題に対して、より最適な解決策を提案できる可能性が高まると考えています。

限定的な〇〇社用のコードは生み出さない

ここのトピックスの最後は、自分の経験則からこんな教訓がありましたというところをおまけとして共有したいと思います。今までは理想を語ってきたのですが、事前にユーザーとある程度仕様を合意して取りかかる必要がある場合もあります。こういう時に、課題解決につながる最小限の仕様だけを合意するというのが、自分が工夫してみてよかったことで、すごくうまく行ったなと思っています。

「これだけ実装できていれば大丈夫ですよね？」と合意しておいて、それ以外の部分に関してはなるべく自由度を持たせて開発チームが提案できる余地を残すというのがうまくいったかなと思います。また、その背景を正しく共有するために開発チームときちんとコミュニケーションを取るのを怖がらずにやろうというのが自分の教訓です。

開発チームとコミュニケーションの時間を取るというと、けっこうリソースを奪ってしまう気がして気が引けてしまうのですが、解決策を検討してもらうために必要なコミュニケーションは、文章だったり言葉だったりで、きちんと準備して伝えることを大事にしたほうがいいなと経験から学びました。

最後ですね。〇〇社用のコードみたいなコードは生み出さないように心掛けるというのが、自分の経験から学んだことです。一見すると一部の改修だけで済んで、開発のコストが低く見えるのですが、安易にこれを選択せずに限定的な機能ではなく課題をもっと抽象化して、より広く使ってもらえる機能としてなるべくリリースできる道を開発チームと一緒に探っていくのが、ユーザーにとっても、開発チームや私たちにとっても良い方法だなと学びました。

CREチームを立ち上げるメリットは顧客中心主義文化の取り込み

最後にあらためて、CREの役割についてお話します。CREが目指しているところですね。これもイメージを紹介しようと思うのですが、Mackerelの機能を使うことで得られる機能そのものの価値と、もう1個上の段階のプロダクトのビジョンも含めてプロダクトを正しく使いこなすことで得られる価値があると思っています。

また、DevOpsやSREといったような、サーバー監視やMackerelに関わる、Mackerelを取り巻くユーザー体験全体が良いものになることをCREは目指して取り組んでいます。

プロダクトに対してフィードバックすることで、プロダクトの機能そのものの価値もどんどん良くすることを目指しているので、CREはユーザーの課題にフォーカスしながらも、プロダクトの価値全体が最大化されることを目指している仕事だなと思っています。

ここで、CREをもしチーム内で立ち上げるとしたらどういうメリットがあるかを紹介したいと思います。内向きには、ユーザーに向き合う時間をチームとしてしっかり割けるというメリットがあると思っています。プロダクトマネージャーの仕事の一部としてこのような取り組みをしているところもあるかと思うのですが、そこに対してCREチームは、明確にコストを払うことになるので、いわば顧客中心主義の文化をチームに明確に取り入れることになるかなと思っています。

外向きのメリットは、CREのこのような支援がMackerelのサービスの1つだと捉えられると、それ自体がプロダクトの強みになります。Mackerelを選んでもらえる理由になるというのがCREがいることの非常に大きなメリットかなと思っています。

最後にまとめです。CREはユーザーの課題解決をミッションとするエンジニアです。CREは、プロダクトの価値を最大化するというところを目指して活動しています。CREチームを作ることは、顧客中心主義の文化をチームに取り入れることになります。最後に、CREの活躍自体がユーザーに向けたプロダクトの強みにもなるというところですね。というところで、私のお話は以上でした。

最後にちょっと宣伝ですが、CREとして一緒に働くメンバーを大絶賛募集中です。支援したいなと思っているユーザーの方がまだまだたくさんいるので、ぜひ助けていただきたいというところもありますし、さっきチラッとユーザーデータからお客さんを知るという話もあったのですが、ユーザーデータを見ながら「ここをこうしたらもっと良い支援になるんじゃないか」とか「解決策になるんじゃないか」とディスカッションをする仲間も求めています。

また、インフラ技術やアーキテクチャをどんどん進化していて、キャッチアップしていくのもけっこう大変なので、インフラエンジニアとしてのスペシャリストという面でも一緒に活躍してくれる仲間を絶賛募集中なので、興味がある方がいらっしゃったらぜひ私にDMをしてもらえればと思います。

ほかにも、CREを立ち上げたいとか、CREの活動そのものについてもうちょっと詳しく知りたいという方がいましたら、ぜひDM等でお声がけいただけたらなと思います。では発表は以上です。みなさまご清聴いただきましてありがとうございました。

司会者：missasanありがとうございました。「CREの方々は特定のプロダクト特化のイメージが強いけど、新しいプロダクトを担当する場合、キャッチアップはどう取り込むんでしょうか？」という質問がきています。

missasan：そうですね。自分がMackerelにジョインした時に何をやったかという話が参考になりそうだなと思うのですが、ダッシュボード上で開いて使える機能をあらかた上から順に自分でも使ってみるというのはすごく心掛けていました。

自分のプロダクトを運用や開発しているプロダクトがあるわけではないので、検証用に簡単なLAMP構成のものを作って監視してみるということをやっていました。新しいプロダクトでユーザーさんがやることをザーッと自分でも実践してみるのはキャッチアップに一番有効なんじゃないかなと思います。

司会者：ありがとうございます。刺さっていそうなツイートを2、3読み上げたいと思います。まずは、ユーザーの自走を目指すというのは複数の方が「すごく良いよね」と反応していましたね。あとは「ユーザー自走を目指すはユーザーのことを知って一歩先のことを予測しないといけないから、それができるのはすごいな」とか、「自走したいわけではなく、ただ話し相手がほしいだけの人も稀に多い」とか。

（一同笑）

missasan：確かにそうですね。最近打ち合わせをして「この界隈の技術はこうですよね」みたいな雑談をお客さまとすることも確かによくあります。インフラエンジニアの方は少数精鋭でがんばっている方がまだまだ多いと思うので、自分の分野に関しての話し相手が業界にいるというのも、CREがいることで喜んでいただけるところかなと確かに思います。

司会者：そうですね。あとは「課題や背景を開発チームにフィードバックする」。これは僕も聞いていてすごく刺さりました。どうしても「こう変えてくれ」と要望を言うほうが簡単ですから、出しやすいんですよね。

missasan：そうですね。ユーザーの方も本当にたくさんのアイデアを持っているので、「何かありますか？」と聞くと、本当にすごくいろいろアイデアをくれます。それ自体はすごくうれしいし、本当に良いアイデアだとそのまま次のスプリントで開発することも実際にあるのですが、腰を据えて課題解決をしたいという時は、一歩立ち戻って背景がどうなっているかをヒアリングすることが多いですね。

司会者：ありがとうございます。それではお時間になりましたので質問・意見については以上にします。素晴らしい講演をありがとうございました。

missasan：ありがとうございました。