スクラムに入るのか入らないのか、それがテスターの問題だ　チームのかかわりで発生する壁と2つの解決方法

自己紹介

河原田政典氏（以下、河原田）：それでは始めていきましょう。「独立QAチーム1年戦記」というテーマで、DevOpsDaysのイベントでありつつも、スクラムのような話です。アジャイルテスティングという分類でお話ししたいと思います。

まずは登壇者の紹介ということで、自己紹介をします。Markといいます。Twitter上では＠mkwrdというアカウントで発信をしています。発信なのか、飯テロアカウントなのかというところですが、そんなことをしています。肩書きというか、役職・ポジションは、“QA知恵袋”と書いてキューエーブレインと読みます。

そんな感じのことをしているエンジニアです。QAのエンジニアですが、その中でいろいろな知見を持って帰ってきて広めたり、こうやってみなさんの前でお話ししたりしています。

株式会社グロービスという、教育事業を展開している会社に勤めています。グロービスでは、2016年からビジネススキルを学べる定額型動画学習サービス「GLOBIS 学び放題」の提供を開始しました。あまりエンジニアが中で働いているイメージをみなさんに持たれていないので、この機会に認識してもらえるとうれしいです。

（スライドを指して）4番目に書かれているエンジニア歴ですが、だいたい9年になります。震災のあった年の3月に卒業しましたが、仕事がなくて1年間専門学校に行きました。その後、2012年4月から働き始めたので、9年という感じになっています。インターナショナルカンファレンスフリークとして、コロナ前はよくいろいろな海外のカンファレンスに行っていました。今でもオンラインで登壇することもあります。

忘れていたのですが、スライドは日本語と英語を併記して表示しています。そういうスライドの作りにしているので、日本語でしゃべりますが、イングリッシュスピーカーの方も、だいたいどんな話をしているのかがわかるような構造になっています。

これが、僕が現在住んでいる部屋です。和室4．5畳とキッチンが5畳という、とても広い部屋ですが、残念なことにお風呂もトイレもありません。トイレは共同です。葛飾区の月3万円の部屋に住んでいます。そんな人物です。

講演の4象限における今回のセッション内容

これは国内も海外もそうなのですが、いろいろな講演を聞いていると、（講演は）もしかしたらだいたい4つに分かれるのではと思います。そして、急遽作ったのが（スライドを指して）この図です。

Quadrantなんて言うと、ちょっとカッチョイイわけですが、こうやって壇上に立って人がしゃべっています。そのしゃべっている中で扱っているものがこちらです。下のほうからいきましょうか。

理論の話なのか、上側の現実に基づいた話なのか。「自分たちはこういうふうにやりました」という現実の話なのか。また、パラダイムはどうか。古いパラダイムにのっとっている話なのか、それとも新しいパラダイム、つまり提案に近いと思うのですが、そういった話をするのかに分かれるかと思います。

テスト界隈では、比較的「自分はこのようにしている」という、右上の現実と新しいパラダイムの話をされることが多いと思います。一方で僕は、テスト界隈、QA界隈の中では比較的理論派です。右下のアジャイルテスティングもそういう話だと思いますが、右下のところで話をしています。

そうなると、だんだんみなさんから批判が出てくるわけです。「あいつは耳当たりのいいことを言っているにもかかわらず、何をしたのかっていう話をぜんぜんしないじゃないか」と思われるでしょう。ですので、今回は右下の理論というところ、実際に自分たちの会社でやってきましたという話ができたらいいかなと思っています。右下に軸足を置きつつ、ちょっと右上に出てみましたという、そんなお話です。

なぜテスターの話をするのか

ではまず、問題の所在についてです。第0章なので“始動”としています。

このスライドは、テスターおよびスクラム実践者に向けて作ったものです。このスライドの場合、テストや品質の専門家すべてをテスターと称しています。なぜかというと、テストエンジニアやQAをいちいち分けて書くと、字数が足りなくなるからです。スライドの中が字数でギッチギチになるのを嫌っているからです。なので、テスターと言ったら、テストにかかわる専門家すべてを指していると認識してください。

