車の内部状態を“見える化”する診断機能。それを支えるのが、ECUに組込まれたダイアグツールです。まずは、今回の開発に深く関わるECUの仕組みについて、基礎からお話を伺いました。

ーECUとはどんなものですか？

車載向けの制御用コンピュータのことです。エンジン制御、モーター制御、ADAS分野と呼ばれる自動運転サポートなど、1台の車には機能ごとにいくつものECUが搭載されています。例えばADASでは対向車や先行車の認識などを行い、ドライバーの安全な運転をサポートしています。

ーダイアグツールについて教えてください。

ダイアグツールは、ECU内に組込まれたBSW（Basic Soft Ware）の一種で、診断機能を担うソフトウェアです。エンジンの回転数や燃料の残量、車速など、さまざまな車両情報を収集し、それらの読み出しや出力をする機能を持っています。

例えば車にトラブルが発生していないかをチェックする際、ダイアグツール上でデータを確認することで、異常の早期発見や原因究明に役立ちます。この機能は、車検時や故障診断時にディーラーなどでも一部活用されている重要な仕組みです。

ー今回のダイアグツールは、どんな目的で開発されたのですか？

先ほどお話ししたようにダイアグツールには車両情報を集める機能があるのですが、その情報は100件以上、多いものだと数百件にのぼることもあります。これらすべてを手作業で設計・実装するとなれば、非常に手間がかかります。そこで、作業の負担を軽減するために、一部を自動化できるツールとして今回のダイアグツールを開発しました。現場の負担を軽くし、生産性を高める狙いです。

ー従来のダイアグツールと比べて、今回のツールはどのような違いがありますか？

従来のツールでは、手作業で設定情報を打ち込み、それをもとにソースコードを出力する流れが一般的です。一方で、今回開発したダイアグツールは設計書を直接インプットとして使うことで、自動的にコードを生成できるようになりました。その結果、手作業の工程を大幅に削減できています。

車載ECUの多様化と同時開発が当たり前となった昨今、開発現場には、これまで以上に効率化が求められています。しかし、ECUの性能に直接影響しないにもかかわらず、ダイアグツールの設計や実装には、多くの工数がかかっていました。その“見えにくい負担”が、効率化を求める開発現場で大きな課題となっていったのです。

ーダイアグツールの自動化に取り組むことになったきっかけを教えてください。

開発がスタートしたのは、今から2年ほど前のことです。別のプロジェクトで、ダイアグに関する作業量の多さから「この作業を自動化できないか」という声が上がったことが、今回の取り組みの発端でした。

そのプロジェクトでは、まず自分たちの手で一通りソースコードを作ってから、仕様に合わせて書き直していくという進め方をしていたこともあり、ダイアグの作業が大きな負担となっていたんです。

そこでECU開発における工数をあらためて分析したところ、やはりダイアグ機能の設計や実装に最も時間がかかっていることが明らかになりました。「ここをうまく効率化できれば、開発全体がスムーズになる」そうした確信をもとに、ダイアグ自動化の動きが本格的にスタートしました。

ー葛綿さんが本プロジェクトに関わることになった経緯を教えてください。

もともと同じ分野に関わっていたこともあって、たまたま手が空いていたタイミングで部長から「ダイアグツールの自動化をやってみないか」と声がかかったんです。その時は正直なところ「えっ、私がやるの？どうやって立ち上げればいいんだろう」と戸惑ったのを覚えています。別のプロジェクトで少し似たようなことをやった経験はありましたが、最初は情報を集めながら手探りで進める状況でした。

とはいえ、最初の時点で「どこに工数がかかっているのか」という分析は既にできていたので、「じゃあ、注力すべきはここだね」と早々にプロジェクトの方向性を定めることができました。初期段階で目的が明確になり、迷わず進められたのは大きかったですね。

開発現場で長年の課題だった手作業の負担を大幅に軽減するため、今回のダイアグツールは「ソースコードの生成」、さらには「テスト仕様の出力」という2つの自動化を実現しました。これにより、作業効率の向上や、開発スピード・品質の改善が期待できます。

ー今回開発したダイアグツールでは、どの様な作業が自動化できるのですか？

