車載ソフトウェアの品質保証のこれから
2020/8/28（金）
ベリサーブ オンラインセミナー
西 康晴
電気通信大学 大学院情報理工学研究科
情報学専攻 経営・社会情報学プログラム
@YasuharuNishi / Yasuharu.Nishi@uec.ac.jp

Profile
• Assistant professor:
– The University of Electro-Communications, Tokyo, Japan
• President:
– Association of Software Test Engineering, Japan - Nonprofit organization (ASTER)
• President:
– Japan Software Testing Qualifications Board (JSTQB)
• National delegate:
– ISO/IEC JTC1/SC7/WG26 Software testing (ISO/IEC(/IEEE) 29119, 33063, 20246)
• Chair:
– JIS Drafting Committee on Software Review Process (based on ISO/IEC 20246)
• Founder:
– Japan Symposium on Software Testing (JaSST)
• Founder:
– Testing Engineers’ Forum (TEF: Japanese community on software testing)
• Judgement Panel Chair / member:
– Test Design Contest Japan, Test Design Competition Malaysia (TDC)
• Vice chair:
– Software Quality Committee of JUSE (SQiP)
• Vice chair:
– Society of Embedded Software Skill Acquisition for Managers and Engineers (SESSAME)
• Steering Committee Chair
– QA4AI Consortium
• Advisor:
– Software Testing Automation Research group (STAR)
© NISHI, Yasuharup.2

車載ソフトウェア開発の現状
• 変化とスピードが新しく競争力を左右する時代になった
– VUCA
• どうなるか分からない、どうしたらいいか分からない時代になった
– CASEとMaaS
• ビジネスモデルと強みの源泉がガラッと変わってしまう技術変化が訪れた
– セキュリティとOSSとAI、OTA
• 自分たちでコントロールできない要素が重要になり、アップデートを迅速に行わなくてはならなくなった
– 電動化によるモジュラー開発化
• デスクトップPCや家電製品のように、部品を買い集めれば自動車を開発・生産できないことはない時代が訪れる
• しかし従来の競争力も継続的に高めなければ、従来からの競合相手に敗退してしまう
– 品質、性能、デザイン、価格、納期…
• テスラに負ける前に欧米・新興国に負けてしまっては本末転倒である
– ソフトウェア開発に関しては、変化だのスピードだのと言ってられないほど
開発力が弱く品質が低くトラブルが多発している現場だったりする
• 派生開発に名を借りた技術的負債増加型開発でアーキテクチャ設計力を喪失した現場をセントラルECU化が待ち構える
© NISHI, Yasuharup.3
車載ソフトウェア開発は
「両利き」の時代に突入した

車載ソフトウェアの品質保証のさまざまな悩み
• 右利きの（伝統的な）ソフトウェア品質保証の悩み
– そもそもテストが下手である
– 実は本来やるべきテストを全部やりきれずに出荷してしまっている
– テストを全部やったとしても、どんな品質をどの程度保証したのか実は分からない
– バリエーションが膨大でテストしきれない
– テストレベルがたくさんあって整理できていない
– きっと当面ツギハギのセントラルECUをどうテストするか、きれいなアーキテクチャになったらどうテストするか
– ソフト内部、実験、全社QA、A-SPICE、機能安全がバラバラにテストプロセスを整備している
– 不具合分析会議が機能しておらず、フロントローディングができていない
– 協力会社やグループ会社のテストがイマイチである（かどうかもよく分からない）
– 全社QAが生産しか分からず、ソフトやサービスは丸投げ状態になっている
– ソフトウェア開発の全体や将来を考える人がどこにもいない
• 左利きの（デジタルな）ソフトウェア開発で発生する品質保証の課題
– OSSやセキュリティによってどんどんOTAでアップデートするソフトのためにQAをどうスピードアップするか
– ミッションクリティカルなアジャイル開発のQAおよびQAのアジャイル化をどう実現するか
– テストの自動化にどう取り組めばよいか
– 開発の多拠点化・多組織化にQAはどう取り組めばよいか
– 稼働中・開発中のビッグデータをどう活用すればよいか
– 機械学習コンポーネントのQAをどう行えばよいか
– （シェアリング）サービスなど、従来の製品とは異なるプロダクトやサービスのQAをどうすればよいのか
© NISHI, Yasuharup.4

