クオリティフォーラムアーカイブ

クオリティフォーラム2025 登壇者インタビュー

製造業の競争力を支えるソフトウェア品質

ベストプラクティスに学ぶ
ソフトウェア品質向上への道筋

アルプスアルパイン株式会社
いわき開発センター（福島県いわき市）
SI部部長の 清水 聡博 氏と
DCS先行開発部の 佐藤 裕典 氏に聞く

聞き手：藤元 正（ジャーナリスト）
清水聡博氏 佐藤裕典氏
佐藤 裕典 氏
アルプスアルパイン株式会社
DCS先行開発部
2012年 アルパイン株式会社 (現・アルプスアルパイン株式会社) 入社。
以来、車載ソフトウェア開発に従事。欧州OEM向けインフォテインメント機器開発においては、ログ出力・解析、共通基盤開発に従事。国内OEM向けインフォテインメント機器向けのソフトウェア開発にも従事し、併せてOSS貢献や、社内標準プロセス策定に取り組む。現在は、アルプスアルパインの掲げる次世代の車室内コンセプト、デジタルキャビンの実現に向け取り組み中。

1. 世界初のカーナビをホンダと共同開発

――まず会社の紹介からお願いします。2019年にアルプス電気とアルパインが経営統合してアルプスアルパインになったわけですが、1948年設立のアルプス電気（当初は片岡電気株式会社）はかつて、バリコン（可変コンデンサ）やTV /FMのチューナー、磁気ヘッド、熱転写プリンターなどで知られた電子部品の大手メーカー。一方のアルパインはカーオーディオやカーナビゲーションシステムといった車載機器で有名ですよね。
清水：電子部品の方は、例えばフロッピーディスクや磁気ヘッドなどで一時期かなりの世界シェアを持っていました。その後は家電だけではなく、ゲーム機やデジタル通信機器などにも市場が広がってきています。また我々が所属していたアルパインは1967年に設立された旧アルプス・モトローラが源流で、1976年に「ALPINE」ブランドを立ち上げました。その２年後にアルパインに社名変更し、OEM（完成車メーカー）向けの車載器の開発だけでなく、アルパインブランドのカーナビ・カーステレオ中心に開発を続けてきています。2019年の経営統合以降は、電子部品と、さらにそれを組み上げた製品という2軸で戦えるメーカーの強みを生かし、「コンポーネント」「センサー・コミュニケーション」「モビリティ」の３分野を中核に事業展開を進めています。実はこのいわき事業所は、元々アルパインの車載関連の事業所が立地していまして、今では旧アルプス電気の車載関連事業も併せた形でモビリティ向けの中心的な開発センターとなっています。
――カーナビといえば、1981年に生み出された世界初のカーナビをホンダと共同開発したのが、アルプス電気とアルパインだったそうですね。
清水：その通りです。非常に名誉なことで、このいわき事業所が中心に手がけた案件になります。
――そのカーナビの技術が進化して、最近ではどのような変遷を遂げているのでしょうか。
清水：実はカーナビの世界ではスマートフォンのナビゲーション機能の向上が著しく、どちらかというとスマホと連携しながらその機能を車載器側に表示するという方向に変わりつつあります。最近ではディスプレイオーディオ（DA）という形で、ナビゲーションの機能を持たず、その他の機能を搭載したユニットが増えてきていますね。また、一部のOEMメーカーではECU（電子制御ユニット）の統合を進め、いくつかの機能を一つのユニットの中に組み込んでいくことで、全体的に車両あたりのユニット数を減らして開発費を抑えたり、全体の重量を減らしたりといった方向に進んでいます。

2. カスタムカー事業にも参入

