【PM座談会】ニーズはエンジニアが掴みにいく。ナビタイムジャパンに学ぶ、ニッチなユーザーにハマるアプリのつくり方

株式会社ナビタイムジャパンは、知名度の高い「乗換NAVITIME」だけでなく、toB,toC問わずさまざまなナビサービスを提供しています。そのどれもが、ニッチなニーズを持つユーザーに徹底的にローカライズすることで、全25アプリのストアレビュー平均4以上（iOS,2023年6月時点）を誇るなど、高い評価を得ています。

なぜナビタイムジャパンは、ユーザーに確実に役立ち、高く評価されるサービスをつくり続けられるのでしょうか？　ユーザーボイスを集めて良いプロダクトに仕上げるために必要なことはなんでしょうか？

ユーザーもプロダクト規模も異なるサービスを手掛けるPM3名に、ニッチなユーザーにハマるアプリのつくり方を聞きました。

• keyboard_arrow_down ナビに欠かせない「視認性確保」も徹底的にユーザーに合わせたUIに
• keyboard_arrow_down ユーザーボイスはエンジニアが自ら掴みにいく。リリースしてから届いた意外な声も
• keyboard_arrow_down ユーザーにとって意義ある改善ができているか？　定性・定量の両面で把握
• keyboard_arrow_down より多くのユーザーにとって便利なアプリにするために「納得感」も重要

——まず、皆さんが担当されているプロダクトと、そのプロダクトに携わるようになったきっかけを教えてください。

板橋：私は「ツーリングサポーター」という、バイク専用ナビゲーションアプリのPMをしています。以前は社内最大規模のサービス「NAVITIME」の開発をしていましたが、自分で何でもやるような小規模の部署で働いてみたくなり、当時リリースして間もなかった「ツーリングサポーター」を担当する部署に転属しました。ツーリングサポーター自体は社内のバイク好きが発案してできたサービスです。

橋山：私はトラックドライバー向けのカーナビアプリ「トラックカーナビ」に携わっています。私自身はもともとサーバサイドのエンジニアなので、「トラックカーナビ」立ち上げ当初はサーバサイドエンジニアとして参画しました。最初は他のサービスにも並行して携わっていましたが、いまはPMとして「トラックカーナビ」に専念しています。

早川：私は「配達NAVITIME」という、個人宅や企業に荷物を届ける配達員向けのアプリを担当しています。新卒入社してからは乗用車向けのアプリ「カーナビタイム」と「ドライブサポーター」に携わっていました。昨年はアプリ「スピードメーター」の立ち上げにはじめてPMとして関わることができ、その経験を生かす形で「配達NAVITIME」の立ち上げからPMとして参画しました。

——サービスごとにユーザーの特徴が異なると思いますが、どのような点に配慮されているのでしょうか？

板橋：「ツーリングサポーター」では、乗用車向けアプリ以上に、視認性の高さに気をつけています。バイクでの走行中は、両手はハンドル、目線は前方、かつ前傾姿勢をとっていることが多い。そのため、乗用車に比べて走行中にスマホが視界に入りづらいんです。文字を大きくしたり目立つ色を使ったりとUIを工夫して、画面が視界の端に入る程度でも案内を理解できるような、視認性の高いサービスにしなくちゃいけないと心がけています。

橋山：「トラックカーナビ」でも、視認性を重視しつつ音声案内にも力を入れていますね。大型トラックは一般的な乗用車よりも、ダッシュボードから運転席までの距離が遠いので、画面サイズいっぱいに文字を配置しても見えづらかったりします。そのため画面を見なくてもルート案内ができるよう、音声案内にも気を配っていて。トラックは乗用車より車体が大きく、小回りが利かないので、案内のタイミングや内容に気をつけています。

早川：「配達NAVITIME」でも、視認性は大切にしています。配達員の方は夜間、暗い屋外や車の中でアプリを使うことも多いので、ダークモードに対応して、見やすさを保てるようにしています。また、業務中は急いで操作する場面も多いので、誤タップを防ぐようボタンを大きめにつくっていますね。

あとは、効率よくルート計画を立ててもらえるように、アプリ操作のステップ数も極力減らすようにしています。例えば住所検索は文字入力中でも住所候補を出したり、郵便番号から地点を検索できたり。配達地点も1タップで最適な順番に並び替えられるようにしたり。ルート計画は1日の業務の最初に立てることが多いようなので、そのときの手間を減らせるように、操作性にもこだわっていますね。

——ユーザーの声を確実につかむためには、どんな取り組みをしていますか？