何に取り組めばよいかは、既に分かっている
• 右利きの（伝統的な）ソフトウェア品質保証に必要な取り組み
– テスト開発方法論の組織的導入によるテスト開発プロセスの構築、
テスト観点のモデリング力の向上、テストアーキテクチャの設計
– フロントローディング技術の導入と不具合分析技術の向上
– 全社品質管理部門のTQMフレームワークの進化と品質担当役員ポストの設置
– 社外エキスパートとのネットワークの構築と、
自社のソフトウェア開発のあり方を相談できるエキスパートの確保、
ソフトウェア開発部門のトップを役員ポストにする経営施策化
• 左利きの（デジタルな）ソフトウェア品質保証に必要な取り組み
– レジリエントQAへのパラダイムシフトとレジリエントなQA/テストプロセスへの移行
– モデルベースQAによるQAパイプラインの構築（フルCI化）
– ミッションクリティカルなアジャイルQA技術の開発と試行、展開
– シフトライトテストとインテリジェントQAへの挑戦
– テスト環境の仮想化・コンテナ化と並列同時実行によるQAの高速化
– 全社QA部門、ソフトウェア部門のQA担当、主要協力会社のDXの推進
– 左利きのQAを理解している社外エキスパートの確保
© NISHI, Yasuharup.5
右利きの取り組みを着実に進めていかないと
左利きの取り組みが砂上の楼閣になったり破綻してしまう

現在の
車載ソフトウェアの
QA/テストの姿

CASE・MaaS時代に目指すべき
車載ソフトウェアのQA/テストの姿

左利きの（デジタルな）ソフトウェア品質保証：QualiTrax
© NISHI, Yasuharu
OTAオープンソース
/COTS/機械学習
QualiTraxを構成する技術
・ コンテナ化による分散非同期開発
・ （ミッションクリティカルな）アジャイルQA
・ モデルベースQA
・ QAパイプライン
・ QAアーキテクチャ
・ フロントローディング
・ シフトライトQA
・ インテリジェントQA
p.8

車両内クラウド化と分散開発化
© NISHI, Yasuharup.9
ECU仮想化 コンテナ化による
機器内クラウド化
と分散開発化
現在
Unit A Unit B Unit C Cloud
Platform
Application
Dev. Team

Misaki: デンソーはクルマをコンテナ化した
© NISHI, Yasuharup.10
https://www.slideshare.net/KentaSuzuki4/kubernetes-based-connected-vehicle-platform-k8sjpt1-k8sjp

フルMBD・MBQA化と非同期開発化
© NISHI, Yasuharup.11
コンテナ化による
エッジクラウドディスパッチの
バランスの最適化
フルMBD・MBQA化 非同期開発化
車両全体のモデルがクラウド上で動くため、
全てのテストを一気通貫で
自動実行できるようになる
車両全体のテストが
クラウド上で随時自動実行できるので
非同期にアップデートする
全てのコンポーネントの最新版を
車両に組み込むことができるようになる

（ミッションクリティカルな）アジャイルQA
© NISHI, Yasuharup.12
• アジャイルチームにおけるQAの役割とマインドセットを明確にする
– 納得感の共感を高め、チームの弱いところを自らがカイゼンしていけるようにすることがQAの役割である
– サーバントシップ、カイゼンサイクル、ミッションシェア、アップストリーミング、ストーリー化
– 振り返りにおいて技術的にフロントローディングができるようバグ分析を的確に行う
• QAプロモーターがきちんと組織的な戦略を立てる
– 自組織・自プロダクトの品質保証の戦略を立てて推進する役割をQAプロモーターと呼ぶ
– 思いついたように、あるプロジェクトだけ（ミッションクリティカルな）アジャイルQAをやろうとしてもうまくいかない
– QAが上手くいかないからといってひたすらインプロセスQAやフェーズゲートQAを増やしても、
QAの技術的負債が溜まりどんどんコストが増えるだけになる
– 可能な限り自動化して内製化した方がよい
• アジャイルと自動化に対応して認証の審査をしてもらえるように開発・QA・受審のやり方を変えていかねばならない
• 審査員の指摘を無くすのではなく、
自分たちが納得感の高い開発をしていることを審査員に共感してもらえるような説明力の高い開発・QAを行う

