「リリース頻度24倍」を実現したルネサスの車載ソフトウェアのDevOps、CI/CD導入の取り組みとは

アーカイブ動画

「リリース頻度24倍」を実現した取り組みとポイント

永井様
ルネサスエレクトロニクス株式会社　
オートモーティブソリューション事業本部
車載ソフトウェア開発統括部　ソフトウェアシステム開発部第一課
主任技師　永井優氏

「To Make Our Lives Easier」をパーパスに掲げるルネサスエレクトロニクスでは、自動車、産業、インフラ、IoTという4つの成長分野に半導体製品やソリューションを提供。安全、健康、スマートな社会の発展に貢献すべく、事業を進めている。

1-1

最初に登壇した永井氏は、組み込みソフトウェアエンジニアとして、これまでデジタルテレビや車載マイコンのSoC（System on a chip）開発に従事してきたキャリアを持つ。現在は車載ソフトウェアのプラットフォーム開発を推進。ソフトウェアアーキテクト、内部開発のリーダーも務める。

「15年以上前から共有開発サーバーのメンテナンスを行い、リモート開発できる環境構築に取り組んできました。ADASの開発においては、欧州メンバーとアジャイル・スクラムなども経験したことが、DevOpsな開発環境の構築に役立ったと思います」（永井氏）

現在の自動車業界は100年に一度の変革期と言われ、ソフトウェアの価値が車の価値を決める「Software Defined Vehicle（ソフトウェア・デファインド・ビークル／SDV）」という考えが浸透している。

1-2

ソフトウェアの品質は高いが、デリバリーのサイクルについては以前から課題があった。そこでよりリリース頻度を上げるべく、最新のCI/CD技術を導入したソフトウェア開発の体制を整備することに至った。この取り組みによって、1カ月サイクルでSDKリリースすることを実現している。

1-3

ルネサスエレクトロニクスでは500人を超える開発者が、30以上のプロジェクトをグローバル4拠点で同時に進める。開発者がシステムにコードをプッシュすると、レビュー、ビルド、テストが自動で行われる。下部のスライド、青色のインテグレートの領域だ。

そしてすべてのテストを通過すると同じく下部のスライド中央緑色のデリバリー領域にマージされ、パッケージングされる。

パッケージングのレビューやテストも自動で行われ、リリースされる状態のSDKが生成される。ここで初めて人が介在、手動で品質確認を行い、お客様のもとにデリバリーされる。

「インテグレーション、パッケージ生成の大部分を自動化したことで、最長2年かかっていたSDKのリリースが、1カ月サイクルに短縮されました」（永井氏）

1-4

開発の効率化を妨げる３つの課題をどう解決したか

今回の取り組みや実際のフローがスムーズに実行されるまでには、「分断された開発環境」「品質担保と規模の両立」「組み込みソフトウェアのテスト自動化」という大きく3つの課題があった。

1-5

まず1つ目の課題「分断された開発環境」については、これまでの開発手法はウォーターフォールであったため、CI/CDの考え方はもちろん、利用ツールの扱いに慣れていないことが想定された。

そこで、開発インフラチームを発足。日本人、ドイツ人、ベトナム人といったグローバルなメンバー構成で、グローバル各拠点の開発者をサポートする体制を整えた。

1-6

開発インフラチームのメンバーは、GitLab上で動作する自動テストのフレームワークの開発・提供・管理のほか、GitLabのIssues機能を活用するなどして、開発者からの質問にも応じる。

GitLab Enterprise Editionを導入したことで、GitLab社からのサポートも受けられる体制とした。開発インフラチームだけでは対応が難しい事案も対応できるようになり、技術セミナーなどの勉強会も開催した。

導入の際には大きく3つのフェーズに分け、段階的に開発者に馴染んでもらう配慮も行った。最初のフェーズでは、先のアーキテクチャを構築するとともに、利用のガイドラインを作成した。

その後、一部の開発チームにトライアルを適用した上で、全開発者に展開した。だが、これだけの準備をしたにも関わらず、当初は導入がうまくいかなかったと永井氏は振り返る。

「結果として、トライアルフェーズでは十分な思考やスキルが身に付いていませんでした。そこで開発インフラチームがよりサポートするよう心がけました。もうひとつ、ウォーターフォールに慣れていたため、テストを少しずつ積み重ねていくとの思考も浸透していないことも問題でした」（永井氏）

