「Hey QA、なぜそのバグを見つけられなかった？」 #ポエム

Hey QA、なぜそのバグを見つけられなかった？
この質問が有害である理由と、代わりに聞くべきこと

「次から気をつけます」に対抗する、反省文よりは効果が上がる再発防止、学びの機会の後日談的に、タイトルだけでドキッとする記事を読んだのでその紹介と感想文、です。以下物語は元の記事をDeepL翻訳し、大きく抜粋・箇条書きしています。

物語

リリース日の翌日、重要なお客様から厄介なバグの報告。アラームが鳴り、ポケットベルが鳴り、メールが飛び交う。チームはすべてを投げ出し、緊急モード。修正プログラムを本番環境に迅速に投入する。アップデートが確認され、お客様も安心され、全員が安堵のため息をついた。その後、マネージャーはシニアマネージャーと非公開でミーティングを行い、「どうしてこんなことになったのか」「どうしてこんなことが二度と起こらないのか」などについて話し合った。

翌日そのマネージャーは、前日に受けた非難の傷癒えぬまま、QAに向かって「なぜバグを見つけてくれなかったのか」と尋ねた。

多くの人にとって、この質問は当然のことのように思われる。QAはバグを発見する上で重要な、中心的な役割を果たしている。本番環境でバグが見つかったのだから、次のステップとしてQAに「なぜバグを見つけられなかったのか」と尋ねるのは自然なことだ。

しかし残念ながら、これは健全な質問ではない。たとえ善意であっても、QAに直接質問することは、責任転嫁の有害な文化につながる。

「なぜそのバグを見つけなかったのか」という質問がなぜ悪いのかについてのお話。

QA、「網」、そしてソフトウェアの品質

品質に特化した人や役割はQA、QE、または "テスター"などと呼ばれている。ここではこれらをすべてQAと呼ぶ。このような人たちは、深い分野の知識を持ち、仮定に挑戦する批判的思考者であり、創造的破壊を好む。高品質なソフトウェアを構築しようとする開発チームの最善の努力を尻目に「陰湿に表面化する、微妙で目立たないバグ」を発見する専門家である。

QAはバグを捕まえる網のようなものだと思われがちである。バグは開発者が意図せずに作ってしまうものであり、QAはバグが本番に移行する前にバグをふるい落とすために存在する網である。「網としてのQA」という比喩は、多くのチームやマネージャーの間でもよく知られる。

だからバグが本番環境に到達したとき、それがどのようにして網を通過したのかを当然「網」に求める。明らかに網には穴が開いていて、塞ぐ必要があった。あるいはQAが採用したテストカバレッジまたは実行に何らかの問題があり、これを特定して修正する必要もあった。

しかし残念ながら、「網」としてのQAは不完全で、ソフトウェア開発という複雑な活動を、「構築」と「テスト」という2つのステップのプロセスに誤って単純化してしまっている。

品質は、時間や専門性に関係なく、ただ1つのステップや個人等などで証明できるものではない。徹底的なテストというものは存在せず、ソフトウェアをリリースする際には、常に何らかのリスクがつきまとう。

ソフトウェア開発は、何百ものステップの積み重ねとして捉えるべきであり、それぞれが品質に関わる活動を行い、それぞれが独自の方法でソフトウェアの全体的な信頼性を高めていくものである。品質が単一の人や役割によって実行される単一のテストステップで証明されると考えるのは、危険である。

「網」という比喩から離れてみると、なぜQAに直接「なぜバグを見つけなかったのですか」と尋ねることはただ有害。この質問は、1役割を固定してしまう。責任転嫁に過ぎない。

この質問は、バグを見逃した責任者としてQAという「個人」を暗示してしまう。QAはバグを見つけるはずだったのに、見つけられなかった。

QAに「なぜそのバグを見つけなかったのですか」と質問し、意図せずに責任の所在を個人に向けてしまうマネージャーは、組織を成功に導くことはできない。

もちろんそれを理解しているマネージャーも居るが、それでも質問してしまうとしたら、それはスケープゴートを探しているにすぎない。

悪いのはマネージャーだけではない。自分で問題を悪化させているQAもたくさんいる。彼ら自身、チームの中で目的と価値を感じていて、それゆえ、穴のない網たる責任を誇りに思っている。しかしそんな彼らに対し、あるマネージャーが指差し、こう尋ねる。「なぜあなたはバグを見つけられなかったのか」。そして自分がミスをしたと考えてしまう。

この有害な質問は複数あるが、QAがすべてのバグを捕らえる完璧な網の役割を果たせると過信している。言い換えれば「バグが見つかったときに困るのは、QAの評判だ」という話になってしまうのだ。

すべてのバグを捕らえる完璧な網などもともと存在しない。
にもかかわらず表題の質問は、ソフトウェア開発の複雑なプロセスを、品質に責任を持つ1つのステップに依拠させ、そのステップがなぜ失敗したのかを問いてしまっている。

