はじめに
Hubble Advent Calendar 2025の9日目の記事です。
こんにちは、HubbleでCREをしている野邉です。
最近はサッカーJ2リーグに熱中しており、応援しているV・ファーレン長崎が8年ぶりにJ1昇格を決め、余韻に浸っております。
さて、本記事では私が入社してから発足したCREでの取り組みについて書きたいと思います。
そもそもCREとは
CREとは、Customer Reliability Engineerの略で、2016年にGoogleが提唱したものになります。
同じような業務をしていても会社によってはCustomer Engineerなど他の名称で呼ばれていることもあります。
CREの主なミッションは、お客様からの信頼を担保することです。
業務内容は会社によって様々ですが、お客様からの問い合わせやフィードバックを受け、調査や改善などを行います。
HubbleにCRE発足
私が入社するまで、CREというポジションは存在しませんでした。
それまでは開発チームのメンバーが日替わりで問い合わせ対応を担当し、新規開発を行う手を止めて対応していました。
聞くところによると、問い合わせ対応が長引くことで開発メンバーのリソースが圧迫し、リリースを遅らせるということもあったようです。
お客様からの信頼を担保するというミッションに加えて、上記のような組織の課題も解決するべく、問い合わせ対応をはじめとするCRE業務を担当するようになります。
CREの苦悩
初めのころは、開発メンバーや仕様に詳しいQAメンバーとペアで調査を行っていましたが、やがて独り立ちの時が来ます。
そこからは、ひたすら愚直に問い合わせ対応と調査を行い、ときには改善活動にも取り組んできました。
こうした日々の中で、「このままのやり方では限界が来るな」と感じる場面が増えていきました。
特に大きかったのが、次の2つの課題です。
初動判断の難しさ
問い合わせ内容を見て、この事象はどの機能に関係しているのか、緊急度はどれくらいか、まず手を付けるべき観点はどれかといったことを素早く判断する必要があります。
問い合わせの内容はとても重要ですが、情報が十分ではなく読み解きに時間がかかることや、本当に解決したいポイントが掴みにくいといったケースも多く、初動の判断に迷いが生まれがちでした。
特にインシデントにつながる可能性がある場合は、初動判断の遅れがリスクに直結します。
「問い合わせの本質を素早く捉える」ことはCREにとって欠かせないのですが、簡単ではありませんでした。
調査の属人化
もうひとつの課題は、調査が属人化することです。
プロダクトの成長に伴いコードが増え、「どのファイルにどの処理が書かれているか」を把握する難易度は上がっていきます。
似たような処理が複数あったり、どこから読み始めればいいのか分からない、過去の実装背景を知らないと理解できないといったことがありました。
こうした構造的な難しさにより、経験の差 = 調査スピードの差 になってしまう状況がありました。
特に、初見の問い合わせほど「どこを見るべきか」を当てるのが難しく、調査に時間がかかったり、調査の進め方が人によってバラついたりする問題がありました。
取り組み
上記の課題を解決するために2つのことを行いました。
1つはAzureOpenAIを活用した課題整理、もう1つはDevinを活用した1次調査です。
※AIの情報を鵜呑みにするのではなく、あくまでも参考情報として利用しています。
AzureOpenAIを活用した課題整理
問い合わせはSlackワークフローで受け付けています。
問い合わせの概要や詳細を記入してもらうのですが、内容の充実度は起票者に委ねられます。
起票者に委ねられるので、欲しい情報が足りなかったり、根本的に何を解決したいのか伝わりにくいこともあります。
また、プロダクトのどこの機能の話なのか、情報はあるがどうやって進めたら良いかわからないことがあります。
それを解決するために、AzureOpenAIを活用して課題整理を行う仕組みを導入しました。
仕組みはシンプルでGASを経由してAzureOpenAIにリクエストを送り、レスポンスをスレッドに返信するというものです。
課題整理を行うことで、何に困っていて何を解決したいのかなど情報が整理され、目先の情報に惑わされず問い合わせの本質を意識することができます。
Devinを活用した1次調査
課題整理することで、困っていることと解決したいことを理解することができました。
次に当たる壁は、該当コードがどこに書かれているのかという問題です。
プロダクトの機能が増え、コードが増えることで、どこでどんな処理が行われているのか把握するのが難しくなります。
そこでコードベースで調査を行うことができるDevinを活用しました。
こちらもAzureOpenAIの課題整理の仕組みと同様です。
問い合わせの詳細をDevinに送り、該当の処理がどんな流れで進んでいるのか、そしてその事象がコード上のどこで発生しているのかをまとめてもらうようにしました。
これによって初見の問い合わせでも、「この辺りが怪しいんだな」とスムーズに調査を進めることができます。
まとめ
これらの取り組みにより、当初感じていた苦悩を解消でき、また、新しくジョインしたメンバーや問い合わせ対応に慣れていないメンバーでも、何をやれば良いのかすぐに理解できるものになるのではないかなと思っています。
初動が早くなり、時間が生まれることで、お客様からの信頼を担保する活動に力を入れることができますね！
明日は @krakazcyrano さんです！