ソフトウェアに飲み込まれた車、SDV

[2024-08、月刊朝鮮］

ソフトウェアに飲み込まれた車、SDV

アメリカ・中国は先行、日本は学びながら追撃、韓国は？

文 : パク・ジョンギュ、KAIST技術経営専門大学院兼職教授 

 

⊙ SDV、走行・制動・操舵機能などをSWアップデートを通じて持続的に提供する車両 ⊙ トヨタ、2020年「ソフトウェアファースト」宣言...昨年10月に「デジタルソフトウェア開発センター」新設 ⊙ 中国、政府が先頭に立ってAPI標準化戦略...BYDとXpeng、テスラのようにSDV車両具現 ⊙ 日本、中国を模倣してモビリティデジタル転換(DX)戦略を推進 ⊙ 車両制御ソフトウェアの長さ、1000万行(2010年)→1億行(2020年)...自動運転機能車は3億～5億行水準 ⊙ 自動車会社がオペレーティングシステム、ソフトウェア、半導体設計に直接関与しなければならない時代 朴正圭(パク・ジョンギュ) 1968年生まれ。 漢陽大学機械工学科卒業、韓国科学技術院機械工学科修士、日本京都大学精密工学科博士、ミシガン大学訪問学者/起亜自動車中央技術研究所研究員、日本京都大学精密工学科助教授、LG電子生産技術院、現代自動車産業研究所・海外工場支援室勤務、漢陽大学未来自動車工学科兼任教授を歴任。現KAIST技術経営専門大学院兼任教授 / 翻訳書『半導体超進化論』『実践モジュラー設計』『モノづくり』。

 

 

 

2011年、〈ソフトウェアが世界を飲み込む理由(Why Software is eating the world)〉というコラムが話題になったことがある。＜ウォールストリート・ジャーナル＞に掲載されたこの記事は、「Netscape」というウェブブラウザを開発して一世を風靡したマーク・アンドリセン(Marc Andreessen)が書いた。彼は映画、農業、防衛分野でソフトウェア(SW)企業が既存企業を脅かしており、他の分野でも同様の現象が起こると予想した。十数年経った今、彼の予想通り、ソフトウェアは自動車を飲み込むような勢いで押し寄せている。

 

かつて自動車は伝統的な機械産業だった。自動車メーカーは馬のように牛のように走る車両、筋肉質な車両を作った。その後、電気・電子産業の発展により、機械部品にマイクロチップを搭載し、機械の微細な動きを制御するようになった。まるで、筋肉を調節する一種の自律神経系のように。産業的な面では、機械産業と電子産業との融合といえる。もちろん、この時にもソフトウェアはマイクロチップに組み込まれた形で存在していた。

 

しかし、今は車両に高性能コンピュータ(HPC-High Performance Computer)が搭載され、そこで実行されるソフトウェアによって車両が顧客に提供する機能が変わる。まるでスマートフォンのように、車両のソフトウェアが無線でアップデートされる時代に突入した。これを私たちはソフトウェア定義車両(Software Defined Vehicle)、SDVと呼んでいる。今、自動車産業は機械から電子へ、そして今、ソフトウェア(SW)への切り替えが行われている時点である。

 

自動車製品開発過程

 

2020年、トヨタ自動車の社長は「ソフトウェアファースト」という宣言をした。昨年10月には既存のソフトウェア関連組織を統廃合して「デジタルソフトウェア開発センター」を新設した。現代自動車もすべての車種をSDVに転換することを明らかにし、今年初めに研究所組織を大々的に改編した。今、自動車業界で話題になっているSDV、ソフトウェアファーストという用語の意味を確認し、今後の車両開発における課題を考えてみよう。

 

SDV(ソフトウェア定義自動車)を説明する前に、まず自動車製品の開発プロセスと特徴について見てみよう。新しい用語であればあるほど、自動車産業の基本に立ち返って把握することで、揺るぎない概念をつかむことができるからだ。

 

自動車メーカーは新しい車両を開発するために、まず顧客のニーズを把握し、製品のコンセプト(concept)を決める。

 

例えば、新しい小型車を開発するとしよう。商品企画部門が「コンパクトな都心型自動車」という車両のコンセプトを作り出す。そして、このコンセプトを満足させる車両の機能、例えば燃費、乗り心地などの目標値を決める。これを機能設計と呼ぶ。

 

目標とする燃費を満足させるためには、車両の重量を減らし、エンジン効率を改善する必要がある。そこで研究開発部門は、既存車両に比べて重量を50kg減らし、エンジンの圧縮比を5%上げる作業を行う。車両重量を減らすために車のサイズを小さくすることもできるし、同じサイズでも軽い素材を使うこともできる。また、車両のサイズを小さくする場合にも、可能な限り広い室内空間を確保するために、各種部品のサイズを小さくしたり、部品の配置を変更する作業を行う。

 

このように、エンジニアは製品が備えるべき機能(Functional Requirements)を満足させるために、具体的な構造物(部品)の設計パラメータ(Design Parameters)、つまり部品の寸法を決め、材質を決定する。この過程を設計という。設計とは、無形の欲求(機能)を満足させるための有形の具体的な情報を作ることであり、設計のアウトプットは図面である。昔は設計された情報を紙の上に描いていたが、今はコンピュータを使ってデジタル化して保存しているという点が異なるが、その本質は同じである。生産とは、このような設計情報を実物(実際のもの)に作り出すプロセスである。

 

設計変更の連鎖効果

自動車産業では、この設計プロセス(Design Process)が容易ではない。自動車は基本的にエネルギーを使用して人を乗せ、2tの重量物を高速で移動させるものである。エネルギーを使用するため、環境問題につながり、高速で移動するため人身事故が発生する可能性がある。自動車エンジニアは、環境と交通事故という二つの問題を宿命のように背負って生きている存在である。ドライバーの安全だけの車両なら、タンクのような車両を作ればいいが、燃費は当然悪い。軽くするために薄い鉄板で車体を作れば、事故が起きた時、車はまるで紙のようにしわくちゃになる。つまり、安全と燃費という機能が互いに衝突する。

 

多くのエンジニアがこのような相反する問題を抱えているが、自動車の場合、その程度が他製品に比べてひどく、特に燃費も良く、安全で、価格まで安くしなければならない場合、設計パラメータが互いに複雑に影響を及ぼし合う。一人の設計者が自分が担当した部品の寸法を変更すると、その部品と関連する他の部品の設計も変更しなければならない。

 

このような設計変更の連鎖効果は、ハイブリッド車(HEV)が電気自動車(BEV)よりも大きい。そのため、自動車を開発する際には、開発過程の途中でこれまで設計した情報をすべて確認した後、次の段階に進む方式を使用する。このような方式をウォーターフォール(Waterfall)方式と呼ぶ。まるで滝が一歩一歩進んでいくイメージから付けられた名前だ。

 

このように車両を開発するためには、研究開発担当者間の緊密な相互協力が求められる。スポーツ競技で言えば、チームワークを重視するサッカーの試合に似ている。筆者は現代自動車経営研究所(KARI)で勤務していた時、1年間(2014年11月～2015年10月)南陽研究所に派遣されたことがある。その時に観察したところ、車体設計部のチームワークが最も良かった。鉄板をつなぎ合わせて3次元の完成された車体構造を作るため、同僚との緊密な協力が不可欠だからだろう。

 

上記で、設計は顧客が要求する機能を具体化するプロセスと言ったが、正直、自動車の場合、満足すべき機能を明示的に設定することは容易ではない。そのため、一般的に機械的な面では、自動車の設計は機能設計よりも構造設計に重点を置く。さらに、構造が完成した後に、以前は考えもしなかった機能を発見することもある。

 

ECU・エンジン制御装置から電子制御装置へ

 

自動車に電子装置が導入され始めたのは、自動車の排気ガス規制が強化された1960年代からだ。特に、米国議会が1970年12月に大気汚染防止のための、いわゆるマスキー法(Muskie Act)を通過させ、本格化した。この法律は、一酸化炭素(CO)、炭化水素(HC)、窒素酸化物(NOx)を5、6年以内に10分の1に減らすことを要求した。

 

それで、自動車メーカーは、エンジンの点火時期などの値を制御できる電子装置を使い始めた。1978年、GMがエンジン制御装置(ECU-Engine Control Unit)という概念を導入した。ECUはまるで弁当箱のようなもので、その中に各種電子機器を相互につなげたプリント回路基板(PCB)が入っていた。その後、電子装置がエンジンだけでなく、ブレーキ、エアバッグなどを制御するのにも使われるようになり、ECUは電子制御装置(Electric Control Unit)の略称に変わった。電子装置が機械部品を制御する時代に突入したのだ。かつてソウル大学の入学試験で最高の合格ラインを誇っていた制御計測工学科が誕生したのが1978年だ。

 

ここで制御の特徴を見てみよう。制御(Control)とは、ある対象物を望む方式に動かすことをいう。そのため、満足させるべき機能（目標値）を明確に定義することが重要である。そして、適切な制御理論を論理回路で実現して目標値を達成する。このとき、電子装置の場合、目標値である機能とそれを実現できる構造（論理回路、電子回路）との対応関係が機械装置に比べ比較的に明瞭である。

 

高級車、100個以上のECUを搭載

 

[図1上段】は、機械部品の中に入った電子デバイスとその中に組み込まれたソフトウェアの様子を示したものである。図の中の四角は、エンジン、ブレーキ、エアバッグなど、自動車における大きな機械部品を意味する。機械部品はサイズが大きいが、制御される立場であり、電子部品はサイズは小さくても制御する立場である。

 

部品を納品する会社は、機械部品にマイクロチップのような電子部品を直接装着し、その内部には制御に必要なアルゴリズムをソフトウェアの形で内蔵させる。ここで、ソフトウェアは各部品に入る特定の半導体に合わせて製作されているため、修正が難しい。

 

電子製品が入ったにもかかわらず、自動車の設計は、[図1下段]のように、機械→電子→ソフトウェアの順で進められた。これは、機械が設計されなければ、電子デバイスの設計が進められず、電子設計（例えば、半導体の仕様決定）ができなければ、ソフトウェアを組むことが難しい構造であることを意味する。自動車の場合、機械部品の量が圧倒的に多く、設計難易度が高いため、多くの人員が配置されている。開発プロジェクトを管理する人も、主に機械工学専攻者である。

 

しかし、顧客のニーズがますます多様化し、エンジンだけでなく、ブレーキ、エアバッグなど電子装置で制御しなければならない部品が多くなった。高級車の場合、車両に100以上のECUが搭載されている。自動車に電子部品の使用量が増えるにつれて、次のような問題が新たに露呈し始めた。

 

認証試験不正、なぜ起こるか

 

まず、電子装置に入るソフトウェアの量が急速に増加した。ECUに使用されるソフトウェアを考えてみよう。例えば、ドライバーが加速をするためにアクセルを踏んだとしよう。すると、アクセルを踏んだ程度をセンサーで検出し、車速、エンジンに入る空気量を考慮して、燃費が良くなるようにガソリンをエンジンに噴射する。燃費、排出ガスなど、考慮すべき条件がますます多くなっている。

 

それで、車両を制御するために使用されるソフトウェアの長さも増え、2010年には約1000万行程度だったが、2020年には1億行になった。そして、自動運転機能が導入された車は3億～5億行レベルだという。

 

このようにソフトウェア量が増えると、エラーが発生しやすくなり、開発コストが増加する。自動車の電装部品が占める原価の割合は、1970年に5%、2000年に22%、2010年に25%に上昇した。そして、2030年には50%に増加すると予測されている(参照：2023年、ハーバード・ビジネス・ケーススタディ、Woven Planet-Designing Software for the Car of the Future)

 

第二に、車両開発期間が長くなった。もし機械設計に欠陥が見つかった場合、電子装置とソフトウェアを再開発しなければならないか、時間が不足して目標とする機能を完成させられない状態で車両を発売しなければならない。

 

今年1月、日本ダイハツの大規模な認証試験不正事件が発覚した。様々な不正事件の中で注目すべきことは、衝突試験時のエアバッグ作動を確認する認証試験での不正である。認証試験時にエアバッグを制御できるECUを完成させることができなかったため、タイマーを付けてエアバッグを作動させた。結局、ソフトウェア開発時間が不足したため、不正な方法で先に認証を受け、後できちんとしたECUを装着したのだ。現在のような開発方式では、決められた期間内に車両開発が難しいことを示す代表的な事例だ。

 

イーロン・マスク、無線でSWをアップデートして問題を解決

 

第三に、新しい機能の実現が難しい。例えば、車の前に突然障害物が現れた場合、以前は人が判断してブレーキを踏むと、電子化されたブレーキ装置が路面状況を把握し、最短距離で車を止めるように制御していた。電子化されても、あくまでブレーキを踏む最終的な意思決定者はドライバーだった。しかし、今はドライバーがブレーキを踏まなくても、車両が自らエンジン回転数を下げ、自動的にブレーキを作動させ、乗員の安全のためにシートベルトに装着されたプリテンショナー(Pre-tensioner)がドライバーをあらかじめしっかりと固定してくれる。

 

このように、各部品が相互に連携して実現する機能が増え、[図1]のように機械に単に電子装置が追加された方式で対応することは容易ではない。今や自動車は、高度な計算能力を持つコンピュータ(HPC)が要求される時代に突入した。

 

ソフトウェアで自動車の概念を変えた主人公は、イーロン・マスクのテスラである。私たちはよくテスラを電気自動車を作る会社だと言う。実際、テスラは2012年にモデルSを発売し、2017年にモデル3を販売し、電気自動車の大衆化時代を開いた。

 

しかし、テスラの車両はバッテリーがある電気自動車であると同時に、高度なコンピューティング能力を持ち、車両に使用されるソフトウェアをアップデートして新しい機能を追加することができる車両である。このような変化を物語る代表的な逸話がある。

 

アメリカに「コンシューマーレポート（Consumer Reports）」という自動車評価誌がある。2018年、この雑誌は、テスラのモデル3がフォードのピックアップトラックF-150より軽いが、制動距離は長いとし、モデル3の購入を推奨しなかった。

 

これを見たイーロン・マスクは、彼のツイート(現在はX)に、OTAで制動距離をもっと短くできるかもしれないと書いた。ここでOTAはOver the Airの略で、無線でソフトウェアをアップデートする技術を指す。実際に1週間でテスラ車両は、スマートフォンのようにソフトウェアアップデートを通じ、モデル3の制動距離を6m短くした(参考：時速97km/hから停止までの距離基準)。制動装置は自動車の主要機能の一つであるが、無線でソフトウェアをアップデートすることでこの問題を解決したのである。結局、《コンシューマーレポート》はモデル3を推薦に変更した。

 

走行・制動・操舵機能、アップデートすべし

 

 

小さなハプニングのように見えるが、この事件は既存の自動車メーカーを驚かせた。テスラ車両は、SDVという用語が使われる前から、すでにソフトウェアで車の機能をアップデートできるソフトウェア定義車両(SDV)を作り上げたのだ。

 

ここでSDVという用語を再確認してみよう。SDV(Software Defined Vehicle)とは、顧客に車両の新しい付加価値をソフトウェアアップデートを通じて継続的に提供できる車両を意味する。ただし、ここで注意しなければならないことがある。

 

まず、単にソフトウェアの量が多いからといってSDVと呼ばれるわけではない。前節で述べたように、高級車のソフトウェアの長さはすでに1億行水準である。ソフトウェアの量ではなく、顧客に新しいサービスを提供できなければSDVと呼ぶことはできない。

 

第二に、車両の基本機能である走行(Go)、制動(Stop)、操舵(Handling)機能などがアップデートされなければならない。ナビゲーション、インフォテインメント関連機能だけをアップデートする車両は、あえてSDVとは呼ばない。

 

[図2]は、SDV車両における機械-電子-ソフトウェアの連結関係(アーキテクチャ)を示したものである。従来の車両は、機械装置内に電子装置があり、その中にソフトウェアが組み込まれている。しかし、SDVでは車載用オペレーティングシステム（OS）がある。OSとは、応用SWとハードウェア(電子)の間で、応用SWの実行に必要なハードウェア資源を割り当てて管理する役割をする。

 

ここでOSは政府の機能と似ている。政府は土地、予算などの資源を国防、福祉などに割り当てる。同様にコンピュータでは、Windows、LinuxのようなOSがCPU(中央処理装置)、メモリなどの資源をワード、インターネットなどの応用SWに割り当てる。政府組織に国防省、外交省があるように、コンピュータのOSの中にはファイルシステム管理、メモリ管理などの機能別管理システムがある。

 

このようなOSの最も大きな役割は、HW(ハードウェア)とSW(ソフトウェア)を分離させることだ。こうなると、自動車もコンピュータのように、より簡単にソフトウェアを作成してインストールすることができるようになる。

 

HALとAPI

 

ここで、HAL(ハードウェア抽象化)とAPIという2つの用語を追加的に理解する必要がある。HAL(Hardware Abstraction Layer)を直訳すると、ハードウェア(電子HW)の抽象化を意味する。

 

抽象化という言葉は難しく感じられるが、私たちはこの概念を無意識のうちに使っている。例えば、パソコンでワード作業をした後、ハードディスクに保存することもできるし、外部記憶装置であるUSBに保存することもできる。実際のコンピュータ内部では2つのハードウェア(ハードディスクとUSB)にアクセスする方法が異なるが、OS(オペレーティングシステム)はユーザーがその違いを全く感じないようにしてくれる。これが抽象化(Abstraction)だ。このような抽象化が行われると、ソフトウェアエンジニアは簡単にプログラムを組むことができる。

 

API(Application Programming Interface)は一種の信号ルールである。車を運転しながら方向指示灯で移動する方向を知らせたり、ブレーキを踏んだときにブレーキランプが点灯して後続車に速度を落とすように信号を送る。このような種類の信号は、直接的なコミュニケーションが難しい主体間の情報伝達方法として有用である。

 

ソフトウェア、インターネットの世界でも同様だ。Naverが地図を提供しながら地図を使用できるルールをAPIの形で提供すれば、誰でもそれを見てスマートフォンでNaver地図を活用したアプリを作ることができる。このように、APIはソフトウェア生態系を活性化する上で重要な役割を果たす。最近、中国の電気自動車が急速に成長した理由の一つが、車両用APIの標準化政策のおかげだ。詳細は後述する。

 

日本、テンストレントに半導体の自動車設計技術者派遣

 

 

車載OSを使えば、100個以上のECUがまるでスパゲッティのように複雑に絡み合っている従来の方式を劇的に改善することができる。そのためには、複数のECUを統合できる高性能コンピュータ（HPC）が必要だ。これもテスラが突破口を開いた。車両に取り付けられたカメラセンサーで映像データを取得し、人工知能アルゴリズムを利用して自動運転を実現したいと考えたテスラは、2019年3月にFSDという名前のコンピューターを開発し、車両に搭載した。ここでFSDは完全自動運転(Full Self Driving)の略称である。実際には完全自動運転はできないが、とにかくテスラはFSDという名前をつけ、この用語で規制当局と様々な争いがあった。

 

FSDコンピュータには半導体チップの事故・故障に備えて2つのFSDチップが入っているが、チップ1個当たりのデータ処理速度は36TOPS(Tera Operations Per Second)である。1テラ(Tera)は1012(10の12乗)を意味する。つまり、36TOPSは1秒間に36兆の演算を行う半導体である。

 

この半導体チップを設計したのはジム・ケラーだ。彼は2016年に半導体設計専門会社であるテンストレント(Tenstorrent)というスタートアップ会社を設立し、2023年には現代車とサムスン電子、LG電子が投資をした。日本は今年下半期から30～40代の半導体設計技術者200人を選抜し、Tenstorrentに派遣するという。いよいよ自動車会社がオペレーティングシステムも、ソフトウェアも、半導体設計にも直接関与しなければならない時代に突入した。

 

ソフトウェア・ファースト

 

今、自動車業界ではSDVとともにソフトウェアファースト(Software First)という用語が流行している。

 

上記で、従来の自動車の開発方式は、機械部品→電子部品(ECU)→ソフトウェアという順番で行われていたが、この方式がますます問題になっているという話をした。特に、ハードウェアの開発期間に比べ、ソフトウェアの開発期間が長くなり、IT産業の発展速度が速いため、従来の自動車メーカーの開発体制では対応しきれなくなった。そこで、ソフトウェアファーストという概念が生まれた。

 

[図3】は、2023年11月、トヨタ自動車のSDV関連責任者である村田賢一さんがソフトウェアファーストについて説明した内容の一部である。彼は慶應義塾大学でコンピュータ工学の博士課程を修了し、1996年から2008年までソニーでソフトウェアアーキテクチャとOS関連の仕事をし、2008年からトヨタ自動車でソフトウェア関連の仕事をしてきた人だ。今では、自動車分野でコンピュータ工学を専攻し、電子会社で実務を経験したエンジニアをよく見かけるようになった。時代が変わったことを裏付けている。

 

彼の説明によると、従来の自動車産業では、［図3］の左側に示したように、①車両が必要とする機能要件を先に定義し、②定義された機能を実装するためのECUハードウェアを選択した後、③各ECUに入るソフトウェアを開発し、④ECU間の通信を行いながら機能を評価するという順序で車両を開発していた。車両を制御する量が限られた状況で、使用するECUの能力を最大限に活用することができる。ただし、この方法ではソフトウェア開発期間を十分に確保することが難しい。

 

そこで、［図3］の右側に示したように開発方式を変更した。まず、①車両が必要とする機能要件を定義した後、②機能要件を満足させるソフトウェアの全体構造（アーキテクチャ）を先に設計し、開発を行う。ただし、③ECUハードウェアがまだ存在しないため、ソフトウェアは仮想空間でシミュレーションを通じて開発していく。最後に④SWが入るECUハードウェアを選定して適用させる。これにより、ソフトウェア開発に必要な十分な時間を確保することができる。そして、将来、SWがアップデートされることを考慮し、コストがかかっても十分に余裕のあるECUを確保して使用する。

 

国別のSDV移行方式

 

ここまで説明したように、自動車がソフトウェアが定義された車両に変わると、どのようなメリットがあるかを簡単に整理してみよう。

 

まず、ソフトウェア機能開発に十分な時間を確保して製品競争力を確保することができる。

 

第二に、ハードウェアとソフトウェアが分離され、ソフトウェア開発が容易になり、ソフトウェアアップデートを容易にすることができ、顧客満足度を高めることができる。

 

第三に、ソフトウェアを通じて各ユーザーに合わせたサービスを提供することができ、自動車メーカーは車両販売後もソフトウェア販売で収益を確保することができる。今、自動車メーカーはこのようなSDVを実現するために総力戦を展開している。

 

中国、政府主導でAPIを標準化

自動車がSDVに移行する方法は国によって異なる。既存の自動車メーカーと新興の電気自動車メーカーも大きな違いを見せている。

 

米国の革新はやはりスーパーマン方式だ。イーロン・マスクという傑出した人物が出てきて、既存の自動車の問題点を見て根本から変えてしまう方式だ。中国は政府の様々な産業支援政策とともに、独自の技術中心の創業者が現れ、SDVへの転換を実現している。日本は競合他社を徹底的に調査し、自国企業と政府官僚が集まって議論をしながら一つずつ改善していく方式だ。

 

まず中国について見てみよう。一般的に中国の電気自動車産業の発展は、中国政府の一方的な補助金のおかげだと言われている。6月21日のブルームバーグの記事によると、中国政府は2009年から昨年まで15年間、2310億ドル(約300兆ウォン)を支援した。

 

このような補助金以外にも、産業振興のための精巧な政策もあった。まず、中国には「市場と技術の交換」という政策があり、中国語で「以市場換技術」と呼ばれている。これは1979年から構想され、1982年から政策として定着した。そして1984年から中国の技術発展を加速させる重要な方針として確定した。この政策の内容は、一言で言えば、外国企業に中国の市場を譲り、利益を渡す代わりに、その企業を通じて技術を確保し、産業を振興させる方式である。

 

偶然かもしれないが、テスラは2019年に上海に工場を建設し、2020年から販売を開始した。その後、中国の電気自動車が本格的に成長し始めた。例えば、中国の電気自動車メーカーBYDは、2020年にハン(漢)という電気自動車を作り、独自の自動車開発方式を確立したと言われている。

 

それだけではない。中国政府は車両用ソフトウェアの生態系を活性化する役割を果たした。中国自動車協会(CAAM)は、テスラ車が電気自動車であると同時にソフトウェア定義車両(SDV)であることに着目し、API標準化政策を推進した。2020年12月に中国自動車協会はSDV研究グループを決定し、2021年4月から自動車メーカーと関連企業が参加し、SDVに必要なAPIの定義と標準化を開始した。そして、2021年10月から、2022年11月まで4回にわたってAPI標準案を発表した。こうして作られた標準案が実際の車両に適用されている。中国の電気自動車メーカーであるBYD、Xpengなどは、すでにテスラのようにSDV車両を実現している。

 

中国に学ぶ日本

 

日本企業は一歩一歩進んでいる感じだ。筆者は7月2日、東京で開催されたSDVサミット2024に参加した。約300人が集まり、政府の政策や企業戦略などを聞く場だった。セミナーに参加した人はかなりの危機感を持ちながら、専門家の発表を真剣に聞いていた。

 

日本経済産業省モビリティDX室の責任者が最初のスピーカーとして登場し、日本政府のモビリティデジタル変換(DX)戦略を説明した。この内容の中で興味深いのは、バッテリー、カメラセンサー、充電装置などと自動車間の情報伝達方式であるAPIを標準化、共通化させるという政策だった。日本政府が中国の自動車産業政策を真似たものだ。

 

二人目の演者として出た名古屋大学のモビリティ社会研究所所長で、SDVの専門家である高田教授は、中国自動車協会が公開した標準化されたAPIを分析した結果、今後、検討や改善の余地が多いと発表した。そして、企業からの寄付金で「オープンSDVイニシアチブ」という機構を発足し、日本の自動車メーカーの長所を生かせるように車両用API標準仕様を作り、来年3月に標準仕様を公開すると発表した。

 

日本企業は、中国や米国の新興企業と比べると、確かに遅れている。しかし、何を学び、何を追随するかを的確に決めているようだ。日本メーカーのSDVは今後2年以内にその実体が見えてきそうだ。ホンダとソニーの合弁会社が作った車両が2026年に発売される予定であり、トヨタもアリーン(Arene)という車載用OSを2026年に公開する予定である。

 

製造業というのは何かを作り出すものなので、常に目に見える形状、手で触れることができるものが存在する。しかし、ソフトウェアは目に見えないものであるため、過去の韓国の製造業が歩んできた道とは多少異なる側面がある。目に見えないものであるため、組織構成員間で共通の対象をめぐって議論することが難しい。ソフトウェアは高度な知的作業で成果物を生み出すが、触れることができないものであるため、蔑ろにされてきた。

 

これは、既存の自動車会社がSDVという新しい概念の自動車を作るのに苦労している理由の一つである。そのため、ほとんどすべての既存の自動車メーカーは右往左往の状態にある。このような時ほど、機械、電子、ソフトウェア工学の違いや働き方を互いに理解する必要がある。お互いの理解があれば、機械、電子、ソフトウェアが融合した形の車両を作り出すことができるからだ。

 

しかし、今の韓国の製造業は過去とは異なり、グローバル化・専門化されている。構成員のほとんどがそれぞれ狭い専門的な領域で仕事をしながら業務効率を向上させる中で成長してきた。しかし、機械、電子、ソフトウェアが融合しなければならない時点では、むしろ領域を超えた人材が必要だ。

 

自動車のSDV化をいち早く成功させた会社は、ほとんどが規模が小さい会社だ。規模が小さければ、働く業務領域が広くなる。テスラのイーロン・マスクを見ろ。ITの専門家なのか、宇宙船打ち上げの専門家なのか分からないほど、彼の活動領域は広い。このような時ほど、業務領域が広いエンジニアを発掘し、育てていく必要がある。

 

韓国の自動車政策は？

 

ソフトウェアファーストとかSDVとかいう用語は、結局、顧客に良い価値の車両を提供するための目的を満足させるための一種の手段に過ぎない。一般的に人気のある新しい用語が出ると、目的と手段を混同しがちだ。そのため、ソフトウェアで実現した結果物を構成員と共有しながら、実現した価値が認められるようにしなければならない。

 

目標は大きくても、手段は具体的でなければならない。中国政府は中国の自動車産業の現実を直視し、電気自動車を集中的に支援した。そして、自動車用ソフトウェアの生態系を作るためにAPIの標準化を行った。日本もこれが必要だと判断して追随している。自動車産業を展開する韓国政府の政策も、隣国の自動車産業政策のように、ソフトウェア生態系を活性化させる具体的な方策を模索しなければならない時期だ。