清水 聡博 氏
――特徴的な事業としてもう一つ、カスタムカーの販売も手がけているとのことですね。
清水：2017年よりお客様のニーズに合わせたカスタマイズカーを販売する「アルパインスタイル」を展開しています。また、2023年からは市販の複数のベース車両をもとに、北米西海岸で生まれたカスタムデザインを外観に取り入れた「Cal's Motor」をラインナップに追加、現在10車種を取り揃えています。見た目はいずれもヴィンテージ風なのですが、例えばボンネットにはカスタマイズで一般的に使われているFRP造形ではなく、精度や強度の高い型成形のスチールを採用するなど最新のカスタム手法を取り入れました。さらに大画面ナビゲーションや大画面ディスプレイ、天井吊り下げ型モニター、高音質の専用オーディオシステムなど、得意とするカーエレクトロニクスとカーエンターテインメントの技術やノウハウをふんだんに盛り込んでいます。またアルパインスタイルの店舗も、いわき、埼玉、東京、千葉、横浜、名古屋、大阪、広島、福岡、沖縄に加え、2025年8月には仙台、10月には広島にそれぞれ店舗がオープンし、全11店舗にまで広がっています。

3. 未来の移動空間「デジタルキャビン」への挑戦

佐藤 裕典 氏
――それでは、本題のソフトウェア開発の取り組みに話題を移したいと思います。今回のクオリティフォーラムではどんな内容の発表を予定されていますか。
佐藤：発表では車載ユニットに組み込まれたソフトウェアの品質向上に向けた話になります。
清水：日科技連さんからいただいた全体的なテーマがソフトウェアの品質をどう上げていくかというものでしたので、製品内のソフトウェア品質の向上を目的に当社が開発した「デバッグコンセプト」という独自手法を中心に紹介する予定です。
――ちなみに佐藤さんの所属する部署はDCS先行開発部となっていますが、DCSとは何のことですか。
佐藤：「デジタルキャビンソリューション」の略になります。対外的には2020年のCEATEC（シーテック）で発表しました。実はその時のCEATECでは「Emotion in Mobility 『移動』を、『感動』へ。」がモビリティ事業での発表テーマだったのですが、そのテーマを実現するためのコンセプトとして「デジタルキャビン」という形でのデモを展開したのが最初です。
清水：デジタルキャビンというのは、現在の車載システムの先を目指したコンセプトで、さまざまなセンサーなどと連携させながら、車に搭乗したエンドユーザーに対して例えば没入感を高めるとか居心地を良くするとか、価値ある空間を届けるための新しい取り組みになります。今までは単体の車載ユニットによって車内環境を作り上げようとしてきたわけですが、今後はいろんなユニットやセンサーが連携して、サウンドに加え、シートや振動、ライトなども使いながら効果を出し、視覚・聴覚・触覚、あるいは嗅覚に関わる技術を総動員した形で、搭乗者に新たな移動空間を提供するという方向に業界全体が変わろうとしています。
――このデジタルキャビンという言葉は自動車業界では一般化してきているのですか。
佐藤：いえ、一般化まではしていないと思います。そもそも我々が作った用語ですので。少し先の未来の移動空間のイメージについては競合他社も似たコンセプトを打ち出していますが、デジタルキャビンとは違った言い回しになっています。

4. ソフトウェア開発を効率化する「デバッグコンセプト」

