Scrum Fest Sapporo 2022 登壇を通して、うねうね考えていたこと
まだまだ先の話だと思っていた スクラムフェス札幌 も、気が付けばもう1ヶ月近く前の出来事となっていました。早いもんです。
というわけで、実行委員のいづさんに会いたい！という一心でプロポーザルを書いて、無事採択されたので札幌に行ってきました。
いづさんって誰？と思った方は下記参照
同僚の honamin がすてきなイベントレポを書いてくれたので、そちらもぜひ読んでください。
今回の発表はこんな感じ。
平鍋さんから反応いただいてびっくりしました。超嬉しい。
これは現実を捉えてでどうする？が書かれている、素晴らしい！ https://t.co/Pm4ciS6xTz
— Kenji Hiranabe (@hiranabe) November 5, 2022
とにかく自分たちが取り組んでいるE2Eテストの紹介がしたい！という新潟の発表 とは違って、今回はプロポーザルを書く段階からかなり悩みました。
その思考のうねうねをここに書き留められればと思います。
出発点は「QAだけアジャイルになれないもどかしさ」
1スプリント、2スプリントと時は流れていきまして
「ちょっと触ってみたいんだけど、開発のみんなそろそろいいかな？」
ところが開発チームのみんなは言います
「いやいや、まだQAさんにテストしていただけるところまで仕上がっていないんです」
「そっか、じゃあまた今度ね」
こうしてさらに1スプリント、2スプリント。。。ついにリリースの1ヶ月前になってしまいました
「あれ、統合テストしか もうやれないじゃん！」
このくだりは、スクラムチームのQA担当者になったばかりの自分が実際に体験したことです。
ウォーターフォール的な開発をずっとやってきた人にとって、アジャイルのサイクルの中で品質保証していくスタイルにシフトするのは簡単ではありません。
これは実装する人、テストをする人、どちらにも言えることです。
互いにテストが可能なタイミングを待って、最後の最後で重厚な統合テストをドカンと持ってきてしまう。それはすごくもったいないことだと思っています。
『実践アジャイルテスト』や『Agile Testing Condensed』に書かれているような取り組みも、読んですぐに実行に移せるものではありません。中には守備範囲の広さにめまいがしたかもしれません(自分はしました)。
だからこそ、もっと具体的な事例の発表が必要です。
ひとまず様子見しすぎて時を逃してしまうパターンから脱出してほしい！という思いで、当初「QAエンジニアがスクラムチームにJOINしたとき、すぐにできる活動リスト」のようなテーマを考えていました。
ターゲットを変更、そして採択されて
プロポーザルと書き始めてからすぐに「ちょっとこれは違うな」と考え直しました。
アジャイル札幌はソフトウェアテストに関心の強いコミュニティという印象を抱いていますが、あくまでメインはQAエンジニアではありません。アジャイルを実践するすべての人、というより幅広い層にとって気付きが得られるような内容に絞るべきでしょう。
その結果生まれたのが、「対話して、対話して、対話せよ！ 〜品質を前もって整えるチームへ〜」です。
ただこのプロポーザル、提出時期にちょうど実務で感じていた苛立ちが文章に滲み出すぎて、もう少しマイルドな書き方が出来なかったものか……と反省しました。
発表資料ではチーム全体の課題として考えられるようネガティブな表現を減らしたつもりではいますが、怒りを昇華させられるような話の展開にするのは結構難しかったです。プロポーザルは感情任せに書いてはいけない。
裏テーマ「スクラムマスターとQAエンジニアは、とてもよく似ている」
まだうまく理論立てて説明することはできないけれど「優れたQAエンジニアはスクラムマスター的にふるまっている」という仮説を立てています。
自分がCSM研修を受けた背景でもあります。
「より良い対話と議論を導こう」という今回の発表も、きっとスクラムマスターであれば共感してもらえるのではないかと思っていました。
発表前日に品川アジャイルさんのYouTube配信に飛び入りでお話させていただいたのですが、QAエンジニアがスクラムでどのような活動をしているか説明した際「それ、スクラムマスターやん！！」と反応いただけたことでより発表内容に自信を持てました。ありがとうございました。
(ちなみに序盤のしどろもどろぶりが恥ずかしすぎて、まだアーカイブを見ていません)
対話だけでは解決できない領域への挑戦
今回の発表では「対話」というソフトスキルに絞っていますが、当然ながらそれだけでアジャイルの世界を乗り切れるとは思っていません。
対話をする時間と精神的な余裕を作るために、テスト自動化や継続的デリバリーの強化が必要になるでしょう。
より深い対話を実現するために、知識の引き出しを増やす必要もあります。それは実装で採用しているアーキテクチャかもしれないし、ユーザーリサーチの手法かもしれないし、プロダクトマネジメントへの理解かもしれない。
スクラムマスターもQAエンジニアも、自身のことを「プロダクトのために何でもやる人」と言います。何でもやる人というのは、それだけ幅広いスキルが要されるという意味でもあります。
これからもその果てしなさに斬り込む発表ができますように。
この記事が気に入ったらサポートをしてみませんか？