【2024年版】
DevOpsにおける
テストの
実態調査報告書

企業のDevOpsトランスフォーメーション進捗度の測定にロードマップは欠かせません。組織やチームごとにDevOpsの採用レベルや成熟度は異なりますが、この調査にあたっては、成熟度（採用レベル）を大まかに「DevOpsへ移行予定」「DevOpsへ移行中」「DevOpsをほぼ採用」「DevOpsを完全採用」の4段階に分類しました。

組織が完全なDevOpsの成熟度に達すると、CI/CDの採用、開発パイプライン上のワークフローの大部分もしくは全てが自動化、シームレスなコラボレーションプロセスを構築し、効率的なメトリクスでのパフォーマンスを測定、継続的な改善の基盤の確立が実現した状態となり、これを「DevOpsが完全採用された」と考えます。

DevOpsが出現したのは2009年ですが、まだまだ採用に取り組んでいる状態の組織が多く、DevOpsを完全採用もしくはほぼ採用していると回答した組織は全体のわずか33％のみでした。3分の1の組織がDevOpsへの移行の初期段階であると回答しています。

しかし「（DevOps採用の）組織内における優先順位が低い」と答えた組織はわずか11％だったことから、DevOps採用に向けての組織の姿勢や意欲が進捗を妨げているわけではないことが分かります。

代わりに、DevOpsトランスフォーメーションを遅らせている要因として回答が多かったのは「技術的な限界」と「予算的な制約」でした。また、2024年は、mablがDevOpsにおけるテストの実態調査を開始してから初めて「予算的な制約」を抜き「技術的な限界」がDevOps採用の最大の阻害要因であるという結果が出ました。前回の調査では、82%のチームがDevOps採用が遅れている要因として技術以外の問題を挙げたことを考えると、これは大きな変化だと言えます。

技術的な限界が最大の阻害要因となった背景には、「DevOpsをほぼ／完全採用」したDevOpsの成熟度が高いチームが増えたことにあります。DevOpsを完全採用しているチームのうち「技術的な限界」を最大阻害要因と答えたチームが40％であった一方で、「予算的な制約」と答えたチームは20％にとどまりました。これとは対照的に、DevOps採用の初期段階にある企業にとっては予算が大きな課題であり、DevOpsへ移行予定している企業の約33%にとっても予算が主要な問題であることがわかりました。

DevOpsの成熟度が上がるにつれ、進捗を妨げる要因が予算的な制約から技術的な限界へと変わることから、早い時期にDevOpsツールに投資することの重要性が浮き彫りになります。効果や有用性の低いソリューションを選んでしまうと、DevOps採用を目指す企業の投資収益率は悪化し、DevOps採用プロセスで問題を抱え続けることになります。しかし、DevOps採用に成功した16％の組織のように効率的なDevOps採用を進めたいならば、長期的な成功を視野に入れてツールや機能を選ぶことが必要です。

83％のチームが過去12ヶ月間にデプロイを加速させているということは、「DevOpsにおけるテストの実態調査」から分かった重要な傾向のひとつです。これは、モバイルアプリ開発チームとWebアプリ開発チームのどちらでも見られる傾向で、新しいイノベーションをより早く市場に発表することへのプレッシャーが高まっていることが伺えます。

しかし、依然として大部分のソフトウェア開発チームが「デプロイ頻度の向上が必要である」と感じていることも示されています。回答者の80%が、所属組織のリリースサイクルが毎週もしくはそれよりも長いサイクルであると答えています。これには、同様のデリバリーサイクルを持つモバイルアプリ開発チームおよびWebアプリ開発チームの3分の2を含んでいます。

3分の2のモバイルアプリおよびWebアプリの開発チームにおいて、ソフトウェアデリバリーのサイクルは月1回以下となっています。モバイルアプリの場合、「アプリの更新頻度が低い」また「特定のパフォーマンスやアクセシビリティ、互換性の基準が満たされていない」などの理由でアプリストアからペナルティを受けるリスクがあります。しかし、更新頻度が高いほど、アプリストアの検索ランキングでランクが上がるので、ソフトウェアのデリバリー頻度の高さが競争力に直結します。新規顧客の獲得と既存顧客の維持のために、新機能、重要なセキュリティアップデート、パフォーマンスの改善などをコンスタントに提供できる状況にあるべきですが、現状はその提供能力を十分に持ち合わせない企業が多い状態です。

