1. Demystifying Quality Management
for Large-Scale Manufacturing
in Modern Context
～品質の高い製造業の品質マネジメントをイマドキの考え方で整理してみた～
16th Apr 2021
DevOpsDays Tokyo 2021
西 康晴（電気通信大学）
@YasuharuNishi / Yasuharu.Nishi@uec.ac.jp

2. おまえ、誰?
• ソフトウェアのテストや品質マネジメントについて研究する人
– 電気通信大学というところにいます
• 製造業（やそれ以外に）
ソフトウェアのテストや品質マネジメントをコンサルティングする人
– 自動車関連、生産設備、家電・AV、医療機器など
– 20年以上の経験がある
• 様々な日本のテスト・QA関連のコミュニティに関わっている人
– メーリングリスト、カンファレンス、NPO法人、資格試験、国際規格など
• TQMマフィアの下っ端のさらに下っ端の人
– 生まれはなぜかTQM村でございます
© NISHI, Yasuharu
p.2

3. Quality Management（品質マネジメント）
• イマドキのソフトウェア開発組織において
「品質保証」や “Quality Assurance” と呼ばれるロールはきちんと定義されていない
– 大規模製造業では「品質マネジメント」と呼ばれることが多い
– イマドキのソフトウェア開発組織は、品質マネジメント関連のロールを整理する必要がある
• QM（品質マネジメント）には3つのロールがある
• TE – テストやレビュー、メトリクスの測定など製品やサービスの評価技術のエキスパート
• SET&SRE – 様々な自動化を行うエキスパート、PE？
• QA – 組織能力を高めるエキスパート
– ロールをきちんと区別しないと、適切にスキルを高められない
– その一方で、それぞれのロールをサイロ化させずに融合していかなくてはならない
• 異なるロールが異なる人に割り当てられている状況でも、
他のロールのことを理解していなければ良い仕事はできない
• このプレゼンテーションでは、
3つのロールを身につけたQMになってよりよく品質を向上していくために、
TEがQAになるためのマインドセットを紹介する
– ハードウェアのTQMをものすごくデフォルメして紹介する
© NISHI, Yasuharu
p.3
QMの三角錐
SET&SRE
→

4. 品質立国ニッポン
• 日本のハードウェアの品質は高いと言われている
– 自動車、生産設備、建築機械など
– 強い製造業企業は、品質が高いだけでなくスピードも速い
• 自動車の開発はもともと48ヶ月かかっていたが現在は15ヶ月
– 派生車であれば最短で10ヶ月が実現されている
• 強い製造業の企業は品質マネジメントに関するフレームワークを持っている
– TQM (Total Quality Management: 日本的な総合的品質管理)
– TPS (Toyota Production System: トヨタ生産方式)
– Taguchi methods（タグチメソッド）
– 独自の品質マネジメントフレームワークを構築できている企業はとても強い
© NISHI, Yasuharu
p.4

5. 日本のTQMの起源
• Dr. Edward Deming （デミング博士）
– 1947年に来日して統計的品質管理を教えた
• Dr. Joseph Juran（ジュラン博士）
– 1954年に来日して、
品質管理の考え方を全社的に応用できることを教えた
• Dr. Kaoru Ishikawa（石川馨教授）
– デミングとジュランに教えてもらったことを魔改造し、
TQM（当時はTQC）の原則を構築した
– 石川馨は日本のTQMマフィアのゴッドファーザーである
• ちなみに「魅力品質・当たり前品質」の狩野紀昭は
TQMマフィアの大幹部である
© NISHI, Yasuharu
p.5
https://www.juse.or.jp/deming_en/award/
https://www.juse.or.jp/qc_circle/case/
https://www.agilityiq.io/product-management/the-kano-model-for-prioritization/
https://www.sme.org/technologies/articles/2005/
masters-of-manufacturing-joseph-m.-juran/

6. © NISHI, Yasuharu
p.6 https://www.qc-ep.com/copy-of-lean-manufacturing-1
リーン生産の歴史

