品質と開発スピードを両立させる「大規模アジャイル開発」のアプローチとは？

アーカイブ動画

ソフトウェアテストと品質保証の知見を武器に、プロダクト開発を支援

朱峰錦司氏は、2021年4月にベリサーブに入社。研究企画開発部サービス開発課課長として、ベリサーブ内製のテスト支援プロダクト群の全体統制と普及展開に従事している。前職は大手SIerで、前半はソフトウェアテスト技術を中心に、後半はアジャイル開発関連技術を中心に携わってきた。

「資格も取得しながら、顧客となるプロダクトオーナーの補佐をしてきました。次第に、自らがプロダクトオーナーとして仕事をしたいと考えるようになり、ベリサーブへの転職を決めました」（朱峰氏）

また朱峰氏は、ソフトウェアテスト技術関連の社外活動も積極的に行っている。若手テストエンジニア向けにワークショップを企画する「WACATE」の実行委員や、IEEEが主催するソフトウェアテストに関する世界最高峰の国際カンファレンス「ICST2017」の運営委員を経験。現在は日本で最大級のソフトウェアシンポジウムを運営している団体「JaSST」の軽量なLT大会「JaSST nano」の実行委員を務めている。

今回の講演では「大規模アジャイル開発の特徴」「その特徴ゆえに生じるソフトウェアテストに関する課題」「これら課題の解決アプローチ」という3つのゴールに対して、朱峰氏の知見や経験が語られた。

アジャイル開発はITビジネスリスクを低減させる開発手法

まず朱峰氏は、ユーザー数が5000万人に達するまでにかかる期間を示し、プロダクト開発の変化を極めて端的に表現した。飛行機は68年、自動車は62年、ATMは18年かかっていたが、プロダクトの主戦場がWebやモバイルに移ってからは、がどんどん短くなっている。

今の時代はVUCAの時代、またはそれに「S」をつけたVUCASの時代と呼ばれる。VUCAとはVolatility（変動性）、Uncertainty（不確実性）、Complexity（複雑性）、Ambiguity（曖昧性）の頭文字をとったもの。そして、Sが表すのはScalability（スケーラビリティ）だ。

不確実性が高く、これまでのやり方が通用しなくなり、プロダクトはより複雑化していく。その一方で、ユーザーが求めるものは曖昧性が増しており、開発したプロダクトを拡大・拡張することが求められる。「このVUCASの時代に取り入れられているのが、アジャイル開発」だと、朱峰氏は語る。

「例えば、10年前に注目を集めた3Dテレビ。今や家電量販店で見かけることはほとんどありません。現在の主流は、4Kや8Kテレビです。開発前に十分なユーザーリサーチを行っていたとしても、いざリリースすると売れないケースも起こりうるのです」（朱峰氏）

では、いかに失敗リスクを下げるか。朱峰氏は「大きく失敗するよりは小さく失敗することが大事」だと言う。もちろん開発手法をアジャイル開発に変えたからといって、確実に成功が待っているわけではない。だが、プロセスを工夫することで、失敗のリスクや失敗のダメージを減らすことができる。それこそがアジャイル開発の真髄なのである。

何かしらのプロダクトやサービスをリリースし、その反応を見ては補正し、また反応を見る。それを短期間で繰り返すことで、時間をかけた一発勝負よりも、ビジネス価値を毀損するリスクが軽減する。

「つまりアジャイル開発とは、VUCAの時代におけるITビジネスリスクを低減させる開発スタイル。アジャイル開発が貢献するのはビジネスなのです」（朱峰氏）

とはいえ、アジャイル開発をすべての領域に適用する必要はないと、朱峰氏は補足する。その指針としては、ビジネスリスクの有無が挙げられる。例えばビジネスリスクのない社内の基幹システムは、しっかり計画してから取り組むウォーターフォール開発の方が手戻りは少ない。一方で、ビジネスリスクを抱えたサービスは、アジャイル開発で取り組む方が得策だというわけだ。

だが、何もない状態から始めるのは難しい。そこで先駆者たちが様々な方法論、フレームワークを提供している。リーンスタートアップやスクラム、エクストリームプログラミング（XP）などは、アジャイル開発の実践方法の代表例である。

「これら3つの技法はすべて併用することが可能です。リーンスタートアップはデリバリーの外側、ビジネスに対してアプローチしていく技法。スクラムはデリバリーに向けたアプローチ。XPはプロセスではなく、技術の話です。どれか一つを選ぶのではなく、適材適所で組み合わせて使っていくことが、アジャイルを実現する秘訣です」（朱峰氏）

