mixi engineer blog

*** 引っ越しました。最新の情報はこちら → https://medium.com/mixi-developers *** ミクシィ・グループで、実際に開発に携わっているエンジニア達が執筆している公式ブログです。様々なサービスの開発や運用を行っていく際に得た技術情報から採用情報まで、有益な情報を幅広く取り扱っています。

【CREウィーク金曜日】CRE チームで活きたこれまでの経験

※こちらの記事は過去のブログから転載したものです。

はじめに

こんにちは。XFLAG スタジオ CRE (Customer Reliability Engineer) チームの神です。

今週は CRE ウィークということで CRE チームのメンバー5名が月曜日から金曜日まで毎日記事を投稿しております。

先日開催された Developers Summit 2018 にて株式会社はてな 井上大輔さんの講演「自分」をまるごと活かす!私が"CRE"というキャリアを選んだ理由をお聞きしました。

CRE ウィーク最終日の今日は、そちらを参考に私のこれまでの経験とそれが今の CRE チームでどのように活きているのかを書いてみたいと思います。

これまでの経歴

まずは私のこれまでの経歴について簡単にご紹介します。

最初の就職では仙台のソフトウェア開発会社にエンジニアとして入社しました。 そこでは主に社内用の業務系システムの開発に携わり、経費管理や契約管理のシステムの開発を行なっていました。

そこから転職をしてミクシィに入社し、仙台に設立された CS (カスタマーサポート) センターで SNSmixi」の規約違反対応やその品質管理業務を行なっていました。

その後 CRE チームの前身となる、 CS 開発と呼ばれる CS 部門専任の開発チームへ異動し、現在は CRE チームとして東京で勤務しています。

CRE チームの成り立ちについては、CREチームを設立しました!をご覧ください!

仙台の CS センターでの経験

SNSmixi」の規約違反対応では内製のツール (CS ツール) を使用して対応を行なっていました。

日々の業務を行う中で、オペレーションの効率化やミスの予防、また対応範囲の拡大にともなう CS ツールへの新機能の追加など様々な機能要望が発生します。
こういった機能要望について抽出、整理をし自分で対応が可能な範囲についてはスクリプトやマクロを書いていました。それ以外については CS 開発へ相談するという形で対応していました。

CS 開発へ相談する際のやりとりは、チャットツールがメインでしたが、困っていることは何か、やりたいことは何かなどということを丁寧にヒアリングし確認してくれたためスムーズに行うことができていました。
また、要望をそのまま実装するのが難しい場合は、実装について私が理解できるように説明し別の方法を提案してくれたり、課題の解決に複数の方法がある場合にもオペレーションについて確認した上で提案してくれたりと、こちらに寄り添って考えてくれているのだなということを感じ信頼して相談できていました。

この時に、CS の課題について優先的に対応してくれる専門の開発チームがあるということのありたがさと重要性を認識するとともに、こういう働き方がしたいという思いも生まれ始めていました。

仙台で転職をするか、東京で CS 開発へ異動するかの選択

しばらく勤務したのち CS センターが縮小することとなり、その際に仙台で転職をするか東京へ転勤し CS 開発へ異動するかという重大な選択を私は迫られました。

先ほど述べた、CS 開発のメンバーとのやりとりでこういう働き方がしたいと思ったことと、同じチームで働きたいという思いが決め手となり私は CS 開発へ異動することを決めました。

さらに言うと、簡易なスクリプトなどの作成ではありましたが、課題に対して自分で何かを作って (開発して)誰かの役に立つ嬉しさを再認識したというところもあります。

今の CRE チームでの働き方とこれから

私が現在の CRE チームで業務を行うにあたり指針としていることは以下の2つです。

エスカレーションに対する解決の早さ 依頼をする人が本来解決したいことは何か

まず、解決の早さについてですが CS スタッフからのエスカレーションに対する解決の早さは、ユーザのお問い合わせの解決の早さに直結します。
CSツールの開発においても、より早く実装ができればその分早く対応を開始することができ、こちらも結果としてお問い合わせの解決が早くなります。 お問い合わせの解決は早い方が良いということは明白です。

解決をより早くするために重要なことは、全てを自分で解決することではなく適切にエスカレーションをすることだと私は考えています。

自分が対応可能な範囲の把握やどの段階でエスカレーションすべきかの判断には CS センターで業務を行なっていた時の、自分が対応可能なこと、CS 開発チームに相談することの判断を状況に応じて行なっていた経験が役に立っています。

解決時間をどのように評価すべきかについての指標はtoC サービスの CRE における SLO の考え方もご参照ください。

次に、依頼をする人が本来解決したいことは何か、についてです。

CSツールの開発を例としてあげると、機能要望に対して全てをそのまま実装することがよいとは限りません。
CSツールを使用する側、開発する側の両方で培った経験は、日々の業務で実際に使用している人にしかわからない、実装を把握している人にしかできない提案があるといった気づきをもたらしてくれました。
私は自身の経験を通して、要望されるままに機能を作る人ではなく、課題を見極めて解決できる人でありたいと考えています。

toBtoC それぞれに様々な形の CRE が存在すると思いますが、今の CRE チームでの働き方には私のこれまでの経験が活きていると感じるとともに、この CRE チームでの経験もこれからのキャリアに繋がっていくに違いないと考えています。

この記事を読んで少しでも CRE に興味を持ち、チャレンジしてみたいと思っていただけたら幸いです。