自動車業界でアジャイル開発の品質保証を適用させるポイントとは？──SDVへの変革に向けた学び

アーカイブ動画

多種多様な業界のさまざまな技術やサービスの品質向上を支援

株式会社ベリサーブ
東日本モビリティ第三事業部長　千葉 素昭氏

最初に登壇した千葉素昭氏は、メーカー系SIerでの組み込みソフトウェア開発に従事した後、パッケージソフトウェアを手がけるスタートアップに移り、プロダクトマネジャーやプロジェクトマネジャーを経験。2006年にベリサーブに入社し、さまざまな業界の品質向上プロジェクトに従事。現在はモビリティ領域、車内空間関連事業部門の責任者を務める。

創業以来40年以上に渡り、テストなどを通じソフトウェア品質の向上をクライアントと共に解決してきたベリサーブ。Webからモビリティまでさまざまな業界での実績を誇り、ソフトウェア検証における日本のリーディングカンパニーだ。

千葉氏が部門長を務めるモビリティ領域は、数多くのプロジェクトが動いているだけでなく、以下に挙げたADASやEV、IVIやTCUなど、多様なのも特徴だ。

これらモビリティにおける先端技術やサービスの品質向上を目指し、車両メーカーから各種部品のサプライヤー、通信キャリア、スマホアプリのベンダーなど、関連する多様なクライアントと協業している。

• ADAS（Advanced Driver-Assistance Systems）
• EV（Electric Vehicle）
• IVI（In-vehicle Infotainment）
• TCU（Telematics Control Unit）

品質チェックの手法を作成し、アジャイル開発における欠陥の早期発見を実現

株式会社ベリサーブ
プロダクトソリューション事業開発部　谷﨑 浩一氏

続いて登壇したのは、プリンターなどの組み込み系ソフトウェアからクラウドサービスなどの領域で実務経験を積んできた谷﨑浩一氏だ。2008年にベリサーブに新卒入社して以来、テスト・QAエンジニアに従事し、現在はテスト設計を支援するクラウドサービス「GIHOZ」のプロダクトオーナーを務める。

研究活動にも取り組む谷﨑氏は、名古屋大学との共同研究でアジャイル開発における品質チェック方法を考案し、ソフトウェア品質における日本最大級のシンポジウム「ソフトウェア品質シンポジウム」で受賞した経験も持つ。なお本セッションで紹介した内容は、まさにその受賞論文がベースとなっている、と述べた。

アジャイル開発においてもウォーターフォール開発のように要所要所で品質チェックを行うことが大事であるとし、どんなことをチェックするのかの「What」に当たる品質チェック項目と、どうやってチェックするのかの「How」に当たる品質チェック方法、これらを作成するプラクティスを紹介すると述べた。その上で、まずは所属する組織の概要や開発体制について紹介した。

自身（プロダクトオーナー）の他、デザイナー、開発者、テスターなどからメンバーは構成され、スプリントの期間は1週間。スプリント内容の計画やレビューなどを、1スプリントの内、約2時間を充て、優先順位の高いものから取り組んでいるという。

続いては、アジャイル開発に適した品質チェック項目の作り方について語った。まずはステークホルダーの関心事を整理するところから始めるという。

「ステークホルダーごとに品質チェックの関心事が異なるので、それぞれの関心事を明らかにすることが重要です」と谷﨑氏は強調する。プロダクトオーナーであれば作る価値があるかどうか、開発者であれば開発できるかどうか、といった具合だ。

続いては、整理された関心事とアジャイル開発のプラクティスをひも付ける。なおプラクティスとは、課題を解決するためのさまざまな習慣のことである。

ステークホルダーの関心事とプラクティスのひも付けは、マトリクスを使って整理する。谷﨑氏は実際のマトリクスを例として示しながら、縦軸にプラクティス、横軸にステークホルダーの関心事、交点のセルに品質チェック項目を記入することを説明。マトリクスにする理由を、次のように述べた。

「マトリクスとして整理することで、プラクティスごとに各ステークホルダーの関心事を考慮した品質チェック項目を挙げられる効果があると考えています」（谷﨑氏）

なお、参考のマトリクスでは中間が省略されているが、実際にはデザイン、コーディングといった領域においても同様に品質チェック項目を定義できる。

実際、このような品質チェック項目を作成したことで事前に見つけることができる欠陥例も紹介された。過去に開発した機能で作成したデータと新機能で作成するデータ間の矛盾などである。

