ジモティーでバックエンドとインフラを担当している吉田です。
およそ10年ぶりに登山用のバックパックを新調したので、さっそく神奈川県の丹沢に行ってきました。鍋割山から塔ノ岳、三ノ塔と縦走して、いったんヤビツ峠に降りたあと、大山まで行くのがお気に入りのコースです。丹沢には何年も通っていますが、今年始めてヒルに吸血されました（一度に両足全3箇所）。
さて、今回は、社内のエンジニアが継続的に行っている、エンジニアへの問い合わせの取り組みについて紹介します。
- エンジニアへの問い合わせとは？
- ⛰️1合目: 特定エンジニアへの集中
- ⛰️3合目: 問い合わせ対応のオープン化
- ⛰️5合目: エンジニアリングサポートチームの発足
- ⛰️8合目: 輪番制の導入と目的の確認
- まとめ
- 最後に
エンジニアへの問い合わせとは？
まず、「エンジニアへの問い合わせ」についての説明です。これは、非エンジニアメンバー（カスタマーサービスやコーポレート部門など）からエンジニアへ日常的に行われる質問や相談のことを指します。
例えば次のような問い合わせがあります。
- 🙋♀️ 「データ分析ツールがエラーになるので対応をお願いします」
- 🙋 「連携サービスでメンテナンスが予定されているので、対応が必要か確認をお願いします」
- 🙋♂️ 「この機能改修の工数見積もりをお願いします」
これらの問い合わせは、すぐに解決できるものから、目的や背景を確認して代替案を相談しながら解決に向かうものまで様々です*1。
⛰️1合目: 特定エンジニアへの集中
私が入社した2017年4月頃、エンジニアと非エンジニアに関わらず、問い合わせ先は特定のベテランエンジニアに集中していました。
そのエンジニアは在籍年数が長く、サービス仕様の経緯や組織の内情に非常に詳しいため、「エンジニアリングの質問や問題はあの人に聞けばすぐに解決できる」という認識が広がっていたと思います。
この問題は次になります。
- 質問者と対応者の2者間で情報が閉じているので、同じ質問が発生する
- 対応する特定のエンジニアに対応負荷が集中する
実際、そのエンジニアの座席に問い合わせ者の列ができる事もありました。
⛰️3合目: 問い合わせ対応のオープン化
そこで、2017年5月に問い合わせ専用の Slack チャンネルを開設しました。
チャンネルは「エンジニア外との会話」と「エンジニア内での会話」の2つで、用途によって使い分けるようにしました。
- エンジニアへの質問部屋
- 用途: 他部署からエンジニアへ質問、相談用
- エンジニア以外のメンバーに対しても分かりやすい説明が必要
- エンジニア間の質問部屋
- 用途: エンジニア同士で質問、相談用
- より専門的な議論が可能
この施策によって情報がオープンになり、複数のエンジニアが回答するようになったため、問題が一気に改善しました。開設当時のメッセージを読み返すと、問題解決や議論の好きなエンジニアが多く、副次的にエンジニア内外のメンバー間の交流も進んだと思います。
また、問い合わせの対応ログや知見は情報共有ツールの Kibela に残す事を推奨し、特定のメンバーしか対応できない問い合わせをなるべく少なくする方針も周知されました。
⛰️5合目: エンジニアリングサポートチームの発足
数年間は大きな問題もなく運用できていたのですが、徐々に放置されたり、最初の反応に時間のかかる問い合わせが多くなっていきます。そして、ついに他部署からたびたび改善要望が発生するようになってしまいました。
この要因は次であったと分析しています。
- メンバーが入れ替わり、エンジニア内で対応の相談が気軽にできなくなっていた
- そのため、DM でやりとりされている事も多かった
- 担当案件に集中するあまり、優先順位がいつの間にか落ちていた
そこで、2023年1月に問い合わせ対応専門のエンジニアリングサポートチームを立ち上げました。
バックエンド担当の若手メンバーが中心で、気軽に相談し合えるように専用の Slack チャンネルを開設しました。また、3ヶ月ごとに設定する個人目標の一部にこの取り組みの成果を含め、メンバーの OKR を統一する事で、チームとして取り組めるようにしました。
⛰️8合目: 輪番制の導入と目的の確認
しばらくすると、今度は対応するメンバーの固定化が問題になってきました。
対応したメンバーはその経験によって、知識の幅が広がり、さらに回答できるようになります。そのメンバーにとっては非常に良い成長サイクルが出来ているのですが、チームや組織全体で捉えるとそのメンバーに強く依存する事になってしまい、望ましくないと考えました。
そこで、問い合わせがあるとエンジニアリングサポートチームのメンバーに順番に自動でアサインする仕組みを導入しました*2。ただし、アサインされていないメンバーが取り組むことや、アサインされたメンバーでも手が離せない場合は申告してスキップもOKとしています。
また、取り組みの目的を「事業を継続する最低限のサービス品質維持」と定義しました。サービスを成長させる上で間接的ではあるものの、一定必要であると考えています。
そして、一次回答までの時間をエンジニアグループで担保するサービス品質の1つとして KPI に組み込んでモニタリングしています。
これらの施策によって、対応時間が短縮され、放置される問い合わせはほとんどなくなりました。
まとめ
ジモティーにおける、他部署からエンジニアへの問い合わせの問題とその解消に向けた試行錯誤の歴史を振り返りました。
今後もまた問題が出てくる可能性は十分にあるため、隔週でミーティングを設定して、もし何か相談事項があれば開催しています。
現在を山で例えると8合目だとしても、数年後に振り返ると実はまだ1合目だったのかもしれません。いずれにしても、発生する問題に対して継続して改善を続け、事業を円滑に進める基盤であり続けたいと考えています。
最後に
ジモティーではエンジニアを積極的に採用しています。
ご興味のある方は採用情報をご覧ください。
