―「次世代アーキテクチャ開発」とはどのようなプロジェクトですか？

A.K：正確には「ソフトウェアアーキテクチャ設計」で、次世代製品に向けた開発用ソフトウェアの構造を設計・開発するプロジェクトです。2018年に本格的にスタートしました。

A.T：当社は自動車部品サプライヤーですから、製品を動かすための膨大な制御ソフトウェアも社内でつくっています。その組み込みソフトをつくるためのソフトウェア構造づくりなのですが・・・。

―ソフト開発のためのソフト構造づくり・・・？

A.K：これまでは製品ごと、車種ごとに、それぞれバラバラに制御ソフトウェアを開発してきました。しかし、電動化をはじめとしたCASE（※1）やMaaS（※2）への対応を考慮すると、相互に連携する機会も増えていき、ソフトウェア開発は今後ますます複雑に、高度になるのは間違いありません。そこで複数の製品が共通で使える新しい開発プラットフォームをつくろうという取り組みが始まったのです。

A.T：それに加えてCASE市場のさらなる拡大が予想される中、これまで自動車づくりに関わってこなかった事業者も続々と参入しています。そうしたさまざまな新しいプレイヤーたちと協業していくためにも、プラットフォームの共通化というのは重要なテーマなんです。

※1 CASE：Connected(コネクティッド)、Autonomous(自動運転)、Shared(シェアリング＆サービス)、Electric(電動化)の略称

※2 MaaS(Mobility as a Service)：ICT を活用して交通をクラウド化し、公共交通か否か、またその運営主体にかかわらずマイカー以外のすべての交通手段によるモビリティ（移動）を1 つのサービスとしてとらえ、シームレスにつなぐ新たな「移動」の概念である。（引用：国土交通政策研究所　“MaaS （モビリティ・アズ・ア・サービス) について” ）

https://www.mlit.go.jp/pri/kikanshi/pdf/2018/69_1.pdf

―なるほど、共通の環境でつくっておけば、その後の環境変化に柔軟に対応できるというわけですね。

A.K：そういうことです。ハイブリッド（HV）ユニットの開発において、そういった開発基盤をいかに構築するかというのが、今回のプロジェクトです。

A.T：アーキテクチャはこの図のような構造になっていて（下記）、まずはプラットフォームという開発する際の土台があって、その上でさまざまなアプリケーションソフトを開発していく感じです。

―このアプリケーションというのが、自動車を制御する各ソフトウェアということですか。

T.C：はい。今私たちのチームが携わっているのはHV向けシステム開発用のアーキテクチャなので、アプリケーションの部分にはモーターやAT（※）を制御するソフトウェアが搭載されます。

※AT：オートマチックトランスミッションの略で自動変速機のこと。常に適切なギアを介するよう電子制御することで、低速域から高速域までパワプルかつ滑らかな走行を実現する。

 ―このプロジェクトの目標とは？

T.C：今までATの制御システムは単体で動いていましたが、効率的なエネルギー消費の観点から、HV化によりモーターとATの協調制御が必要になります。ここに対応する新しいアーキテクチャ構造をつくることですね。

A.K：近年、グローバル競争の激化により開発サイクルの短縮が求められ、従来型のアーキテクチャでは戦えなくなってきているんです。そのため、開発効率アップによる競争力向上もテーマになっています。

―どのような方法で効率化を？

A.T：新しいアプリケーションを開発する場合、従来型のアーキテクチャだとプラットフォームへの依存度が高くて、その属性に適したシステムしか適用できないなど開発に制約がありました。

A.K：新しい顧客と取引を始める時にプラットフォームの改修が必要になるケースも多く、そこに工数を取られてしまって、肝心なアプリケーションの開発に注力できなかったんですね。

―なるほど。プラットフォームに依存しない構造ってどうやってつくるんですか？

T.C：「疎結合化」です。

―疎結合？

T.C：依存度を低くするために、プラットフォームとアプリケーションをつなげる部分をゆるく、つまり「疎」にしていく必要があるんです。

A.T：例えば、今は別々のECUに搭載されているアプリケーションソフトウェアを、ひとつのECUにまとめようと思っても、いきなりガチャッとくっつけることはできません。疎結合化とともに個々のアプリケーションが持っている接続の口の形や通信の規格などを、事前に揃えておくということが必要になってきます。そういうことも考慮しつつ、全体の構造を設計する仕事ですね。

―要するに汎用性、拡張性に優れた構造を新たにつくるということですか？

A.K：そういう認識で大丈夫だと思います。

―みなさんはそれぞれ具体的にどのような業務を？

A.K：私たちが設計・開発したアーキテクチャは既に現場で使われているのですが、私はプラットフォームとアプリケーションの層でやり取りされるデータの標準化や、運用時の管理に注力していますね。

T.C：私はA.Kさんの下で同じ業務に取り組んでいます。

―既に稼動しているんですね。A.Tさんは？

