QAを歩んだ先にあったスクラムマスター道
はじめに
スクラムマスター Advent Calendar 2023 の23日目の記事です。
本記事では、QAを十数年経験したのち、QAとスクラムマスター（以下、SM）の兼任として3年ほど活動してきた実体験を元にした学びを共有しています。
主に自分自身がQAとSMの経験を通じて感じた、定性的かつ主観的な内容となっていますので、参考程度にお願いします！
自己紹介
職務
QA15年以上
直近の3年くらいはQA兼スクラムマスター
一時的にPOだった時期もり
所属
4回ほど転職
1社目は独立系SIerで、以降はほぼベンチャー。
現在はサイボウズ株式会社に所属
もし興味あれば、以下もどうぞ！
この記事で伝えたいこと
QAはSMとの親和性が高く、SMに向いている
QAを突き詰めるとSM的な活動に行き着く
QAはもれなく全員SMになるべき（暴論）
スクラムマスターに向いているQAの特性
QAは以下に挙げるような特徴を持ちやすいと思っています。
ハブとしての役割
開発プロセス全体の改善
品質文化の醸成
ハブとしての役割
QAは品質という文脈で活動します。
品質を広い意味で捉えると、社内の様々な職種の方が関係してくると思います。
そういう意味で、QAは開発〜運用〜サポートにいたるまで、多くの人達と関わりを持つことが増えます。
SMも1チームを支援したとしても、チーム外の人たちを巻き込みながら改善しなければ全体最適に繋がらず、根本的な改善はできません。
SMにも以下のようなレベルが示されています。
開発プロセス全体の改善
QAのメインの活動は後工程になりがちです。
それを改善しようとシフトレフトを目指しているチームは多いのではないでしょうか。
シフトレフトを推進していくには、開発工程や仕様策定、要件定義の部分にも切り込んでく必要があります。
そうすると必然的に、全体の開発プロセスを把握することにつながります。
SMとしても、全体のプロセスを俯瞰して全体最適できるように支援するため、この特性もSMへの親和性は高そうです。
品質文化の醸成
品質文化が醸成されていない現場では、ろくなテストが行われず、マルっとQAに渡されるというケースがあります。
その場合、当然ですが多くの障害が見つかり、手戻りによってリードタイムが伸びる要因に繋がります。
そこでQAとしては、ただテストをするのではなく、開発メンバーに品質を向上させることの本質的な理由を伝えて行く必要があります。
スクラムも同じで、ただスクラムのフレームワークに従っていればいいというわけではありません。
SMはスクラムの原理原則を伝えて、開発チームには常に改善し続ける文化を醸成することが大事です。
QAを突き詰めるとSMに行き着く
以下は狩野モデルを簡易的に示したものです。
多くのQAは、当たり前品質を担保しつつ魅力的品質を向上させたいと思っているのではないかと（勝手に）思っています。
ただ僕の経験上、魅力的品質の向上に取り組んでいると胸を張って言える人は少ないように思います。（そして僕自身も）
よくあるケースとしては、当たり前品質を担保するだけで手一杯になってしまい、魅力的品質に取り組むだけの余力がなくなるケースです。
手一杯になるシチュエーションとしては以下のようなことが思いつきます。
機能的な品質が担保されておらず、バグが大量に出て対応に追われる
ほとんどのテストは手動で行われており、特にリグレッションにかける工数が膨大
シフトレフトが進んでおらず、後工程によるバグ検出による手戻り工数の増大
この問題を解決するためにはどうすればよいでしょうか？
銀の弾丸はないため、様々なことを試しながら泥臭く改善してくほかありません。
とはいえ、言えることとしてはQAが主に関わる工程だけで改善を続けても限界があるということです。
前述の「スクラムマスターに向いているQAの特性」でも伝えた通り、開発プロセス全体の改善や文化の醸成などが重要です。
そのためには、じっくりと全体最適につなげるために支援するSMという役割が都合が良いのです。
専任SMになるべき理由
別にSMにならなくても、QAとして全体最適に貢献できるでしょ？と思われた方もいると思います。
それは、全くその通りだと思います！
ただ、それには限界があるかなと思っています。
その理由の1つとしては、QAとSMとして担うタスクの性質の違いがあります。
それぞれを重要度と緊急度の4象限に当てはめてみます。
QAもSMもどちらも重要度の高い作業を担当しています。違いは緊急度。
QAの場合、直近のリリースがあるかもしれませんし、スプリントに収めるため緊急性の高い作業が多くなります。
一方、SMとしては中長期的な対策が主になっているため、今すぐやらなければならないという作業は少ないです。
QAだと目の前の作業に追われてしまい、SM的な活動はおざなりになってしまうのは必然です。
QAとSMの兼任も同様の理由で難しいです。兼任にしたところでQAで担う作業が変わりません。
個人的には、専任SMという方法は良い方法なのかなと思ったりしています。
他に伝えたかったこと（蛇足）
他にも盛り込みたい内容があったので、自分の備忘録的に残しておきます。
気が向いたら、記事にしたいと思います。
蛇足1：POとの親和性
同様の理由でPOにも向いている
蛇足2：QAとSMの兼務について
兼務も相当大変。帽子の切り替えが難しい。
自分も周りのメンバーも、どの立場での行動かわからなくなり、SMとして効果的に振る舞うことが困難。
蛇足3:魅力的品質へ向かう際の壁
魅力的品質に寄与するために必要なこと
蛇足4:QAの領域について
QAのメインは第一領域って話をしましたが、実際は第一領域を経て第二領域に行くのが良いかなと思ったりしてます。そして最終的にはSMと同様にチームにいなくても回るようになるのが理想かな、と。
会社のフェーズや思想によって、そのへんの是が非が変わってくるので今回はそこまで言及しませんが、また今度考えてみたいと思います。
終わりに
SMの方がいいぞ！という内容に思えたかもしれませんが、QAだろうがSMだろうがただの役割であり、手段に過ぎないと思っています。
大事なのはどんな役割であっても、ビジョンやゴールに向かってチャレンジしていくことなはず！
以下にも投稿しているので、よろしければどうぞ！
・シン・アジャイル Advent Calendar 2023 の23日目
・ソフトウェアテスト Advent Calendar 2023 の23日目
・ソフトウェアテストの小ネタ Advent Calendar 2023 の23日目
・子育てエンジニア Advent Calendar 2023 の23日目
・ふりかえり（裏） Advent Calendar 2023 の23日目