この記事はPeter G Walenによるゲスト投稿です。

チーム全体の品質 (Whole Team Quality) の概念が知られるようになってからというもの、この言葉が何を意味するかについて華々しいことを言う人たちはたくさんいます。これでお金を儲けようとする人たちのあいだでのバズワードになっているようにも思われます。もう一度見直してみましょう — 初めて見たつもりになって考えてみるのです。

チーム全体の「定義」

何らかの形で「アジャイル」を標榜する組織なら、「Whole Team」、「Whole Team Quality」という言葉を聞いたことがあるでしょう。人間は人間である以上、概念が実際に何を意味しているかではなく、自分の先入観に合わせて解釈しがちです。私の考えでは、この概念が何を意味するか、またチームや組織にとってどのような利益をもたらすかを批評的に考察した情報はほとんどありません。

多くの人にとって、「whole team」とは、つぎの2つの極端な見解のどちらかに言い換えられます。

1.すべてのテスターは製品コードを書かなければならない。自動化をサポートするコードは「製品」コードではないので「本物の」コードには入らない。

2.ひとりひとりが品質に責任を持つので、テストをする人員は必要ない。

多くの人々は自分のふるまいや決定を正当化するためならどんなことでもするものです。悲しいことに、決定を下し方向性を定め、その後に決定を正当化するために情報やデータを集め、調査をするという例は無数にあります。

昔、ある人がこう言ったのを覚えています。「心はもう決まっている、事実を持ち出して混乱させないでくれ」

問題

上の「定義」の最大の問題は、チーム全体の品質に関して最もひんぱんに引き合いに出されるふたり、権威であるリサ・クリスピンとジャネット・グレゴリーの意図とは関係がないことです。2人の最初の共著Agile Testing(邦題は『実践アジャイルテスト―テスターとアジャイルチームのための実践ガイド』)では、アジャイル環境におけるテストの役割の問題が扱われています。

多くの組織は「whole team」を上記のいずれかの意味に解釈しますが、それはそうしておくと都合がよいからであることも多々あります。この言葉によって自分たちの行動にある程度の正当性を持たせようとしているのです。「whole team quality」の本質は上記の2つの意味の中にはありません。

重要なのは、チームの誰もが製品の品質を向上させるうえで役割を果たせるということです。

多くの人は「品質」と「テスト」をごっちゃにしています。目的を果たす手段としてそうしていることもよくあります。上記の定義を採用している組織を見てみると、たいていは頭数の削減という結果につながっています。

私が問題にしているのは、これらの定義に見られる同語反復的な誤りというよりは、品質とテストの関係について、またチームやさらに大きなくくりでは企業が品質の高い製品を顧客に届けるにあたってテストスペシャリストがどれほど力になるかについて理解が欠けていることです。

開発とテスト

私が見るところ、問題の一因は「開発」と「テスト」の間の亀裂にあります。問題は、役割を完全に互いから独立させてしまうことにあります。

現在ソフトウェア業界で働いている人の中には、「典型的」と考えられているものとは異なるさまざまな背景を持つ人も多いことを私は知っています。また、このような状況は少なくとも過去35年は続いていることも知っています。何ら新しい現象ではありません。私がソフトウェアの開発を始めてから長い間、開発者は自分の作業や同僚の作業をテストすることを期待されていました。

詳細設計仕様に基づいて作業することでしかるべき注意を払い、仕様自体も開発者によって作成され、「テスト」されていました(このテストはレビューおよびウォークスルーと呼ばれていました)。仕様は業務エキスパート、ユーザー、顧客との会話から得られたメモに基づいて開発者によって記録された要件から作成されていました。

また、テスト計画やテストスクリプトの作成を扱わないテストに関するワークショップが催されていました。純粋にコミュニケーションやコラボレーションだけを扱っていたのです。ソフトウェアをテストすることや、ここで挙げた他のプロセスに関わることを拒否する開発者は、少なくとも私がいた職場では長続きしませんでした。

こう書いてみると、今の時代の若手や新人レベルの開発者が経験することとは大きな違いがあることがわかります。そこで難題が残ります。

「テストのコスト」という難題

