ソフトウェアとクルマ開発はどうリンクするのか？　トヨタのエンジニアリングにおけるシステム設計の重要性

クルマ開発におけるライフサイクル

長尾洋平氏（以下、長尾）：それでは今までクルマの開発のおもしろさと大変さに少し触れたところで、話題を変えてみたいなと思っています。

今表示しているスライドなんですけど、工業製品はクルマに限りませんが、企画から設計、製造、販売、運用、破棄もしくはリサイクルといったかたちのライフサイクルが存在します。クルマのように規模が大きくなればなるほど、このライフサイクルを正しく支えていくことが困難になってきています。

我々もクルマを作っていますので、このライフサイクルを正しく支えるために何が大事かというと、クルマというシステムも正しく理解することが大事になってきます。このクルマというシステムを正しく理解するためには、今スライドに出ている3つの要素が大切だと考えています。

1つはスライド左下に置いているクルマ全体のシステム設計、もう1つは右下に置いているシステム情報のDX、そしてそれぞれの情報を正しく使える開発のプラットフォームになります。それぞれの要素において従来よりもソフトウェアの重要性が増してきていることがトヨタ自動車の実情になります。

ソフトウェアがいわゆるスマートフォンのアプリケーション開発という意味では今は使っていなくて、少しイメージが違っているかもしれませんが、こういったソフトウェアの力を活用してクルマのライフサイクルを正しく支えていく活動がトヨタの中にあります。ここからは今紹介した3つの要素を1つずつ取り上げまして、トヨタ自動車の中の活動の一端を少し紹介していきたいなと思っています。

まず1つ目ですね。1つ目はシステム設計という部分に関してです。まずトヨタ自動車のクルマ開発はみたいな少し古い話から入りますけど、トヨタ自動車のクルマ開発は多くのサプライヤーさんと一緒に機械部品開発やメカトロニクス部品開発から中心に、専門領域を詳しくしながら伸ばしてきた。下に書いているトヨタ自動車が育ててきた専門領域と書いています。

こういった領域は社内では制御設計なんて言われたりするんですけど、この制御設計をするにあたりまして真ん中に黄色で書いているMBDを使ったりします。これはModel Based DevelopmentとかModel Based Designの略になります。

ただ今後、クルマという開発規模が大きくなってくると、この機械部品とかメカトロニクス部品の延長線上にはあまりない新しい専門領域、もしくはトヨタ自動車が革新しなければならない専門領域が存在します。

それが一番右に置いてあるシステム開発になります。このシステム開発として今我々がチャレンジしようとしているのはシステムズエンジニアリングという考え方ですね。こういったものを取り入れながら、このシステム開発という部分に関してソフトウェアの力を最大限に活用しながら革新していきたいと我々は考えています。

ちなみにMBSEのSEの部分がシステムズエンジニアリングになりまして、冒頭のMBはModel Basedになります。本体はSEですね。MBは手段になります。

ソフトウェアエンジニアリングとクルマ開発はどうリンクするか

長尾：とはいえソフトウェアと私が紹介したクルマのシステム設計がうまくつながらないなと感じられる方もいらっしゃると思いますが、それに対して私なりの見解をお伝えします。

いわゆる、ソフトウェアのプロダクトを作るために使うソフトウェアエンジニアリングといった技術体系は、システム設計で使うシステムズエンジニアリングという領域においても有効で、もう少し砕けた言い方をすると潰しがきく技術だと考えています。

例えば、システムズエンジニアリングにおける設計手法の1つとして、オブジェクト指向設計が存在しています。これはソフトウェアのほうで少し前になりますけど、流行った設計手法だったりしますね。そういうものはシステム設計でも有効であると世の中では考えられています。

では、それだけなのかという話になるんですけれども、いくつかは私の私見が入っていますけど、他にソフトウェアとシステム設計で同じように使えるような技術はあるのかに関していくつかあげたいなと思っています。

例えば、私が考えるのはいわゆるアジャイル開発手法と呼ばれているようなプラクティス群が、56種類ぐらいあると思います。そういった考え方、やり方はシステム設計やソフトウェアに関わらず適用できます。

あとは少し前の考え方になりますが、しっかりと地に足が着いている考え方としてプロダクトライン開発やオブジェクト指向設計、フィーチャーツリー、テスト戦略、テストのメソドロジーですね。テスト手法の選択のことですね。テスト手法とは、境界値分析や同値分析など、手法のどれを選択するかというテスト戦略ですね。それはシステム設計でも、ソフトウェア設計でも変わらないことになります。

あとは品質管理なども含む、開発のプロセスやワークフローになりますね。例えば、これは自動車関連でいうとISO26262などの規格が有名かなと思います。

V字開発の例に見る、ソフトウェアの考え方

