Dear Great Hackers

「UI/UX」、ここ数年、目にしない日はないというほど一般的なITキーワードです。この「UI（User Interface）/UX（User Experience)」の語順がトヨタ自動車の社内では「UX/UI」と逆になっていることをご存知ですか？

この語順に、電気自動車（EV）、自動運転、スマートシティといった、様々なモノをユーザーが使うことを考えてモノづくりをするトヨタの想いが込められています。そして、この想いが如実に表現されているのがクルマの運転席（コックピット）だといいます。

2020年11月26日に開かれた、オンラインイベント「TOYOTA Developers Night ～UX/UI × ソフトウェア = クルマの運転席？～」。このイベントにトヨタ自動車のコネクティッドカンパニーの関沢 省吾氏、山田 薫氏、鈴木 真一氏が登壇され、クルマのコクピット周辺の「UX/UI」を向上させるための企画・開発に関する取り組みについてお話してくださいました。今回はこのイベントの概要をお伝えします。

プロフィール

 

 

トヨタが「UX/UI」と表現することで示したかった想い

日に日に高まるコクピット（運転席周辺）の重要度

「TOYOTA Developers Night ～UX/UI × ソフトウェア = クルマの運転席？～」は、登壇者の自己紹介で幕を開けました。商品魅力・ビジネス強化推進室　グループ長 関沢省吾氏、同グループ長 山田薫氏、ソフトファースト推進グループ　主幹 鈴木真一氏は、普段は同社東京ロケでコクピット周りのUX/UIの開発を進めているといいます。

今回のイベントテーマは、クルマのコクピットのUX/UIの設計とそれを実現する大規模ソフトウェアの開発事例です。はじめに、関沢省吾氏（以下、関沢氏）は最近のクルマはコクピット（運転席付近）周りのデジタル化が進み、運転席に大きめのディスプレイが設置されることが増えてきていると話されました。コクピットはクルマとユーザーの接点。ソフトウェアを利活用することで様々な価値を生み出すことができる場所として認識されています。近年、クルマ開発の中でUX/UIの重要度が増しているといいます。

「UI/UX」？「UX/UI」？

関沢氏は、一般的にWEB系の開発などでは「UI/UX」の順で用語が並んでいますが、トヨタでは、あえて「UX/UI」の順で使っているといいます。

これは、ユーザーが車を使うことを考えた上でUXを設計し、それを実現するためのソフトウェア、そしてハードウェア（クルマ）を作ることを意識するためだそうです。ソフトからハード、コトからモノへの順で考えるのは、現在、トヨタが進めている「ソフトウェアファースト」の考え方と同じだといいます。

「なぜ、クルマのUX/UIが重要になってきているのか？」

冒頭で話がありましたが、なぜ、車のUX/UIが重要になってきたのでしょうか。IT技術の発達によって、技術の刷新スピードが急激に速くなり、世の中の感覚が大きく変化してきているからだと関沢氏は話しました。

今では、スマートフォンなど情報通信機器は常にオンラインでアップデートをすることが常識になっています。これまでメディアで購入することが前提だったコンテンツは、オンライン配信やサブスクリプションといった形で必要なときに必要なものを入手するようになっています。

クルマでは、一部で地図が更新されることはあっても、ソフトウェアがアップデートされることはほとんどありませんでした。10年以上、同じクルマを使い続けることもあり、基本的にユーザーがクルマに合わせる状況でした。ここにユーザーからの期待値・感覚とのギャップが生じていると関沢氏は指摘します。

これからは、クルマやモビリティ体験そのものがユーザーに寄り添い、新しい体験・発見を与えられるよう、ソフトウェアの力を上手く使って絶え間なく新しい価値を与え続けていくことが大切になります。そのため、ユーザーとの接点となるコクピットのUX/UIが重要になっているのです。

UX/UIをより良くしていくために

UX/UIをより良くしていくには、クルマがモノ、コト、ヒト、社会とつながる「コネクティッド」な技術が必要になります。

これに必要な要素は、主に3つあり、

• データ分析（基盤）・活用F
• クラウド技術、通信、エッジコンピューティング
• OTA（Over The Air – Software Update）

といったソフトウェア技術がポイントとなってくることを、第1回（10月29日）のイベントで同社 BR-OTA推進室　室長 村田 賢一氏が解説してくださいました。