A.T：アーキテクチャ構造を守るため、技術者のみなさんに開発時に守っていただくルールを策定しているのですが、私は「技術者のみなさん、ルールを守って開発できていますか？」ということを見に行くような役割を担っています。

―ルールを守らないと使用者のみなさんが怒られるということですか？

A.T：いえいえ、とんでもない。ルールを守っていないのがダメなのではなくて、守れないってことはアーキテクチャの構造が実業務に適していないのだと捉え、問題点をヒアリングしながら内容の改修を行います。

―なかなか現場を想像しにくい仕事ではありますが、どのようなご苦労が？

T.C：このアーキテクチャ上で開発する技術者が世界中にいるんですね。みなさんそれぞれいろいろな用途のアプリケーションを開発していて、考え方も違いますし、開発手法も違います。今回の新しいアーキテクチャ導入にあたり、技術者のみなさんに開発手法や手順などの変更をお願いしなきゃいけなかったのですが、そこの説得がなかなかうまくいかずに苦労しました。

―どうやって新しいアーキテクチャのメリットを伝えていくんですか？

T.C：疎結合化による開発上のメリットはもちろん伝えるのですが、それに加えて「この先自動車業界はこう変わりソフトウェア開発はこう変わる」と大きな視野で話をしたり、いろいろな側面から説得しながら、協力をお願いする形ですね。

―慣れたやり方を変えるのには誰だって抵抗ありますもんね。

T.C：そうなんですよ。だから先ほどお話ししたようなメリットをまとめた資料を作成して、現場に足を運びながら技術者の方々と打ち合わせを繰り返すということを地道に続けています。

A.T：アプリケーションの開発者は、やっぱり目の前にある仕事に全力を注ぐわけです。だから将来の話をされても、すぐにピンとくる人が少ないのは当たり前なんですよね。

―なるほど、そういうご苦労があるんですね。A.Kさんはいかがですか？

A.K：入社後、私たちも制御アプリケーションソフトウェアの開発を経験してきました。その時は要素技術に絞って、例えば通信だったら通信の専門家としてソフトウェアを開発してきたわけですね。でも今回はアーキテクチャということで、ソフトウェア全体を考えていかないといけない。狭い部分に限定されていた視野をグッと広げないといけない。そのあたりは苦労しましたね。

―確かに全然違う仕事ですよね。どのように知見を深めていったのですか？

A.K：上司の存在が大きいですね。ATなど実際の製品を見ながらどこの制御に使われるのか、全体最適とは何かを教えてくれたり、シミュレーション環境を構築することで実ECUがなくても開発ができるようにする方法について一緒に考えたり。

A.T：私は本で知識を得ることが多かったです。技術書だけじゃなくて、自動車やソフトウェアの未来を社会全体の動きから読み取るような本とか、面白いですよ。新型コロナウィルスの流行前は展示会に出かけたり、大学に行って講義を受けたりしていましたけど、最近は行けてないですね。

―入社前にこんな仕事があるなんて想像できました？

A.T：いえ、まったく（笑）。

T.C：私も（笑）。

A.K：入社したらパワートレインの制御ソフトウェアか何かをつくるんだろうな、くらいにしか思ってなかったです。

―アーキテクチャ設計のやりがいとは？

T.C：今後、自動運転社会の到来を見据えた時、自動車の安全性や乗り心地など「“移動”のクオリティ」を高めるためにアーキテクチャが結構重要な役割を担っているんです。スマートフォンでいえばOSのようなものなので、それを自分がやれているということにやりがいを感じますね。

―今後の目標があれば教えてください。

A.K：まずは今のプラットフォームの基盤をしっかり固めて、技術者のみなさんが開発しやすい環境を整えることが第一です。ただ、もう少し先の話をすると、2021年4月のアイシン精機とアイシン・エィ・ダブリュの経営統合によりプラットフォームの共通化が進むはずですので、そこにも視点を置いて進めていきたいです。

A.T：自動運転など今後のモビリティ社会を支えるソフトウェア開発のためにアーキテクチャ設計が担う部分はとても大きいですから、やらなくちゃいけないことはめちゃくちゃあります。

―自動運転社会向けのソフトウェア開発には、どのようなことが求められるのでしょうか？

A.T：自動運転車には、現在とはまったく違う制御が求められるようになります。そこに適応するために当社の製品はどう動かされなくちゃいけないのかを考えると、現行のシステムでの対応は困難であることはわかっています。ただ、それは誰にも知見がない新しい分野ですので、構造のあり方をゼロから考えていかないといけないでしょうね。

T.C：クルマを使う人が運転手から移動サービスを受ける側に変わるので、そのときにどうやって駆動部品を制御するか、どんなソフトウェアや開発環境が必要なのか、発想の転換が必要だと思います。

A.K：アイシンが提供する製品を動かすソフトウェアの基盤をつくるわけですから、その基盤がいまいちだと製品も魅力的なものにならないですよね。その役割を自覚して開発を進めていきたいです。