Passenger App はどこへ向かうのか
シリーズ目次
- 第一章｜背景 — なぜ Passenger-Centered Design が必要になったのか
- 第二章｜実験 — 自動運転車両における Passenger App の実装と試行
- 第三章｜今後 — Passenger App と乗車体験のこれから
車両タイプと Passenger App
一口に自動運転車両といっても、その形態はさまざまだ。
ロボバス、ロボタクシー、搬送用ロボットなど、用途や前提条件によって、車両の性格は大きく異なる。我々は、これらを車両タイプ別に リファレンス・デザインとして整理している。
それぞれの車両は個別のHMIを備えており、Passenger App ひとつを取ってみても、その有用性は一様ではないのが正直なところだ。
たとえば、米国 Tesla の Robotaxi 専用車両には、タクシー型とバス型が存在する。しかし、そのどちらにおいても、乗客向けスクリーンは一つだけだ。車両タイプが異なっても Passenger App を共通化することで、乗車体験を一貫したものにしようとしている。その意図は、はっきりと読み取れる。
鉄道・バス・タクシーという比較軸
日本の文脈で考える場合、タクシーやバスと並び、鉄道を無視することはできない。鉄道は、日本においてもっとも成熟した公共交通のひとつだからだ。鉄道車両における Passenger Screen を見てみると、その構成はバスと非常によく似ている。
- 次の停車駅
- 駅出口や階段の案内
- 路線全体の俯瞰
といった情報が、スライド形式で表示される。これは、移動の理解と安心を支えるための、きわめて合理的な設計だと言える。
一方で、タクシーでは広告配信用のタブレットを搭載した車両が増えている。とくに、乗客の意思とは無関係に再生され続ける広告は、乗車体験の設計者という立場から見れば、扱いが難しい存在だ。
乗客の目的から考える
乗車体験を設計する際、設計者はまず「乗客の目的」から考えるのが通説だ。自動運転車両の文脈で言えば、その目的は大きく二つに集約される。
- 自動運転（技術）の確かさを確認したい
- 自動運転車両に実際に乗ってみたい
そのうえで、乗客が期待するのは、自動運転車両ならではの特徴が分かること、そして自動走行とそれ以外の走行の違いが理解できることだ。そのため、Passenger App には次の役割を担わせている。
- 自動運転車両の特徴の可視化
カメラやセンサー配置、検知対象を通じた車両周辺の可視化 - 自動走行とそれ以外の違いの可視化
発進・停止、ルート選択、車線変更といった判断プロセス - 運行案内
バス停や到着予定、停車理由などの情報提示
これらはいずれも、「見たければ見てください」というスタンスで設計されている。その意味で Passenger App は、操作を前提としない ビューアー としての性格が強い。
前章で触れたロボタクシーのように、操作機能を持たせた Passenger App とは、車両タイプも、乗客の目的も、そもそも異なる。
Passenger App とスマートフォン
冒頭で触れた「（ドライバーの）余暇時間＝エンタメ」という論理は、あくまで 能動的に見たい場合 にのみ成立する。受動的に視聴を強いられるコンテンツは、乗車体験を豊かにするどころか、ノイズになり得る。前章で触れた音声対話の例を踏まえると、
代替可能な手段があるのであれば、それに越したことはない。
わざわざ車内に新たなインターフェースを持ち込む必然性は、慎重に見極める必要がある。
近年では、こうした広告配信スクリーンが、バスや鉄道車両にも広がりつつある。だが実際には、乗客はそれを「見る暇がない」ことがほとんどだ。なぜなら、乗客の手元には、いつでも自分の関心に最適化されたスマートフォンがあるからだ。
見たい情報、必要な通知、楽しみたいコンテンツは、すでにそこに集約されている。
実は、Passenger App が担おうとしている多くの役割は、乗客自身が持参するスマートフォンで代替可能である。というより、他の交通機関での体験を振り返ると、スマートフォンのほうが望ましいと感じる場面のほうが多い。
スマートフォンを「ハブ」として捉える
スマートフォンの画面を車載ディスプレイにミラーリングする仕組み、たとえば Apple CarPlay や Android Auto の登場は、かつて自動車OEMにとって大きな脅威と捉えられていた。
現在では、
- ミラーリングを前提とする方向
- ミラーリングを除外し、独自の車載システムを強化する方向
というように、対応は二極化している。
一方で、配車予約や決済といった機能は、すでに多くの場合、スマートフォンアプリ側に集約されている。鉄道やバスなど、他の交通機関でも、電子チケットやモバイル決済は当たり前になった。
これらを踏まえると、乗車体験を一気通貫で設計するためには、常時人が携帯しているスマートフォンにハブ的な役割を担わせるほうが合理的だと考えられる。
Passenger App を Web ベースで展開しているのも、このマルチモーダル化を推進しやすくするためだ。車両タイプごとに個別対応を重ねるよりも、Passenger App を共通化し、スマートフォンと連携する「情報のハブ」として位置づけるほうが有用だ。
車内外サイネージとの関係
自動運転車両には、Passenger Screen のほかにも、車内外に複数のサイネージが存在する。
これらを自動運転システムの一部として捉え、利用シーンに応じて情報を出し分ける構想もある。Passenger が目にするディスプレイ群を統合的にコントロールできれば、
- 必要なときに
- 必要な情報だけを
- 適切な粒度で提示し
さらにオペレーションとも連動させることが可能になる。
パッセンジャー中心とは何か
自動車OEMにおける車両開発は、運転席が存在する前提から「ドライバー中心」で設計されてきた。では、自動運転車両においてはどうだろうか。私の答えは明確だ。
それは パッセンジャー中心 である。
人の移動を支援することが乗り物の本質だとするなら、ドライバー不在の車両において、人はパッセンジャーとしてしか存在しない。
ただし、そのパッセンジャーは、すでにスマートフォンを手にしている。この前提を無視して、能動的に見なければならない情報を車両側に独立して持たせることは、乗客にとって不本意でしかない。
たとえば飛行機では、座席前方に個別モニターが設置されている場合がある。しかしそれは、飛行中にスマートフォンが使えない、あるいは使いづらいという前提があるから成立している体験だ。もし飛行中も自由にスマートフォンが使えるとしたら、鉄道と同じように、多くの人はスマートフォンを見るだろう。
人々の生活の中で、移動体験はごく限られたシーンである。
移動中の時間は、余暇というよりも、できるだけ早く終えたい時間だと捉えることもできる。
Passenger App とは、その限られたシーンにおいて、自動運転の状況を可視化し、乗客が安心して過ごすための手段のひとつとして位置づけられる。
第三章｜まとめ
- Passenger App は万能なUIではなく、理解と安心のための最低限のビューアーである
- エンタメや個人化は、スマートフォンに委ねたほうが合理的な場合が多い
- Passenger-Centered Design とは、見せる情報を選び取る設計態度である
本記事では、Passenger App を起点に、自動運転時代における「乗車体験」をどのように設計すべきかを整理してきた。
ドライバー中心で組み立てられてきた車両設計は、自動運転によってその前提を失い、乗客が何を理解し、何を知らなくてよいのかを問い直す段階に入っている。
Passenger App は、その問いに対するひとつのインターフェースとして位置づけられる。
20世紀最大のプロダクトである自動車が自動運転を備えるということは、その移動体験自体を、利用者に委ねることにほかならない。
※この記事は、Mediumからの転載です。
