車載システム開発における品質保証の進化──伴走型QAと現場で作り込む品質
車載システム開発におけるアジャイル普及と品質保証の現状近年、車載システム開発でもアジャイル開発（スクラムなど）の採用が進んでいます。しかし、品質保証（QA）は従来型の方法論に留まり、スプリント外で行われる監査やゲートレビューに偏っているケースが少なくありません。この方法論では、品質リスクが早期に共有されず、リリース直前に重大な問題が発覚することもあります。QAが「最後に合否判定を下す役割」として認識され、開発チームとの距離感が生まれてしまうのです。 品質保証の役割とアジャイル開発への適応従来型QAは、品質計画を立て、ゲートレビューや監査で品質基準を満たしているかを確認する役割を担います。これは品質保証の枠組みを維持するために不可欠です。一方、アジャイル開発では短いサイクルで価値を届けることが求められます。その中で、開発と同じリズムで品質を作り込む仕組みが必要です。そこで登場するのが 伴走型QA＝Quality Engineering（QE） です。QEは、品質保証担当が担う場合もあれば、開発チーム内に専任を置く場合もあります。いずれの場合も、品質を「後から判定する」ではなく「一緒に作り込む」ことを目指します。QEはスプリントの長さに依存せず、例えば2週間のスプリントでも、計画・レビュー・分析をスプリント内で回すことが可能です。一部の事例では、イテレーション内の最終スプリントを品質保証活動に充てる方法もありますが、QEは全スプリントで品質を作り込む点が特徴です。 車載システム開発の現場で報告されている事例：QE導入による品質保証強化車載システム開発の現場では、QEを導入することで、従来型QAの仕組みがより効果的に機能した事例が報告されています。例えば、ある車載ソフトウェア開発チームの取り組みとして、次のような事例があります： スプリント計画時に品質リスクを洗い出し、優先度を設定し、チーム全体で共有→ リスクを早期に共有することで、対応漏れや後工程での不具合発生を防止 Doneの定義を明確化し、品質基準をチームで共有→ 品質基準の認識ズレが減り、レビュー指摘や手戻りが大幅に減少 スプリントごとに品質指標を振り返り、改善策を次スプリントに反映→ 継続的な改善により、品質課題を早期に解消報告によると、リリース前の重大不具合は半年で約50％削減され、品質リスクが早期に共有されることで手戻り工数も大幅に減少したとされています。この報告は、QAの枠組みとQEの現場適応が組み合わさることで品質保証が進化する可能性を示しています。 QAとQEの役割分担 QA（Quality Assurance）品質計画、ゲートレビュー、監査 → 品質保証の枠組みを維持 QE（Quality Engineering）スプリント内で品質リスク管理、Done定義、品質指標改善 → 品質を現場で作り込む両者は競合するものではなく、補完関係にある「両輪」です。 QEの具体的な関わり方 Doneの定義やチェックポイントの整理「何をもって完了とするか」を明確化し、品質基準をチームで共有 品質リスクの見える化と共有スプリント計画時にリスクを洗い出し、優先度を設定 技術レビューへの参加設計レビューやコードレビューに参加し、品質観点で議論をサポート レビュー指摘の分析スプリント内で発生したレビュー指摘（不具合や改善点）を記録・分析し、品質改善に活用 テスト結果の分析スプリント内で検出された不具合を分類・傾向分析し、次スプリントの品質戦略に反映 リリース判断のための品質情報提供「どこに懸念が残っているか」を可視化し、リリース可否判断に必要な情報を提供 スプリントの振り返りで品質状況を確認し、改善策を次に活かす不具合件数やレビュー結果などを確認し、改善策を次スプリントに反映まとめ品質保証は、もはや「最後に判定する役割」だけではありません。QAが品質保証の枠組みを維持し、QEが現場で品質を作り込む──この両輪で、品質保証はアジャイル時代に適応します。当社では、こうした取り組みを実現するために、品質リスクの見える化やスプリント内レビューの仕組みづくり、品質指標の設計といった仕組みづくりの お手伝い に加え、実際のQE活動における現場サポート（レビュー参加、品質データ分析、改善提案など）も ご支援できます。「QEをどう立ち上げ、QAと連携させるべきか？」とお悩みの方は、ぜひご相談ください。品質保証を進化させる第一歩は、開発とQA/QEが同じゴールを見て走ることです。（安部宏典）