This slides show the "No More QA" concept by Idealist in agile software development is not practical in Japanese.

1. 「もうQAはいらない」ってホントなの？それって美味しいの？
にし やすはる（@YasuharuNishi）

2. 「もうQAはいらない」なの？
• 開発者によっては「もうQAはいらない」という言葉を口にする人がいる
– こんな方がよく口にする
• アジャイル開発を極めた「雰囲気」を出しておられる方
• 完璧超人（© SEA-SIGSQA / テストの街「葛飾」）
– 神に認められた超人を祖とする自分たち以外の超人を「下等超人」と呼び見下すなど選民意識が高い
（「完璧超人」 - Wikipedia）
– テストやQAの議論には、
常にこの「開発者完全性仮説」がつきまとう
• 開発（者）が完璧だったらテストやQAはいらないよね？
• 完璧なスクラムチームだったら（以下略）
– それって人間が弱い存在であることを認めないってことじゃない？
© NISHI, Yasuharu
p.2
「もうQAはいらない」って
ホントなの？
「キン肉マン」 18巻

3. 例えば製造業の場合
• QAらしきものがいらない組織は確かにある
– ドリームチーム
– 完璧超人
– とても小さい組織（数人以下）
– 研究メインで商用の製品を作らない組織
– お客様の要求レベルがとても低い組織
• それ以外は、品質管理や品質保証を行わない組織などない
– 品質管理に力を入れている生産部門は多い
– 設計部門は設計部門で「設計技術向上」という名で品質向上を行っている
– やってない組織があったとしても、そのことを問題視しており、
品質に関する活動などいらない、という声にはならない
© NISHI, Yasuharu
p.3
https://sportiva.shueisha.co.jp/clm/
otherballgame/basketball/2021/01/26/2912/

4. 「もうQAはいらない」の正体
• QAらしきものがいらない組織で働いている
– ドリームチームさんですか？
• お客にテストをさせているという実態を理解していない
– フィーチャートグルなどを過信して、「バグがあったらすぐ引っ込めればいい」と本気で思っている
• （官僚的組織で）品質系の活動やスタッフがクソだった怨みを口にしている
– 「QAがレビューに参加しても、誤字脱字の指摘ばっかりで正直ジャマなんですよねー」
• その組織のどこにもQAを理解している人がいない
– 「うちのQAは自動テストと探索的テストでバッチリです！」
© NISHI, Yasuharu
p.4

5. では皆さんはソフトウェアのQAを理解してるのなの？
• 質問：どうしたら品質を「保証できた」と言えますか？
– テスト？レビュー？
• 全部はテストもレビューもできない
– メトリクス？信頼度成長曲線？
• ほとんど当たらない
– プロセスを定義して遵守すること？
• 手順書とフォーマットを与えられてもなぁ…
© NISHI, Yasuharu
p.5
実は、どうしたらソフトウェアの品質を
「保証できた」
と言えるのか、について
深く考えている人はあまりいない

6. ハードウェアにおける品質の「保証」
• どうやったら間違いがないことを保証できるんだろう？
– 「狙いの値（ex. 寿命）」と「ばらつき」に分ける
• 狙いの値
– 設計における材料の「狙いの値」は物性によって決まり、ほとんどは物理的・化学的に調べられている
– 生産における「狙いの値」は、作業を決めきることで実現できる
– 設計そのものの「狙いの値（設計解）」は、主に二つの方向から皆で考え抜き、皆が納得して共感する
» 良さ：筋のよい設計
» 悪さ：設計FMEAにおける故障モード
• ばらつき
– 同じ材料や同じ作業を統計的に測定して分析し、ばらつきの要因を減少させたりしながら、
一定の範囲内に収まるように管理する
– 狙いの値をきちんと達成し、ばらつきが十分少なければ、検査はゼロでもよい
• 検査をする場合には、悪さの知識に基づいて、
どこをどう検査するかを皆で考え抜き、皆が納得して共感する必要がある
– どこがどうおかしいか、って実は予想がとても難しいのよ
© NISHI, Yasuharu
p.6

