アジャイル開発の本質とは

現代はVUCA（変動性、不確実性、複雑性、曖昧性）の時代と言われます（図表1）。社会の仕組みが複雑化するのに伴ってITシステムも複雑の度を増しています。しかも先行きが不透明なため、わずか数年後のビジネスニーズさえ予測することは困難です。このような時代において求められるのが、価値あるソフトウェアを素早く提供することを原則の１つとしているアジャイル開発です。

従来の大規模プロダクト開発では、「最初にしっかりとした計画を立て、数年かけて作る」というスタイルが一般的でした。しかし、現代のように価値変動の大きい時代に、例えば2～3年もの歳月を開発に費やしていては、世の中の需給スピードに対応できません。また、大規模なものを作るということは、それだけビジネスリスクも大きくなることを意味します（図表2）。

これに対して「小さく作って小さく失敗しよう」と考えるのがアジャイル開発です。短い時間で小さく作れば、失敗したとしても影響は小さくて済みます。失敗は開発現場にフィードバックし、また小さく作る。これを短いスパンで繰り返すことで損失を限定的にする。
単に「小さく作る」だけではなく、ITビジネスリスクを小さくとどめながら世の中の変化にも追随し、結果としてより早く、価値の高いプロダクトを実現する。これがアジャイル開発の本質です。アジャイル開発は不確実な時代に適した開発スタイルと言えるのです（図表2）。

進むアジャイル開発の大規模化

欧米企業を中心に、近年、アジャイル開発の規模の拡大が進んでいます。米IT企業Digital.ai社は、1年に一度、世界の技術者を対象としたアジャイル開発のトレンドに関する調査レポートを公表しており、2021年版となる「第15回 State of Agile Report」によると、アジャイル開発実践企業のうちの約7割が、後述するようなフレームワークを用いて、複数のアジャイル開発チームによる規模の拡大を実施していることが分かります（図表3）。規模の拡大の程度はまちまちで、2チームという小さな規模のものから1000人規模で取り組むケースまであることが、このレポートからはうかがえます。

アジャイル開発の大規模化を支える技術

アジャイル開発の大規模化が進む背景には技術の進化があります。例えば、エンタープライズ領域では、サーバーサイドのアジャイル化を支える多数の新しい技術が出てきています。マイクロサービスアーキテクチャと呼ばれるシステム設計アプローチもその1つです。これは、プロダクトを細かなサービスとして分割して設計し、それぞれを専任のチームがスピーディーに並列開発をしていくというものです。また、こうしたアーキテクチャをサポートする「Docker」に代表されるコンテナ技術^※1 や、複数のコンテナを運用していくために「Kubernetes」といった基盤が進歩してきたことも、アジャイルの大規模化を支えています。

※1：１つのコンピューターを仮想的に区画分けして、複数の独立した環境でアプリケーションを動作させる技術。区画ごとにゲストOSを設ける仮想化技術とは異なり、ベースのOSの機能を用いて動作するため、より少ない資源で多くのアプリケーションを動作させることが可能となる。

大規模アジャイルのフレームワーク

企業規模に合わせてアジャイルを拡張するための体系的な方法論やフレームワークも、昨今ではさまざまなものが登場しています。その代表例である「LeSS」と「SAFe」を紹介しましょう。

（1）LeSS

LeSSはLarge Scale Scrumの略です。アジャイル開発のプラクティスの1つである「スクラム」をベースに、チーム数を増やすことで大規模化しようというのがLeSSの基本的な考え方です。大きなものを小さなチームで作ろうとする場合は「要件を小さく分解する」必要があります。
LeSSでは、プロダクトを複数あるチームの数に合わせて分解し、個々のチームが協調しながらスクラム開発を進め、最終的に成果を組み合わせてプロダクトを完成させます（図表4）。

（2）SAFe

SAFe（Scaled Agile Framework）もまた、複数のアジャイルチームがプロダクト開発を行うときに利用するフレームワークです。LeSSとの共通点も多いのですが、企業の事業ポートフォリオをどのように加味するか、また投資計画とどのように整合させていくかなど、プロダクト開発と経営戦略の連動の仕方にまで言及している点に特徴があります。そのため、大企業が大規模アジャイルを取り入れる際により好まれる傾向があるフレームワークです（図表5）。

大規模アジャイル開発におけるソフトウェアテストの課題

ここからは、大規模アジャイル開発を実践する上でのソフトウェアテストの課題と、その要因について見ていきます。

LeSSの項で触れたように、大きなものを複数のチームで作るには、要件を「分割」し、それぞれのチームが作ったものを最後に「統合」する方法が一般的です。この、アジャイル開発の大規模化に伴って生まれる2つの新たな作業工程のうち、ソフトウェアテストという文脈では「統合」が特に重要になります。個々のチームで開発したものをそれぞれテストするのとは異なり、統合したものがきちんと動くかを検証しなければなりません。この新たなテストがボトルネックになると、アジリティの低下につながります（図表6）。これが、大規模アジャイル開発におけるソフトウェアテストの課題です。

ボトルネック化を招く要因は大きく分けて2つあります。
1つ目は、大規模アジャイル開発では手動テストのボリュームが増えることに加えて、自動テストも実施しなければならないことです。システムが統合されるとテストシナリオは複雑になり、自動化が不可能な箇所について手動テストのボリュームが増えます。また、開発チーム単位で行うテスト自動化は開発技術に長けた人たちが行うためスムーズに進みますが、統合の工程では基本的にテストがメインとなるため、必ずしも開発に長けた人たちをアサインできるとは限りません。開発力が相対的に低いチームでも、テストを自動化しながら手動テストも効率的に行う必要があります。