（ミッションクリティカルな）アジャイルQA
• スプリントデザインを適切なタイミングで行う必要がある
– インスプリントQAの増加ををどう自動化することで抑制するか
– インスプリントQAのスプリントからアロングサイドQAをいつどのようにフォークするか
– スタンドアロンQAのスプリントとどのように同期するか
– 安全関連系や高信頼部位のQAと、そうでないところのQAをどのようにバランスさせるか
• 予防的QAとレジリエントQAのリミットを見極めて組み合わせる
– レジリエンスリミットにおける予防的QAをスムーズに通過させるQAをどうQAスプリントに割り振り、どう自動化しておくか
– レジリエンスリミット以前のレジリエントQAでいかに技術的負債を蓄積せず解消しながら進めるか
– レジリエンスリミットを後ろにずらせるようプロダクトマネジャーやビジネスサイドといかに協調するか
© NISHI, Yasuharup.13

マニュアルQAからモデルベースQAによるQAパイプラインへ
© NISHI, Yasuharup.14
膨大な人力テストによる
開発遅延を引き起こす
同期型一発勝負的品質保証
フルCI（全ての検証の一気通貫の自動化によるCI）による
短いリリースサイクルでも成功しやすい
非同期型継続的漸進的品質保証
テスト自動生成

QAアーキテクチャの構築
© NISHI, Yasuharup.15
色々やってるが
実はバラバラで
全体として
何を保証しているのか
把握できないQA
整理されており
全体として
何を保証しているのか
把握しやすいQA

QAアーキテクチャの構築
© NISHI, Yasuharu
※ ハードウェアにおけるQC工程表や
QAネットワークなので、無い方がおかしい
社内外に
色々なテストプロセスがあり
全体像が掴めなくなっている
自分たちで
統一したテスト設計ができるようにし、
全体として何を保証しているのかを
把握できるようにする
テスト観点
テストレベルやテストタイプ
p.16

フロントローディング
© NISHI, Yasuharup.17
分析してパターン化して
再利用して
開発を成長させる
開発やバグの情報
使い捨てなので
開発は成長しない
フロントローディングをしない組織
フロントローディングが根付いた組織
開発やバグの情報

インテリジェントQA
© NISHI, Yasuharup.18
デジタル化された
開発やバグの情報
機械学習によって
AIが開発支援情報
を生成してくれる
フロントローディングが根付き
DXできている組織
開発やバグの情報
使い捨てなので
開発は成長しない
フロントローディングをしない組織

シフトライトQA（実運用中テスト）
© NISHI, Yasuharup.19
時代遅れの
フェーズゲート型QA
（しかし本当は終わってことにしているだけ）
モデルベースQA
シフトライト型QA
（運用中にもテストを行い
品質を監視することで
常に品質を保証し続ける）
OTA
オープンソース
/COTS/機械学習

シフトライトQA + インテリジェントQA
© NISHI, Yasuharup.20
シフトライトテストの結果から
BIのように人間が分析したり
機械学習によるAIを活用して
ダイナミックに
開発支援情報やテスト支援情報
を生成してくれる

左利きの（デジタルな）ソフトウェア品質保証：QualiTrax
© NISHI, Yasuharu
OTAオープンソース
/COTS/機械学習
QualiTraxを構成する技術
・ コンテナ化による分散非同期開発
・ （ミッションクリティカルな）アジャイルQA
・ モデルベースQA
・ QAパイプライン
・ QAアーキテクチャ
・ フロントローディング
・ シフトライトQA
・ インテリジェントQA
p.21