7. © NISHI, Yasuharu
p.7 https://www.qc-ep.com/copy-of-lean-manufacturing-1
リーン生産の歴史
TQMだけが偉いのではなく、
様々なフレームワークが
お互いに学び合いながら進化してきた

8. TQMのマインドセット
• 品質
• 品質第一
• カイゼンサイクルと標準化
• 方針管理
• 目的指向とプロセス主義
• 水平展開による品質の作り込み
• 全員参加と「後工程はお客様」
• 事実に基づく管理と5ゲン主義
• 自律と小集団活動
• 人間性尊重
• 悪さの知識
© NISHI, Yasuharu
8
たくさんあって大変なので、
イマドキの
ソフトウェアエンジニア向けに
思いっきりデフォルメします

9. （日本の製造業で）本当に品質の高い組織の持つマインドセット
• Journey into quality forever
– ずっと「品質とは何か」を考え続ける
• Make everyone perseveringly smarter
– 全員をより賢い愚直にし続ける
• Enhance co-confidence
– 納得感の共感を高め続ける
• Nestle weakness
– 弱さヲ抱擁スル
© NISHI, Yasuharu
p.9

10. Journey into quality forever: ずっと「品質とは何か」を考え続ける
• 品質とは何か？
– ソフトウェア開発では「ユーザだけが品質を判定できる」がみんな大好き
– ワインバーグ師匠の「品質は誰かにとっての価値である」も大好き
• これは「価値って言ってるんだからユーザの価値だろ」という意味じゃないので注意
• （日本的）TQMでは「あらゆる（品）質が重要」と言っている
– 「製品の質、仕事の質、サービスの質、情報の質、工程の質、部門の質、
作業者・技術者・管理者・経営者の質つまり人の質、システムの質、会社の質、方針の質、等々
というように、これらすべての質を管理していこうというのが、われわれの基本姿勢である」（石川馨）
– 品質マネジメントの人たちは、誰の何の質について（だけ）扱っているかを常に徹底的に考え続けなければならない
• ユーザは品質について理解しているのだろうか？
– もちろん！
• だから、日本の製造業企業はユーザからのフィードバックを得るプロセスを構築してきた
– はい
• だから、スピーディなフィードバックが難しい場合は、社員が仮想のユーザに扮する
– いいえ、のこともあります
• だって、ユーザは「こんな製品なんて想像したこともなかったわ！超欲しい！」と言うことがある
– いいえ
• だって、ユーザは保守性の高い設計のような品質は分からない
© NISHI, Yasuharu
p.10
From his twitter

11. Journey into quality forever
• 品質の高い日本の製造業企業は、カスタマーサポートやマーケティングと連携して
お客様からのフィードバックを得るサイクルを構築してきた
© NISHI, Yasuharu
p.11
Development
User Support
/ Marketing

12. Journey into quality forever
• ある家電企業は、お客様の生活を心から理解するために、
工場の中に家を建てて、品質保証の技術者が主婦の生活をシミュレートしていた
© NISHI, Yasuharu
p.12

13. Journey into quality forever
• 日本の製造業企業の中には、ITによるフィードバックサイクルを既に構築していたり、
手を付け始めたところがある
– 建機や農機は、稼働データを自動的に収集して機材やお客様のビジネスの改善に活かしているところがあるらしい
– 自動車関係では、実走行データを使ってCI/CDやDevOpsを始めようとしているところがあるらしい
– ハードウェアでも反復型開発を行うために、製品設計のモジュラー化を進めようとしているところがあるとかないとか
© NISHI, Yasuharu
p.13

