スクラムチームに入らない道を選んだ理由
河原田政典氏（以下、河原田）：第2章は「なぜスクラムチームに入らない道を選んだか」です。ここで、この話の背景となっている、僕の勤めている会社が出てきます。30年弱という、それなりに歴史のある事業会社で、2016年に開発部門ができました。Webやモバイルアプリ、LMS、ラーニングマネジメントシステムなどを開発しています。
その中でQAチームは、2019年1月に初めて1人のテスターの方が入社し、その後1年かけて人数を4人に増やし、やっとチームとして確立した状況です。テックブログとして『ビジョナリー・QA』という記事を書きましたので、そちらも参照してもらえるとうれしいです。
では、その背景です。我々がなぜ独立QAチームとしてスクラムにかかわっていくことを選んだかというと、そもそも人数が少なくて、物理的に全スクラムチームにアサインできなかったからです。
（スライドを指して）こんなイメージです。QAチームがこれだけ並んでいます。8つ星をつけてありますが、周りにスクラムチームがポンポンたくさんあるわけです。
こうなると、1人1スクラムに入っていくのも大変になってきています。だいたい、1人1スクラムに入っていくとすごく属人化していきますから、それよりはチームとしてきちんとやっていきたいと思いました。
2つ目に、テストだけでなく、あらゆる側面から品質に貢献するQAチームになりたいと思っています。
テストというものを考えた時に、何のためにやるかというと、品質を上げるためです。品質向上のための取り組みの1つとして、テストがすごく重要なのは確かですが、一方で、テスト以外にも品質を上げる取り組みはたくさんあります。
ただ、そのたくさんを具体的に示さないところが、僕のスライドの悪いところですが。海外でも「Let's Focus More on Quality and Less on Testing」と言われるくらい、品質というものに注力していこうという動きがあります。
3つ目に、今はQAチームとして動いているけれど、究極的にはQAチームが要らない組織として動いていきたい、そういうふうに仕上げていきたい思いがあります。以上のような背景があって、独立QAチームとしてスクラムを支援するという方法を選びました。
厳選したバグを報告することでできた協力的な体制
第3章は「独立QAチーム1年戦記」というタイトルを回収する章です。4つほど「実際のプロジェクトにこんなふうにかかわりました」という実例が出てきます。1つは、課金のプラットフォームの切り替えです。現状使用している課金のプラットフォームAがあります。そこに既存の顧客が紐づけられていて、課金業務が進んでいるわけです。
今後は、ここに課金プラットフォームBという新しいシステムを使っていきたい。その時に、新規の顧客は課金プラットフォームBを使い、既存の顧客は引き続き古い課金プラットフォームを使っていくようなところがあります。
この両方を活かさなければならない時に出てきたのが、広範なリグレッションテストです。新しい課金プラットフォームBを載せた時に、既存のお客さんに、不利益というか、Aのほうでバグが出ないかを確かめなければならず、大変スコープの広いプロジェクトでした。
そして、ここに対応するために2つのテストがありました。1つは、開発者が作ったテストケースを基にした形式的テストです。この形式的テストはISTQBといって、標準的なテストの用語ではスクリプトテストと呼ばれるものです。当社では形式的テスト（Formal Testing）と呼んでいます。
もう1つは、テスターが作ったテストチャーターを使って、探索的テストをやっていく感じです。
探索的テストというのは、単にアドホックにテストをするということではなく、LEARNINGとテストのDESIGNとEXECUTION（実行）を、サイクルで回していくやり方です。
この探索的テストをやる前に、開発者が作ったテストケースを使って、テスターの仕事を加速させようと考えました。当時の僕らがこの課金周りの仕様をどれだけ知っていたかというと、インプットされた分しか知りませんでした。要するに、開発者のほうがよく知っていました。
そこで、開発者がテストケースを作ってくれたので、最初はそのテストケースを消化することになりました。そうすると、不具合の傾向が見えてくるわけです。その不具合の傾向をインプットして、「じゃあ、次はああいうところを攻めてみようか」と、探索的テストで回し始めた。そしたらいい感じにバグが出てきた、といった流れです。
この、ボンとたくさん出てきたバグとか、不具合とか違和感みたいなものを全部報告すると、開発者に嫌われてオコ（怒）になってしまうので、自分たちの手元でまず、その不具合とやらが大事なものかどうかフィルタリングをかけました。そして、フィルタリングによってかなり数を減らした上で、開発者に渡しています。
おもしろいことに、この状態で渡すと開発者側は「あれ？ これだけしかなかったの？」と、だんだん不安になってくるわけです。そして、よくよく話をすると「いや、たくさんありますよ」となるわけです。そうすると開発者側は「あ、なるほどね。そうだよね。であれば、どれがバグなのかどうかは私たちも一緒に見ますよ」といい感じになり、一緒に取り組んでいく共働体制になりました。
このように、最初からボンと送りつけていたら開発者はオコ（怒）だったと思うのですが、あえて最初に絞り込んだことによって、協力的な体制になってくれた、ということがありました。1つ目は、厳選して報告したことです。
「安心感を得られるまでのテスト」に対しての共通認識作り
2つ目です。データテーブル更改というプロジェクトがありました。これも先ほどのように広範なリグレッションテストをしなければいけなかった一方で、リリースまでの期間が短いプロジェクトでした。これに関しては、POにテスターが寄っていくというか、スクラムの距離を縮めて取り組むことになり、密接なコミュニケーションを取りました。
要するに、期間や僕たちのできるテスト範囲が限られている中で、スコープを決めたというか、どこまでやれば安心感が得られるかを握った感じです。スクラムにはDefinition of Done、完了の定義という考え方がありますが、それに似ています。テストの完成の定義をここで握ったということです。「安心感を得られるまでのテスト」というところに対して共通認識を作って無事にリリースできたという感じです。
スクラムチームの目線と役割を考えてコミュニケーションをとる
3つ目は、iOSのアプリの大型アップデートをしました。大型だったのでフェーズが2つあります。
1つ目の「新アプリへの更新」に関しては、比較的スピードを重視する必要があったので、探索的テストを使ってやっていきました。看板ツールを使っていたので、どこまでテストが進んでいるかとか、どれだけのバグを見つけたかについて、トリビアルなバグ、マイナーなバグ、メジャーなバグ、クリティカルなバグのように、チケットをつけているわけです。
だから、みんな見ようと思えばいつでも見られるのですが、あえて週次ミーティングの場を使い、こんなふうにちょっときれいな感じにして、数値で見せてみました。そうすることによって、“透明性の確保”なんて言うとかっこいいかもしれませんが、そんなことをしました。それがフェーズ1です。
フェーズ2に入ると、今度は課金への対応があります。課金の発生するiOSアプリの開発には、必ずこのSANDBOXというアップルお手製の環境があり、ここでテストをする必要性が出てきます。
ところがこのSANDBOXさんがだいぶアレなので、僕らテスターとしては、「なんか不具合っぽい挙動になっているよね」といった時に、それがコードのせいなのか、このSANDBOXのせいなのかがわかりませんでした。
そこでの対応策は、やはりいつものようにスクラムチームに寄っていくわけです。距離を縮めていき、特にこのプロジェクトの場合は、スクラムマスターと頻繁にコミュニケーションを取ったわけです。何がバグで、何がSANDBOXの不具合なのかを見切っていくような、協調してその問題に取り組んでいくような対応ができました。
そういうわけで、QAチーム対スクラムチームのような構造にするのではなく、スクラムチームとQAチームをワンチームにして、解決すべき問題に向かっていくような構造を作った感じです。口で言うのは楽で、みんな「そうだよね」と言いますが、ワンチームと言うだけでは実現しません。大事なのはコミュニケーションなのです。
スクラムチームにはスクラムチームそれぞれの役割があって、その目線でそれぞれ何を考えているのか、何をしてくれたらうれしいのかを、テスターが考えていくようなことに取り組みました。
スクラムチームを介した共通DODの作成
4つめは、Scrum＠Scaleへの貢献です。会社では大規模スクラムを取り入れていますので、テスターとしてそこに対するアプローチもできるのではないかと思い、1年間取り組んでみました。
Scrum＠Scaleに関しては、みなさんググってもらえればいいと思いますが、スクラムマスターのサイクルと、プロダクトオーナーのサイクルが定義されていて、それらが有機的に関連しているような感じです。
大規模スクラムのやり方は、日本だとLeSSのほうが多い気がします。商業っぽいものは名前を出しませんが、ほかにScrum＠Scale、Nexus、Disciplined Agileなど、いろいろあります。
その中で、当社ではScrum＠Scaleを取り入れています。Scrum＠Scaleの流れの中、特にスクラムマスターズサイクルの中に、各スクラムのスクラムマスターが集まる会議帯があるのですが、そういったところで共通のDOD（Definition of Done）作りをリードしました。
いろいろなスクラムチームがバラバラある中で、こちらのチームが言っている“完成”と、あちらのチームが言っている“完成”に差がありました。そこで、各チームにヒアリングを行い、それぞれの共通ラインを探り出し、「最低限ここはクリアしよう」みたいなガイドラインを作りました。「それって本当にQAの役割なんだろうか」という気がしないでもないですが、「品質にかかわる仕事は、あらゆることをするよ」というのが僕の考え方です。
さらにもう1つ、プロダクトオーナーズサイクルというものがあります。こちらは、特にプロダクト全体としての一貫性といったところをみんなで考えるような動き方をしています。
特に、ユーザーストーリーの中でも受入条件として、こちらに対してアプローチをかけていく。シフトレフトもそうです。「早いうちから取り組んでいくとあとが楽だよ」と言うとすごく雑な言い方になりますが、そんな感じです。
協業の秘訣は丁寧なコミュニケーション
以上のようなことを行った結果、この1年間でQAやテスターというものの存在感を出せたかなと思っています。繰り返しになりますが、2020年1月にやっと4人でスタートしたQAチームなので、まず何の役に立てるのかを示さなければならなかったという経緯があります。
そこにいくつかあったプロジェクトの中の3つと、Scrum＠Scaleの貢献をピックアップして、お話しした次第です。
そして、この動きができたのはなぜか。協業の秘訣とは何かを、みなさんにちょっと考えてもらいたいと思っています。
独立QAチームとスクラムチームの協業、この秘訣はなんでしょうか。「もちろんQAチームはQAの人なのだから、テストの人なのだから、これでしょう！ 『卓越したテスト技術』」。確かに、探索的テストというものがあると紹介して、それを実践してみたり、たくさんバグを見つけるテスター目線みたいなところもあります。しかし、これは秘訣ではありません。
そうではなくて、月並みですが、「僕らが見出したのは、丁寧なコミュニケーションだよね」と思っています。コミュニケーションが大事です。コミュニケーションという言葉を使うと、なんだかみんな嫌うというか、構えちゃうというか、あまりいいイメージを持たれないのですが、僕は見過ごしてはいけないというか、取り組まなければならないという気がしています。
以上のような1年間を過ごしました。そして、「次はどうするの？」という話が次の章です。
（次回につづく）