7. 伝統的（？）ソフトウェア開発組織では？
• 材料の「狙いの値」を決めるために、
上流成果物を徹底的にレビューし、プロセスを定義して改善しない
– そのため重厚長大なプロセスになりやすい
• そもそもソフトウェア開発におけるプロセス定義は改善のためであった（CMMi/SPICE）が、同時期に普及した
2者間取引のための契約内容遵守の一つであったISO9000sと混同されたため、誤解・誤用されるようになった
• 生産の「狙いの値」を決めるために、
作業手順書を細かく書いたり、用いる技法を決めたりする
– しかし「考える」という手順を決めきることは本質的にできないし、
「考える」やり方は人によって異なるので細かい作業手順書は邪魔にしかならない
– 開発技法を決めたところで、
「考える」やり方を決めきれるわけではないので何かを保証したことにはならない
• 設計の「狙いの値（設計解）」を決めるために、
モデリング力を向上したりデザインパターンを活用する
– バグのパターンを活用している組織は残念ながら少ない
• ばらつきを小さくするために、メトリクスを測定して統計的に管理しようとする
– 同じ材料や同じ作業ではないので統計的に管理することはできず、
メトリクスの測定の負荷だけが現場にのしかかる
© NISHI, Yasuharu
p.7

8. 伝統的（？）ソフトウェア開発組織では？
• 狙いの値を達成できないし、ばらつきも小さくできないので、テストを大量に必要とする
– 悪さの知識がないし、どこをどうテストするかを皆で考え抜いて納得感を共感するようなことは
なかなか行われない
– 納得感を共感する代わりに
「偏りのある開発者じゃなくて第三者がテストするから大丈夫です」というロジックを誤用しだす
• このロジックは「第三者」がどこをどうテストするかを皆で考え抜いて納得感を共感できることが前提となっているが、
第三者テスト会社でそれができるところはごく少数である
• そのため、「何も考えずに片っ端からなぞる」と「偏りのある開発者じゃなくて
（別の偏りのある）QA/テストエンジニアがテストする」という方法になってしまう
– 大量のテストを時間内に終わらせるために自動化が必要となるが、
多重下請・工数精算のビジネスモデルを脅かす上に、
そもそもどこをどうテストするかを皆で考え抜いて納得感を共感することができていないので、
自動化をやっても誰も嬉しくない
• そもそもソフトウェア開発組織では、テスト専門組織に絞っても、
なぜその基準で品質を保証できたことになるのかを
深くきちんと理解している人はほとんどいない
– なぜ単体テストはカバレッジだけを気にすればよいのか
– なぜテストの中身を反映させずに測定したプロダクトメトリクスで判断できるのか
© NISHI, Yasuharu
p.8

9. ハードウェアの品質保証を丁寧にソフトウェアになぞらえると？
• 材料が無いので、設計における材料の「狙いの値」はありえない
• 作業を決めきることができないので、生産における狙いの値はありえない
– そもそもソフトウェアに生産工程は存在しない
• 設計そのものの「狙いの値（設計解）」は、
主に二つの方向から皆で考え抜き、皆が納得して共感する
• 良さ：デザインパターン
• 悪さ：バグパターン
• 同じ材料や同じ作業はないので共通のものや共通の作業を経験で括りだし、
リスクが少なくなるよう改善するが、一定の範囲内に収まるように管理はできない
– リスクが減りそうかどうかは、皆で考え抜いて納得して共感する
• 考える手順を細かく指示しなくても、考える単位を小さくすると上手に考えやすくなる
– t-wada流TDDや反復型開発
• 狙いの値を達成できないし、ばらつきも小さくできないので、テストを大量に必要とする
– 悪さの知識に基づいて、どこをどうテストするかを皆で考え抜き、皆が納得して共感する
– 皆が考え抜くことに集中するために、人間が時間をかける必要のない作業を自動化する
© NISHI, Yasuharu
p.9

10. QAは品質を保証しないの
• ソフトウェアは「皆で考え抜いて納得感を共感すること」によって品質を保証する
– 決して、何かを盲目的に遵守したり、基準を決めて守らせたり、規格認証を取得したり、
膨大にテストをすることではない
• ソフトウェアにおいて品質が保証できないこと
– 考え抜かないこと
– 納得感のないまま進めること
– 誰も共感しない、もしくは一部の人だけが共感すること
• どんな得意技が必要？
– QA：「皆で考え抜いて納得感を共感する」ことができるようになるよう寄り添うスペシャリティ
– TE：「（悪さの知識に基づいて）どこをどうテストするかを皆で考え抜き、皆が納得して共感する」スペシャリティ
– PE：「皆が考え抜くことに集中するために、人間が時間をかける必要のない作業を自動化する」スペシャリティ
– 複数の得意技を1人が兼ね備えてもいいし、複数人で分担してもいい
• すなわち、QAやTE（、PE）が品質を保証するわけではなく、
チームだけでなく組織全員で品質を保証することが必要になる
– QA: Quality Assurance
– TE: Test Engineer
– PE: Platform Engineer, a.k.a. SET or Automator
© NISHI, Yasuharu
p.10