具体的には、リリースの直前にインテグレーションが大量に行われていた。そのため問題が同時期に多発するため、リリースの遅れが生じたのである。

この課題を解決するべく、永井氏はSDKのインテグレーションで発生した問題を、ここでもGitLabのIssues機能を使い、開発者に共有・可視化。同対応を地道に重ねることで、課題は解決していった。

1-7

GitLabの機能を活用し、クライテリアの設定や簡便なシステムを構築

続いては「品質担保と規模の両立」だ。GitLabにはビルドやテストをパスしたかどうかをチェック（記録）する機能がある。この機能を使い、マージをリクエストする際には、すべての自動テストをパスしていることを必須のクライテリア（基準）とした。

先述したように、500人以上の開発者がそれぞれ、ドライバー、ミドルウエアといった個別のコンポーネント、モジュールを開発している。それぞれのコンポーネントやファイルの責任を持つ開発者が、変更時のレビューをチェックしたことも、同じくクライテリアとした。

なお、こちらの確認においてはGitLabのCODE OWNERSという機能を使っており、セッションでは実際のUI（以下スライド右下）も紹介された。

1-8

最後は「組み込みSWテスト自動化」について。R-Carの場合、1つのデバイスに対して複数のOS、30以上のドライバーを組み合わせることで、構成されている。そのため必然的に評価テストを行う際は多くの機材が必要となり、多数のケーブルとつながるなど、かなり大変な業務で、フリーズするようなこともあるという。

そこで、これらのフローを簡便に行えるように、リモート制御システムを開発した。GitLab Runner機能を活用することで、開発者は他のテストと同じようにGitLabにコードをプッシュするだけで、自動でテストを実行でき、結果も同じく自動で戻ってくる仕組みとした。

フリーズ対策も講じた。不調を感知した際は開発者が遠隔地にいても、リモートで制御できる仕組みを構築。問題が発生した場合には、フルリモートで復旧を可能とした。また、これら制御内容はリポジトリ上の定義ファイルとして可視化されているため、新たな機能開発などにも流用でき、開発者自身での改善フィードバックも可能。

1-9

取り組みは現在、ADASやGateway領域の製品で導入されており、今後はMCU領域にも展開していく。さらなる展望を次のように述べ、セッションを締めた。

「最終的には評価ボードの使用やSDKをインストールすることなく、クラウド経由でリモートでお客様がソフトウェア開発を行える環境を提供したいと考えています」（永井氏）

なぜ、車載組み込みソフト開発にはCI/CDが普及しないのか？

久保様
ルネサスエレクトロニクス株式会社
オートモーティブソリューション事業本部
車載ソフトウェア開発統括部　ソフトウェアシステム開発部第三課
課長　久保善弘氏

続いて、R-Carプロジェクトの管理、ソフトウェア開発管理のインフラ構築・支援に携わる久保氏が登壇した。久保氏は2015年から数年にわたりドイツに駐在し、世界中から集まったメンバーと一緒にインフラ開発に携わった経験を持つ。

そうしたグローバル経験から、日本はエンジニアが新しい技術を取り込んだり、技術が組織に広まるまでの環境やスピードがヨーロッパと比べると遅いと指摘する。

「技術的な観点もありますが、CI/CDを組織に浸透させるには『課題解決』と『プロジェクト管理』が非常に重要だと考えています」（久保氏）

2-1

久保氏は実際のデータも照らし合わせながら、まずはDevOpsの普及率を紹介。経営層にDevOpsの重要性は浸透しているが、実践は難しいと認識している。レガシーなインフラ、移行コストなどもあるが、上位職種と現場の意見相違が大きいことを言及した。

現場のエンジニアは新しい技術やモダンな開発フレームワークを使いたいと思っても、ビジネス的な観点や目先の業績を優先するために承諾されないこともある。特に日本はこの傾向が強いと久保氏は指摘する。

では、実際にCI/CDがどのくらい普及し、成功しているのか。海外の大手IT企業は1日に数千から数万件という頻度で、新たなリリースを行っている。一方、自動車メーカーや家電メーカーなどの企業は、外資系であってもIT企業と比べると頻度が低い。