左利きの（デジタルな）ソフトウェア品質保証：QualiTrax
• QualiTraxとは
– 部品/製品の稼働状況・品質保証状況を
継続的かつ動的に把握し予測し品質リスクを最小化するともに、
（継続的な）開発そのものを動的にカイゼンする仕組み
• フェーズゲート方式のような静的な把握・予測ではなく
常にテストなどを行い動的な把握・予測を行い対処しカイゼンする
– OTAによってOSSやCOTS、MLなどが動的に変化しても、常に最新の品質保証状況を非同期に得ることができる
» そのために「手動テストを自動化する」から「自動テストできないところを手動でやる」モデルベースQAにパラダイムシフトして
分散非同期開発によるQAパイプラインを構築し、インテリジェントQAを行う必要がある
• 開発中も稼働中も把握し予測し対処しカイゼンする
– 開発中からの品質保証状況が全てデジタル化され構造化され記録されているため、
稼働中の不具合検知に対する原因究明が最速で可能になる
» そのためにテスト容易性設計とQAアーキテクチャの構築が必要になる
– 「終わったことになっている」テストを許さず、デプロイ前には品質リスクの高いテストを行って
運用中には品質リスクの低いテストを行うなどスピードと品質リスクのバランスを取ることができるようになる
» そのためにアジャイルQAとシフトライトQAが必要になる
» そのためにフロントローディングによる技術的負債が少なくテスト容易性の高い開発へのカイゼンが必要になる
• 構成や稼働環境などの異なる全ての部品/製品について把握し予測する
– 様々な構成や稼働環境の違いを次期部品/製品に反映できるだけでなく、
構成や環境によってデプロイする機能や制約を動的に変えることによって
品質リスクを最小化することが可能になる
– 未テストの部品/製品の品質リスクを、よく似た構成のテスト済みの部品/製品から推測することで
ピンポイントにバグを見つけるテストを設計することができる
© NISHI, Yasuharup.22

CASE・MaaS時代に目指すべき
車載ソフトウェアのQA/テストの姿

プラットフォームはどこが…？
• プラットフォームを制するものが勝つ世界になる
– OEM-QualiTrax
• 自社製品に標準搭載し、自社出荷台数をベースとして規模を高め、
単一のQualiTraxマネジメントシステムを構築する
– Tier0.5-QualiTrax
• QualiTrax対応ユニットでキモを押さえ、システムとしての販売を行い、
OEMごとのQualiTraxマネジメントシステムのインスタンスを構築する
– 複数のOEMに展開できる
– QualiTraxそのものの開発費用は単一で済む
– QualiTraxの運用も受注でき、自社の開発改善につなげることができるようになる
– (Test)Vendor-QualiTrax
• QualiTraxの規格をオープン化し、OEMやサプライヤに導入を促し、
自社でQualiTraxマネジメントシステムを構築し、そのインスタンスを提供する
– 複数のOEM、複数のサプライヤ、複数の業種に展開できる
– QualiTraxの規格策定において主導的役割を担い、存在感を盤石にする
– QualiTraxマネジメントシステムそのものの開発費用は単一で済む
– QualiTraxの運用も受注でき、顧客の開発改善のコンサルティングが可能になる
• QualiTraxコンポーネントのアドオンを開発し販売する手もあるが、これはオープンにした方が筋がよい
© NISHI, Yasuharup.24
？

講演のまとめ
• 車載ソフトの品質保証は両利きの時代になった
• 右利きも左利きも様々な悩みがあるが、何に取り組めばよいかは既に分かっている
– 右利きも忘れずに頑張りましょう
• 左利きはQualiTraxになっていく
– コンテナ化による分散非同期開発
– （ミッションクリティカルな）アジャイルQA
– モデルベースQA
– QAパイプライン
– QAアーキテクチャ
– フロントローディング
– シフトライトQA
– インテリジェントQA
• 右利きのレベルが高く、既に自分たちで左利きの取り組みを始めている
サプライヤやソフトハウス、テスト会社と一緒に歩んでいくとよい
– 自組織のQAプロモーターを確立するのが一番大事なのを忘れないこと
© NISHI, Yasuharup.25