🍜

ソフトウェアテストが持つ「透明性」の側面

に公開
Test
QA
agile
scrum
qualityassurance
idea

ソフトウェアテストが持つ「透明性」の側面

本記事はスクフェス三河2025で発表した内容を元に再構成した内容です。

以下の内容もぜひご覧ください。

【注意】
本稿で紹介する内容は、やまずん（バキバキQA/Dirty Tester）の個人的な体験に基づいた活用法であり、所属団体や世の中のQA・テスターの一般的な見解、JSTQBなどの規格を忠実に紹介するものではありません。

はじめに

アジャイル開発、あるいはスクラムの文脈において、「スクラム（アジャイル）にテスターは不要である」という主張がしばしばありました。

この言葉は、チーム全体で品質に責任を持つというスクラムの理念を反映する一方で、テストという専門技術の価値を曖昧にしてしまう可能性があります。
私はスクラムにおいて、QAエンジニアやテストエンジニアが必ずしも必要だと思いませんが、こういった傾向は危険だと考えます。

この記事は、このテスターの存在を否定する意見を尊重したいと思います。
そのうえで、スクラムの根幹をなす「透明性」という概念を軸に、テスト技術がチームにもたらす価値の一側面を言語化し、考察するものです。

「テスター不要論」は、アジャイルの浸透・理解における必要かつ重要な段階であったと捉えています。
開発者自身が完璧なコードを書けるという理想状態（開発者完全性仮説）や、QAエンジニアの存在がチームから品質への当事者意識や学習機会を奪うという懸念は実際にあると考えます。
それどころか、この記事で紹介する透明性がない活動をするテストの当事者は、自己管理されたチームが「品質」と向き合う機会を実際に奪っていますし、そういった現場を見かけたこともあります。

本記事で紹介することは、テスト活動を単なるバグ発見のタスクとしてだけではなく、製品の状態、リスク、そしてプロセスそのものに関する『透明性』を組織的に高めるための専門技術として捉え直すことです。
この視点に立つと、テスト技術の貢献は、欠陥を探すことから製品における曖昧さを排除することへとシフトし、その価値が明確に浮かび上がると考えました。
テストがもたらす透明性こそが、チームの経験主義に基づくプロダクト作りを可能にして、真の自己組織化を促すと考えています。

1. スクラムの三本柱と「透明性」の不可欠な役割

スクラムの成功は、スプリントやデイリースクラムといったプラクティスの導入によってなされるものでないことは言うまでもありません。
これについてはさまざまな意見がありますが、私は経験主義によるチームの成長と、それによる価値あるプロダクト作りができる状態を成功と考えます。

そのためにはスクラムの三本柱が重要だと考えました。
「透明性」「検査」「適応」という三本の柱です。

スクラムガイドは、これらの柱の相互関係を次のように定義しております。

透明性によって検査が可能になる。透明性のない検査は、誤解を招き、ムダなものである。
スクラムガイド（2020年版）,p5

この一文は、三本柱が並列関係ではなく、依存関係にあることを示唆しています。
透明性は、検査と適応の前提条件なのです。

言い換えれば、スクラムチームの適応の質は検査の質に依存し、その検査の質は透明性に依存します。

透明性が欠如した状態でなされる検査は、それに基づくいかなる適応も、見当違いや最悪の場合は有害な結果をもたらすと考えます。
透明性の確保は、スクラムを支える土台だと考えます。

スクラムにおいて、テストは「検査」だと位置付けられることがあります。
その点はありうるかもしれません。

一方で、スクラムにおける「検査」とは、プロダクトのインクリメントが合意されたゴールに向かっているかを確認する活動を指します。
この観点から見れば、テストは検査の主要な一手段であると考えます。
テストは、プロダクトの現状を客観的な事実として可視化（透明化）する技術だと捉えられるのではないでしょうか。

2. テストがもたらす「透明性」の本質：タスクから意思決定の基盤へ

「テスト」という言葉は、その文脈によって「開発の側面」と「品質保証の側面」があることを以下の記事で述べました。

「透明性」に直結するのは、後者の側面だと考えます。

この文脈において、にしさんの以下の言葉は示唆に富むと考えます。

スタンス1:テストとは行動である
スタンス2:テストとは説明である
スタンス3:テストとは納得してもらうことである
「てすとづくり〜質の高いテスト設計の原理〜」,p7

また、テストは難しい側面があります。

ソフトウェアテストはサンプリングで一部の品質しか見れないし、それが妥当かの判断が難しい上に成果を出すのが遅い。そしてテストのリソースや情報に余裕がない
ソフトウエアテスト徹底指南書,p10

ソフトウェア開発とは、限られた時間とリソースという制約のなかで、膨大なパターンのなかから一部をサンプリングする活動です。