橋山：ストアレビューはもちろん、当社ではすべてのプロダクトに「ご意見箱機能」をつけてユーザーボイスを集めています。さらに、イベントを開催したり、展示会に行ったりして、エンジニアがユーザーと直接お話をする機会もあります。例えば「トラックカーナビ」では、サービスエリアやガソリンスタンドでイベントを開催して、ドライバーさんに直接サービスを紹介したり、実際に使っていただいて感想を聞いたりしています。

また、走行中での使用感を体験するために、開発メンバーで大型トラックをレンタルして、トラックカーナビを使用しながら道路を走ってみて改善点を洗い出す、という取り組みも行いました。

当社はエンジニアが8割の会社で、エンジニア自身が企画や営業の領域も担っているので、「自分たちがユーザーニーズを掴みにいくのが当たり前」という土壌がありますね。

板橋：「ツーリングサポーター」でも、バイク関連の展示会やファンミーティングなどのイベントに参加して、ユーザーの生の声を聴くようにしています。ツーリングを趣味として楽しむユーザーが多いので、いただくご意見もかなり熱量が高いですね。さらに、アプリの使用感をブログやSNSに投稿するユーザーもいるので、日常的に観測しながら、ニーズをつかんでいます。

早川：「配達NAVITIME」は2022年12月にリリースして、運用期間がまだ短いので、直接ユーザーと会う機会をこれから能動的につくっていこうとしているところ。あまりイベントなどがある業界ではないので、既に直接会えているみなさんがうらやましいです（笑）。

私自身は配送業の経験がないので、まずはネットで調べて情報収集するところから始めました。調べる中で、我々のユーザーとなるラストワンマイル（顧客に商品を届けるまでの最後の区間）の配送を担っている人には、意外にも個人事業主の方が多いとわかりました。その方々の中には、SNSやブログで積極的に情報発信している人も結構いるんですよね。そうした情報からニーズを類推しながら、改善や新機能を考えています。

——ニーズをサービスに落とし込むにあたって、苦労したことはありましたか。

早川：「配達NAVITIME」だと、技術的な難易度が高い要望がけっこうありますね。特に「手元の端末で、経由地を100地点登録してルート検索する機能」を開発した際は大変でした。

プロジェクト発足直後のリサーチ段階で、ユーザーとなる配達員の方は1日100地点以上を訪問することが多いという情報は掴んでいました。そのため、サービスの仕様を検討しているときから、この機能は必須だろうと判断していたんですが、実現できるんだろうかという不安もありました。

「経由地100地点のルート検索」という機能自体は、法人向けのWebアプリにはすでに実装されていたものの、コンシューマ向けサービスでとなると話は別です。当社で提供するtoCサービスでは、経由地数は多くて10地点くらいで、「コンシューマ向けサービスで」「100地点を経由地に登録しルート検索を行う」という前例がありませんでした。

地点の数が増えるほどデータ量は膨大になり、サーバーに大きな負荷がかかります。また、ルート検索のための分岐も爆発的に増えるので、その処理のための負荷がかかり、レスポンスの速度を出すのも難しくなります。

また、ユーザーである配達員の方は、ほとんどのみなさんが朝の出発前にルートを決めていると分かっています。つまり「配達NAVITIME」のコンシューマ向け端末すべてにこの機能を実装する場合、何十万台もの端末から、同じくらいの時間帯に、多くて100地点を考慮する高負荷なルート探索リクエストが集中することになります。

チーム内では、サーバー負荷への対策コストをかけるだけの意味があるのか、実装して本当に使ってもらえるのかといった議論もありました。ただ、配達員の業務についての調査を重ねる中で、1日100地点以上の配達はざらにあることだとわかりました。われわれには桁外れの要望に見えても、配達員の方々にとっては日常的に直面する課題だと気づいたんです。「これはサービスを使っていただく上でマストな機能に違いない」と、ルート探索周りの開発者や技術チームと相談を重ね、サーバーやインフラの負荷などさまざまな調整を繰り返し、実装することができました。

橋山：「トラックカーナビ」だと「配達NAVITIME」のような機能単体の難しさより、いかに多くのユーザーに刺さるものをつくるかということに難しさを感じています。

特に強く印象に残っているのは、駐車場やシャワーがある場所など、施設の特徴をシェアできる投稿型の機能を実装したときのことです。

大型トラックはそもそも駐車できる場所が多くない上に、1つの施設に停められる数も少ないんです。さらに、食事ができたりシャワーが使えたりと長距離ドライバーさんに重宝される施設の情報は表に出回りづらく、休憩に困るユーザーが多く見受けられました。