関沢氏は、人と「In-Car」「Out-Car」をつなぐインターフェースであるコックピット周辺のUX/UIでユーザーに安全安心で価値ある体験を提供することが大切だと語ります。

UX/UIの企画段階で押さえておくべきこととは？

UX/UI開発のプロセス

ここで、話者は山田薫氏（以下、山田氏）に変わります。山田氏は「UX」という言葉をどう日本語にするか、いろいろな解釈があるが、山田氏個人としては「使い勝手が良くなること」として、UXの改善を認識していると話されました。

はじめに、トヨタのUX/UI開発のプロセスについて説明がありました。

プロセスは、いくつかのフェーズに分類されています。流れとしては、まず、「ユーザーリサーチ」から入って「分析・示唆出し」といった発見の手順を経て、アイディアを煮詰める「アイディエーション」といった工程を実施。この時点でアイディアやコンセプトの検証を行うといいます。

続いて、「UIデザイン」に移ります。ここにも検証のサイクルが入っています。その後、本格的に「開発」「ユーザーテスト」「リリース」へと進む工程になっていると概要が示されました。

企画フェーズで押さえておく点とは

プロセスのうち、「ユーザーリサーチ」と「分析・示唆だし」は企画フェーズと呼ばれています。企画・改善案策定の材料を探すことを目的としています。

ユーザーリサーチには、2つの種類があると山田氏はいいます。1つはユーザーの「現在情勢」を調べていくことで、もう1つは「未来動向」です。

「現在情勢」とは、トヨタの理念の1つ「現地・現物」の観点から、クルマを所有するユーザーに実施する「サービス満足度調査」などのこと。「エスノグラフィ調査」と呼ばれる、ユーザーが実際に運転をしている挙動を録画して、利用方法などを明らかにする調査も実施しているそうです。これにより、ユーザーも気づいていなかった課題を発見することもできるといいます。「現在情勢」の調査は深掘りができるところだと山田氏は語ります。そして、ユーザーからのクレームやご意見はリサーチの「宝の山」といいます。

こういった調査を重ねることで、ユーザーの方々が使いにくいと感じている「ペインポイント」や逆に便利だと感じている価値を掴んでいくそうです。

「未来動向」とは、クルマの開発スパンは長いため、取り組んでいるクルマが世の中に出るときの社会情勢を睨んで企画をブラッシュアップするための調査のこと。先進的な「エクストリームユーザー」への聞き取りなどを経て、未来洞察や先行技術、またユーザーの価値観の変化等についても調査を行っていくそうです。

試行錯誤も多いアイディエーションフェーズ

企画フェーズを終えると、アイディエーション、コンセプト検証を実施します。
ここでは、以下の観点から、様々な手法でテストが行われるといいます。

• 「価値の検証」ユーザーに価値を感じていただけるのか
• 「UIの検証」ユーザーに伝わるUIになっているのか

端的にいえば、ユーザーにアイディアや改善を価値として感じてもらえるのかといったこと、そしてUIを通じて、その価値がユーザーに伝わっているかという検証が必要だと山田氏は話します。実は試行錯誤することも多いそうです。

アイディアや、コンセプト検証は、「現地・現物」の観点もあり、できるだけ現状に近い検証用の設備を用意することもあるといいます。テストにはタブレットやドライビングシミュレーター、VR技術などが使われます。

VR技術は現在開発中とのことですが、VRゴーグルを利用して、車内や運転状態を再現するのはメリットがあると山田氏は指摘しています。なぜなら、天気や道など周囲の状況を、自由に自分たちで設定でき、ほぼ360度が見渡せるからです。さらにVRゴーグルがあれば世界中どこでも同じテスト環境を再現でき、最低限イスがあれば実施できる簡便性を兼ね備えている点もメリットだといいます。

全世界で通じる「安心・安全かつ便利なUIデザイン」が非常に重要

ここで、話者は関沢氏に変わり、「UIデザインフェーズ」について説明がありました。「UIデザインフェーズ」では、ここまでで検証されてきたユーザーの価値や体験からくるユースケースをベースに、UIを細かくデザインしていくのだといいます。大前提として、クルマのUIは、ナビ、メーターなど、ユーザーが目にする表示器類や操作するモノのことだと関沢氏は話され、次の4つのポイントを示しました。

1.安全・安心を担保：運転しながら、安全に操作・情報を取得

