“時代遅れ”にならないように愚直にスクラム開発する　トヨタ自動車の「ソフトウェアファースト」の考え方

安全安心を担保する

関沢省吾氏（以下、関沢）：ここまではUXの企画やデザイン、コンセプトの検証のフェーズについて話をしてきました。このような検証された価値や体験からくるユースケースをベースに、実際のUIの細かいデザインを実施していくことになります。

ただ大前提として車のUIというのは当然ナビやメーターといった車のユーザーから見えるところの表示器や、操作するものになります。実際車は走行するわけでして、ここでしっかりそれに応じた要件を入れ込まないとユーザーにとっては非常に危険なUIになってしまいます。

いかに安全安心で、かつ、使い勝手がよく、操作やユーザーへの情報伝達を行うことができるかがポイントになります。なおかつ、我々は全世界でさまざまな車に対してUIのソフトウェアを開発していますので、その対応も必要になってきます。

これから車のUIデザインをするうえで気を付けるポイントを簡単に説明いたします。第一に、先ほども言いましたが、安全安心を担保することです。運転しながら安全に操作でき、かつ、ユーザーは情報を取得する必要があります。

みなさん、歩きスマホはいけませんよね。人にぶつかったりして怪我をさせてはいけません。基本的に同じことで、運転を阻害することをさせてはいけないわけです。いかにわかりやすく情報を運転者に与えて、またすばやく操作、タスクを完了させることができるかがポイントになります。

例として走行規制ですが、走行中の操作を規制しています。例えば目に入って見えてしまうような動画を禁止するなど、また1つの操作を8秒以内で完了することも要件としていれています。それもできるだけ早くですね。

伝える情報の優先度

次に視認性と可読性です。小さすぎると見えなくて凝視してしまいますし、見えやすいフォントである必要性があると思います。年配の方々には特に重要になると思います。

文字数に関しても運転中に熟読しているわけにはいきませんので、例えば日本語だと30文字以内に抑えるようにしています。これらは言語によっても違っていて、英語などだとまた違う文字数の規定があったりします。弊社の社内規定でも認知するまでの目標として何秒以内、といったことを要件としてやっています。

ここでまたうまく使いたいのが、最近特に多くなってきている音声操作ですね。音声で操作することで、運転の視線を外すことなく操作することが可能になります。使い勝手の面もあるのですが、実は安全安心に寄与することもできる機能になります。

次に直感的な情報提示です。運転者が知りたい情報を違和感なく取得することが重要になります。情報によってどこに表示するのがよいのか、例えば中央にナビを中心としたディスプレイ、また運転席にメーターディスプレイがありますが、情報によってどこに出すのがよいのかを考えて設計しています。ナビとメーターはシステム的にもソフトウェア的にもかなり連携していて、そういった情報のやりとりの設計も行っています。

次に伝達情報とそのタイミングですね。実際にはUIで表示するほかに音や音声も使うことになります。視覚だけでなく聴覚も使った伝達です。それらとの連動も全体設計としては重要になってきます。内容に応じて音を変えたり、必要に応じて音声で伝えたり。そのときにUIに何を表示していればよいかと、感覚的にズレのないタイミングが非常に重要になってきます。

ほかには伝える情報の優先度ですね。例えば逆走注意の情報とナビの案内、どちらを優先して出すべきか。みなさんわかると思います。逆走しているのにナビの案内が終わらないからと逆走注意の情報の伝達が遅れては危険なわけです。

このような情報による優先度を細かく規定していて、それによって出す画面の調停をソフトウェアで行なっています。これらの情報の出し方、伝え方というのは車が高機能になればなるほど複雑になるので、人とのやり取りの中で非常に重要です。今後自動運転技術などが加わることで、さらに重要になってくると考えられています。

車特有の複雑な環境への配慮

次のポイントですけれども、車特有の複雑な環境への配慮です。車は外のいろいろな場所を走るわけですから、どのような環境でも見えやすくわかりやすい必要があります。例えば苦労するのは太陽光の反射です。前のガラスや横のガラスから直接日光が入ってくるわけですね。

それによって見えにくかったり、見え方が変わったりするものですから、もちろんハードウェアでいろいろがんばるところもあるのですが、色味の調整とUIで工夫をしているところもあります。ほかには昼夜の見え方、夜にヘッドライトを付けるとディスプレイの照度も自動で変わるのですが、そのときの見え方も考慮する必要性があります。

ほか、ヘッドアップディスプレイといってフロントガラスに映像を重畳するディスプレイも最近の車は特に増えてきていると思います。外界の物体と重なって見えにくくなることもあるので、色の出し方のケアが非常に重要になります。