開発ベロシティの高いチームが少ない背景には「87%ものチームがまだ完全にCI/CDを採用できていない」「回答者の4％がチームの自動化能力についてよく分かっていない」などの開発パイプライン自動化が進んでいない現状があります。

パイプラインの自動化レベルが低い場合、現場やチームにさまざまな影響をもたらします。ひとつは、デプロイ頻度の向上に苦慮する可能性が高いこと。また、自動化が進んでいない場合、作業の負担は増え、従業員の過労やバーンアウト、更には退職などにつながり、結果的に組織全体に悪影響を及ぼす可能性も高まります。適切なスピードで新しい製品を市場に出すにあたって「従業員を増員する」「作業量を軽減するツールを見つける」などの対応をしない限り、人材面やコスト面で大きなロスを生むことになってしまうでしょう。

89％の企業がDevOps採用の成功を優先事項にしているものの、3分の2の企業にとっては課題の残る取り組みとなっています。技術的な限界が課題だとする回答者の数が2022年に比べ44%増えていることから、DevOpsトランスフォーメーションの初期段階にあるチームにとって早い時期に自動化とツールへの投資が重要であることは明らかです。パイプライン自動化が進んでいないということは、開発の合理化を促進しデプロイ頻度を向上する技術へ投資することで競争優位性を強化できる機会があることを示しています。

ユーザーフレンドリーで期待通りに機能するアプリの構築にテストは重要な役割を担っています。しかし、現状は手動テストとレガシーなテスト自動化などに関する問題の対処に追われているソフトウェアテストチームが多数を占めます。

現時点で主要なテスト手段となっているのは依然として手動テストで、74％のチームが手動でソフトウェアをテストしていると答えています。また、過半数（60％）のチームがSeleniumやPlaywrightのようなオープンソースのテスト自動化ツールを使用していることが分かりました。確かな品質のためにテスト自動化に商用ツールを採用している企業はわずか半数以下でした。

モバイルアプリ開発チームも、依然として手動テストに依存しています。これらのチームのほぼ3分の2が品質戦略の一環として手動テスト、56％のチームが自動テスト、約3分の1がサードパーティのデバイスファームを利用していると回答しています。

新機能やエッジケースの探索的テストには手動テストが不可欠なので、手動テストが普及する状態は当然かもしれません。しかし、組織としてのソフトウェアテスト戦略の大部分もしくは全体を手動テストに依存している場合は、デプロイの加速化につれテストがボトルネックとなる可能性が高まります。

自動テストツールに関しては、DevOpsの成熟度が最終段階に達するまではオープンソースツールを活用する傾向があり、DevOpsの採用が進むにつれ、テスト自動化のための商用ツールを採用する可能性が大幅に増加します。

オープンソースツールでのテスト自動化の影響は、開発チームのテスト時間の内訳を見ることで分かります。最も時間を要するテスト作業は、回答者の21％が挙げた「テストメンテナンス」が1位で、次に回答者の19％が挙げた「テスト実行」が僅差で続きました。 

2022年には最も時間のかかる作業の2位で、1位とはかなり差のあった「テストメンテナンス」が、2024年には1位に上昇しました。20％の回答者が、他の作業と比較して、テストメンテナンスにはかなりの時間を要すると答えています。

最も時間のかかるテスト作業は、同時にテストにおける最大の課題でもあり、回答者の3分の1が「テストメンテナンスが最大の課題である」と答えています。これは2022年にメンテナンスがテストにおける最大の課題であると答えた回答者のほぼ2倍となっており、デプロイ頻度が加速化するにつれ、自動化テストの安定性と信頼性の低さが問題となることが浮き彫りになりました。

テストにおける最大の課題としてメンテナンスが1位に上昇したということは、DevOps成熟度の高いチームにおいて、テストへのコラボレーションレベルが向上、テストツールへの投資が増加、「技術的な限界」がDevOps採用の阻害要因として認識されていることを示します。自動テストツールへの投資が増加していることからも、DevOpsトランスフォーメーションにとってのソフトウェアテストとテスト自動化は明らかに重要と言えます。それと同時に、テストメンテナンスが持続的に管理されない限り、不具合のあるテストによってデリバリーサイクルが遅れ、チームがその潜在能力をフルに発揮できなくなるリスクが大きくなります。

