見出し画像

経路探索エンジンの品質改善で得た新卒1年目エンジニアの学び

🎄この記事は、NAVITIME JAPAN Advent Calendar 2023の16日目の記事です。


こんにちは、新卒1年目のヤシです。
ナビタイムジャパンで、経路探索エンジンの研究開発をしています。

配属後初の業務として、経路探索エンジンが算出する経路の品質向上施策を行いリリースしました。このnoteでは、新卒1年目のエンジニアとしてどんな学びがあったかをお話します。

経緯

今回の対応では札幌駅を通る移動について、今までよりも良い経路が出るようになりました。
まずは、どんな経緯でこの改善に着手したのかお話しします。

みなさんは札幌駅を利用したことはありますか?
北海道を代表するターミナル駅で、1日439本の列車が行き交う乗り換えに便利な駅です。
例えば、新千歳空港から旭山動物園に行く際は、札幌まで快速エアポート、札幌から折り返して特急「カムイ・ライラック」に乗るのが便利です。

NAVITIMEでの経路探索結果例

過去にnoteでご紹介しましたが、折り返し乗車は、切符を買い直さないと不正乗車となってしまうケースがとても多いです。
今回のケースでは、札幌〜白石間が重複しており、折り返し乗車にあたります。果たして、アプリに案内された通りに、札幌駅まで行っても良いのでしょうか……?

札幌〜白石間が折り返し乗車になっている

当社の経路探索エンジンは、ユーザに安心してご利用頂くために、折り返し不正乗車につながりかねない経路がサービスに出にくいようチューニングされています。

ところが、金額がかからず折り返し乗車ができる例外パターンがあります。調査の結果、今回の札幌駅のケースも、折返しの例外パターンに該当することがわかりました。つまり、きっぷを買い直すなどの手続きをしなくても、札幌駅まで行って帰ってくることができます。

品質改善前の当社の経路探索では、札幌を回避し、白石駅で乗り換えるような経路が出てきてしまっていました。
白石は特急が停まらないため、代わりに各駅停車を使う経路を選んでいました。例外パターンに対応できていないために、より移動に時間のかかる経路が出ていたのです。
そのため、より便利な経路が出るよう、改修することにしました。

対応内容

取り組む経路品質改善課題が決まったら、次に、改善業務を

  • 実装方針を検討する

  • 実装する

  • 経路がどう変わるか、処理速度がどう変わるか検証する

という手続きを踏んで行います。本セクションでも、この順でご説明します。

実装方針検討

この仕事に取り組むことを決めた時、私は、経路探索エンジンが経路を調べていく処理について、軽く研修を受けている状態でした。
そのため実装のイメージがつきやすく「経路を調べていく処理に、特例に合致するような折返しパターンが検出できたら折り返しが選ばれやすくなるような改修を加えよう」と考えました。

実装

ところが、この案を先輩に伝えたところ「すでに対応している折返し特例がある。今回は、特例パターンを表すデータを追加すれば良いのでは?」と助言を頂きました。

対応イメージ

助言をもとに条件を精査し、実際に、データ追加版の経路探索エンジンを構築して経路探索したところ、札幌駅を通る経路が出るようになりました!

検証

経路品質としては良くなりましたが、データ追加前と比べ、処理速度が 5%ほど悪化していました。データを読むぶん処理に時間がかかってしまっているのです。このままでは、札幌駅を通るリクエストどころか、あらゆるリクエストでユーザをおまたせしてしまうことになり、リリースができません。

困っていたところ、先輩にモブプログラミングを提案していただきました。
モブで、先輩の助言を受けながら、どこが重くなっているのか、どの処理ならスキップしても構わないのか調査し、速度を早くするための施策を見つけることができました。

この改修を取り入れることで、処理速度がむしろ 1%程度向上し、めでたくリリースができることが決まりました!
実際の改善結果が以下です。(左がBefore、右がAfter)

Before / After

気づき

今回の対応を経て、今後の業務に活かせる気づきがありました。

先輩を上手に頼ろう

早く一人前になりたかった私は、自分で解決策を考えられることが理想だと思っていました。
しかし、自力で解決を図るより、巨人の肩に乗るほうがいいケースが多いです。今回も、自力で処理を書くよりは、すでにある処理を活用する対応の方が良いことが、先輩に訊いて初めてわかりました。
解決策の細部を自力で頑張って詰めるよりも、一旦先輩から知見を頂くほうが手戻りが少なく、結果としてチームのためになりました。

また、最初の仕事だったので「自分が何がわからないのかわからない」となってしまうこともありました。先輩に訊きにいこうにも、質問がうまくできず何往復もしてしまったり、時間を奪うことが心配で質問に踏み出しにくかったりしました。
この解決策が「1時間、モブの時間のアポを取って、なっていたい状態を伝えて臨む」ことでした。こうすれば、

  • 画面や操作を見ながらのやりとりになるので、無理に質問文にしなくても、状況が伝わりやすい。

  • 決まった時間で片付く。

と、良いことづくめです。

実際の作業を通して学ぶため、「ターミナルでCtrl-rを押すと過去に打ったコマンドが見られる」といった、先輩の技術を受け取りやすいメリットもあります。質問の本筋から外れているやりとりではありますが、同じコマンドを何度も繰り返して検証するため、業務にしっかり役に立ちました。

別の仕事に取り組む先輩の姿を見てみても、また別の先輩にモブを頼んでいる様子が見られました。一人前になってからも、人と一緒に取り組むことがゴールへの近道だと感じました。

鉄道趣味は役に立つ

私は、鉄道とプログラミングが好きで当社に入社しました。ただ「趣味と業務は違うよな」「業務に役立ちそうと言われるけど、本当にそうなのかな?」と思っていました。

ところが、この改善業務中、鉄道ファン冥利に尽きるうれしいことが何度もありました。

  • 札幌駅を迂回する問題に直面した時、「もしかして、折返しができる特例に対応しきれていないんじゃないか?」とひらめくことができました。

  • 実装方針検討・検証では、改修によってどこまで影響範囲が及ぶかを見積もり、網羅する必要があります。
    網羅するにあたって、「北海道内の移動では、札幌を使う人が多いから、北海道が出発地・目的地のリクエストを調べれば良さそうだ」「苗穂が目的地の例はどうだろう」「苗穂に停まるけど、白石を通過する列車はないよな……」と、狭すぎず、広すぎない範囲を思いつくことができました。

札幌・苗穂・白石の位置関係

鉄道規則や路線図は、とても複雑です。
全部はわかっていなくても、「こんな例があるんじゃないか」と発想できることが、仕事を進める原動力になります。

終わりに

新卒1年目エンジニアの初仕事をお伝えしました。
これからも、自分の視点での思いつきを大事にしつつ、早めにチームに共有して助言をいただくことで、スムーズに業務を進められることを目指してまいります。