部門横断チームは、統合ECUの開発を複数部署、企業で分担して行うプロジェクトということでした。しかし統合ECUをどのような仕様にするのかは、そもそも「どんなモビリティを作りたいか」によって変わってくるように思います。

森：　そうなります。モビリティを外から操作したいなど、実現したいことが最初になければ統合ECUは作れません。これも統合ECUの開発の難しさです。

モビリティ全体の企画・開発プロセスに関わってくるわけですね。

森：　統合ECUの開発では、最初の段階から各ドメインでやりたいことを集約していく、横の仕切りの作り方がとても重要になります。デンソーはお客さまであるOEMと密接に連携し、仕様のご提案をさせていただきながら開発を進めています。

統合ECUを開発するためにはかなり多くの人員が必要になってくると思います。人数が多い場合、アジャイル開発をうまく回すことはできるのでしょうか？

松本：　一般的なアジャイル開発は10人以下で1つのチームにして、プロダクトオーナーが要件を決め、スクラムマスターが全体の進捗を取り仕切るという形が多いと思います。2・3週間単位でモノを作っては、フィードバックを基に仕様を再定義する、といったループを回すことになるでしょう。

ただ、今回の統合ECUはOEMも含めて大人数で開発しています。
そこで大規模なアジャイル開発を行うためのフレームワーク、「SAFe」（Scaled Agile Framework）が採用されています。SAFeでは短期間での成果を各チームが積み上げて、3ヶ月に1度は丸2日間にわたって全メンバーが参加して開発を行います。エンジニアのチームだけでなく、経営陣やマネジメント層も含め、企業が一丸となってアジャイル開発に取り組むための仕組みです。業務のフローだけでなく、アジャイル開発のマインドセットをメンバーに根付かせる点に特徴があります。

統合ECU開発には、従来型ECUのエンジニアも参加されているのですか？これまでのECUとは開発手法も大きく異なるのではないでしょうか？

松本：　世の中に存在するモビリティのアーキテクチャをいきなり替えるわけにはいきません。各ECUを担当していた部署は、これまで通りのECUも開発を継続します。

そこで従来ECUの担当エンジニアがソフトウェアをアレンジして、統合ECUを担当する部署に渡すということも行っています。
こうしたことを含め、複数の部署や組織が関わる大規模なアジャイル開発の課題を解決するのも、またソフトウェアです。
部門横断チームでは、株式会社デンソークリエイト製の「Next Design」を用いることで、開発の効率化を図っています。

Next Designというのは、どのようなツールなのでしょうか？

森：　統合ECUの開発では「ソフト部品のインターフェイス（つなぎ目）の仕様を複数組織間で取り決めたうえで、協業・並行開発を行う」という進め方をします。各組織がインターフェイス仕様を守って開発することで、統合時にそれらをつなぐことができます。

しかし市場の動向に追従するために、インターフェイス仕様に追加・変更が必要となる場合があります。OS側のサービスも仕様が固まっているのではなく、後に進化・発展していくのです。
サービスのインターフェイスは数千にも上りますが、これらはさらに追加されたり進化したりしている途中ですから、古い仕様のままアプリケーションを書いては正しく動作しなくなります。開発を進めるためには、OSやアプリケーションなどの担当者がお互いに歩調を合わせることが必要です。

日々進化するインターフェイスを管理し、インターフェイスに変更が発生したらエンジニアに知らせる。バージョンがずれていたら警告を出す。
そうした仕組みを、Next Designで実現しています。

インターフェイスの仕様を常に同期してくれるユーティリティということなのでしょうか？

森：　その用途にも使えますし、他にもさまざまなことができます。元々、Next Designはモデリングツールの一種です。モデリングというのは概念の図式化のことです。

モデリングというとUMLやsysMLといった記述言語を連想される方も多いと思いますが、Next Designには概念構造を自分で決め、記法も自分で決められるという特徴があります。例えば組織構造を描くために、「組織を□で、上位下位関係を↓で描く」ということを自分で決められるのです。これを使うことで、統合ECUにおけるさまざまなモデリングに柔軟に対応することができます。こうした対応を簡単にできるツールは、他には見当たりません。
また、Next Designはデータベースのように使えるというのも特徴です。これを用いることで、先述したような複数組織間の仕様の共有を実現しています。