長尾：そういったソフトウェアの考え方やプラクティスが、クルマの開発にどう適用されているのか。そのイメージを少し、簡単な図を使ってお伝えしたいなと思います。

スライドの青いVのところがよくV字開発なんて言われますけど、上のほうにはシステムデザイン、真ん中のほうにあるサブシステムデザイン、その下にあるソフトウェアの部品とかセンサーとかの開発。V字の反対側にいきますとテスト設計、そんなかたちになっています。

このV字開発に対して今冒頭に書いているんですが、テスト駆動開発というアジャイルのプラクティスと継続的インテグレーション、これもアジャイルのプラクティスの1つですね。

これらを組み合わせるとどうなるのかを少しご紹介したいなと思います。その2つを組み合わせるとこんな図になるのかなと思います。まずV字の左側は仕様や設計をする場所ですね。そこで作った設計に応じて先に右側でテストを作るんですね。このテストを先に作るのがテスト駆動開発と呼ばれているプラクティスになります。

毎日なのか毎時間なのかわかりませんけど、右の赤い丸がそこで繰り返しテストをする仕組みを作ることになります。当然、仕様を作ってすぐテストすると、全部テストはfailしちゃいますよね。それで良くて、そのテストが正しくすべてpassするように、モノを作ろうという考え方になります。

トヨタ自動車として大事になってくるのは、そのプラクティスを「あそこの部署がやっている」「そこの部署がやっていない」という感じにしちゃうと、うまくクルマとして成立しません。一番下にある部品から車両のレベルまでを包括的に日々実行して、自動化して、品質状態を見える化して、最後に結果をAIなどで分析して各フェーズのテストをフィードバックして、戦略的に昇華していく。こういったことをやらなければいけないと考えています。

こんなふうにソフトウェアのプラクティスを、システム設計にも応用していきたいと考えています。

LEXUS「F-SPORT」にも活かされるソフトウェア

長尾：では次の話題にいきたいと思います。私から今日ご紹介したい具体例がここに出ているメーターになるんですけど、もしかしたらご存知じゃない方もいらっしゃるかもしれないので、念のためお断りしておきます。

LEXUSというブランドがありまして、トヨタ自動車が展開している少しハイグレードのブランドになります。このLEXUSというクルマに、今表示しているメーターはF-SPORTといって、各LEXUSにグレード設定で存在しているんですね。

このF-SPORTがついているLEXUS車を買いますと、このメーターが漏れなく付いてきます。このF-SPORTというクルマは個人的に僕が好きなだけなんですが、デジタルのメーターの丸い部分がメカ的に動くようになっていまして、デジタルの表示と連動するんですね。なのでデジタルとメカと3次元の造形美が融合していて、個人的には好きなメーターの1つです。

話を戻しますけど、このメーターという部品は単にかっこよく表示すればいい部品じゃないんですね。例えば、法律などで表示しなければならない内容や大きさが細かく決まっていたりする部品があったりします。法律で決まる部分があるということは、国によって違いが出てくることなんですね。

なので先ほど述べたように、そういった細かな違いが出てくる部品を正しく世に出すためには、そのシステム自体を正しく理解できていないとダメになります。

では、そのメーターの中からご紹介します。具体的な中の写真というか、開発時の写真を持ってきたんですけど、これはあるクルマのメーターに搭載される新機能の設計をレビューするために印刷した資料の一部になります。

図形のようなものがスライドのあちらこちらに見えていると思いますが、これはUMLやSysMLなどと言われている表記方法になります。単純に言うと、世界の誰が見ても同じ意味にしか取れないような言葉である「モデリング言語」と呼ばれているものですね。こういったものも、もともとソフトウェアの世界発祥でスタートしているものでした。

これを我々としては、メーターのシステム設計にも応用していくと考えて、活用していきます。工学的な手法をシステム設計にも活用することによって、品質をより確実なものにしていくことが我々の狙いになります。いずれにしても、このスライドでお伝えしたかったのは、ソフトウェアに関する知識は、やはりハードウェアが関係するシステム設計でも応用できると示す部分になります。

クルマ開発のシステム設計

長尾：では、もう少し生々しい数字をお見せしたいなと思っています。今20、600、400、50という数字をスライドに印字してありますけど、これは先ほどのメーター設計の規模を表している数字になります。それぞれどんな数字なのかをイメージできますか？少しだけ想像してみていただけたらと思います。

答え合わせにいきたいと思います。答えが上の2つが静的な構造を表すための設計で使っている数字、下の2つがメーターの動きですね。動的な動きを表すための設計で使っている数字になっています。もう少し専門的な言葉になってしまいますが、UMLという範囲の言葉で説明しますと、20がクラス図の数です。600がその中で使われているクラスの数ですね。