脇見運転をしないように規制を加えたり、安全に操作できるよう表示を工夫したりするといったことがUIデザインのポイントになります。「歩きスマホがいけないのと同じ」と関沢氏は例えられました。

今後、上手く活用していきたいものとしてあげられたのが「音・音声」でした。音声操作により、姿勢を変えることなく運転でき、使い勝手、安全安心のどちらにも寄与することができる機能だからだといいます。

2．直感的な情報提示：運転者が知りたい情報を違和感なく取得

UIデザインで、自然な表示場所で、適切な伝達方法、タイミングで情報を伝えることが大切だと関沢氏はいいます。なかでも「優先度」が重要です。例えば、道を逆走しはじめたときにカーナビが道案内を続けていて、逆走の注意が後から出てはダメということです。これら連動がUIの設計としては重要になってくるため、情報の優先度を細かく規定して、その調整をソフトウェアで行っているといいます。

関沢氏は、車が高機能になればなるほど複雑になり、今後さらに自動運転技術などが加わるため、情報提示の取り扱いはさらに重要になっていくと話しました。

3.クルマ特有の複雑な環境への配慮

UIデザインにおいて、クルマ特有の複雑な環境への配慮が必要だと関沢氏はいいます。クルマは外のいろいろな場所を走るため、どのような環境でも計器類の表示を見えやすく、わかりやすくする必要があるということです。

例えば、太陽光の反射でナビ等が見えにくくなったり、見え方が変わったりすることがあります。こういった課題には、ハードウェアでいろいろ対策もしますが、UIデザインで色味の調整等をして工夫をしていることもあるといいます。

今後は、フロントガラスに映像を映すヘッドアップディスプレイが増え、外の物体と重なり、表示が見えにくくなることへのケアも大切になっていくと関沢氏は語りました。

4．インストルメントパネルとの一貫性：車種バリエーション、グローバル展開

商品性を担保するのは当然ですが、全車種向けにUIを作っていては開発規模が膨大になってしまいます。そのため、最大限に共通化できるよう、全バリエーションを想定しながらUIデザインをしていくことになるそうです。この際、パラメーターになるのが、Lexus、トヨタといったブランドの違い、車両コンセプト、イメージなどです。これらの一貫性がポイントになると関沢氏は話します。

なかでもディスプレイサイズには注意が必要だといいます。スマートフォンでも機種によってディスプレイサイズや縦横のアスペクト比が異なっていて開発者はサイズを合わせるのに苦労していますが、クルマも同じだといいます。

クルマならではのパラメーターが右ハンドル、左ハンドルといったハンドル位置の違いだそうです。ハンドル位置によって見え方が違うため、操作性や視認性を考えて細かくUIデザインを煮詰めていくのだそうです。

また、トヨタの場合、全世界にクルマを提供しているため、多種多様な言語表示に対応する必要性があります。言語によって同じ意味・内容であっても文の長さが異なってくるため、この調整にはたいへん苦労すると関沢氏はいいます。一例としてアラビア語の表示をあげられました。

共通化を進めても、ソフトウェア開発はかなり大規模という事実

バリエーションが多い大規模な開発とテストを同時に回す

ここで話者が鈴木真一氏（以下、鈴木氏）となり、開発からリリースに関わるフェーズについて説明がありました。

「実装・ユーザー評価フェーズ」では、UX/UIデザイナーが作成したデザイン、アニメーションをUIフレームワークで実装していきます。ここでは、汎用のツール・ツールフレームワークを活用して、軽く、早く、品質良く開発するようにしていると鈴木氏は語ります。ツールは流行やバージョンアップを考慮して選択しているといいます。

ユーザーテストによるアジャイル改善をしているのがポイントです。ユーザーテストでは、場合によってはツールを作るなどして、実際の車に近い形で実施することを重視しているそうです。

前の工程で、UIデザインが共通化を進める工夫がされていても、実際にはバリエーションが多く、ソフトウェア開発はかなり大規模になっていると鈴木氏はいいます。ユーザーテストを繰り返して改善を進めながら、大規模な開発を同時に回していくことが開発における大きなチャレンジになっています。

大規模開発 × アジャイル・スクラム

大規模で変更の多い開発では、「変更前提」「大規模開発」「期限厳守」の3つのバランスをとって開発を進めていくことが大切になります。