リサーチの中で、こういった施設の情報をSNSや口コミでシェアしあっていると知りました。そこで、そのシェアを「トラックカーナビ」で担うことができれば、困っている多くのユーザーに役立つのではないかと考え、施設投稿機能を実装しました。

リリース後は好評のお声をたくさんいただきましたが、一方で「自分がいつも使っている施設が知らないうちにシェアされてしまったら、突然混みだして、利用できなくなってしまうかもしれない」という不安の声もあったんです。

たしかに、ある地域での配送業務に慣れているユーザーの多くは、停められる場所を把握していて、そもそもこの機能を必要としていないかもしれません。となると、施設投稿機能を重宝してくれるのは、その地域での配送業務に慣れていないユーザーのはず。施設ごとの駐車場の数は変わりませんから、今まで来ていなかった人が来れば混むし、そのぶん常連さんは入れなくなってしまいます。

開発する以上、より多くのユーザーに喜んでもらいたいし、その確信をもってリリースしたものの、結果としてユーザーの評価が相反する機能になっちゃったなと思いました。我々開発者がキャッチできるユーザーニーズには色々な背景があって、すべてのユーザーにとって嬉しい機能をつくるのは本当に難しいことだと学びましたね。

板橋：「ツーリングサポーター」では、数としては少ないけれどもクリティカルな要望をいただくこともあります。バイクの排気量を考慮したルート探索機能がその最たる例ですね。

バイクは自動二輪車なので、通常の乗用車と交通ルールが多少異なります。排気量によって通れる道が決まっていたり、全ての自動二輪車が走行できない道があったりします。たとえば、高速道路は総排気量125cc以上の自動二輪車であれば走行できますが、原付など低排気量の自動二輪車では走行不可、といったように。

アプリローンチ当初のルート案内では、「全ての自動二輪車が走行できない道」のみを弾くようにしていました。そしたら、原付など低排気量のバイクを愛用している方などから「通れない道を案内された」という意見が、少数ながらも日常的に届いていました。

数が少ないとはいえ、ナビアプリとして通れない道を案内してしまうのは、アプリ自体の存在意義を損なう重要な課題です。そこで、チーム内で検討し優先度を上げて対応するようにしました。

ただ、排気量ごとにルートを案内できるようにするのは、技術的にもかなり難しい要求でした。

自動二輪車の通行ルールは、「原付一種（50cc以下）は通れないけど、原付二種（50cc以上125cc以下）以上は通れる」「125㏄以下の二輪車は通れないが、125㏄以上であれば通れる」など、排気量によって細かく定められています。

当時そのデータは当社になかったので、データを全てイチから集めた上で、既存のデータに追加する必要がありました。さらに、ルート検索のロジックにもそのデータを組み込まなくてはいけませんから、必然的に大規模な改修を行うことになります。通行ルールのデータを集めたり、通行ルールを考慮したルート検索のためにロジックを組み直したりと、色々駆けまわって半年くらいかけてリリースしました。

開発は大変だったのですが、リリース後には多くの好評の声をいただき、ユーザー数もグッと伸びたので、つくって良かったですね。

——改善指標はどう設定しているのでしょうか？

板橋：これは全プロダクトに共通して言えることですが、基本的には各機能の利用数で見ています。その機能がどれだけ多くの人に使われているのかはもちろん、有料ユーザーしか使えない機能であれば、その機能をきっかけにどれくらいの人が有料サービスに加入してくれたかという数値も把握するようにしています。

「ツーリングサポーター」はユーザーからの声がどれも熱烈なぶん、意見の数自体は少なくても存在感が大きく見えてしまう部分もあります。つくった機能が、ユーザーの中のごく一部にしか使われないものになっていないかをより注意深く確認するために、「数多くのユーザーに刺さったかどうか」を重視するという姿勢です。

橋山：「トラックカーナビ」は日々の業務で活用いただいているアプリなので、ありがたいことに、「ここがこうだと困るのでこうしてほしい」と詳細に伝えていただいています。そのため、「困った！」という声が多いかどうかは、改善や機能追加がうまくいったかを判断する１つの基準ですね。

なにか皆さんの役に立った機能がリリースされると、レビューやご意見箱に「ありがとう」というメッセージが届くんですよ。それが励みになっています。ただ、アプリが日常業務に溶け込んでいる分、具体的にどこがよかったかをわざわざ言葉にしていただくことが少なく、どのあたりを良いと思ってくださっているのか、機能の利用状況などを見ながらさらに改善しています。