400が動的な振る舞いを定義するシーケンス図の数になります。そして50が別の側面で動的な設計を表現するアクティビティ図の数になります。どうでしょう？　こういったソフトウェアの設計に関して、少し知見がある方向けにもう少し掘り下げて補足しますと、600のクラスに10のメソッドがあると想像してみていただいて、その10のメソッドが単純にそれぞれ100行ずつあるねという世界を想像していただきたいなと思います。

そうすると、単純なかけ算でそれだけでも、60万行のソースコードを作らなければいけなくなるんですね。もちろん、それ以外にもまわりで設計しなければならないものや実装しなきゃならないものもあるので、＋αされてはしまいますけど、だいたいこれぐらいの規模だとイメージしていただければ、これを紹介した甲斐があるなと思います。

今、僕がご紹介したのはシステム設計情報になるので、どの会社から見ても機密情報に該当します。なので、詳細な設計が公になることはそもそもありません。他社さんの情報を我々が知ることは当然できないわけですけど、少なくとも我々トヨタ自動車としてこういったシステムデザインをしっかりやっていくことはチャレンジとしては画期的なことだと考えています。

トヨタが推進するDXプロジェクト「TITAN」

長尾：では次の話題にいきたいと思います。飯山さんお願いします。

飯山真一氏（以下、飯山）：ここからは2枚のスライドを使ってトヨタ内で進めているDXの話を少ししていきたいなと思っています。我々がDXの推進に向けて活動している事例になります。簡単に言うと、クルマのシステムの設計情報を管理して、より品質が良いシステムをより早く開発するためのIT基盤を自分たちの力で産み育てようというプロジェクトになっています。

自分たちで作ることは、その基盤の中の中枢にあるソフトウェアは自分たちで作るという意味になります。プロジェクトの名前は「TITAN」と名付けています。巨大なクルマのシステム開発を陰ながら支えるプロジェクトという意味で、ギリシャ神話に出てくるタイタン族のアトラスという神になぞって命名しています。

このプロジェクトで何をしているかについて、すべてをお話しすることはできないんですけど、まず取り掛かっている内容としては、必要な設計情報をデジタルにつなげて、通信仕様の開発期間を圧倒的に短縮することです。IT基盤を自分たちで作ることは、他の企業の方にとってはごく当たり前のことなのかもしれませんけど、少なくともトヨタ自動車にとっては画期的なことだと私は思っています。

自社の製品であるクルマに入るシステムやソフトウェアを作ることはあっても、それを設計、開発するための全社的な基盤システムについては、ITベンダーにお願いすることが一般的かなと思っています。それを自分たちで作ることはこれまでなかったのではないかなと思っています。

これまではそれでよかったと思うんですけど、これまで以上に良い製品を素早く作るには、それを作る道具を自分たちのやり方、プロセスにうまく合わせて作っていく必要があります。それをしっかり作り込んでいくことが、ますます重要になってきていると思っています。よく職人の方が何かの作品を制作される時に、それにあった道具を自作されることに似ているのではないかと思います。

そうすることで、時代の変化に合わせて作るものや作り方、そういったものを変えざるを得なくなっても、それに合わせて柔軟に道具を作り変えて素早く対応できるようになります。とくに変化が加速度的に大きくなっているソフトウェアに関する分野については、こういった取り組みはますます重要になってくるのではないかと私は考えています。

このように自分たちで道具を用意することで、前のスライドでお見せしたような多くのシステム設計情報が複雑に絡み合う問題を、何か状況が変わっても素早く、柔軟に解くことができるようになります。ひいては、クルマを買ってくださるお客さまに対して、品質の良い製品やサービスをより安く、より早く提供できるようになるのではないかと思っています。

スクラム開発で自律的なチームへと変ぼう

飯山：このスライドの最後にインセプションデッキとして有名な「我々はなぜここにいるのか？」という問いに対してメンバー全員で考えたものを紹介したいと思います。ここのスライドの右下にあるものですね。

表現としては非常に幼稚になっているかもしれませんけど、プロジェクトに関わるメンバーがそのソフトウェアの力を借りてトヨタを変えていこうとしているリアルな気持ちや熱量を感じていただけるんじゃないかなと思っています。

さらに次のスライドに行くんですけど、これは実際にどうやって開発をしているのかを紹介したいと思っています。プロジェクトの開始当時、クルマのシステムの設計情報は、ある程度見える化をしました。

それよりもまだまだ見えていない情報があるような状況でしたので、それでクルマのシステムの全体を詳細に把握している人は誰もいなくて、システムの設計者を知らないデータ同士のつながりであることも見えてきたりしていました。