品質に対するチーム全体のオーナーシップとBetter Question

エンジニアリングチームは、それでもバグを発見する必要がある。また、バグが本番環境に流出した場合には、同様の問題を将来的にどのように回避できるかを理解する必要がある。どうすればよいのか。

「網」の考え方に対するアンチテーゼは、品質に対するチーム全体のオーナーシップであり、ソフトウェア開発の複雑で多くのステップを踏むプロセスに携わるすべての人が、最終的な製品の品質に対して何らかの役割と説明責任を持っているという理解であるという。

ソフトウェアの品質とは、優れた開発プロセスから生まれる特性であり、多くのものが多くの方法で組み合わさったときに生じる結果であり、一人の人間や役割だけが責任を負うものではない。

「高品質なソフトウェアは健康な庭のようなもの」と考えてみる。ただ単に健康な庭を作ることはできない。健康になるための条件がすべて揃っていることを確認した上で、庭が自ら育つのを待つ必要がある。健康は自然に生まれるものなのだ。水に向かって「あなたの仕事は水を確保することです」と言うのは愚かなことである。水を指して「庭の健康を確保するのはあなたの仕事です！」と言うのは愚かなことだ。それと同じように、QAを指して「ソフトウェアの品質を確保するのはあなたの仕事です！」と言うのも愚かなことだ。

ユニットテストは素晴らしい第一歩だが、それだけではチーム全体のオーナーシップの考え方を示すことはできない。開発者は、システム設計、要件収集、プロファイリング、実装、統合、デプロイメントなど、ソフトウェアのアイデアから本番稼動までの多くのステップに関わる。これらの活動はすべて品質に影響を与える可能性があり、品質をテストして信頼性を高めるためには、すべての活動にチェックとガード（開発者が参加）が必要。

例えば、コードレビューが堅苦しいものになっていないか？ユーザーストーリーと受け入れ基準は、十分に定義され、テスト可能なものになっているか？APIテストのテストカバレッジは十分か？UXチームは、プロセスの早い段階でUIアセットをレビューすべきか？テストデータは十分に変化しているか？システムアーキテクチャは実際に分解可能か？

これらの問題をはじめ、開発プロセスの数多くの部分に問題があることが、品質問題の根本的な原因であり、QAが欠陥を「見逃した」という事実ではないかもしれない。この質問の新しい表現は、このことを理解している。
-「なぜそのバグを見つけられなかった？」その質問は、頻繁に、そして率直に尋ねられるべきものであり、お互いを尊重し、率直に学ぶ場であるべきだ。一つの言葉と対象者を少し変えるだけで、会話が非難やスケープゴートのものから、反省、説明責任、改善のものへと変わる。

**この話は、開発者を悪者に仕立て上げようとするものでもない。品質に対するチーム全体のオーナーシップとは、まさにチーム全体のオーナーシップであり、品質の高いソフトウェアを成功させるためには、すべての役割が重要な役割を果たす。**だから、正しくは、その質問はチーム全体に向けられるべきだ。

このちょっとした質問の言い換えと対象者の変更により、開発プロセスに関わるすべての部分とすべての人が正しく吟味されることになる。 これは、将来的に同様の欠陥を効果的かつ効率的に防ぐことができる変更を特定するために、役割とすべての活動全体が、正しく網として役割を果たすべきだ。

物語の結論

あるいはQAであるあなたは今、評価されていると感じるかもしれないが、それは一転、非難が向けられる事態も避けられない。自分は品質のヒーローだと思っているかもしれないが、実際にはただの欠陥のスケープゴートだ。

テスターであるあなたは欠陥を見つける専門家だが、あなたのテストは複雑な仕組みの一部分に過ぎず、高品質のソフトウェアを生産するためには、すべてが健全でなければならない。

またマネージャーは、品質の責任を一人の人間や一つの役割に押し付けるような質問をしてはいけない。品質に責任を持つ人がいれば安心できるかもしれないが、それではチームを成功に導くことはできない。誰もが品質に対して何らかの役割を担っていることを理解し、品質に影響を与えるあらゆることについて、批判的でオープンで正直な議論が許されるだけでなく、評価され、奨励されるような環境を醸成することが大切だ。

QAは「網」の役割であると言う固定観念で失敗に陥らないようにしよう。

感想

ある特定の一個人や部署や役割をスケープゴートにしてもそれは本当に「原因」ではない。責任逃れであるというお話。

「批判的でオープンで正直な議論が許されるだけでなく、評価され、奨励されるような環境」

それを作るのが最も難しいんだよ... と思いつつ、「原因」を説明するのは津々浦々難しい話だよな、あとQAっていう組織もな、と改めて感じた記事でした。関連:

「品質には問題ありません！」と「満場一致のパラドックス」 - Qiita

以上参考になればさいわいです。