――話をデバッグコンセプトに戻します。そうなると、現在の車載関連のソフトウェア開発では主にどういった課題や困りごとに直面しているのでしょうか。
佐藤：例えば車の中を見てみると、組み込まれているDAのユニットは表面上、単独で動いているように見えます。ですが、実際の車の中では多数のさまざまなECUのユニットが連携して動作しているわけです。各ECUのハードウェアで各ソフトウェアが動作して機能しているわけですけども、軽量化やコスト削減のためECUではハードウェアの統合が進んできています。一方で必要とされる機能はどんどん増え、ECUの個数が減るのとは対照的にソフトウェアは巨大化、複雑化の一途を辿っています。わかりやすい例で言うと、今までは一つのユニットの中に一つのOSしか動いていなかったのが、Linux OSもAndroid OSもリアルタイムOSも同時に動かさなくてはならない時代になってきています。
――なぜマルチOSのような形で動作させる必要があるのですか？
佐藤：元々は複数のECUが別個に動いていたわけですが、ECUの統合が進む中で、個々の機能を独立して動作させたいというニーズが強くなっているためです。つまりECUのハードウェアを切り分けながら機能ごとに適切なOSを選択し、そのOS上で必要な機能を動作させるというイメージですね。全体的に見てソフト開発のボリュームはどんどん上がってきていますから、それに付随して不具合の数も増え、当然ながら不具合の解析にかかる時間も増えてきています。その不具合の解析に役立つのが「ログ」と言われるものです。わかりやすく言うと、スマホのアプリでエラーメッセージが表示される場合があると思いますが、あのメッセージが不具合の要因解析に役立つ情報になるということです。そのログの出し方について、以前は開発者が各自自由なやり方でやっていたのですが、このままだと開発の効率化が進まないことから、我々の方で不具合解析の効率化手法を検討した結果、今回発表するデバッグコンセプトにたどり着くことができました。
――ソフトウェア開発の検証やデバッグにかかる期間は、全体の開発期間のどれくらいを占めているのですか。
佐藤：実際には開発期間の大半がデバッグや検証で占められている状況です。
清水：例えば新機種のカーナビを開発するのに以前は3年くらいかかっていましたが、今では2年とか1年半で開発しないと市場で勝負になりません。しかも全体の設計をしてから全体のソフトを作っていく、というやり方ではなく、大体要件がまとまってきたものから作り始め、後から機能がどんどん増えていく形をとります。そのため、でき上がったものから評価していくことになるのですが、それに従って不具合も増えていく。つまり、機能を作り上げながら同時並行的に不具合を直していく作業が途中から延々と続き、開発期間の大半の部分を不具合解析に費やすことになります。

5. ログトレースで不具合解析を短縮

――不具合の解析にはログが重要な役目を果たすとのことですが、そのログは開発の担当者が書き込むのでしょうか。
清水：自分たちでコードに追加して書いていくことになりますね。
佐藤：不具合解析に時間がかかる要因として一つ挙げられるのが、不具合が発生したときに取得したログのみでは、解析できないケースの不具合の再現試験です。ログに解析に必要な情報が足りない。ではどうするかというと、同じソフトウェアのバージョンを使い、もう1回同じ環境を作り出してテストを行い、再度ログを取得します。それでも情報が足りない場合は、このプロセスを何度も繰り返すことになります。つまり、解析にかなりの時間がかかってしまう。それに対して、我々のデバッグコンセプトを適用すると、その再現試験の数を減らすことができますので、不具合の解析期間の短縮につながります。
清水：まずは設計段階でログの洗い出しが行われ、ここは絶対ログが必要だろうという部分にはログが埋め込まれるわけですが、それでもログが抜けた箇所がどうしても出てきてしまう。そこでソフトウェアの不具合を修正するときに関連するログが一緒に追加され、次の再現時には必ずそのログがフィードバックされて検出されるというサイクルが回り、ログの網羅率がどんどん改善されていくことになります。

6. 不具合発生を可視化

――こうしたログトレースによるデバッグ手法について、やはり最大の導入効果は開発期間の短縮でしょうか。
佐藤：そうですね。可視化による効果も大きいです。通常、ログは自然言語で書いてある訳ではなく、記号化された数字でコードに書き込んであり、可視化する際にはシステム側で人間に分かりやすく自然言語に変換して提示します。それ以外にも、単に時系列で温度とか電圧の値が時系列でどう推移しているのかをログに出したりするのですが、実際に人間がそれをテキストベースで読もうとしても分かりにくい。そこでデータをグラフ化して可視化するシステムも我々で開発しています。こんなイメージになります。
佐藤：これは「Alpine Trace Log Analysis Suite」を略して「ATLAS（アトラス）」と名付けられた内製のソフトウェアツールで、2015年から活用しています。時間軸に対して値がどう変化したのかが文字上だとわかりにくいのに対し、グラフだとぱっと見て、どこかで何かおかしい動きをしていないかがすぐわかる。こちらは、システム内の状態が時系列でどう変化したかを表示した例です。例えば実車でテストする際、走行しながらどの場所を走っている時に、どんな問題が出てきたかといったグラフもすぐに表示できます。
――社内の開発検証に関わる方がこのグラフを見ながら、不具合の箇所を直感的に把握できる仕掛けになっているわけですね。
佐藤：そうですね。もちろんテキストでより詳細な情報も見られるのですが、まずはこうした大枠のグラフで怪しい部分を見つけ、詳細はテキストで確認するという、そういった流れを想定しています。

