---
title: アジャイル開発 QAチーム不要論
tags:  #qa #アジャイル #web制作 #品質管理  
author: [rhdoh](https://convert.docswell.com/user/7533020536)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/4EQX4LPX7P.jpg?width=480
description: アジャイル開発で独立したQA組織は必要でしょうか？ アジャイル開発でのQAの役割って何？ QAが直面する課題と解決策を、例示を交えてご紹介します。 ※引用文献の記載がない箇所、および、参考文献のみの箇所は、個人の意見です  Do we need a Independent QA Team for Agile Development? What&#039;s the role of QA during agile development? There are some examples of the problems faced by QA and their solutions also.  And notes that all of these solutions suggest that an independent QA team is not necessary. As it&#039;s just my opinion,  this slide is in Japanese language only.
published: January 29, 23
canonical: https://convert.docswell.com/s/7533020536/53P4JK-2023-01-29-141559
---
# Page. 1

![Page Image](https://bcdn.docswell.com/page/4EQX4LPX7P.jpg)

アジャイル開発
QAチーム不要論
Need a Independent QA Team for Agile Development?
@s_rhdoh


# Page. 2

![Page Image](https://bcdn.docswell.com/page/KJ46QDY271.jpg)

こんな⼈向け
● アジャイル開発でQAを導⼊したけれど、スプリントを圧迫して
上⼿くいかなかった
● ⾃動テスト、ノーコードで全部組みたい
● ⾃分のPJではテストしている暇はないからテストを効率よく削り
たいという気持ちがわいてる
取り扱わない話
ウォーターフォール開発ではQAチームは必要か
そうじゃない⼈はブラウザバックでOK
このテンプレートは
© Presentation Design
からお借りしています（テーマカラーは変えています）


# Page. 3

![Page Image](https://bcdn.docswell.com/page/LE1VPZ6K7G.jpg)

Contents
1. 現PJで困ったこと
2. 解決策（案）は４つ
3. どの解決策も「QAチーム」はいらない
3


# Page. 4

![Page Image](https://bcdn.docswell.com/page/GEWL29WP72.jpg)

1. 現PJで困ったこと
因⼦⽔準の多い
NEW
ECサイト ＋ 別サイト
Hybrid Agile
• 全体⼯程はウォーターフォール
• スプリント管理と思想がアジャイル


# Page. 5

![Page Image](https://bcdn.docswell.com/page/47ZMD956E3.jpg)

1. 現PJで困ったこと
NEW
別サイト
スプリントは2週間
10⽇だよ！


# Page. 6

![Page Image](https://bcdn.docswell.com/page/YJ6N1K9LJV.jpg)

1. 現PJで困ったこと
NEW
別サイト
ポイントギリギリ
ヨシッ
設計1 設計2 設計3
レビュー
テスト
バック修正
実施準備


# Page. 7

![Page Image](https://bcdn.docswell.com/page/GJ554PNMJ4.jpg)

1. 現PJで困ったこと
NEW
別サイト
決まるはずの
仕様未確定
あふれる
設計1 設計2
臨時
リファイン
メント
設計4ʼ
テスト
レビュー
バック修正 実施準備


# Page. 8

![Page Image](https://bcdn.docswell.com/page/LE3NG329E5.jpg)

1. 現PJで困ったこと
NEW
別サイト
mtgで詳細を詰め切らない /
コミュニケーションエラー
テスト対象間違い
あふれる
設計1 設計2
設計１
(再設計)
設計3
テスト
レビュー
バック修正 実施準備


# Page. 9

![Page Image](https://bcdn.docswell.com/page/8EDW14Z87G.jpg)

1. 現PJで困ったこと
スピードが⾜りない
コミュニケーション不⾜
仕様が決まらない


# Page. 10

![Page Image](https://bcdn.docswell.com/page/V7P9QMDWJ8.jpg)

1. 現PJで困ったこと
現PJは まさにこんな状態
因⼦⽔準が多い
“製品が大きくなるにつれテスト量は飛躍的に増加し、QA チームは常に付
いていくのに必死です。プロジェクト所有者は、リリースを遅らせるか、
テストをスキップするかという望ましくない選択に直面します。(99% どち
らが勝つか、おわかりでしょう?)
一方、開発チームはすでに他の作業に着手しています。つまり、技術的負
債が積もるだけではなく、それぞれの不具合に取り組むことにより、コー
ド ベースの 2 か所の間でコンテキスト切り替えが必要となり、大きな犠牲
がともないます。何ともばかげた損害です。”
–DAN RADIGAN/ATLASSIAN
「アジャイルテストのプラクティスを通じてさらなる⾼品質を実現」


# Page. 11

![Page Image](https://bcdn.docswell.com/page/2JVM5919JQ.jpg)

1. 現PJで困ったこと
コミュニケーションで解決は可能
ただ⼈は間違える
仕組み化・環境づくりが⼤事


# Page. 12

![Page Image](https://bcdn.docswell.com/page/5EGG6Z24EL.jpg)

2. 解決策（案）
• アジャイル開発事例
• AATDの良書


# Page. 13

![Page Image](https://bcdn.docswell.com/page/4JQX4LPREP.jpg)

2. 解決策（案）は４つある
▍アジャイル開発事例
”アジャイルテストのプラクティスを通じ
てさらなる⾼品質を実現”
/ 作成者 DAN RADIGAN
⼤規模アジャイルより
（アジャイルに関するページが豊富）
ATLASSIAN
「⼤規模アジャイル」トップページ
(2023.01.16時点)


# Page. 14

![Page Image](https://bcdn.docswell.com/page/K746QDYQE1.jpg)

2. 解決策（案）は４つある
▍ATDD良書
著者は10年くらいリーン⽣産⽅式やア
ジャイル⽣産⽅式で開発するためのチー
ムワークを実践。WIkiでの参照が多いか
ら読んでみた。2010年の本だけど事例
ベースでめっちゃわかりやすい。TDDと
ATDDとの違いがくっきりしている
Amazon(Kindle)
¥3000以内で読める！
Lean Agile Acceptance Test-Driven-Development (2010)/ Ken Pugh


# Page. 15

![Page Image](https://bcdn.docswell.com/page/LJ1VPZ6LEG.jpg)

2. 解決策（案）は４つある
1
QAを開発チームへ分散
導⼊しやすさ
★★☆
コミュニケーション改善
仕様決定促進
事例）楽天, Base, ATLASSIANなど多数
3
探索的テストの活⽤
導⼊しやすさ
★★☆
スピードアップ
事例）現PJ, ATLASSIAN など
2
テスト⾃動化
導⼊しやすさ
★★★
スピードアップ
事例）現PJ, メルペイ, ATLASSIANなど多数
4 受け⼊れテスト駆動開発
導⼊しやすさ
コミュニケーション改善
★☆☆
仕様決定促進
スピードアップ
事例）Base, SmartHR など


# Page. 16

![Page Image](https://bcdn.docswell.com/page/GJWL29WQE2.jpg)

2. 解決策（案）は４つある
1
QAを開発チームへ分散
あなたが本当に欲しいものはQA組織ですか？
“もし、「開発者がテストをする時間がない」のであれば、QA組織を作っても同じこと
が起きます。
開発もテストももともとは表裏⼀体、ひとつです。どちらかを減らすことはできませ
ん。テストをする時間がなければ取ればいいはずです。開発者なら⾃動化も⽐較的楽に
進められます。開発量が少ないなら、開発者を採⽤すればいいはずです。”
“アジャイル開発とQA（品質保証）は相性がバツグンに悪い” (accessed: 2023.01.16 )
/ mablなどの スーパーアジャイルコーチ
Dai FUJIHARA


# Page. 17

![Page Image](https://bcdn.docswell.com/page/4EZMD953J3.jpg)

2. 解決策（案）は４つある
そもそもQAが注⼒する領域ってなに
スペシャリスト
• テストアーキテクチャ設計
• メトリクスの可視化
• テストコードとカバレッジを理解
• ホワイトボックステストの精査
• 探索的テストの設計
• テストプロセスの評価
マネージャ
• テスト⽬的とリスクの整理
• テスト全体の活動計画の⽴案
• テストプロセス全体の最適化
• テストツールの選択と実装⽀援
• 各組織へのQA活動の発信
客観性担保のため外部テストベンダーによるテスト実施とできるとBetter
参考
”QA組織が最後の砦から脱却するために”(2021)
/
Akatsuki Tomotaka Yamasaki


# Page. 18

![Page Image](https://bcdn.docswell.com/page/Y76N1K9Z7V.jpg)

2. 解決策（案）は４つある
“開発者はコードに関する問題を解決する
ことが得意である。
開発者は作成したテストが失敗した時
に、他の誰よりもそれを修正する能⼒が
ある。
開発者はフィーチャー要件とテストの意
義を理解して、より良いコードを作成す
るものである。”
アジャイルテストのプラクティスを通じてさらなる⾼品質を実現
/ DAN RADIGAN
内の”Quality at Speed”の解説
※フィーチャー：機能の⼩さな塊
ATLASSIAN”Quality at Speed” / Penny Wyatt


# Page. 19

![Page Image](https://bcdn.docswell.com/page/G7554PN974.jpg)

2. 解決策（案）は４つある
“これは、開発者が単独で作業するという
意味ではありません。チームに QA エン
ジニアがいるということも重要です。
フィーチャーの開発にとって QA エンジ
ニアは重要な視点をもたらすうえ、優れ
た QA エンジニアはバグが隠れていそう
な場所を認識しているため、予測して開
発者にアドバイスできます。”
アジャイルテストのプラクティスを通じてさらなる⾼品質を実現
/ DAN RADIGAN
内の”Quality at Speed”の解説
※フィーチャー：機能の⼩さな塊
ATLASSIAN”Quality at Speed” / Penny Wyatt


# Page. 20

![Page Image](https://bcdn.docswell.com/page/9J2NV655ER.jpg)

2. 解決策（案）は４つある
QAチームいらないかな
そして、QAはテストだけではなく
探索的テスト観点を
コーチングする技術を学ぼう


# Page. 21

![Page Image](https://bcdn.docswell.com/page/DEYP39K6EM.jpg)

2. 解決策（案）は４つある
2
テスト⾃動化
すべて⾃動テストにするのはきついのでは？
“Do not automate everything.”
ー なんでも⾃動化するんじゃない
Lean Agile Acceptance Test-Driven-Development (2010)/ Ken Pugh


# Page. 22

![Page Image](https://bcdn.docswell.com/page/VJN5VLZ178.jpg)

2. 解決策（案）は４つある
アジャイルでのテストフレームワーク
Agile Testing Quadrants
⾃動化
スコープ
Trends in Agile Testing by Lisa Crispin (2009)
/Lisa Crispin, Janet Gregory
Test Matrix
⾃動化
スコープ
Lean Agile Acceptance Test-Driven-Development (2010)
/ Ken Pugh


# Page. 23

![Page Image](https://bcdn.docswell.com/page/YE9Y64ZYJ3.jpg)

2. 解決策（案）は４つある
各テストボリュームの考え⽅
Unit 単体テスト
• 基本機能のみが期待通りに動作すること
• カバレッジに拘らない（諸説あり）
• あまり細分化とモック化をやりすぎると
TDDが死んでしまう
“TDD is dead. Long live testing.”(2014)
(TDDは死んだ。テスト万歳(万歳と持続可能なテストをかけて
いるっぽい))/David Heinemeier Hansson
Testing Trophy from “TESTING JAVASCRIPT” / Kent C. Dodds


# Page. 24

![Page Image](https://bcdn.docswell.com/page/GE86ZQ1K7D.jpg)

2. 解決策（案）は４つある
各テストボリュームの考え⽅
Integration 内結テスト
• [Testing Trophy]の考えを採⽤するな
ら、内結テストの⾃動化を充実させる
• コードによる⾃動化が⼀般的
（JavascriptならJest + React Testing
Libraryなど）
Testing Trophy from “TESTING JAVASCRIPT” / Kent C. Dodds


# Page. 25

![Page Image](https://bcdn.docswell.com/page/LEL9DXQPJR.jpg)

2. 解決策（案）は４つある
各テストボリュームの考え⽅
End to End 総合テスト
•e 2 e テ ス ト は そ こ そ こ ( コ ー ド
Playwright, Cypressなど、 ノーコード
だとAutify, mablなど)
• ノーコードは実装が早い！課⾦が⾼い。
フレイキーになりがち（現PJでは
Autify → mabl乗り換えの結果フレイ
キーさが減ったけれどまだフレイキー）
Testing Trophy from “TESTING JAVASCRIPT” / Kent C. Dodds


# Page. 26

![Page Image](https://bcdn.docswell.com/page/4JMZPL12EW.jpg)

2. 解決策（案）は４つある
QAはe2eテストならできる
でもそんなに⼈数いらないかな


# Page. 27

![Page Image](https://bcdn.docswell.com/page/PJR61KL579.jpg)

2. 解決策（案）は４つある
3
探索的テストの活⽤
探索的テストとは
“探索的テストはリスクベースで、批判的思考によるアプローチです。リスクに関する
ナレッジ、実装の詳細、カスタマーニーズを⽤いてテストを実施できます。
〜中略〜
開発者や QA エンジニアはテストケースのスクリプト、詳細なテストプラン、要件など
を必要とせず、問題を早急に包括的に発⾒できます。”
アジャイルテストのプラクティスを通じてさらなる⾼品質を実現/ DAN RADIGAN


# Page. 28

![Page Image](https://bcdn.docswell.com/page/PEXMYLWX7X.jpg)

2. 解決策（案）は４つある
２派ある


# Page. 29

![Page Image](https://bcdn.docswell.com/page/3EKG3LV9JD.jpg)

2. 解決策（案）は４つある
主要なテスト
テストケース作成の上実施
条件が複雑なテスト
探索的テストにて担保


# Page. 30

![Page Image](https://bcdn.docswell.com/page/L73NG3M975.jpg)

2. 解決策（案）は４つある
主要なテスト
探索的テストにて担保
条件が複雑なテスト
テストケース作成の上実施


# Page. 31

![Page Image](https://bcdn.docswell.com/page/87DW1468JG.jpg)

2. 解決策（案）は４つある
取り⼊れようとしています


# Page. 32

![Page Image](https://bcdn.docswell.com/page/VJP9QMYWE8.jpg)

2. 解決策（案）は４つある
テスト観点
（ボタン特殊押下やテキストボックス特殊記⼊など）
その他汎⽤的な
テスト観点を
テンプレ化し、
準備時間はゼロ
該当テスト観点にて
⾏う操作をリストアップ
• 不具合があれば、フォーマットに記録を残す
• なくても何をしたかの記録が残る
実施テンプレ（画⾯はだせないので概念のみ）


# Page. 33

![Page Image](https://bcdn.docswell.com/page/2EVM59G9EQ.jpg)

2. 解決策（案）は４つある
いつか開発だけで
探索的テストできるように
なるんじゃないかな


# Page. 34

![Page Image](https://bcdn.docswell.com/page/57GG6Z847L.jpg)

2. 解決策（案）は４つある
4 受け⼊れテスト駆動設計(ATDD)
受け⼊れテスト駆動設計とは
“ Jeff Sutherland, the cocreator of Scrum, has metrics on software productivity
[Sutherland01]. He has found that adding a quality assurance person to the
team and creating acceptance tests prior to implementation doubles the
team&#039;s productivity. ”
ジェフ スクラムの共同開発者であるサザーランドは、ソフトウエアの⽣産性に関する指
標を持っている[Sutherland01]。彼は、品質保証の担当者をチームに加え、実装前に受
け⼊れテストを作成することで、チームの⽣産性が倍増することを実感しているそうで
す”
Lean Agile Acceptance Test-Driven-Development (2010)/ Ken Pugh


# Page. 35

![Page Image](https://bcdn.docswell.com/page/4EQX4L9R7P.jpg)

2. 解決策（案）は４つある
で、どうするのか


# Page. 36

![Page Image](https://bcdn.docswell.com/page/KJ46QDXQ71.jpg)

2. 解決策（案）は４つある
ATDDでないとき
• QAはすぐ設計に着⼿できず、リードタイムが発⽣
• 仕様決定段階でテスタブルかどうか確認できていない、テスト設計可能
なレベルまで仕様詳細が未定といった要因で⼿戻りが発⽣する
仕様決定
開発・テスト設計
開発可能
か検討
仕様詳細が
未確定
準備・テスト実施
リリース


# Page. 37

![Page Image](https://bcdn.docswell.com/page/LE1VPZNL7G.jpg)

2. 解決策（案）は４つある
ATDDであるとき
• 仕様ではなくテストを開発者、テスター、クライアント3⼈にて議論し
決める（兼任可）
• テストが通れば仕様通りの実装ができている
• 要件定義→テスト作成とはせず、テストが要件となる
テスト設計（＝仕様）
開発・テスト準備
開発可能
か検討
仕様詳細が
未確定
テスト実施
リリース


# Page. 38

![Page Image](https://bcdn.docswell.com/page/GEWL294Q72.jpg)

2. 解決策（案）は４つある
ATDDであるとき
• もちろん、いきなりテストをつくらない
• PJ⼤⽅針 → ストーリー → シナリオを決めてからテスト（＝仕様）決
定というように、納得感のある⼤きな⼿戻りを防ぐプロセスを踏む
Fig.
Projects Start with the Charter
Lean Agile Acceptance Test-Driven-Development (2010)/ Ken Pugh


# Page. 39

![Page Image](https://bcdn.docswell.com/page/47ZMD923E3.jpg)

2. 解決策（案）は４つある
みんなでテスト設計するなら
QAが注⼒する領域にのみ
QAの⼈数を割くことができるのでは？
（＝QAの⼈数は少なくできる）


# Page. 40

![Page Image](https://bcdn.docswell.com/page/YJ6N1KVZJV.jpg)

3. ということで


# Page. 41

![Page Image](https://bcdn.docswell.com/page/GJ554PD9J4.jpg)

3. どの解決策も「QAチーム」はいらない
爆速スピードのテスト
コミュニケーションとりやすい体制
詳細な仕様決定


# Page. 42

![Page Image](https://bcdn.docswell.com/page/9E2NV6857R.jpg)

3. どの解決策も「QAチーム」はいらない
アジャイル開発での
QAの独⽴チーム不要度を
★評価してみる


# Page. 43

![Page Image](https://bcdn.docswell.com/page/D7YP39667M.jpg)

3. どの解決策も「QAチーム」はいらない
1
QAを開発チームへ分散
もうチームない
コミュニケーション改善
★★★
仕様決定促進
事例）楽天, Base, ATLASSIANなど多数
3
探索的テストの活⽤
開発へのコーチング中
開発へのコーチング後
★☆☆
★★☆
スピードアップ
事例）現PJ, ATLASSIAN など
2
テスト⾃動化
コードテストの壁
★★☆
スピードアップ
事例）現PJ, メルペイ, ATLASSIANなど多数
4 受け⼊れテスト駆動開発
もうチームない
コミュニケーション改善
★★★
仕様決定促進
スピードアップ
事例）Base, SmartHR など