最後のポイントになりますけれども、そのうえでお客さまのニーズに応じたさまざまな車種やデザインへの対応になってきます。商品性はもちろん担保しつつ、とはいえ全種類を作っていては開発規模としては膨大になってしまいます。最大限の共通化ができるように全バリエーションを見ながらデザインをしていくことになります。

パラメータになるのが、例えばブランディング、車両コンセプト。インストルメントパネルのデザインや車両のイメージとの一貫性が重要になります。例えばレクサスでポップなイメージのUIだとちょっと違ったかたちになってしまいます。

次にディスプレイサイズです。スマホのUIでも機種によってディスプレイサイズが違って、合わせ込むのに苦労されているかと思いますが、車も同じです。車に合わせて多種多様なサイズや縦横のアスペクト比が存在していて、それに対応していく必要性があります。

次は、これは車ならではだと思うのですが、ハンドルの位置違いです。例えば日本やイギリス、タイやオーストラリアといったところは右ハンドル。アメリカや主なヨーロッパなどは左ハンドルになります。ハンドル位置によって見える方向が違うものですから、操作性や視認性を考えて細かく設計を変えています。

ほかには多言語対応ですね。我々トヨタ自動車は全世界に車を提供しているため、多種多様な言語表示に対応する必要性があります。言語によっては同じ内容でも長さが異なるのでものすごく苦労するところです。

最たる例はアラビア語です。日本語だと（横書きの場合）普通は左から右に書きますが、アラビア語の場合は右から左に書かれているので、そういった表示の仕方も変えていく必要性があり、非常に苦労するところです。

こういった中でも共通化できるようにデザインはできるだけ工夫しています。ただ商品性が最優先のため、車のUIソフトウェア開発がかなり大規模になるとイメージがつくかと思います。

車もいろいろUIを見ると、見え方が変わる

最後、これらの要件を折り込みながらUIをデザインしていくわけですね。（スライドを示し）すみません、本当は新しいデザインを載せたいんですが、さすがに無理なので、すでに市場に出ているデザインを載せています。

これらは実例ですが、例えば視認性からする文字サイズ。こうして見ると、時計文字の大きさなどをケアしていることがわかるかなと思います。次に外環境の考慮。これはヘッドアップディスプレイですが、トンネルや一面真っ白な雪道といった環境でも見えやすく表示をする必要性があって、かなり苦労するところです。

また車種固有のデザインですね。レクサスのようなセダンもあれば、アメリカで主要なピックアップトラックもあったりします。またブランドとしてはトヨタとレクサスは大きく分けています。基調色が違っているのがわかるかと思います。

みなさん自分や家族や友人の車に乗るときに、一度こういった目線でいろいろUIを見ていただけると見え方が変わってきておもしろいかなと思います。私からのポイントは以上です。

実装・ユーザー評価のフェーズ

鈴木真一氏（以下、鈴木）：ここまではUXデザインの話をいたしました。ここからは実装・ユーザー評価のフェーズについて説明いたします。このフェーズでは開発、コーディング、実装、それからユーザーテスト、リリースまでを説明することになります。

ユーザーテストをした結果NGになった場合は、今まで話をしたアイディエーションだったり、UXのデザインだったり、そういったところに実際は戻ることになりますが、画面の関係上、省いています。

開発の後段でそのような手戻りが発生すると大変ですので、今まで説明をしてきたアイデア・コンセプトの検証など、デザインの検証は非常に重要だなということがわかっていただけるかなと思います。

それでは工程の詳細の説明をいたします。まず実装・ユーザー評価のフェーズになります。UIの開発はデザイナーが作成したデザイン、アニメーションを、UIフレームワークを使って実装していくという工程になります。

実際に使っているツールについては割愛いたしますが、汎用のツール・フレームワークをうまく使ってできるだけ軽く、早く、品質よく作っていきたいと考えています。

ただこういった汎用のフレームワーク・ツールは流行り廃りが激しく、エンジニアは常にアンテナを高くもってツールやフレームワークのリサーチ、あるいは変更されても、新しいものに変わっても追従できるような基本的な理解が必要かなと考えています。

こういったところを進めていく中で、デザイナーが作ったデザインを実際に実装に落としていくときには自動で変換するツールも非常に重要になってきますので、我々もいくつかそういったものを過去も今もトライをして作っていっています。

みなさんもご経験があるかと思いますが、想定していたデータがツールのバージョンアップによって使えなくなったりということもありますので、ツールを選ぶときにはそういったことも含めて選んでいるというのが現状です。

できるだけ実際の車に近いかたちでユーザーテストをする

次がユーザーテストの部分になります。今までもいくつかユーザーテストをしてきましたが、ここでのユーザーテストで一番重要なのはできるだけ実際の車に近いかたちでのユーザーテストをするということになります。

例えば、単純にパッドを使って評価するのではなくて走行テストを行ってユーザーテストをするなど、シミュレーターを使うみたいなことがここでは重要になります。