どれくらいの欠陥が事前に見つかるのか、プラクティスごとの数も具体的に紹介された。約半数が、実装に着手する前に発見できるものであることが分かる。

さらに谷﨑氏は、実際に整理した品質チェック項目を基にどのように品質チェックを行っていくのか、Howのフェーズについても「ぜひ覚えていただきたい」と前置きした上で説明していった。なおチェック方法の作成においても、実装に入る前の領域を例に進められた。

具体的には、ウォーターフォール型の開発で行われていた品質保証の方法を参考に、アジャイル開発での内容に置き換えていく。そのため谷﨑氏は改めて、ウォーターフォール/アジャイル開発の違いについて触れた。

大きくは二つあるが、最初に全てが決まっているわけではなく、時間軸により変化することがあるため、その点をチェックすること。もう一つはチェック対象が散在していることを考慮することだ。

具体的な取り組み事例も示された。紹介した手順どおり、まずはウォーターフォール開発での手法を参考に、アジャイル開発でのチェック方法を作成していく。チェック方法に基づく実際のチェックの進め方においては、リアルな会話やプランニングポーカーといった具体的な場面でのチェックの例を示すと共に、理由やメリットを次のように述べた。

「品質チェック方法を意識することで、普段からチームの会話の中で品質チェックを行うことができます。プランニングポーカーは、人により考慮した作業内容に差があると、ストーリーポイントが大きく異なることがあり、そこから会話や議論が深まります」（谷﨑氏）

実際のセッションでは具体例を三つ紹介していたため、興味がある方、より深く知りたい方は動画も視聴して参考にしていただきたい。

谷﨑氏は、実際このようなチェック方法を行ったことで事前に改善する必要があることが見つかった事例も二つ紹介した。まずは、他のユーザーを招待する機能の上限人数についてチームで議論したケースである。チェック項目の記載に沿って議論を重ねていくと、QA担当者が将来開発予定の内容との矛盾に気付き、結果として将来の予定を踏まえた上限人数にまとまった。

もう一つはプランニングポーカーを使い、ストーリーポイントをメンバー同士で見積もっていたケースだ。開発エンジニアが大きなポイントのカードを出したこと、その理由を聞くことで、そもそもデータが循環している場合の出力に関する内容があいまいであったことが見つかったという。

谷﨑氏は最後に次のように述べ、セッションを締めた。

「開発に入る前のチーム内での会話やプランニングの場面、要所要所でチェックを行うことで、欠陥の早期発見、ならびに仕様改善を実現し、より良いプロダクトをいち早くユーザーに届けてもらいたいと思います」（谷﨑氏）

アジャイル開発を適用させるためには、PMOの役割や動きがポイント

続いては、再び千葉氏が登壇した。冒頭で説明したように、ベリサーブはテストなどを通じて、クライアントのソフトウェア品質の向上に寄与してきた。このようなテストは「ある意味、プロダクトの品質をモニタリングする行為だと思っています」と、述べた。

加えて、問題があれば是正勧告するなどして、開発やリリースの遅延を防ぐ役割も担ってきた。このような取り組みは、プロダクト・プロセス両工程で行っており、「それぞれプロダクトPMO、プロセスPMOと呼ぶことにします。その上でこれからの話を聞いてもらえれば幸いです」と、千葉氏は語った。

昨年開催されたScrum Tokyoに登壇した、世界的なスクラムトレーナーJoe Justice氏は、講演の中で「ハードウェアを含むプロダクト開発において、アジャイルの適用が進まないのは、11の理由がある」と語ったという。

千葉氏はその11の理由を例に挙げると共に、その中から「あるチームが別のチームを待つ状態」「サードパーティのテスト待ち」という二つの理由に着目し、解説を続けた。

まずは、あるチームが別のチームを待つ状態について、自身が担当する自動車業界を参考に紹介していった。

以下スライド左側のイラストを見ると分かるように、多様な関係者が他のチームやパートナーからのモジュール受け取りなどを待っている状態となっており、「このことが開発の遅れにつながっている」と、千葉氏は指摘した。

そして、解決に向けては開発の初期段階からモジュール間をつなぐ、インターフェイスを設計する「インターフェイス・ファースト・デザイン」の考えが求められている、と続けた。

コンストラクト・ファースト開発とも呼ばれる同手法は、ソフトウェア開発を行うSIerやSaaSベンダーで働く人にとっては、当たり前と言えるだろう。

一方で、自動車業界などハードウェアも含むプロダクト開発でも、徐々に浸透していると、千葉氏は説明する。スマートフォンのカメラやセンサーへのアクセスを可能にするAPIが該当するという。