さらに調べると、自動車の部品メーカーは平均頻度が3カ月くらいであることも分かった。

「我々は月に一度の頻度でリリースを行えば、現在の自動車メーカーの期待に応えられることが見えてきました。これらの数値を参考に、目標を実現するための課題解決に取り組むこととなりました」（久保氏）

2-2

具体的には、開発・試験リードタイムのさらなる短縮、システム信頼性のリスク対応などである。結果として、新たなCI/CDシステムの導入も含めた大幅な業務プロセス改善が必要であり、当初はうまくいかなかったことを改めて強調した。

しかし二度の失敗を経験したからこそ、先の世の中の状況を調べたり、どのような取り組みを行えば失敗を重ねず済むのかとの知識を得たと言えるだろう。

事実課題を書き出し、社内の第三者を交えて解決策を探る

さらに「課題解決」の手法についても解説された。具体的な取り組みとして紹介されたのは、社内で定期的に開催している課題解決講座だ。車載ソフトウェアの開発、つまりCI/CDのフレームワークを導入した際に使う数百人のメンバーを対象に、開発統括部長自ら1グループ10～15名のメンバーを対象に、定期的に実施している講座である。

「例えば『なぜCI/CDの導入がうまくいかなったのか』をテーマに事例をケーススタディとして実践的な議論を重ねて、手法を学んでいくMBAの講座スタイルで実践しました」（久保氏）

久保氏はトレーニングで身につけた、課題解決の手法もいくつか紹介した。１つは、発生した事実を客観的に書き出すことだ。できるだけ具体的に、他の部署や第三者にも分かる書き方がポイントだと語る。

「事実を書き出していくと頭の中が整理されていき、課題の本質が少しずつ見えるようになっていきました」（久保氏）

2-3

次のステップは「CI/CDの定義があいまい」など、書き並べた事実を5つのカテゴリに整理し、それぞれ対策を講じた。

対策を行う際には、久保氏が属するインフラチームが部署を横断して行った。加えて、統括部長など上位職種のレビューも交えることが重要であり、その上でギャップが生じたら都度、アクションしていくことが重要だという。

もうひとつ、課題解決やギャップ解消の状況をスライドのようにグリーン、イエロー、レッドと色分けし、進捗が一目で分かる工夫も行った。

「問題を明らかにして整理すること。加えて第三者はもちろん上位職種に共有、対策を依頼することで、支援を得られやすくなることに気づきました」（久保氏）

2-4

見える化し、共有することで共通理解と協力体制が生まれる

CI/CDで効果を出すためには従来のウォーターフォールではなく、アジャイル・スクラムの開発手法も取り入れる必要があった。そこで、まずは開発者に伝えることに努めた。

その際の工夫として、「誰でも分かりやすく」を心がけたと久保氏は言う。例えば、アジャイルやCI/CDの手法や概念は海外で生まれたと思っている人が多いが、起源はトヨタ自動車の改善活動がルーツである。

また、外部のコンサルタントなども招き、教育講座といったかたちでも実施した。ワークフローの再定義も実施した。

2-5

KPIやKGIの設定においては、レベルを1-5段階と分け、それぞれのレベルに各チームがいつまでに達成すべきか、スケジュール管理も行った。

「自分たちのチームは今どのあたりにいるのか。いつまでに目標のKPIを達成すればいいのか。当たり前のことですが、全メンバーの共通理解を得るために行いました」（久保氏）

そしてこれらの状況を幹部も含め全員が共有できるよう、アジャイル・スクラムボードで管理し、見える化した。同時に、タスク（チケット）の達成をポイントに置き換えることで、先のレベル達成を分かりやすくした。

2-6

こうした取り組みの結果、各チームの進捗が日々把握できるようになった。途中でマイルストーンの達成が難しい状況が発生したが、ボードで素早く把握し、対策も早く打つことができた。結果として全チームが目標どおりの期日までにゴール達成できた。

「CI/CDに限らず、新しい技術やスキームを導入する際は、技術的な検証とともに今回紹介した2つのポイントを適用する。周囲の協力を得ながら情報を共有し、ゴールを設定して、全員で前に進んでいくことが成功の近道だと考えています」（久保氏）

【Q＆A】参加者からの質問に登壇者が回答

