QAがスクフェス新潟に参加して学んだこと

こんにちは。QAのくぼぴー(@kubop1992)です。 2024年5月10日にスクフェス新潟に参加したので、そこで学んだことを書いてみようかと思います。

スクフェス新潟とは

スクラムフェス新潟は、スクラムと名を冠していますが、同時にテストや品質について興味のある方が多く参加されています。コンセプトとしては以下のような内容を扱います。

特に以下のようなテーマに興味を持ちます。テストエンジニアリング、テストオートメーション、モダンテストマネジメント、アジャイルトランスフォーメーション、メンタルヘルス、アジャイルリーダーシップ、生成AI、コミュニケーションと関係性

スクフェス新潟にオンラインで参加していて、自身に興味のあるセッションばかりだと感じていたので、現地に行ってみたい！という気持ちがありました。

参加のきっかけ

スクフェス新潟のブースで掲示するアンケートボードをより良くするためのアイデアを提案し、QA目線で参加することでアンケートボードをより盛り上げて、品質の情報を社内外に広めるという目的で参加することになりました。

参加のきっかけは他チームの同僚のSlackのメッセージから始まりました。

スクフェス新潟でアンケートボードを用意する場合、そろそろ発注せねばなりません。

@kubop1992 QA目線だとどんな質問が嬉しいですか？

という質問がSlackで飛んできたので、

kubop: スクフェス新潟に来るQAエンジニアは、どの人もシフトレフトみたいなのは当たり前に考えていて、それをどう実現しているのか気になってる & 議論したいみたいな感じ...? 私がスクフェス新潟に参加して、オッ！ってなる企業が出してる情報で目に止まるのは、やっぱりシフトレフトについてどう考えて、どう実行しているかなので、実際問題現在どこからどうやってQAしてる？みたいなのをdevopsの輪の中にぽっちをつけるみたいな質問があると、現在自分が置かれている状況と、カケハシで行っているQAの話ができるし、話盛り上がって嬉しいかもって思いました。

という提案をしました。すると、次々と仕様が固まっていき...なんとその日にはおおまかなデザインが完成してしまいました。

CTO: くぼPが行くのめっちゃ良さそうだなスクフェス新潟参加して最近のQA事情を話す勉強会を社内でやっていただけるなら、スポンサーチケットで行っていただくの良いかも！

と言っていただき、参加させて頂くことになりました。

私としては、相談頂けたことがとても嬉しかったし、ずっと憧れていた現地での参加ができる機会を頂けて本当に感謝です。

スクフェス新潟における私の役割

QAとして、何ができるのかを考え、あらかじめテーマを決めて参加しました。

自分に出来ることは、これまでの経験をもとにスポンサーブースでQAの方とお話や質問をすること。スクフェス新潟の特色である品質についての知見、経験を吸収し社内に展開すること。だと考えました。

スポンサーブースを盛り上げる

スポンサーブースでは、以下のようなボードを設置しました。

"DevOpsで興味がある部分はどこですか？" という質問と、DevOpsのインフィニティループが描かれた、上下に空白のあるボードです。

このボードに集まり、解答してくださった方(主にQAの方)に、さまざまな質問をしてみました。

興味がある部分を選択した理由。
- PLANであれば、何が決まっているとQA的に嬉しいのか。
- CODE/BUILD/DEPLOYであれば、どのように関与したいと考えているのか。
- OPERATEであれば、どんな行動に興味があるのか。
- MONITORであれば、どんな指標が気になっているのか。
境界部分を選んだ場合は、その理由。

PLANを選択した方

PLANは、イベント1日目の段階で選択している方が多い印象でした。スクラムフェスらしいのですが、「顧客への価値」が明確になっていて欲しい、という意見が多かったです。 QAの方は、主にこの部分での仕様の整理をしっかりしたいという方が多く、さらにCODEとの境界部分に興味を持つ方がいて、この部分でPLANとCODEの行き来出来ると良い。というような意見がありました。

CODE/BUILD/DEPLOYを選択した方

CODEに関しては、内部品質に興味を持っているQAの方がいました。コードのアーキテクチャや、綺麗さ、リファクタリングについて話す場面がありました。外部品質のみならず、内部品質についてエンジニアと協力したい、という意見もありました。 QAはチーム内で、内部品質についてエンジニアと話し合いが出来る状態であるといいんだろうな、と思いました。

OPERATEを選択した方

OPERATEについては、テストの目線とユーザーの目線を分けて考えたい、という方がいました。テストの手順で発見される不具合と、ユーザー目線の不具合は異なるということでした。例えば特定の手順で発生するクリティカルな不具合と、ユーザー目線でイラっとくる不具合ではどちらを優先するべきか？というお話をしました。(イラバグと名付けた。もしかすると、これらの2つは分けて優先度を決めた方が良いのではないか、ということでした。

OPERATEの先に「ダメージ/エフェクト」という概念があるかもしれないという話が出ました。 MONITORのひとつなのかもしれませんが、DevとOpsが分かれている場合には「ダメージ/エフェクト」をDev側で想像することが難しいため、コード変更や仕様変更に「恐怖」が強く感じられてしまう症状があるのではと考えました。

MONITORを選択した方

MONITORでは、PLANにいかに活用できるデータを取得するか、という話をしました。この部分は、興味はあるがうまくできているという方は少なく、PLANに活用することが難しいという印象でした。というのも、PLAN時点で何がモニタリングされているのか、エンジニアしか知らないといった状態があり得るからということでした。（確かにエンジニアじゃない人が全てのデータベースを把握するのは難しいかもな...。) モニタリングしたい指標としてはCPUやメモリなどの指標や、ユーザーの行動、エンジニアの生産性など、切り口が異なるものがありました。(OKRもあったよ。)