そして内外問わず、これらハードウェアレベルでもAPIテストを確認する際に必要なのがテストダブルの手法や、支援するPMOのアプローチだと主張した。

というのも、スライドの右表で示しているように、テストダブルにはダミーからスタブ、フェイクなど、テスト対象ごとに適した要素がいくつもあるが、それぞれの要素をどう規定するかが重要であり、このような活動はまさにPMOに該当するからだ。

さらに先述した、プロダクト/プロセスそれぞれの領域に重ねて説明した。テストやテスト自動化の環境構築や、プロダクトの不具合を検出する活動支援がプロダクトPMOである。

一方、これらの活動を仕組み化するなどしてプロセスに組み込むような活動は、プロセスPMOに該当する、といった具合だ。

実際、ベリサーブではすでにIVI周りのシステムやTCUなどを対象に、IVIを操作できる環境や、制御ユニットのスタブを開発するなど、テストダブル環境の構築を進めているという現状を紹介。「テストを本格化する手前での、手戻りリスクや遅延リスクの検知に役立っています」という手応えも併せて述べた。

そして、このようなテストダブルを活用した活動のルール化や監視などにおいて、まさに先述したPMOが重要な役割を担っている、とも続けた。

また、テストダブルは資産化しやすいことも語られた。Vehicle OSやOTAなどの利用の広まりにより、テストダブルはさらに利用されるという特徴やトレンドを踏まえ、千葉氏は次のような認識、展望を述べた。

「まさしく自動車業界もですが、ハードウェア業界でもアジャイル的な開発が求められる昨今、早期に不具合を検出したり、品質リスクを可視化できたりする仕組みやプロセスを構築する活動は、今後ますます重要になっていくでしょう」（千葉氏）

続いては二つ目の理由、サードパーティのテスト待ちについて語られた。というのも、先のインターフェイス・ファーストの取り組みであっても、実際には開発中に幾度となくインターフェイスの仕様が変更されているからだ。

そのためテスト内容などが事前に詰めきれておらず、後回しとなり、結果としてボトルネックになっている。そして引き続き、こちらの対策も示したのが「テスト駆動開発（TDD：Test Driven Development）」である。

ただし、ハードウェアが含まれるプロダクトの場合は、プログラムレベルでのTDDでは完結しない。

そのため、ユーザーストーリーや要件に基づく受け入れテスト環境などを先に構築し、そのテストを通過するように実装を進める「受け入れテスト駆動開発（ATDD ：Acceptance Test Driven Development）」が有効であると、アジャイルテストの4象限の図も引き合いに出しながら、特徴などを紹介した。

中でもQ2の象限においては、自動化と手動化のすみ分けなど実施ハードルが高く、挫折する人が多いと、千葉氏は語る。

一方で、OTAなどの技術の浸透により、テスト資産の増加、ならびにそれらのアセット管理活動が、まさしくPMOの領域であり、「実際、最近はクライアントからの引き合いが多いです」と述べると、参加者の多くが驚きと称賛のリアクションやコメントを発した。

既存のテストケースをどう自動化していくかというアプローチを取ると、大抵の場合は失敗すると千葉氏は指摘する。ボタンを押すなどのハードウェアの物理的なテストのスクリプト実装で、行き詰まるからである。

自動化の手段を把握した上でテストケースを生成し、自動化できないユースケースは手動に回すと共に、徐々に自動化の割合を高めていく。そのような成功パターンも併せて紹介した。そして最後に次のようにさらなる課題を述べ、セッションを締めた。

「アジャイル開発をアジリティ高く推進する上で、さらにPMOの活動をIT化していく。このようなことが、今後の課題になると思っています」（千葉氏）

【Q&A】参加者からの質問に回答

講演終了後は、参加者からの質問に答えるQ&Aセッションが実施された。なお、Q&Aセッションでは先の二人に加え、品質管理エキスパートの熊川一平氏が、ファシリテーター兼回答者として参加した。

熊川氏は、谷﨑氏と同じくSQiPで多くの賞を受賞するなど、さまざまな企業や団体にスクラムコーチやアドバイザリーなどを行っている。抜粋して紹介する。

ican.lab　熊川 一平氏

Q．アジャイル開発を進める上での新人や技術が低い人へのアプローチは？

谷﨑：新人に対しては、他のメンバーがフォローするようにしています。具体的には、既存メンバーと一緒にモブテストやペアテスト、ペアプログラミングなどを実施しています。