これらの変化をまとめると、DevOpsチームが全員をテストに参加させる品質文化を受け入れていることを示すものであり、DevOpsを完全採用しているチームの全員が品質に関わる役割を担っていると報告する傾向が最も高いということが分かります。DevOpsを完全採用しているチームの約3分の1が、テストは組織全体で共有される活動であると回答しているのに対し、DevOpsをほぼ採用しているチームまたはDevOpsへ移行中のチームの約5分の1が、テストは組織全体で共有される活動であると回答しています。 

DevOpsを完全採用しているチームは、QA担当者、手動テスター、自動化エンジニア、ソフトウェアエンジニアからのテスト貢献が増加していると報告しており、DevOpsの成熟度とともにテストのニーズとテストコラボレーションが増加していることを示しています。

これらの異なるグループのテストニーズや関心は、それぞれの専門分野と同様に、大きく異なります。したがって、これらの多様なニーズに対応するためには、多様なテストツールのセットが必要となります。

DevOpsを完全採用しているチームにおいては、テスト作業に関わるメンバーの増加と、テストツールへの投資の増加が比例しています。テストツールを使っていない回答者は合計5％と非常に少なく、テストツールを1つしか使用していないと答えた回答者も、移行予定のチームもしくはほぼ採用のチームで8％、移行中のチームで7％、完全採用のチームで6％と非常に少数でした。多くのチームが十分なテストカバレッジを維持するのに苦慮しており、予算の制約と技術的な限界によってDevOps採用が進まない状況においても、過半数の58%が3つ以上のテストツールを使っています。ソフトウェアテストはDevOpsの成熟において重要であることは明らかですが、テスト技術スタックの複雑化がDevOpsにおけるテストの根本的な問題解決を難しくしています。

チームが使用するテストツールが3つ以上にすると、「DevOpsを完全採用しているチームほど使用するテストツールが多くなる」というパターンが見えてきます。完全採用をしているチームの実に4分の1（26%）が5つ以上のツールを使用しており、4つ使用しているチームは12%、3つ使用しているチームは31%となっています。

テスト技術スタックの増大はDevOpsにおけるテスト管理の複雑化を意味します。DevOpsチームには、前述したように、あらゆるレベルの役割やスキルの人が使うことのできる自動テストツールはもちろん、機能品質と非機能品質、複数のデバイスとブラウザ、さらにAPIも検証する必要があります。多方面をカバーするテストは不可欠ですが、テスト技術スタックが増えると、コストの増大やサイロ化のリスク、オンボーディングも増えることになります。テストはDevOpsの成熟度にとって優先すべき事項ですが、無駄な重複作業や不要なコスト、ワークフローのサイロ化を避けるにはどんな自動化テストツールが有効なのかよく検討することが必要です。

テストツールによる影響力を考えれば、調査回答者の過半数が、品質へのアプローチを改善するために、新しい自動テストツールに投資する予定であると回答したことは当然と言えます。

限られた予算の中でも企業が新しいテスト自動化ツールへの投資をしていることから、DevOps採用への道のりにおけるテストツール改善の重要性、企業のテストに対する姿勢が分かります。DevOpsへ移行予定のチームは新しいソフトウェアテストツールを採用する可能性が高く、48%が近い将来に新しいツールを購入する計画を立てています。この傾向から、これらの組織がテスト技術スタックを業界標準に近づけることを優先していると示されています。

適切なテストツールは幅広い品質に関する課題に対応することができることから、組織が新しいテストツールに積極的に投資をしている理由が分かります。

新しいテストツールは、組織内のQAチームや開発チームが手がける幅広い種類のテストをサポートするためにも不可欠です。2024年DevOpsにおけるテストの実態調査では、外部委託せずに、内部でテストの計画や実行を手がける組織が大半であることが分かりました。