2つ目は、分業化によってチームメンバーのプロダクトへの理解度が低下することです。アジャイル開発においてアジリティを担保するものの1つに「チームの自律性」があります。企画から開発に至るまでチーム全員が同じマインドセットを持ち、目指すべきゴールを共有するのがアジャイル開発の原則であり、これによってチームの自律性を保ち、アジリティを高めます。

ところが、チームが大きくなると必然的に分業が発生し、各アジャイルチームはプロダクト全体の一部しか触れないことになります。その結果、自分たちが作るプロダクトが最終的にどういう振る舞いをするのか、どのようにユーザーに使われるのかをイメージしにくくなり、チームの自律性は発揮しづらくなります。体制を拡大する際は、プロダクトの全体像をどのようにして把握するかについても検討していく必要があります（図表7）。

大規模アジャイル開発を加速させるソフトウェアテストの工夫

ここまで見てきた大規模アジャイル開発の課題とその要因に対し、どのような解決方法があるでしょうか。ここでは、自動テストの効率化、手動テスト設計・管理の効率化、探索的テストの活用という3つのポイントを紹介します。

自動テストの効率化

ここ数年、自動テスト実行ツールが急激な進化を遂げ、実用化が進んでいます。とりわけ、AIによる支援を備えているツールの進化は顕著で、大規模プロジェクトでテストを実行する場合は、これらの活用が推奨されます。 これら高度な自動テスト実行ツールの代表的な機能として、「テスト実装支援」と「オートヒーリング」が挙げられます。通常、テストを実行するには、あらかじめテストシナリオを作成する必要があります。テスト実装支援では、GUIによる直感的な操作でテストシナリオの作成が可能になり、プログラムのコーディングがさほど得意でなくても、自動テストのテストケースを実装することができます。
一方、オートヒーリングは、開発とともに進化していくプロダクトに対して、どのような変更が生じたかを検知して、自動でテストシナリオを進化させていく機能です。こうした機能を備えた自動テスト実行ツールを活用することで、チームメンバーのスキルを総体的に底上げしたり、増加する一方の自動テストに関してメンテナンスを効率化したりする効果が得られます。

手動テスト設計・管理の効率化

手動テストを効率化するには、従来型開発で採用していたテスト設計技法の活用が重要なポイントとなります。また先述したように、アジャイル開発ではアジリティを担保する上でチームの自律性が求められます。そこでは誰かの指示によって動くのではなく、開発メンバーがそれぞれの判断に基づいて能動的に活動すること（自己組織化）が重要視されます。そのためには透明性の向上、すなわち状況の見える化が欠かせません。テストケース設計ではテスト設計技法を活用し、またテストの進捗・品質管理の透明性向上についてはツールを使って可視化することが推奨されます。

それぞれ具体的に説明しましょう。まずテスト設計技法について、２つ例を挙げます。

1つはデシジョンテーブルという手法です（図表8）。ビジネスルールに基づき、自然言語で書かれることの多い仕様書について、内容を表形式に整理することで必要十分な（網羅的で、より少ない）テストパターンを割り出し、説明可能にするテスト設計技法です。

もう1つはペアワイズ法です。テスト時に考慮すべきパラメーターや組み合わせのバリエーションが膨大になることは、テストエンジニアにとって大きな悩みの種です。こうしたテストケースを絞り込むのに有効なのがペアワイズ法です。図表9は、携帯電話の着信音のテストを例にとったもので、設定項目とオプションの組み合わせが全81パターンあるところ、ペアワイズ法を活用することで説明可能な根拠^※2 に基づき、テストパターンを９つに絞り込むことができます。

※2：図表9の場合、着信音、待ち受け画面の2つの設定については組み合わせを網羅し、かつ、他の設定においても全てのオプションのテストが一度は実施されるような最小の組み合わせとなる。

透明性の向上に関しては、ツールベンダーから多くのテスト管理ツールが提供されており、さまざまなアプローチでテストの状況を可視化することができます。図表10のように、収束曲線グラフを通してテストの進捗やバグの出方、今どの機能にどれだけバグがあるかなどを可視化してくれるツールや、システム全体の品質状況を一目で見渡せるツールなど、有用なものが多数ありますので、ぜひ活用していただきたいと思います。

探索的テストの活用

開発チームの全員とプロダクトの価値を共有するには、探索的テストの活用をお薦めします。探索的テストは従来型のテストとは異なり、テストケースを作らずにその場で触りながら気付きを得ていく新しいタイプのテストです。例えば、自チームで開発した機能以外も含めたプロダクト全体を、2週間に1回など定期的に動作させる時間を設けることが有効です。プロダクトをさまざまな視点から徹底的に使ってみることで気になる振る舞いをあぶり出し、プロダクト価値向上につなげることができます。

おわりに

現代のような不確実性の高い時代には、ユーザーに素早く価値を提供することに主眼を置き、アジャイルでプロダクトの開発を進めていくこと、高いアジリティを維持しながら大規模なシステム開発にもアジャイルを適用すること、それによって機会損失によるITビジネスリスクを軽減することが求められます。そのため、ソフトウェアテストの領域においてもさまざまな工夫が求められます。テストがボトルネックにならないよう、自動テスト、手動テスト、探索的テストの導入といった３つのポイントから取り組むことで、大規模アジャイル開発を一層加速させることが可能になります。テスト技法やテスト管理についてはベリサーブも支援ツールを提供しています。こうしたツールもご活用いただき、皆様のビジネス価値の向上に少しでも寄与できれば幸いです。

この記事をシェアする