熊川：それはある意味開発スピードを落としたり、育成コストとしてコストを余計に積んだりするような形なのでしょうか？

谷﨑：コストという意識は持っていません。あくまでチーム全体として成果を出すために必要な取り組みだと考えています。

熊川：そもそもコストをかけて優秀な人材を採用する。それができないのであれば、育成も含めた開発スピードを考慮した上で、新人などを採用すべきでしょうね。

千葉：チームに合う方を採用していくという考えは、正しいと思います。一方で、求めるスキルがしっかりと含まれているかどうかというと、そこはなかなかうまくいかないのが実情だと考えています。

Q．アジャイル開発におけるドキュメントの作成・管理について

谷﨑：私が紹介したプロジェクトではしっかりと残しています。何をしたいかなどをバックログとしてJiraで管理しているのですが、ユーザーストーリーの形式、文字として残しています。

UIのデザインはFigmaを使っていますが、こちらの成果物は文字ではなく画面デザインという成果物で残しています。また、先ほど千葉が説明したような受け入れテストの条件なども細かく記載するなど作成・管理しています。

熊川：それはどのタイミングで作成しているのですか？

谷﨑：バックログを作るときは細かくは書いていません。実装に入る前に、どういう機能を作るのかを具体的に記載したり、デザイナーがUIまで完成させた段階で、追ってドキュメントが増えていったりするイメージです。

毎日朝にスタンドアップミーティングをZoomで実施していて、その会でもバックログの内容についてチームに共有・相談して、決まった内容をドキュメントに反映していますから、まさに日々育っていくようなイメージです。その他、MiroやConfluenceといったツールも活用していますが、これらのツールでのコミュニケーションも残っています。

Q．品質チェック項目の管理はExcelで管理しているのか？

谷﨑：JiraとConfluenceを使っていますが、特にツールにはこだわっておらず、チームで使いたいツールを使ってきたら、今に至るという感じです。

熊川：品質チェック項目のステータス管理は、チケットなどで行っているのでしょうか？

谷﨑：そこまで厳密には管理していません。事例で紹介したような会話の際に頭の中に入れておき、会話の中で自然と品質チェックを行っているようなイメージです。どちらかというとコミュニケーションを密に取ることを意識しています。

一方、受け入れ条件はJiraで書き出していて、開発者が実装した後にGitHubで管理、セルフチェックするような形としています。

Q．QAチームがスクラムチーム外の場合、品質チェックはどのタイミングで行うのか？

谷﨑：われわれの開発チームでは、QAのメンバーがチーム内にいますが、QAチームがスクラムチーム外の場合は、QAチームもなるべくスクラムのイベントに参加して共有や会話する場を設けるのが良いと思います。

熊川：QAチームは、スクラムチームがあくまで社内リリースしたプロダクトに対して第三者的にテストする。その上で問題がなければ市場にリリースする体制はあると思います。

スクラムチーム、QAチーム、テストエンジニアチームなど。それぞれの参画方法にはさまざまな考え方があるので、今回のケースも含めさまざまな回答を参考に検討するのがいいと思います。

Q．車載ソフトウェアでは走行環境や電波状況など条件が無限に存在してしまうのでは？

千葉：ある自動車メーカーではオーナーであるドライバーにテストさせるケースもあると聞きますし、どのように工夫していくかがポイントだと思います。

熊川：ISOでシナリオベースの定義がされており、いろいろな業界標準のテストもありますので、これらを参考にまず実施するのが、一つの回答なのかと思います。その上で、どこまでリスクヘッジするのか。プロダクトオーナーやビジネスオーナーがどう判断するのか。チームメンバーとも相談しながら進めるといいでしょう。

Q．人の入れ替わりが多いチームにおいて、アセットを円滑に引き継ぐ方法は？

千葉：なぜ、人の入れ替わりが発生するのか。また、できるだけ人の入れ替わりが起きないようにするためにはどうすればよいか。このようなことを考えたいところではありますね。

谷﨑：プロダクトの世界観やビジョンをきちんと示していくこと、そこに共感してくれるメンバーで開発を進めれば、入れ替わりが多く発生するような事態にはならないのではないかと思います。

熊川：うまくいっているチームでは、ペアプログラミングなどのオンボーディングならびに、その後のキャッチアップもうまくいっているように感じます。単純にメンバーを入れ替えるのではなく、チームのカルチャーに沿っているかどうかが大事だと思います。

株式会社ベリサーブ
https://www.veriserve.co.jp/

株式会社ベリサーブの採用情報
https://www.veriserve.co.jp/recruit/