EVや自動運転、コネクテッドカーなど、モビリティにおける車載システムの高機能化を支え、ハードとソフトの境界を担う次世代ソフトウェアプラットフォーム。そこでのソフトウェア品質の考え方にも今、変革が訪れている。本田技研工業株式会社（以下、Honda） SDV事業開発統括部で配信ソフトウェア品質の責任者を務める久木 隆と、ソフトウェア品質研究の第一人者で製造業での知見も豊富なAGEST高橋 寿一氏が語り合う。
【Honda技術者が識者と語り合う vol.3｜Honda×AGEST高橋寿一氏コラボ】SDV時代のソフトウェア品質とは——安全とスピードを両立するため、Hondaのエンジニアが考えていること
この記事に登場する人
INDEX
なぜ、「北米オデッセイ」のインフォテインメントシステムの品質問題が発生したのか
──いま、HondaにはSDV開発において、ソフトウェアの品質をいかに維持、向上させるかという課題があります。もちろん、これまでのHondaはエンジンなどの制御ソフトウェアではテストを繰り返し、品質の作り込みをする文化があったわけですが、これまでの品質への考え方とSDV時代における考え方とでは何が変わってきているのか、そのあたりからお話を伺えますか。
クルマは人の命を預かる乗り物ですから、事故を起こしてはいけない。エンジン、ブレーキ、ステアリングの制御などはミッションクリティカルなものなので、ソフトウェアのホワイトボックステストはもちろんやっていますし、ステートメントやブランチも全部チェックして、カバレッジも100%を目指してやってきました。
当然ブラックボックステストもやって、要求仕様通りチェックしても見つからない場合は、探索的テストや意地悪テストなど、そういうのも試行錯誤しながら追加してきたという経験があります。
社内のソフトウェアの品質基準は基本的にミッションクリティカル※なパーツを前提に作られていて、バグはゼロでないと世の中に出さないというルールがあります。もちろん現実的にゼロというのはありえないんですが、少なくとも開発中に見つかったものは全て直してから出荷する。そのためにはかなり長い時間をかけてテストする。そのテストをウォーターフォール型でやってきました。
ただ、ナビゲーションやインフォテインメントシステムについては、ソフトウェアの進化が早いので、そんなに時間をかけてテストをしても、出した頃には何の魅力もないものになってしまう。ミッションクリティカルなものとは別に、テストのやり方を変えるべきではないか、という問題意識は以前からありました。
※ミッションクリティカルとは 「業務遂行に必要不可欠な要素」（ソフトウェア、機器、手順、ソフトウェアなど）のこと。
また、カーナビシステムはTier1※のサプライヤーが開発したものを購入することが多いので、サプライヤーが「バグゼロ」を保証するのであれば、それを信じて量産するという形でやってきました。
そういう形で、これまでは社内の仕組み的には成り立っていたのですが、これだとサプライヤーにとっても開発費がかかるし、リスクもあるというので、北米の開発センターでは、私が赴任する直前の2017年ごろからインフォテインメントシステムについては内製することにしたんです。しかも、それをアジャイルで開発するという試みに取り組んでいました。日本ではまだ内製化が進んでいない頃の話です。
内製開発をアジャイルでやれば、開発スピードは上がるのですが、ここで問題が起こります。2019年に私が北米に赴任したちょうどその日ですが、「Hondaの“オデッセイ”がクラスアクション（集団代表訴訟）を起こされた」というニュースが飛び込んできたんです。
インフォテインメントシステムの画面が、走行中にブラックスクリーンになってしまう。クルマを止めて、イグニッションをオフにして再起動すれば直るのですが、高速道路走行中にそんなことはできない。当然、お客様は大激怒なわけです。
なぜ、そういうことが発生したのか、原因を追及してみると、アジャイル開発なのでスクラムとかスプリントといった短期間のサイクルで開発をしていたのですが、スプリントの中でテストを終了できていなかったことが判明したんです。
※Tier1とは 完成車メーカーに直接部品を納品するメーカーのこと。
製品や機能に応じたソフトウェア品質目標値を設定すべき
この出来事は、私が開発のスピードと品質保証の両立について、改めて考えるようになったきっかけでした。定期的にスモークテスト※をやって、致命的なものが入ったらすぐ直せるように取り組んでいました。結局、内製ソフトウェアの品質確保が軌道に乗るまでには、2年間ぐらいかかりました。
自動テストやスモークテストでは、MTBF（平均故障間動作時間）を測り、その値をIQS（日本自動車初期品質調査）で評価するようにしました。当初はIQSの数値が低かったのですが、品質向上の取り組みを進める中で、かなり改善されました。
私は北米にいる間に、その実績を示しながら、「エラーの発生頻度とシリアス度のマトリックスで、比較的高いやつはちゃんとしっかり直しましょう。でもマトリックスの値が低いものは、基本的には後から直せばいいよね」というような提案をしたんです。
※スモークテストとは 本格的なテストを実行前に「テスト対象のソフトウェアがテストを行うに値する品質であるか」を確認するテストのこと。
ところが、当時はまだ受け入れてもらえませんでした。逆に「バグがあるって分かってるのを直さないで出すってどういう神経してるの？」って、すごい集中放火を浴びたりしました(笑)。まだ、SDVという言葉が出る前の時代の話です。
いま、SDVに取り組む中であらためて考えることは、自動運転中にお客様にコックピットでの体験価値を提供しようという時には、全部一律の基準ではなく、製品や機能の特性に応じた品質の目標値を設定すべきだということです。ソフトウェアのミッションクリティカル度に応じて、つまり、安全なものからエンターテインメント的なものまである中で、それらに合った品質の目標値を合わせないと、日々進化していくSDVに対応していくことは難しいなと感じています。
ただ、問題は、これまで「バグゼロ」を基準でやってきた文化を、個別にKPIを設定しながら品質を評価する文化に転換するのに、まだまだ時間がかかるということなんです。
「バグをゼロにする文化」はこれからも不変なのか
——高橋さんは、今の久木さんのお話をどうお感じになりましたか。
久木さんのお話を聞いていると、自動車の世界はいまソフトウェアの品質を担保するのが、他の製品に比べても、とてもきつい世界だという感想を持ちました。実は飛行機の方がまだ楽なんですよ。飛行機の方がソフトウェアサイズも小さいし、そんなに複雑じゃないし。別にコックピットの画面を素人がいじるわけではないので、ユーザビリティを担保する必要もあまりない。
しかし、クルマはそうはいかない。特に、ソフトウェアがこれまで以上に決定的な役割を果たすようになったので、ソフトウェア品質について発想の転換が必要になっているということですね。
それと、OEMとサプライヤーの関係も、伺っていて「なるほどな」と思いましたね。発注側と受注側はソフトウェア開発ではあるレベルで合意しているはずですが、テストの領域では実は合意していないところも結構あったりします。例えば、「コードは全部テストしてください」とOEMは言うんですが、サプライヤーは「はい、分かりました」とは言えないんですよ。テストはしたいんですが、コストの圧迫も避けたい。
品質についての考え方もそうで、本当にミッションクリティカルな部分をどう担保するかというところにおいて、クルマの世界ではOEMとサプライヤーの分担が、何十年も前からあまり合意できてないなという印象があります。
それでもやってこられたのは、クルマは開発期間が長いし、シミュレーターを使ったり、実機を動かしたりして、その間にバグはなんとか潰せていたからです。ところが、SDVの時代には、短い期間でクルマをアップデートしていかなければなりません。
では、OEM側がソフトウェアを全部内製にしてしまえばいいかというと、そのためには今度は、ソフトウェアエンジニアを大量に採用しなければいけない。それもそう簡単なことではないのは、よくわかっています。
「バグゼロ」の文化についても、インフォテインメントシステムと、ミッションクリティカルな制御システムで、考え方の切り分けができていないということは、私の経験からもそれは痛感します。正直に言えば、ミッションクリティカルな部分は「バグゼロ」の文化を維持すべきですが、ナビやメーターの表示系は、「バグゼロ」の文化でやっていくのは非常に難しいと思います。特にメーター系は新しい表示技術の品質担保のバランスをとりにくいと思います。
それでは、ソフトウェア品質について、社内に二重のルールを作るべきなのか。その場合も、二重ルール化に伴って、開発プロセスとか品質テストをどうするのかという課題があって、そこもクリアしなければなりません。どこがミッションクリティカルか否かを切り分けすることから考えないといけませんからね。
ただ、結論を言えば、ソフトウェア品質をめぐる問題がますます複雑さを増すなかでは、クルマの世界の品質担保の手法に、ある部分に、いわゆるSaaS的なやり方を適用しないともう追いつかなくなってきているのは、確かだということです。
SaaSというのは、私たちクルマのメーカーからすると、これまでIT業界とひとくくりにしていた世界のことですね。
そうです。IT企業の中でも、主にソフトウェア開発を提供している企業のことです。自社製品やサービス開発のほとんどがSaaS型にシフトチェンジしていますから。
1日に書くソースコード量。SaaS業界は自動車の数倍に
——ソフトウェアを巡る環境をグローバルに見れば、国内メーカー間のソフトウェア開発競争以上に、アメリカや中国企業との競争がありますね。Hondaは誰とどこでどのように競争していくべきなのでしょうか。
Hondaはこれまではソフトの開発といっても、別にソフトだけを開発しているわけじゃなくて、メカを含めたシステムの開発、機能の開発をしているんですね。その中にソフトという要素がある、という位置づけでやってきました。最低でもソフトウェア開発に2年ほどかけて、それをウォーターフォール型でやるので、私たちは「年」「月」「週」といったタイムスパンでものを考えてきました。
ところが、テスラや中国の新興OEMは、もともとITがベースだったりする会社もあるので、タイムスパンが「日」「時間」「分」と短期間の単位なんです。我々は今までメカ・エンジン・デザインといったところで戦ってきたんですが、今後ガソリンエンジンがなくなって電気自動車になると、バッテリーとモーターさえ買ってこれば誰もがクルマを作れちゃう時代になる。
差別化が難しい中で、どこで価値を出していくかというと、自動運転も事故ゼロも、やはりソフトで実現しないといけない。同時に、開発スピードについても、これまでの固定観念を外してやっていかなければいけない。
これまでの品質基準が時代遅れになっているのなら、それを変えればいいだけですが、仕組みと同時に現実のソフト開発力や品質力、新しい技術力を身につけていかないと、勝てないということは強く感じています。
1日に書くソースコード、コードの生産量は、自動車会社とSaaS型企業を比べれば、私感ですが、SaaS型企業の方が何倍も多いと思います。さらに彼らは生成AIを使ってもっと上げようとしているので、クルマの世界も今までの何倍ものスピードでソフトウェア生産性を高めないと追いつけなくなります。
ただ、クルマはスマートフォンとは違うということも、忘れてはいけないと思います。私はソニーにいた時代もありますが、ソニーだけでなく、日本の家電はほとんど中国にやられてしまいました。それと似た生産性競争が、クルマでも起こるかもしれない。とはいえ、クルマでは重要なところでソフトウェアがバグってしまったら、人が死んでしまうわけで、そんなことが起こった場合のブランドイメージの低下は計り知れないものがあると思います。
つまり、クルマにおいてもソフトウェア的な魅力をどんどん追加するべきだし、それを早くやるべきだけども、命にかかわる最後のところは絶対担保しないといけない。このミッションクリティカルの部分をちゃんと担保することができれば、テスラとかBYDにサクっと負けることはないように思いますけどね。
とはいえ、ソフトウェア開発の効率化は焦眉の課題です。ECU※の開発も、シミュレーター上でソフトウェアが動けば動くほど簡単なんです。日本のOEMはもっともっとシミュレーターを活用すべきだと思います。そのほうが、開発効率、テスト効率は断然よくなります。テストの自動化率の向上はシミュレーターの性能に大きく依存しますからね。
そもそも、ソフトウェア開発では、「開発コストの3割から4割が品質向上のためのコスト」というふうに言われていますけどね。クルマの場合はもう少し大きいですよね。
※ECUとは
Electronic Control Unit（エレクトロニックコントロールユニット）の略称で、車両のあらゆるシステムを制御する装置の総称のこと。どこまでを品質向上のためのテストに入れるかですけど、もしかすると半分を超えているという気もしますね。
だからこそ、テストの効率化やスピード向上には、きちんと投資すべきですよね。それが会社の将来を左右することになるはずです。
データ収集の要になるハードウェア設計に投資を惜しむべきではない
今までの自動車メーカーは、開発中にデータを取るけれども、売ってしまえばそれで終わりだったんですよね。ところが、テスラの場合は、販売した後、お客さんがドライブしている車からも、データを吸い上げている。それを使ってどんどん機能を改良しているようです。それこそが、SDVの一つの特徴だと思うのですが、データを取得するタイミングからして違っているんですね。
どこまでデータを取っているかは企業秘密ですが、テスラが走行中のデータを取っているということは、IEEE Software※の論文にも載っていることです。恐らく…これは想像に過ぎませんが、バグのデータも送って、アップデートに役立てているような気がします。
※IEEE Softwareとは
アメリカに本部を置く電気・電子工学、コンピュータサイエンス、情報技術などの分野で世界最大の専門家組織のこと。私もそう聞きました。Hondaではどうしているかというと、一応データは吸い上げていますが、テスラほどたくさんは吸い上げられていません。お客様からクレームがあり、ディーラーに車が持ち込まれたら、その時点でデータを収集する。それを品質部門が解析し、不具合だと確認されたら開発に行く。その間にもう1ヶ月ぐらいは経ってしまいます。
一方、テスラはもうその場で開発者が確認してすぐ直せるし、あと膨大なデータが集まるので、どれが本当の問題なのかも、多分AIなどを使って選別してるんじゃないかなって想像もしています。
そのためには、やはり最初からそれを考えたセンサーデバイスの配置など、最適なハードウェアの設計にしないと、役に立つようなデータをお客様の車から吸い上げることができない。これまではハードウェアのコストをいかにギリギリ抑えるかという発想が身に染みていて、余分な機能を載せるなんていう発想自体がなかったんですが、これからはそれではダメですね。
SDVとは言われますけれど、データ収集のデバイスはハードウェアリッチじゃないとできない。なぜなら将来拡張することまで考えて、データを集めるためのメモリだったり通信帯域だったりを持つ必要があるからです。
日本の企業は、本当に開発に必要なところを削っちゃったりしますからね(笑)
だからかもしれないけれど、家電で負けてしまった。日本のモビリティ業界はそこを削らず、しっかりとしたハードウェア基盤を構築した上で、ソフトウェアで頑張ってほしいなと思います。
人材流動化で変わる組織。業界構造にも変化の兆し
——そういう変化に対応するために、もちろん技術力を高めていくと同時に、それを可能にする組織へと変わることが大事ですね。SDV時代に合わせて組織を変え、人を変えていく。そういう動きも同時に進める必要があるのかなと思うのですが。
先ほど、高橋さんが指摘されたシミュレーターを駆使した開発環境も必要で、そのための社内プロジェクトも動き出しています。それと、ソフトウェア技術者の職場環境も大切ですね。我々はこれまで栃木で開発していました。
栃木は住むにはいいところですが、ソフトウェアエンジニアから見て魅力的かというと、必ずしもそうではない。特に経験のある方に来ていただいて、即戦力としてやっていただきたいといった場合には、いきなり栃木でというと、二の足を踏む人も多いことも承知しています。
そのために、Uターン、Iターンの人も含めて日本各地で仕事が出来るように、いま全国のソフトウェア開発拠点を増やしているところです。
その前提として、日本は人材の流動性をもっと高める必要がありますね。一つの会社にとどまるより、動くことのメリットのほうが、特にエンジニアの場合は多い。私は、マイクロソフトにいて、SAPにいて、その次がソニー。
ドメインの全然違うところだったけれど、ソフトウェア品質という点では一貫していて、別段何の苦労をせずにやってこられました。自分の専門領域さえしっかりしていれば、会社を移ることで見える世界はもっと豊かになると感じています。
企業にとっても違う文化の会社、違うドメインの会社にいた人が、移ってきてくれるのは大歓迎ですよね。
私が北米の開発センターにいたときも、iPhoneの「CarPlay※」での接続に不具合があったのですが、元HondaアソシエイトがAppleに転職していて、会議中にその場で電話をして聞いてみたら、どうやらiOSのバグらしいってことが分かりました。エンジニア同士の企業の枠を越えた横のつながりは、これからは会社にとっても貴重な財産になります。
※CarPlayとは
iPhoneを車載システムと連携して電子キーとして利用したり、カーナビのディスプレイでiOSアプリを使ったりできる機能のこと。
——先ほど、OEMとサプライヤーの関係についても話が出ていましたが、SDV開発が主流になると従来の業界構造も変わってくるでしょうか。新しいソフトウェアの時代における両者の関係を再定義して、両方ともハッピーになるような関係ができればいいな、というふうに思うのですが。
そこは、いま悩みながら考えているところですね。結局Honda1社だけで全てを開発することはできませんから、今まで一緒に頑張ってくれたサプライヤーとこれからも一緒にSDV開発を進めていきたい。
例えば、中国の自動車産業だと、ハードを専門で開発する企業が、EMS（受託生産）を超大規模にやっていて、コストも安く抑えています。さらに、ソフト開発だけを専門でやっている会社もたくさんあって、そこは複数のOEMにソフトウェアを供給している。そういう形で、業界全体のコスト構造を下げる努力をしています。
日本の場合は、各OEMが似たような機能にもかかわらず個別のソフトウェア仕様をサプライヤーさんにお願いしても、彼らもやりきれないと思います。専用でテーラーメイドのソフトを作っていたら勝ち目がないので、そこをどういう風に勝てる道筋を描くかっていうのをやっていかなきゃいけないなと。いますぐに答えは見つからないですけれど。
私にも答えはないですけれど、OEMにおける内製化率は上げた方がいい気がします。内製化率をどんどん上げていって、外部に委託する部分をしっかり区分けをしていくという考え方ですね。その上で、サプライヤーとOEMが一つのオフィスで仕事をするというのもありだと思います。顔を突き合わせる関係だったら、誰がバグを出したかもすぐわかりますから(笑)
Googleの例ですが、ソースコードの一部を変えると、例えばCI/CDがGCPで回ってすぐにイメージができて、その人がすぐにテストできるようになっている。クルマの場合はそう簡単ではないけれど、可能な限りGoogleのようなやり方をコピーしてでも、開発とテストの連動性、そこでの効率化は必須だと思います。そのプロセスをOEMとサプライヤーで共有できるようになれば、もっといいのですが⋯⋯。
私は「JASPAR」（Japan Automotive Software Platform and Architecture）という、日本のOEMやサプライヤーで作る業界の活動もしています。車載電子制御システムのソフトウェアやネットワークの標準化を進める団体ですが、これまでは非競争領域、開発ツールやAUTOSAR※のようなベーシックなソフトウェアでの協業というのが前提だったんです。しかし、最近は、もっと踏み込んでミドルウェアとかAPIとかぐらいまで拡大していかないといけないという議論が起きています。
やはり、「これからのライバルはどこなんだ？」ということを考えて、日本の中でつばぜりあいをしていてもしょうがない。OEMが倒れたらサプライヤーも成り立たないので、一緒にもっと効率を上げていって、中国やテスラに勝てるようにやり方を考えていかないと、本当に家電の二の舞になってしまうのではないかという、危機感をもっています。
※AUTOSARとは
モビリティ業界における車載ソフトウェアの標準化を目指す団体およびその標準仕様のこと。
ソフトウェアテストの「2年後の姿」
——高橋さんの専門領域であるソフトウェア品質テスト。そこでの先進的な考え方は自動車業界でも導入すべきだというような、テストという観点からみたソフトウェア開発のあるべき姿をお話しいただけますか。
クルマの開発もどんどん仮想化していくので、将来はクルマだろうがSaaSだろうが同じ形になっていくんだとは思います。そこで、AIの活用は必須ですね。例えば、MC/DCテストには厳しい基準があって、書くのがすごく大変。膨大なコストがかかるんですが、そういうのも、だんだんAIでできるようになってきました。現時点では実用化レベルとはいえないけれど、2年以内には必ずそのレベルに達するはずです。
あと、APIやインスタンス間の連携も、AIが定義するような時代がまもなくやってきます。システムテストもいずれAIが自動生成してくれるようになる。こうなると、いろいろなことが省力化され、テストケースだけ書いている人はもはや不要になります。
だからこそ、人間は品質向上の工夫をするべき。そこにこそ、人間の知恵を入れ込むことが重要。それだけ脳みそのレベルが高い人が求められるということですね。
クルマの世界にいきなりそれを持ち込むのはなかなか難しいけれど、そうした近未来を想定しながら、ソフトウェア開発・テストを進めるべきです。
テストの過程でバグが出やすいところはあるので、それをAIが予測して、この辺りがやばいから集中的にやらなきゃいけないとか、そういうこともアドバイスしてくれるようになるのでしょうか。
多分2年ぐらいで出てきそうだと思っています。プルリク（Pull Request）に対してAIがチェックしてくれるツールというのはすでにありますから。まだ全然役に立たないんですけれど(笑)
しかし、自社のソースコードとバグデータベースをクローリングして、プルリク時の警告を出してくれるっていうツールも数年後には登場していると予想しています。そうすれば、ここはバグが出やすいところだから、もうちょっとテストを厳密にやっていきましょうという世界になるはずです。
北米にいたころは立場上、何のバグを修正したかを確認しなくてはいけなかったのですが、やはり多かったのが、高橋さんの本にも書かれていた、マルチスレッドの入った制御のところでしたね。
そうしたもののもっと上手なテストの方法があるといいなと思うんですけれど、その辺って難しいのでしょうか？
それは多分、AIがヘルプしてくれると思いますが、そこはまた先になると思います。ただね、どうやってもテストできない部分というのは存在します。これは1980年代のデータで検証されていて、テストで見つけられるのは頑張っても30%。あとの70%のバグはテストで見つけられないという風に昔から言われていて、それは変わっていません。
かなりの部分がAIによって見つけられるようにはなりますが、マルチスレッド処理やインスタンス間の通信などいくつかの部分に関しては、AIを使ってもかなり厳しい。そういうところに対してはやはり人間が時間を使って検証しなくてはいけないですね。
クルマの場合、センサーが何十個も搭載されていて、それぞれに対して適切な処理を行う必要があります。そうした中で、絶対にバグを出さないようなテスト設計は、やはり人間が考えるしかありません。そこはやはりAIでも、どんな高速のGPUを使っても超えられないところではあるので、AIに頼るべきところと、ちゃんと人間の脳が必要なところは切りわける必要がありますね。
品質とスピードを両立させ、製品の魅力をソフトウェアで創り出す
——これまでお話ししていただいて、高橋さんから見て、これからのSDV大競争の時代にHondaの優位性あるいは強みはどこにあると思いますか。
Hondaさんというよりはクルマ業界全体だと思いますが、これからも魅力のあるものを作ってほしいと思います。私はソニーではゲーム機の「PlayStation」を作っていたんですけれども、日本にはハードもそうですけれども、ソフトも含めてやっぱり魅力のあるものを作る力があります。あとは、それをいかにスピード感を持って作っていくのかが課題ですよね。
スピードについては、既存のソフトウェア業界が取り組んできた手法の良いところはどんどんコピペすればいいわけで、あるいは、そこから人材をヘッドハンティングするという手もあるので、それでスピードと品質を両立できるようにすればよい。
もともと、日本のものづくりの品質は高いし、信頼性保証、品質担保の仕方も他の国に比べてしっかりしています。とりわけ、人が死なない、ケガをしないためのものづくりというのは、クルマにとってきわめて重要なキーファクターなので、そこはしっかり守りながら、新しい付加価値をクルマに加えていってほしいなと思います。
魅力的な機能を早く出せる仕組みづくりについては、それを作るのは私の役割だと、今期の初めにみんなの前で宣言しちゃったもので⋯⋯。
これはやるしかないですね(笑)
これまでも品質の再定義ということを巡っては、品質部門の人ともディスカッションしてきて、以前よりはだいぶ理解が得られるようになりました。
IT業界を含む他業界から学ぶという点についても、Hondaのソフトウェア拠点全体で取り組んでいます。いま、Honda Software Studio OmiyaではSCSKさんと一緒に同じフロアで開発に取り組んでいたり、Honda Software Studio Tokyo ShinagawaではDrivemodeさんと隣り合わせで仕事をしたり、Honda Innovation Lab, Tokyo（六本木オフィス）でもソニー・ホンダモビリティの共同開発が進んでいたりと、これまでは見られなかった他社との協業が展開されています。
これからもそういう新しい工夫を次々にやっていって、Hondaのソフトウェア開発の魅力を増やしていきたいなと思っています。
※掲載内容は、2025年7月時点のものです。
