本記事では、2025年7月8日に開催されたイベント「チームのテスト力を総合的に鍛えてソフトウェア開発の高品質と高スピードを両立させる実践技法」の内容をお届けします。イベントでは、『ソフトウェアテスト徹底指南書 〜開発の高品質と高スピードを両立させる実践アプローチ』の著者である、井芹 洋輝さんにご講演いただきました。イベント当日に回答しきれなかった質問についても、本記事にてご回答いただきました。ぜひ本編のアーカイブ動画とあわせてご覧ください。
井芹：本日は「チームのテスト力を総合的に鍛え、品質・スピード・レジリエンスを共立させる」と題し、お話しします。
私はこれまで開発者、テストエンジニア、コンサルタントとして様々なテスト業務に従事し、現在はトヨタ自動車でQA／テストのテックリードを務めています。社外ではJSTQB技術委員や、テスト設計コンテストU30クラスの初代審査委員長も担当しています。
継続的な開発に必要なのは、“品質、スピード、レジリエンスの共立”
なぜ今、品質・スピード・レジリエンスを共立させる必要があるのか。その背景となる、近年のソフトウェア開発を取り巻く状況変化からご説明します。
現在の大きな傾向として、SaaSやWebサービスに代表されるようにプロダクトの形態が「サービス化」しています。これはパッケージや組み込みの世界でも同様で、リリース後も継続的なアップデートで価値を提供することが一般的になりました。自動車業界でも、テスラのように高頻度なアップデートで顧客満足度を高める手法が広がっています。
このサービス化により、開発ライフサイクルも長大化しています。一度リリースして終わりではなく、継続的な改善によってプロダクトが長く成長し続けるためです。こうした環境での激しい競争を勝ち抜くため、開発のアプローチも変化しました。
従来は、案件ごとにプロジェクトチームを編成し、リリース後に解散する「プロジェクト型」が主流でしたが、継続的な改善が求められる現在では、同じチームがプロダクトを運用・改善し続ける「チーム型」へ移行しています。それに伴い、優秀な人材を都度集めるのではなく、チーム自身の開発力を継続的に高め、プロダクト価値を支え続けることが重視されるようになっているのです。
スピードとレジリエンスの重要性とは？ — 顧客満足を加速する開発力
こうした開発様式の変化を受け、近年は品質確保を大前提としつつ、スピードとレジリエンス（問題やストレスに対する適応力・回復力）を合わせた総合力が重視されています。
まず、スピードとビジネスの関係ですが、開発スピードは、言うまでもなく顧客満足に直結します。スピードが速ければ、ユーザーのニーズや不満に迅速に対応でき、挑戦的な機能開発といった試行錯誤の回数も増やせます。さらに「開発→デプロイ→市場の評価→改善」というフィードバックループを高速で回し、ビジネスを素早く成長させることが可能です。
逆にスピードが遅いと、有限なリソース（人員・時間）を浪費して、品質に割くべきリソースまで削ってしまいます。試行錯誤の機会が減って挑戦もできず、フィードバックループの鈍化で顧客満足も遠のく、という悪循環に陥りかねません。
つまり、現代の開発においてチームのスピードは品質と不可分であり、顧客満足に直結する重要な要素なのです。
レジリエンスも同様です。チームのレジリエンスが高ければ、障害やユーザーの不満を即時に解消できます。また、対応できるリスクの許容度が上がるため、挑戦的な開発を通じてプロダクト価値をさらに高めることも可能です。
逆にレジリエンスが低いと、障害発生時の復旧が遅れてユーザーの不満が解消されず、リスクを伴う挑戦も避けがちになります。
ここで注意したいのは、チームの能力としてのレジリエンスとプロダクトの品質は、開発者側では別物でも、ユーザーの目には同じに見えるという点です。例えば、障害からの復旧が遅いと、それは単に「品質が低い」と見なされてしまいます。
このように、品質とレジリエンスはもはや不可分であり、レジリエンスそのものが顧客満足に直結するのです。
DORA指標が示すデータでの相関性
スピードとレジリエンスの重要性は、客観的なデータからも裏付けられます。Googleの研究組織DORAが提唱[1]する、ビジネスパフォーマンスと強い相関を持つ4つの指標を見てみましょう。それは、変更要求からリリースまでの速さを示す「変更のリードタイム」**、**リリースの頻度である「デプロイ頻度」、変更が失敗する割合の「変更失敗率」、そして障害発生から復旧までの「障害復旧時間」です。
この調査によれば、ビジネス競争力が高い「エリート」組織は、変更のリードタイムを1日未満で収め、デプロイも高頻度で行い、障害が起きても数時間で直してしまうなど、スピードとレジリエンスの両面で際立っています。
対照的にパフォーマンスが低い組織では、変更の適用に1か月以上、デプロイは月に1回程度、障害復旧にも1週間以上かかってしまいます。
このデータが示すように、現代の開発ではスピードとレジリエンスがビジネスの成否に直結します。だからこそ、品質、スピード、レジリエンスを高いレベルで共立させることが不可欠なのです。
品質、スピード、レジリエンスを共立させるテストアプローチ
ここから手段に入りますが、まず本講演で最もお伝えしたい核心的なメッセージを共有します。それは「チームのテストを考える際、品質・スピード・レジリエンスをトレードオフではなくトレードオン、すなわち同時に高めるアプローチを取る」という考え方です。
テストでは、スピード等を犠牲にして品質を高めるトレードオフに陥りがちですが、そのアプローチはビジネス上のリスクを招きます。だからこそ、この3要素を高いレベルで「共立」させることが不可欠なのです。
テストのアプローチには、3要素を「トレードオフ」の関係にするものと、同時に高める「トレードオン」の関係にするものがあります。
現場によっては、トレードオフのアプローチを推進してしまう場合があります。例えば、「品質ゲートの重厚化」として最終テストの量や期間をひたすら増やすアプローチ。これはバグを多く見つける代わりにスピードとレジリエンスを犠牲にし、結果的に顧客満足を損ないます。
また、独立性の高い第三者検証チームにテストを丸投げするのも同様です。チーム間のコミュニケーションロスが開発の遅れを招き、ビジネスを停滞させてしまいます。これらは一部の価値のために他を犠牲にする、トレードオフのアプローチです。
トレードオン戦略 — 開発チーム全体でスピードと品質を共立する
では、品質・スピード・レジリエンスをトレードオンで実現するアプローチとは、具体的にどのようなものでしょうか。それはチームの総合力を高めるというものです。
テスト担当者だけの工夫には限界があります。開発者もテストに協力するなど、チームの開発力を総合的に高める必要があり、それによりトレードオンを実現できます。
例えば開発チーム全体で協働関係を構築するアプローチがその一つです。開発でテスト容易性を含めた保守性を作りこみ、チームのテストを効率化する、といったものです。また開発・テストを含めたチーム全体を顧客満足に向けて方向づけして、無駄のない開発活動を推進するといったものが該当します。
実践編 - 3つのプラクティス
今回は、品質・スピード・レジリエンスを共立させるための、特に取り入れやすいプラクティスを3つご紹介します。
- 開発者テストの充実
- テスト容易性の充実
- Wモデル／テストファースト
開発者テストの充実
まず、テストの責務をなるべく開発者の手で果たすアプローチです。具体的には、テストピラミッドの考え方に従い、開発者がユニットテストや統合テストを厚く実装することで、品質確保の「シフトレフト」を促進します。ここで重要になるのが、プログラマーが自分のコードに責任をもって自分のコードに自動テストを書くことを習慣化し、CI/CDに組み込んでチームの資産とすることです。
このアプローチは、スピードとレジリエンスを大きく向上させます。
スピード向上
バグの修正コストは、発見が後工程になるほど増大します。開発者テストで早期に問題を発見・修正できれば、この手戻りコストを削減できます。また、自動テストが充実すればリグレッションテストが容易になり、開発者は安心してコードの追加・変更に臨めるため、追加変更の作業が高速化します。
レジリエンス向上
自動テストが充実していると、リグレッションテストが効率化され、開発のデバッグ容易性が高まります。また自動テストが維持されていれば、その対象範囲内でテスト容易性が確保されます。このデバッグ容易性やテスト容易性は、問題の解析・修正をサポートし、チームのレジリエンスを支えます。
テスト作成の習慣化に向けたアプローチ
この開発者テストの充実を成功させるのに重要になるのが、開発者が開発と並行してテストを書く習慣を定着させることです。
開発者テストの習慣化は次の3方向で改善を進めます。
習慣の定着
まず習慣を定着させるため、納得感のあるガイドラインやプロセスを示し、チームにあるべき開発者テストの姿を示します。そこでは、具体的なプログラミング手法としてTDD（テスト駆動開発）や、より手軽なCover & Modify（変更箇所を先にテストで保護する手法）を奨励し、プロダクトコードとテストコードを同時に書く流れを自然に作ります。
なお開発者テストを書く作業は細かな実装の総合力が求められます。テストを書くタイミング、プロダクトコードとテストコードの開発環境の切り替え方、良いテストの書き方といったものです。こうしたテスト実装の総合力をチームに広めるにはペアプログラミングやモブプログラミングが有効です。
また、開発者テストを書く習慣を定着させるには、書いたテストはCI/CDに組み込むことで、開発者テストをチームの資産として継続的に生かし続ける工夫も重要になります。
短期サイクルでのフィードバック
次に、習慣定着に対してすばやいフィードバックを提供して、改善サイクルを回します。この手段として、プルリクエストレビューでテストコードの有無や質を確認したり、コードカバレッジの推移を監視してテスト不足を検知したりするのが効果的です。
また、手間がかかるため常に実行できる手段ではありませんが、意図的にバグを埋め込んで自動テストの有効性を測るフォールトインジェクションやミューテーションテストによる「テストのテスト」を行えば、テスト自体の信頼性を確認し、習慣が正しく定着しているかを確認できます。
中長期サイクルでのフィードバック
そして中長期サイクルで、本当に習慣が定着し効果を出せているかを確認・是正していきます。この手段として、反復開発で前の反復からのバグの流出を分析してテストがバグを見つけ出しているか評価したり、市場の障害に基づいてテストが適切か評価したりして、開発者テストの習慣が適切に効果を出せているか確認・是正します。
テスト容易性の充実
次に、プロダクトの「テスト容易性」を高めるアプローチです。これは、コードや設計に「テストのしやすさ」を組み込むことで、品質・スピード・レジリエンスのトレードオンを実現する手段となります。
テスト容易性は、以下の品質特性で構成されます。
こうした「テストのしやすさ」を設計段階から実装することで、テストの実装・実行・保守のすべてが高速化します。その結果、デバッグ、障害対応、機能開発といったテストが絡む開発活動のスピードとレジリエンスが向上し、3要素の共立に大きく貢献するのです。
テスト容易性を高めるアプローチは、大きく2つに集約できます。
開発初期から、テストしやすいアーキテクチャを設計に組み込む
アーキテクチャの例としては、疎結合・高凝集な設計の推進が挙げられます。リスクの高い機能を特定のコンポーネントに分離・集約すれば、その部分のテストを重点的に行うことで、開発全体の品質とスピードを両立できます。
早期からテストを実行し、テスト容易性の問題を素早く発見・改善する
早期実行の例としては、テストファーストが有効です。先にテストを書くことで、設計・実装をテストしやすいものに誘導できます。
また、作りかけでも動かせるウォーキングスケルトンなどを活用して早期から自動テストを回すことで、テストしにくさに早期に気づけ、その是正を早期着手できます。
Wモデル・テストファースト
これは、仕様定義、設計と並行してテスト活動を行うアプローチです。このアプローチとしては、次のWモデルとテストファーストがあります。
- Wモデル：要求定義や設計などの各開発工程と並行して、テストの分析・設計も行う手法。相互にフィードバックをかけながら進めます。
- テストファースト：その名の通り、先にテストを書き、それを通すプロダクトコードを後から書く手法です。
前者は「一緒に」、後者は「先に」という違いはありますが、いずれも仕様段階から「テストのしやすさ」を組み込むためのプラクティスです。
例えば、「検索履歴の呼び出し」というユーザーストーリーを考える際、Wモデルでは仕様作成段階からテスト分析を進めます。「履歴件数の境界値は？」「詳細なUI仕様は？」「セキュリティ要件は？」といった点を仕様作成中にフィードバックすることで、最初から不具合を予防し、テスト容易性を確保できるようになります。
まとめ
今回ご紹介した内容は、先月出版した『ソフトウェアテスト徹底指南書』から抜粋したものです。
本書は、QAエンジニアだけでなく、開発チーム全体に求められるテスト力を総合的に解説した一冊で、テスト戦略から自動テスト、マネジメントまで幅広く扱っています。本日の講演も本書から内容を抜粋したものですので、ぜひお手に取っていただけると幸いです。
以上で講演を終わります。ご清聴ありがとうございました。
Q&A
イベント当日に触れられなかったご質問にも回答いただいています
Q. 開発者が“テストしやすさ”を考慮してコードを書くのは難しそうですが、客観的な指標はありますか？CIのように自動で検査できないのでしょうか？
A. テスト容易性を直接的にズバッと示せる完璧な指標はありません。計測の手間、効果のバランスをとって、現実では以下の2つを組み合わせて評価することが多いです。
①コードカバレッジ：ただし、単体では不十分なので他の情報と組み合わせて使用します。
②バグ流出率：スプリントを回している場合、前スプリントから流出したバグのうち、「本来ユニットテストで検出すべきだったバグ」の件数を追います。
改善フェーズでは、有識者によるチェックポイント制のレビューを設け、テストケースに抜け・ムダがないか、エッジケースが網羅されているかを点数化する方法も有効です。総合的な定量化をしたい場合は、テスト実行時間、インターフェースのパラメータ数、サイクロマティック・コンプレキシティといった指標を複数組み合わせて評価する形になります。
Q. TDD（テスト駆動開発）を実現するには、要件定義が明確であることが前提ではないでしょうか？
A. それは誤解で、要件定義が固まっていなくてもTDDは可能です。ユニットレベルの仕様が見えていれば十分に進められます。要件定義の有無にかかわらず、個人のプログラミング作業の中でTDDは実践できますのでぜひ試してみてください。
Q. 開発早期からテスト容易性を織り込もうとすると、やりすぎて開発スピードが落ちたり、結局テストが容易にならなかったりします。どうバランスを取っていますか？
A. 私は次の3つの切り口でバランスを取り、「やりすぎ」にならないよう随時テスト戦略を微調整しています。
- 計画：開発計画の段階で想定されるテスト要求を識別し、計画上必要なテスト要請を確保する
- リスク：発生可能性と影響度でテスト容易性に関わるリスクを評価し、高リスクなポイントにテスト容易性を確保する
- 当たり前：巨大なメソッドを作らない、デッドコードを作らないなど「当たり前」レベルのテスト容易性を確保する
上記に該当しないものは、やりすぎであることが多いです。
Q. 昨今、AIをQA分野でどう活用し、今後どう変わっていくと考えていますか？
A. 変化が激しく読めない部分もありますが、2つの流れが生まれると思います。
1つはQAの業務がQA担当からチームに分散すると思っています。例えばAIの活用で開発者に余力が生まれるほか、生成コードの品質も高まっていくため、開発者がQAの責務を担う流れが強まると考えています。
2つは、QA業務の中の単純作業がシュリンクすると考えています。
この2つの流れから、QAは、AIでは難しい、高度な分析や探索作業がより多く求められると考えられます。例えば、組織間コミュニケーションに問題があるところを見て、そこに起因する品質リスクに対策していく、といった活動です。
Q. よく「QAは予防的な活動」というようなことが言われますが、これはレジリエンスを高める活動に含まれるのでしょうか。
A. QAが予防的な活動というのは、QAのあるべき姿といえます。これはレジリエンスを直接高める方向性です。
対応が求められる品質リスクを予測し、その対策を事前に打つことで、問題のダメージを減らせますし、問題解決を効率化させます。これはレジリエンスを高める活動です。
Q. ある程度できあがってしまっているプロダクトに対して、組織文化的な壁もあり、なかなかテストを最初から考慮したアプローチを取りにくいなと感じています。このような場合はなにから手を付けていくのが良いのでしょうか。
A. 最終的には組織全体の改善を目指すべきですが、組織間の壁が大きい場合は開発担当チームの改善から手掛けるのが良いと経験しています。開発担当チーム内で、ユニットテストを書く習慣を定着させたり、バグを予防・早期検出させる改善を行ったりするアプローチです。
開発担当チーム内で改善ができれば、例えテスト組織が旧態依然のままであっても、開発担当チームからテストチームへのバグ流出が減り、手戻り工数が削減されてスピードアップ・コスト削減につなげられます。
Q. 事業会社のSEとしてテストのマネジメントを担当しています。テスターのテスト力を向上させることが急務となっているんですが、井芹さんが実際に実施して効果があった施策があれば教えてほしいです。
A. テストは属人性の高い活動だと考えています。そのため協力会社といった関係でもよいので、見本となる良いテストエンジニアを確保し、日頃の業務の中で「やって見せて、やらせて見る」アプローチをとるのが、手早い能力向上に有効だと実感しています。またテスト分析を行った直後といったレバレッジポイントを見定めて、そこで見本となる良いテストエンジニアのレビューを入れて影響力を拡大させる施策も有効でした。
アーカイブ動画・発表資料
イベント本編は、アーカイブ動画を公開しています。また、当日の発表資料も掲載しています。あわせてご覧ください。
▼動画・資料はこちら
※動画の視聴にはFindyへのログインが必要です。