セッション後は、イベントを聴講した参加者からの質問に登壇者が回答した。その中からいくつか紹介する。

Q．DevOps開発への転換に伴う品質確保の考え方の変化は？

永井：大きくは2つあります。1つは、ウォーターフォールでは工程を区切り、移行する際に品質を確認します。一方、アジャイルではマイルストーンを設け、期間で区切ります。その期間の中でテストを行い品質も確保するプロセスに変えました。

もう1つは、テストも評価も手動ではなく、自動で行うことにしました。その結果、従来と同等以上のテストを行いながら判断を短縮、品質も担保する流れとしました。

久保：アジャイル・スクラム体制への移行に伴い、品質保証や品質管理を行っている部門から、品質担保についてこれからどう変えていくべきかという課題が挙がっていました。そこで我々も一緒にレビュー活動などを行っています。

Q．GitLabを選んだ理由は？

永井：組み込み評価ボードも組み合わせた環境を構築するためです。グローバルで共通利用するシステムであるため、日本にサーバーを置いた場合、ヨーロッパのアクセスがストレスになるだろうと考えました。そのため、まずオンプレサーバー上で動くこと、複数のサーバーを複数地域で分散構成できるという2つの要件がありました。

もう1つは既に社内でGitLabを使っているチームがあり、ぜひ使いたいという要望があったからです。

Q．電源制御装置は市販のものか

永井：スマートPDUという市販品で、いわゆる電源タップです。ただ、組み込み評価ボードを遠隔で制御できるように独自機器を開発し、組み合わせて使っています。

Q．自動テストの規模感やエラー誤検出など、運用面での苦労は？

永井：1チームあたり100～200件かけるチーム数なので、5万～10万といったオーダーになります。OSやデバイスの組み合わせで、どうしても条件が増えてしまうからです。

苦労に関してはインフラの不安定、組み込み評価ボードの動作が安定していないことです。テスト結果がfailと出ても、ボード不安定による環境のものなのか、テストによるものなのか、判断が難しい状況です。

現在の工夫としては、failの理由が環境要因なのか、テスト結果なのか簡単に分かるように、テスト実行を行う仕組み側で一時判定を行うようにしています。環境要因であれば開発インフラチームが対応。テスト結果によるものであれば開発チームが確認しにいく。そのような振り分けにしています。

Q．QAの自動化を阻んでいる主要因は何か

永井：GitLabにはApproveのような自動化テストの機能があり、今回のケースでも実現できているケースもあります。一方で、車載ソフトとしてリリースに値する品質を担保するために、さらなるメトリックス（基準）をエビデンスとして収集する必要があり、自動化が難しいのが現状です。

例えば、ソースコードレビュー指標や車載機能の安全規格で要求される要件カバレッジなどです。専用ツールも用意されていますが、全チーム共通の仕組みで行える段階にまでは、至っていません。

また、これらが整備されたとしても、機械が自動で担保した品質をそのまま受け入れるかどうか、会社の現在の文化と照らし合わせても難しい。そのため、この両輪で取り組みを進める必要があり、まだ時間はかかると考えています。

久保：日本ではまだまだオートテストレポートを作成し、メトリックスとして活用する環境や文化が整っていないように思います。

一方、ヨーロッパでは進んでいるため、ヨーロッパのQAメンバーは、メトリックスを自動で出すとともに、開発サイドにアドバイスも行っています。私たちも次のステップとしては、その輪を国内ならびにグローバルの拠点にも広げていきたいと考えています。

Q．ソフトウェアBOMの管理はどのように行っているのか

永井：私たちがリリースしているSDKは大きく2種類のソフトに分けられます。1つはLinuxベースのOSSで構成されているもの。もう1つはドライバーなど、私たちがゼロから作ったもので、提供が異なります。

私たちがゼロから作っているものは、ドライバーなどコンポーネント単位でバージョンをリポジトリの中で管理。パッケージする際に情報を集めて、BOMリストを生成して含めています。

一方、OSSに関してはLinuxのディストリビューション、いわゆるUbuntuのようなものを作るためのYocto Projectというフレームワークがあります。Yocto ProjectにはソフトウェアBOMのように、組み込まれているライブラリを生成する仕組みがあるので、このフレームワークを使って構築しています。