以前は、ウォーターフォールで大規模開発をしていたため、企画から3～4年後にクルマが量産される頃には、すでにソフトウェアが時代遅れになってしまうことがあったといいます。そのため、評価、バグフィックスをしていたタイミングでアジャイルの要求仕様の変更・機能追加を行う、「ウォーターフォール ＋アジャイル」の手法で開発が進められるようになったといいます。

しかし、この場合、商品性の維持をしながらバグフィックスをしなければならないため、どうしても日程遅延のリスクがあると鈴木氏は話します。

大規模開発 × （ウォーターフォール ＋アジャイル・スクラム）

そこで、大規模なスクラムでのアジャイル開発をCI/CDの環境を整備して愚直に進め、対応をしているといいます。スクラム開発の様々な要求に対して、1人POを立て、バックログで管理をして開発を進めており、バグフィックスに関してもバックログで管理しているそうです。

その結果、プロジェクトだけでなく、全体のベロシティも右肩上がりとなり、スクラム開発をして、成長を実感できていると鈴木氏は話します。

大規模開発 × アジャイル w/CICD

ここで、実際のプロジェクトで用いたCI/CD環境の図が示されました。

一般的なCI/CDのパイプラインと大きく変わらないと前置きした上で、鈴木氏は、唯一、特殊だったのが、これらのシステムが全てオンプレミスの環境だったことだと話しました。当初、セキュリティの懸念もあり、オンプレミスで実施したそうですが、最終的にはフレキシビリティが高くなり、良かったと思っているそうです。

内容としては、リポジトリの中のコードの変更をトリガーに、ビルド、テストを実行しています。最終的に出来上がったものについては、SDKの形でDockerのイメージと共に開発者の方に渡るようにして、同じ環境で皆が開発できるような形をとっていたといいます。クルマ用のソフトウェアのため、セキュアコーディング対応ができているかどうか、不正コードが混入していないかの確認もしていたそうです。

初めてのCI/CD　失敗事例　その1

ここで、鈴木氏から、CI/CD環境を作って開発を進めた中での失敗事例の共有がありました。

1つめは、ユニットテストの運用ルールを細かく決めずに「軽いノリで」テストコードを作ってしまったことで、ビルドとユニットテストだけで半日かかるようなジョブを作ってしまった事例です。

鈴木氏によると、リリース直前になると、いつもこのジョブをどうするのかが問題となっていたといいます。テストビルドのノードが、これで詰まってしまうことがあり、誰かが1人監視をして、詰まりがなくなるようにジョブを調整していたそうです。テスト時間の上限を決めたり、目安時間を決めたりすることが非常に重要だったと反省されたそうです。

反省：テストの時間上限・目安時間を決めることが非常に重要

初めてのCI/CD　失敗事例　その2

2つめの事例です。組み込みシステムが動くSoCはArmで、検証にはテストノードCPUのシミュレーターを使っていたそうです。

開発当初、比較的スペックの高いサーバーを用意したこともあり、楽観ムードがあったようですが、実行してみるとシミュレーターのジョブが回らないという事態に陥ってしまったといいます。

最終的に、オンプレミスを採用していたため簡単に対応できたようですが、大量にArmの実機を用意してテストを実行することになったと鈴木氏は話してくださいました。

反省：CPUエミュレータを用いてテストしたことによるジョブの滞留

初めてのCI/CD　失敗事例　その3

最後にあげられた失敗事例です。差分を常に確認したいとの考えから、ビルド、テスト等は、変化があった部分のみをSDKベースに差し替える形で実施していたといいます。当初、何も考えずに毎回SDKをダウンロードして実施していたそうですが、次第にI/Oが非常に重くなり、ジョブが回らなくなったそうです。

現在は、NASのローカルへのミラーリングやパッケージのキャッシュ行うことで対応できているといいます。ストレージのI/Oも含めてCICDの環境を作るのが重要だと勉強できたと鈴木氏は語りました。

反省：ストレージのI/Oを含めた適切なCI/CD環境の確保

UX/UI開発（大規模開発）×アジャイル・スクラム

まとめとして、鈴木氏は、このような形でスクラム開発を適用し、CI/CDの環境を導入することで大規模開発であっても、アジャイル開発に近い形で開発が進められるようになったと話します。