では、なぜ今回2021DevOpsDaysTokyoで、このテスターとやらの話をするのかですが、ちょっとスライドを見てください。もしご興味があれば、調べればわかると思うのですが、State of Testingというテストの現状調査データが、毎年発表されています。

おそらく日本語版も出てくると思いますが、おととい（発表当時）英語版が発表されました。その中で、DevOpsにかかわっているテスターの数が増えてきています。ちょっと見にくいかもしれませんが、こちらの比較図でいうと、一番右側で28パーセントの人が「私の組織はDevOpsだよ」と言っていたのが、この2021年の一番新しい調査結果では、42パーセントの人が「DepOpsで働いているよ」と言っているわけです。

母数が同じなのかわからないので単純に比較はできませんが、それでもけっこうな人がDevOpsにかかわり始めていると言えるのではないかと思います。ちなみに、DevOpsの上はAgile or Agile likeで、「アジャイルっぽいところにいます」と言っている人が多い割合です。

そして、おそらく2017年にカトリーナ・クロッキーさんが発表された『A Practical Guide to Testing in DevOps』という書籍があります。DevOpsにおけるテストにはどういうものがあるのかという、非常に興味深い内容でした。

さらに、やはり見覚えのある図がこうやって出てくるわけですが、DevOpsの流れの中でテストがどうかかわってくるかについて、（スライドを指して）2016年にダン・アシュビーさんという方がブログに書いたこんな図があります。プランからコードを書いたり、ビルドしたり、リリースしたり。すべてにおいてテストはかかわってきますよ、といった話です。

そういうわけで、このDevOpsDaysでテスターがテストの話をすることは、一定効果があるというか、みなさまにも関係があるということを理解してもらえたのではないかと思います。

テスターはスクラムに入るのか？入らないのか？

（スライドを指して）ここまでで10分を費やしているので「テスト業界は話の長いやつらばっかりか」と思われるかもしれませんので、この肖像画の人物から話を進めていきます。こちらは、『ロミオとジュリエット』で知られるウィリアム・シェイクスピアというイギリスの劇作家です。

シェイクスピアが言ったことで日本人がよく知っているのは、「To be or not to be, that is the question.」（このままでいいのか、いけないのか、それが問題だ）です。これを「生きるべきか死ぬべきか」という日本語で知っている方が多いですが、僕個人としては、小田島さんの訳の「このままでいいのか、いけないのか」のほうが文脈としてはしっくりくると思うので、こちらを取り上げています。

これに当てはまる僕らの問いは何かと考えると、「さあ、そのテスターというやつらが、スクラムに入るのか入らないのか、それが問題だ」なんて言えるのではないかと思うわけです。

なぜなら、開発者はスクラムの中に定義されています。プロダクトオーナーも定義されています。スクラムマスターも定義されています。この3ロールが定義されている中で、テスターという人は定義されていません。では、どうかかわっていくのでしょう、というお話です。

変化してきたテストの考え方

では、スクラムとテスターの関係についてです。（スライドを指して）見たことのある従来の図だと思いますが、ウォーターフォール時代の話です。このウォーターホールの時代、テスターという人たちは、“テスト”というプロセスに入っていました。

コーディング側と一緒にテストを仕掛けて「よし、OK」となったらテストが行われる。そのテストの段階でテスターが「うーん、これはちょっとだめだな」と思ったら突っ返されるという感じで、門番のような機能をしていた。それがテスターと言われる人たちです。そこには、たくさんのお金と時間がかけられてきました。

その、たくさんのお金と時間をかけてきたことが、このJAPAN QUALITYを支えてきたと言えるのではないかと思います。JAPAN QUALITYという言葉でイメージできるのは、ソニーのウォークマンなどもそうなのかもしれませんが、いわゆる製造業、特に伝統的な製造業です。

