新機能「日向ルート」を開発した新卒1年目エンジニアの学びとは？
こんにちは、十一です。
ナビタイムジャパンで経路探索エンジンの開発を担当しています。
今回は『ALKOO by NAVITIME』/『NAVITIME』にてリリースした「日向ルート」機能を紹介します。
また今回の開発は、新卒1年目の私にとって初めての大きな新機能開発でした。
本記事では「日向ルート」の紹介とともに、新卒1年目エンジニアの視点で学んだことをお話します。
「日向ルート」機能とは
今回追加された「日向ルート」機能は、現在地から目的地まで、日向を優先したルートを表示する機能です。
プレスリリースも発表しています。
同様の日陰を優先する「日陰ルート」機能について詳しくは日陰ルートのnoteで紹介されていますので、ぜひご覧ください！
使い方
『ALKOO by NAVITIME』は以下の手順で使うことができます。(11月~2月の日中限定機能となっています)
ホーム画面から「歩く」を開く
地図上で行きたい地点を長押し
右下の経路ボタンを押すと、日向ルートが表示される
『NAVITIME』は以下の手順で使うことができます。
ホーム画面から、出発地・目的地を設定し検索をする
バリエーション一覧画面から、iOSなら設定ボタン・Androidなら＋ボタンからルートバリエーション設定画面を開く
「日陰を避ける」項目にチェックを入れて、バリエーション一覧画面に戻る
追加された「日陰を避ける」タブから経路を選択する
経路画面から、地図を選択すると経路が表示される
日向ルートの特徴的な仕様
「日向ルート」は、「日陰ルート」とは多くの部分で逆の特徴を持っています。
例えば、屋根のある場所では日陰になりますので、日陰ルートは経路の検索結果に出てきやすく、日向ルートでは出にくくなっています。
ただし、日向ルートと日陰ルートでは、屋内の扱い方は同じにしています。
両方のルート共に、屋内のルートは検索結果に出てきやすくなっています。日陰ルートの逆を考えると、日向ルートでは屋内が通りづらくなる可能性がありますが、私たちはユーザーが日向ルートで求めているのは、暖かい経路ではないかと考え、日向ルートでも屋内を通りやすくしています。
実際にユーザーが暖かい経路を求めているかはまだはっきりしていませんので、今後はユーザーの声をもとに改善していく予定です。
私の開発内容
大きく以下2つの業務を担当しました。
内部の機能開発
コストチューニング・検証
内部の機能開発
内部の開発部分は、日陰ルート機能の際に、予め拡張を想定した実装をしていただいていたため、スムーズに行うことができました。
経路を出すためには様々な要素でコストをかけて、かけたコストの中から通りやすい経路を出力しています。
「日向ルート」を実現するために、日陰率に応じてコストをかけるという対応を行いました。
コストチューニング・検証
「日陰にコストをかける対応」自体はすぐに対応できたのですが、「日陰ルート」と同規模に日陰のコストを設定したところ、不自然に日向の道を通る経路が見られました。
ユーザーとして納得感がない経路が出てしまう事は良くないため、「納得感がない経路は出てこないが、日向をしっかり通る経路がでる」コストを求めてコストチューニングを行いました。
2つの点を検証の確認観点としながらコストチューニングを行いました。
観点1:ユーザーにとって納得感のない経路がでていないか？
実際にチューニングを行ったエンジンから得られた経路からサンプルをとり、上記画像経路のような、納得感が得られない経路がないかを確認しました。
観点2で得られた全体傾向と異なる経路を中心に経路を確認し、納得感がない経路が確認された場合は、原因特定と問題解消を行い、ユーザにとって納得感のない経路が出ないように、コストチューニング・検証を行いました。
観点2:コストチューニングした結果出てくる経路傾向
日向ルートの傾向を確かめるために、日陰具合が異なるいくつかの時間ごとに経路の傾向を確かめました。
上記画像は、12:00と日向が多い時間帯のコストチューニング後のグラフです。
上記の可視化したグラフから、12:00の時間帯では「距離は増加しているが経路全体に含まれる日陰の量は減少している」という傾向が見えました。
この傾向は、12:00の時間帯に想定していた「日向ルート」の傾向であり、コストチューニングした結果、異常な傾向が見られないことを確認しました。
学びとその活かし方
個人開発と異なったこと
私は、学生時代に個人開発を少ししていたのですが、大きく3つの違いを感じました。
感じた違い1:ユーザー目線
今までの個人開発では利用者がほぼ自分自身ということもあり、自分自身が使いたい機能を考えることが主でした。
ユーザーが使いたい機能を、「日向ルート」では考えました。
その1つとして、屋内を通りやすい仕様にしたことがあります。
今後は当社アプリの使用頻度を高め、ユーザー目線をさらに養い、次の機能開発では、よりよい機能開発を行えるようにします。
感じた違い2:機能の拡張性の重要さ
私は学生時代、制作物を長期間の運用・改修する前提ではなかったので、作り切りで制作物を作成していました。
日陰ルートでの機能開発を担当したチームメンバーが「日向ルート」の拡張を前提に作成していたため、とても開発しやすかったです。
今回、実装をスムーズにできたのは拡張性が高かったことが理由ですので、機能の拡張性は重要だなと深く感じました。
今回は恩恵を受けた側でしたが、これからの機能開発では、次の開発者がスムーズに開発を行える機能開発を行ってまいります。
感じた違い3:品質の担保
学生時代は自分自身の作りたい部分を作っており、品質は気にしていない部分でした。
ユーザーに使って頂く機能ですので、様々なユーザーが納得できる品質を担保する必要がありました。
そのため機能開発の時間と比べて、圧倒的に品質確認に時間を充てました。
機能開発における品質の担保の大変さを理解することができましたので、次の機能開発では、私自身で品質確認・機能開発の工数をより正確に見積もり開発を進めていきます。
「周りを頼る」という選択肢
上記の「品質の担保」は初めて意識したこともあり、自分自身で正解を出そうとして空回りしました。
私一人では品質の担保に苦戦してしまったため、同じプロジェクトメンバーとモブ形式で、経路を確認してもらいながら品質の担保を進めました。
モブ形式を行ったことで、他のメンバーの調査の仕方を見て品質の担保のノウハウを獲得できました。
ノウハウがないと、時間をかけても空回りしてしまうので、効率・今後の自分自身のためのどちらの観点でも人を頼るという選択肢は重要だと感じました。
今後は、「周りに頼る」という選択肢を次の新卒のプロジェクトメンバーに自然に選んでもらえるような雰囲気と技術力を自分自身が身に付けていきます。
終わりに
新卒1年目のエンジニアの学びをお伝えしてきました。
実際の機能開発を経験し、学びや次に活かしたいと感じることが多かったです。
今回の学びを活かして、職業エンジニアとしてよりよい機能を開発し、ユーザーの方々に喜んでもらえるような機能を提供を目指してまいります。