この記事はOPENLOGI Advent Calendar 2023の4日目の記事です。
オープンロジではCREチームがFY23に発足し、もうすぐ発足から１年が経つところになります。
私は発足のタイミングでチームに参加しておりチームとしても個人としてももうすぐ１年経つことになるため、節目として１年間で取り組んだことの振り返りをしてみようと思います。
すでにCREとして働かれている方、これからCREとして働くことやCREチームを立ち上げることを考えている方の参考に少しでもなれば幸いです。
そもそもCREとは何か
CREとは、Customer Reliability Engineering（顧客信頼性エンジニアリング）の略で、Googleが提唱した専門職です。
一般的にCREは”顧客信頼性の向上”が目的とされていますが、具体的な仕事内容は様々であるかと思います。
イメージとしてはテクニカルサポートやエスカレーションエンジニアといったようなユーザーからの技術的なお問い合わせに対応する職種と近いかと思いますが、実際に顧客対応経験や開発経験がどの程度求められるかは具体的な業務内容により異なるのではないでしょうか。
近年SaaS企業ではCREをおく企業が増えている印象ですが、CRE自体の認知度としてはまだまだでこれから発展していくであろう職種になるという印象です。
CRE発足の背景
弊社では元々エンジニア側でお問い合わせを専門に担当するチームはなく、プロダクトに関する技術的なお問い合わせについて自チームで対応が難しい場合は、"CS→PdM→各エンジニアチーム"の流れでエスカレーションされるようになってました。
そうした状況下においてお客さまの増加に伴ってお問い合わせ量の増加や質の多様化が進んでおり、各チーム（特にCS）の対応工数や負荷が増えてきているという問題がありました。
また、PdMや各エンジニアチームはそれぞれ別の本来の業務を持ちながら並行してお問い合わせ対応をしていたため、例えばお問い合わせ対応ナレッジを作成するなどのお問い合わせ対応を効率化するための取り組みが進みにくい状況になっていました。
こうした背景があり"お問い合わせ対応を専門に扱うチームを立ち上げよう！"ということになりCREが発足される流れになりました。
Before(CRE発足前）
After（CRE発足後の期待効果）
取り組んだこと
基本的な業務としてはいわゆるテクニカルサポートのような技術的なお問い合わせの対応がメインの業務となりますが、このお問い合わせ対応業務を支えるために、お問い合わせの集計・分析と社内向けお問い合わせ対応ナレッジ作成にも取り組みました。
これらの取り組みを通して、日々のお問い合わせ対応をより早く正確に効率的にこなせるように改善のサイクルを回してきた形になります。
お問い合わせ対応
基本的な流れとしてはお客さまからCS宛に届いたお問い合わせの中で技術的な内容を含みCSで対応が難しいものはCREにエスカレーションされます。
＊ちなみにCREへのお問い合わせの受付にはSlackのワークフロー、ステータスや対応ログの管理はRedmineを使っています
CREではお問い合わせの一次受付を担当し、その後はCRE自身で調査・対応することもあれば難易度が高い場合はさらに各開発チームにエスカレーションすることもあります。基本的には社内の担当者向けに最終回答するまでが業務範囲ですが、場合によっては直接お客さまとコミュニケーションして解決策を探ることもあります。
また、後述のお問い合わせの集計・分析の項でも触れますが、お問い合わせは大きく分けて運用作業系、調査系、相談系の３つに分けられます。
・運用作業系は、プロダクトの画面上で設定作業、SQLでデータの抽出や更新、SSHでサーバに入ってコマンド実行などがあります。
・調査系は、実際にプロダクトを触ったり、コードを読んだり、Athenaでログを調べたり、SQLでデータを調べたり...と様々な観点からトラブルの原因やプロダクトの仕様などを探りながら解決まで導きます。
・相談系は、ユーザーが実現したいことを深掘りながら、実現可能かどうかやどのように実現できるかを探ります。
いずれもエンジニアとしての基礎的な能力、プロダクトに関する知識や業界の（弊社だと）物流のドメイン知識、課題解決力や説明力などが求められる能力になるかなと思います。
お問い合わせの集計・分析
CREではただお問い合わせ対応をするだけではなくお問い合わせ対応の効率化やそもそもできるだけお問い合わせをしなくてもいい状態を目指しており、そのための第一歩としてお問い合わせデータの集計・分析をしています。
これは様々な観点からトライアンドエラーで集計・分析しているのですが、現状だと回答リードタイムの計測とお問い合わせの分類が活用されているデータになります。
回答リードタイムの計測
各お問い合わせの回答までのリードタイムを把握できるように集計しており、遅くなりすぎないように注意しています。１次回答リードタイムと解決リードタイムの２種類を集計しており、特に１次回答のリードタイムをできるだけ早くすることと拾い漏れをなくすことを意識しています。
（解決リードタイムはお問い合わせ内容に左右され指標としては扱いにくいため）
お問い合わせの分類
お問い合わせの分類を以下の４つに定義した上で、各お問い合わせについてラベリングを実施しています。
仕様調査...何らかのシステムにおける操作や処理においてどのような挙動や結果になるかを知りたい
原因調査...何らかの実際に発生した想定外のシステム上の挙動や結果に対してなぜそうなったかを知りたい
運用相談...ユーザーが実現したいことがシステム上で実現可能かどうかを知りたい
運用作業依頼...事業側で対応できない設定作業やデータ抽出・更新作業などをエンジニアに依頼したい
このラベリングは主に以下のようなお問い合わせ対応効率化の取り組みに活用しています。
・お問い合わせの全体傾向を把握した上でお問い合わせ対応効率化のためにどこからアプローチするかを探る
・後述のナレッジ作成について、期待効果の高い書くべきネタを探す
・後述のナレッジ作成について、分類ごとに書き方を型化する
この分類は後述のナレッジ作成において活用できている部分はありますが、お問い合わせ対応の効率化に向けて具体的な改善につなげるにはもう少し詳細なラベリングと分析が必要であるというのが正直な感想ではあります。
＊ちなみにこのラベリング作業については機械学習で自動化してみたので、興味ありましたらぜひ以下の記事をご覧ください！
CREチームへのお問い合わせをscikit-learnでラベリングしてみた
（社内向け）お問い合わせ対応ナレッジ作成
お問い合わせ対応の効率化を目的に、日々のお問い合せ対応の中で得られたナレッジをFAQの形式で社内Wikiをまとめています。記事はよくあるトラブルの原因と解決策を記載するトラブルシューティングとプロダクトの機能や仕様を記載する機能・仕様案内の２種類にカテゴライズして作成しています。
- 社内Wikiの画面イメージ
記事を読むことでCREへエスカレーションしなくても自己解決できるのが理想ですが、自己解決はできなくてもCREにおける対応工数の削減につながるように意識しています。
網羅的に情報を揃えるにはある程度記事数が必要になるため週１くらいの頻度で定期的に記事を追加しており、古くなった情報が放置されないように過去記事を定期的にチェック・更新するようにしています。
最終的には「プロダクトについて困ったことがあったらまずこのページを見ればいい！」という状態を目指していますが、現状の活用状況はそこまで到達していないので今後に改善していきたいところです。
CRE発足により改善されたこと・難しかったこと
取り組みの振り返りとしてCRE発足後の期待効果の期待効果がどの程度実現できたかや、取り組みの過程における良かったことや難しかったことを「他チームの業務負荷軽減に寄与できたか」と「CREチームの職務・職責について」の２つの観点から振り返ります。
他チームの業務負荷軽減に寄与できたか
弊社では特にCSの方の負荷軽減というのがCREのメインミッションとしてあったのですが、CSの方からは「以前よりも質問しやすくなった！」や「社内Wikiのおかげで自己解決できた！」という声を聞くこともできたので、一定程度寄与できているという感覚はあります。
これはCREチームができたことで先述での取り組み内容についてしっかり工数をかけて取り組めたことが大きいのかなと思います。
また、CREをおくということは全社的に技術的なお問い合せ対応に力を入れて対応していくという意思表示とも取れるので、エンジニアに質問する時のスキーム自体は同じでも、CREをおくことによってCSの方がエンジニアに質問することへの心理的なハードルが下がる効果はあるのではと感じました。
（＊エンジニアは怖いというイメージを持たれがちではあるので・・・）
エンジニアの運用工数削減については副次効果として期待されていたところではあるのですが、これまではエンジニアが担当していた運用作業を一定数CREで巻き取るようになり、またナレッジも以前よりは整備されてきてはいるので、エンジニアからも「運用作業の工数が減って楽になった」という声は聞けたりもしています。
ただ、正直なところ定量的な効果を出すの難しい部分ではあるのですが、今後社内向けのアンケート等で検証していきたいとは考えています。
ここまでをまとめると、技術的なお問い合わせ対応が何らかの形で事業成長や組織成長のボトルネックになっている場合にCREをおくというのは選択肢としてあるかなとは率直に感じました。もちろんCREをおくことでその分のエンジニアの工数を取られる側面もあるので、そこはCREをおくことによる期待効果とのトレードオフで考える必要があるのかなと思います。
CREチームの職務・職責について
上述の取り組んだことにもある通りCREの業務はお問い合わせ対応がメインとなっており、これはもちろんとても大事な取り組みではあるのですが、ただお問い合わせ対応するだけのチームにならないようにしたいという思いがありそこが難しいところでもありました。
CREのミッションから考えた時にお問い合わせ対応以外で自分達からどういったアクションをとるか？またCREは雑用などの便利屋的なことを求められがちではあるがそれらの業務は本当にCREがやるべきなのか？そういったところの職務・職責をどう定義していくかは難しいところだなと感じました。
また、CREが開発をするかどうかは会社によって変わると思うのですが、できるのであればCREも開発した方がいいのではないかと感じています。CREはプロダクトを触る機会が多いので細かい改善点に気づくことが多いのですが、CRE以外の開発チームで対応しようとするとなかなか優先度が上がらないことも多かったりします。CREの中で開発できるとプロダクトの改善も進みやすく組織としても良いですしCREエンジニアのキャリアとしてもプラスになるのではないでしょうか。
最後に
オープンロジではCREだけでなく複数のポジションで仲間を募集しておりますので、ご興味がある方はぜひご覧ください！
ここまでお読みいただきありがとうございました。