翻ってこのAGILE METHODOLOGYですが、アジャイルにおけるテストは1つのイテレーション、あるいはスクラムでいうところのスプリントの中の1つの部分になっています。今まですごく時間とお金を費やして数ヶ月かけていたところが、たった2週間や1週間のスプリントの中の、しかもごく一部みたいなところに入ってきているため、考え方が大きく変わっているんです。そのようなことがあって、テスターはけっこう戸惑っているのではないかと思います。僕自身もそう思います。

テスターとスクラムチームがお互いに対してどう感じているか

テスターという立場からスクラムチームを見た時に、どう見えているかについて、簡単にお話しします。

1つ目は、なんかちょっとハードルが高い感じがする。スクラムガイド2021などを読まないといけないので、なんかハードルが高い感じがする。スクラムガイドというのはマニュアルではなく単なるガイドなので、自分たちで考えなきゃいけないとか。うーん、なんかハードルが高い感じがする。

もう1つ。スクラムチームは仲がいいですよね。アジャイルであれば、チーム仲がいいのはけっこうあると思うのですが、その一体感が作る見えない壁、ATフィールドのようなものが感じられることがあって、テスターとしてはちょっと近寄りがたい、ちょっと距離を感じるようなところがあります。

そしてアジャイルやスクラムの中でも特に、「長い間テスターがいなかったけれど、今回は大事なリリースだからテスターを入れてみました」みたいな。プロジェクトにありがちなのが、不具合や違和感のようなものが無限に見つかることです。テスターとしてはちょっとやりにくいというか、困った状態になっている感じです。

一方、スクラムチームはテスターが入ってくることについてどう考えているか。

まず1つは、コミュニケーションが煩雑になる。そして、距離が遠いので決まるまでの時間とても長い。毎週1つずつしか決まらないようなところがあって、これでプロダクトオーナーはオコ（怒）になるわけです。

腕のいいテスターであればあるほど、不具合報告をたくさん上げられます。なぜならテスターの仕事は、「パスを出すこと」「NGを出すこと」「直してもらうこと」というのがあって。つまり、直してもらうことがあるわけで、直してもらうためには開発者に投げなければならないので、たくさん出してきます。そこで開発者としては、確かに違和感や不具合なのだけど、そんなに重要でもないようなことでもボンボコと上げられるので、オコ（怒）になります。

そして、時間です。このプロダクトオーナーや開発者とのちょっとしたすれ違いが多い中で、スクラムマスターとしては、自分のチームのベロシティが下がらないように、コントロールしていきたい。下がっている状態が正しいチームもありますが、コントロールしていきたいのにすごく時間を使われるということで、スクラムマスターもオコ（怒）になります。

解決方法とメリット・デメリット

いずれも仮定の話ですが、そういうのがあるかなと思います。これらをどうやって解決しようかと考えます。解決策としては2つあるかなと思います。

1つは、テスターが開発者としてスクラムチームに参加する方法です。もう1つは、独立したQAチームが、スクラムチームを支援するという方法です。

（スライドを指して）独立したQAチームというのはこんなイメージです。テスターが集まっているQAチームがあって、スクラムチームに対して支援していくような感じです。

そこで、テスターが開発者としてスクラムチームに参加する場合の、メリットとデメリットをここに挙げています。1つは、コミュニケーションロスを最小にできるメリットがあります。

一方で、スクラムに開発者としてジョインするので、テストが得意な開発者としての振る舞いになるわけです。テスターという専門的な、悪く言うと「サイロ化されたような振る舞い方はちょっと困る」となるわけですが、それに対応できるテスターがどれだけいるのかという問題があります。

一方で、独立したQAチームがスクラムチームを支援していくという、この2番目がデメリットであることは明らかです。コミュニケーションロスが大きくなる。先ほどの図でも2つのチームの距離が遠いという話をしましたが、それがデメリットになります。一方で、中長期的な品質向上を考えた時に、そこにコミットしていきやすいメリットもあります。

さあ、どちらがいいでしょうか。みなさんの組織で、ぜひどちらがいいかを考える機会にしてもらえたらうれしいのですが、今回はこの2番目の事例、すなわち独立したQAチームがスクラムチームを支援してみた結果、わかったことをみなさんにシェアしたいという話です。

（次回につづく）