RSGT(https://2021.scrumgatheringtokyo.org)
で自身が参加したセッションのメモ&ふりかえりです。
ふりかえりの手法は、びばさんが配信しているPodcastである、ふりかえりAM ep.4(カンファレンス用のふりかえりをする例)で紹介されていたFun Done Learnを参考にしています。

概要

Janet Gregoryさん
Day2 (1/7) 10:00-11:30
あなたのチームや組織はどのように品質を測定していますか？
多くの場合、テストしていることが高品質と見なしています。
あなたが良いテストのプラクティスを持っているなら、それは高い品質の製品を作っていると言えるのでしょうか？
多くのチームはプロセスの品質を測定し、顧客が気にかけている製品の品質を忘れていることに気づいていません。
高品質の製品には多くのことが関わっており、テストは1つの側面にすぎません。開発プロセス（テストを含む）と組織が使用するさまざまなタイプの品質測定値との間の相互作用をJanetは調査します。
彼女は、「十分に良い」プロセスが、製品を顧客にとってより価値あるものに、どのようにできるかについての考えを共有します。製品の品質を測定するために使用できる様々なアプローチを見つけてください。

気になったことメモ

「品質は皆の責任です。品質を向上させることは生産性を向上させることに繋がります」 by Deming
- 生産性の定義には誤解が生まれやすいので注意
ワーク～どのお茶が一番ですか？～
- 緑茶/抹茶/紅茶
- この時、それぞれのお茶の茶葉とかランクについて考えた？
品質とは誰かにおいて価値があるものである by Weinberg
顧客だけが品質を判断できる by Jensen
品質には多数の定義がある
- 製造ベース/製品ベース/ユーザーベース(好み)/価値ベース(価値がある)/超越的品質(一目見ただけで素晴らしいと分かる)
- 品質は異なる視点でとらえられる可能性がある
- 株と債券のシステムをJanetたちはトレーダー向けに作っていた。ある時、バグがあるという報告が立て続きにあった。このバグは「フォントが小さすぎる」という内容だった。
  Janetたちはトレーダーからの報告だと考えていたが、トレーダー視点ではフォントが小さすぎるとは思えなかった。
  そして、内容を深堀していく内に、トレーダーの後ろにいる監督者からの報告だった。Janetたちはトレーダー視点の品質を考えていたが故に、監督者視点で品質の低い商品を作っていた。
テストとは何か？
- テストは常にやるものである。
- フィードバックをもらう
- 隠された前提を特定する
  - 同じプロダクトでも、目線が違うと異なる前提が見えてくることがある
- 製品がどういう状態にあるかを提供する
- 製品/ビジネス/技術的リスクを特定, もしくは軽減できる
- 品質についての評価を行う(誤解されがちだが、保証するものではない。品質担保するものでもない。)
アジャイルテストの四象限 by Brian Marick
- 縦軸 : 下に行くほど技術面を重視したテスト。上に行くほどビジネス面を重視したテスト。
- 横軸 : 左に行くほど開発面を導くテスト。右に行くほどプロダクトを批評するテスト。
- 第 1 象限（Q1）：開発を導く技術に面したテスト
  - TDD/Show me(他の人に自分のプロダクトを見てもらう)/コードを分析する/UAT
- 第 2 象限（Q2）：開発を導くビジネス向けのテスト
- 第 3 象限（Q3）：プロダクトを批判するビジネス向けのテスト
- 第 4 象限（Q4）：プロダクトを批判する技術に面したテスト
- 全象限を網羅すべき訳ではない。元々何もテストしていない状態からスタートする。
  その状態で、チーム内で話し合い「自分たちはどんなテストをしているのか」「考えついたテストはどの象限にあたるのか」をチームで考えることが重要
シフトライト/シフトレフトという言葉はJanetは嫌い。直線的なイメージを連想させるかが、開発はそうではない。
- 参考 : https://janetgregory.ca/testing-and-coding-not-coding-then-testing/
- シフトライト/シフトレフトという言葉が嫌いなので上記記事を改めようと考えている。
検証(Verification)と妥当性(validation)
- 検証(Verification) : バグがない
- 妥当性(validation)：顧客が満足するかどうか
ワーク～このカンファレンスは何点ですか？(1～5)～
- Janetの経験上、1をつける人も5をつける人もいるのではないかと推測している。ただし多くの人は2, 3, 4をつけるのでは？(会場ではほとんど4, 5で1をつける人はいない...)
- 1点が一番良い可能性もあった(明示的に、何点が最高化をJanetは言っていなかった)
- 上記前提がない状態で測られた指標で、カンファレンスの評価はできない。
品質をどう測定するか？
- サイクルタイム
- 重大なバグの数(バグの数を闇雲に数えるのはやめた方が良い。品質のごく一面しか評価できない。)
- 自動テストがall green
- 自動テストの数
- 手戻りのコスト
- テストカバレッジ
品質の測定指標に踊らされてはいけない(グッドハートの法則)
- 自動テストのパス数だけを品質に置いたら、無駄なテストケースをたくさん作るかもしれない
- バグがXX件以下ならOKとしたら、バグを報告しにくくなるかもしれない
- 品質項目をルール化するとろくなことが起きない
品質について、チームやお客さんと会話したことはありますか？なければすぐやってみて欲しい。品質とは何だろうか？チームで品質に対する考え方はずれていないだろうか？お客さんとは品質に対する考え方はずれていないだろうか？さらに進んだレベルなら、会社の社長は品質についてどう考えるか？
- 参考) クオリティスライダー(https://janetgregory.ca/part-4-testing-vs-quality-management/)
- 重要なのは品質についての話が始められること。目線がずれていることが分かることが大事。
あなた(のチーム)にとっての品質は何か？そこから考え始めて欲しい。その後、どうやって品質を(常に)テストするのか？を考えていって欲しい。
品質には多数の定義があり、複雑なものである。だからこそ、チーム/顧客/会社で共通理解をすることが大事。
テストはチームのコミュニケーションや学習に用いることができる。
品質を客観的に定義することは不可能。
スリーアミーゴス(https://www.agilealliance.org/glossary/three-amigos/)

楽しかったこと

ブロッコリーさん(JanetのAgile Test Condensedを翻訳した方)が、Janetの講演中に出た疑問に対して解説や見解を書いてくれていた。
Janetの豊富な例え話
satoryuさんのぼけw(1～5点のワークで、Janetが見ているチャットに10点を書き込むw)

やったこと

アウトプットを意識しながら話を聞いた
ワーク～どのお茶が一番ですか？～
Agile Testing Condensed の本を読み直しながら聞いた
Janetの会話を聞くことだけではなくて、参考記事を読んだりDiscordのチャット内容を見ながら講演を聞いた
ワーク～このカンファレンスは何点ですか？(1～5)～

学び

全員が共通理解をするためにテストする、という発想は理解できていたものの、現場でまだ実践できていない。
ユーザーと品質について会話する、はやったことなかった。是非取り入れてみたい。
まずは目線を合わせること。目線を合わせるために自身が持っている情報の開示をすることが大切。