はじめに

こんにちは！アソビューでバックエンドエンジニアとスクラムマスターをしている島田です。

日々の業務で発生する障害対応や問い合わせ対応が特定の人に偏ってしまっていることはありませんか？
まさに直近私が所属しているチームで感じていることです。

この記事は、日々の業務で発生する障害対応や問い合わせ対応が特定の人に偏っていて、

対応できる人を増やしたいけど、何から手をつければいいか分からない
メンバーが協力してくれないわけではないが、なぜか問い合わせや障害対応には及び腰になってしまう

といった悩みを抱えているエンジニアやチームの方に向けて書いています。

障害対応のような緊急性の高い業務は、どうしても個人の知識や経験といった「暗黙知」に頼りがちです。しかし、勇気を出してその課題をオープンにし、チームで向き合うことで、属人化は解消できるかもしれないということをお伝えできればと思います。

なぜチームで解決していく必要があると思ったのか

私の所属チームは8人体制で、ローンチから1年半が経ち、まさに成長期真っ只中のプロダクトを担当しています。新機能を短いサイクルで次々とリリースして利用者も増えてきた故に問い合わせも頻繁に発生するようになりました。

体制変更があったため仕様に詳しくないメンバーもいることや、バックエンドエンジニアとしてプロジェクト立ち上げ当初から携わっていたこともあり、主に私が問い合わせに対応することが多いです。頻繁なコンテキストスイッチで普段の業務はなかなか進まず「今日やろうと思っていた仕事は夕方から…」ということも、しばしばありました。このままでは自分への負荷が大きすぎるだけでなく、チームとしての対応能力も上がらないという危機感がありました。

私たちのスクラムチームではスプリントレトロスペクティブでKPT（Keep, Problem, Try）を使った振り返りを実施しています。そこで「問い合わせ対応に反応しよう！」と問題として取り上げました。実は、これまでも数回同様のProblemを上げたことがあり、その際はHow（どう解決するか）にフォーカスしてTryを実践してきました。しかし、根本的な属人化の解消には繋がらなかったため、今回はWhy（なぜそうなっているのか）を深掘りすることにしました。

流れはシンプルで、以下の3ステップで進めました。

エラーや問い合わせの調査フローを改めて整理する
各メンバーが、どの工程にボトルネックを感じているかを正直に出してもらう
なぜその工程が難しいのか、具体的な理由を全員で話し合う

すると、メンバーは実際に調査・対応すること自体に大きな不安を感じていることが分かりました。同時に、属人化していることへの問題意識は全員が持っており、「もっと協力していきたい」と思ってくれていたことも分かりました。

（余談ですが、本音が垣間見える意見を出してくれたことで、私たちのチームがスクラムの価値基準である「公開」「勇気」を体現できるようになってきたことが、個人的にとても嬉しかったです。）

何がメンバーを不安にしているのか

メンバーと対話したことで「調査する・対応する」部分が不安に思っていることが分かりました。

出てきた意見としては以下でした。

反応すると最初から最後まで一人でやり切らないといけない
業務知識が無くてよく分からない
自身の得意領域でない(フロントエンドが得意なメンバーがバックエンドの調査をする等)
何を見れば良いかそもそも分かっていない
ツールの使い方がよく分かっていない

実際に対話している中で感じたことは知識不足というよりも、心理的ハードルが高いことが原因であると感じました。普段の開発業務ではチーム内への相談とかは頻繁に行われているにも関わらず、障害や問い合わせ対応となった途端に出来なくなるのはなぜだろう？と疑問に思っていたことが腑に落ちました。

第三者(利用者・他部署等)に対して責任を伴うため、「もし調査結果が間違っていたらどうしよう...」「解決できなかったらどうしよう...」など失敗することに不安が多く、それが「反応すると最初から最後まで一人でやり切らないといけない」に繋がっていました。
本来はチームとして解決しなければならないところ、実際に解決した人が最後までやり切っている姿を見てきているからそのように思い込んでいるのではないかと私は感じました。

私も同じ不安を感じているが、なぜできているのか

実際にメンバーの意見を聞くと私も同じ不安を感じているなと思いました。しかし、メンバーから見た私は解決出来る方法を知っている。と映っていたことにも気付きました。
ではなぜ私はその不安を乗り越えられているのかを考えると以下のことを実践しているなと思っています。

目の前で困っている人はもっと不安

アソビューでは「生きるに、遊びを。」というMISSIONと、「For You」「Professional」「One Team」というVALUEを掲げています。
私が障害や問い合わせ対応の第一歩を踏み出せるのは、まさにこのVALUEを意識しているからだと改めて感じました。
自分の不安よりも目の前で困っている人がいて、「その方々達の遊びに対する思い出が嫌なものとして残ってしまうかもしれない」という思いが動機になっています。

まず分かるところまでやってみる

最初から全てが分かることはありません。逆に知識が足りないからといって全てが分からないこともありません。
そのため、まずは「事象を再現してみる」「ログから断片的な情報を集めて整理する」など、分かるところから始めます。そこから、何が情報として足りないかを考え、仮説を組み立てていきます。
その際に分からないことはチームに頼ったりしながら進めていきます。この時に一人で抱え込む必要はなくチームや他の人に頼りながらチームで解決する意識を持っています。

やってみることで知識が付いていることを実感したから

解決する問題が難しければ難しいほど終わった後の知識が上がっていることを実感できます。
例えば、

どのようなユースケースが存在するか
誰にどのような影響があるのか
その時のAPIは何か・データ構造はどうなるか

といったことが分かります。
苦労した分記憶としても定着して、やればやるほど断片的な知識がチャンク化してくるため引き出しが増えていくことで次回の調査等でも役立ちます。

チームで始めたこと

モブ調査

心理的なハードルを下げることを目的に、反応した人が調査時にMeetを立ち上げて2、3人でモブ調査を行うようにしました。
お互いに知識を共有しながら進めることで個人の中にあった暗黙知を知れるきっかけとなっています。その場で仕様などはもちろんのことツールの使い方や調査する過程も分かるので学びになります。

チーム特化のエラー通知チャンネルを作成

「そもそも通知に気づけない」という物理的な課題もありました。
アソビューではエラー通知をslackに流すようにしています。しかし、全プロダクトの通知が一つのチャンネルに流れるためメンションを付けていても流れてしまい、通知に気付けない課題があったのでチーム専用の通知チャンネルに流すようにしました。これにより、チームとして見るべき情報が限定され、まずは「全員がエラーに気づける」状態を作ることができました。

調査の過程を可視化するようにした

これまではSlackのスレッドに調査過程を記載していましたが、口頭でのやり取りが記録に残らなかったり、過去の類似事象を探すのが大変だったりと、情報がその場限りになりがちでした。
そのため、調査手順や解決方法についてはConfluenceにまとめることで毎回1から調査するのを避けられるだけでなく、他のチームメンバーでも対応できるように改善しました。

また、エラー通知の調査結果はDatadogのActivityに記載することで探す手間や調査有無の必要性を判断できるようにしました。

まとめ

今回、自分がネガティブに感じていたという問題を、勇気を出してチームに共有したことで変化が生まれました。メンバーが抱える「不安」を具体的に知ることができ、それを解消するための仕組みをチーム一丸となって作ることができました。まだ改善を始めたばかりですが個人のスキルや意識だけの問題ではなく、チームの仕組みと文化で乗り越えられるのだと実感しています。