$30 off During Our Annual Pro Sale. View Details »

Agile Testingのエッセンス #devsumi / Agile Testing Essence 20220218

nihonbuson
February 18, 2022

Agile Testingのエッセンス #devsumi / Agile Testing Essence 20220218

Developers Summit 2022で発表した資料です。

【参考文献のページに記載したURL】
◆P153(参考書籍)
Agile Testing Condensed(日本語版はこちら
The BDD Books - Discovery

◆P154(Agile Testing関連の参考文献)
Appendix A: What We´ve Learned Since Agile Testing
テストマニフェスト(日本語版はこちら
Continuous Testing in DevOps…(日本語版はこちら
実例マッピング(日本語版はこちら
Cucumber School - Give Me An Example
Cucumber School
ベリサーブが考えるテスト自動化プロジェクトのマネジメントとは
Explore It!
探索的テストはじめの一歩 #wacate

◆P155(品質管理関連の参考文献)
ソフトウェアの品質管理推進について(ENGINEERS 誌 1981年8月号)
ソフトウェアの検査の考え方(学会誌「情報処理」1972年5月号)
ソフトウェア製品生産管理:ソフトウェア工学における品質管理(QC)と品質保証(QA)
(学会誌「情報処理」1980年10月号)

日本的品質管理<増補版>
Quality Management Evolution from the Past to Present: Challenges for Tomorrow
品質保証の歴史学 at「リリカルの質問全部答えます」

【発表資料中のURL】
※複数ページで出てくる場合は、初出のページ数に掲載

◆P4
Agile Testing: A Practical Guide for Testers and Agile Teams
実践アジャイルテスト(Agile Testing: A Practical Guide for Testers and Agile Teamsの日本語翻訳版)
More Agile Testing
Agile Testing Condensed
Agile Testing Condensed Japanese Edition

◆P6
社内読書会報告
atama plus 株式会社様
メディアマックスジャパン株式会社様
株式会社エス・エム・エス様
ユニバ株式会社 Azukaritaiチーム様
感想ブログ
hgsgtk様
らーめん様
粕谷様

◆P11
ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版Version 2018.J03

◆P12
The Testing Manifesto
【翻訳記事】テストに対する考え方「Testing Manifesto」

◆P13
テストコードを書き始める前に考えるべきテストの話(2021年版)

◆P17
ソフトウェアテスト自動化の変遷。変わったことと変わらないこと。テスト自動化の導入パターン。

◆P19
ベリサーブが考えるテスト自動化プロジェクトのマネジメントとは

◆P21
Explore It!
探索的テストはじめの一歩 #wacate

◆P23
Continuous Testing in DevOps…

◆P34
Introducing Example Mapping
【翻訳記事】受け入れ基準の設定時などに役立つプラクティス「実例マッピング(Example Mapping)」

◆P95
The BDD Books - Discovery

◆P96
Keep your scenarios BRIEF
【翻訳記事】テスト自動化の対象となるテストシナリオの整理に役立つBRIEFの原則

◆P113
アジャイルサムライ
アジャイルテストの世界 - Agile Testing Condensed と実例マッピング

◆P114
@m_sekiさんのツイート

◆P132
ソフトウェアの品質管理推進について(ENGINEERS 誌 1981年8月号)

◆P134
ソフトウェアの検査の考え方(学会誌「情報処理」1972年5月号)

◆P136
ソフトウェア製品生産管理:ソフトウェア工学における品質管理(QC)と品質保証(QA)
(学会誌「情報処理」1980年10月号)

◆P142
日本的品質管理<増補版>

◆P170
品質保証の歴史学 at「リリカルの質問全部答えます」

◆P171
Quality Management Evolution from the Past to Present: Challenges for Tomorrow

nihonbuson

February 18, 2022
Tweet

More Decks by nihonbuson

Other Decks in Technology

Transcript

  1. 開発者・経営者へ
    特に伝えたい
    Agile Testingの
    エッセンス
    ブロッコリー
    (@nihonbuson)
    https://www.pexels.com/ja-jp/photo/6387848/

    View Slide

  2. 自己紹介
    ● 風間裕也(ブロッコリー)
    ● @nihonbuson
    ● 所属
    ○ 株式会社ビズリーチ
    ○ QAグループ
    ● 社外活動
    ○ JaSST Review実行委員長
    ○ WACATE実行委員
    ○ 書籍『Agile Testing Condensed』翻訳
    ○ 書籍『Testing in DevOps』翻訳

    View Slide

  3. Agile Testingの生い立ち

    View Slide

  4. JanetとLisaが執筆した3冊のAgile Testing
    Agile Testing
    (日本語版あり)
    More Agile Testing Agile Testing Condensed
    (日本語版あり)
    2008年刊行
    全576ページ
    2014年刊行
    全544ページ
    2019年刊行
    全113ページ

    View Slide

  5. なぜ最新作はページ数が少ない?
    ● 今までの本は分厚すぎて経営者が読まなかった
    ● 手軽に読んでもらいたくてこの量になった
    Condensed=濃縮された

    View Slide

  6. 『Agile Testing Condensed』読書会&感想
    ● 社内読書会報告
    ○ atama plus 株式会社様
    ○ メディアマックスジャパン株式会社様
    ○ 株式会社エス・エム・エス様
    ○ ユニバ株式会社 Azukaritaiチーム様
    ● 感想ブログ
    ○ hgsgtk様
    ○ らーめん様
    ○ 粕谷様

    View Slide

  7. 第一部
    Agileの中で行われる
    Testing活動
    第二部
    Agile Testingとは
    新しい概念なのか?

    View Slide

  8. 第一部
    Agileの中で行われる
    Testing活動

    View Slide

  9. 改めてテストを考える
    Designed by pch.vector / Freepik

    View Slide

  10. 質問
    ● なぜ皆さんはテストをしているのでしょうか?
    ● テストの目的はなんでしょうか?

    View Slide

  11. テストの目的とは何か?
    ● 要件、ユーザーストーリー、設計、および
    コードなどの作業成果物を評価する
    ことによって欠陥を防ぐ。
    ● 明確にしたすべての要件を満たしていることを検証する。
    ● テスト対象が完成したことを確認し、ユーザーやその他ステークホル
    ダーの期待通りの動作内容であることの妥当性確認をする。
    ● テスト対象の品質に対する信頼を積み重ねて、所定のレベルにあること
    を確証する。
    ● 欠陥や故障を発見し、ソフトウェアの品質が不適切になるリスクレベル
    を軽減する。
    ● ステークホルダーが意思決定できる、特にテスト対象の品質レベルにつ
    いての十分な情報を提供する。
    ● 契約上、法律上、または規制上の要件や標準を遵守する、そして/または
    テスト対象がそのような要件や標準に準拠していることを検証する。
    ISTQBテスト技術者資格制度
    Foundation Level シラバス
    日本語版Version 2018.J03より
    実装前に行うこともある

    View Slide

  12. テストマニフェスト
    http://www.growingagile.co.za/2015/04/the-testing-manifesto/
    日本語版: https://nihonbuson.hatenadiary.jp/entry/TestingManifesto
    『Agile Testing Condensed』
    第1章 P5より

    View Slide

  13. 欠陥を防ぐ活動はデブサミ2020で講演済
    テストコードを書き始める前から考えるべきテストの話

    View Slide

  14. 質問
    ● 皆さんは普段どんなテストをしてますか?
    ● 業務の中にある「◯◯テスト」
    を思い出してください
    Communication vector created by freepik - www.freepik.com

    View Slide

  15. こんな考えを持っていませんか?
    ● QAチームがテストしているよ
    ● TDD(テスト駆動開発)でテストしているよ
    ● 自動テストツールを使ってテストしているよ
    ● 自動テストでできるだけテストして、
    できない部分は探索的テストをしているよ
    ● 最新のツールを使ってテストしているよ
    だから大丈夫だよ!
    or
    十分考えているけど上手くいかない…

    View Slide

  16. こんな考えを持っていませんか?
    ● QAチームがテストしているよ
    ● TDD(テスト駆動開発)でテストしているよ
    ● 自動テストツールを使ってテストしているよ
    ● 自動テストでできるだけテストさせて、
    できない部分は探索的テストをしているよ
    ● 最新のツールを使ってテストしているよ
    だから大丈夫だよ!
    or
    十分考えているけど上手くいかない…
    TDDも
    自動テストも
    探索的テストも
    必要だけど、
    それだけじゃない!

    View Slide

  17. Test Automation Circles(※今日は話しません)
    参考:ソフトウェアテスト自動化の変遷。変わったことと変わらないこと。テスト自動化の導入パターン。

    View Slide

  18. Test Automation Circles(※今日は話しません)
    参考:ソフトウェアテスト自動化の変遷。変わったことと変わらないこと。テスト自動化の導入パターン。
    同心円の中心から
    順に考えるべき

    View Slide

  19. 自動テストプロセス例(※今日は話しません)
    参考:ベリサーブが考えるテスト自動化プロジェクトのマネジメントとは

    View Slide

  20. 自動テストプロセス例(※今日は話しません)
    参考:ベリサーブが考えるテスト自動化プロジェクトのマネジメントとは
    自動テストの話
    =自動テスト
    スクリプト実装の話
    に限定されがち

    View Slide

  21. 探索的テストとは(※今日は話しません)
    探索的テストとは
    「システムについて
    学ぶためのテスト設計
    と実行を同時に行い、
    最後の実験から得た
    洞察を次に伝える」
    探索的テストはじめの一歩 #wacateより
    Explore It!より

    View Slide

  22. 探索的テストとは(※今日は話しません)
    以下のテストは探索的テストではない
    ● 計画や文書なしで行うテスト
    (アドホックテスト)
    ● ランダムな入力やランダムなアクションを
    入力して確認するテスト(モンキーテスト)
    「ランダムにさまようこと」と
    「思慮深く探索すること」は違う
    『Agile Testing Condensed』
    第6章 P26より

    View Slide

  23. 継続的テストモデル
    https://danashby.co.uk/2016/10/19/continuous-testing-in-devops/
    『Agile Testing Condensed』
    第1章 P3より

    View Slide

  24. 継続的テストモデル
    https://danashby.co.uk/2016/10/19/continuous-testing-in-devops/
    『Agile Testing Condensed』
    第1章 P3より
    AgileTestingの範囲

    View Slide

  25. 継続的テストモデル
    https://danashby.co.uk/2016/10/19/continuous-testing-in-devops/
    テストの
    範囲に
    なりがち 『Agile Testing Condensed』
    第1章 P3より

    View Slide

  26. 継続的テストモデル
    https://danashby.co.uk/2016/10/19/continuous-testing-in-devops/
    TDD
    など
    『Agile Testing Condensed』
    第1章 P3より

    View Slide

  27. 継続的テストモデル
    https://danashby.co.uk/2016/10/19/continuous-testing-in-devops/
    今回の
    発表
    範囲
    『Agile Testing Condensed』
    第1章 P3より

    View Slide

  28. ストーリー完了までの流れ
    『Agile Testing Condensed』
    第4章 P17より
    Sprint
    開始前に
    実施する

    View Slide

  29. ストーリー完了までの流れ
    『Agile Testing Condensed』
    第4章 P17より
    Sprint
    開始前に
    実施する
    自動
    テスト
    探索的
    テスト

    View Slide

  30. ストーリー完了までの流れ
    『Agile Testing Condensed』
    第4章 P17より
    Sprint
    開始前に
    実施する
    今回の発表範囲

    View Slide

  31. Sprint開始前に
    行う活動
    テスト活動面に
    注目した
    Scrumでの例

    View Slide

  32. Sprint開始前に
    行う活動

    View Slide

  33. ストーリー完了までの流れ
    『Agile Testing Condensed』
    第4章 P17より
    Sprint
    開始前に
    実施する
    今回の発表範囲

    View Slide

  34. Sprint開始前の活動例…実例マッピング
    日本語版: https://nihonbuson.hatenadiary.jp/entry/ExampleMapping
    https://cucumber.io/blog/bdd/example-mapping-introduction/
    ● BDDの導入にあたり考えられたやり方
    ● 4色の付箋を用いる
    ○ 黄色の付箋
    ユーザーストーリー
    ○ 青色の付箋
    ルール
    ○ 緑色の付箋
    具体例
    ○ 赤色の付箋
    疑問点、仮定

    View Slide

  35. 事例を通じて伝えたいこと
    ● 実例マッピングという
    プラクティスを使うことが大切なのではない!
    ● ストーリーとルールと具体例と疑問点を
    分けて会話し、分かれた状態で記録する
    という思考が大切!
    ● 実例マッピングが作られていく過程となる
    会話も併せて紹介する

    View Slide

  36. Three Amigos
    3つの立場の人が集まり協調的に要件を確認する
    People vector created by stories - www.freepik.com
    QA(Tester) 開発者 PO

    View Slide

  37. 今回の題材・登場人物
    PO QA
    人数のグラフを
    良い感じに表示する
    開発者

    View Slide

  38. スケールのルール追加
    人数のグラフを
    良い感じに表示したい
    「良い感じ」が
    分からないので
    色々質問しますね
    縦軸の目盛りは最大値を
    基準に良い感じで
    スケールが変わる
    最大値を
    基準に
    スケール
    変更
    人数のグラフを
    良い感じに表示する

    View Slide

  39. 1000人の場合
    例えば1000人の場合は
    どうなります?
    人数のグラフを
    良い感じに表示する

    View Slide

  40. 1000人の場合
    目盛りが4本なので、
    目盛りは250, 500,
    750, 1000ですかね
    例えば1000人の場合は
    どうなります?
    人数のグラフを
    良い感じに表示する

    View Slide

  41. 具体例の追加
    例えば1000人の場合は
    どうなります?
    人数のグラフを
    良い感じに表示する
    最大値を
    基準に
    スケール
    変更 1000人

    View Slide

  42. 具体例の追加
    目盛りが4本なので、
    目盛りは250, 500,
    750, 1000ですかね
    例えば1000人の場合は
    どうなります?
    人数のグラフを
    良い感じに表示する
    最大値を
    基準に
    スケール
    変更 1000人
    250,500
    750,1000

    View Slide

  43. 目盛りのルールの追加
    目盛りが4本なので、
    目盛りは250, 500,
    750, 1000ですかね
    例えば1000人の場合は
    どうなります?
    人数のグラフを
    良い感じに表示する
    最大値を
    基準に
    スケール
    変更
    目盛りが
    4本出る
    1000人
    250,500
    750,1000

    View Slide

  44. 800人の場合
    じゃあ800人だったら?
    人数のグラフを
    良い感じに表示する

    View Slide

  45. 具体例の追加
    人数のグラフを
    良い感じに表示する
    目盛りが
    4本出る
    1000人
    250,500
    750,1000
    800人
    最大値を
    基準に
    スケール
    変更
    じゃあ800人だったら?

    View Slide

  46. 具体例の追加
    人数のグラフを
    良い感じに表示する
    目盛りが
    4本出る
    1000人
    250,500
    750,1000
    800人
    250,500
    750,1000
    最大値を
    基準に
    スケール
    変更
    じゃあ800人だったら?
    その場合も目盛りは
    1000人の場合と
    同じです

    View Slide

  47. 1500人の場合
    人数のグラフを
    良い感じに表示する
    じゃあ1500人でも
    同じ?

    View Slide

  48. 1500人の場合
    人数のグラフを
    良い感じに表示する
    じゃあ1500人でも
    同じ?
    その場合は
    400,800,1200,1600
    に調整されますね

    View Slide

  49. 1500人の場合
    人数のグラフを
    良い感じに表示する
    じゃあ1500人でも
    同じ?
    1500人
    最大値を
    基準に
    スケール
    変更
    目盛りが
    4本出る
    1000人
    250,500
    750,1000
    800人
    250,500
    750,1000

    View Slide

  50. 具体例の追加
    人数のグラフを
    良い感じに表示する
    その場合は
    400,800,1200,1600
    に調整されますね
    じゃあ1500人でも
    同じ?
    1500人
    400,800
    1200,1600
    最大値を
    基準に
    スケール
    変更
    目盛りが
    4本出る
    1000人
    250,500
    750,1000
    800人
    250,500
    750,1000

    View Slide

  51. 目盛りを超えないルールの追加
    人数のグラフを
    良い感じに表示する
    1500人の場合はなぜ
    変わるんですかね?
    1500人
    400,800
    1200,1600
    最大値を
    基準に
    スケール
    変更
    目盛りが
    4本出る
    1000人
    250,500
    750,1000
    800人
    250,500
    750,1000

    View Slide

  52. 目盛りを超えないルールの追加
    人数のグラフを
    良い感じに表示する
    上の目盛りが
    1000だと
    グラフが突き抜けて
    しまうので…
    1500人の場合はなぜ
    変わるんですかね?
    一番上の
    目盛りを
    超えない
    1500人
    400,800
    1200,1600
    最大値を
    基準に
    スケール
    変更
    目盛りが
    4本出る
    1000人
    250,500
    750,1000
    800人
    250,500
    750,1000

    View Slide

  53. 1050人の場合
    そしたら1050人は?
    1000人超えだけど…
    人数のグラフを
    良い感じに表示する

    View Slide

  54. 具体例の追加
    人数のグラフを
    良い感じに表示する
    1500人
    400,800
    1200,1600
    最大値を
    基準に
    スケール
    変更
    目盛りが
    4本出る
    1000人
    250,500
    750,1000
    800人
    250,500
    750,1000
    そしたら1050人は?
    1000人超えだけど…
    一番上の
    目盛りを
    超えない
    1050人

    View Slide

  55. 具体例の追加
    人数のグラフを
    良い感じに表示する
    その場合はグラフが
    外にはみ出ないので
    目盛りは1000のまま
    ですね。
    1500人
    400,800
    1200,1600
    最大値を
    基準に
    スケール
    変更
    目盛りが
    4本出る
    1000人
    250,500
    750,1000
    800人
    250,500
    750,1000
    そしたら1050人は?
    1000人超えだけど…
    1050人
    250,500
    750,1000
    一番上の
    目盛りを
    超えない

    View Slide

  56. ルールの変更
    人数のグラフを
    良い感じに表示する
    その場合はグラフが
    外にはみ出ないので
    目盛りは1000のまま
    ですね。
    一番上の
    目盛りを
    超えない
    1500人
    400,800
    1200,1600
    最大値を
    基準に
    スケール
    変更
    目盛りが
    4本出る
    1000人
    250,500
    750,1000
    800人
    250,500
    750,1000
    そしたら1050人は?
    1000人超えだけど…
    グラフがエリア外に
    出ないことが
    重要なんですね。
    1050人
    250,500
    750,1000

    View Slide

  57. ルールの変更
    人数のグラフを
    良い感じに表示する
    その場合はグラフが
    外にはみ出ないので
    目盛りは1000のまま
    ですね。
    データが
    エリア外
    に出ない
    1500人
    400,800
    1200,1600
    最大値を
    基準に
    スケール
    変更
    目盛りが
    4本出る
    1000人
    250,500
    750,1000
    800人
    250,500
    750,1000
    そしたら1050人は?
    1000人超えだけど…
    グラフがエリア外に
    出ないことが
    重要なんですね。
    1050人
    250,500
    750,1000

    View Slide

  58. 600人の場合
    今度は小さい値を
    考えてみます。
    600人はどうですか?
    人数のグラフを
    良い感じに表示する

    View Slide

  59. 具体例の追加
    人数のグラフを
    良い感じに表示する
    最大値を基準に
    スケール変更
    600人
    今度は小さい値を
    考えてみます。
    600人はどうですか?

    View Slide

  60. 具体例の追加
    人数のグラフを
    良い感じに表示する
    最大値を基準に
    スケール変更
    600人
    200,400
    600,800
    250,500,750,1000だと
    グラフが小さく表示さ
    れるので、200,400,
    600,800ですかね。
    今度は小さい値を
    考えてみます。
    600人はどうですか?

    View Slide

  61. 150人の場合
    人数のグラフを
    良い感じに表示する
    もっと小さい値
    で150人だったら?

    View Slide

  62. 具体例の追加
    人数のグラフを
    良い感じに表示する
    最大値を基準に
    スケール変更
    600人
    200,400
    600,800
    150人
    もっと小さい値
    で150人だったら?

    View Slide

  63. 具体例の追加
    人数のグラフを
    良い感じに表示する
    最大値を基準に
    スケール変更
    600人
    200,400
    600,800
    150人
    40,80
    120,160
    そしたら40,80,120,
    160ですかね。
    ちょうど良いのは。
    もっと小さい値
    で150人だったら?

    View Slide

  64. ルールの発見
    人数のグラフを
    良い感じに表示する
    あー、
    確かにそうですね
    なるほどー。
    ここまでの話から
    最大値は目盛りの
    上から2番目よりは
    大きいように調整
    するんですかね?

    View Slide

  65. ルールの発見
    人数のグラフを
    良い感じに表示する
    最大値を基準に
    スケール変更
    600人
    200,400
    600,800
    150人
    40,80
    120,160
    あー、
    確かにそうですね
    なるほどー。
    ここまでの話から
    最大値は目盛りの
    上から2番目よりは
    大きいように調整
    するんですかね?

    View Slide

  66. ルールの発見
    人数のグラフを
    良い感じに表示する
    最大値が目盛りの
    上から2番目よりは
    大きくなる
    600人
    200,400
    600,800
    150人
    40,80
    120,160
    あー、
    確かにそうですね
    なるほどー。
    ここまでの話から
    最大値は目盛りの
    上から2番目よりは
    大きいように調整
    するんですかね?

    View Slide

  67. 2人の場合
    人数のグラフを
    良い感じに表示する
    さらに小さい値を
    考えてみます。
    2人だと
    どうなります?

    View Slide

  68. 具体例の追加
    人数のグラフを
    良い感じに表示する
    最大値が目盛りの
    上から2番目よりは
    大きくなる
    600人
    200,400
    600,800
    150人
    40,80
    120,160
    2人
    さらに小さい値を
    考えてみます。
    2人だと
    どうなります?

    View Slide

  69. 具体例の追加
    人数のグラフを
    良い感じに表示する
    最大値が目盛りの
    上から2番目よりは
    大きくなる
    600人
    200,400
    600,800
    150人
    40,80
    120,160
    4分割で考えると0.5,
    1, 1.5, 2ですかね。
    2人
    0.5,1
    1.5,2
    さらに小さい値を
    考えてみます。
    2人だと
    どうなります?

    View Slide

  70. 疑問点の追加
    人数のグラフを
    良い感じに表示する
    最大値が目盛りの
    上から2番目よりは
    大きくなる
    600人
    200,400
    600,800
    150人
    40,80
    120,160
    あー、それは調整する
    必要があるかも。
    人数なのに
    小数点以下の
    目盛りがあるのは
    違和感がありますね
    2人
    0.5,1
    1.5,2

    View Slide

  71. 疑問点の追加
    人数のグラフを
    良い感じに表示する
    最大値が目盛りの
    上から2番目よりは
    大きくなる
    600人
    200,400
    600,800
    150人
    40,80
    120,160
    あー、それは調整する
    必要があるかも。
    人数なのに
    小数点以下の
    目盛りがあるのは
    違和感がありますね
    2人
    0.5,1
    1.5,2
    小数点の
    目盛りは
    表示される?

    View Slide

  72. 疑問点の追加
    人数のグラフを
    良い感じに表示する
    最大値が目盛りの
    上から2番目よりは
    大きくなる
    600人
    200,400
    600,800
    150人
    40,80
    120,160
    価値が無くなる訳では
    ないので、今回は一旦
    そのままにしましょう!
    目盛りの数を状況に
    よって変えるのは
    工数がかかるから
    今回はそのままに
    したい…
    2人
    0.5,1
    1.5,2
    小数点の
    目盛りは
    表示される?

    View Slide

  73. 疑問点の追加
    人数のグラフを
    良い感じに表示する
    最大値が目盛りの
    上から2番目よりは
    大きくなる
    600人
    200,400
    600,800
    150人
    40,80
    120,160
    価値が無くなる訳では
    ないので、今回は一旦
    そのままにしましょう!
    目盛りの数を状況に
    よって変えるのは
    工数がかかるから
    今回はそのままに
    したい…
    2人
    0.5,1
    1.5,2
    小数点の目盛り
    は表示される?
    →表示する

    View Slide

  74. 0人の場合
    人数のグラフを
    良い感じに表示する
    それは自分も
    どうするか明確に
    してないですね…
    あとは、0人だったら
    どうなります?
    目盛りがどのように
    調節されるのか
    分からない…

    View Slide

  75. 疑問点の追加
    人数のグラフを
    良い感じに表示する
    最大値が目盛りの
    上から2番目よりは
    大きくなる
    600人
    200,400
    600,800
    150人
    40,80
    120,160
    それは自分も
    どうするか明確に
    してないですね…
    あとは、0人だったら
    どうなります?
    目盛りがどのように
    調節されるのか
    分からない…
    2人
    0.5,1
    1.5,2
    小数点の目盛り
    は表示される?
    →表示する
    最大値が0人
    の時に目盛り
    はどうする?

    View Slide

  76. 今回の実例マッピングのまとめ
    人数のグラフを
    良い感じに表示する
    600人なら
    200,400
    600,800
    150人なら
    40,80
    120,160
    最大値が目盛りの
    上から2番目よりは
    大きくなるように調整
    2人なら
    0.5, 1
    1.5, 2
    小数点の目盛り
    は表示される?
    →表示する
    最大値が0人
    の時に目盛り
    はどうする?
    目盛りが
    4本出る
    1000人なら
    250,500
    750,1000
    800人なら
    250,500
    750,1000
    データが
    エリア外
    に出ない
    1500人なら
    400,800
    1200,1600
    1050人なら
    250,500
    750,1000

    View Slide

  77. 実例マッピングの
    成果物から分かること

    View Slide

  78. 今回の実例マッピングの成果物
    人数のグラフを
    良い感じに表示する
    600人なら
    200,400
    600,800
    150人なら
    40,80
    120,160
    最大値が目盛りの
    上から2番目よりは
    大きくなるように調整
    2人なら
    0.5, 1
    1.5, 2
    小数点の目盛り
    は表示される?
    →表示する
    最大値が0人
    の時に目盛り
    はどうする?
    目盛りが
    4本出る
    1000人なら
    250,500
    750,1000
    800人なら
    250,500
    750,1000
    データが
    エリア外
    に出ない
    1500人なら
    400,800
    1200,1600
    1050人なら
    250,500
    750,1000

    View Slide

  79. 実例マッピングの成果物から分かること
    人数のグラフを
    良い感じに表示する
    600人なら
    200,400
    600,800
    150人なら
    40,80
    120,160
    最大値が目盛りの
    上から2番目よりは
    大きくなるように調整
    2人なら
    0.5, 1
    1.5, 2
    小数点の目盛り
    は表示される?
    →表示する
    最大値が0人
    の時に目盛り
    はどうする?
    目盛りが
    4本出る
    1000人なら
    250,500
    750,1000
    800人なら
    250,500
    750,1000
    データが
    エリア外
    に出ない
    1500人なら
    400,800
    1200,1600
    1050人なら
    250,500
    750,1000
    ここがSpike Taskになる場合も…
    (調査・決定しない限り、
    開発に着手すべきでない)

    View Slide

  80. 実例マッピングの成果物から分かること
    人数のグラフを
    良い感じに表示する
    600人なら
    200,400
    600,800
    150人なら
    40,80
    120,160
    最大値が目盛りの
    上から2番目よりは
    大きくなるように調整
    2人なら
    0.5, 1
    1.5, 2
    小数点の目盛り
    は表示される?
    →表示する
    最大値が0人
    の時に目盛り
    はどうする?
    目盛りが
    4本出る
    1000人なら
    250,500
    750,1000
    800人なら
    250,500
    750,1000
    データが
    エリア外
    に出ない
    1500人なら
    400,800
    1200,1600
    1050人なら
    250,500
    750,1000
    受け入れ条件に使える
    (これらを実現したことを確認して
    案件を「完了」に変える)

    View Slide

  81. 実例マッピングの成果物から分かること
    人数のグラフを
    良い感じに表示する
    600人なら
    200,400
    600,800
    150人なら
    40,80
    120,160
    最大値が目盛りの
    上から2番目よりは
    大きくなるように調整
    2人なら
    0.5, 1
    1.5, 2
    小数点の目盛り
    は表示される?
    →表示する
    最大値が0人
    の時に目盛り
    はどうする?
    目盛りが
    4本出る
    1000人なら
    250,500
    750,1000
    800人なら
    250,500
    750,1000
    データが
    エリア外
    に出ない
    1500人なら
    400,800
    1200,1600
    1050人なら
    250,500
    750,1000
    テストケース例に使える
    ※これが全てではないので注意!

    View Slide

  82. 実例マッピングの成果物から見える状況
    具体例の付箋が少ない
    →議論が足りないかも
    or
    実装内容が自明かも

    View Slide

  83. 実例マッピングの成果物から見える状況
    1つのルールに対して
    具体例の付箋が多い
    →ルールが複雑なので、
    複数のシンプルなルールに
    分割した方が良いかも

    View Slide

  84. 実例マッピングの成果物から見える状況
    ルールの付箋が多い
    →ストーリーが複雑なので
    もっと小さいストーリーに
    分割した方が良いかも

    View Slide

  85. 実例マッピングの成果物から見える状況
    疑問点の付箋が多い
    →開発開始する準備
    ができていないかも

    View Slide

  86. 実例マッピングで
    必要なスキル
    Designed by Rawpixel.com / Freepik

    View Slide

  87. 今回の実例マッピングで必要なスキル
    ● 具体例で考えられる
    ○ 実際に起こりうる例で考えられる
    ● 抽象化と具体化の行き来ができる
    ○ 具体例からルールを導き出す時に必要
    ○ テストのスキルも必要
    ■ 同値分割法
    ■ ハイレベルテストケースと
    ローレベルテストケース

    View Slide

  88. 具体例で考えられる
    ● 具体例を用いることで…
    ○ 各ストーリーの共有理解を
    構築するのに役立つ
    ○ 矛盾点に気付きやすくなる
    ○ ストーリーの受け入れ拒否が減る
    ○ 本番デプロイまでの時間短縮が期待できる
    『Agile Testing Condensed』
    第4章 P16より

    View Slide

  89. Three Amigosの得意分野
    Three Amigosは得意分野となる注目点が異なる
    ● PO…今回のFeatureで実現したいことに注目
    ● 開発者…今回のFeatureはどのようにすれば
        実現できるかに注目
    ● QA…今回のFeatureが「完成した」と
      判断するためには
      何を確認すれば良いのかに注目
    ※あくまでも得意分野であり、
     責任分担している訳ではない

    View Slide

  90. 抽象化と具体化の行き来
    人数のグラフを
    良い感じに表示する

    View Slide

  91. 抽象化と具体化の行き来
    じゃあ1500人は
    どうなる?
    人数のグラフを
    良い感じに表示する
    1500人
    具体化

    View Slide

  92. 抽象化と具体化の行き来
    上の目盛りが1000だと
    グラフが突き抜ける
    ので、その場合は
    400,800,1200,1600に
    調整されますね
    じゃあ1500人は
    どうなる?
    人数のグラフを
    良い感じに表示する
    1500人
    400,800
    1200,1600

    View Slide

  93. 抽象化と具体化の行き来
    上の目盛りが1000だと
    グラフが突き抜ける
    ので、その場合は
    400,800,1200,1600に
    調整されますね
    じゃあ1500人は
    どうなる?
    人数のグラフを
    良い感じに表示する
    一番上の
    目盛りを
    超えない
    1500人
    400,800
    1200,1600
    抽象化

    View Slide

  94. 実例マッピングから
    自動化へ…

    View Slide

  95. BDDにおける自動化への流れ
    参考:『The BDD Books - Discovery』第1章より

    View Slide

  96. BDDにおける自動化への流れ
    参考:『The BDD Books - Discovery』第1章より
    例)実例
      マッピング
    例)自動テスト
      コード作成
    例)BRIEFによる
      シナリオ整理
    参考:【翻訳記事】テスト自動化の対象となる
       テストシナリオの整理に役立つBRIEFの原則

    View Slide

  97. 自動化ツールを最初に考えない
    ● 実例マッピングのような発見のプラクティス
    を単独で実施するだけで、
    ソフトウェア開発活動を大幅に改善できる
    ● BDDツールを利用したり、Given/When/Thenを
    使用してテストを自動化しても、
    開発アプローチは少しもBDDにはなりません
    ● チームをまたいだ協調作業が
    得意になるまでは、
    自動化ツールに焦点を合わせない方が良い
    参考:『The BDD Books - Discovery』

    View Slide

  98. 自動化ツールを最初に考えない
    ● 実例マッピングのような発見のプラクティス
    を単独で実施するだけで、
    ソフトウェア開発活動を大幅に改善できる
    ● BDDツールを利用したり、Given/When/Thenを
    使用してテストを自動化しても、
    開発アプローチは少しもBDDにはなりません
    ● チームをまたいだ協調作業が
    得意になるまでは、
    自動化ツールに焦点を合わせない方が良い
    参考:『The BDD Books - Discovery』
    この書籍の著者は、BDDツール
    「SpecFlow(Cucumber for .NET)」の作者

    View Slide

  99. 実例マッピングの
    まとめ

    View Slide

  100. 実例マッピングのまとめ
    ● ストーリーに対し、ルール・具体例・疑問点を
    区別して表現することができる
    ● 具体例で考え、
    抽象化と具体化の行き来をする思考が大切
    ● 開発者・PO・QAが協力し、
    開発の実装前からテストを考え、
    チームが目指す製品について認識をしよう
    ● 実例マッピングなどの発見のプラクティスは
    自動テストを行う前に考えるのが大切
    ○ 実例マッピングを必ず使う必要はない

    View Slide

  101. テスト活動面に
    注目した
    Scrumでの例

    View Slide

  102. テストの考えを日々のサイクルに取り込む
    Scrumのどのタイミングで、
    テストの考え方を
    活用すれば良いのか紹介する

    View Slide

  103. 今回説明するScrum中の出来事
    プロダクト
    バックログ
    リファイン
    メント
    スプリント
    プランニング
    デイリー
    スクラム
    スプリント
    レビュー
    レトロ
    スペクティブ
    開発

    View Slide

  104. 注意事項
    ● 今回はScrumイベント自体の説明はしません
    ● Scrumの出来事の中で行う、テスト活動面や
    QAエンジニアの活動に注目した説明をします

    View Slide

  105. プロダクトバックログリファインメント
    ● 毎日30分だけ行う
    ● 作成したユーザーストーリーから
    1つをピックアップして話し合う
    ● POや開発に疑問点を聞きまくる
    ● 受け入れ基準(対象PBIをクローズする条件)
    についてPOと認識合わせをする
    ● 開発する時のテスト観点の元ネタを作る
    ● 成果物の例
    ○ 実例マッピング
    ○ テスト観点図

    View Slide

  106. スプリントプランニング
    1. 各PBIのざっくりとした相対見積もりを行う
    ○ テストがどのくらい大変になるか考える
    ○ テストの工数も踏まえた見積もりにする
    ■ 例.全画面に影響ある共通部分の修正1行
    2. 見積もり結果とPBI達成時のインパクトから
    開発の優先順位を決める
    3. テスト観点を出す
    4. 各PBIに対してのタスクを洗い出す
    ○ 最初にテストのタスクを考える

    View Slide

  107. 開発
    ● 開発者
    ○ 最初にテストケース作成を行う
    ○ その後、各PBIの実装・テスト実施をする
    ● QAエンジニア(テスター)
    ○ 開発者作成のテストケースをレビューする
    ○ 各PBIのテスト実施をする
    ■ スクリプトテスト
    ■ 探索的テスト
    ○ 仕様変更によるリグレッションテスト用の
    E2E自動テストへの影響確認をする

    View Slide

  108. レトロスペクティブ
    ● 今回のスプリントのふりかえりを行う
    ○ 次回以降のスプリントでもっと仕事を
    やりやすくするには?を考える
    ● QAエンジニアだからとかは関係なく、
    とりあえず意見は出す
    ○ 「やる/やらない」を判断するのはチーム

    View Slide

  109. 第一部まとめ

    View Slide

  110. 第一部のまとめ
    ● Agileの中で行う活動として
    実例マッピングを紹介した
    ● Scrumの中でどのようにテスト活動を
    考えれば良いか紹介した

    View Slide

  111. 第二部
    Agile Testingとは
    新しい概念なのか?

    View Slide

  112. Agile Testingとは
    特別な存在なのか?
    Abstract photo created by jcomp - www.freepik.com

    View Slide

  113. 書籍『Agile Testing』執筆のきっかけ
    JonathanとJanetが同じプロジェクトで関わる
    ● Jonathan…XP/TDDのコーチ
    ● Janet…QA出身のPO
    Jonathan「XPなのでQAいらない」
    Janet「そんなことはないはず」
    ● Janetは書籍『Agile Testing』を執筆
    ● Jonathanは書籍『アジャイルサムライ』を執筆
    ○ アジャイルテスターが書籍内に登場
    参考:https://kawaguti.hateblo.jp/entry/2020/05/08/172925

    View Slide

  114. Agile without testing
    https://twitter.com/m_seki/status/1424503907435225091

    View Slide

  115. Agile Testingは特別なことをしていない
    ● 『Agile Testing Condensed』は
    AgileにおけるTestingについて述べた書籍
    ○ Agileの中でTestingだけ
    別途のフェーズが存在している訳ではない
    ○ Agileでテストエンジニア(Tester)が
    どうすべきかのみ述べた書籍ではない
    ● "Agile Testingは特定の人が行う訳ではない"
    と主張して書籍が書かれているのに、
    逆にこの書籍の存在が、Agile Testingという
    特別な存在のように見える皮肉

    View Slide

  116. Agile以前に
    Agile Testingのような
    考え方はなかったのか?
    Designed by Freepik - jp.freepik.com

    View Slide

  117. デブサミのテーマは Hello, New Decade!

    View Slide

  118. デブサミのテーマは Hello, New Decade!
    次の10年を考える前に
    今までの歴史を振り返る

    View Slide

  119. https://nureyon.com/seven_segment_indicator-4?pattern=5

    View Slide

  120. View Slide

  121. View Slide

  122. テストマニフェスト考案(2015)
    http://www.growingagile.co.za/2015/04/the-testing-manifesto/
    日本語版: https://nihonbuson.hatenadiary.jp/entry/TestingManifesto
    『Agile Testing Condensed』
    第1章 P5より

    View Slide

  123. View Slide

  124. View Slide

  125. View Slide

  126. テストの目的を定義したISTQBの前身が発足(1998)
    ● 要件、ユーザーストーリー、設計、および
    コードなどの作業成果物を評価する
    ことによって欠陥を防ぐ。
    ● 明確にしたすべての要件を満たしていることを検証する。
    ● テスト対象が完成したことを確認し、ユーザーやその他ステークホルダーの期待
    通りの動作内容であることの妥当性確認をする。
    ● テスト対象の品質に対する信頼を積み重ねて、所定のレベルにあることを確証す
    る。
    ● 欠陥や故障を発見し、ソフトウェアの品質が不適切になるリスクレベルを軽減す
    る。
    ● ステークホルダーが意思決定できる、特にテスト対象の品質レベルについての十
    分な情報を提供する。
    ● 契約上、法律上、または規制上の要件や標準を遵守する、
    そして/またはテスト対象がそのような要件や標準に
    準拠していることを検証する。
    ISTQBテスト技術者資格制度
    Foundation Level シラバス
    日本語版Version 2018.J03より

    View Slide

  127. ISTQBの
    前身が
    発足
    アジャイル
    ソフトウェア
    開発宣言
    実践
    アジャイル
    テスト刊行
    1998
    2001
    2008
    2015
    2016
    2019
    Agile Testing
    年表
    継続的
    テスト
    モデル
    実例
    マッピング
    テスト
    マニフェスト
    Agile
    Testing
    Condensed
    刊行

    View Slide

  128. ISTQBの
    前身が
    発足
    アジャイル
    ソフトウェア
    開発宣言
    実践
    アジャイル
    テスト刊行
    1998
    2001
    2008
    2015
    2016
    2019
    Agile Testing
    年表
    継続的
    テスト
    モデル
    実例
    マッピング
    テスト
    マニフェスト
    Agile
    Testing
    Condensed
    刊行
    1998年以前に、
    欠陥を防ぐ
    品質はチーム全体での責任
    という考え方は無かったのか?

    View Slide

  129. View Slide

  130. View Slide

  131. View Slide

  132. 1950年代に品質を作り込むことをやっていた
    1950年代後半から,新製品開発の品質管理
    ということが盛んにいわれるようになります.
    つまり,
    設計や開発段階からしっかりチェック,
    管理を行い,いいものを作っていこう
    という考え方です.
    ソフトウェアの品質管理推進について(ENGINEERS 誌 1981年8月号)

    View Slide

  133. テストマニフェスト(再掲)
    http://www.growingagile.co.za/2015/04/the-testing-manifesto/
    日本語版: https://nihonbuson.hatenadiary.jp/entry/TestingManifesto
    『Agile Testing Condensed』
    第1章 P5より

    View Slide

  134. バグの発見よりもバグの防止
    検査の業務は単なる評価ではなく,
    予防に主眼を置いた広汎な活動領域である.
    ソフトウェアの検査の考え方(学会誌「情報処理」1972年5月号)

    View Slide

  135. 機能性をチェックするよりも
    チームが理解している価値をテストする
    ソフトウェアは
    「原理的に動く」だけのものであってはならず,
    「製品として価値がある」ものでなければ,
    システムにおける機能を全うし得ない.
    ソフトウェアの検査の考え方(学会誌「情報処理」1972年5月号)

    View Slide

  136. 直接部門と間接部門のいかんを問わず,(中略)
    いろいろな角度から
    全社的品質管理(Total Quality Control:TQC)を
    推し進めてゆかねばならない.
    ソフトウェア製品生産管理:ソフトウェア工学における品質管理(QC)と品質保証(QA)
    (学会誌「情報処理」1980年10月号)
    テスターの責任よりも
    品質に対するチームの責任

    View Slide

  137. ISTQBの
    前身が
    発足
    QCリサーチ
    グループ
    結成
    ソフトウェアの
    検査の考え方
    発表
    ソフトウェア製品生産管理:
    ソフトウェア工学における
    品質管理(QC)と品質保証(QA)
    発表
    日本的品質管理刊行
    ソフトウェアの
    品質管理推進
    について 発表
    1949 1972
    1980
    1981
    1998
    新製品開発
    の品質管理
    を始める
    1950年代
    後半

    View Slide

  138. ISTQBの
    前身が
    発足
    QCリサーチ
    グループ
    結成
    ソフトウェアの
    検査の考え方
    発表
    ソフトウェア製品生産管理:
    ソフトウェア工学における
    品質管理(QC)と品質保証(QA)
    発表
    日本的品質管理刊行
    ソフトウェアの
    品質管理推進
    について 発表
    1949 1972
    1980
    1981
    1998
    新製品開発
    の品質管理
    を始める
    1950年代
    後半
    日本では半世紀以上前から
    欠陥を防ぐ
    品質はチーム全体での責任
    という考え方を持っていた

    View Slide

  139. QA活動とは何か?
    品質保証(Quality Assurance)とは
    ● マニュアル通り作っているかチェックする活動
    ● チェックリストの内容を確認する活動

    View Slide

  140. QA活動とは何か?
    品質保証(Quality Assurance)とは
    ● マニュアル通り作っているかチェックする活動
    ● チェックリストの内容を確認する活動
    ● ソフトウェアエンジニアリングを用いた活動
    ○ 要求が漏れにくいような要件定義を考える
    ○ 適切なアーキテクチャの良し悪しを考える
    ○ 欠陥が発生しにくい設計を考える
    ○ テスト自動化を検討する
    ○ 稼働実績の把握とフィードバックを考える

    View Slide

  141. QA・QCではエンジニアリングを活用する
    大事なことは,計画段階から設計,製造,検査,
    運用,保全を経て廃棄に至るまでのそれぞれの
    過程に焦点を合わせた方法論の定式化である.
    稼働実績の把握に際しては,
    信頼性工学の場で広く適用されている解析技法
    (中略)を大いに活用し,データに語らしめ,
    データに学ぶことが大切である.
    ソフトウェア製品生産管理:ソフトウェア工学における品質管理(QC)と品質保証(QA)
    (学会誌「情報処理」1980年10月号)

    View Slide

  142. QA・QCではエンジニアリングを活用する
    全社的品質管理という名前に引っ張られて、
    統計的方法の活用が不十分な企業を見受けるが、
    統計的方法はQCの基礎である。
    石川馨著『日本的品質管理<増補版>』p136

    View Slide

  143. QA活動とは何か?
    品質保証(Quality Assurance)とは
    ● マニュアル通り作っているかチェックする活動
    ● チェックリストの内容を確認する活動
    ● ソフトウェアエンジニアリングを用いた活動
    ○ 要求が漏れにくいような要件定義を考える
    ○ 適切なアーキテクチャの良し悪しを考える
    ○ 欠陥が発生しにくい設計を考える
    ○ テスト自動化を検討する
    ○ 稼働実績の把握とフィードバックを考える
    日本では昔から
    存在する考え方

    View Slide

  144. View Slide

  145. View Slide

  146. View Slide

  147. 未来はどうなるのか?
    ● 手法は新たに発明されるかもしれないが
    根本的な考え方は昔から変わらないかも
    ● 新たな技術に飛びつくのも大事だが、
    根本的な考え方を見失わないようにしよう!
    ○ 「新しい手法だから」
    「新しい単語だから」は危険な兆候
    ○ 本日紹介した実例マッピングを導入する
    際も、根本となる考えを思い出して!
    ● New Decadeに思いを馳せる前に、
    温故知新の考えを持つと良い

    View Slide

  148. 未来はどうなるのか?
    ● 手法は新たに発明されるかもしれないが
    根本的な考え方は昔から変わらないかも
    ● 新たな技術に飛びつくのも大事だが、
    根本的な考え方を見失わないようにしよう!
    ○ 「新しい手法だから」
    「新しい単語だから」は危険な兆候
    ○ 本日紹介した実例マッピングを導入する
    際も、根本となる考えを思い出して!
    ● New Decadeに思いを馳せる前に、
    温故知新の考えを持つと良い
    今までのQAのやり方はダメだ!
    ではなく、
    本来行っていたQAを知らなかった!
    だけかもしれない…。
    (私自身、反省…)

    View Slide

  149. 第二部まとめ

    View Slide

  150. 第二部のまとめ
    ● Agile Testingでは特別なことをしていない
    ○ 特別なフェーズが存在しているのではない
    ○ Agile Testerのみの話ではない
    ● Agile Testingで述べられていることが
    実は昔から日本でやられている

    View Slide

  151. おわりに

    View Slide

  152. まとめ
    ● Agile Testingのことを開発者や経営者にも
    気軽に知ってもらうために
    『Agile Testing Condensed』は刊行された
    ● チーム全体でプロダクトの品質に責任を持とう
    ● 具体例を用いることで、
    より協力して開発を進めることができる
    ● Agile Testingで述べられていることは、
    実は昔から日本でやられている(組織もある)
    ○ Agileかそうではないか、
    テスターか開発者かは関係ない

    View Slide

  153. 参考書籍
    https://leanpub.com/
    agiletesting-condensed-japanese-edition
    http://www.bddbooks.com/

    View Slide

  154. その他、参考文献(Agile Testing関連)
    ● Appendix A: What We've Learned Since Agile
    Testing【動画】
    ● テストマニフェスト
    ● Continuous Testing in DevOps…
    ● 実例マッピング
    ● Cucumber School - Give Me An Example【動画】
    ● Cucumber School
    ● ベリサーブが考えるテスト自動化プロジェクトの
    マネジメントとは
    ● Explore It!【書籍】
    ● 探索的テストはじめの一歩 #wacate

    View Slide

  155. その他、参考文献(品質管理関連)
    ● ソフトウェアの品質管理推進について
    ● ソフトウェアの検査の考え方
    ● ソフトウェア製品生産管理:ソフトウェア工学
    における品質管理(QC)と品質保証(QA)
    ● 日本的品質管理―TQCとは何か【書籍】
    ● Quality Management Evolution from the Past
    to Present: Challenges for Tomorrow
    ● 品質保証の歴史学 at
    「リリカルの質問全部答えます」

    View Slide

  156. おしまい

    View Slide

  157. 補足
    (時間が余れば話します)

    View Slide

  158. これってテストの話ではないのでは?
    Q. テストの話ではなく、仕様の話では?
    Q. これってレビューの話では?
    A. レビューもテスト活動の一部として
     考えています。
    “テスト対象のコンポーネントやシステムを実行
    しない場合は、静的テストと呼ぶ。このため、テスト
    は要件、ユーザーストーリー、ソースコードなどの
    作業成果物をレビューする活動も含む。”
    ISTQBテスト技術者資格制度 Foundation Level シラバス日本語版Version 2018.J03 より

    View Slide

  159. 参考:BDDアプローチを含めたプロセス例
    『The BDD Books - Discovery』第4章を元に要素を追加し作成

    View Slide

  160. どうしてQA=チェックという認識になったの?
    Q.半世紀以上前から、Agile Testingで
     言われている活動を日本で行っていたのに、
     なんで、その活動が最近まで無かった
     (QA=チェックという認識になった)の?
    A.まずは品質管理の歴史について
     おさらいしましょう

    View Slide

  161. 品質管理の進歩
    ● 検査重点主義の品質管理
    ● 工程管理重点主義の品質管理
    ● 新製品開発主義の品質管理
    石川馨著『日本的品質管理<増補版>』p106

    View Slide

  162. 検査重点主義の品質管理
    ● 性悪説的な考え方
    ○ 生産部門は悪いことをするもしれない
    ■ 厳しく管理しよう
    ■ 検査部門を独立させ、権限を強くしよう
    ● 検査を強化することが品質保証につながる
    ● 日本ではQCを初めてすぐ、この考え方を捨てた
    ● 工場従業員に対する検査員の比率(1981年当時)
    ○ 日本…1〜5%(検査重点主義ではない)
    ○ 欧米…15%の場合も(検査重点主義)

    View Slide

  163. 工程管理重点主義の品質管理
    ● 生産工程をよく管理して
    全製品を良品にしてしまおうという考え方
    ● QCの格言「品質は工程でつくり込め」
    ● 検査部門だけでは目的を達成できない
    ○ トップから作業員までQCを実施する
    ● 開発・設計段階に起因する問題は
    製造部門や検査部門でカバーできない

    View Slide

  164. 新製品開発重点主義の品質管理
    ● 新製品企画からアフターサービスまでの
    各ステップごとにしっかりした評価を行う
    ○ 本生産に入る前に十分な品質解析を行う
    ● 格言「品質は設計と工程でつくり込め」
    ● 新製品開発のQAを重要視している理由
    ○ 新製品開発中に品質管理していなければ、
    十分な品質保証ができない
    ○ 新製品開発に失敗すると、その企業は
    倒産の瀬戸際に立たされることになる
    ○ 全部門が、品質管理、品質保証を実際に体験できる

    View Slide

  165. 欧米式TQC(Total Quality Control)
    ● ファイゲンバウム博士の考え方
    ● 本来のTQCの考え
    ● 全部門がQCを実施する必要がある
    ● QC技術者が中心になって活躍する必要がある

    View Slide

  166. 日本式TQC(Total Quality Control)
    ● 1949年から行っているQC活動で生まれた考え方
    ● QC技術者が行うQCということではない
    ● 各階層、各部門がQCを勉強し、実施する
    ● トップやスタッフも含めた全員でQCを実施する
    ● 品質の管理と同時に
    原価管理、量管理、納期管理を推進していく
    ● 海外にはCWQC(Company-Wide Quality Control)
    として紹介していた
    ● 後にTQM(Total Quality Management)に発展し
    欧米に受け入れられる

    View Slide

  167. 品質管理の時代変化
    検査
    重点
    主義
    工程
    管理
    重点
    主義
    新製品
    開発
    重点
    主義
    ISO
    9001
    信仰
    ??
    ??
    検査
    重点
    主義
    ??
    ??
    1950 1990 2010




    認証主義
    →ISO9000へ発展
    日本的TQCの導入
    →TQMへの発展

    View Slide

  168. 品質管理の時代変化
    検査
    重点
    主義
    工程
    管理
    重点
    主義
    新製品
    開発
    重点
    主義
    ISO
    9001
    信仰
    ??
    ??
    検査
    重点
    主義
    ??
    ??
    1950 1990 2010




    認証主義
    →ISO9000へ発展
    日本的TQCの導入
    →TQMへの発展
    NBCが
    「If Japan Can…
    Why Can't We?」
    を放映

    View Slide

  169. 品質管理の時代変化
    検査
    重点
    主義
    工程
    管理
    重点
    主義
    新製品
    開発
    重点
    主義
    ISO
    9001
    信仰
    ??
    ??
    検査
    重点
    主義
    ??
    ??
    1950 1990 2010




    認証主義
    →ISO9000へ発展
    日本的TQCの導入
    →TQMへの発展
    ・プロジェクト
     マネジメントブーム
    ・プロセスを守ればOK
    ・国際規格を守ればOK

    View Slide

  170. プロセスを決めれば品質保証できるという幻想
    品質保証の歴史学 at「リリカルの質問全部答えます」

    View Slide

  171. 参考:米国専門家が捉えた品質管理の時代変化
    Quality Management Evolution from the Past to Present: Challenges for Tomorrow のTable2を翻訳

    View Slide

  172. 参考:米国専門家が捉えた品質管理の時代変化
    Quality Management Evolution from the Past to Present: Challenges for Tomorrow のTable2を翻訳

    View Slide