早川：「配送NAVITIME」はリリースして間もないので、そういうフィードバックはまだですね。ただ橋山さんのお話を聞いて、同じtoBのアプリだからこそ、「トラックカーナビ」と似た方法で指標を立てていく部分もありそうだと思いました。「配達NAVITIME」の配達業界と、「トラックカーナビ」の物流業界は、同じ「物を届ける」という面で似ているところも多そうですね。

——ユーザーの声を反映するための開発を行うとき、大切なことは何でしょうか。

橋山：NAVITIMEが提供するルート案内サービスは、道路状況や交通ルールなど様々な条件を考慮して最適な経路を導き出し、ユーザーに提供するものです。

だからこそ、我々の提案はユーザーの需要に届いたのか、ユーザーにとって現段階での最善案を提供できているのか、いつも試行錯誤しながら開発しています。

早川：たしかに、いかにユーザーに納得してもらうかが大事だと感じています。
「配達NAVITIME」での経由地100地点の最適順並び替え機能をリリースしてからも、「なんでこの順番になっているかわからない」という感想をいただくことがありました。その感想を深掘りしてみたところ、順番の提案の際に、狭い道を避けたり渋滞を考慮したりして設計しているということが、ユーザーに伝わっていないとわかったのです。

ユーザーの抱える不満は、提案したルート自体への不満なのか、提案の背景が分からないことからの不満なのか。それを見極め、後者の場合は、しっかり提案の背景を伝えて「そうなってるんだ」と納得感を持ってもらうことも、満足につながりそうだなと思っています。

板橋：たしかに、納得感が持てれば、提案したルート自体への満足感も変わってきそうですね。

僕としては、「そのユーザーボイスを直接反映してプロダクトがよりよいものになるか」を判断できるかどうかも大切だと思います。目指すべきは「より多くのユーザーが抱えている課題を解消できるプロダクト」であって、ニッチなニーズに応えてばかりでは、よいプロダクトとは言えないかなと。

「ツーリングサポーター」でも、熱烈なユーザーボイスがある＝多くのユーザーが欲している機能だと判断してつくったものが、ごく一部のユーザーにしか使われていない、ということもありました。ユーザーの熱量を受け止めたうえで、「本当に多くのユーザーが喜んでくれるか」は注意深く調査して判断する必要があると思います。

橋山：さらに、既存のニーズに応えていくだけでは物足りないと思っていて。プロダクトを通じて、社会を良くする視点を持つことも大事だと思います。

「トラックカーナビ」だと、「社会課題の解決」が事業のミッションにあるので、事業者の抱える困りごとを掴んで、随時機能としてつくれないか検討しています。とくに長距離トラックドライバーに関しては、労働環境や安全など課題も多く、事故などがニュースになることもあります。ニュースから課題を掴み、ドライバーの安全に関する課題や、慢性的な人手不足など事業者の課題にアプローチできる方法を探していますね。

最近では、防災関連で、災害時の輸送基や装備品を確認できる「防災手帳」や、危険な箇所を表示する「防災チェッカー」、音声で案内する「防災ガイダンス」などの機能をリリースしました。

近年、豪雨や地震などの自然災害が増え、トラックは災害発生後、被災地に物資を届けるなどの場面で重宝されています。ただ一方で、立ち往生や事故のリスクも高まり、大きな課題となっていました。安全に目的地に辿り着くようサポートしながら輸送の維持に貢献できるよう、今後もこういった課題にアプローチできる機能を追加していかなくては、と思っています。

——最後に、今回3人で話してみた感想を伺いたいです。

橋山：ユーザーニーズの汲み取り方や、多くの人に刺さるものをつくるという判断、それらを実現することの難しさはプロジェクトを問わず同じだなと。一方で、求められている機能の方向性や、ユーザーからのリアクションの特徴などは、プロダクトごとに違いが出ていますね。

板橋：そうですね。それぞれユーザーは違っても、「ルートの品質を高める」というナビタイムジャパンの共通の技術をもとに、役立つものを届けられている、ということに改めて気づけました。

早川：「配達NAVITIME」をこれからスケールさせていく上で、ニーズの汲み取り方や改善指標の置き方など、既存プロダクトからいただけるノウハウはたくさんありそうです。「ナビ」という起点から個別のユーザーに最適化していくっていう、事業全体の強みもここにあるのかもしれないですね。

取材：光松瞳
文：中島佑馬
撮影：赤松洋太