ScrumFestNiigata2023に参加してきました。
去る2023年5月19日~20日、Scrum Fest Niigata実行委員会主催の「Scrum Fest Niigata 2023」が開催されました。
参加させていただいて、その学びをお伝えできればと思います。
0. 前提として、仕事とは【人からの期待】に応えることである
仕事の中で、役割によって【人からの期待】されることは異なります。
特に、<QA>の役割は、Shift-left & right testingと言われており、大きく変わり、そして広くなっています。
1. 【人からの期待】に応えるには、その人と一緒に”Big Picture”を眺めて、その人の目線にフォーカスして対話する
- 登壇者：Daniel Maslynさん
- タイトル：Reaching the “Big Picture” In Testing and Quality /テストと品質における「全体像(ビッグピクチャー)」への到達
【人からの期待】は<PO>と<QA>ではズレることが多い
上の絵は、<PO>の人は「木」の全体を見ています。
つまり、Zoom Out（抽象化）して対話したいです。
しかし、<QA>の人が「葉」しか見えていません。
つまり、Zoom In（詳細化）しかしていません。
これでは、『なんかズレて、話が通じないな…』を思われてしまいます。
これは、<QA>の人は陥りがちです。
<QA>に対しての【人への期待】は欠陥を見つけることではなく、欠陥を評価することである
前段の説明ですと、皆さんと”Big Picture”のフォーカスが合っていないので、Zoom Inしますね。
<QA>の人は目の前の仕事、例えば、欠陥を見つけることにフォーカスします。
そして、「テスト実行」と「欠陥を見つけること」を繰り返します。
しかし、<PO>が<QA>に対しての【人への期待】は、欠陥を評価して、リスク分析をできていることです。
そして、<PO>は「欠陥が残っているが、リリースして良いのか？」の判断材料を<QA>から提示してほしいのです。
欠陥を残すのはなぜ？は略します。
欠陥がない状態でリリースはできるのでしょうか？
このように、Zoom Outをして、対話する相手の目線でみることが必要です。
Zoom Out（抽象化）とZoom In（具体化）は、やりすぎると対話ができない
Zoom OutとInをやりすぎるのも問題です。
上の絵ですと、
- Zoom Out（抽象化）：「森」は「SDGs」のため
- Zoom In（具体化）：「葉」は「原子」で構成する
まで考えしまうことです。
どちらも対話の中で、『え？いまその議論する？』の原因になるので、良い塩梅を考えたいですね。
2. テスト自動化への【人の期待】が無いのであれば、その人の興味があることで対話する
- 登壇者：ぱいん さん
- タイトル：PO,SMに送るテスト自動化の8原則に5箇条を添えてから
- スライド：https://speakerdeck.com/pineapplecandy/scrumniigata2023
自動テストが失敗する理由は、そもそも開発プロセスが整備されていないから
発表の中でYoshikiItoさんのテスト自動化お掃除ロボットをもとに、テスト自動化の効果をお話しされていました。
「お掃除ロボット」の例では、以下の効果があります。
- 「お掃除ロボット」が動きにくい → 家の物が邪魔だから
- 「お掃除ロボット」が動きやすい → 家の物がなくなるから → 家を綺麗にしておくという意識が働く
それを、「自動テスト」に当てはめると、以下の効果があります。
- 「自動テスト」が動きにくい → 開発プロセスが整っていないから
- 「自動テスト」が動きやすい → 開発プロセスが整っているから → 開発プロセスを綺麗にしておくという意識が働く
<PO>の興味は、プロダクトが早くリリースできることである
開発プロセスは、プロダクトを開発するために必要なことです。
そのため、開発プロセスが整うと、プロダクトが安定してリリースすることができます。
<PO>の興味は、そちらではないでしょうか？
「自動テスト」は「プロダクト」をリリースするための手段でしかありません。
つまり、
- 「自動テスト」を安定させるためには
- 「開発プロセス」が整っている必要があり
- それは、「プロダクト」が安定して早くリリースされることに繋がる
とアプローチすれば、自動テストへに対しての【人の期待】は高まるのではないでしょうか。
逆に、開発プロセスと自動テストが切り離されている、つまり、開発プロセスに自動テストが組み込まれていない（テストは後追いである）と、効果の説明が難しいです。
3. QAが外から支援をすると、【人の期待】と異なることが多く、それは人へ伝えるスキルが足りないからである
- 登壇者：Masami Morita さん
- タイトル：QAはチームの外から支援するのか?中から支援するのか?
- スライド：https://speakerdeck.com/moritamasami/scrum-fest-niigata-2023-qahatimunowai-karazhi-yuan-surunoka-zhong-karazhi-yuan-surunoka
会社の成長によって、<QA>は中から支援（インプロセスQA）だけではリソース不足になるため、外から支援（QAコーチ）が必要になる
上の絵の例ですと、
最初は、「プロダクトの数」と「インプロセスQAの数」が合っていて、問題はありません。
次に、会社が成長をすると、「プロダクトの数」が増えます。
その結果、「プロダクトの数」と「インプロセスQA」の数のバランスが取れないタイミングが発生します。
<QA>が外から支援（QAコーチ）をするには、人へ伝える、対話スキルが必要である
バランスが取れないと、プロダクトの重要度で優先順位を付けて低いものは、インプロセスQAは、QAコーチとして兼任して担当することになります。
ここで、問題が発生します。
それは、プロダクトCのチームの人は、<QA>に対しての『思った動きをしてくれないな…』と感じ始めます。
なぜなら、今まではその会社のチームでは、QA = インプロセスQAと認識されているからです。
さらに、QAコーチとして必要なスキルは、インプロセスQAと異なります。
それは、人へ伝える、対話するスキルです。
4. QAが【人の期待】に応えるには、何ができるべきなのか？を定義する必要がある
前段の続きです。
QAコーチが必要なスキルとして、人へ伝えるスキルがあることと伝えました。
しかし、Zoom Outして考えると、人への伝えるスキルは<QA>を構成する1つでしかないです。
なので、まずは、<QA>の持っているべきスキルを定義が必要なのではないでしょうか。
さらに、定義をもとに、QA組織のメンバーのスキルの棚卸が必要なのではないでしょうか。
スキルの棚卸をした結果、QA組織として弱い部分がわかります。
弱い部分がわかると、QA組織としてどのスキルを強化するべきか？がわかります。
そして、育成や採用の戦略を立てることが可能になります。
さらに、そのスキルを補うことが、【人からの期待】に応えるということに繋がり、自身のキャリアプランに反映する人も出てくるかもしれません。
<QA>の持っているべきスキル【QAスキルアセスメント】を学べるカンファレンスがある
実際に、freee株式会社様では、<QA>の持っているべきスキルを定義して、棚卸しをしております。
そして、実際にQAスキルアセスメントを作成された湯本さん（ymty / ゆもつよ）をお迎えして、その内容を余すことなく、聞けるカンファレンス「JaSST'23 Niigata」が「2023/9/22(金)」が開催されます。
前段で、「人に伝えるスキル」と抽象化して書きましたが、カンファレンスではZoom Inしてお話しします。
※ “02:ジュニアQAエンジニア > ID:25 > 疑問点を投げかけることができる”の部分
しかも、ScrumFestNiigata2023と同じ新潟で開催されますよ。
最後に
学びといいつつ、かなり私の解釈を交えてしまいました。
ただ、そのまま受け止めるのではなく、自分なりの考えを交えることは、自分の課題を整理できて、楽しかったです。