まず実装部分では、ソースコードの自動生成です。設計書をインプットにして、ダイアグ用のソースコードを出力します。設計書にはダイアグに必要なデータの種類やサイズ、範囲といった情報が記載されており、それらをもとにテーブル形式のソースコードを出力する仕組みです。

もう1つが、結合テストの仕様書の自動出力です。例えば「どんな要求を出して、どんな応答が返ってくるべきか」といった期待値をもとに、自動でテスト仕様を作成することができます。

ーそのテスト仕様を使って、実際のテストも自動で動かせるようになるのでしょうか。

はい、そうなんです。今年度の開発では、テスト仕様をもとに、実際にテストを自動で実行できるスクリプトの出力にも取り組んでいます。具体的には、車載向けの通信規格であるCAN通信を用いたテストにおいて、ダイアグへの要求と応答をやりとりするスクリプトを自動生成できる仕組みです。
このスクリプトは、車載開発の現場で広く使われている通信デバッグツール上で動きます。こうした既存のテスト機材と連携することで、結合テストも自動化しやすくなり、現場の負担を大きく減らせると考えています。

ーツールを開発する上で1番工夫した点はどこですか？

汎用性を高めることです。というのも、ダイアグツールにインプットする設計書のフォーマットは、車両やメーカーによってかなり違うんです。そのためフォーマットが違ってもある程度インプットできるよう、情報がどこにあるのかを指定するなどの工夫をしました。このあたりの汎用性をどう実現するかが一番の課題であり、時間をかけた部分ですね。

ー今後、このツールはどのような形で進化や発展していく予定でしょうか。

開発自体は今年度いっぱいで一旦区切りをつける予定です。このツールの特徴は、ソースコードの自動出力だけではなく、テスト支援までできる点にあります。そこが他のツールとの大きな違いであり、いろいろなプロジェクトで使ってもらえると期待しています。そして使う中で出てきた要望をフィードバックとして、さらに改善をしていきたいと考えています。

葛綿さんらがダイアグツールの開発を進める中で立ちはだかったのは、「データ取得処理の煩雑さ」と「リソース不足・外部連携」という2つの壁でした。実際の現場では、何がボトルネックになっていたのか。プロジェクトの裏側を追いました。

1つ目の課題「データ取得処理の煩雑さ」

ー1つ目の課題を教えてください。

一番の課題は、取り扱うデータの量が非常に多いことでした。車両1台あたりに10〜100以上のDataIDというデータ項目があり、例えば燃料残量や車速、エンジン負荷など、多岐にわたる情報を扱います。1つずつ丁寧に処理できれば問題はないのですが、なにしろ数が多いだけに、手作業ではミスが起きやすく、工数も何日もかかってしまうところが大きな負担でした。

ー車種やメーカーごとに違いがあることも影響しましたか？

そうなんです。同じメーカーでも車両が変わると仕様が大きく変わることが多く、kmとmile、Lとgalといった単位の違い、データIDの形式も異なります。そのため既存のソースコードを流用することが難しく、毎回ほぼ作り直しのような状態になってまうんです。

ーその結果、どんな影響が出たのでしょうか？

大量のデータを毎回個別に処理しなければならず、作業が煩雑で時間もかかるため、車載ソフト開発の中でも特に工数がかかる領域になっています。これが開発全体の効率化を妨げる大きな要因となっているんです。

2つ目の課題「開発リソースの不足と外部連携ニーズ」

ー2つ目の課題を教えてください。

2年前に今回のプロジェクトが始まった頃、車載開発の需要がこれから増えることは各メーカーや部品メーカーでも予想されていました。私たちもビジネスチャンスと捉え規模拡大を目指していましたが、国内での人材確保が難しく、多品種同時開発に追われる中でリソース不足が大きな課題でした。そこで海外のリソースを活用しようと考えたんです。

ー海外のリソース活用は今回が初めてだったのですか？

いいえ、実は7年ほど前からベトナムのFPTソフトウェアジャパン社と協力体制を築いていました。

