Slide 1

Slide 1 text

QAスタイルファインダーの使い方 (フィクション) 2022/1/6 おおの やすよ

Slide 2

Slide 2 text

チームの現状 ● エンジニアが頻繁に退社していた。(過去の情報が引き継がれない) ● スパゲッティコードなので、改修に時間がかかる。 しかし、それを理解して いないマネージャに、詰められながら作ってきた ● マネージャの考えていることと異なる意見は受け入れられないので、開発 チームもQAチームも、マネージャに意見を言わなくなっている ● 開発チーム内では、相談を何度もしながら、設計・製造をしている ● いろいろこわいので、結合テストつくるときに、毎回、エンジニアにたくさん 相談して、どこまでどれくらいどんなテストするかを決めている

Slide 3

Slide 3 text

QAスタイルファインダーで表してみる QAスタイルファインダーにしてみたけど、 一つの軸でも、していることと、していない ことの両方がある このチームが、次のステップに進むための 課題を見出すためには、何か足りない? そもそも、このQAスタイルファインダーはど のスコープをあらわしているんだったっ け?

Slide 4

Slide 4 text

QAスタイルファインダーで表していたスコープと全体の構成  リーダー リーダー リーダー リーダー renewal 開発チームA renewal 開発チームB renewal 開発チームC 保守チーム マネージャ renewal  PM QAチーム スコープ=現場 保守作業がメインだが、 Renewalの開発タスクも実施する 開発チーム 保守のQA作業 がメインだが、 RenewalのQA タスクも実施す る マネジメント 組織のつながり 人の行き来 スコープ

Slide 5

Slide 5 text

チームの課題を表せているのか? 現場だけをスコープにしていると、 アカウンタビリティを果たしている方向(現場)と、果たしていない方向(マネジメント)がある ので、本当の状態を表せてない&課題もわからない →課題を明確にするために、スコープを拡げる必要がありそう →スコープを拡げたら、QAスタイルファインダーの軸のカスタマイズも必要そう どうしたら、チームの課題を表せるか ● スコープを拡げる(現場+マネジメントに) ● QAスタイルファインダーのアカウンタビリティを、現場とマネジメントの方向ごとに分け る ● アザタビリティも同様に

Slide 6

Slide 6 text

QAスタイルファインダーのスコープを拡げる  リーダー リーダー リーダー リーダー renewal 開発チームA renewal 開発チームB renewal 開発チームC 保守チーム マネージャ renewal  PM QAチーム 現場 保守作業がメインだが、 Renewalの開発タスクも実施する 開発チーム 保守のQA作業 がメインだが、 RenewalのQA タスクも実施す る マネジメント 組織のつながり 人の行き来 スコープ 追加分

Slide 7

Slide 7 text

新たなスコープを、 カスタマイズしたQAスタイルファインダーであらわすと アカウンタビリティとアザタビリティ →現場内とマネジメント向けの落差が大 きい →アカウンタビリティとアザタビリティが閉 じた範囲(現場内)しか機能していない →現場側は「 意見を言っても無駄。だか ら言わない」 →マネジメント側は「納得する説明がな い」、「もっと意見を言って」、「ちゃんと考 えているのか?」 カスタマイズした軸 カスタマイズした軸 マネジメントと現場に分ける

Slide 8

Slide 8 text

カスタマイズしてわかったこと:アカウンタビリティ 現場では話し合って、納得してタスクを進めている マネジメント向けには本当のことを説明しているのではなく、怒られない説明をしている、 あるいは、怒られないように発言を控える。 → 現場が説明責任を果たしてこなかったため、組織的な技術的負債がかなり貯まっ ている状態 現場 マネジメント向け

Slide 9

Slide 9 text

現状 カスタマイズしてわかったこと:アザタビリティ 現場では何か情報を持っていそうな人を探して 、いろいろ情報を引き出してお互い に協力しあってタスクを進めている マネジメント向けに、いろいろと協力してもらうため、懐に入り込む努力を開発チーム やQAチームはしていない。 →現場とマネジメントが、一体になっていない マネジメント 現場 本来

Slide 10

Slide 10 text

どうするか? ● マネージャへの対応から取り組む? ○ 開発チームにとって納得感のある決定になる よう、マネージャに都度説明を求める? ● 開発チームやQAチームの思いをそのま まにして? ○ 開発チームやQAチームは、マネージャと意 見が違ったら怒られるから、話したくないと 思っている →開発チームやQAチームまでが敵になる マネージャ 開発チーム 開発チーム マネージャ

Slide 11

Slide 11 text

方針:2階建てで進める 1. 現場が「マネジメント向けのアカウンタビリティに関する改善」を自分のことだと思う 方向を向かせる a. ふりかえりのKPTをしてみたが、かするものさえ出てこない b. 私がアカウンタビリティをチーム内から果たす 2. マネージャに対して、必要なアカウンタビリティを都度果たす。 a. ごろにゃんを使う b. トレーサビリティを意識する c. 網羅性を持たせる d. ロジックをきちんと組み立てて伝える e. アカウンタビリティとアザタビリティの両立

Slide 12

Slide 12 text

具体的には、こんなアプローチですすめる ● QAスタイルファインダーを共有してみる→改善を自分事にしてもらう ○ 「外部の勉強会で『QAスタイルファインダー』っていうのがあって、試しに作ってみたんだけど、ちょっと見 てもらえる?」 ○ どう思うか意見を聞く。 ● マネージャに、都度理由を聞いていく→アカウンタビリティとアザタビリティの両立 ○ マネージャのアカウンタビリティを引き出すために、アザタビリティを使う ○ 「いつも、いろいろご指摘を受けて、再検討に時間が掛かり、ご迷惑をおかけして申し訳ありません。でき れば、お考えをうかがって、今後に活かさせてください」 ● 報告書や見積の型をつくる→マネージャ向けの網羅性、ロジック組立 ○ 今は作成者ごとの工夫で乗り切ろうとしていて、型にまでできていない ○ マネージャが気にするところを可視化し、ブラッシュアップも重ね、再利用していく ○ いずれ、報告書や見積の書くポイントがマネージャの求める情報となっていく ○ 結果、メンバーのアカウンタビリティも向上し、 Win-Win!