そういった情報を入手して分析しながら、こういったソフトウェアをどんどん更新していくやり方として、このプロジェクトではスクラムを使っています。また、コロナの影響もあって、全員がほぼ自宅からフルリモートという状況でスクラムを実践しています。直接会ってのコミュニケーションを前提とすることが多いスクラムなんですけど、フルリモートでやるのはなかなかないのではないかなと思っています。

ただし、普通の車両開発のほとんどがこんなことができる状況ではありません。まだまだそういう状況ではなくて、このプロジェクトについてはフルリモートで開発できる条件が揃っていたとご理解いただければと思います。

プロジェクトの中身に話を戻すと、とにかく現場で使えるものにこだわって作っています。実際そのユーザとなるそのシステム設計部署のメンバーに実際に入っていただいて、作ったものを見てもらってフィードバックをしてもらうかたちをとっています。

このプロジェクトが始まって、スクラムがある程度の期間をこなしてきましたので、開発メンバーも慣れてきて、個々人の自律的な動きがどんどん出てきていますし、同じ方向を向く連携のレベルが上がってきている状況です。

スクラムという手法を使うことで、プロジェクト全体が活性化されていると私は感じています。スクラムを適用した成功事例の1つと言える状態になってきておりまして、こういった活動を広げて、社内外問わず仲間作りをしていこうとしているのも、我々の挑戦の1つになっています。ここで、このTITANのプロジェクト紹介は終わりたいと思います。

スマートシティ「Woven City」が目指すもの

長尾：ではここから開発プラットフォームに話を移したいと思います。ここで最初に説明した3つが大事だという話に対して、システム設計の話と設計情報のDXの話をしました。

最後の1つは開発プラットフォームになります。実は開発プラットフォームに関しては、みなさん去年トヨタがスマートシティを作るというニュースをご覧になりました？　覚えています？

そのWoven Cityを実現していくにあたりまして、woven planetという関連会社が今、トヨタ自動車にあります。そこは去年までTRI-ADと呼ばれていた会社なんですけど、今年から社名が変わりました。このwoven planetの中ではシティの話もしますし、いろいろなことをやるんですけど、その中の1つにAreneと呼ばれているものが存在します。

このAreneと呼ばれているものは、実は「The most programmable vehicle on the planet.Enabling open vehicle programming for everyone without compromising safety or security」と書いております。つまり、地球上で一番プログラムしやすいクルマを目指すという、そんな開発プラットフォームを目指すプロジェクトをやっております。

当然、トヨタ自動車も自動車のプラットフォームをまずは目指しますので、そこにコントリビュートというか一緒に共同してやっていくことを、今は私がwoven planetと兼務するかたちでやっていたりします。詳細はwoven planetのURLをご覧いただければなと思います。本日はここまでにいたします。

「プロになろう！」に込められたメッセージ

長尾：それではここから今日のまとめに入っていきたいなと思います。まずは2019年の年度に我々の社長の豊田（章男）が「みんなプロになろうよ」という話を社員に向けて言いました。実はこれはトヨタイムズというINSIDE TOYOTAの#1に掲載されています。YouTubeでもご覧になれますので、もしご興味があったらご覧になってみてください。

この「プロになろう！」という言葉なんですけど、一芸に秀でたスペシャリストという意味が当然にありますけど、トヨタの中ではそういった人の背中を見て、周りへもよい影響を与える人物像を求められています。

今までの過去の話を少し触れますと、トヨタはクルマという大きなシステムを作る会社でしたので、どちらかというとスペシャリスト側よりは、ジェネラリストになることを良しとされる風潮、全員ではないんですけどそんな風潮がありました。

ただ、ソフトウェアに関わる方はどちらかというとスペシャリストになりたいというマインドの方が多いかなと思いますので、正直、過去はそういう活躍の場が限定されてしまうこともあったのかなと想像しています。ただ、今はソフトウェアの力を使ってより良いクルマを作ろうよ、という流れが社内にあります。

なのでソフトウェアのエンジニアの方はぜひ来ていただけると、システム設計から先ほどご紹介しました実装まで幅広く技術を使える選択肢が増えてきているので、存在価値や仕事の楽しさがなかなか広がっているんじゃないかなと個人的には考えています。

スライドは、そういったソフトウェアのエンジニアもしっかりと価値を認める動きを、トヨタの経営理念として表現している円錐です。トヨタはクルマというシステムを構築しているんですけど、（これからは）装置としてのハードウェアをソフトウェアで柔軟に変化させていくことが裏に込められています。そのため、ソフトとハードが同じのValueのところに書かれています。

我々は「幸せを量産する」「モビリティを社会の可能性に変える」の上に、手段としてソフトとハードを含めて対等にやっていくことが経営理念として、すでに謳われています。そういったソフトウェアエンジニアのみなさまも、広がっていくトヨタ自動車に今後もご期待いただけるとうれしいなと思います。今日は以上になります。ありがとうございました。

（質疑応答につづく）