品質・スクラムの情報を持って帰る

カケハシメンバーが登壇しているセッションを聴きたかった一方で、私は品質に関する知見を得るために以下のセッションに参加していました。

(※ 登壇資料が見つからなかったものはConfengineのページのリンクにしています)

主に、品質・スクラムに関するもの、さらに内部品質に関わるものを選択して参加していました。また、事前に自チームにおけるスクラムの課題、メンバーが知りたい情報をヒアリングしており、社外の方に問いかけを行っていました。

参加した中で特に印象に残ったセッションについて自分なりの考えを共有します。

境界を認識し、越境していくこと

The Boundaries of Testingというセッションでさまざまな次元の境界があることを学びました。それは、スキルかもしれないし、部署かもしれないし、プロセスかもしれない。どのような次元の、どのような境界なのかを知り、越境するのか、あえてしないのか。

セッションの中で、

テスターは価値をもたらそう

という文言がありました。境界をあえて用いるということも、越境するということも、まずはどのような価値を生み出すのかということを念頭に行動したいなと思いました。

グイグイ系QAエンジニアでやっていくよ！というセッションでは、QAというロールに捉われずにさまざまな役割を自ら「何が出来るのか」を考えて行動するという事例がありました。このセッションでは、「この人ならどう考えて行動するかな」ということを考え、仲間の行動に対してリスペクトを持って越境していくというQAとして重要なマインドが示されていました。

グイグイいくことで「恥ずかしい」と思ったり「逆に仲間を蔑ろにしてしまっているかも」と気にして越境できないことがあるため、ハッとしました。この2つのセッション同士は実はつながりがあるなと思っていて、価値のあるQAとは何かを学びました。

QA出身スリーアミーゴスでDeep Dive！スクラムで品質とスピードを意識したOne Teamを構成するために必要だったものというセッションや、スクラムチームが一体になるために行ったQAプロセス変革の道のりというセッションも、境界を越境する試みだったり、その手法だったりを学べてとても良かったです。

スプリントの価値を決める重要さ

教えて！スクラムコーチ！品質とスピードを両立させるにはどうすりゃいいの？というセッションでは、スプリントすり抜けバグという概念を学びました。

これは、該当スプリントで変更をしたコード以外のスプリントで変更したコードの不具合のことです。例えば、2スプリントあるとして、2回目のスプリントで、1回目のスプリントで仕込んだコードの不具合が発生した場合はスプリントをすり抜けたバグとして計上されます。このスプリントすり抜けバグは、リリース可能な状態としての品質基準の一つになりうるという話でした。(説明が難しいので、資料を見るといいかもです。)

これは、準備完了の定義・完成の定義、さらにはスプリントで対応する影響範囲を明確に決めていないとそもそも判断が難しい部分です。「すり抜けた」ということすら気がつけないかもしれません。さらに言うと、どのような価値をスプリントで達成するかという点を決めていないと、そもそも完成の定義が難しい状態になります。

例えば、スプリントで達成する価値を決めていない状態で、「ログイン機能をつくる」といったチケットが存在している場合、3スプリントで対応したとしても、どの時点で何の価値が達成されているか不明瞭なために3スプリント目で「パスワードに記号を入れるとエラーになる」という不具合が発生してもどのスプリントで仕込まれたコードなのか全くわかりません。

品質基準としてスプリントすり抜けバグは使えそうだなと思う一方で、まずはスプリントで達成できる価値について明確に決めるということをしたいなと思いました。

「始める」より、「終わらせる」を優先する

教えて！スクラムコーチ！品質とスピードを両立させるにはどうすりゃいいの？というセッションでは、チームでパラレルに案件が進んでしまう、ということがよくあるとセッション内で言及されていて、その際に、「始める」より、「終わらせる」を優先するという言葉が出てきました。これは自分の中でかなり刺さった言葉で、今までそのことについて考えたことがありませんでした。

経験上、1人で1週間、2週間のスプリント内で仕様を決め、実装し、テストする。というプロセスを完遂し顧客に届けるという作業は、かなりスピード感をもっていても達成することは難しいです。何故ならば、上記の作業は必ずチーム内外での協力が必要になり、メンバーはそれぞれに案件を抱えているため、そもそもコンテキストが異なる状態で認知負荷を乗り越えて作業しているからです。レビューは滞留し、精度が低くなり、品質も落ちます。

私はこの状態をあたりまえだと認識していたし、そういうものだと思っていました。

しかしながら、価値は顧客に提供したときに発生します。優先度の高い案件をランキングにして、複数件パラレルで動き、出来上がった順に提供するより、 1番優先度の高い案件を素早く届けた方がビジネス的に圧倒的に有利だと思いました。

同時にいっぺんに冷えた料理を出されるより、お腹が空いたタイミングで温かい食べたい料理が出された方が満足度が高いのです。終わらせるという点にピン留めした考え方、それが可能となるPBI分割方法などをしっかり学ばなければならないと思いました。