はじめに
お久しぶりです。Customer Reliability Engineer (CRE) のmayuzoです。
前回の記事アンドパッドのCREチームを紹介します！ - ANDPAD Tech Blogを書いてから１年が経ちました。早いものです。
おかげさまでCREというチームも成長し、１年前に比べると人数も倍になりました！
その間、サービスや利用者数もかなり増えているので、CREの仕事や守備範囲も増えてきました。
最近は採用面接もを担当しているmayuzoですが、先日こんな質問をもらいました。
「アンドパッドのCREとして求められることや客観的な期待値を知りたいのですが、何か発信しているものはありますか？」
おおお！ありませんね！！！！
残念ながらテックブログにもご無沙汰で、まだまだ「アンドパッドのCREとはこんな仕事だ！」という発信が足りていないと気付かされました。
上記の反省を生かして、今回は私が思う「一人前のCREとしての期待値」について書いてみます*1。
一人前のCRE？
ここでは、主要業務である問い合わせ対応に絞って書きます。
先述した通りCREメンバーも増加し、「CREとして問い合わせ対応が十分にできる（＝一人前）と言えるようになるには、何を指標にすればいいのか？」ということを考える機会が増えました。
問い合わせ対応は以下のプロセスに分解でき、最後までやりきることができれば、その人には１サービスを任せられると私は考えています*2。
- カスタマーサポート・カスタマーサクセス・セールスのメンバーからの問い合わせを受け、その内容を理解する
- 不具合の場合は再現確認をする／仕様確認の場合は挙動を確認する
- ログ調査やデータ調査をする
- わかった事象・ユーザーが遭遇した事象に対して「仕様として正しいか」「ユースケースとして想定されていたか」を検討する
- 上記の検討を元に、プロダクトマネージャー（PdM）やソフトウェアエンジニア（SWE）とあるべき仕様について相談・改善提案する
- 一連の流れを踏まえて問い合わせ者に回答する
4以降がいきなりハードル高いですが、まぁそうなのです。
アンドパッドのCREは、プロダクトの定義に関われるのです。
開発本部の中でユーザーに一番近いのはCREですから、その知識・経験をプロダクトに生かしていけるポジションです。
大事なのは「要約と言語化」
話を一人前のCRE基準に戻します。
１番大事なのは仕様理解です。
再現確認をするにも、どういった手順で操作するのか、その操作が想定していた操作なのかの理解は非常に重要で必須です。
ただ、入社間もない場合や新プロダクトの場合、いきなり理解を深めるなんて無理ですよね。
では、どうすればいいのか。私は「要約」と「言語化」が重要と考えています。
CREとして調査を開始すると、必ずどこかで行き詰ります。自分の能力だけで解決できないことは、他のその仕様に詳しいCREに聞いたりします。
この時、「どこまで自分（調査者）が理解できていて、どこからがわからないのかを伝える力」が必要です。
CRE内で相談する段階
相談されたCREは、「調査者がどこまで調査して、何を知りたいのか、何をすれば解決に至りそうか」をまずレビューします。
私は、レビューに出す前に調査過程をチケット*3に残すようにお願いしています。
どういった過程でその結果が出たのかわからないと、今後の打ち手もお伝えできないからです。
レビューを受けたら、調査者は調査を進め、その結果をチケットに再びまとめます。
仕様調査の場合は、仕様を（できれば意図とともに）書いてもらうようにします。
こうしてメンバーは調査方法と仕様理解を進めていき、自分一人の力で調査をやりきることができるようステップアップしていきます。
（もちろん、そんなに簡単にステップアップできないのですが…。ここは地道な作業です）
チームを超えて相談する段階
ここまでに１～２回、「チケットに文章でまとめる」という作業があります。この作業ができるようになると、プロセスの５・６がやりやすくなります。
調査をしてどうやら不具合らしい（仕様によっては不具合ではないが、ユースケースを考えると改善した方がいい場合が往々にしてあります）とわかったら、今度はSWEやPdMと修正可否や修正方法を相談します。
ここでチケットに調査過程・改善要望がまとめてあると、会話がしやすいです。
CRE内では、最低限以下の内容を書くように決めています。
- 再現環境と再現手順・結果
- 再現した時のキャプチャ
- 修正依頼内容
- 修正依頼の理由
問い合わせ者も含めた関係者が、「何が起きていて、今後どうすべきか・したいのか」を、チケットを見れば把握できる状態を意識しています。
残念ながら、チケットが作成された瞬間に解決される問題ばかりではありません。数週間など時間が空いた後でも、手を付けやすくなっているのが理想です。
回答する段階
最後の回答の段階では、これまでわかったことを問い合わせ者に「まとめて（要約して）」、技術的な言葉を最低限にして「言語化」することが必要です。自分たちの発信した内容が開発・プロダクトの公式見解になるので、非常に気を遣います。
ここでやはり、チケットにまとめていることが役に立ちます。
また、慣れないうちは以下のようなフォーマットを用意して、内容に抜け漏れがないか確認しながら記載しています。
- 起こっていること
- 回答例：〇〇が〇〇となるのを確認しました。（常に「誰・何が」「どうなる」を書く。）
- 本来の仕様
- 回答例：こちらは〇〇となる仕様です。
- なぜ今の動きになるのか
- 回答例：〇〇の設定が〇〇となっているため、表示されない内容があります。
- 対応方針
- 回答例：見づらいので、〇〇となるように改善を検討します。
- 回避策
- 回答例：修正されるまでは、〇〇をご利用いただけますでしょうか。
ここで書けない内容があれば、問い合わせ内容理解や仕様理解が不足しているとわかるので、再度調査内容を振り返ってもらったり、チームメンバーから意見をもらったりします。
まとめ
現在は、こうして段階的にCREとして仕様理解と言語化に強くなっていける仕組みを構築中です。
1～2年前は「とにかく調査！わかったら回答！」という、速さ重視のオペレーションで、チケットへの記述は今よりもおざなりでした。
けれど、これでは同じことを調査・説明する必要があったり、時が経てば何のことかわからない、という弊害もありました。
結局「最初にしっかり書く」という当たり前のことをすることで速さを手に入れられたと思っています。
「書くこと」は「伝えること」です。個人的には、私の書いたものを受け取る人がスムーズに次の作業ができることを意識しています。
つくづく、CREはコミュニケーションが要のチームだなぁと思います。
CREに限らず、よい開発をする上でよいコミュニケーションは必須ですし、その筆頭となるチームでいたいですね。
おわりに
問い合わせ対応とは少し別の視点ですが、今は「アンドパッドで働くメンバーが開発に問い合わせなくてもANDPADの仕様を知ってもらえる仕組みを作る」を１つの課題にしています。
メンバーが急激に増えていますが情報は分散していて、さらにはサービスもどんどん拡大して、仕様確認の問い合わせが多く来るからです。
取り組み始めたばかりなので、次回ブログを書く頃にはこの辺の方法のお話なんかをできればいいなぁという希望を書いて終わりにします。
まだまだやりたいことがたくさんあるので、メンバーを大募集しています！
興味を持っていただけましたら採用サイトにもお越しください。
engineer.andpad.co.jp
