新卒2年目エンジニアが案件を主導し、タイトなスケジュールで新機能をリリースした話
はじめに
こんにちは、My Hair is Goodです。
ナビタイムジャパンで経路探索エンジンの開発を担当しています。
今回のnoteでは、プログラミング未経験の新卒2年目のエンジニアとして、複数のPJが関わる案件のまとめ役を担当した経験を元に、学んだことや感じたことを共有したいと考えています。
案件の主導に不安を感じている新人や、ナビタイムジャパンの働き方に興味を持っている方に読んでいただきたいと思います。
対応したこと
新機能の導入：冠水注意地点迂回ルート
カーナビアプリの『カーナビタイム』で「冠水注意地点回避ルート」という新機能の追加が検討され、私はその取りまとめを担当することになりました。
「冠水注意地点回避ルート」の詳細です。
ルート探索時、冠水注意地点（全国約3,600箇所）での降雨量が1時間に30㎜以上予想される場合、「冠水注意地点回避ルート」が提案される
ルート上に複数の冠水注意地点が存在する場合、すべてを回避するルートが表示
走行中、5分ごとに降雨量を確認し、走行開始時に雨がなくても、走行中に大雨が予想される場合、ナビゲーションで「冠水注意地点回避ルート」が提案される
※ 冠水とは以下のことを指します。
洪水や河川の氾濫などにより、農地や道路などの土地が広範囲に水に浸かる・覆われる状況を指す語。大雨が原因で発生する場合もある。
短期間に大量の雨が降ると、アンダーパスなどの水が溜まりやすい場所で排水が追いつかなくなり冠水してしまいます。
より多くのユーザに「冠水注意地点回避ルート」機能を利用してもらうために、台風シーズン中のリリースを目指す必要がありました。
スケジュールはタイトですが問題なく進行することができれば、なんとか間に合うという状況でした。
ただ、案件を1人で主導するのが今回が初めてということで、少し不安がありました。
既存機能との衝突
この案件は概要しか決まっていなかったため、具体的な課題や実現可能性を探るためにまずは調査を行いました。
要件の整理と使用できるデータの確認を進める中で具体的な実現方法が明確になっていき、順調に思えたその矢先に問題が発生しました。
現在の対応方針の課題を探すため、プロトタイプの経路探索エンジンで算出した経路を見ていたところ、期待しない挙動を発見したのです。
本線上に冠水注意地点がある場合、側道に迂回することを想定していたにも関わらず、側道を通らず遠回りする不自然な迂回経路が見られました。
これは、本線上に渋滞が起きた際に頻繁に側道を通行するようになったり、頻繁に高速道路から降りて渋滞を回避することを防いだりするために、側道の走行を抑制する既存機能が存在することで問題を引き起こしていました。
しかしこの既存機能が発動しないと不自然な経路が出てしまいます。
該当する場所が多いため、元々側道を通行させたくない場所では既存機能を使用し、冠水注意地点が本線にある場合には該当する側道のみ既存機能をOFFにする必要がありました。
この対応は既存機能の仕組みの影響で複雑な対応が必要となり、想定以上に多くの工数が必要になります。台風シーズンまでにリリースすることが、難しくなりました。
限られたスケジュールで何とかこの対応ができないかと思い、最低限の対応で解決できないかを考えました。
冠水注意地点に紐づいた側道だけではなくすべての側道で通行抑制の機能をOFFにする対応を試みました。
その結果、アプリを利用したユーザが走った経路2,000件を利用し再探索してみたところ、渋滞がある場合に側道を通る経路は意外にも全体の2％に留まりました。
側道を通る経路を確認しても頻繁に高速道路を乗り降りするなどの不自然な経路も見られなかったため、関係者に相談したところこの程度の影響ならOKという判断になりました。これにより想定より工数を大幅に増やすことなくこの案件を続行できることが確定しました。
検証での問題発覚
実現可能性が確認された後、関係者とのキックオフMTGを開催。各PJそれぞれ動き出し、自分も経路探索エンジンの開発を進めました。キックオフ前に実装方針を概ね決めていたため、実装で手こずった部分はありながらも冠水注意地点回避ルートを出せる状態にすることができました。
経路探索エンジンのリリースまで1週間を切り、対応した経路探索エンジンで期待通りの経路が出せることを確認し自分の対応が終了するはずでしたが、再び重大な問題が発覚。
冠水注意地点を回避するべき場所でそのまま通過する経路が確認されました。
調査の結果、一つはデータの加工ミス、もう一つは一本道のため回避する道がないという問題が判明しました。
データ加工のミスは担当者の迅速な対応により解決しましたが、回避する道がない問題はかなり深刻でした。今回の「冠水注意地点回避ルート」は、初めの経路検索時だけではなく、走行中も冠水注意地点への接近を検知し、適切な回避経路を提案するものでした。このため、冠水注意地点に近づくほど回避できる道が限られ、これにより「回避ルート」にもかかわらず冠水注意地点を避けられないルートが算出されることになります。
回避提案をするタイミングは「開かずの踏切」に近づくと回避提案をするという今回の対応に似た既存機能があり、キックオフ時にそこから横展して冠水注意地点から500m手前にしようということを決めていました。
開かずの踏切の情報にも対応し、時間帯によっては踏切を回避するなど、考慮したルートを検索できます。これらにより、実際の道路・交通状況に近く、所要時間や走行距離の精度の高いルートを算出できるようになります。
この回避提案のタイミングで問題ないか調査するために、出発地の位置を冠水注意地点の500m手前に打ち直すことでサービス上での挙動を再現させて検証し直すことにしました。
以前の検証と同じく2,000件の経路で確認したところ、約2割の割合で回避する道がない経路が見られました。しかし1000m手前からの回避提案ではその割合が約1割程度と半減することが確認できました。
また、踏切は近づくにつれて減速していることが多いのに対し、国道など速度の出る道路にも冠水注意地点は存在するため、回避提案をしてからユーザが判断する時間も必要ということもあり回避提案するタイミングは冠水注意地点から1000m手前に変更することとしました。
結果
スケジュールの切迫した状況でしたが、なんとか関係者の迅速な対応もあり、予定日を大きく遅らせることなくリリースすることができました。
その結果、台風が直撃し全国的に冠水地点が増加した時期にサービスを提供。これにより被害を少しでも減らすことに貢献でき、2023年9月6日にはプレスリリースを出すことができ、9月7日にはテレビにも取り上げられました。
学び・気付き
不明点の解像度を上げる
ふりかえると、はじめの段階で不明点を洗い出し、情報収集をすることでスムーズな要件や仕様の決定につながりました。
特に、プロトタイプを作成して対応方針の課題を洗い出したことで、側道の走行を抑制する既存機能と衝突してしまうことが調査の段階でわかったので有効だと感じています。
しかし、簡易的なプロトタイプしか作成しておらず検証時に発覚した回避する道がない問題を見落としてしまっていました。
スケジュールの都合もあるためどこまで作り込むかという問題もありますが個人的には不明点がなくなるまで作る必要があると考えました。
今回は「対応方針の課題」というざっくりとした目的でプロトタイプを作成しましたがここで、もっと仕様検討の段階から不明点を徹底的に洗い出すべきでした。
これがもし実践できていたとした、「はじめは既存機能を参考にして冠水注意地点から500m手前で考えていたが今回はその距離で十分なのか？」を深掘りできて、ナビ中の回避提案のタイミングについては、早い段階で問題を認識できていた可能性があります。
うまくいかない可能性を考え、スケジューリングする
今回はスケジュールがタイトなこともあり、キックオフ段階でわかっているリスク（既存機能との衝突）以外はおおよそうまくいく想定でスケジューリングしてしまっていたため、検証で問題が発覚してからは調査・関係者と相談・実装・再度検証と短期間で多くのことを対応することになり、スケジュールが後ろ倒しになりました。
この経験を踏まえ、今後は余裕を持ったスケジューリングを心がけたいと思います。ただし、無闇矢鱈にスケジュールにバッファを設けるのではなく、アジャイル開発でよく使われる「プランニングポーカー」という見積り手法を用い、より正確なスケジューリングができるようにしていきたいです。
プランニングポーカーとは、ソフトウェアのアジャイル開発手法の一つである「スクラム」（scrum）で、作業項目の規模を見積もる手法の一つ。チームメンバーが集まって、各項目ごとに各自の思う規模を相対的な値として一斉に提示する。
共有・相談はもっとこまめに、もっとカジュアルに
案件対応中の自分は、特にリリース直前は、問題が発生したりして目先の作業が多くなっていったことにより、切羽詰まって全体像がわからなくなっていたように感じます。
そのため全体像と進行中の作業の関係性が見える化できておらず、自分以外のPJメンバーからはこの案件の進行度合いが把握しにくい状態でした。
「自分がこの案件を主導する」という思いからだんだん自分一人で抱え込んでしまっており、こうなる前にPJに相談しておくべきでした。
これは新人がよく陥りがちな「まだ自分でできそう」という思いが積もってこういう状況を生み出してしまっていたように思います。
どうしても、相談する際にある程度報告できることを持っていきたいと思ってしまっていた自分がいて、もっと気楽にもっとカジュアルに相談できていれば良かったなと思います。
複数のPJが関わる案件を主導して感じたこと
複数のPJが関わる案件を主導するということで、決まった仕様や変更されたスケジュールに対して全ての関係者の認識を合わせることが必要だと感じていました。
そのため、一部の関係者が参加したMTGでも全員が把握できるように決定事項は必ず議事録として記録し、全体の目が届く場所で共有することを改めて心がけました。
ただ、自分が普段あまり関わりのないPJとMTGをする際に、自分の仕事に対してどの程度の知識があるのかわからず、自分では伝えられていると思っていても実際は伝わっていなかったというような難しさを感じることがありました。
しかし、そういった認識が合っていなさそうな箇所について積極的に質問をしてくださることで曖昧なイメージを共有してしまうことなく目標に向けた話し合いをすることができました。
このように、わからないことを曖昧にして流すことなく進めることができたことにより、複数の関係者が関わるような重大な手戻りが発生することなく限られたスケジュールでリリースすることができたと思います。
終わりに
ふりかえってみるともっとこうするべきだったと思うことがいくつも浮かんできますが、限られた期間で台風シーズンのうちにリリースし、社会に貢献できたことはとても嬉しく思います。
このnoteで「冠水注意地点回避ルート」に興味を持っていただけた方はぜひ『カーナビタイム』をご利用ください。
ナビタイムジャパンでは、サービスの利用者からのご意見やご指摘をもとに経路品質の改善を行っています。使ってみた率直な感想・ご意見などをいただけると幸いです！