大規模アジャイル開発の現場が増えている

近年、大規模アジャイル開発が増えている。degital.ai社のアジャイル開発に関する調査「State of Agile」2021年版では、アジャイル実践企業の73％が2チーム以上で協業していると発表されている。

アジャイルチームがスケールする方法には2パターンある。1つは通常のアジャイルチームで小さく始めたプロダクトが、ビジネスの成長とともに少しずつ大きくなるパターン。もう1つは最近増えつつある、大規模プロダクトを開発する前提でデリバリースピードを上げる工夫をするパターンである。アジャイル開発の大規模化を支える技術の進化によって、後押しされている。

例えばサーバーシステム領域においては、従来のモノリシックなシステムに変わり、マイクロサービスアーキテクチャが採用されるようになった。また、Kubernetesや類似サービスによる軽量コンテナベースのシステム運用へと変わりつつある。

これらの技術により、エンタープライズシステムやWebシステムのアジリティが向上している。車載ソフトウェア領域では、OTA（Over the Air）やFOTA（Firmware Update Over the Air）という運用技術の進化により、販売後のシステムアップデートを実現。組み込みシステムのテスト自動化の実践が成熟しつつある。

大規模アジャイル開発を実践するにあたり、さまざまな方法論やフレームワークも存在する。代表的なのは、LeSSとSAFe。ビジネスの成長とともにアジャイルチームが大きくなった場合は、今までのフラットな構造を維持する方がやりやすいので、LeSSを採用する。

一方、最初から大きなプロダクトを開発する場合は、SAFeが向いている。SAFeは経営を巻き込み、最低限の階層構造を持つフレームワーク。賛否両論あるが、朱峰氏は「エンタープライズ企業が変わるためには有用」と語っている。

大規模アジャイル開発の課題、それを解決するアプローチ

大規模アジャイル開発の課題、中でもソフトウェアテストにおける課題は大きく2つある。第一の課題はデリバリーアジリティの維持をいかに担保するか。つまり、テストの生産性をどう上げるかである。

●課題１：デリバリーアジリティの維持

一般的に大規模アジャイル開発においては、サブチームへの開発分割とその成果の統合が発生する。この工程のソフトウェアテストは、チーム単位でのテストに比べ、テストシナリオが複雑で手動テストの割合が増える傾向にあるため、効率的に対処する必要がある。第二の課題はプロダクト価値の追求だ。

「アジャイル開発を進める中で、なるべくドキュメントを書かずに進めるにはどうしたらいいのかという根深い問題がありますが、Whyの共有こそがドキュメント依存文化から脱却する一つの鍵になります」（朱峰氏）

だが、大規模アジャイル開発では各チームの成果が統合されることでプロダクトが完成するため、分業状態にある段階では自分たちのプロダクトが最終的にどう動くのかイメージしづらいという課題もある。

●課題２：プロダクト価値の追究

各開発チームメンバーが、自らのプロダクトの価値を追求することはアジャイル開発の重要なポイント。「メンバーが定期的にプロダクトに触れる仕組みは必要」だと朱峰氏は言う。

いかにデリバリーアジリティが維持できるか。そして自分たちのプロダクト価値をQAチームはもちろん、そのプロダクトに携わっている全員が把握する仕組みを作ることは、解決すべき課題なのである。

この2つの課題を解決するアプローチも紹介された。まずテストの生産性を上げる手がかりとしては、自動テスト実装と保守の効率化。そして、手動テスト設計・管理の効率化である。プロダクトが大規模化すればするほど、テストの自動化が難しくなり、手動テストの割合も増えていくからだ。そのため、手動テストの生産性も上げていかねばならない。

自動テスト実装については、Webやモバイル領域に限られるものの、有償ツールを中心に高度なテスト自動化ツールの活用事例が増えている。コードをゴリゴリ書くのではなく、直感的な画面操作によるテストシナリオの実現が可能であり、テスト資産の運用保守もサポートするツールが続々と登場している。

また規模が大きくなると自動テストの分量も増えるため、そのメンテナンスにも時間がかかってしまう。それを防ぐために、AIによる自動テストのメンテナンスを支援するツールを活用するのも有用である。