Webアプリとモバイルアプリ、機能テストと非機能テスト全体にわたって、より多くのテスト戦略タスクを内部で処理していることが分かりました。以前の調査結果ではQAチームの61%が何らかの形で外部委託していたので、大きな変化と見なせます。アクセシビリティテストやパフォーマンステストのような特殊なテストでさえ、大部分が内部で処理されており、組織がDevOps採用にあたり内部での能力向上やスキルの向上に重点を置いていることが分かります。

おそらくAIほど急速に不可欠な技術となったものはないでしょう。AIは未来的な好奇心から必須の能力へと急成長しました。

約80％のチームが開発プロセスにAIを採用し始めており、開発チームやQAチームの60％が「一部／フル活用している」と回答しました。DevOpsを完全採用しているチームでは、76%という高い割合でAIを活用しており、DevOps成熟度の高さが継続的な技術の進歩と適応のための基盤となっていることが分かります。

AIがソフトウェアテストにどのように適用されているかは、DevOpsの成熟度とパイプラインの自動化レベルによって異なることが分かりました。AIの活用状況は、パイプラインの自動化レベルに大きく左右されているようです。完全に自動化されたパイプラインを持つ組織ではテストサマリーの作成に、DevOpsを完全採用しているチームではテストケース生成にAIを活用する傾向が強いです。

意外にも、テスト分析が最も時間を必要としない作業として考えられているにも関わらず、テストサマリーの作成にAIを活用しているチームが多く、またテストケース生成にAIを活用しているチームでも、最も負担が大きいテストメンテナンスやテスト実行などの作業には活用していないようです。

このことから、DevOpsにおけるテストのボトルネックに対応するためのツールとして、新しいテクノロジーであるAIはまだ進化の途中であることが伺えます。

最後に、テストツールの数が増え、AIの機能が急速に進化しつつある状況の中で、「DevOpsチームは開発パイプラインのどのタイミングでテストを実施しているのか」という点を考えることが重要です。

機能テスト、エンドツーエンドテストのどちらも開発全体プロセス全体にわたって実施されますが、それぞれが実施されるタイミングには大きなばらつきがあります。ほとんどのチームが、開発パイプラインの初期段階であるコーディングの段階（52％）やプルリクエストの段階（41％）で機能テストを行っています。これらは主にユニットテストや統合テストであると考えられます。一方、エンドツーエンドテストは開発のデプロイ段階で実施される可能性が高いことが分かりました。

開発プロセスの後半に発見される問題の数は、Webアプリとモバイルアプリにわたるテストカバレッジが低いチームの数に関連していると考えられます。テストカバレッジが60%未満であると答えたWebアプリとモバイルアプリの開発チームは67%、テストカバレッジが20%未満であると回答したチームは5チーム中1チームの割合でした。

テストカバレッジに関する課題は、非機能テストではさらに深刻であることが分かりました。モバイルアプリ開発チームについては、 73％が非機能テストカバレッジは60％未満であると答え、約25％がカバレッジは20％未満であると回答しています。また、Webアプリ開発チームにおいても、71％が非機能テストカバレッジは60％未満であると答え、25％がカバレッジは20％未満であると回答しています。

非機能テストのカバレッジが十分でない場合、エンドユーザーにとって非常に使いにくいアプリとなってしまい、最終的にユーザーが使用をやめてしまうというリスクが高まります。レスポンスタイムが1秒遅れるごとにウェブコンバージョンは7％減少し、53％のユーザーが「ページの読み込みに3秒以上かかるモバイルサイトは使わない」と回答しています。同様に、動作の遅いアプリは使わないと答えた人たちは45％にものぼり、アプリの品質がビジネスへ悪影響を与え、結果的に消費者のブランド離れにつながることが示されています。また、政府関連、消費者向けの小売、ヘルスケアなどの分野ではとりわけ、アクセシビリティテストが不足すると、訴訟や罰則の対象となるリスクが高まります。

GoogleもAppleもアプリストアに登録したアプリに対してアクセシビリティとパフォーマンスの基準を設けています。つまり、効果的な非機能テストはモバイルアプリにとって非常に重要なのです。要件を満たさないアプリには、アップデートが遅れたり、ストアの検索結果に悪影響が出たり、アプリストア自体から削除されたりするなどさまざまなリスクが生じます。

