Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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. 自己紹介 • 風間裕也(ブロッコリー) • @nihonbuson • 所属 ◦ 株式会社ビズリーチ ◦

    QAグループ • 社外活動 ◦ JaSST Review実行委員長 ◦ WACATE実行委員 ◦ 書籍『Agile Testing Condensed』翻訳 ◦ 書籍『Testing in DevOps』翻訳
  2. JanetとLisaが執筆した3冊のAgile Testing Agile Testing (日本語版あり) More Agile Testing Agile Testing

    Condensed (日本語版あり) 2008年刊行 全576ページ 2014年刊行 全544ページ 2019年刊行 全113ページ
  3. 『Agile Testing Condensed』読書会&感想 • 社内読書会報告 ◦ atama plus 株式会社様 ◦

    メディアマックスジャパン株式会社様 ◦ 株式会社エス・エム・エス様 ◦ ユニバ株式会社 Azukaritaiチーム様 • 感想ブログ ◦ hgsgtk様 ◦ らーめん様 ◦ 粕谷様
  4. テストの目的とは何か? • 要件、ユーザーストーリー、設計、および コードなどの作業成果物を評価する ことによって欠陥を防ぐ。 • 明確にしたすべての要件を満たしていることを検証する。 • テスト対象が完成したことを確認し、ユーザーやその他ステークホル ダーの期待通りの動作内容であることの妥当性確認をする。

    • テスト対象の品質に対する信頼を積み重ねて、所定のレベルにあること を確証する。 • 欠陥や故障を発見し、ソフトウェアの品質が不適切になるリスクレベル を軽減する。 • ステークホルダーが意思決定できる、特にテスト対象の品質レベルにつ いての十分な情報を提供する。 • 契約上、法律上、または規制上の要件や標準を遵守する、そして/または テスト対象がそのような要件や標準に準拠していることを検証する。 ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版Version 2018.J03より 実装前に行うこともある
  5. こんな考えを持っていませんか? • QAチームがテストしているよ • TDD(テスト駆動開発)でテストしているよ • 自動テストツールを使ってテストしているよ • 自動テストでできるだけテストさせて、 できない部分は探索的テストをしているよ

    • 最新のツールを使ってテストしているよ だから大丈夫だよ! or 十分考えているけど上手くいかない… TDDも 自動テストも 探索的テストも 必要だけど、 それだけじゃない!
  6. 具体例の追加 人数のグラフを 良い感じに表示する 目盛りが 4本出る 1000人 250,500 750,1000 800人 250,500

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

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

    目盛りを 超えない 1500人 400,800 1200,1600 最大値を 基準に スケール 変更 目盛りが 4本出る 1000人 250,500 750,1000 800人 250,500 750,1000
  9. 具体例の追加 人数のグラフを 良い感じに表示する 1500人 400,800 1200,1600 最大値を 基準に スケール 変更

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

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

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

    1500人 400,800 1200,1600 最大値を 基準に スケール 変更 目盛りが 4本出る 1000人 250,500 750,1000 800人 250,500 750,1000 そしたら1050人は? 1000人超えだけど… グラフがエリア外に 出ないことが 重要なんですね。 1050人 250,500 750,1000
  13. 具体例の追加 人数のグラフを 良い感じに表示する 最大値を基準に スケール変更 600人 200,400 600,800 250,500,750,1000だと グラフが小さく表示さ

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

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

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

    40,80 120,160 あー、 確かにそうですね なるほどー。 ここまでの話から 最大値は目盛りの 上から2番目よりは 大きいように調整 するんですかね?
  17. 具体例の追加 人数のグラフを 良い感じに表示する 最大値が目盛りの 上から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人だと どうなります?
  18. 疑問点の追加 人数のグラフを 良い感じに表示する 最大値が目盛りの 上から2番目よりは 大きくなる 600人 200,400 600,800 150人

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

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

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

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

    40,80 120,160 それは自分も どうするか明確に してないですね… あとは、0人だったら どうなります? 目盛りがどのように 調節されるのか 分からない… 2人 0.5,1 1.5,2 小数点の目盛り は表示される? →表示する 最大値が0人 の時に目盛り はどうする?
  23. 今回の実例マッピングのまとめ 人数のグラフを 良い感じに表示する 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
  24. 今回の実例マッピングの成果物 人数のグラフを 良い感じに表示する 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
  25. 実例マッピングの成果物から分かること 人数のグラフを 良い感じに表示する 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になる場合も… (調査・決定しない限り、 開発に着手すべきでない)
  26. 実例マッピングの成果物から分かること 人数のグラフを 良い感じに表示する 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 受け入れ条件に使える (これらを実現したことを確認して 案件を「完了」に変える)
  27. 実例マッピングの成果物から分かること 人数のグラフを 良い感じに表示する 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 テストケース例に使える ※これが全てではないので注意!
  28. Three Amigosの得意分野 Three Amigosは得意分野となる注目点が異なる • PO…今回のFeatureで実現したいことに注目 • 開発者…今回のFeatureはどのようにすれば     実現できるかに注目 •

    QA…今回のFeatureが「完成した」と   判断するためには   何を確認すれば良いのかに注目 ※あくまでも得意分野であり、  責任分担している訳ではない
  29. BDDにおける自動化への流れ 参考:『The BDD Books - Discovery』第1章より 例)実例   マッピング 例)自動テスト   コード作成

    例)BRIEFによる   シナリオ整理 参考:【翻訳記事】テスト自動化の対象となる    テストシナリオの整理に役立つBRIEFの原則
  30. 自動化ツールを最初に考えない • 実例マッピングのような発見のプラクティス を単独で実施するだけで、 ソフトウェア開発活動を大幅に改善できる • BDDツールを利用したり、Given/When/Thenを 使用してテストを自動化しても、 開発アプローチは少しもBDDにはなりません •

    チームをまたいだ協調作業が 得意になるまでは、 自動化ツールに焦点を合わせない方が良い 参考:『The BDD Books - Discovery』 この書籍の著者は、BDDツール 「SpecFlow(Cucumber for .NET)」の作者
  31. 実例マッピングのまとめ • ストーリーに対し、ルール・具体例・疑問点を 区別して表現することができる • 具体例で考え、 抽象化と具体化の行き来をする思考が大切 • 開発者・PO・QAが協力し、 開発の実装前からテストを考え、

    チームが目指す製品について認識をしよう • 実例マッピングなどの発見のプラクティスは 自動テストを行う前に考えるのが大切 ◦ 実例マッピングを必ず使う必要はない
  32. スプリントプランニング 1. 各PBIのざっくりとした相対見積もりを行う ◦ テストがどのくらい大変になるか考える ◦ テストの工数も踏まえた見積もりにする ▪ 例.全画面に影響ある共通部分の修正1行 2.

    見積もり結果とPBI達成時のインパクトから 開発の優先順位を決める 3. テスト観点を出す 4. 各PBIに対してのタスクを洗い出す ◦ 最初にテストのタスクを考える
  33. 開発 • 開発者 ◦ 最初にテストケース作成を行う ◦ その後、各PBIの実装・テスト実施をする • QAエンジニア(テスター) ◦

    開発者作成のテストケースをレビューする ◦ 各PBIのテスト実施をする ▪ スクリプトテスト ▪ 探索的テスト ◦ 仕様変更によるリグレッションテスト用の E2E自動テストへの影響確認をする
  34. 書籍『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
  35. Agile Testingは特別なことをしていない • 『Agile Testing Condensed』は AgileにおけるTestingについて述べた書籍 ◦ Agileの中でTestingだけ 別途のフェーズが存在している訳ではない

    ◦ Agileでテストエンジニア(Tester)が どうすべきかのみ述べた書籍ではない • "Agile Testingは特定の人が行う訳ではない" と主張して書籍が書かれているのに、 逆にこの書籍の存在が、Agile Testingという 特別な存在のように見える皮肉
  36. テストの目的を定義したISTQBの前身が発足(1998) • 要件、ユーザーストーリー、設計、および コードなどの作業成果物を評価する ことによって欠陥を防ぐ。 • 明確にしたすべての要件を満たしていることを検証する。 • テスト対象が完成したことを確認し、ユーザーやその他ステークホルダーの期待 通りの動作内容であることの妥当性確認をする。

    • テスト対象の品質に対する信頼を積み重ねて、所定のレベルにあることを確証す る。 • 欠陥や故障を発見し、ソフトウェアの品質が不適切になるリスクレベルを軽減す る。 • ステークホルダーが意思決定できる、特にテスト対象の品質レベルについての十 分な情報を提供する。 • 契約上、法律上、または規制上の要件や標準を遵守する、 そして/またはテスト対象がそのような要件や標準に 準拠していることを検証する。 ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版Version 2018.J03より
  37. ISTQBの 前身が 発足 アジャイル ソフトウェア 開発宣言 実践 アジャイル テスト刊行 1998

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

    2001 2008 2015 2016 2019 Agile Testing 年表 継続的 テスト モデル 実例 マッピング テスト マニフェスト Agile Testing Condensed 刊行 1998年以前に、 欠陥を防ぐ 品質はチーム全体での責任 という考え方は無かったのか?
  39. ISTQBの 前身が 発足 QCリサーチ グループ 結成 ソフトウェアの 検査の考え方 発表 ソフトウェア製品生産管理:

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

    ソフトウェア工学における 品質管理(QC)と品質保証(QA) 発表 日本的品質管理刊行 ソフトウェアの 品質管理推進 について 発表 1949 1972 1980 1981 1998 新製品開発 の品質管理 を始める 1950年代 後半 日本では半世紀以上前から 欠陥を防ぐ 品質はチーム全体での責任 という考え方を持っていた
  41. QA活動とは何か? 品質保証(Quality Assurance)とは • マニュアル通り作っているかチェックする活動 • チェックリストの内容を確認する活動 • ソフトウェアエンジニアリングを用いた活動 ◦

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

    要求が漏れにくいような要件定義を考える ◦ 適切なアーキテクチャの良し悪しを考える ◦ 欠陥が発生しにくい設計を考える ◦ テスト自動化を検討する ◦ 稼働実績の把握とフィードバックを考える 日本では昔から 存在する考え方
  43. 未来はどうなるのか? • 手法は新たに発明されるかもしれないが 根本的な考え方は昔から変わらないかも • 新たな技術に飛びつくのも大事だが、 根本的な考え方を見失わないようにしよう! ◦ 「新しい手法だから」 「新しい単語だから」は危険な兆候

    ◦ 本日紹介した実例マッピングを導入する 際も、根本となる考えを思い出して! • New Decadeに思いを馳せる前に、 温故知新の考えを持つと良い 今までのQAのやり方はダメだ! ではなく、 本来行っていたQAを知らなかった! だけかもしれない…。 (私自身、反省…)
  44. まとめ • Agile Testingのことを開発者や経営者にも 気軽に知ってもらうために 『Agile Testing Condensed』は刊行された • チーム全体でプロダクトの品質に責任を持とう

    • 具体例を用いることで、 より協力して開発を進めることができる • Agile Testingで述べられていることは、 実は昔から日本でやられている(組織もある) ◦ Agileかそうではないか、 テスターか開発者かは関係ない
  45. その他、参考文献(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
  46. 検査重点主義の品質管理 • 性悪説的な考え方 ◦ 生産部門は悪いことをするもしれない ▪ 厳しく管理しよう ▪ 検査部門を独立させ、権限を強くしよう •

    検査を強化することが品質保証につながる • 日本ではQCを初めてすぐ、この考え方を捨てた • 工場従業員に対する検査員の比率(1981年当時) ◦ 日本…1〜5%(検査重点主義ではない) ◦ 欧米…15%の場合も(検査重点主義)
  47. 新製品開発重点主義の品質管理 • 新製品企画からアフターサービスまでの 各ステップごとにしっかりした評価を行う ◦ 本生産に入る前に十分な品質解析を行う • 格言「品質は設計と工程でつくり込め」 • 新製品開発のQAを重要視している理由

    ◦ 新製品開発中に品質管理していなければ、 十分な品質保証ができない ◦ 新製品開発に失敗すると、その企業は 倒産の瀬戸際に立たされることになる ◦ 全部門が、品質管理、品質保証を実際に体験できる
  48. 日本式TQC(Total Quality Control) • 1949年から行っているQC活動で生まれた考え方 • QC技術者が行うQCということではない • 各階層、各部門がQCを勉強し、実施する •

    トップやスタッフも含めた全員でQCを実施する • 品質の管理と同時に 原価管理、量管理、納期管理を推進していく • 海外にはCWQC(Company-Wide Quality Control) として紹介していた • 後にTQM(Total Quality Management)に発展し 欧米に受け入れられる
  49. 品質管理の時代変化 検査 重点 主義 工程 管理 重点 主義 新製品 開発

    重点 主義 ISO 9001 信仰 ?? ?? 検査 重点 主義 ?? ?? 1950 1990 2010 日 本 欧 米 認証主義 →ISO9000へ発展 日本的TQCの導入 →TQMへの発展
  50. 品質管理の時代変化 検査 重点 主義 工程 管理 重点 主義 新製品 開発

    重点 主義 ISO 9001 信仰 ?? ?? 検査 重点 主義 ?? ?? 1950 1990 2010 日 本 欧 米 認証主義 →ISO9000へ発展 日本的TQCの導入 →TQMへの発展 NBCが 「If Japan Can… Why Can't We?」 を放映
  51. 品質管理の時代変化 検査 重点 主義 工程 管理 重点 主義 新製品 開発

    重点 主義 ISO 9001 信仰 ?? ?? 検査 重点 主義 ?? ?? 1950 1990 2010 日 本 欧 米 認証主義 →ISO9000へ発展 日本的TQCの導入 →TQMへの発展 ・プロジェクト  マネジメントブーム ・プロセスを守ればOK ・国際規格を守ればOK