何年も前、少なくとも10年以上昔、ソフトウェアの世界で「ソフトウェアテストのコストを削減する」ということが盛んに言われ、その方向への圧力がありました。まさにそれをテーマとしてテスターによって書かれ、編集された本がありました。How to Reduce the Cost of Software Testingです。私はこのプロジェクトに参加して章をレビューし、コピーエディティングでライターに協力しました。

当初から、この問題については自分のこととして考えており、問題の原因や理由について意識していました。また、これに関連して多くの説を却下もしました。私の論拠は単純です。なぜ要求分析やプロジェクト管理やコーディングのコストと切り離してテストのコストに注目するのか？

ソフトウェア開発の1つの側面だけに注目するのに、他に目を向けないのはなぜか？必要な側面の1つが他よりも価値がないとしたら、その理由は何か？

私に言えるのは、テスターはソフトウェアを「壊す」ことに熱中していて的外れだという感じ方があるためだということです。すばらしいソフトウェアを作るためにチームとして取り組む代わりに、同僚のうちの結構な数の人間が、嬉々としてチームの他のメンバーの作業を貶めているように見えるのです。

これはテストがどのようにして開発から切り離されることになったかという疑問への答えになるでしょうか？いいえ。まったくなりません。同様に、テストが設計や分析と同じように考慮されないことの理由にもなりません。

これは「whole team quality」がテストスペシャリストはいらないという意味になった理由を説明するでしょうか？私にはわかりません。

しかし、そのような意識を持つテスターがいるチームでは、この考え方に疑問を持たない傾向があることの説明にはなるかもしれません。

難題を越えて

意識の問題を改善する決定的な方法があるかどうかはわかりません。私のテスターとしてのキャリアの最初のほうでは、コードのバグを見つけたら、それはテスターである私の勝ちなのだという思い上がりがいくらかあったことは確かです。

今では、バグは私の失敗なのだと捉えています。つまり、私はチームの開発者と協力して問題を未然に防ぐことに失敗したのです。私のテストスペシャリストとしての役割で考えれば、私は検証すべき問題や懸念を明確にできなかったということです。問題を阻止するようなテストや調査プラクティスについてチームを適切にコーチングできなかったということでもあります。

これが「whole team」とテストに対処する方法ではないでしょうか。

各々が自分の専門知識を持ち寄ることでプロジェクトに貢献します。熟練したテストスペシャリストは、設計、顧客が接するコードの作成、ソフトウェア開発のその他の側面についてのスペシャリストと協調します。誰もがプロジェクト全体に貢献します。誰もが関わり、情報を得ます。

チーム全体で製品を形作り、作り上げるのです。

それでも

テストスペシャリストの必要はないと主張しつづける組織やチームもあります。会社として自分たちはテスターを「必要としていない」のだと堂々と宣言しているところもあります。そういった企業は、テストを自動化することで、テスターが行っていた作業を代替しています。

一理ある可能性

もしテスターがチームと関わっていないなら、開発者と情報やアイデアを共有していないなら、開発者にテスト技術を説明し、実演して見せるとき、開発者から学んでいないなら、自動化されたテストツールはおそらくコスト効果の高いオプションでしょう。

テスターが開発のエラーを指摘して勝ち誇ることでキャリアを築いているなら、テスター自身がテスターの最大の問題であり敵でしょう。チームの他のメンバーを強化するために働いていないからです。協調するのが難しいようなメンバーもいることは私も承知しています。だからといってテスターが努力しなくていいことにはなりません。

メンバーがともに学び、製品を良くしていかないなら、チームというものは存在しません。チームというものが存在しないのですから、「whole team」について考えるまでもありません。個人の集まりでしかありません。

品質はチームが全体として協調するかどうかにかかっています。そうなっていないなら、私の経験から言えば、テストスペシャリストがいてもいなくても何の変りもありません。

Peter G. Walenは、ソフトウェア開発、テスト、アジャイルプラクティスで25年以上の経験を持っています。ソフトウェアがどのように動作し、他のソフトウェアと連携するか、またソフトウェアを利用するユーザーをチームが理解できるよう支援に尽くしています。 Agile Alliance、Scrum Alliance、American Society for Quality (ASQ)のメンバーであり、ソフトウェアミートアップに熱心に参加し、カンファレンスでもたびたび講演しています。

（この記事は、開発元Gurock社の Blog 「Whole Team Quality and Testing」2020年4月2日の翻訳記事です。）