はじめに
BASE BANK Department で エンジニア をしている池田聖示です。
入社して1年が経ちましたが、この間、アラートやお問い合わせの対応に積極的に取り組んできました。
今回は、その理由や意識していたことを振り返ってみようと思います。
アラート対応、ユーザーからのお問い合わせ対応の価値
主語を大きくしたくないですが、多くのエンジニアにとってアラート対応などは敬遠されがちだと思います。
確かに、集中して取り組んでいるタスクを中断しなければならないこともあり、スイッチコストもかかります。
しかし、私はアラート対応やユーザーからのお問い合わせ対応の業務に大きな価値があると考えています。理由は、以下のような形で自分自身の成長にもチームへの貢献にもつながるからです。
- キャッチアップにつながる
- 問題解決能力の向上
- ユーザーの声に直接触れる貴重な機会
キャッチアップにつながる
私が所属しているチームでは、主に4つのプロダクトや機能を担当しています。
積極的に開発しているプロダクト以外は、なかなか普段のタスクでシステムの詳細を追うことが難しいです。
アラート対応やお問い合わせ対応を行うことで、データ構造や該当処理のコードを追うことができてシステムへの理解が深まります。
また、このエラーを出さないためにはどんな設計にすれば良いのか、どんなハンドリングが適切か、などを考えることができてエンジニアとして技術力を上げる機会になると思います。
実際に、エラーハンドリングの修正PRを上げることや、プロダクトのドキュメントに記述を追加するなどのアウトプットを行い、チームの資産にすることもできたと思います。
問題解決能力の向上
アラート対応やお問い合わせ対応などを行う際に、エンジニアだけに閉じず、他職種の方と連携して解決することが必要な場合があります。
例えばお問合せをもらった際に、「このような意図であっているか」、「更にこういった情報が欲しい」といった連携をしたり、
「システム的にこんな状態になっているのでユーザーに伝えたいがどんな風に伝えるのが適切か」などの相談をしたりと、コンテキストを共有することや、問題解決までの道のりを一緒に描くなどの職種を超えた連携の力を育むことができます。
ユーザーの声に直接触れる貴重な機会
ユーザーからのお問合せを受けることで、どのように機能を使っているか、どんなことで困っているのか、という情報に直接触れることができます。
ユーザーと向き合っている実感が持てる貴重な機会だなと思うと共に、
こんな風にヘルプ情報出したら良いかも、こんなUIにしたら分かりやすくなるかも、という考える機会になるためエンジニアとしての視野を広げることができると思います。
実際にどのような流れで行っているか
実際には概ね下記のような流れで行っています。
お問い合わせの場合
- お問い合わせ文を見て回答すべきことを確認する
- 回答の根拠となる、情報を集めに行く
- 対象のソースコード、DB、ヘルプページ、ドキュメントなど
- 情報の整理を行い、回答する
アラート対応の場合
- アラートが発生したらSlackの通知が飛ぶので、そこからSentryを見に行く
- 該当ユーザーのデータを確認しつつ、リカバリー必要の有無を判断して実施する
- リカバリーが必要であればクエリを書いたりなどの対応を行う
- 根本原因を調査
- 根本原因への対策を検討
- EPMやPdMとすり合わせて優先度付けを行う
意識していること
- お問い合わせの回答をする際に、どの情報を、どのように伝えれば過不足なく理解してもらえるか
- 根本原因への対策が運用手順書に書いてあったとしても、「なんでこの優先度の意思決定になったのか」などを追うことで、自分自身の成長に繋がるためissueを追って見たりします
- 進め方や解決策に関して積極的にフィードバックをもらいにいくことで、本当に良かったか、もっと良くするための方法を吸収していく
参照：EPMとは
具体的な得
冒頭の結論で書いた「キャッチアップにつながる」、「問題解決能力の向上」、「ユーザーの声に直接触れる貴重な機会」でも記載した内容と重複するところもありますがまとめると下記の3点だと思います。
- エンジニアとしての技術力の向上
- 仕事の進め方が良くなる
目の前の問題を解決するだけではなく、「もっとスムーズに解決するためには」、「そもそも起きないようにするためには」などのことを思考することで上記のような成長に繋がると思っています。
大変なこととその対処法
一時的にマルチタスクになると思うので忙しい、スイッチコストがかかるなどの負担があると思います。
ただ、EPMやマネージャーなどに適切にエスカレーションを上げることで、忙しいという面は解消できていますし、この相談も仕事の進め方能力向上につながると思っています。
具体的には、下記のような流れでEPMやマネージャーとコミュニケーションをとっています
- 目の前のアラート対応やお問合せ対応の緊急度を判断（既知の原因でのものか、機会損失になるか、今後のユーザーに影響が出るかなど）
- 目の前のアラート対応やお問合せ対応の概算の工数を見積もり、今の自分のタスクにどの程度影響が出るかを判断（30分程度で終わりそうであれば、その場で対応して終了）
- 必要があればissueを作成して重要度と緊急度なども含めて概要をまとめる
- 差し込みで対応するべきかバックログに積むかを検討してEPMやマネージャーと相談
- 差し込みでの対応なら見積もりなども踏まえて、差し込み前に対応していたissueの期限などを調整
意識していることは、アラートのスレッドや、お問合せのスレッドなど細かく現状の報告をするようにしています（調査開始時や、調査が長引きそうな時の中間報告など）
温度感や難易度などの情報をEPM・マネージャーと共有するために必要だと思っています。
補足：
私が所属しているチームのEPM・マネージャーがデイリーなどで、良しなに調整してくれているケースが多いので、私自身あまり差し込みで逼迫した経験がない前提ではあります。
まとめ
アラート対応や、お問合せ対応は、大変な側面もありますが、個人的には得られる経験値は膨大であると思っています。
入社後のキャッチアップスピードを上げる。エンジニアとして技術力を上げる。仕事の良い進め方を身につける。など、意識次第で成長角度を上げることができるチャンスだと思います。
おわりに
今まで書いてきたことは私のチームが、メンバーの成長をサポートするという土壌が豊かであるという前提のものです。
アラート対応やお問合せ対応から成長するためには、適切なフィードバックやアドバイスが不可欠です。
BASE、BASE BANKでは一緒に働く仲間を募集していますので気になった方はぜひ下記リンクを見ていただけると嬉しいです。