14. Journey into quality forever
• 高い品質を達成している日本企業は、
全ての品質を高め続けようと長い時間をかけて奮闘している
– 短期的にはトレードオフや妥協が必要となる場面がある
– それでも、継続的な改善やイノベーションによって全ての品質を高め続けようという強い意志がある
• 高い品質を達成している日本企業の品質マネジメントの人たちは、
いつも社内を歩き回って品質を高めるために必要なことは何でもやっている
– あらゆるステークホルダーと話して理解する
– 全員がお互いを理解できるように奮闘する
– 品質は全員のミッションだと全員が考えるように奮闘する
– 全員であらゆる品質を高め続けていくように奮闘する
© NISHI, Yasuharu
p.14

15. Journey into quality forever
• 品質マネジメントの人たちにとって、品質は終わりのない旅路なのである
© NISHI, Yasuharu
p.15

16. Make everyone perseveringly smarter: 全員をより賢い愚直にし続ける
• （日本的）TQMでは、組織の質や人の質をとても重視する
– （日本的）ＴＱＭにはサイロ化を防ぐさまざまなマインドセットやプラクティスが含まれている
• 品質マネジメントの人たちは、
組織自身がより「賢い愚直」に自らなっていくように奮闘してきた
– 全員参加
– チームワーク
– 次工程はお客様
– 重層的なフィードバックサイクルとフロントローディング
• 品質マネジメントの人たちは、全員がより賢い愚直に自らなっていくように奮闘してきた
– （日本的）TQMでは、全ての品質を高め続けようと長い時間をかけて奮闘していると、
人々が賢い愚直になれると考えている
– （日本的）TQMは、人々が賢い愚直になるための方法論を包含している
• 統計的考え方・統計技術
• なぜなぜ分析
• 5ゲン主義
• 悪さの知識
© NISHI, Yasuharu
p.16

17. Make organization perseveringly smarter: 組織を賢い愚直にし続ける
• 全員参加
– 誰かが品質に鈍感になっていないかをいつも気をつける
– 「私作る人、僕食べる人」にならないよう、常に横串を通しサイロ化を崩し続ける
• 開発だけが縦割りになるのではなく、品質保証部そのものも縦割りになるので注意が必要である
• チームワーク
– ワイガヤな現場はカイゼンがたくさん発生する
– QCサークルは「モブカイゼン」の仕組みである
• 次工程はお客様
– 自分の工程で改善すべき点の悪影響を一番被るのは次工程であるので、
次工程がお客様のように満足するようにすれば、自分の工程がどんどんよくなっていく
• 重層的なフィードバックサイクルとフロントローディング（a.k.a. PDCAサイクル）
1. ビジネスレイヤでのお客様とのフィードバックサイクルとフロントローディング
2. 組織間のフィードバックサイクルとフロントローディング
3. 隣の工程とのフィードバックサイクルとフロントローディング
4. 自分の工程でのフィードバックサイクルとフロントローディング
© NISHI, Yasuharu
p.17
From Wikipedia

18. Make organization perseveringly smarter
© NISHI, Yasuharu
p.18
Development
User Support
/ Marketing
• ビジネスレイヤでのお客様とのフィードバックサイクルとフロントローディング
– 例） リーンでオープンな組織づくり

19. Make organization perseveringly smarter
© NISHI, Yasuharu
p.19
Development User Support
/ Marketing
Design Production
• 組織間のフィードバックサイクルとフロントローディング
– 例） コンカレント・エンジニアリング

20. Make organization perseveringly smarter
© NISHI, Yasuharu
p.20
Design
Review
Design
Development User Support
/ Marketing
Production
• 隣の工程とのフィードバックサイクルとフロントローディング
– 例） 前倒し・前捌き活動（フロントローディング）

21. Make organization perseveringly smarter
© NISHI, Yasuharu
p.21
Design
Review
Development User Support
/ Marketing
Production
• 自分の工程でのフィードバックサイクルとフロントローディング
– 例） QCサークル活動

