Contenu connexe
Similaire à 車載ソフトウェアの品質保証のこれから (20)
Plus de Yasuharu Nishi (9)
車載ソフトウェアの品質保証のこれから
- 2. 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
- 3. 車載ソフトウェア開発の現状
• 変化とスピードが新しく競争力を左右する時代になった
– VUCA
• どうなるか分からない、どうしたらいいか分からない時代になった
– CASEとMaaS
• ビジネスモデルと強みの源泉がガラッと変わってしまう技術変化が訪れた
– セキュリティとOSSとAI、OTA
• 自分たちでコントロールできない要素が重要になり、アップデートを迅速に行わなくてはならなくなった
– 電動化によるモジュラー開発化
• デスクトップPCや家電製品のように、部品を買い集めれば自動車を開発・生産できないことはない時代が訪れる
• しかし従来の競争力も継続的に高めなければ、従来からの競合相手に敗退してしまう
– 品質、性能、デザイン、価格、納期…
• テスラに負ける前に欧米・新興国に負けてしまっては本末転倒である
– ソフトウェア開発に関しては、変化だのスピードだのと言ってられないほど
開発力が弱く品質が低くトラブルが多発している現場だったりする
• 派生開発に名を借りた技術的負債増加型開発でアーキテクチャ設計力を喪失した現場をセントラルECU化が待ち構える
© NISHI, Yasuharup.3
車載ソフトウェア開発は
「両利き」の時代に突入した
- 4. 車載ソフトウェアの品質保証のさまざまな悩み
• 右利きの(伝統的な)ソフトウェア品質保証の悩み
– そもそもテストが下手である
– 実は本来やるべきテストを全部やりきれずに出荷してしまっている
– テストを全部やったとしても、どんな品質をどの程度保証したのか実は分からない
– バリエーションが膨大でテストしきれない
– テストレベルがたくさんあって整理できていない
– きっと当面ツギハギのセントラルECUをどうテストするか、きれいなアーキテクチャになったらどうテストするか
– ソフト内部、実験、全社QA、A-SPICE、機能安全がバラバラにテストプロセスを整備している
– 不具合分析会議が機能しておらず、フロントローディングができていない
– 協力会社やグループ会社のテストがイマイチである(かどうかもよく分からない)
– 全社QAが生産しか分からず、ソフトやサービスは丸投げ状態になっている
– ソフトウェア開発の全体や将来を考える人がどこにもいない
• 左利きの(デジタルな)ソフトウェア開発で発生する品質保証の課題
– OSSやセキュリティによってどんどんOTAでアップデートするソフトのためにQAをどうスピードアップするか
– ミッションクリティカルなアジャイル開発のQAおよびQAのアジャイル化をどう実現するか
– テストの自動化にどう取り組めばよいか
– 開発の多拠点化・多組織化にQAはどう取り組めばよいか
– 稼働中・開発中のビッグデータをどう活用すればよいか
– 機械学習コンポーネントのQAをどう行えばよいか
– (シェアリング)サービスなど、従来の製品とは異なるプロダクトやサービスのQAをどうすればよいのか
© NISHI, Yasuharup.4
- 5. 何に取り組めばよいかは、既に分かっている
• 右利きの(伝統的な)ソフトウェア品質保証に必要な取り組み
– テスト開発方法論の組織的導入によるテスト開発プロセスの構築、
テスト観点のモデリング力の向上、テストアーキテクチャの設計
– フロントローディング技術の導入と不具合分析技術の向上
– 全社品質管理部門のTQMフレームワークの進化と品質担当役員ポストの設置
– 社外エキスパートとのネットワークの構築と、
自社のソフトウェア開発のあり方を相談できるエキスパートの確保、
ソフトウェア開発部門のトップを役員ポストにする経営施策化
• 左利きの(デジタルな)ソフトウェア品質保証に必要な取り組み
– レジリエントQAへのパラダイムシフトとレジリエントなQA/テストプロセスへの移行
– モデルベースQAによるQAパイプラインの構築(フルCI化)
– ミッションクリティカルなアジャイルQA技術の開発と試行、展開
– シフトライトテストとインテリジェントQAへの挑戦
– テスト環境の仮想化・コンテナ化と並列同時実行によるQAの高速化
– 全社QA部門、ソフトウェア部門のQA担当、主要協力会社のDXの推進
– 左利きのQAを理解している社外エキスパートの確保
© NISHI, Yasuharup.5
右利きの取り組みを着実に進めていかないと
左利きの取り組みが砂上の楼閣になったり破綻してしまう
- 12. (ミッションクリティカルな)アジャイルQA
© NISHI, Yasuharup.12
• アジャイルチームにおけるQAの役割とマインドセットを明確にする
– 納得感の共感を高め、チームの弱いところを自らがカイゼンしていけるようにすることがQAの役割である
– サーバントシップ、カイゼンサイクル、ミッションシェア、アップストリーミング、ストーリー化
– 振り返りにおいて技術的にフロントローディングができるようバグ分析を的確に行う
• QAプロモーターがきちんと組織的な戦略を立てる
– 自組織・自プロダクトの品質保証の戦略を立てて推進する役割をQAプロモーターと呼ぶ
– 思いついたように、あるプロジェクトだけ(ミッションクリティカルな)アジャイルQAをやろうとしてもうまくいかない
– QAが上手くいかないからといってひたすらインプロセスQAやフェーズゲートQAを増やしても、
QAの技術的負債が溜まりどんどんコストが増えるだけになる
– 可能な限り自動化して内製化した方がよい
• アジャイルと自動化に対応して認証の審査をしてもらえるように開発・QA・受審のやり方を変えていかねばならない
• 審査員の指摘を無くすのではなく、
自分たちが納得感の高い開発をしていることを審査員に共感してもらえるような説明力の高い開発・QAを行う
- 16. QAアーキテクチャの構築
© NISHI, Yasuharu
※ ハードウェアにおけるQC工程表や
QAネットワークなので、無い方がおかしい
社内外に
色々なテストプロセスがあり
全体像が掴めなくなっている
自分たちで
統一したテスト設計ができるようにし、
全体として何を保証しているのかを
把握できるようにする
テスト観点
テストレベルやテストタイプ
p.16
- 20. シフトライトQA + インテリジェントQA
© NISHI, Yasuharup.20
シフトライトテストの結果から
BIのように人間が分析したり
機械学習によるAIを活用して
ダイナミックに
開発支援情報やテスト支援情報
を生成してくれる
- 22. 左利きの(デジタルな)ソフトウェア品質保証:QualiTrax
• QualiTraxとは
– 部品/製品の稼働状況・品質保証状況を
継続的かつ動的に把握し予測し品質リスクを最小化するともに、
(継続的な)開発そのものを動的にカイゼンする仕組み
• フェーズゲート方式のような静的な把握・予測ではなく
常にテストなどを行い動的な把握・予測を行い対処しカイゼンする
– OTAによってOSSやCOTS、MLなどが動的に変化しても、常に最新の品質保証状況を非同期に得ることができる
» そのために「手動テストを自動化する」から「自動テストできないところを手動でやる」モデルベースQAにパラダイムシフトして
分散非同期開発によるQAパイプラインを構築し、インテリジェントQAを行う必要がある
• 開発中も稼働中も把握し予測し対処しカイゼンする
– 開発中からの品質保証状況が全てデジタル化され構造化され記録されているため、
稼働中の不具合検知に対する原因究明が最速で可能になる
» そのためにテスト容易性設計とQAアーキテクチャの構築が必要になる
– 「終わったことになっている」テストを許さず、デプロイ前には品質リスクの高いテストを行って
運用中には品質リスクの低いテストを行うなどスピードと品質リスクのバランスを取ることができるようになる
» そのためにアジャイルQAとシフトライトQAが必要になる
» そのためにフロントローディングによる技術的負債が少なくテスト容易性の高い開発へのカイゼンが必要になる
• 構成や稼働環境などの異なる全ての部品/製品について把握し予測する
– 様々な構成や稼働環境の違いを次期部品/製品に反映できるだけでなく、
構成や環境によってデプロイする機能や制約を動的に変えることによって
品質リスクを最小化することが可能になる
– 未テストの部品/製品の品質リスクを、よく似た構成のテスト済みの部品/製品から推測することで
ピンポイントにバグを見つけるテストを設計することができる
© NISHI, Yasuharup.22
- 24. プラットフォームはどこが…?
• プラットフォームを制するものが勝つ世界になる
– 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
?