しかしコロナ禍になり、一度大幅に縮小せざるを得ませんでした。ですが今後の車載開発需要の拡大を見据えて、コロナ明けから再びベトナムの人材を活用し、リソースを確保する体制を整える動きが出てきました。ベトナムの技術者を日本へ招いてサポート体制を作っている部署もありますし、複数の部署で連携が進んでいます。こうした取り組みはお互いにとって良い刺激になっていますね。

ー海外リソースとの連携ではどんなご苦労がありましたか？

一番苦労したのは、やはりコミュニケーションの部分です。文化の違いや時差もありますし、ベトナムのメンバー全員が日本語を喋れるわけではありません。通訳を介してのやりとりになるため、誤解なく意思を伝えるのにかなり労力がかかりました。

明確な答えがない中で、とにかく打ち合わせの回数を増やそうと考え、週に2～3回の定例ミーティングでコミュニケーションの機会を増やすことで対応しました。今は現地に日本人のブリッジSEが駐在しているので、その方を通じて情報のやりとりをしています。

ー具体的に、どんなところでコミュニケーションの負荷を感じましたか？

こちらの言いたいことがきちんと伝わらないことですね。特に専門的な内容や技術的な話になると、通訳の方が理解しきれず、正確に伝えられないことがあります。日本語がわかるベトナムの技術職の方も一部にはいますが、そうした人はまだ少数派です。でもベトナムは親日国ですし、考え方自体は日本人に近いように感じます。

ー海外リソースの活用を検討している部署へのアドバイスをお願いします。

今回の取り組みで感じたのは、何よりも気を付けないといけないのはコミュニケーションだということです。言葉のニュアンスや文化の違いで、ちょっとしたすれ違いも起きやすいので、こまめに確認しながら進めるのが大事だと思います。また、打ち合わせの時間や依頼のタイミングは時差を考慮して調整することも必要です。

実際の作業においては、仕事を進めながら彼らの得意なところや実力を見ていきました。その上で、それぞれの特徴や状況に合わせて、うまく指示を出したりサポートしたりすることが必要だと感じました。

これまで属人化しやすかった開発業務を、標準化・効率化へと導く今回のダイアグツール。他の部署などでの開発プロジェクトでも活用でき、全社的な開発負荷の分散にもつながると、葛綿さんは話してくれました。

ーこのツールを、今後どのような部署やプロジェクトに展開していきたいですか？

車載開発の中で、BSW部分を担当している部署であれば、十分に役立てられると思います。このツールは、車載開発の現場において大いに力を発揮できるものだと感じています。

ーどんなきっかけがあれば、他部署での活用が進むと思いますか？

まずは、とにかく実際に使ってもらうことが大事だと思います。BSWのダイアグをしっかりやることが前提になりますね。

それから、さっきもお話ししたようにデータの量が多くて困っている開発現場があれば、すぐに「これを使ってみてほしい」という話ができるのかなと思っています。

具体的には、私が所属している部署や、似たプロジェクトを進めている部署など、似たようなプロジェクトを進めている部署にはすでに「こういうツールを作ったので評価してみてほしい」と声をかけています。まだ完全には浸透していませんが、入り口はできてきているので、あとは実際に使ってもらいながら広げていければと考えています。

ーどんなフィードバックをもらえたら、さらに良いツールになっていくとお考えですか？

そうですね。まず、今回アプリケーションの画面を作ってツールを開発していますので、まずはUIの部分、使い勝手の部分のフィードバックが欲しいです。

あとは、ツールを使って出力した内容ですね。ここをこう直せばもっと使いやすくなるとか、こういう情報を追加してほしいとか、具体的な要望をもらえれば、より汎用性が高まっていろんな部署や現場でも活用しやすくなると考えています。

ー最後に、社内メンバーへのメッセージをお願いします。

今回開発したツールをどんどん使っていただいて、悪いところ、改善すべきところについて積極的にフィードバックをいただけたらと思っています。

いただいたフィードバックをもとに、より良いツールを作り上げていきたいですし、最終的には工数削減が目的ですので、使う方にその効果を実感してもらえるツールにしていきたいと考えています。

だから、使えそうだと思ったら迷わず使ってみてほしいです。まずは体感してもらうことが一番大切だと思っています。


※記事内における内容、組織名などは2025年6月公開時のものです。
※本文中の会社名および製品名は各社が商標または登録商標として使用している場合があります。