そのため、テストの現実的なゴールは「すべてのバグを発見すること」ではなく、「これならリリースできる」という合理的な納得感をチームとステークホルダーの間で醸成することが現実的な解だと私は考えています。
テスト活動とは、この納得感を形成するための体系的な情報提供プロセスであり、技術であると捉えることもできるのです。

3. 透明性を高めるためのテスト技術

テストは一般的に、テスト計画、テスト分析、テスト設計、テスト実装、テスト実行、テスト完了、テストのモニタリングとコントロールといった、体系化された技術プロセスがあります。
このプロセスはJSTQBを参考にしました。

これらは「テスト」という活動を体系的に捉えて段階的に詳細化したり、使う技術やアウトプットの違いを表したものであります。
私はこれらのアクティビティ1つ1つに透明性を担う側面があると考えています。

3.1. テスト計画：暗黙知を形式知に変える

「アジャイルでテスト計画はできない」という言説がたびたびされます。
これは重厚長大なテンプレート作成と化してしまったテスト計画への批判としては妥当だと考えますが、計画という「活動」そのものを否定するものではないと思っています。
私が考えるテスト計画の本質とは、「テンプレートを埋めること」ではなく「限られたリソースのなかでどのようなテストが実施されれば自信を持ってリリースできるか」という問いに、チームとしての戦略について対話を行ない、時に具現化することです。

この活動を通じて、スコープ・リソース・コスト・手段といった点が明確化されます。
テスト計画を怠ったチームは暗黙の前提や個人の思い込みに依存してしまう傾向があります。
「機能性しか検討しないスクラムチーム」は最もたるものです。

この状況を「透明性のなさ」と捉え、レビュー可能な共有知へと転換させるのが私の提案です。
文書化されたテスト計画は、プロダクトオーナーやステークホルダーがチームのプロダクトリスクマネジメントを理解し、議論することを可能すると考えます。

なお、同様に「探索的テストだから無計画にテストする」という考え方もあります。
私はこれに対しても、探索的テストというスタイルに適したテスト計画をすべきだと考えます。

3.2. テスト分析:テスト担当者の1人よがりな成果物にさせない

テスト分析は「何をテストすべきか」について体系的に洗い出す技術だと考えています。
JSTQBの場合では「テスト条件」が識別されるはずであり、これは現場によって「テストアイテム」「テスト観点」「テスト項目」など、さまざまな呼ばれ方がします。

ここで私が大事にしていることは、チームのメンバーが理解できない便利な表を作ったり、自己本位な箇条書きをさせないということです。

テスト分析にはさまざまな手法がありますが、まだ体系的かつ確かなベストプラクティスは存在しないと考えています。
これは「テストはコンテキスト次第」という原則の一側面を捉えていると思います。

だからこそ、テスト分析についてはチーム共同で行なうか、少なくともチーム内でレビューすることをおすすめしています。
これもテスト計画と同様に、「テンプレートを埋めるだけ」になっていたら危険な兆候です。

後述する「テスト設計が可能」= テスト技法の適用によりテストケースの導出が可能なまで記述うすることをおすすめします。
そのためチームは最低限のテスト技法は知っておくべきであり、テストケースについても理解している必要があると思います。

もしよろしければ、以下の記事も参考にしていただきたいです。

3.3. テスト設計：テストケースによって何をカバレッジしているのかを明らかにする。

テスト設計とはテストケースを作ることだと私は捉えています。

ここで重要になるのが、「テスト技法」の適用です。
状態移動テスト・デシジョンテーブルテスト・同値分割法といったテスト技法は、単にテストケースを作成するためだけのものではないと考えています。

テスト技法の真価は「なぜこのテストケース群が選ばれたのか」という論理的な根拠（カバレッジ）を明確に説明するところだと考えています。
テスト技法が適用されないテストケース群は、しばしば「テスト担当者の勘」や「いい感じに散らしてみる」といった恣意的なものとなることがあります。

テスト技法の適用により、テストケースは客観的な技術的成果物となります。
テスト技法の適用は、テストケースの網羅性が論理的に妥当であり、エンジニアリングに基づくことを証明すると考えています。

3.4 テスト実装

T.B.D

3.5 テスト実行

T.B.D

3.6. テスト完了報告：結果からインサイトを引き出す情報提供

テスト活動の終了として、チケットのステータスを「完了」にすることと認知しているチームを見たことがあります。

しかしながら、テスト実行で得た情報を単なる結果の羅列で終えるのは、透明性を下げる行動だと考えます。
テスト完了のうちのテスト報告の本質は、チームの次の意思決定を支援するためのインサイトを提供することだと考えます。

