特性要因図に「全ての要因をもれなく列挙せよ」とか「なぜなぜ分析によって作る」といった誤った指導を受けた人に、このページは必読である。
→ なぜなぜ分析との違い
特性要因図を漫然と作成してはならない。特性要因図は誤解されやすく、QC活動で多くの場合に誤った(役に立たない)使い方がされている。
何の目的でどの特性要因図を作れば何が得られるのか、列挙する要因の種類や数が違う。特に、QCサークルは、No.1のタイプの特性要因図を学ぼう。→ 解析用特性要因図の分類
また、要因と「疑わしい要因」の区別を学ぶことが重要である。 → 用語の意味
特性要因図と「なぜなぜ分析」の違いについて概要を説明しよう。
惑わされないように、特性要因図となぜなぜ分析の違いを最初に述べよう。結論からいうと、これらは全く異なる手法であり、共通点はない。
事故が起きたときに、現場のデータ(手掛かり)を分析して(場合によってはそれを繰り返して)真の原因を突き止め、対策を講じて問題を解決しなければならない。
しかし、問題を解決下だけでは、管理の欠陥をそのまま放置することになって、再発を防止できない。
そこで、責任者と部下や関係者で構成する会議において責任者(議長)が「なぜ、事前に防げなかったか、管理システムのどこに欠陥があったか、意見を述べて欲しい」と切り出し、そこで提出された欠陥について、さらに「なぜ」を繰り返して対策可能な根本原因(システムの欠陥)を特定する活動が必要になる。これが「なぜなぜ分析」である。
詳細 → なぜなぜ分析
〔注〕管理システムとは、トラブルを予防するための規則、設計とそれを実行するのに必要な組織、人材、技術、設備等の経営資源をいう。
手法 | 事故 | 目的 | 内容 | 実施者 |
なぜなぜ分析 | 特定の一件の事故 | 再発 防止 |
管理システムの欠陥を追究 | 管理職 経営者 |
特性 要因図 |
ある期間の成績 | 予防 | 管理すべき要因を列挙 | 規則制定者 設計者 |
問題 解決 |
解析すべき要因を列挙 | 現場管理者 |
上の表で注目すべき点は、目的と実施者が異なることである。それによって内容の違いを推測して頂きたい。
他方、特性要因図は、特定の結果との原因系の関係を系統的に表した図(JIS z 8101)である。
平たく言うと、どのような事象(要因)がトラブルの原因になり得るかを示した図である。
特性要因図には、作成目的によって二つの種類がある。
今から工程(=業務プロセス)を設計しようとする際に作成する特性要因図で、頭の中にある知識や経験の記憶から想定されるトラブルごとに対策すべき要因を同じく想定によって漏れなく列挙したもの。
漏れなく列挙するのは、全ての要因に対策を講じなければトラブルを予防できないからである。しかし、漏れがないようにするのは容易でなく、一般に会議を開いて広く意見を募ることが望まれる。
種類 | 目的 | 作成時期 | 列挙する要因 | 要因の根拠 |
管理用 | 予防 | 設計,規則の作成時 | 影響し得る全要因 | 頭中の知識、経験 |
解析用 | 問題解決 | 問題の発生後 | 少数の疑わしき要因 | 現場の手掛かり |
トラブルが発生したときに、原因と疑われる要因(疑わしき要因)のみを列挙したもの。全ての要因を漏れなく列挙するのではなく、最も疑わしい要因を挙げる。
1つ~少数挙げて層別や対策を講じて「原因かどうか」を検証する。
それで解決しなければ、次の疑わしい要因を1つ~少数挙げる。少数にするのは、CAPDを繰り返して1つずつ原因かどうか確かめ、原因でなかったら次々に疑わしい要因を追加するからである(逐次追加型)。
小集団活動では、この逐次追加型が有益である。
よく見る間違いは、不良削減などの改善目的に、漏れなく要因を列挙した管理用の特性要因図を作成することである。
挙げる要因の数は、次のように異なる。
No | 列挙 | 原因の認定手順 |
---|---|---|
1 | ・1個の疑わしい要因 ・QCサークル一般 |
疑わしい要因を1個、2個、3個~と、CAPDサイクルを回すたびに次々に増やし、対策の効果が認められる要因があったら、それを原因と認定する。 参照 → 逐次増やしていく場合 |
2 | ・関連する一式の疑わしき要因 ・QCサークル中級 |
直交配列表を使った小規模な実験で、同一工程などの一式の疑わしき要因について実験し、不具合が再現された要因を原因と認定する。 参照 → 一式の要因を列挙する場合 |
3 | ・全ての要因 ・専門家向き |
直交配列表を使った大規模な実験で、不具合が再現された要因を原因と認定する。 参照 → 疑わしい要因がない場合 |
特性要因図が上の目的に役立つように作成するためには、工程管理(=事務や製造現場のプロセス管理)の仕組みを知らねばならない。
プロセスから生み出される成果(結果、特性)は、図の右上に示した次の5つである。
上に述べた成果(特性)に影響を与える原因系(条件)は、左下に「5M」と表示した項目である。
1. 品質や納期等に問題が起きないように管理するためには、これら「5M」を管理(正常に維持・改善)しなければならない。
2. また、不良などのトラブルが発生するときは、これら「5M」に原因が潜んでいる。
「5M」の内容は次の通りである。
ここに列挙したのは、工程から生み出される成果(特性)に影響する条件(=要因)である。これらが適切に選定され維持されれば工程が順調に稼働し、その結果として右上に列挙した成果(結果、特性)が順調に生み出される。
以上の中で、5Mが原因系であり、生み出された結果が特性系である。
〔注〕5Mに、マネジメント、環境、マネーを含めるのは望ましくない。
講習会が開かれている。そこにはパワーポイントを使って解説する講師、パソコン及び周辺機器、スクリーン、建物、教室、受講生が使う椅子とテーブルなど、ごく普通の風景がある。 この講習会はプロセス(工程)であるが、この工程で「材料」とは、何を指すか。 |
5Mは、次の要素で成り立つ。ポカによる作業ミスは、上の5Mのどれに属するか? → 演習問題(2)の正解
|
濱田金男氏は、次の事項は5Mの「人」に関する事項であると指導されている。正しくは、それぞれどの5Mに属するか?
|
〔演習問題(3)の正解〕
・「作業のバラつき」、「手作業による異物付着」、「個人差」等は、作業方法の異常を意味し、5Mの「方法」に属する。
・「指示違反」は5Mの全てにあり得る。指示に違反して誤った機械を使用すれば「機械」の問題だし、誤った材料を使えば「材料」の問題である。
以上の準備を経て、特性要因図に進もう。
特性要因図について、JISの定義がある。
特性要因図とは、特定の結果と原因系との関係を系統的に表した図 (JIS Z 8101)。 |
英語表記は、Characteristic diagram, Characteristic factor diagram, Fishbone diagram Ishikawa diagram 等。
このJISの定義の意味を一言で説明するのは意外に難しく、次の3つを解説する必要がある。
以下、これらを簡単に説明し、詳細は後述する。
特定性を要件とする理由は、特定しなければ数値的に把握・表現できずQC手法の対象にならないからである。例えば、「なぜ、コストが高いか」を特性の位置に置いて特性要因図のような図を描いても、どの製品のどの工程のコストか特定しないから特性要因図にはならない。
以上を分かりやすくするために、表に整理しよう。
特定の結果 | 列挙する | 目的 |
特性 (寸法など) | 要因 | 予防・管理 |
事故 (不良率など) | 疑わしい要因 | 原因解析 |
上表に示すように、生産技術課の工程設計者が列挙するのは要因であり、QCサークルが列挙するのは、原則、疑わしい要因である。
「系統的に表す」とは、次の意味である。
以下、具体的な例を示そう。
1. 魚骨図
「特定の結果」と「原因系」を矢印でつないで影響の伝達経路を示した図。
魚骨図の欠点:原理を説明するのに適するが、作成が困難で、要因を追加し、対策や効果を記載することが出来ない。
特性と要因の関係を系統的に表す様式として、石川先生は魚骨図を発明した。それ故、石川ダイヤグラム(Ishikawa diagram)とも呼ばれる。
2. 表形式
「特定の結果」と「原因系」を影響の伝達経路を示すように表した表。
表形式の長所:作成が容易で、要因を追加し、対策や効果を記載することができるので、実務で推奨される。
問題点は後述するとして、とりあえず、石川馨先生が最初に特性要因図を作成された際の考え方を紹介する。
特性要因図を最初に考案したのは、1952年に実験計画法の大家であられた東京大学教授、石川馨先生が川崎製鉄で品質管理の指導をされた際であり、実験計画で取り扱うべき要因を整理する目的で考案・使用されたと言われている。
悪い結果には必ず原因がある。しかし、原因となり得る事象(原因候補、要因)はいろいろあり、データで検証しない限りこれと決めかねる。
不良の原因として「これが一番疑わしい。次にあれが疑わしい」という具合に「疑わしい要因」があれば比較的取り組みやすいが、石川先生は製鉄の知識がなく、思い当たるものがない。
そこで特性値に影響する全ての要因を列挙して、その中から実験で原因を特定して一発勝負で一挙に解決しようと考えた。従って原因とは考えていない要因まで、関係ある要因を全部列挙したものになる。これは、本来は管理用・特性要因図である。
従来、この一発勝負のやり方をQCサークル活動に使用させようと指導する過ちが横行している。
石川先生は実験計画法の大家で、一発勝負のやり方を得意とした。この先生がQCサークルを提唱し、本来はCAPDサイクル(試行錯誤)で行うべき小集団活動に(誤って)一発勝負のQCストーリーを与えてしまった。
これが、QCサークルの「ホラ吹き大会」を招き、衰退の原因になったのである。
魚骨図の作り方を説明する。
右端に「特性」を記載する。
水平に「背骨」を引く。
「大骨」を引いて5Mを記載する。
「中骨」を引き、要因を束ねる分類(機械なら、機種、段取り、操作など必要なもの)を記載する。
「小骨」に、要因(例えば、速度)を記載する。
孫骨に要因の水準(高速、低速)を記載する。
しかし、ケースバイケーに変更してもよい。
例えば、「機械の回転速度」を要因として挙げる場合に、「人」でも「材料」でもなく「機械」に関するという意味で、「機械」の大骨の次に(小骨を省略して)中骨に要因として「速度」を示してもよい。
下の特性要因図について、若干の説明をする。
〔注目点〕
「研磨条件」というグループを中骨に設けると、小骨に属する要因は全て研磨条件だと分かる。
そして、これら研磨条件のどの組み合わせで「バルブの面荒れ」が起きるか、直交配列表を使った再現実験ができる。石川先生が特性要因図を発明した目的はここにある。
これと同じような特性要因図の作成を、直交配列表を使わない小集団活動に指導するのは誤りである。小集団活動は、列挙した多数の要因を検証する能力がないから、飾り目的で特性要因図を作成してしまう。
〔参照〕直交配列表を使った簡単な事例 → 直交配列表
「要因」と「原因」は、明確に区別しなければならない。
1. 「要因」とは「特性に影響する条件」を意味し、適切に管理すればトラブルの原因にならないが、管理が不適切だと原因になる。従って、トラブルの予防の目的で管理すべき要因を挙げて管理しなければならない。
2. 「疑わしい要因」とは「そのトラブルの原因になっているのではないか」と疑われる事象である。トラブルの原因かどうか検証する目的、あるいは、トラブルを解消する目的で「疑わしい要因」を挙げて対策を講じる。
3. 「原因」とは、事象Aが起きなかったら事象Bも起きなかった関係(因果関係)における事象Aをいう。事象A,B共に、現に発生した事象に限られる。
殺人事件に例えれば、こうなる。
用語 | 意味 |
---|---|
要因 | その殺人を犯すことができた人々 |
疑わしい要因 | その殺人を犯したと疑われた人 |
原因 | その殺人を犯したと立証された人 |
そこで、特性要因図に列挙すべきものは、要因か、疑わしい要因か、の問題となる。
1. 疑わしい要因に思い当たらない場合:
何が原因なのか全く見当もつかない場合は、疑わしくない要因も含めて、全ての要因を列挙した上で、そこから実験等によって、→ 原因候補 → 原因と絞り込むことになる。
この特性要因図は、膨大な数の要因を列挙することになり、大掛かりな実験を要する。石川先生が最初に作られた特性要因図はこの種のものと思われ、小集団活動には適切でない。
2. 疑わしい要因に思い当たる場合:
「これが原因ではないか?」と、日常の経験で疑っている要因=疑わしい要因がいくつかあり、それらを特性要因図に列挙して、実験や層別によって原因を絞る場合である。
小集団活動で作成すべきは、このタイプ。
疑わしい要因(1個~3個)を列挙し、最も疑わしい第一候補から順に、対策や層別を行い、効果を見てから次の原因候補に対策を講じるようCAPDサイクルを指導しなければならない。
参照 → 第1問:要因が1個の特性要因図
工程設計に管理用を用い、不良対策に解析用を用いる。 |
特性要因図には、作成目的により、管理用と解析用がある。
項目 | 管理用 | 解析用 |
---|---|---|
目的 | 予防目的 | 是正目的 |
作成の機会 | 工程設計時 | 不具合発生時 |
列挙する要因 | 全ての要因 | 原因と疑われる要因 |
要因の数 | 多数 | 少数 |
工程設計書や手順書は、何の目的で作るか?
何の目的で工程設計書、手順書、作業標準を作るかって? そりゃ、おめぇ、手順を示すためだっぺ。手順を書いた書面がなくっちゃ、何やったらいいんだか、分かんねぇもんな。ガハハハ。
実は、そうではない。
工程設計は、品質・納期・コスト等のトラブルを予防するために行う。従って、予め「どの特性にはどのような要因があり、どう管理すべきか」を想定して対策を設計しなければならない。
そのため、工程のステップごとに知識・経験などから管理すべき特性の要因を列挙した「管理用・特性要因図」が必要になる。この場合に列挙するのは、要因(寸法などの特性に影響する条件)であり、全てのトラブルの全ての要因を列挙する。故に、管理用は要因の数が一般に多くなる。
ただし、要因が1~2個しかなく、しかも明白な場合に、敢えて特性要因図を作成する必要はない。
要因の数が多く、対策案を記載するときは、表形式が便利である(→ 表形式)。
解析用の詳細を説明する。
不良や高原価など、特性値が改善したい状況にある場合に、原因を特定する目的で作成する。
列挙するのは、日常業務の中で「原因ではないか」と疑っている事象(=疑わしい要因)のみである。これには、次のやり方がある。
下の図のように、疑わしい要因が「研磨条件」である場合に、それに属する一式の要因の最善の水準の組合せの究明、あるいは不良の再現実験を直交配列表を用いて行うのに適する。
石川馨先生が最初に作成した実験計画タイプの場合は、疑わしい要因がないケースだから、上の図よりも多く、漏れなく網羅的に要因を列挙した特性要因図を作って大掛かりな実験をすることになり、QCサークルには不向きである。
QCサークルがカンに頼って挙げた疑わしい要因を一通り検証しても(対策を講じてみても)原因が分からないときは、通常、手あたり次第に層別を繰り返すしかない。
すなわち、1号機と2号機で差はないか、A社の材料とB社の材料で差はないか~という具合に層別を繰り返して、差が顕著に表れたものを疑わしい要因として対策を講じてみる。
下の図のように、日常業務の現場の経験やデータから最も疑わしい要因を一つ挙げて対策を講じ、それで不十分なら次に二つ目を挙げて対策~という具合に、CAPDサイクルを回して逐次増やしていく場合に適する。
〔注〕上の図で「組立ジグの使用」を要因として挙げた意味は、「人の熟練作業に頼っている」現状をジグを使用することによってバラツキを減らそうという意味で、「要因と手段」を同意に表そうとしたもの。
最も普通のやり方は、日常の経験から最も疑わしい要因を1個挙げて、層別 or 対策を行い、それで不足なら2番目に疑わしい要因を挙げて同様に処理するというCAPDサイクルを繰り返すことである。
例えば、ある寸法特性の不良率について、作業のバラツキAが「疑わしい要因」であるとする。そこで、製品1000個当たりの不良個数を、水準A1、A2に層別してみた(1図参照)。
上の図から、ジグの使用が有効と予測され、実施してみると次の結果となった(2図参照)。
日によるバラツキを大きく超えた変化が認められるので、ジグの使用は効果があると確認でき、従って原因が確認できた。しかし、まだ不十分であり、他にも原因があることが明らかになった。そこで、第二の「疑わしい要因」を挙げることになる。
従来のQCサークル指導が誤っていることは、体裁のために当てずっぽうに多数列挙する事例発表をみれば分かることである。
特性要因図を作って、「ある要因が特性(寸法など)に影響する」ことを検証しただけでは、要因であることが検証されただけで、特性不良(寸法不良)の原因が分かったことにはならない。つまり、要因分析をしても、要因が判明するだけであって、原因は解明できない。
「原因が分かった」というためには、通常、次のどれかに該当しなければならない(原因解析)。
その原因候補を強弱すれば、トラブルが増減すること(影響力の検証)。
その原因候補に対策を講じればトラブルが解消し(改善効果)、対策を除去すればトラブルが再現すること(再現実験)。
実務では、次のような手順を踏むのが普通である。
失敗が許されない大改善では、多数の要因について直交配列表による再現実験で原因を確定してから対策を考案して一発勝負で解決する(原因確定型)。
失敗が許されるQCサークル活動のような小改善では、少数の疑わしい要因に対策を打つ試行錯誤(CAPDサイクル)を手段がつきるまで繰り返えす(対策先行型)。
改善活動において、「トラブルの原因」、又は、「原因でないことが判明した要因」を工程設計部門に報告するときに作成する特性要因図である。
(例)QCサークルが改善の結果を工程設計部署に報告する場合に作成する。
直交配列表を使って多数の要因について影響力を検証し再現実験をする場合には、特性要因図に考え得る多数の要因を列挙する必要が生じる場合がある。
しかし、QCサークル(小集団)の活動では、要因を多数列挙してはならない(原因ではないかと疑っている要因のみを挙げればよい)。
この点を誤って指導されることが多く、まずこの点を確認すること。
→ 第6章:第1問
石川馨先生がQCサークルを提案された当時から特性要因図の指導に誤りがあったと思われる。それが今日まで尾を引いて、古典的な理論の温床になっている。以下、一般の指導例を吟味しよう。
軽部文雄氏(FK-Plaza)から引用する。
1. 特性要因図とは、特性(現象など。課題として取り上げる対象を云う)と、それに影響を及ぼすと思われる要因(特性に影響を与える、もしくは原因となりえること)との関係を系統的に網羅して魚の骨のような図にまとめたものである。
2. 作成では始めに分類的なレベルの要因を記入して行き、段々と具体的な要因を記入してゆきます。このことで具体的な要因が見えてくるので、次段階の「原因の究明」や「対策の立案」策定に繋げることが出来ることになります。
3. 作り上げた特性要因図から重要と思われる要因をマークして、原因追究のテーマに設定してゆきます。小集団では、要因の解析の段階で使用されます。
要約すると、こうなる。
誤っている点を指摘する。
1.「重要と思われる要因」ではなく「疑わしい要因」に着目すべきである。「重要と思われる要因」は、通常、よく管理されて原因になる可能性は少ない。
2.「疑わしい要因」は、特性要因図を作成してから思いつくのではなく、普段の業務の中で経験やデータから思いつくものである。
3.「特性に影響を与えるものを網羅する」という必要はない。最初から「疑わしい要因」のみを挙げればよい。
特性要因図を「対策検討型」と「原因追求型」に分けて、下のように説明している。内容の乏しい記事で占められる一般のサイトに比較すれば、このサイトは真面(まとも)である。しかし、若干の問題がある。
1. 未発生の特性を予防的に管理・検討するような場合は、関係者の経験や知識、またはブレーン・ストーミングなどによって管理すべき要因を網羅的に列挙・整理する(対策検討型)。
2. 一方、すでに発生した結果から原因を探るときは、全ての要因を列挙するのではなく、影響の強いものに絞って、問題と主要因の因果関係を明確にする(原因追及型)。
間違いを指摘する。
第5C図の特性要因図が、原因追求型として掲載されている。
「品質変動が大きい」というような問題点を特性とし、思いつくままに要因を挙げ、さらに「なぜ○○○なのか、×××だから」を繰り返す。
例えば、「なぜ体調が悪いのか、睡眠不足だから。なぜ睡眠不足なのか、夜更かしするから。」と言う具合に。そして、重要な要因をまるで囲う。
〔第5C図〕
これは、全くの間違いである。問題点を指摘しよう。
1. 特性が「特定の結果」に該当しない(JISの定義)。
「品質変動が大きい」というような漠然とした特性はあり得ない。
特性が特定しないと、要因も特定しないし、対策を講じても効果を確認できない。
2. 経験や現場データを無視して「思いつくまま」に要因を多数列挙しており、原因が見つかることは千に1つもないと知るべきである。
この特性要因図を見ると、「品質変動が大きい」原因のうち、作業者に関して、態度が悪い、作業ミスが多い、技能が低い、問題意識が低い、体調が悪い、のどれかが原因だと言っている。これらの因果関係をデータで検証するのは困難である。
これは「作ってはならない特性要因図」の代表的な事例である。
前述の新潟大学の講義で、特性要因図の要因の列挙の仕方について説明している。特に注意をひく点は、「問題点を思いつくままに挙げ、後で整理・採用する」という最初のステップである。
作成のポイント
- 問題点を思いつくままに挙げ、後で整理・採用する。
- 現場、現物,実際の現象を直視する。
- 最終的にはデータの取れる要因や、具体的に取れる対策を挙げる。
- うまく書くことを目的としない。
- (現実には)複数人で検討し、何度も書き直す。
複数人で思いつくままに問題点を挙げ、データをとって、対策を考えて、何度も書き直して~それで、なぜ原因が判明するのか全く理解できない。
下に示す羽根田 修氏のサイトで、特性要因図を古典的な姿で説明している。
特性とは結果のことです。要因とは重要な原因のことです。特性要因図とは、重要な原因の候補をリストアップし、図で整理したものです。
特性要因図は、あくまで仮説ですから本当の原因をデータで確認するための準備として使うツールになります。
解決しようとする要因は数多くあるのが普通ですから、系統的に図示しておくと問題解決にとても便利です。また、目的と手段の混同を防止するためにも有効です。
「要因とは重要な原因のこと」と国語辞典に書いてある。専門用語を国語辞典で学んだようで、素人丸出しである。原因を知る前に「重要な原因」を列挙できるはずがない。
「解決しようとする要因は数多くあるのが普通」ということはない。
普段の仕事を通じて疑っている要因は、せいぜい1~3個である。列挙する要因が多いのは、ヘボ刑事の場合に取り調べる容疑者が多く、犯人に辿り着く可能性が低いのと同様である。
「要因を系統的に図示すれば目的と手段の混同を防止するのに有効」とは、意味不明である。
説明を補充する。
殺人事件が起きたとき、できるだけ多くの容疑者をリストアップするのではない。容疑者が出来るだけ少なくなるように初動捜査によって手掛を探す。容疑者が多いのは捜査が下手だということである。
同氏が原因追求型と称するのが、下の特性要因図である(文字が小さくて読めなくても、やたらと多数の要因が列挙されていると分かればよい)。
初動捜査がずさんでデータがないから多数の容疑者が生まれ、犯人の候補を選べず、恐らく迷宮入りか冤罪になると推測できる。
上の特性要因図のさらなる決定的な欠陥を指摘する。
1.
特性は物流部の仕事の時間
という漠然としたもので特定しない。従って、時間を測定できず、特性とは言えない。
2. 要因を思いつくままに多数列挙しているため「疑わしい要因」が不明で、検証の対象が定まらない。
実務で特性要因図を作る場合に役立つ、いくつかの参考点を挙げてみよう。
「特性」に、原因が異なる特性を混ぜてはならず、層別されていなければならない。例えば、「すりキズ」と「打痕」のデータを混ぜて「キズ不良」としてはならない。
〔理由〕「すりキズ」と「打痕」では原因が異なるから同じと癖要因図に含めることはできない。
JIS の定義で「特定の結果」とは、この層別された結果を指す。→ JISの定義
「人がポカで温度設定を誤って不良を作る」というシナリオを特性要因図にどのように表わすか? 「ポカ」によって「何をする、しない」の問題だから、その行為を該当箇所に記載すればよい(第5-5図)。
すなわち、「ポカミス」が機械の段取りの間違いを意味するなら「機械」に属し、製品検査の漏れを意味するなら「測定」に属し、作業のミスなら「方法」に属する。
CAPDサイクルの有益性を示す筆者自身の体験事例である。
CAPDサイクルで失敗を繰り返すと、データが蓄積し、原因の所在範囲が狭まって解決の道が開ける。
パソコンとプリンターで年賀葉書を印刷した。 手差しトレイに載せた数十枚の葉書の宛先印刷が終わり、裏返して「謹賀新年」の面の印刷に取り掛かった。 間もなく「葉書がプリンターの中で止まり、トナーが固着せず、触ると滲む」というトラブルが頻発した。 紙が詰まるトラブルは従来も時折あったが、今回は頻繁で、しかも葉書は業者に依頼して作った特製品だから、枚数が足りなくなってしまう。 |
そこで、思いつくアイデアを片っ端から試した。
(1)トナーカートリッジを疑って、新品と交換 → 頻度は少し減ったが、解決しない。
(2)プリンターが故障したかもと疑って、予備の新品プリンターを使う → 全く変わらない。
(3)ふと気づいたが、葉書がいやに反っている。熱変形を疑った。
宛先印刷して生じた葉書の反りを手で逆反りに変形させて印刷してみた。→ 成功。
分かってみれば「成る程」だが、先に宛先を印刷して生じた反りがプリンターにとって「支障のある反り」だったのである。この「葉書に反りが生じている」というデータ(現場情報)を「疑わしい要因」だと気付く注意力と経験が問題解決の鍵となることが分かる。
七転び八起で性懲りもなくCAPDサイクルを続けると、原因の範囲が狭まってきて成功することがあるのは確かである。ノーベル賞学者の研究の多くは、このような方法で成功している。