7. 開発効率化という価値の創出

――では次に、こうした不具合解析の効率化を通して提供したい価値について。これはたぶん自動車メーカーにアピールする部分になるかと思いますが、どういった価値になるのでしょうか。
佐藤：ソフトウェア開発は要求分析から始まり、システムやソフトウェアの詳細設計を行い、最後に評価を実施するという工程が定められています。特に自動車業界では、車載システム開発のプロセスを標準化して品質を評価するための「オートモーティブスパイス」という国際標準フレームワークが定められていて、当社もそれに則ってソフトウェア開発を進めています。さらにその工程ごとに適切かつ体系的にログを埋め込み、それらをトレースすることにより、ソフトウェア開発で複雑化の度合いが増しても、解析の効率性を一定以上保つことができています。これが一つ、大きな価値になるものと考えています。

8. インターフェースのログに秘密あり

――一方で、ソフトウェア開発には複数のチームや企業が関わったりする場合が多いと思いますが、その際の開発プロセスでの責任の所在、というか問題の切り分けにはどう対処していますか。
佐藤：一つのソフトウェアの中だけではなく、自分たちの開発しているハードウェアと別のECUとの間で、どちらに問題があるのか、切り分けが難しい場合もあります。それに対し、ソフトウェアの各レイヤーやシステム分割のインターフェース部分にログを仕込んでおいてそれをトレースするやり方を取ると、問題の切り分けが容易になります。インターフェースのログについては、外部のハードウェアとの切り替え面や、一つにユニットの中のソフトウェアのコンポーネント間といったインターフェース部分にログを仕込んでおくと、問題の所在の早期発見に役立てることができます。
――導入効果のところですが、ログトレースによって不具合の発見から検証・対策までの期間短縮について、大雑把に言ってどれくらいの短縮がなされるでしょうか。
佐藤：概算で言うと、導入前は解析に30日間以上かかるような案件も多数ありました。それが今では半分以下、つまり15日を切るところまでの短縮効果を確認できています。

9. 社外展開も視野に

――今後の対応あるいは今後の課題についてですが、やはりデジタルキャビンということで、デジタルでいろいろ新しい機能を作り込もうとすると、開発工数が増えてさらに作業が大変になっていくのではと素人考えで思われますが。
佐藤：その通りです。少しでも作業の負担を軽減するという意味で、ログトレースの仕組みやATLASについて、今後もさらなる改善が必要と考えています。あと現在は完全に社内だけの利用にとどまっていますが、それに限らず、もし他社さんにも有効性を評価してもらえるようであれば、社外に展開できればとも考えています。
――それは外部への販売も検討しているということでしょうか。
佐藤：まずは同じプロジェクトに関わっている会社さんに使ってもらって、裾野を広げていければと思っています。そこでもし良いフィードバックが得られるようであれば、外販も視野に入れられるかなとは思いますね。

10. 生成AIやAIエージェントへの期待

――今後の対応の中で、佐藤さん自身、こんなことがやりたいという案件は何かありますか。
佐藤：最近ではやはり、生成AI（人工知能）やAIエージェントが普及し始めていますので、そうした機能をデバッグコンセプトの中でも活用していきたいですね。今現在は可視化にとどまっていますが、生成AIを使うことで機能がさらに進み、一瞬でソフトウェアの不具合の原因を突き止めるとか。あるいはそこまでいかなくても、不具合の原因の候補はこの辺りでは、とシステム上に提示できるようなところまでいけるようになると、開発に必要な工数に対して効果の方がかなり大きくなるのではないかと見ています。