ユーザーからいただいたフィードバックについては、できるだけ早く修正をして、実際に直したものを再度ユーザーテストしていただく必要があります。過去の事例になりますが、こういったかたちでいろいろなツールを用意してその日のうちに再度テストができるということを回しているようなプロジェクトもありました。

場合によってはこういったツールも作らなければいけないくらいユーザーテスト、ユーザーに確認していただくという、そういった工程は重要だと考えています。

できる限り効率化を進めていこうと考えてはいるのですが、実際問題、先ほど関沢からも説明があったとおり、バリエーションが多かったり、仕向けが多かったり、あるいは車によっては別のある車ではなかった機能があとで突然出てきたりということもありまして。どうしてもバリエーションが多くて、開発が大規模になりがちです。

バリエーションが増えて、かつ、メンテナンスもそれを継続していかなければならないということもありますので、ユーザーテストを行いながらどんどん改善をしていくということを回しながらも、大規模な開発をどうやって回していくのかというところが開発の中では一番大きなチャレンジになります。

時代遅れになってしまう問題

（スライドを示し）大規模な変更をよくする開発について、もう少しまとめた資料がこちらになります。まず変更が前提になります。お客さまの期待値というのは常に変わります。新しいUIのトレンドや新しいサービス。今みなさんも困ってらっしゃると思いますが、新型コロナの影響もUIに対しての期待値の変化につながるところがあります。

その一方で、具体的な数字はなかなか述べることは難しいのですが、何千枚もの画面があって、何千APIみたいな、そういった大規模開発になります。車の開発の日程と連動した開発をしていかなければいけませんので、期限の順守も非常に重要なポイントになります。これらの3つをうまくバランスを取って開発をしていくところが大きなチャレンジです。

（スライドを示し）このようなチャレンジに対して今までの開発の手法がどうなっていたのかを示している図がこちらになります。簡単な絵になっているのですが、企画から3年、車の形になる頃にはすでに考えていた企画が時代遅れになってしまう、そういったことが起こっていました。

スケジュールを後ろから見ると、車の開発というのは実際に量産をする前に量産の工程を作る必要があります。その量産の工程を作って、そこで車の試作をして本当に作れるかどうかを確認する。量産の工程をどのように作っていくのかを考えるための試作があるみたいなかたちで、（スライドの）上のプロセスになりますが、3年や4年、そういった長い期間かかる開発になっています。

それに合わせたソフトウェアの開発をしようとすると、（スライドの）下のプロセスのようになって、先ほども申し上げましたとおり企画をしてから実際にお客さまの手に届くまでが長い、時代遅れになってしまうというのが問題でした。

愚直に大規模なスクラム開発をする

（スライドを示し）ここに対して我々は最近どのような開発手法を取っているのかというのが、こちらの絵になります。単純に企画をしたものを作っていくのではなくて、今までであれば評価をしてバグフィックスをする。

時代の要望に沿ったかたちで要求仕様を変更してアジャイルで機能を追加していく。そういったことを並行してやっていくことで商品性の維持というところを狙って開発をしています。

ただ、イメージされるとすぐわかるかと思うのですが、商品性の維持をしながらもバグフィックスをしていかなければいけないので、どうしても日程遅延のリスクがあります。

ここに対して我々の取り組みとして何をしてきたかというところについて少し説明したいと思います。実際になにかすごいことをしているわけではなくてですね。愚直に大規模なスクラム開発をする。スクラム開発でアジャイル開発をしていくことと、CI/CDの環境をきちんと準備をしていくことで対応しています。

スクラム開発に関してはいろいろな要求があります。先ほどの要求仕様の変更であったり、バグの指摘であったり、そういったいろいろな要望を、POを1人立ててバックログで管理して、実際に開発をしていくということをやっています。

単純にアジャイル開発、スクラム開発で言いますと、要求を開発するというバックログだけ作ることがあるかと思いますが、バグフィックスに関してもきちんとバックログで管理しています。どのくらいバグが発生しているのかというのを見ながら、バッファもきちんと用意をして、直さなきゃいけないものはすぐ直せる体制を取って開発をしてきました。

スクラム開発は大変だけど成長したと実感

（スライドを示し）こちらのページが実際のプロジェクトでどのようなベロシティの変化をしたのかというのを表しているグラフになります。なかなかこのようなグラフを出すことはないのですが、ご参考になればと思います。

左側が各スクラムの、小さなスクラムチームのベロシティとバーンダウン。右側がプロジェクト全体のベロシティの様子になっています。各チームのベロシティも右肩上がりになっていますし、プロジェクト全体のベロシティも右肩上がりになっています。我々としては愚直にやりました。大変ですが成長したと実際に感じています。

ただ、スクラム開発を愚直にやれば本当にベロシティが4倍になると思ったのですが、4倍になっていないのが唯一の心残りです。

