QAなんなん？～みんなが納得できるQAのスタイルを見つけよう～ QAスタイルファインダーの使い方(フィクション)/qastylefinder

QAスタイルファインダーの事例です。
RSGT2022の「QAなんなん？～みんなが納得できるQAのスタイルを見つけよう～」の発表資料です。
https://confengine.com/conferences/regional-scrum-gathering-tokyo-2022/schedule/rich#session-29589-info

Transcript

1. QAスタイルファインダーの使い方 （フィクション） 2022/1/6 おおの　やすよ
2. チームの現状 • エンジニアが頻繁に退社していた。（過去の情報が引き継がれない） • スパゲッティコードなので、改修に時間がかかる。 しかし、それを理解して いないマネージャに、詰められながら作ってきた • マネージャの考えていることと異なる意見は受け入れられないので、開発 チームもQAチームも、マネージャに意見を言わなくなっている • 開発チーム内では、相談を何度もしながら、設計・製造をしている • いろいろこわいので、結合テストつくるときに、毎回、エンジニアにたくさん 相談して、どこまでどれくらいどんなテストするかを決めている
3. QAスタイルファインダーで表してみる QAスタイルファインダーにしてみたけど、 一つの軸でも、していることと、していない ことの両方がある このチームが、次のステップに進むための 課題を見出すためには、何か足りない？ そもそも、このQAスタイルファインダーはど のスコープをあらわしているんだったっ け？
4. QAスタイルファインダーで表していたスコープと全体の構成　 リーダー リーダー リーダー リーダー renewal 開発チームA renewal 開発チームB renewal 開発チームC 保守チーム マネージャ renewal　 PM QAチーム スコープ＝現場 保守作業がメインだが、 Renewalの開発タスクも実施する 開発チーム 保守のQA作業 がメインだが、 RenewalのQA タスクも実施す る マネジメント 組織のつながり 人の行き来 スコープ
5. チームの課題を表せているのか？ 現場だけをスコープにしていると、 アカウンタビリティを果たしている方向（現場）と、果たしていない方向（マネジメント）がある ので、本当の状態を表せてない＆課題もわからない →課題を明確にするために、スコープを拡げる必要がありそう →スコープを拡げたら、QAスタイルファインダーの軸のカスタマイズも必要そう どうしたら、チームの課題を表せるか • スコープを拡げる（現場＋マネジメントに） • QAスタイルファインダーのアカウンタビリティを、現場とマネジメントの方向ごとに分け る • アザタビリティも同様に
6. QAスタイルファインダーのスコープを拡げる　 リーダー リーダー リーダー リーダー renewal 開発チームA renewal 開発チームB renewal 開発チームC 保守チーム マネージャ renewal　 PM QAチーム 現場 保守作業がメインだが、 Renewalの開発タスクも実施する 開発チーム 保守のQA作業 がメインだが、 RenewalのQA タスクも実施す る マネジメント 組織のつながり 人の行き来 スコープ 追加分
7. 新たなスコープを、 カスタマイズしたQAスタイルファインダーであらわすと アカウンタビリティとアザタビリティ →現場内とマネジメント向けの落差が大 きい →アカウンタビリティとアザタビリティが閉 じた範囲（現場内）しか機能していない →現場側は「 意見を言っても無駄。だか ら言わない」 →マネジメント側は「納得する説明がな い」、「もっと意見を言って」、「ちゃんと考 えているのか？」 カスタマイズした軸 カスタマイズした軸 マネジメントと現場に分ける
8. カスタマイズしてわかったこと：アカウンタビリティ 現場では話し合って、納得してタスクを進めている マネジメント向けには本当のことを説明しているのではなく、怒られない説明をしている、 あるいは、怒られないように発言を控える。 → 現場が説明責任を果たしてこなかったため、組織的な技術的負債がかなり貯まっ ている状態 現場 マネジメント向け
9. 現状 カスタマイズしてわかったこと：アザタビリティ 現場では何か情報を持っていそうな人を探して 、いろいろ情報を引き出してお互い に協力しあってタスクを進めている マネジメント向けに、いろいろと協力してもらうため、懐に入り込む努力を開発チーム やQAチームはしていない。 →現場とマネジメントが、一体になっていない マネジメント 現場 本来
10. どうするか？ • マネージャへの対応から取り組む？ ◦ 開発チームにとって納得感のある決定になる よう、マネージャに都度説明を求める？ • 開発チームやQAチームの思いをそのま まにして? ◦ 開発チームやQAチームは、マネージャと意 見が違ったら怒られるから、話したくないと 思っている →開発チームやQAチームまでが敵になる マネージャ 開発チーム 開発チーム マネージャ
11. 方針：2階建てで進める 1. 現場が「マネジメント向けのアカウンタビリティに関する改善」を自分のことだと思う 方向を向かせる a. ふりかえりのKPTをしてみたが、かするものさえ出てこない b. 私がアカウンタビリティをチーム内から果たす 2. マネージャに対して、必要なアカウンタビリティを都度果たす。 a. ごろにゃんを使う b. トレーサビリティを意識する c. 網羅性を持たせる d. ロジックをきちんと組み立てて伝える e. アカウンタビリティとアザタビリティの両立
12. 具体的には、こんなアプローチですすめる • QAスタイルファインダーを共有してみる→改善を自分事にしてもらう ◦ 「外部の勉強会で『QAスタイルファインダー』っていうのがあって、試しに作ってみたんだけど、ちょっと見 てもらえる？」 ◦ どう思うか意見を聞く。 • マネージャに、都度理由を聞いていく→アカウンタビリティとアザタビリティの両立 ◦ マネージャのアカウンタビリティを引き出すために、アザタビリティを使う ◦ 「いつも、いろいろご指摘を受けて、再検討に時間が掛かり、ご迷惑をおかけして申し訳ありません。でき れば、お考えをうかがって、今後に活かさせてください」 • 報告書や見積の型をつくる→マネージャ向けの網羅性、ロジック組立 ◦ 今は作成者ごとの工夫で乗り切ろうとしていて、型にまでできていない ◦ マネージャが気にするところを可視化し、ブラッシュアップも重ね、再利用していく ◦ いずれ、報告書や見積の書くポイントがマネージャの求める情報となっていく ◦ 結果、メンバーのアカウンタビリティも向上し、 Win－Win！