22. Make people perseveringly smarter: ひとを賢い愚直にし続ける
• 「シフトレフト」は、単に早くから何かをすればいい、という意味ではない
– 知恵をフィードバックしてこそ成功する
• 知恵をつくる方法論を組織で構築し浸透しておかないと、薄っぺらいアイデアだけがフィードバックされる
– （日本的）TQMでは知恵をつくる方法論を提供している
• 統計的考え方・統計技術 / なぜなぜ分析 / 5ゲン主義 / 悪さの知識
• 統計的考え方・統計技術
– 大量生産のように、反復的なことから知恵をつくるのが、統計である
• 統計は上手に使わないと騙されてしまう
• なぜなぜ分析
– なぜを繰り返すことで知恵をつくるのが、なぜなぜ分析である
• なぜを繰り返しすぎると、「我々が人間だから」のような意味の無い理由が出てきてしまう
• 5ゲン主義
– 思考の抽象度を揺すらせることによって知恵をつくるのが、5ゲン主義である
• 3つの具体： 現場・現物・現実
• 2つの抽象： 原理・原則
© NISHI, Yasuharu
p.22

23. Make people perseveringly smarter
• 品質マネジメントの人たちにとって、悪さの知識はとても重要である
– 開発のエキスパートは、「良さの知識」と「悪さの知識」の両方を持っているから腕が良い
• 「良さの知識」とは、デザインパターンなど、どうすれば成功するかのパターンである
• 「悪さの知識」とは、コードの（不吉な）臭いなど、どうすれば失敗するかのパターンである
– 開発エンジニアは「悪さの知識」を避けるし、嫌いだし、忘れたがる傾向がある
• だから品質マネジメントの人たちは「悪さの知識」に着目して抽出して再利用するだけでなく、
好きにならなければならない
– 品質の高い日本の製造業企業では「悪さの知識」を組織的に蓄積し再利用している
• FMEAにおける故障モードは、（特にソフトウェアの）欧米の故障モードと異なり、「悪さの知識」を表現している
• 3D-CAD（設計ツール）に「悪さの知識」がたくさん蓄積されるようにしている
© NISHI, Yasuharu
p.23
https://interfaces.com/blog/2013/08/some-examples-of-design-failure-on-physical-space/

24. Make people perseveringly smarter
• 我々は“ソフトウェアトラップ”として「悪さの知識」をパターン化している
– ソフトウェアトラップは、要求や設計でバグが入り込みやすいパターンを表している
• ASTER/バグシェルジェでオープンに議論している
– 「浦島太郎」トラップ（欧米ではRip Van Winkleという逸話になる）
• 浦島太郎は、竜宮城に行って帰ってきたらあらゆることが変わってしまっていた、という話
• 「寿命の短いプロセスからフォークされた、物理的時間を伴う子プロセスは戻り先を失いやすい」
– カーナビで、ナビゲーション終了間際にディスクをイジェクトすると、
イジェクト子プロセスが動作中に親であるナビゲーションプロセスが終了してしまい、
イジェクトプロセスが戻り先を失い一般保護違反になる、という不具合からパターン化されている
© NISHI, Yasuharu
p.24
From Wikipedia

25. Make people perseveringly smarter
• コンフリクトこそが知恵を生み出す
– 知恵を生み出す方法論はどれもコンフリクトを内包している
• 統計的考え方・統計技術、なぜなぜ分析、5ゲン主義、悪さの知識は
全てコンフリクトを内包している
– Conflict: 衝突, 矛盾, 不一致, 葛藤（かっとう）, 板ばさみ, 対立（ジーニアス英和辞典）
– 仕事を進めていくためにトレードオフは必要だが、
コンフリクトは知恵を生み出すと前向きに捉えよう
© NISHI, Yasuharu
p.25
Conflict