（スライドを示し）こちらが我々の用意したCI/CDの環境になります。一般的なCI/CDのパイプラインと大きく変わらないかと思うのですが、唯一ちょっと特殊なところが、これらのシステムをすべて、時代遅れなオンプレで作っているというところが少し違うところになります。

企画をした当初はセキュリティの懸念もあったのでオンプレでやったのですが、最終的にはオンプレでやったことでいろいろフレキシビリティも高くてよかったと思っています。

中身としては、よくあるようにリポジトリの中のコードの変更をトリガーにビルド、テストを実行しています。最終的にできあがったものについてはSDKのかたちでDockerのイメージとともに開発者に渡るようにして、同じ環境でみんなが開発できるようにしています。

Nightlyではリグレッションテストなど、車の中のソフトになりますのでセキュアコーディングの対応ができているかどうか。それから不正なコードが混入していないかを確認するようにしています。各ジョブの進捗状況については、チャットのシステムと連動して開発者に通知するようにしています。

失敗事例の共有

このような環境を愚直に作ってきているのですが、なにぶんあまり経験もない中やってきていますのでいろいろ失敗がありました。その失敗事例をみなさんと共有したいと思います。

まず1つ目になります。ユニットテストの運用ルールを細かく決めずにテストコードを作って、うまく自動でテストできればいいかなというくらいの軽いノリでやってしまったことで、ビルドとユニットテストだけで半日かかるようなジョブを作ってしまいました。

リリース直前になりますと、いつもこのジョブをどうするのかということが問題になりました。テスト、ビルドのノードがこれで詰まってしまうということがありましたので、1人誰か監視をして詰まりがなくなるようにジョブを調整する。そんなようなことをやってしまっていました。

ここの反省としては、やはりテストの時間の上限を決めるなど、目安時間を決めるみたいなことが非常に重要です。今で言いますとGitHubのActionsなどだと上限6時間で切られているみたいな、そういったことは非常にリーズナブルなのかなと思っています。

次が失敗事例になります。我々組み込みのシステムを作っていますので、実際に動くSoCがアーム状になります。そのためテストをするためのテストノード、CPUのシミュレーターを使ってテストをしておりました。

開発当初は比較的スペックの高いサーバーを用意していたので大丈夫かなと思っていたのですが、実際にやってみるとここがCPUのシミュレーターであることによって非常にジョブが回っていかないということが起こりました。

最終的には、これはオンプレでやっていたから簡単にできたと思うのですが、大量にアームの実機を用意して、そちら側でテストを実行して、なんとか開発を進めたみたいな事例がありました。

次が最後で、失敗事例3になります。差分を常に確認していきたいと思っていましたので、ビルドとテストは変化があった部分のみをSDKをベースに差し替えるかたちで実施していました。

当初はなにも考えずに毎回そのSDKをダウンロードしてとやっていましたが、I/Oが非常に重くなってうまくジョブが回らないことが起こるようになってしまいました。

NASのローカルへのミラーリングや、パッケージのキャッシュを行うことでなんとか今は動いています。ストレージのI/Oも含めてCI/CDの環境を作るには重要だと勉強しました。

お客さまに提供できる価値を無限大にできれば

このようなかたちで愚直にスクラム開発の適応、CI/CDの環境の導入ということで、大規模開発であってもアジャイル開発に近いかたちの開発ができるようになってきました。

UX/UIの開発に関しては要件の定義もアジャイルですし、開発もアジャイルですので、その2つのアジャイルをバックログでつなぐかたちで開発を進めていくということを考えて進めていっています。この2つのアジャイルの輪がつながって、お客さまに提供できる価値を無限大にできればよいと我々は考えています。

最後になりますが、本日はUX/UIの設計・開発と大規模ソフトウェアの開発ということでお話ししました。最近の車は特にコックピット周りのデジタル化が進んできていて、今日お話ししたようなことが非常に重要になってきています。今日の内容が少しでもみなさまの興味に応えられたらよかったかなと思っています。

第2回の勉強会の説明自体は以上になりますが、次回の第3回について案内をしたいと思います。次回は12月16日木曜日、同じ時間に開始される予定です。テーマは『ソフトウェアエンジニアが支えるデータフローとその未来』というタイトルで考えています。

私たちではない別の人が登壇します。おもしろい内容だと思いますので、私もぜひ視聴したいなと思っています。みなさんもよろしくお願いいたします。以上です。

司会者：ありがとうございました。

（会場拍手）

みなさまありがとうございます！　では続きまして質疑応答に移らせていただきたいと思います。みなさん、視聴中にもたくさんコメントや質問ありがとうございました。どんどんどんどんチャットが流れていく様子が見ていて私も楽しかったです。

（次回につづく）