Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
品質管理の歴史学 / Quality Management History
Search
nihonbuson
December 15, 2024
Technology
3
100
品質管理の歴史学 / Quality Management History
WACATE 2024 冬
での発表資料です。
nihonbuson
December 15, 2024
Tweet
Share
More Decks by nihonbuson
See All by nihonbuson
シフトライトなテスト活動を適切に行うことで、無理な開発をせず、過剰にテストせず、顧客をビックリさせないプロダクトを作り上げているお話 #RSGT2025 / Shift Right
nihonbuson
2
800
境界値分析
nihonbuson
3
87
振る舞い駆動開発(BDD)における、テスト自動化の前に大切にしていること #stac2024 / BDD formulation
nihonbuson
5
2k
品質管理チームのEMとして大事にしていること / QA EM
nihonbuson
0
1.4k
忠実度という概念と開発手法 / Fidelity
nihonbuson
1
97
WACATE流 勉強会会場の選び方 / WACATE venue
nihonbuson
1
650
継続的テストモデルを実現するためにスリーアミーゴスを用いた10Xでのシフトレフトの事例
nihonbuson
3
1.6k
BDD(Cucumber)コミュニティが無料提供しているコンテンツの紹介と現在起きている危機
nihonbuson
4
4.9k
JSTQB FL 幻のテスト技法「ユースケーステスト」を学ぶ / Use_case_testing
nihonbuson
5
2.7k
Other Decks in Technology
See All in Technology
サーバーなしでWordPress運用、できますよ。
sogaoh
PRO
0
170
Unlearn Product Development - Unleashed Edition
lemiorhan
PRO
2
160
AWS re:Invent 2024 Recap in ZOZO - Serverless で好きなものをしゃべってみた
chongmyungpark
0
900
12 Days of OpenAIから読み解く、生成AI 2025年のトレンド
shunsukeono_am
0
970
組織に自動テストを書く文化を根付かせる戦略(2024冬版) / Building Automated Test Culture 2024 Winter Edition
twada
PRO
25
6.9k
開発生産性向上! 育成を「改善」と捉えるエンジニア育成戦略
shoota
2
820
Denoで作るチーム開発生産性向上のためのCLIツール
sansantech
PRO
0
120
Google Cloud で始める Cloud Run 〜AWSとの比較と実例デモで解説〜
risatube
PRO
0
130
テストを書かないためのテスト/ Tests for not writing tests
sinsoku
1
140
メンタル面でもつよつよエンジニアになる/登壇資料(井田 献一朗)
hacobu
0
170
Fearsome File Formats
ange
0
540
20241218_マルチアカウント環境におけるIAM_Access_Analyzerによる権限管理.pdf
nrinetcom
PRO
3
140
Featured
See All Featured
Become a Pro
speakerdeck
PRO
26
5.1k
Site-Speed That Sticks
csswizardry
2
210
Practical Orchestrator
shlominoach
186
10k
Optimising Largest Contentful Paint
csswizardry
33
3k
GraphQLの誤解/rethinking-graphql
sonatard
68
10k
Facilitating Awesome Meetings
lara
50
6.2k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
97
17k
The Straight Up "How To Draw Better" Workshop
denniskardys
232
140k
The Cult of Friendly URLs
andyhume
78
6.1k
Building Your Own Lightsaber
phodgson
104
6.1k
Documentation Writing (for coders)
carmenintech
67
4.5k
Statistics for Hackers
jakevdp
796
220k
Transcript
品質管理の歴史学 ブロッコリー (@nihonbuson) https://www.pexels.com/ja-jp/photo/6387848/
自己紹介 • 風間裕也(ブロッコリー) • 株式会社10X 品質管理部 • 副業…B-Testing(個人事業主)として ◦ 株式会社MonotaRO(テストコンサルタント)
◦ グロース・アーキテクチャ&チームス株式会社 ◦ 他数社でお手伝い • 社外活動 ◦ JaSST Review実行委員長 ▪ ソフトウェアレビューシンポジウム ◦ WACATE実行委員長 ▪ ソフトウェアテストの 合宿型ワークショップ形式勉強会 SNS上の アイコン
翻訳書籍
はじめに 〜品質とは何か〜 Two ways photo created by aopsan - www.freepik.com
「品質」という訳語の歴史 「ニーズまたは期待を満たす能力に関する特性の全体」を 意味する"quality"の訳語としてわが国では長く「品質」 という用語が用いられてきた. (中略) 品質の「品」は,品物の「品」ではなく, 「品が良い,悪い」というときの「品」である. "quality"の訳語として,同様の意味を持つ,「品」と「質」 を重ねて「品質」という用語をあてたのである. 引用:飯塚悦功(2009).『現代品質管理総論』.朝倉書店,
p.3
品質管理の 歴史を遡る Time machine vector created by storyset - www.freepik.com
https://nureyon.com/seven_segment_indicator-4?pattern=5
None
None
テストの目的を定義したISTQBの前身が発足(1998) • 要件、ユーザーストーリー、設計、および コードなどの作業成果物を評価する ことによって欠陥を防ぐ。 • 明確にしたすべての要件を満たしていることを検証する。 • テスト対象が完成したことを確認し、ユーザーやその他ステークホルダーの期待 通りの動作内容であることの妥当性確認をする。
• テスト対象の品質に対する信頼を積み重ねて、所定のレベルにあることを確証す る。 • 欠陥や故障を発見し、ソフトウェアの品質が不適切になるリスクレベルを軽減す る。 • ステークホルダーが意思決定できる、特にテスト対象の品質レベルについての十 分な情報を提供する。 • 契約上、法律上、または規制上の要件や標準を遵守する、 そして/またはテスト対象がそのような要件や標準に 準拠していることを検証する。 ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版Version 2018.J03より
テスト マニフェスト ISTQBの 前身が 発足 アジャイル ソフトウェア 開発宣言 実践 アジャイル
テスト刊行 199 8 200 1 200 8 201 5 201 6 201 9 Agile Testing 年表 継続的 テスト モデル Agile Testing Condensed 刊行 1998年以前に、 「欠陥を防ぐ」 といった考え方は 無かったのか?
None
None
None
デミング博士来日 1950年には、米国からW・エドワーズ・ デミング博士を招聘して、日科技連主催の 八日間セミナーが行われた。 (中略) デミング博士はサンプリングの専門家であるが、 日本のQCの導入者であり、よき理解者である ばかりでなく、大変な親日家でもある。 参考:石川馨(1981).『日本的品質管理<増補版>』.日科技連出版社, p.23
1950年代に品質を作り込むことをやっていた 1950年代後半から,新製品開発の品質管理 ということが盛んにいわれるようになります. つまり, 設計や開発段階からしっかりチェック, 管理を行い,いいものを作っていこう という考え方です. ソフトウェアの品質管理推進について(ENGINEERS 誌 1981年8月号)
ISTQBの 前身が 発足 QCリサーチ グループ 結成 ソフトウェアの 検査の考え方 発表 ソフトウェア製品生産管理:
ソフトウェア工学における 品質管理(QC)と品質保証(QA) 発表 日本的品質管理刊行 ソフトウェアの 品質管理推進 について 発表 1949 1972 1980 1981 1998 デミング 博士 来日 1950年
ISTQBの 前身が 発足 QCリサーチ グループ 結成 ソフトウェアの 検査の考え方 発表 ソフトウェア製品生産管理:
ソフトウェア工学における 品質管理(QC)と品質保証(QA) 発表 日本的品質管理刊行 ソフトウェアの 品質管理推進 について 発表 194 9 197 2 198 0 198 1 199 8 デミング 博士 来日 1950年 日本では半世紀以上前から 欠陥を防ぐ 品質はチーム全体での責任 という考え方を持っていた
日本と欧米における 品質管理の時代変化
時代変化を紐解く上での参考書籍 https://www.amazon.co.jp/ dp/4817100109 https://www.juse-p.co.jp /products/view/1020 https://www.asakura.co.jp/detail.php ?book_code=27566
品質管理の時代変化 検査 重点 主義 工程 管理 重点 主義 新製品 開発
重点 主義 ?? ?? 検査 重点 主義 ?? ?? 1950 1990 2010 日 本 欧 米
検査重点主義の品質管理 • 性悪説的な考え方 ◦ 生産部門は悪いことをするもしれない ▪ 厳しく管理しよう ▪ 検査部門を独立させ、権限を強くしよう •
検査を強化することが品質保証につながる • 日本ではQCを初めてすぐ、この考え方を捨てた • 工場従業員に対する検査員の比率(1981年当時) ◦ 日本…1〜5%(検査重点主義ではない) ◦ 欧米…15%の場合も(検査重点主義) 参考:石川馨(1981).『日本的品質管理<増補版>』.日科技連出版社, p.107
品質管理の時代変化 検査 重点 主義 工程 管理 重点 主義 新製品 開発
重点 主義 ?? ?? 検査 重点 主義 ?? ?? 1950 1990 2010 日 本 欧 米
工程管理重点主義の品質管理 • 生産工程をよく管理して 全製品を良品にしてしまおうという考え方 • QCの格言「品質は工程でつくり込め」 • 検査部門だけでは目的を達成できない ◦ トップから作業員までQCを実施する
• 開発・設計段階に起因する問題は 製造部門や検査部門でカバーできない 参考:石川馨(1981).『日本的品質管理<増補版>』.日科技連出版社, p.110
工程管理重点主義の品質管理 • 生産工程をよく管理して 全製品を良品にしてしまおうという考え方 • QCの格言「品質は工程でつくり込め」 • 検査部門だけでは目的を達成できない ◦ トップから作業員までQCを実施する
• 開発・設計段階に起因する問題は 製造部門や検査部門でカバーできない 参考:石川馨(1981).『日本的品質管理<増補版>』.日科技連出版社, p.110 PDCAサイクル の実施 3現主義 (現場、現物、現実)
品質管理の時代変化 検査 重点 主義 工程 管理 重点 主義 新製品 開発
重点 主義 ?? ?? 検査 重点 主義 ?? ?? 1950 1990 2010 日 本 欧 米
新製品開発重点主義の品質管理 • 新製品企画からアフターサービス までの各ステップでしっかりした評価を行う ◦ 本生産に入る前に十分な品質解析を行う • 格言「品質は設計と工程でつくり込め」 • 新製品開発のQAを重要視している理由
◦ 新製品開発中に品質管理していなければ、 十分な品質保証ができない ◦ 新製品開発に失敗すると、その企業は 倒産の瀬戸際に立たされることになる ◦ 全部門が、品質管理、品質保証を実際に体験できる 参考:石川馨(1981).『日本的品質管理<増補版>』.日科技連出版社, p.110
日本と欧米での発展の違い 検査 重点 主義 工程 管理 重点 主義 新製品 開発
重点 主義 ?? ?? 検査 重点 主義 ?? ?? 1950 1990 2010 日 本 欧 米 認証主義 →ISO9000へ発展
日本式TQC(Total Quality Control) • 1949年から行っている QC活動で生まれた考え方 • 各階層、各部門がQCを勉強し、実施する ◦ QC技術者が行うQCということではない
• トップやスタッフも含めた全員でQCを実施する • 品質の管理と同時に 原価管理、量管理、納期管理を推進していく • 海外にはCWQC(Company-Wide Quality Control) として紹介していた 参考:石川馨(1981).『日本的品質管理<増補版>』.日科技連出版社, p.127
欧米式TQC(Total Quality Control) • ファイゲンバウム博士の考え方 • 本来のTQCの考え • 全部門がQCを実施する必要がある •
QC技術者が中心になって活躍する必要がある • どのようにすれば品質が良いものになるか 企業が示す ◦ 後に規格化され、認証されたものが 良いものであるという考え方になる 参考:石川馨(1981).『日本的品質管理<増補版>』.日科技連出版社, p.126
日本式TQCが欧米へ持ち込まれる 検査 重点 主義 工程 管理 重点 主義 新製品 開発
重点 主義 ?? ?? 検査 重点 主義 ?? ?? 1950 1990 2010 日 本 欧 米 認証主義 →ISO9000へ発展 日本式TQCの導入 →TQMへの発展
日本式TQCが欧米へ持ち込まれる 検査 重点 主義 工程 管理 重点 主義 新製品 開発
重点 主義 ?? ?? 検査 重点 主義 ?? ?? 1950 1990 2010 日 本 欧 米 認証主義 →ISO9000へ発展 日本式TQCの導入 →TQMへの発展 NBCが 「If Japan Can… Why Can't We?」 を放映
「If Japan Can…Why Can't We?」とは • 1980年6月24日の21:30から1時間半、 NBC放送局によって全米放映されたテレビ番組 • 多くのアメリカ企業に影響を与えたと
言われている • The Deming Instituteによって、 2015年からYouTubeで無料公開されている ◦ 動画
「If Japan Can…Why Can't We?」の内容 エンジンに関する新しい環境規制を議論するとき、 アメリカの製造業者は、 • それを延期する方法 •
それを止める方法 • どの議員に連絡するか についてすぐに考える傾向があります。 トヨタ、ホンダ、フォルクスワーゲンは研究者と開発者が これらの仕様を満たす課題として取り組んでいます。 つまり、早く顧客が戻ってくる方法を考えています。 参考:If Japan Can, Why Cant We? – 1980 NBC Special Report
「If Japan Can…Why Can't We?」の内容 アメリカでは、 生産性の問題に対して労働者から貢献を引き出すために、 経営者と労働者の関係を変える必要があります。 参考:If Japan
Can, Why Cant We? – 1980 NBC Special Report
「If Japan Can…Why Can't We?」の内容 アメリカでは、 生産性の問題に対して労働者から貢献を引き出すために、 経営者と労働者の関係を変える必要があります。 参考:If Japan
Can, Why Cant We? – 1980 NBC Special Report 欧米式TQCから 日本式TQCへの 転換を訴えた 番組内容
日本式TQCが欧米へ持ち込まれる 検査 重点 主義 工程 管理 重点 主義 新製品 開発
重点 主義 ?? ?? 検査 重点 主義 ?? ?? 1950 1990 2010 日 本 欧 米 認証主義 →ISO9000へ発展 日本式TQCの導入 →TQMへの発展 NBCが 「If Japan Can… Why Can't We?」 を放映
欧米式TQCが日本へ持ち込まれる 検査 重点 主義 工程 管理 重点 主義 新製品 開発
重点 主義 ISO 9001 信仰 ?? ?? 検査 重点 主義 ?? ?? 1950 1990 2010 日 本 欧 米 認証主義 →ISO9000へ発展 日本式TQCの導入 →TQMへの発展
欧米式TQCが日本へ持ち込まれる 検査 重点 主義 工程 管理 重点 主義 新製品 開発
重点 主義 ISO 9001 信仰 ?? ?? 検査 重点 主義 ?? ?? 1950 1990 2010 日 本 欧 米 認証主義 →ISO9000へ発展 日本式TQCの導入 →TQMへの発展 ・プロジェクト マネジメントブーム ・プロセスを守ればOK ・国際規格を守ればOK
日本的品質管理とISO 9000の品質保証の違い 参考:飯塚悦功(2009).『現代品質管理総論』.朝倉書店, p.31 日本的品質管理 でいう品質保証 ISO 9000 でいう品質保証 ・お客様が安心して使って
いただけるような製品を 提供するための すべての活動 ・総合的な品質管理活動 以下を満たす能力が あることの実証 ・契約型製品であれば契約事項 ・市場型製品であれば 製品仕様に明示された事項 ・組織内部で定めた要求事項
プロセスを決めれば品質保証できるという幻想 品質保証の歴史学 at「リリカルの質問全部答えます」
品質管理の時代変化 検査 重点 主義 工程 管理 重点 主義 新製品 開発
重点 主義 ISO 9001 信仰 ?? ?? 検査 重点 主義 ?? ?? 1950 1990 2010 日 本 欧 米 認証主義 →ISO9000へ発展 日本式TQCの導入 →TQMへの発展 日本式品質管理と 欧米式品質管理の 逆転現象
品質管理の時代変化 検査 重点 主義 工程 管理 重点 主義 新製品 開発
重点 主義 ISO 9001 信仰 ?? ?? 検査 重点 主義 ?? ?? 1950 1990 2010 日 本 欧 米 認証主義 →ISO9000へ発展 日本式TQCの導入 →TQMへの発展
新・品質の時代 品質保証というと,守りの品質保証,すなわち失敗, 取りこぼしの防止に目が向けられやすい. こうした側面はもちろん重要ではあるが,品質の第一義は 顧客満足であり,品質の保証といえば,第一に顧客に 受け入れられる製品・サービスの企画を考えるべきである ことは自明である. 変化の時代,成熟した時代の事業経営においては, 品質保証の原点であるこの視点がことさら重要である. 引用:飯塚悦功(2009).『現代品質管理総論』.朝倉書店,
p.208
最近提唱されている考えと TQC/TQMは 何が違うのか? Designed by Freepik - jp.freepik.com
最近提唱されている考え • テストマニフェスト • Holistic Testing(旧Agile Testing) • QA2AQ •
Leading Quality
テストマニフェスト http://www.growingagile.co.za/2015/04/the-testing-manifesto/ 日本語版: https://nihonbuson.hatenadiary.jp/entry/TestingManifesto
バグの発見よりもバグの防止 検査の業務は単なる評価ではなく, 予防に主眼を置いた広汎な活動領域である. ソフトウェアの検査の考え方(学会誌「情報処理」1972年5月号)
機能性をチェックするよりも チームが理解している価値をテストする ソフトウェアは 「原理的に動く」だけのものであってはならず, 「製品として価値がある」ものでなければ, システムにおける機能を全うし得ない. ソフトウェアの検査の考え方(学会誌「情報処理」1972年5月号)
直接部門と間接部門のいかんを問わず,(中略) いろいろな角度から 全社的品質管理(Total Quality Control:TQC)を 推し進めてゆかねばならない. ソフトウェア製品生産管理:ソフトウェア工学における品質管理(QC)と品質保証(QA) (学会誌「情報処理」1980年10月号) テスターの責任よりも 品質に対するチームの責任
テストマニフェスト http://www.growingagile.co.za/2015/04/the-testing-manifesto/ 日本語版: https://nihonbuson.hatenadiary.jp/entry/TestingManifesto
テストマニフェスト http://www.growingagile.co.za/2015/04/the-testing-manifesto/ 日本語版: https://nihonbuson.hatenadiary.jp/entry/TestingManifesto 昔から テストマニフェストの ような考え方をしていた
Holistic Testing(旧Agile Testing) 研修コースのブランドを 「チーム全体のアジャイルテスト(Agile Testing)」から 「全体的なテスト(Holistic Testing) :アジャイルチームの戦略」 に変更します。
参考:Holistic testing: What it means for agile teams
Holistic Testing(旧Agile Testing) https://janetgregory.ca/testing-from-a-holistic-point-of-view/ 日本語版①:https://note.com/globis_engineers/n/neeaad6dfd67b 日本語版②:https://daipresents.com/2022/05/09/testing-from-a-holistic-point-of-view/
Holistic Testing(旧Agile Testing) テストを行う際には、(中略) あらゆる種類のテストを考慮する必要があり、(中略) チーム全体・製品組織・顧客さえも含まれるのです。 【翻訳】ホリスティック・テスト:プロセス全体からテストを捉えなおす(Testing From A Holistic
Point Of View)
Holistic Testing(旧Agile Testing) テストを行う際には、(中略) あらゆる種類のテストを考慮する必要があり、(中略) チーム全体・製品組織・顧客さえも含まれるのです。 【翻訳】ホリスティック・テスト:プロセス全体からテストを捉えなおす(Testing From A Holistic
Point Of View) 新製品開発重点主義の考え方と似ている
QA2AQ QA2AQは、アジャイル品質の考え方と推奨される 実証された活動のエッセンスを、問題と解決をペアにした パターンのカタログとしてまとめたものです。 QA2AQとの名称には、 「伝統的な品質保証(Quality Assurance, QA)から アジャイル品質(Agile Quality,
AQ)へと変わっていこう」 「昔ながらの品質保証の考え方から脱却し、 アジャイル開発に適合する形でよりアジャイルな方法で 品質保証を進めよう」 といったメッセージが込められています。 参考:https://codezine.jp/article/detail/12092
QA2AQ QA2AQの発表者の1人、Joseph Yoderは、 下記のように述べています。 • QAまたはTQCは、全体に関与する 最初からプロセスに品質を組み込む アプローチです。 これをアジャイル品質(AQ)と呼びます。 参考:XP祭り2018:QA
to AQ – Being Agile at Quality: Values, Practices, and Patterns
書籍『Leading Quality』 2019年8月刊行の書籍。 総合品質管理(TQM)は、 生産だけに焦点を合わせるのではなく、 品質を「顧客に価値を提供すること」と定義しました。 製造業におけるTQMの動きがビジネスの成果に 焦点を合わせ、「顧客に価値を提供する」ことを 経営幹部の最前線にもたらしたように、 今日のソフトウェアリーダーも同じことを始めています。
書籍『Leading Quality: How Great Leaders Deliver High-Quality Software and Accelerate Growth』より
日本では昔からQA活動の範囲が広かった https://twitter.com/yoshikiito/status/1515325728585568259
https://www.slideshare.net/slideshow/line-developer-meetup-in-tokyo-39-presentation-modified/104158117#15
おわりに
まとめ • 品質管理・品質保証の範囲は広い • 最近提唱されている考えは、 実は昔から日本でやられている
参考書籍 https://www.amazon.co.jp/ dp/4817100109 https://www.juse-p.co.jp /products/view/1020 https://www.asakura.co.jp/detail.php ?book_code=27566
その他、参考文献 • ソフトウェアの品質管理推進について • ソフトウェアの検査の考え方 • ソフトウェア製品生産管理:ソフトウェア工学におけ る品質管理(QC)と品質保証(QA) • Agile
Testing Condensed Japanese Edition【書籍】 • If Japan Can, Why Can't We?【動画】 • Quality Management Evolution from the Past to Present: Challenges for Tomorrow • 品質保証の歴史学 at 「リリカルの質問全部答えます」
参考:米国専門家が捉えた品質管理の時代変化 Quality Management Evolution from the Past to Present: Challenges
for Tomorrow のTable2を翻訳
参考:米国専門家が捉えた品質管理の時代変化 Quality Management Evolution from the Past to Present: Challenges
for Tomorrow のTable2を翻訳
参考:米国専門家が捉えた品質管理の年表 Quality Management Evolution from the Past to Present: Challenges
for Tomorrow のTable1を参考に作成
参考:米国専門家が捉えた品質管理の年表 Quality Management Evolution from the Past to Present: Challenges
for Tomorrow のTable1を参考に作成
おしまい