現状、UX/UIの開発に関しては、要件の定義もアジャイルで、開発もアジャイルのため、その2つのアジャイルをバックログでつなぐ形で開発を進めていくことを考えて開発をしているそうです。

2つのアジャイルの輪がつなげることで、ユーザーに提供できる価値を無限大にすることを考えていると鈴木氏はまとめてくださいました。輪が2つ並び無限大「∞」に見えるのが印象的でした。

質疑応答

ユーザーリサーチからリサーチまでの期間は？

トークセッション終了後、関沢氏、山田氏、鈴木氏と参加者との質疑応答が行われました。はじめに、ユーザーリサーチからリリースまでどのぐらい時間がかかるものかという質問に、山田氏は、最初ユーザーリサーチコンセプトと決める時点から、3～4年ぐらいかかると思うと答えてくださいました。

ユーザーリサーチは年齢・性別等で対象を絞っているのか

ユーザーリサーチの対象は、年齢や性別などをどのように絞っているのか、という質問がありました。これに山田氏は、クルマの買い換え等はライフステージの変化に連動することが多いので、必要な特徴に応じて対象を絞り、リサーチをしていると話しました。

エンジニアやデザイナーもリサーチ・コンセプト検証に参加するのか？

エンジニアやデザイナーもリサーチやコンセプト検証には参加しているのか？　という質問に、関沢氏は、エンジニアもアイディエーションから関わることが非常に重要だと回答しています。デザイナーだけで作ったものは良いものにはならず、エンジニアが早いうちから入って企画や検証をすることが大切だといいます。

山田氏は、なるべく早い段階からエンジニアが入った方が、考えも深まり、モノづくりへの愛着も生まれるので、時間がかかってもその方が良いのではないかと話されました。

現在のスクラム・アジャイル開発へ移行するための期間は？

次に、「実装・ユーザー評価フェーズ」で、従来、ウォーターフォールで行っていた大規模開発を、今のアジャイルの形に持っていくまでにどのぐらいの時間がかかったのかという質問が紹介されました。

これに鈴木氏は、企画段階から移行するとなると3年以上必要だが、部分的に移行していく形をとっていると答えました。クルマの開発は比較的長い時間がかかるため、個々のタイミングにあわせてアジャイル開発の企画をして、実際3年、4年、5年といったスパンで部分的に適用を進めているとのことでした。

ウォーターフォール開発とのすり合わせはどのように行っているのか？

開発プロセスについてアジャイル開発をしているコンポーネントとウォーターフォール開発をしている側との連携について、開発プロセスのすり合わせなどはどのように行っているかという質問がありました。

これに対して、鈴木氏は特別なことはしておらず、泥臭いすり合わせをしているだけだと語りました。また、それがトヨタの特色でもあり、強みでもあるとも付け加えてくださいました。

UX/UI開発を通じて叶えたい「夢」

最後に登壇された方々がUX/UI開発を通じて叶えたい「夢」を語ってくださいました。

山田氏は、運転が苦手で、自社の自動運転車など、これから登場する未来のモビリティを自分が死ぬまでに、どれくらい体験できるかを楽しみにしていると語ります。

鈴木氏は、今まで以上に、ソフトウェア開発が当たり前に行われるような会社になればいいと考えているといいます。

関沢氏は、クルマが好きで、クルマに自分のした仕事を載せたいということと、自分の子供が大きくなったときに、それを良いものだと思ってもらえるものを作りたい、それが一番の夢だといいます。トヨタは、今後も愚直に開発を進め、ユーザーに良いものを提供していくので、ぜひ期待を持って見守っていただきたいとも話してくださいました。

編集後記

何気なく私たちが座っているクルマのコックピットには、長い年月をかけ、試行錯誤を繰り返した知恵と工夫が詰まっていることがお話を伺ってわかりました。使う側は「ヘッドアップディスプレイ、格好いい」と思うだけで、使用する際に危険を感じることはありませんが、表示と実際の風景が溶け合ってしまっていたら危険です。そう思わせないための技術があって実現された「安心」なのです。

安全安心を当然のこととクリアして「UX/UI」を進化させることで、ユーザーに新たな価値を提供するための苦労が垣間見える印象深いイベントでした。これから、「すべての人に幸せを」もたらすヒューマンコネクティッドな社会の実現を目指すトヨタが見せる「未来」に期待しています。

文：神田 富士晴

---