11. QAらしきものがいらない組織
• ドリームチーム
– 皆で考え抜くし、皆スゴイので自然に納得感を共感できる
• 採用が難しいのでスケールしない
• 完璧超人
– 一人が考え抜いて皆が従うので共感がいらない
• 完璧超人がいなくなると品質が急降下する
• とても小さい組織（数人以下）
– 皆で考え抜くし、顔が見えるので納得感を共感できる
• チームに馴染ませながら人数を増やすのに時間がかかる
• 研究メインで商用の製品を作らない組織
– 実運用を考えずに特定の技術のみを考え抜けばよく、一人の納得感があれば共感は必要ない
• 実運用を考えるよう技術力を高めることと、納得感の共感が必要だと分かってもらうのが難しい
• お客様の要求レベルがとても低い組織
– 納得感が必要ない
• 「greater fool theory」なビジネスは持続可能性が低い
• 要求レベルが上がったときに達成できるよう技術力を高めるのが難しい
© NISHI, Yasuharu
p.11
「キン肉マン」 18巻

12. 「もうQAはいらない」と思ったら？
• 自分はドリームチームに所属するスーパースターであるのなら
– ずっとドリームチームにいられるよう、QAのことなんか気にせずにスキルアップしてください
• 自分はQAらしきものがいらない特殊な組織にいると思ったら
– 持続可能性が低いので、QAが必要だというマインドセットを身につけましょう
• 自分はQAについて深く考えたことがなかったのなら
– 品質を保証するとは一体なんなのか、を深く考えつつ、世の中の色んな情報に触れましょう
• 有名な人が、権威が、教科書が、専門会社が言ったから正しいとは限りません
• 以前接した品質系の活動やスタッフがクソだった怨みがあるのなら
– 今度は自分の手で皆から感謝されるQA活動をしましょう
© NISHI, Yasuharu
p.12

13. 「もうQAはいらないの？」ってホントなの？
• 「もうQAはいらない」って思ったら
– QAらしきものがいらない組織の場合は、持続可能性が低い開発スタイルでないかを疑いましょう
• ドリームチーム、完璧超人、開発者完全性仮説
– どうしたらソフトウェアの品質を「保証できた」と言えるのか、
について深く考えられるのでしょうか？
• ソフトウェアの品質は、ハードウェアのように保証できるわけではない
• 「皆で考え抜いて納得感を共感する」ことを
チームだけでなく組織全員でやるようなマインドセットを身につけましょう
• 品質を「保証する」というのは、とても深遠な行為なのです
© NISHI, Yasuharu
p.13

14. 「やっぱりQAはいるよね」と思ったら？
• 品質を保証するとは一体なんなのか、を深く考えつつ、
世の中の色んな情報に触れましょう
– 有名な人が、権威が、教科書が、専門会社が言ったから正しいとは限りません
• 品質を「保証する」というのは、とても深遠な行為なのです
• 自分の組織やチームで
「皆で考え抜いて納得感を共感する」ために何をしようか
を考えて実践してみましょう
– 「皆で考え抜いて納得感を共感する」ことを
チームだけでなく組織全員でやるようなマインドセットを身につけましょう
– QA/TE/PEといった得意技を身につけて、
いつも 「皆で考え抜いて納得感を共感する」組織体質に近づけていきましょう
• QAは導くというよりも「寄り添って自律できるようにする」ことがミッションです
• 考える途中で疑問に思うことがあったり、何か考えがまとまったり、
実践してみたりしたら、JaSST (nano)などで話してみましょう
– Twitterで誰かと会話するのもよいですよ
• @YasuharuNishiに話しかけてみてください
© NISHI, Yasuharu
p.14

15. 不自然な誘導：JaSST北海道 on 2022/7/15（金）
© NISHI, Yasuharu
p.15