見出し画像

サーバー開発のサの字も知らなかった開発者がサーバーサイドの窓口にまでなれた話

NAVITIME_Tech

はじめに

こんにちは、knsnです。ナビタイムジャパンで地図データを配信するサーバーの開発を昨年まで担当していました。

今回はサーバー開発のサの字も知らなかった開発者がどのようなマインドで未経験領域に対して取り組んできたのかをお話しできればと思います。

自己紹介

まず簡単にですが自己紹介をさせてください。
ナビタイムジャパンに入社する前、私は車載カーナビ向けの地図データを作成する部署で何年か仕事をしていました。
そんな特異な経歴もあってかナビタイムジャパンでは研究開発部門の地図PJというチームに配属となりました。

地図PJとは

地図PJでは、皆さんがナビタイムジャパンのサービスで目にしている地図データを作成しています。
また、それ以外にも作成した地図データを配信しているサーバーの開発・管理、アプリやweb上で地図データを表示させるための機能を作り込むのも地図PJの仕事になります。
このように、地図PJの役割は名前以上に広い範囲を対応しています。

サーバーサイド開発担当初期の2つの壁

このように担当範囲の広い地図PJですから、地図データの作成周りを担当していた私も、一年ほど経とうかという頃にリーダーから「そろそろサーバー側の開発も」とお願いされることとなりました。

当時、地図PJが管理するすべてのサーバーを把握している有識者がいました。なので私はその方の元でゆっくり教えてもらいながら対応すれば良いかなと考えていました。

しかし、そんな甘い考えがうまく行くはずもなく、程なくしてその有識者がチームから離れられることが決まったのです。(1つ目の壁)
また、当時はバックエンドクラウド化の過渡期ということもあり、サーバー開発知識も当然ですが、クラウドに関する知見も全くありませんでした。(2つめの壁)

意識と行動の改革

この頃地図PJでは、新規の研究開発検討が進められており、元々サーバーサイドを担当していたメンバーもそちらに注力していました。
そのため、サーバーサイドの開発メンバーは主に新卒1, 2年目のメンバーと私という状態でした。

今後、後輩からの質問への回答や開発レビューを行うにあたり、今のままでは知識が足りず適切なアドバイスが行えないと感じました。
そこで、私は次の3点を意識して行動しようと努めました。

1. 外部からの問い合わせ・要望を引き受ける

随時、地図PJには他の研究開発部門のPJからの質問や、サービスを担当している事業部門からの要望などの問い合わせがきます。
これらの一次受けと回答を積極的に行うようにしました。

以下は対応した問い合わせの一例です。

  • サーバーで一時的にエラーが出ていたので調査してほしい

  • 複数地点のマーカーを表示する時、地図縮尺を自動で調整してほしい

  • ルート線を表示させると海上に移動してしまうので対応方法を教えてほしい

最初の頃は元々開発をしていたメンバーに「この関数からあたりをつけると良い」など、調査のとっかかりからの相談となっていました。
しかし、ある程度経験を積んでくると処理の流れがわかってくるようになり、調査で躓いても、「ここまで調べてみたけど、この先がわからない」というように相談ができるようになりました。
そして、最終的には各開発アイテム全般について把握できるまでになりました。

2. サーバーアラートのレスは早めに

エラー検知の仕組みとして、エラー率などの閾値を超えた際、slackに通知が飛ぶようになっています。

地図PJの管理するサーバーがアラートを上げた際は、問題が発生しているのか、静観で良いのかできるだけ早く一次回答をするようにしました。
これは、実際にバックエンドを利用しているサービス担当の事業部門に不安を持たせないよう意識して行うようにしました。

初めの頃は「503エラーが出ています」「一時的なものです」など最低限の起きている事象だけの報告となっていました。
しかし、サーバーメトリクスでの確認方法を覚えると「データ更新による負荷で503エラーが出ています」など理由をつけて報告ができるようになりました。
また、負荷の状況が確認できるようになったことで、スケール条件を見直すなどといった改善もできるようになりました。

3. インフラチームに頼りきりにしない

クラウド化によりサーバー開発の知識に加え、クラウドサービスの知識も必要になってきます、そこで頼りになるのがインフラチームの方々でした。
皆さん優しいので調査のとっかかりを相談すると「ここで〇〇となっているので××です。」のように答えまで教えてくれました。

しかし、このままでは毎回インフラチームに確認することになってしまいます。
そうならないように教えてもらった後は、次は自分で調べられるようにどのような手順で行ったかを確認するようにしました。

インフラチームの方には、メトリクスの見方・ログ参照の方法・デプロイの仕組みなど、さまざまなことを教えていただきました。
いつの間にかデプロイスクリプトのレビュアーに選定されることもありました。

自分事として捉える

この3点を意識して行動した結果、サーバー開発に関する知見、及び関わるクラウドサービスに関する知見を増やすことができました。
また、このように色々なところに顔を出したことにより、SREチームと一緒に運用検討を行うようになったり、インフラチームとのコミュニケーションがスムーズになったりと、地図PJの窓口として動くことも多くなりました。

先ほど挙げた3点に通じていたのは、未経験領域のことでも自分事として取り組むことができたのが大きかったと感じています。
未経験領域は「自分の範囲ではない」と自身の経験から無意識に線を引いてしまったり、手を挙げるとそこに責任が生まれてしまうことに躊躇してしまったりします。
しかし、PJに対する質問を自分事として捉えることで、自分にとってプラスになることは多かったですし、結果的にチームに対してもプラスに働いたと考えています。

もし、成長したいけど未経験領域だから不安と思っている方がいらっしゃいましたら、是非思い切って一歩を踏み出してみてください！