出荷できる品質とその加速のための7つの原則

河原田政典氏(以下、河原田):次は、品質に対する「チーム全体アプローチ」というものをきちんと考えていかなければならないと思っています。すなわちQAチームは、スクラムチームが自分たちで成果物をテストできるように支援するような存在です。

アラン・ペイジとブレント・ジェンセンという、2人の元テスターによる、「モダンテスティング」という考え方があります。

その中身がどんな感じかはググってもらえれば出てくるので割愛しますが、ミッションは出荷できる品質への到達であり、これを加速させることが大事といったところです。

(スライドを指して)そのために必要な7つの原則が挙げられています。ビジネスの成長、ボトルネックへの対処、継続的な改善、品質文化醸成。5番目の「顧客こそ品質の評価者」は、アジャイルでもDepOpsでも、ウォーターフォールでも変わらない気がします。6番目はデータドリブンです。そして7番目に、「テストはチームに還る」という考え方があります。

これは、「テストスキルやノウハウをチームに広めていくんだ」ということを表しています。「We expand testing abilities and knowhow across the team」。つまり広めていくということです。今まではQAチームの専売特許だったテストのスキルやノウハウを、チームに広めていく、みんなにもやってもらえるようにするということです。

それによって、専属のテストスペシャリストの需要が減ったり、なくなったりすることがわかっていてもやる。僕は、もしかしたら何十年後かには、日本からテスターという職業の人がいなくなるかもしれないと思っていますが、それはまた別の話なのでやめておきます。

そういうわけで、品質に対する「チーム全体アプローチ」というものがあって、こちらに対する取り組みをしていきたいと思います。イメージとしては、スクラムチームはこんなことを思うのです。「いやあ、Definition of Done(完了の定義)を書かなきゃいけないのだけど、『QAチームのテストをとおすこと』なんて、書きたくないな」みたいな。

なぜかというと、スクラムのチームはすべて自分たちで完了することを理想としているので、ものが出来上がっているという完成の定義の基準に、ほかのチームのことはあまり書きたくないのではないかなと。そんな感じです。

そうすると、テスターがフーっと寄ってきて、「スクラムチームさん、ご自身でテストができるようになりたくはありませんか? もしそのおつもりならば、QAチームがテストのやり方を実践でお伝えしますよ!」といったことを言ってみるわけです。

すると、スクラムチームとしてはできることが増えるし、自分たちでテストができればコミュニケーションが遠いなどの問題が解決するので「なるほど」と思うわけです。テストが自分たちのものになるのだから、「いいじゃない」と思います。

「QAチーム要らず」への4つの階段

そこで、次に僕が示すのは階段です。最初はスクラムチームの人たちに「じゃあ、テストをやってください」と言ってもなかなかわからないので、テストプロセスのほぼすべては、QAチームがリードしていきます。そして、「こういうふうにやっていくんですよ」みたいなことを、スクラムチームと共有していきます。これが第1段階です。

第2段階に入ると、今度はスクラムチームが、自分たちでテストを主導していくようになります。QAチームはレビューやアドバイスなどをしていくフェーズになっていきます。

第3段階になると、スクラムチームがほぼすべてのテストを実施し、QAチームは専門性を要する時に支援をしていくかたちになります。だって、自分たちでほぼすべてのテストができるのだから、QAチームがわざわざやる必要はない感じになっていきます。だんだん手離れしていくイメージを、わかってもらえるとうれしいです。

第4段階では、スクラムチームがQAチームの手を借りずにテストをする状態です。この1、2、3、4の階段は、僕が作ったんですが「QAチーム要らず」への階段といいます。

以上のようなことができると、今はまだQAの人たちの専売特許になっているテストというものが、今後だんだん広がっていく。QAのエンジニアとしても、テスト以外に品質を向上させるメソッドがいろいろあると話しましたが、そちらに時間を割けるようになるので、けっこうWin−Winな流れなのではないかな、と思うわけです。

スクラムチームに参加するのがいいか?独立QAチームによる支援がいいか?

最終章になりますが、第5章は「池に小石を」です。まず、ここまでみなさんにお伝えしたことの1つとして、最初のほうにあった「品質を高めるために、スクラムにテスターを入れるか否か」という問題への絶対的な答えはまだ存在しません。これが1つ目です。

別のイベントでも同じような話が出てきましたが「やはりまだ答えは出ていないよね」「その組織によって答えは変わってくるよね」という意見がありました。

2つ目は、独立QAチームがスクラムを支援する時の鍵は「卓越したテスト技法や技術」などではなく、そもそも「丁寧なコミュニケーション」が要るという話でした。

もちろん、丁寧なコミュニケーションがきちんとできた上で、何か次に進んでいこうとなってきた時に「卓越したテスト技法やテスト技術」は大いに活躍すると思います。しかし、最初から「自分たちにはこんな技術があるんだ! こんなことをしているんだ!」みたいに振りかざして近寄ってきてもただのストーカーなので、僕はあまりよくないと思うのです。

3つ目は、プロダクト品質の担保です。これは、スクラムが責任を持ってやっていくような感じになっていきます。責任を持ちましょう、そして、独立QAチームがいなくても自分たちでテストできるようになりましょう、ということです。

そもそも、ここまでのチーム全体アプローチみたいな話は、自分たちで品質を上げていくとか、保っていくという発想がなければ成り立ちません。ですので、自分たちでテストをできるようになろうという3つ目の話が出てきました。

というわけで、「今こそすべてのテスターやスクラム実践者に問います」というところでこの2つです。テスターが開発者としてスクラムチームに参加するのがいいのか、それとも独立したQAチームがスクラムチームを支援していくのがいいのか。さあ、あなたならどう考えますか、というところです。

この話を聞いてくれているみなさん自身だけでなく、ぜひ自分たちの会社やチームに持ち帰ってもらって、この問いを投げかけていただきたいと思います。

そして、(スライドを指して)最初この図を見た時は「自分は1だな」と思っていたけれど、この話を聞いて「2がいいな」と思った。あるいは「いや、最初2がいいと思っていたけれど、Markのこの話を聞いて、あまり実効性が高くなくね?」「あまり実効性を感じられなかったので、やはり1かな」と思う方もいると思います。

もしくは、the 3rd way、つまり別の第3の道を見つける方もいるかもしれません。中には「うちはそもそもスクラムをやっていないし」という方もいるかもしれませんが、そうした投げかけをします。

そういうわけで、今回のこのスライドは、最後に投げかけで終了したいと思います。「独立QAチーム1年戦記」という話でした。ご清聴、どうもありがとうございました。