こんにちは。MackerelチームでCRE（Customer Reliability Engineer）をしている 
id:a-know です。今年の7月から、岡山県倉敷市よりフルリモートで働いています（そして現在は半育休期間中です）。
はてながCRE職を新設したのが2017年8月。それから約2年たち、同じようにCRE職を立ち上げる企業の数も増えてきたように思います。その様子を見て最近思っているのは、「CRE職に求められていることや在り方は、企業ごとに結構違いそうだなぁ」ということです。というわけで今回は、「はてな（Mackerelチーム）のCREと開発チームとの関わり合い」にフォーカスして、その様子をご紹介できたらと思います。
Mackerel の開発について
Mackerel の開発チームでは、スクラムのプラクティスを部分的に取り入れた開発をおこなっています。"プロダクトバックログ" "スプリントバックログ" を ZenHub を用いて管理していて、2週間1スプリントとし、スプリントごとにバックログリファインメントやスプリント計画のためのミーティングの場を設けています（といった全体を、Mackerel の開発ディレクターであり認定スクラムマスターでもある 
id:daiksy が管理しています）。こうした開発スプリントが回っている場にCREがいる風景をご紹介する、というのがこのエントリの主題となります。
Mackerel というプロダクトと CRE
CREは、他の職種・ロールに比べ、お客さまとのやりとりが多いロールです。そして、セールスメンバーとの接点もまた同様です。また、Mackerel という技術プロダクトに対してエンジニアリングのバックグラウンドを持つ者としてCREを担っているわけですので、「お客さまの声を適切に社内に届ける」ということは義務に近いと私は考えています。
今現在、お客さまからの声を取り入れるため・そしてその成果をお客さまに届けるために実施していることは、以下のような取り組みです。
"ビジネスサイドバックログ" を持つ
週に一度、セールスメンバーとのミーティングの場があるのですが、この場で「その一週間でお伺いしたお客さまからの要望や導入のハードルになってしまった点」をヒアリングしています。そしてこれに、CREとして収集したお客さまからの声や、「自分自身が Mackerel ユーザーとして感じること」も含めマージして、開発チームが持っているプロダクトバックログとは別にバックログ（のようなもの）を持っています。いまのところ "ビジネスサイドバックログ" といった感じの名前で呼ばれることが多いのですが、名称はもっといいものを付けなきゃな、とは思っています......。名付け、難しいですね。
そしてこのバックログについては、いまのところ GitHub Projects を使って管理してみています。この時点では、issueではなく Project の card としてひとまず簡易的に登録しておくことが多いです。そのすべてをお見せすることはできないのですが、以下のようなかんじになっています。
最近、狩野モデルの考え方を取り込み整理のしやすさの向上を図っているのですが、この先もずっと続けるかどうかはもう少し様子を見たいと思っています（その前は「すぐに欲しい機能」「いつか欲しい機能」などにしていました）。あとこれは少し余談なのですが、"CREがチャレンジ" というレーンもあります。Mackerel には OSS プロダクトも複数あり、CRE自身で出来そうなものは積極的にチャレンジするようにもしています。
"ビジネスサイドバックログ" に対してオーナーシップを持ちメンテナンスする
そしてこのビジネスサイドバックログに対するリファインメントを、これまた開発チームのバックログリファインメント会とは別に、CREチームだけで実施しています。その頻度は、セールスメンバーとのミーティングの頻度に合わせて毎週実施するようにしています。
このリファインメントの場では、以下のような点についての話し合いをCRE内で実施しています。
- その要望について、各CREメンバーは率直にどう思うか
- 要望の根っこの部分は何なのか、その理解や把握のための議論
- 狩野モデルに基づく要望の種別の分類
その後、cardをアーカイブすることもあれば、プロダクトバックログのリファインメントの場で提起する（後述）ためにissue化することもあります。issue化する際には、議論の結果をissueタイトルやdescriptionに反映する形になります。また、CRE内だけで納得のいく結論を見いだせなかった場合には、社内グループウェアでさらに広い範囲の人に対して意見を求めたりすることもあります。
こうしてメンテナンスをしたのちに、隔週（スプリント毎）のバックログリファインメントの場に臨みます。
バックログリファインメントに参加する
"ビジネスサイドプロダクトバックログ" と "プロダクトバックログ" のすり合わせの場が、隔週でのバックログリファインメントの場になります。ここにはプロダクトオーナーや開発ディレクター、Mackerelチームのテックリードが参加しているのですが、そこにCREも参加するようにしています。
ここで、あらかじめCRE内で認識合わせをしておいたバックログアイテムをプロダクトバックログに乗せてもらえるように話をするわけです。プロダクトバックログ内での優先順位は、プロダクトオーナーに判断してもらっています。
スプリントレビューに参加する
打って変わって、開発が完了したあとについてのお話です。
スプリントレビュー会も、スプリントごとに実施されています。そのスプリントでリリースされた機能について、開発チームに直接説明を求めるための場です。説明を求める、といっても、開発チームから機能ごとに事細かに説明をしてもらうわけではなく、「そのスプリントでリリースされた機能一覧」をCREが確認し、「これはどういう変更なのか？」と疑問に感じたものについてより詳細な説明を求めることができる、そういった場になっています。それで済んでいるということも、エンジニアとしてのバックグラウンドを持つCREが担当しているからこそだと思っています。
そして、このレビュー会で得たものをもとに、Mackerel 公式ブログでのリリース記事をCREが執筆する、という流れになります。
リリースされたことに気づかれず、使われることのない機能は、デリバリされていないに等しく、このようにブログを書いて広くお知らせしたり、ときにはお客さまに会ってそのことを直接お伝えしたり、といったことも、立派なプロダクトデリバリの一部であり、それをCREが担っているのだと考えています。
こうしたCREの動きによる最近の（そして比較的大きめな）成果としては、以下のリリース記事でご紹介している、サービスメトリックの送信途絶監視機能です。
毎日のようにたくさんの要望をいただいており、ともするとバックログアイテムも溢れがちになるのですが、今後もその整理とエスカレーションに積極的に携わっていき、CREとしてプロダクトの改善や向上に貢献していきたいと思っています。なので、ご利用の皆様もぜひどんどんご意見・ご要望を挙げていただけたらと思います。
開発チームとのコミュニケーションパスとしての役割も
またMackerelは、パートナー企業様とのアライアンスを組ませていただけるような側面もあるプロダクトです。
ときには、ビジネス要件が少し複雑になる局面もあります。そういうときに、ビジネスの最前線に立っているメンバーと開発担当者との橋渡し役を担えるのもまた、CREならではの役割だと考えています。
セールスメンバーと開発担当者との直接のやりとりを拒むものではもちろんありませんが、CREとして同席することで「なんだかスムーズに話ができた気がする」という局面を増やすことができたことも、事実としてあったと自負しています。
おわりに
「CREのいる開発スプリントの風景」というタイトルで、CRE というロールが Mackerel というプロダクトの開発にどのように関与しているか、その一端をご紹介しました。
はてなにおけるCRE職の在り方については、今のところは以下のようなページをご覧いただければと思うのですが、
今回ご紹介したように、CREの新しい動き方というのも出てきており、また "カスタマーサクセス" に対する CRE 職の可能性を感じていることのなどもあって、そろそろ「はてなCRE ver.2」のようなものを再定義しなければいけないかな、とも感じています。その際にはまた、こちらでご紹介できたらと思います。
また、この記事のような形でその働き方を自らで切り拓いていける仕事であるCRE職では、一緒に働ける新たなメンバーを募集しています。まずは気軽なお話からでも構いません！上記採用ページからぜひお問い合わせください！
