新卒1年目のエンジニアが、社内地図フレームワークに新機能を追加した話
こんにちは、広葉樹です。
ナビタイムジャパンで、地図フレームワークの研究開発を担当しています。
今回は、新卒1年目のエンジニアが開発した2種類の地図機能についてご紹介し、開発の中でどんな学びがあったのかについてお話します。
開発の背景
みなさんは、当社がリリースしている『配達NAVITIME』というアプリはご存知ですか？本アプリは、宅配ドライバーの方々をサポートするために作られた、配達専用の業務管理/カーナビアプリです。
その『配達NAVITIME』の開発担当より、さらなる宅配ドライバーの安全運転と業務効率化のための新機能要望があり、開発を担当することとなりました。
道路の車高・車幅のデータを、地図上に一目で分かるように表示する（車高車幅の規制表示機能）
道路の広さ(幅員)のデータを、地図上に表現する（幅員の表示機能）
前者については、当社が既に所有している車種別規制データについて、一部のデータを地図上に直接描画してほしいというものです。なお、当社で扱っている道路の規制情報データについては過去に記事をまとめていますので、よろしければ以下の記事をご覧ください。
後者については完全な新規機能であり、道路全体の幅員データについて、当社のサーバーから配信されたデータをアプリ内で通信して地図上に描画するというものです。
いずれにせよ、新卒で配属されてから初めての大きな機能追加であったこともあり、1年の集大成として開発に臨むことになりました。
なお、車高車幅の表示機能、幅員の表示機能の詳細はそれぞれ当社プレスリリースにも掲載されておりますので、ぜひご覧ください。
機能紹介
それぞれの機能について、規制数値の表示には2週間弱、幅員表示には1ヶ月弱の開発期間がかかりました。
車高・車幅・重量規制数値の描画
ナビタイムジャパンでは、アプリで車種を指定することで、車種ごとの交通規制アイコンとその規制区間を表示する機能が既に存在しています。この機能の中で、アイコンだけでなく、車高・車幅・重量規制数値データの中身を追加で表示する機能を追加しました。表示するデータの見せ方は、細かく調整することを可能にしており、
表示位置設定
フォントやフォントサイズの設定
データ文字色設定
これら全てを任意に調整可能なように実装しました。もちろん、従来の規制アイコンのみを見せる機能も使用可能で、アプリの状態によって数値データの表示と非表示を切り替えることも可能にしています。
左はアイコンだけを表示し、右はの車高車幅のデータも表示しています
道路幅員表示
こちらの機能は、通信の層から描画処理まで一貫して実装を行いました。
画面上の見た目としては、上記規制数値の描画機能と同様に幅員データの存在する道を線でハイライトし、その中央部に吹き出しアイコンと幅員の大きさを表示させるようにしています。
また、道路の狭さに応じて危険度を表現するために、幅員の狭さに応じて線の色を変更することが可能なほか、線の色自体も設定することが可能です。加えて、幅員データの表示位置設定なども規制数値の描画機能と同様に調整可能にしています。
また「地図の見やすさ」を担保するために、表現方法にも工夫を入れています。
例えば、大量の幅員データの情報が存在する場合、地図上に吹き出しが大量に表示されてしまいます。そこで、
地図を縮小した場合では線のみを表示する
吹き出しが重なった場合は、数値の大きい吹き出しを削除する
といった処理を行うことで、より見やすい表示を実現しました。
学んだこと・気づいたこと
新機能を開発していくにあたり、今後の業務にあたっての学びや気づきがありました。
2つのOSで同じものを作る難しさ
世の中のスマートフォン向けOSには、大きくiOSとAndroidOSの二種類が存在します。私はAndroidOS版の開発を行い、iOS版の開発は他のメンバーが担当しました。
しかし、開発言語の違う2つのOSに対して、全く同じものを作ろうとすることは実は難しいことです。特に、OS内部の処理系による差異が発生すると厄介です。実際に幅員機能のリリース直前には、「見た目上は全く同じ処理をしているはずなのに、表示された値が違う」といったことが起こり、解決に苦労しました。
アプリ開発者やサーバ開発者との仕様調整の難しさ
私は、ナビタイムジャパンの「地図フレームワーク」を担当しているエンジニアであり、Google PlayやApp Storeに配信する『配達NAVITIME』の開発者はまた別に存在しています。
また、幅員や道路規制のデータを取得して地図に表示可能な形式にデータを変換する、バックエンドの担当者も存在します。そのため、通信の形式はどうするか・実際にどのような見せ方をするかについては、アプリの開発者やデザイナーの方と検討を重ねる必要がありました。
地図の開発者として「できること」「できないこと」「できるけど時間的に難しいこと」は何か、アプリの開発者として「やりたいこと」「やりたくないこと」「可能ならばしたいこと」は何なのか。
開発の難易度や納期までの時間を天秤にかけて、複数のチームが一つの着地点に向かう難しさについて実感しました。
利用者は自分や自分のチームではなく、他人であるという意識
前述のとおり、私はアプリの開発者とは少し違い、地図の機能作成後はそれを社内向けのライブラリとしてリリースしています。
今回紹介した2つの機能についても、全社に向けて公開されています。そのため、関数の名前やパラメータの説明・コメント内容には、特に誤解のないように書く必要があります。
プログラムのコメントといえば、自分のための備忘録やメンテナンス・引き継ぎのために書くという印象が強いかと思いますが、初めから人に使ってもらうという観点で書いている人は少ないのではないでしょうか。
クラッシュの発生しうる要因は全て検証する
プログラム開発においては、新機能開発に関わらず「ただ開発してぱっと見動いたらOK」というわけではありません。ユーザーやアプリ開発者からの様々な使用用途を想定し、全ての用途に対して正常に動作していることを検証する必要があります。
もし、アプリが市場に出てから、地図機能内に致命的な不具合が見つかってしまったら大変です。なぜなら、不具合を修正するために、「地図の修正＆検証＆リリース→ アプリ修正＆検証＆リリース」と二段階に分けて修正を行う必要があるからです。この工程は最低でも2日はかかってしまうため、その間、ユーザーは常に不都合なサービス体験をすることになってしまいます。
そのため、条件分岐による処理フローの変更や非同期処理、null(nil)の有無に関しては、常に頭の片隅に置きながら開発を進めていく必要がありました。
Done is better than perfect.
クラッシュ要因について言及した後にこの話をするのもどこか矛盾している気がしますが、まずは問題があっても「とりあえずできた状態」に持っていくのが大切だと感じました。
シンプルに時間がかかってしまったり、実装方法に悩んでいることがあっても、動いているものがあればそこから先輩に見てもらってレビューやアドバイスを頂くことができます。なにより、動いているものがあると、目で見える進捗があって精神的に良いです。
近年、プログラミングの情報はWeb上に溢れていますが、実際の開発技術は一朝一夕で身につくものではなく、「習うより慣れろ」という側面が強いと感じています。
おわりに
今回は、新卒1年目のエンジニアが地図に新機能を追加し、学んだことについてお伝えしました。開発期間は短期間ではありましたが、今後もさらなる地図機能の開発に向けて努力を重ねてまいります。
最後までお読みいただき、ありがとうございました。