✌️
アジャイル開発の品質保証〜自動車業界で起きるSDVへの変革に向けた学び〜イベントレポート
公開
2025-03-18
更新
2025-03-18
文章量
約3692字
Yard 編集部
Yardの編集部が、テック業界の最新トレンドや知見について発信します。
はじめに
2024年12月16日に開催されたオンラインイベント「アジャイル開発の品質保証〜自動車業界で起きるSDVへの変革に向けた学び〜」は、ウォーターフォール開発からアジャイル開発へと変化する開発現場のリアルを、品質保証（QA）の観点から鮮明に解きほぐす刺激的な内容でした。
主催のベリサーブ社は「ソフトウェアテスト」や「品質保証支援」を専門に数多くの企業と協業してきた企業であり、今回のセミナーでは自動車業界にも広がりを見せる“アジャイルの潮流”にフォーカス。ソフトウェア中心の車づくり――いわゆるSDV（Software Defined Vehicle）――の時代が到来する中、「アジャイル開発でも品質は担保できるのか？」という問いに対する具体策が披露されました。
本レポートでは、イベント全体の構成を踏まえて以下の点を紹介します。
アジャイル開発の狙いと、従来のウォーターフォール開発とのギャップ
アジャイルで「不具合の早期発見」を実現する品質チェックの具体策
SDVがもたらす自動車業界の変革と、その中でのアジャイル／QAの新しい在り方
自動車業界に限らず、アジャイル開発の品質をどう確保するか悩む方々にとって、手がかりが詰まったセミナーだったのではないでしょうか。以下では、その各セッションのエッセンスを要点的にまとめていきます。
アジャイルで欠陥を早期発見するための具体策
イベント前半を飾ったセッションでは、ベリサーブ社のテストエンジニア／博士号ホルダーでもある谷崎氏が登壇。
「アジャイル開発はリリースサイクルが短く、変更にも柔軟に対応できる一方、早期に欠陥を拾いにくいリスクがある。そこで“品質チェック”をどう仕組み化するかが鍵になる」というテーマを軸に、ウォーターフォール開発時代の“前倒し検証”をヒントにしたアジャイル版の品質チェック手法が示されました。
品質チェック項目の作り方
谷崎氏が提案したのは、「ステークホルダーごとの関心事」×「アジャイルで用いられるプラクティス（工程・習慣）」 を組み合わせたマトリクスで品質チェック項目を整理するアプローチです。
アジャイル開発では仕様の決定や修正が絶えず行われ、ウォーターフォールのような大きな一区切り（レビュー工程）が存在しないため、「いつ」「何を」「誰の視点で」 チェックするのかを明確にしないと、欠陥が後工程に持ち越されやすくなります。 たとえば、次のように整理します。
プラクティス例: バックログアイテムの作成、バックログのリファインメント、スプリント計画、テスト設計…
ステークホルダー例: プロダクトオーナー（ビジネス観点）、開発エンジニア（実装観点）、テスター（テスト観点）、UXデザイナー（ユーザー体験観点）…
各プラクティス×ステークホルダーの交点で、「どういう点をチェックすべきか」＝品質チェック項目を洗い出すわけです。これにより、例えば「バックログリファインメント時に、将来予定している機能と矛盾しないか？」「スプリント計画時に、テスト自動化の分量を考慮した見積もりか？」といった具体的なチェックを明確化できます。
品質チェック方法
では、そのチェックを実際にどう行うか。「ウォーターフォールのレビューを、そのまま持ち込むのは難しい」と思いがちですが、 「あえてウォーターフォール時代の知恵を活かす」 というのが谷崎氏のアドバイス。
たとえば、ウォーターフォールで言う「仕様レビュー」は、アジャイルなら「バックログ作成時の会話やプランニングポーカーでの見積もり」を利用して確認する、など。
例1: バックログリファインメント中に「既存機能との整合性は大丈夫か？」と必ず質問する
例2: プランニングポーカー（見積もり）で大きくポイントがブレた場合、その差分を議論することで“曖昧な仕様”や“想定外の条件”を発見
こうした会話を品質チェックにつなげることで、欠陥を早期発見し、修正コストを抑える狙いです。
実際の事例
事例としては、チームメンバーの「開発者のポイントが大きい理由を聞いてみたら、既存仕様との整合性問題が判明した」「プランニング中に“将来的に別のプランで人数制限する可能性あるよね？”という意見から、新仕様を修正できた」などが語られ、「明確な品質チェックの作法があるだけで、普段の会話に『気づきのトリガー』を埋め込める」 ことの重要性が示されました。
SDV時代に求められるPMOとアジャイル適用
後半は、ベリサーブ社の千葉氏が登壇し、 SDV化が進む自動車業界でアジャイルがどこまで浸透するか？ を問い直しながら、そこで品質保証を支える役割として「PMO（Project Management Office）」がどのように動くのかを論じました。
なぜSDVにアジャイルか
「ソフトウェアで車を定義する」SDVは、OTA（Over The Air）による機能更新が前提。となると、機能やセキュリティ対応のたびに“早めのリリース→追加アップデート→ユーザーフィードバック”と回す必要があるため、アジャイル開発（短いサイクルで改修・検証する手法）が親和性を持ちやすいという文脈です。ただし、「アジャイルを導入すれば即解決」という単純な話ではなく、「車載ECUを含むハードウェアとのインターフェース設計（API化）」をいかに早い段階で決めるかが肝になるとのこと。ここで鍵を握るのが、インターフェイスファースト（APIファースト）という設計手法です。
インターフェイスファーストとテストダブル
SDVでは、多数の制御ECUやセンサー、サーバーと車載システムが連携するため、モジュール間の“契約”を最優先で固めることが重要。それを支援するのが「テストダブル」と呼ばれる擬似モジュールです。
テスト対象のモジュールに対して、入出力を模擬するスタブやフェイクを先に準備する
これにより、アジャイルにありがちな「隣のモジュールがまだできていないからテストできない」という遅延を避けられる
必要な契約（API仕様や動作条件）を事前に確立し、インターフェイスを起点に開発を進める
このテストダブルを用いるアプローチは、プロダクトPMO（プロダクト品質のモニタリング担当）やプロセスPMO（開発プロセスを整備・監視する担当）が連携することでうまく回せる、と千葉氏は語ります。
アジャイルを回すPMOの役割
さらに、「アジャイル×車載」 という難題に対してテスト駆動開発（TDD）やアクセプタンステスト駆動開発（ATDD）の考え方を導入する事例も増えているとのこと。
ハードウェアと組み合わせる開発では、すべてを自動化するのは困難ですが、少なくとも 「インターフェイスの契約に従ってテストを書く→合格するまで実装」 というフローを一部でも適用すれば、早期に欠陥を洗い出せるメリットは大きい。
そのため、テスト環境をどう構築し、どう資産化して維持するか――これをプロセスPMOが支援する。プロジェクトの速度を落とさないためにも、このような仕組み作りの視点が不可欠だ、というのが千葉氏の主張でした。
全体を踏まえた感想：変革の波を“品質”で乗りこなす
ウォーターフォールからアジャイルへ――この潮流は、ソフトウェア業界なら当たり前になりつつありますが、車載業界（自動車開発）においては、ハードウェアとの複雑な融合が障壁となり、実際にどうやってアジャイルを回すかが模索されてきました。
本セミナーでは、「あえてウォーターフォールの知恵を活かしつつ、アジャイル開発に品質チェックのトリガーを仕込む」という具体案が示されました。アジャイル開発では工程が曖昧に連続しているため、バックログ作成やプランニングポーカーなど、日々の開発プラクティスを“ミニレビュー”の場に転用する、という発想が非常に現実的です。 さらに、「SDVで広がるOTAやソフト更新の需要」「ハードウェアとソフトウェアのAPI化」「テストダブルやATDDの活用」など、自動車業界が直面する変革は、実はアジャイルと密接に絡み合っているという見解も説得力がありました。
この大きな変革を“品質”の面から支えるのがPMOの役割。プロダクト単位の不具合検出（プロダクトPMO）と、開発プロセスの整備や自動化基盤の整備（プロセスPMO）を両輪で回し、アジャイルと品質保証を両立していく――この視点は、自動車業界だけでなく大規模システム開発全般においても必見のヒントを提供してくれます。
「アジャイルでも品質を犠牲にしない」――イベントを通じて語られたのは、そこに至るためには日常の開発活動に“気づきのトリガー”を仕掛けるしかないということでした。ドキュメントやレビューの考え方を固定観念に縛られず、ステークホルダーが“対話”を通じて欠陥を拾いあげる仕組みを作ること。それこそが、SDV時代に必須のアジャイルQAなのだ、と改めて納得させられるセミナーとなったのではないでしょうか。
Yardでは、テック領域に特化したスポット相談サービスを提供しています。
興味がある方は、初回の無料スポット相談をお申し込みください。
また、資料請求やお問い合わせもお待ちしております。テック領域の知見を獲得し、事業成長を一緒に実現していきましょう。
