さようなら第三者的品質保証
この記事はソフトウェアテストの小ネタ Advent Calender 2019の23日目の投稿です。文字数的に小ネタじゃなくなっているのですが、言ってることは小ネタなので気にせずに投稿しようと思います。
昨今、多くのソフトウェアテストの有識者が第三者的品質保証から当事者的品質保証へ変化を遂げる必要があるよねという発言をよく耳にします。
私個人もその変化にはとても共感をしています。
そこで今回は実体験視点と、ソフトウェア業界の動向視点でなぜ変化していく必要があるのかを自分なりに切り取ってみたいと思います。
第三者的品質保証からの脱却 ~実体験視点編~
当時私はWebサービスを自社開発している会社のQA部署にいた。
QA部隊は開発部隊と隔離され、独立した機関としてテストしていた。
物理的にも離され、テキストコミュニケーションを中心とした必要最低限のやり取りしかしなかった。
開発とQAは水と油で交わることはないと言い伝えられ
対立構造を生むことで、テストは忌憚のない鋭い欠陥指摘が可能になり
極限まで洗練された品質を届けられると信じられていた。
そんなユートピアはどこにもなかった。
開発者はテスターを嫌い、テスターは開発者を嫌った。
顔も見えない、会った事もなければ話した事もないテスターからの容赦ない欠陥報告は、「なぜこんな簡単な問題をもっと早く見つけることができないのか？」「それバグじゃありません。ロジックわからないんですか？」「仕様です。そんなこともわからないんですか？」といった言葉と共にテスターたちへ真っ直ぐに突き刺し、返された。
欠陥を見つけて報告しても対応されない日々。
再依頼一つとっても、また嫌な顔をされるのではないかとテスターにとっては大仕事だった。
バグチケットに書かれた修正コメントは「修正しました」の一言。
影響範囲がわからず、原因と修正範囲を尋ねると「言ってもわかりませんよね？」と小馬鹿にされる日々。
画面を見ても、修正されている気配がない。
バグチケットは修正済で返ってきている。
「開発者の手違いかな？」
「いや、QA側の確認ミスかもしれない。」
「もう少し、画面上で色々試してみよう」
いたずらに時間だけが過ぎていく。
罵詈雑言の日々。お互いがお互いを忌み嫌い、蔑み
次第に大きな欠陥以外は、
「どうせ対応されないだろう」
「間違って報告したらまた刺される」
と報告されなくなっていった。
テスターは孤独だった。そんなテストは腐っていた。
私は心身に限界を迎え、3年弱でその会社を退職した。
パラダイムシフトへのいざない
私は開発者をひどく恐れていた。
開発者は理論武装で固めた正義の鉄拳で、欠陥報告の欠陥を容赦無く振りかざす人たちという世界観で塗り固められていた。
そんな凝り固まった狭い視野での価値観のまま
転職先が決まり配属先はローンチ案件のプロジェクトに決まった。
そのプロジェクトはQAも開発者も同じオフィス内にいたので
あのドッグファイトをゼロ距離でやり合うのかと思うと、気が気でならなかったが、そんなディストピアはすぐ吹き飛んだ。
あんなに億劫だった仕様やロジックのすり合わせは物理的に直接話し合うことで一瞬にしてSyncした。
あんなに時間のかかった欠陥の再現報告も、開発者の席に直接再現報告しにいくことで一瞬にして再現と特定が可能になった。
あんなに一言であしらわれていた欠陥報告の原因と修正範囲の確認も、非言語的コミュニケーションを合わせることで、丁寧に共有して工夫してもらえるようになった。
あんなに嫌で嫌で参加したくなかったふりかえりも、直接膝を突き合わせてコミュニケーションを取ることで、このチームのために改善できることなら全力で向き合い改善したいと思えるようになった。
それだけでなく、お互いが品質やテストについて話し合う機会が増えることで、チーム全体で品質やテストについて考える時間が増えていった。
開発者の裏に人間の存在を認知できるだけであらゆる心理的障壁が
いとも簡単に取っ払わられ、品質のあり方についても価値観がアップデートされ、開発者とQAとの関係性のパラダイムシフトが自分の中で起こった。
水と油だった関係性の時は、どれを取っても、「プロダクトをより良いものにするため」以前に、開発者の怒りを買わないようにするためにはどのように立ち振る舞えば良いかが常に諸氏の先頭に立っていた。
わかっている。仕事なんだからそれでも物事を進めなければいけない。
それができない奴は無能のレッテルを貼られるんだ。
わかっている。わかっていたが、ただただ怖かった。
構造おばけ
8年の知識と経験を経て、色々な角度から物事を判断できるようになった今だからこそわかることは、開発者の人格に問題があったわけでもなく、私の人格に問題があったわけでもなく（たぶん）、ただただ構造に問題があっただけだった。
物理的にも仮想的にも距離を置き、意図的に非言語的コミュニケーションを低くした結果生まれた構造おばけの仕業だった。
最初から敵なんてどこにもいなかったのだ。
開発者であるとかQAであるとかの前の大前提に私たちは結局人間なんだ。
人間として向き合い、お互いの存在を認め合い、歩み寄り、傾聴し、信頼し、リスペクトするその架け橋で、初めて心理的安全性の高いラーニングゾーンの世界へ到達することができる。
そのユートピアにいけない限りは、本当の意味で「プロダクトをより良いものにするため」の正義の拳は振りかざすことはとても難しいと思う。
構造おばけにとらわれたままでは、あらゆるところでテストは腐る。
責任を転嫁し、問題を隠蔽し、品質は置き去りだ。
QAは品質の最終責任者、最後のゲートキーパーとよく言われるが
チームがそのような状況では、ペナルティエリアから弾丸シュートを打たれるようなものだ。到底防げるものではない。
プロダクトをより良いものにしていくためには
心理的安全性の高いラーニングゾーンへ到達することに加えて、QAだけが品質について責任を持つのではなく、品質についてプロジェクトメンバー全員がオーナーとなり、それぞれが品質について考える当事者的品質保証に形を変えなければいけない。
QAは、品質の保証者という立場ではなくアドバイザーという形で、プロジェクトメンバー全員が品質について考え、打ち手を打てることができるように上手くリードする立場へと変わらなければいけないと思っている。
-Fin-
といった感じで、なんか偉そうに断定口調で書いてみました。
一回やってみたかったんです。
この話は私の体験視点の元、プロダクトをより良いものにしていくためには、第三者的品質保証から脱却する必要があるという個人的見解でした。
この問題は、JSTQB-SyllabusFoundation Version2018.J03にも独立したテストのデメリットとして説明されています。
•開発チームから隔絶されると、協力関係の欠落、開発チームへのフィードバック提供の遅延、開発チームとの対立を招くことがある。
• 開発担当者の品質に対する責任感が薄れることがある。
• 独立したテスト担当者は、ボトルネックとして見られたり、リリース遅延で責任を問われたりすることがある。
• 独立したテスト担当者にテスト対象の情報などの重要な情報が伝わらないことがある。
テストの独立性については開発モデルや、テストレベルによってメリットになる場合も当然出てくると思いますが、昨今のソフトウェア業界の動向視点で考えても、第三者的品質保証からの脱却は目を背けてはいけないことだと感じています。
第三者的品質保証からの脱却 ~業界の動向編~
技術の進歩、開発手法の変化、ユーザニーズの変化により、サービスが勝てるかどうかは、素早く開発、テスト、リリースして、市場の反応を見てまた戻るという、このフィードバックループを以下にして早く回すかが一つの成功要因となっています。このフィードバックループを素早く回すためには、ソフトウェアテストのニューノーマル（新しい普通の状態）を受け入れ、取り入れていく必要があります。
あらゆるリスクの対応、要求の変更に素早く対応していくためには、チーム全体があらゆることに対して自分ごととなり、チーム全体で密接に連携する必要があります。開発とテストはチームスポーツと表現されるほどなので、
開発とテストを区別する考え方はニューノーマルからは遠ざかりそうです。
また、フィードバックループを素早く回すためには、各テストレベルでの自動化についても注力していく必要がありそうです。
では実際に上記のニューノーマルはどの程度認知され、普及してきているのでしょうか。
世界80ヶ国、1000人以上のソフトウェアテストの有識者に対してテストの現状調査を行い、世界規模でソフトウェアテストの動向を毎年レポートしているState Of Testing 2019のデータからも、フィードバックループを素早く回すために必要なAgileやDevOpsなどの開発手法の変化、CI/CD/CTなどのデプロイパイプライン構築の活用が進んでいることが見て取れます。
多くのアナリストからDevOpsがキャズムを超えたと昨今言われていることから、このモデルが世に広く知れ渡り活用される一定の障害を超えたことになります。
2019 Accelerate State of DevOps ReportのDevOpsを活用しているチームと、そうでないチームでのパフォーマンス比較を見ると
・デプロイ頻度が208倍以上
・コミットからデプロイまでのリードタイムが106倍高速
・障害復旧時間が2604倍高速
・運用環境へのデプロイ失敗率が1/7
このデータを見ればAgileやDevOpsなどの昨今盛り上がりを見せる開発モデルがウォータフォールを抜いてなぜに採用されているのかが一目瞭然だと思います。
このようなソフトウェア業界の動向を踏まえて、開発とテストを独立させ、テスト部署を品質の最終責任者にしてテスト部署だけに品質を考えさせることは、テストをボトルネックにしてしまう確率が上がり、リリースサイクルの高速化を妨げてしまいます。市場に勝つためにやっている品質活動が
結果的に市場に負けてしまう要因になってしまう本末転倒な悲しいことに。
おわりに
プロダクトをより良いものにしていくためには
信頼の元にあるコミュニケーションが必要不可欠です。
アジャイル宣言の背後にある原則 に書かれている通り
ビジネス側の人と開発者は、プロジェクトを通して
日々一緒に働かなければなりません。
意欲に満ちた人々を集めてプロジェクトを構成します。
環境と支援を与え仕事が無事終わるまで彼らを信頼します。
情報を伝えるもっとも効率的で効果的な方法は
フェイス・トゥ・フェイスで話をすることです。
日々一緒に働き、フェイス・トゥ・フェイスで話をすることが成功への近道だと身を以て感じています。
プロダクトをより成功に導くためには
リリースサイクルの向上が必要不可欠です。
開発モデルの変化の先に見据えた品質やテストのあり方は、開発とテストが区別できなくなるぐらい自然に溶け込み、チーム全員が品質やテストについてあらゆるフェーズで考えていくことが重要になってきそうです。
今一度、品質保証の形や、品質保証の言葉の定義自体を考え直し
品質が誰かにとってのスケープゴートにならないよう、チーム全体で捉え直す必要がありそうです。
この記事が気に入ったらサポートをしてみませんか？