エンジニアが新チームに加わる際に苦労したことと工夫

NAVITIME_Tech

2022年12月2日 15:06

この記事は、NAVITIME JAPAN Advent Calendar 2022の8日目の記事です。
https://adventar.org/calendars/7390

こんにちは、pegaです。
ナビタイムジャパンで、法人向け店舗データ管理・発信クラウドサービス『NAVITIME Location Cloud』の開発・運用を担当しています。

私はナビタイムジャパンに新卒で入社した5年目のエンジニアです。今年の7月に異動により新しいチームに加わったので、その際に苦労したこととそれに対して行った工夫を記事にしてみます。

既存プロダクトの理解

プロダクトの概要

私が開発を担当している『NAVITIME Location Cloud』には主に、

店舗データの管理を行う『Location Cloud Manager』
Google/Yahoo/Bing等のメディアに店舗情報を登録する『Location Cloud Sync』
ローカルSEOに対応した店舗サイトを簡単につくれる『Location Cloud Media』

というプロダクトが存在します。
さらに、分析機能などの周辺機能も含めると、管理するプロダクトはかなりの数になります。
幸い、チームに新しく加わる人のためにオンボーディング資料が用意されていて、プロダクトの概要はスムーズに理解することができました。

しかし、実際に開発に取り掛かると細かい点で不明点が出てきます。
例えば、

あるデータがあったときに、更新処理は正常終了してDBの値が書き換わっていることは確認できたが、APIを通すと取得できない
どこかでキャッシュされている？（CDN、アプリケーションサーバー、ブラウザキャッシュなど）

というような場面です。

モブプログラミングの活用

そこで、モブプログラミングを積極的に活用しました。
私が加わったチームでは、毎日1時間モブプロタイムが用意されています。
設計に悩んでいたり、実装に詰まっていたりする人がいればチーム全員で解決にあたります。
ここでは、最大効率で自分の理解を深めるために、

相談したい問題について、自分が分かること/分からないことを明確にしておく
できれば、自分なりの答えを出して言語化しておく

を事前に行っていました。
先ほどの例だと、

分かること：APIリクエストしたときの取得先のDBは把握している。
分からないこと：どこでデータをキャッシュをしているか。
自分なりの答え：アプリケーションサーバーを再起動したら最新のデータが取得できたので、アプリケーションサーバー内でキャッシュを持っている？

これをしておけば、モブプロの時間は答え合わせをするだけでよいので、知識が定着しやすかったです。

他にも、直接話しながら設計や実装を進めることで、チーム内で知識の共有や認識合わせが効率よくできるということも実感しました。
そのためには、全員が「分からないことを分からないと言える」ように

間違えて恥をかくことを恐れず発言できる
他人の間違えを受け入れる

という雰囲気を作ることがとても大事だなと思います。

問い合わせにより発生するコンテキストスイッチ

既存プロダクトの理解が進み、社内や顧客からの問い合わせ対応を担当するようになると、多いときは1日10件以上にもなる問い合わせ対応により頻発するコンテキストスイッチ(※)にも苦労しました。
※ ここでいう「コンテキストスイッチ」とは、様々なタスク（プロダクト開発、メール返信、ドキュメント作成など）を切り替えることを指します。

問い合わせはいつ来るか分からないため、基本的に割り込みタスクになります。
そうすると、その度に自分が着手していたタスクを中断して問い合わせの対応に入るため、毎回集中力が途切れていました。

顧客からの問い合わせは優先度が高く、問い合わせをいただいた時点で対応する必要があるため、社内からで、ある程度期限に余裕がある問い合わせについて、下記の工夫を行いました。

近い属性の問い合わせはまとめて対応する

対象となるプロダクトや技術領域（フロントエンド/サーバーサイド/インフラ）が同じであるなど、近い属性を持つ問い合わせは、まとめて対応するようにしました。
これによって、通常タスクのコンテキストスイッチを少なくでき、別の問い合わせでも、ほぼコンテキストスイッチコスト0でまとめて対応できるようになりました。

期限に余裕があっても、すぐ完了するタスクはその場で対応する

タスクを中断する際のコンテキストスイッチコストもありますが、期限に余裕がある問い合わせだからとタスクに積みすぎると、
そのタスクに着手する際に、問い合わせ内容を思い出すためのコンテキストスイッチコストが発生したり、優先度を整理するコストも増えます。

そこで、問い合わせが来た時点ですぐに完了すると思われるタスクはその場で対応するようにしました。
そうすることで、後でタスク内容を思い出すコストを0にし、その時間を通常タスクに当てられるようになりました。

今回は、問い合わせにより発生するコンテキストスイッチに対して、どう工夫したのかを単純化してまとめてみました。
実際の割り込みタスクの発生はもっと複雑で色々な要因があると思いますが、考え方は応用できる場面もあると思いますので、参考にしていただければ幸いです。

おわりに

今回は、新メンバーとしてチームに加わったときにした苦労とそれに対する工夫をまとめてみました。
どういう働き方をするのが良いかは、チームの状況やプロダクトの特性、また個人の能力や性格によっても変わるとは思いますが、この記事が働き方を再考するきっかけになれば幸いです。
最後までお読みいただき、ありがとうございました。