開発プロセスの後期段階での不具合発見は、デプロイ頻度やDevOpsの成熟度を左右する大きな問題となり得ます。とりわけ、パフォーマンスが中程度の開発チームのほとんど（53％）が、デプロイの修正に最低1日を要し、問題への対応に平均11.12時間（1日半）かかると答えています。これはDORAが定義する中間的なパフォーマンスと大差ないのですが、毎週または毎日デプロイする場合には、11時間の遅れは決して小さくありません。 

不具合への効率的な対応とDevOpsプロセスの成熟に重要なのは、組織内の複数部門でコラボレーションできる能力であり、これはQAと開発者の間で適切なハンドオフ（連携）ができるかどうかにかかっています。2024年版DevOpsにおけるテストの実態調査では、開発チームの43%がハンドオフプロセスを改善する必要があると答えています。

不具合の48％がデプロイ段階、特にモバイルアプリ開発においてはWebアプリ開発よりも比較的プロセスの早い段階で発見されます。しかし、QAチームと開発チームがうまく連携できていないと、せっかく不具合を早期に発見しても、結果的にその恩恵を得られないというリスクが発生します。

2024年4月、mabl Japanでは独自にmablのユーザーの皆さまへアンケートを実施しました。このアンケートは、mablの導入によって得られた効果を中心に構成されており、実際にテスト業務に携わるエンジニアだけでなく、テストの業務効率化を目指すビジネスパーソンや意思決定者にとって、特に有益な情報が含まれています。

約30社、40名程から得られたアンケート結果によると、回答者属性は71%超がQAチームに所属、38％がマネージャー職、導入して1年以上が約75%程の割合となっています。

61%が手動でのテスト対応を行っていると回答しています。テストの課題として、テストの実行や作成/実装や修正/保守の問題が上位を占めていることから、既に手動での対応はオーバーフローを起こしている状況と理解できます。テスト作成自体は約半数をQAが担当し、次いで開発者や外部委託が25％ずつと回答しています。手動以外のテスト方法として、スクリプトツールの使用が20%強ですが、メンテナンスなども考慮すると、手動テストと同様の課題が解決できない状態にあると推測できます。

mablの導入以後、テストの並列実行、テストの再利用性、ノーコードでの容易な作成やカスタマイズ、APIテストに対して高い満足が得られており、効率的なテスト作成が可能になったことで、テスト作成工数が31％以上削減されたとの回答がありつつも、一方でテスト実装に関わる人数が減ったとの回答は約17％となり、34％以上は増えたと回答しています。後述しますが、これはテストを効率化しつつも品質の向上に向けて更なる取り組みを行っていることを表しています。

テスト実行において、mablの導入により実行頻度が2.5倍向上し、少なくとも26%以上の削減が見られたと回答した方が全体の半数以上（54％超）を占めています。プラットフォームを使いこなすことで効率的なテスト実行が実現し、テストプロセスがスムースになっていると言えます。

mablを使用するにあたり、約半数のお客様がアドホック実行やスケジュール実行を駆使し、テストプロセスの改善に努めています。さらに23％のお客様は、既に開発パイプライン上でmablを使用しており、シフトレフトを進めていることが明らかとなりました。また、並列実行やローカル/クラウド実行の柔軟性、様々な実行トリガーに対する満足度が90%以上に達しています。

mablの導入により、テスト修正工数が少なくとも26％以上改善されたと回答した割合が51％を越えています。先のアンケート結果と組み合わせると、テスト実装に関わる人数を増やしながらも、修正や保守の工数削減を実現させていることから、より効果的に品質向上の達成に向けた取り組みができていることを表しています。

リリースサイクルにおいて、88%以上のお客様がテスト情報の把握が容易になったと回答し、次いで45%以上のお客様が不具合の把握が容易になったと回答しています。一般的にウォーターフォール開発ではプロジェクトの後半にテストを通じて様々な不具合が明らかになり、多くの場合でWBSを引き直し工期の遅れが初めて可視化されがちですが、シフトレフトを進めているプロジェクトやチームは、このように早期にテストや不具合の状況を把握し、最小の工数で改善に向けて取り組むことができます。