Wordで仕様書を作成して共有するのに比べて、圧倒的に効率化できそうですね。

森：　効率化について言えば、Next Designは自動化機能を自分で追加することもできます。C#で記述したプラグインを、Next Designに組み込むことが可能です。
この自動化機能を利用することで統合ECUの開発でインターフェイスの変更が発生したときには、それに関わる調整作業を自動化するようにしています。

お話を聞いていると、従来のモビリティ組み込み開発とはだいぶイメージが違いますね。

松本：　もちろん、統合ECUも車載ECUではありますから、これまでデンソーが得意としてきた組み込み開発技術は従来同様に必須です。ただ、お客さまであるOEMが必要とするものは、製品だけではなくなってきています。製品によってどんな価値を生み出せるのか、また開発のためのツール。さらには開発プロセスまで考えなくてはいけません。既存の役割分担ではカバーしきれない部分がどうしても出てきます。
お客さまや市場の要求変化に柔軟に対応するために、組織横断の開発体制が採用されることが今後増えていくと思います。

エンジニアに求められるものも変わってきますね。

松本：　通常の開発ですと、設計、実装、評価と、役割分担して効率化するのが一般的です。
しかし今回の統合ECUは先行開発であるため、単なる効率化ではなく、人材育成も重視しました。1人1人が設計・実装・評価を一気通貫でできるよう、業務割り当てをしています。
こうしたやり方は他の先行開発分野においても重要ですし、全領域を俯瞰できるリーダーを育て、製品開発をしてもらいたいという想いもあります。
特に統合ECUのような製品では、全体のアーキテクチャを見通し、複数ドメインの調整ができる人材が欠かせません。

統合ECUの開発は、スマートフォンやパソコンなどに近づいている印象です。

松本：　ハードウェア面から見ると、統合ECUはArmマルチコアのCPU、NAND Flashメモリ、Ethernetポートと、これまでのECUに比べてリッチになっています。ソフトウェア面も、OS、ファイルシステムのほか、クラウド接続、アプリケーション追加／削除といった拡張性を持っていますから、確かに「画面のないスマートフォン」と言えますね。

ただモビリティといわゆるIT業界では、安全マージンやコストなどの点で考え方が大きく異なる点もあります。IT的な発想で言えば、CPUパワーやメモリは潤沢に使えるのが常識です。ところがモビリティでは、安心・安全が第一。ノイズや熱、消費電力、そしてコストの制約もありますから、高性能CPUをそのままECUに使えないなど、限られたリソースで開発をしなければならないという事情があります。

統合ECUを開発する、技術的なおもしろさはどのようなところにありますか？

松本：　安心・安全が重視される「クルマ」という製品には、制御方法や情報活用などの点で大きな制限がありますし、それはこれからも変わらないでしょう。しかし今や「クルマ」は「モビリティ」として再定義され、最新技術もこれからどんどん搭載されていきます。

人を乗せてリアルに移動できる。

この点において、スマートフォンやクラウドよりもスケールの大きなことができますから、そこにやりがいを感じます。

統合ECUの開発では、どんな人材を求めていますか？

松本：　広い意味で、ソフトウェアに精通したエンジニアです。統合ECUの開発にはこれまでの組み込み開発だけではなく、さまざまな知見が必要となります。
ネットワーク、クラウド、セキュリティから、OSやミドルウェアに通じたエンジニアなど幅広く募集しています。アプリ開発の得意な方々も開発に取り組める環境が整っています。

森：　先にお話ししたNext Designのような開発支援ソフトウェアや、ソフトウェア開発のためのSDK・開発環境を企画・整備できるエンジニアも求めています。
ソフトウェア開発の世界では、「Dev Environments as Code」というフレーズがよく聞かれるようになりました。これは、ソフトウェア技術を用いて開発環境自体の進化を加速させようというトレンドです。新技術を我々とともに次々と創造・吸収していける方々と一緒に仕事をしたいと考えております。