26. Enhance co-confidence: 納得感の共感を高め続ける
• テストもプロセスも品質を保証しない、という事実に向き合わなくてはならない
– エキスパートのテストエンジニアはベストを尽くしているとはいえ、網羅的なテストは不可能である
– そうなると誰もが分かっているのに、プロセスはどうしても形骸化・重量化しやすい
• 全員が納得感を共感することだけが、品質を保証できる
– 自分や周りがベストな仕事をしている、という納得感を全員が共感できている組織は、
（その組織の技術力の上限まで）高い品質を達成できている
• 残念ながら「合意」や「議事録」、「エビデンス」ではない
– 知恵は納得感を向上させる
• 知恵の無い作業は「やらされ感」になり納得感は皆無になる
– モヤモヤ感や心配事は納得感が足りないサイン（兆候）である
• 品質マネジメントの人たちのミッションは、納得感の共感を全員が高めていくことである
– 決して、全員にルールや標準、プロセスを守らせることではない
– テストは、ユーザや開発を含む全員の知恵を湧き出させる「るつぼ」である
– プロセスは、全員で知恵を共有し活用するツールである
– 品質マネジメントの人たちのミッションは、組織や個人で知恵をつくりだし循環させ増やしていくことである、と言える
– 納得感の共感の高い組織では、ムダやダメを自然に減らし、
より良い技術に自然に進化させようとするので、品質とスピードが自然に両立されていく
© NISHI, Yasuharu
p.26

27. Nestle weakness: 弱さヲ抱擁スル
• 過つは人の常（To Err is human） - Alexander Pope
– 限定合理性: 人間は不完全な存在であり、人間は弱さを持つ存在である
– 一人で自身の弱さを克服し続けられるほど強い人間はいない
• 弱さを抱擁し、全員がそれぞれ弱さに打ち勝っていけるよう
皆に寄り添うことが、品質マネジメントの人たちには必要である
– ペナルティや罰則ではバグは防げない
– バグを開発に投げればQAの仕事は終わり、なのではない
– バグを作り込んでしまった開発者と会話をして、
その開発者が納得感を共感できていたのかを尋ね、
モヤモヤ感や心配事をスルーしてしまった理由を聞きましょう
– その開発者が、「悪さの知識」を生み出せるように寄り添いましょう
© NISHI, Yasuharu
p.27
From Wikipedia

28. TEとQAは何が違うのか
• 高い品質を達成している日本の製造業の企業では、
モダンテスティングやアジャイルテスティングと同じようなマインドセットを持っている
– Journey into quality forever: ずっと「品質とは何か」を考え続ける
– Make everyone perseveringly smarter: 全員を賢い愚直にし続ける
– Enhance co-confidence: 納得感の共感を高め続ける
– Nestle weakness: 弱さヲ抱擁スル
© NISHI, Yasuharu
p.28

29. 品質マネジメントができるようになるために、まずTEからQAに広げよう
• アジャイルテスティングの4象限を拡張すると、
どう成長していけばいいかを考えやすい
– Business Facing → Journey into quality forever （ずっと「品質とは何か」を考え続ける）
– Critique Product → Make everyone perseveringly smarter （全員を賢い愚直にし続ける）
– Technology Facing → Enhance co-confidence （納得感の共感を高め続ける）
– Guide Development → Nestle weakness （弱さヲ抱擁スル）
© NISHI, Yasuharu
p.29
QMの三角錐
SET&SRE
→

30. まとめ
• 自分たちの組織のQAはどんな仕事なのかを言えるようにしよう
– TE？SET&SRE？QA？
– どれか一つだけじゃなくて、3つを理解できて初めてちゃんとQMができる
• TEだけじゃなくてQAとしても成長しよう
– そのために（日本的）TQMのマインドセットを理解して身につけよう
• Journey into quality forever
– ずっと「品質とは何か」を考え続ける
• Make everyone perseveringly smarter
– 全員をより「賢い愚直」にし続ける
• Enhance co-confidence
– 納得感の共感を高め続ける
• Nestle weakness
– 弱さヲ抱擁スル
– アジャイルテストの4象限を拡張しよう
• ＱＭになって成長して強い組織とひとを育てよう！
– 表面的な技法やツール、イマドキっぽい用語に踊らされるのはやめよう
© NISHI, Yasuharu
p.30