一方、手動テストについては、従来開発同様のアプローチでプロセスを効率化することが有用だ。テストケース作成時のテスト設計技法の活用はその一つ。これにより仕様に対する網羅性を確保しつつ、なるべく少ないテストケース数で効率的なテストが実現できる。加えて、テストケースの導出過程が明確になるため、品質に関する説明性も向上する。

「手動テストは、テストの進捗やテスト結果からわかる品質状況の可視化が重要となります。そこでテスト管理ツールを活用し、テストの品質状況の可視化を手間なくシンプルに実現するのです」（朱峰氏）

探索的テストはテスト対象を動作させながら、その場でテスト設計・実行・結果の分析を積み重ねて行う対話型ソフトウェアテストスタイル。重要なのは市場フィードバックに加え、自らが開発しているプロダクトを自ら定期的に使い倒すこと。さらにこれまでの知見をすべてフル動員し、頭の中でリアルタイムに気になる振る舞いをあぶり出すことが重要だ。

ベリサーブが提供するテストプロセス支援ツール

ベリサーブでは、テストプロセスのさまざまな工程を支援するプロダクトを開発・運用している。例えば、手動テストのテスト設計を支援するテスト技法ツール「GIHOZ」は、仕様のモデルをブラウザ上で簡単な操作を行うことで、一定の網羅基準に従ったパターンを抽出。ソフトウェアのインストールも不要だ。

テスト管理をシンプルにするスケーラブルなテスト管理ツールとしては、「QualityForward」を提供している。QualityForwardでは、テストを実行するとリアルタイムでレポートを出力し、テスト状況の見える化を実現してくれる。

まだ世には出しておらず、現在開発中なのが、探索的テストツールだ。プロダクトに触れながら、リスク低減やプロダクト価値の向上についてチームで共有できる支援ツールである。

特徴はテストを失敗か成功でマーキングすることに加え、チームで振り返りを行い、その見解を残せるようにしていること。このような工夫を施すことで、探索的テストを支援できるツールに仕上がる予定だと、朱峰氏は太鼓判を押す。

「アジャイル開発はビジネスリスクを低減するための開発スタイル。その開発手法においてソフトウェアテストがボトルネックにならないためにも、テスト自動化ツールやテスト管理ツールなどの導入が必要です。当社ではさまざまなツールの開発・提供をしているので、ぜひご活用ください」（朱峰氏）

【Q&A】参加者からの質問に答えるセッションを紹介

講演終了後は、参加者からの質問に答えるQ&Aセッションが実施された。

Ｑ．複数人でアジャイルに取り組んでうまくいかなかったこと、その原因と改善するために何か実施したことは何か

一般的なアジャイルは役割を設けずに、1人1人が何でもできることを理想としていますが、大規模にはなればなるほどそれは難しくなります。結果的にテスト専任チームやQAチームを設けることが、多くなります。

そこで大事なのは、テスト専任チームも、普段の開発から関わること。普段から開発メンバーが集まる朝会に参加するなど、情報収集してキャッチアップするようにしています。

Ｑ．グローバルで分散した形での開発における品質管理の運用について

グローバル案件の課題として、よく挙げられるのは時間や言語、文化のずれです。中でも時間のずれを管理するのは大変です。特に手動テストや複数人で作業する場合は、後ろ倒しになってしまうことも多い。手動テストでは、テスト管理を可視化する仕組みを作ることが重要です。「なぜこれをやるのか」をしっかり意識合わせすることも大切です。その上で、しっかりネゴシエーションすることがポイントです。

Ｑ．非機能要件の設計について、品質管理としてはどう取り組むか

パフォーマンスやセキュリティに対する、基本的なアプローチは変わらないのですが、どのようなタイミングや頻度で拡充していくかは重要です。特に難しいのがタイミング。少しずつ大きくなるパターンの場合は、場合によっては作り直しになることも覚悟の上で、パフォーマンスなどは考えずに始めるのが現実解です。

一方、最初から大きなパターンの場合は、最初からパフォーマンスを考える。SREやアーキテクチャなどの専任チームを組成して、事前に作り込んでおくのが最適解だと思います。

Ｑ．探索的テストで個人の習熟度を上げるコツは？

テスト専任テストを中心としたキャリアがないと、プライオリティは上げられないと思います。一つあるとすれば、日頃からプロダクトに対して変な触り方をすること。例えば、スマートフォンに入っているアプリをいろいろといじってみるのはいかがでしょう。

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

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