優れたテスト完了報告は、以下のような情報を含み、プロダクトの現状に関する透明性を最大化します。

  • 低減したプロダクトリスク：今回のテストでどのようなリスクが確認され、低減されたか。
  • テストケース外で発見された課題：テストケースにないバグが見つかったか。
  • 第一のユーザーとしての所感：使いやすさや性能に関する定性的なフィードバック。
  • 次の意思決定への提言：得られた情報から、リリース判断や次スプリントで取り組むべき課題は何か。

テスト完了報告は、過去の活動記録ではなく、実用的な情報であるべきです。

それは、チームやステークホルダの意思決定を促す透明性を提供します。

3.7. テストのモニタリングとコントロール

T.B.D

4. スクラムチームにおけるテスト技術の再定義：透明性の促進者として

スクラムチームにおけるテスト技術、あるいはその担い手であるQAエンジニア・テストエンジニアの役割が、いわゆる「品質の門番」といった第三者的な役割ではなく、能動的な透明性の担い手として捉えるべきだと考えています。

テストを実行することは重要な責務です。
一方で、チーム自身の成長や自己組織化を促すための透明性を設計・構築することでもテストは役に立ちます。

そのように考えたとき、「開発スプリントとテストスプリントの分離」や「開発が終わったらQAに丸投げ」といったパターンはアンチパターンだと捉えることができるかもしれません。
これらは透明性を破壊し、チームの自己組織化を阻害している場合があります。
テストが見えなくなり、適切な検査が行なわれず、バランスを崩した適応をしてしまうかもしれません。
その結果、スクラムやプロダクトの価値そのものが失われてしまう可能性があると考えます。

スクラムチームにテストエンジニアが必要な場合

スクラムにおけるテストエンジニアの貢献はさまざまありますが、私は以下の3点だと捉えています。

  • テスト技術の専門家として
    テストプロセス全体を技術的にリードし、チームが「どれくらいテストしたら十分か」という問いに対し、技術的根拠に基づいて合理的に判断できるよう支援する。

  • 批判的視点の提供者として
    プログラマー自身では気づきにくいユーザー視点や・システムの境界条件・悪条件での振る舞いといった、建設的で批判的な視点からプロダクトを評価し、それらをテストするのが妥当かどうかについて、健全な議論をチーム内で活性化させる。

  • チームの自己組織化の支援者として
    テストに関する情報を常にオープンにし、そのプロセス・品質情報・根拠をチーム全員が理解できるよう働きかける。
    テストエンジニアの究極的な目標は、チームがテスト活動の妥当性を自ら判断し、品質を自己管理できる状態へと導くことだと考えます。単なるセーフティネットではなく、チームの品質に対するリテラシーを高める存在だと捉える。

この役割が、テストエンジニアという存在がチームにとって何を意味するのか、という問いに対する私なりの答えとなります。

もちろん、分業としての価値提供は存在するかもしれませんが、それはエンジニアとしての専門性という観点では取り扱わないようにしています。

結論：テストによってスクラムチームで透明性を獲得しよう

本記事は、「スクラムにテスターは不要か」という問いから始まりました。
ここまでお読みいただきありがとうございます。
ここまでの考察を経て、皆さんはどのように感じるでしょうか？

テストは価値を生まず、本来不要な活動かもしれません。
顧客が満足し・よく売れて・誰も損せず・社会が良くなり・永遠に続くことがテストなしで実現できるならそれに越したことはありません。

個人的な結論として、理想的に成熟したスクラムチームには、特定の役割としての「テスター」は不要だと考えます。
しかし、ソフトウェア開発に本質的に伴う「不確実性」はなくならないと考えます。
同様に、テストという専門技術そのものが不要になることはないと考えています。

テスト技術の真価は、テスト実行によってバグを出すことだけではないと考えます。
その専門技術を用いてプロダクトとプロセスに関する「透明性」を最大化し、スクラムの根幹である「検査」と「適応」のサイクルをより効果的かつ合理的に回すことを可能にすることだと考えます。
テスト技術はチームが経験から学び、不確実性のなかで妥当な意思決定を下すための情報を提供する技術です。

したがって、組織やチームが品質について熟考する際に立てるべき問いは、「テスターを置くべきか」や「テスターがテストするか開発者もテストするか」という表面的な二元論ではないと思います。
真に問うべきは、**「我々のチームは、テストがもたらす『透明性』をいかにして獲得し、それを活用して不確実な未来へと適応していくのか」**だと考えます。
これらの答えは組織それぞれが探し・持つべきものだと考えます。
「テストはコンテキスト次第」だからです。

みなさんの現場では、どのくらいテストのことを知っているでしょうか？

参考文献：

GitHubで編集を提案

Discussion