車載ソフトウェア開発を改革するトップに聞く！
クルマ×ITの品質を高めるために、今そして未来に必要なこと
本記事の内容は、発行日現在の情報です。
製品名や組織名など最新情報と異なる場合がございますので、あらかじめご了承ください。
PDFダウンロード
PDFをダウンロードいただくには、会員登録が必要です
1台の車には約1億行のソースコードが搭載されている
小野寺 充（以下、小野寺）：本日は、長年、組み込みソフトウェアの開発に携わってこられたご経験を含め、お話をお聞かせいただければと思います。最初に、村山様のご経歴を教えていただけますでしょうか。
村山 浩之氏（以下、村山）：1980年にデンソーへ入社して以来、最初の15年間は、さまざまな製品のソフトウェア開発を担当しました。その後の約20年間は、製品開発を離れ、二つの「ぜんしゃ」、すなわち「全社」ならび「全車」共通で利用するソフトウェア開発のための電子プラットフォームの構築に取り組んできました。
小野寺：電子プラットフォームの構築とは？
村山：高機能で大規模なソフトウェアを短期間かつ効率的に開発するためには、プログラミング技術や開発プロセス、プロジェクト管理の手法などを体系化する工学的な取り組み、すなわちソフトウェア開発のための電子プラットフォームが必要となります。現在、1台の車には1億行に及ぶソースコードのソフトウェアが搭載されているとも言われており*、しかも数多くのパーツに細分化されているソフトウェアを、個人の技量に依存する形で開発することは大きなリスクとなります。
小野寺：さらに、環境対応や安全対策、セキュリティ、自動運転など、車載ソフトウェアを取り巻く環境はますます厳しくなっているように見受けられますが。
村山：さまざまな規格や基準に対応しなければならない部分もありますが、欧米の規格よりも国内自動車メーカーの社内基準のほうが優れていると評価されることもあるので、簡単なことではないですが、これまで実施してきたこととは変わりはないと思います。
小野寺：ソフトウェア開発という視点で見たとき、一般的な情報システムと車載ソフトウェアでは、どのような違いがあるのでしょうか。
村山：一般的な情報システムをスクラッチで開発する場合、ラインアップが複数になるケースは希だと思います。
一方、車載製品の場合は、機能が同じソフトウェアであっても、複数の車種、さらには複数のメーカーに展開されていくので、車種やメーカーごとにバリエーションやバージョンが増えていくという特徴があります。そのため、展開する際の「差分」をいかに少なくするかは、ソースコードを開発する段階から重要なポイントになります。
また、組み込みソフトウェア開発の場合、パーツ単位で個別最適を図ればミッションは達成されてしまうこともあります。そのため、製品としての全体最適や同期・整合性などは視野に入れながらも、個々のソフトウェア開発やソースコードのプログラミングといったレベルで、共通の仕組みを意識することは少なく、積極的に横のつながりを持つという思想もなかったですね。
小野寺：そのような状況下で、どのように電子プラットフォームという考え方を開発現場に浸透させていかれたのでしょうか。
村山：最初はプロジェクト単位からスタートし、成果を上げることで評価を得て、少しずつ適用範囲を広げていきました。
開発の現場では、ソフトウェア・コンポーネントを作る側と、出来上がったコンポーネントを使ってソフトウェアを組み上げる設計側と役割分担を明確にしました。
前者はプログラミングを行い、後者はあくまで部品としてパーツを組み上げる作業に専念させました。さらに設計側には、市場環境や技術動向などを踏まえ、ソフトウェアのライフサイクル全体を見据えた開発にも取り組ませるようにしました。
センスを養うためには、距離感のある仕事を経験させることも重要
小野寺：設計側には技術的な知識を超えたセンスも求められるため、育成も大変なのではないでしょうか？
村山：例えば、アーキテクトと呼ばれるような上流のエンジニアを育成するためには、特定のテクノロジーや製品に限定することなく、できるだけ距離感のある仕事を経験させることがセンスを養うためには重要だと思っています。また、素養の見極めも必要ですね。
小野寺：素養は、どのように見抜くのですか。
村山：直接話をすると大抵は分かります。言葉で説明すると、アーキテクトは「他人（外部）から期待されてモチベーションを持つタイプ」よりは、「モチベーションが内部から湧き出てくるタイプ」のほうが向いていると思います。この点については、心の知能と言われる「EQ （Emotional Intelligence Quotient）」なども活用できればと考えています。
小野寺：エンジニアは個人としてのスキル向上も重要ですね。
村山：「何がしたいか」、「何をめざすか」、自分のキャリアパスを思い描き、そのための「課題」と「克服方法」を考え、現状とのギャップを埋めるために行動していくことが重要だと思います。
だれでも悩みや不安があって当然だと思います。重要なのは、そこで思考を停止するのではなく、分からなければ「分かるために何をすべきか」を考え、実行することだと思います。
開発支援ツールには、「可視化」と「自動化」という大きく二つの役割がある
小野寺：デンソー様にも当社取り扱い製品のC言語用ソースコード静的解析ツール「QA・C（キューエーシ－）」を採用いただいておりますが、ツールの役割をどのように捉えていらっしゃいますか。
村山：ツールには、「可視化」と「自動化」という二つの役割があります。可視化とは、ソフトウェアの品質などを客観的な指標で示すことです。ソースコードのレビューはどうしても主観的なものとなりがちなので、「QA・C」でソースコードを解析すれば、修正前後の品質の違いや成果を可視化できます。また、ツールによってプロセスを自動化すれば、作業の効率化と精緻化を図ることができます。
一方、ツールに頼りすぎないことも重要です。例えば、C言語でしか開発をしたことがないエンジニアは、ハードウェアを直接制御するアセンブリ言語を知っているエンジニアには及ばない部分があると一般的に言われています。組み込みソフトウェアの場合は、そのような知識や経験の差が如実に表れますので、プログラミングの技術は最低限、スキルとして身につけて欲しいですね。
小野寺：本日は、大変勉強になりました。ありがとうございました。
*参考資料：経済産業省 第１回 情報サービス・ソフトウェアに係る技術に関する施策・事業評価検討会資料
http://www.meti.go.jp/policy/tech_evaluation/c00/C0000000H22/110107_jyouhou1/06-3.pdf
C言語用ソースコード静的解析ツール QA・C
プログラムに混入された問題の指摘や品質測定を行うC/C++言語用静的解析ツール
プ ロフィー ル
株式会社デンソー 技監
村山 浩之
1980年日本電装（株）（現（株）デンソー）に入社。幅広く電子システムの企画・研究開発・製品設計に従事した後、1996年プロジェクトを立ち上げ、車載ソフトウェア開発の改革活動を開始。
以後一貫して、車載ソフトウェア開発の全社横断活動や自動車業界における標準化活動を推進。 2001年ソフトウェア基盤開発室長、2008年電子プラットフォーム開発部長、同年常務役員を経て、 2012年技監に就任、現在に至る。
※所属・役職は取材当時のものです