製造業における人的要因 – パート1
ヒューマンエラーはどうして起こるのか。ヒューマンエラーはどうしたら防げるのか。
2回シリーズでお届けする『製造業における人的要因』のパート1では、どのようにヒューマンエラーを洗い出すかを解説します。
quality.org掲載の英文記事はこちらから
- 目次
- はじめに
- ヒューマンエラーは人的要因により引き起こされる
- タイプ別ヒューマンエラー関連の状況
- 人的要因根本原因を突き止めるためには
- 方向性をもったブレインストーミングを行うことで探究に方向性をもたせる
- チームのブレインストーミングセッション
- 人的要因根本原因を検証する
- 事象/ハザードの根本原因に対応する
はじめに
「結局、これはヒューマンエラーだ (だから対応のしようがない)」という言い訳を、だれしも聞いたことがあると思います。しかし、例えばだれかが何かを間違って行ったなど、不適合が「ヒューマンエラー」に帰結するとされる場合も、実はその陰には根本原因があるのです。
ヒューマンエラーが起こる可能性のある状況にはたくさんの要因が潜んでいますが、前駆的状況、つまり前提条件を「人的要因 (human factors)」と呼びます。
人的要因の研究 (ヒューマンファクター学) で対象となるのは、作業環境における人々であり、人々と機器や手順との関係性です。同様に、他の人々、例えば同僚や上司との関係性も重要です。この研究の目的は、安全性、効率性と有効性の向上です。ヒューマンファクター学は「優秀なはずの人々がなぜ時として、危険な、あるいはバカなことをしてしまうのか」という問いに答えるためのものです。
ヒューマンエラーは人的要因により引き起こされる
最初に人的要因について考え始めたのは、航空保守、修理及びオーバーホール (MRO = maintenance, repair and overhaul) の分野ですが、その後、他の多くの製造業やサービスセクターでも適用されるようになりました。
組立工が個人的な悩みで頭がいっぱいで、自分の業務を適切に果たさなければ、その製品を使用する人々の命を危険にさらすことになるかもしれません。
メンテナンス技術者が要求事項に定められた責務を果たさなければ、人命を奪う可能性のある事故が引き起こされるかもしれません。実際に、航空史上、もっとも恐ろしい事故のいくつかは人的要因によって引き起こされたのです。
ヒューマンエラーと戦うためには体系的なアプローチが必要です。そもそも発生を防ぐことが第一であり、起こってしまった場合には重大な影響を軽減し、決して再発させないよう対策を立てます。
タイプ別ヒューマンエラー関連の状況
ハザード (危険源) とは、発生するかもしれない出来事、あるいは安全でない状態であり、そのまま報告されず、対応もされずにいれば、ヒューマンエラー、ニアミスや不適合の可能性及び/または安全上の懸念につながるものです。
何が起こり得るか – 事前的
事象 (event) とは発生してしまった出来事を指しますが、これは顧客からの苦情、是正処置要求、重大な品質問題、安全警報、監査での不適合及び事故など、さまざまなプロセスから知ることができます。
何が起こったか – 事後的
ヒューマンエラーの根本原因である人的要因を理解することによって職場内のヒューマンエラーが減れば、製造に起因する重大なインシデント/事故の可能性はそれに比例して減り、クオリティの低さのために生じる無駄なコスト (COPQ = cost of poor quality) を減らすことができるでしょう。
人的要因根本原因を突き止めるためには
まず、考慮すべき事象/ハザードについて明確で簡潔な記述をすることからプロセスを開始します。特定したヒューマンエラーの本当の根本原因を探るには、以下を問うことから始めます。
- 作業者が行うべきなのに、行わなかったことは何か?
- 作業者が行うべきではないのに、行ってしまったことは何か?
さらに以下を繰り返し、問い続けます。
- なぜ作業者はそれを行わなかったのか?
- なぜ作業者はそれを行ったのか?
お気付きのとおり、「5回のなぜ (なぜなぜ分析)」ツールです。事象/ハザード (すなわち、問題) から根本原因 (つまり、人的要因) にまで遡るためのものです。しかし、もっとよい方法があります。
方向性をもったブレインストーミングを行うことで探究に方向性をもたせる
コンセプトは、だれかが間違ったことをしたために起こった事象/ハザードがあるとしたら、なぜそう行動したのか、理由があるはずだということです。ヒューマンエラーが起こる可能性のある状況が発生する要因はたくさんあり、300以上の人的要因を挙げているリストもあります。
石川ダイアグラム (特性要因図) は根本原因を特定するときに事象やハザードの予想される原因を分類するためのすばらしい視覚化ツールです。クオリティチームが、あり得る根本原因についてさまざまな視点からブレインストーミングする際のヒントを提供します。各視点は、ダイアグラムの「中骨」 (それゆえ、この図はフィッシュボーン・ダイアグラムとも呼ばれます) あるいは「スポーク」として特定します。
異なる視点から人的要因を探るためにさまざまなモデルが開発されています。もっともポピュラーなのは以下のモデルでしょう:
- 人的要因を特性でわけるPEAR (People 人々、Environment 環境、Actions 活動、Resources資源) モデル (主に航空機産業で使用されている)
- IAQG (International Aerospace Quality Group) の人的要因の根本原因分析
- SCMH (Supply Chain Management Handbook – IAQGの開発したガイダンス文書) 根本原因カテゴリー – 製造に特化
- ダーテイ・ダズン (dirty dozen：エラーを誘起する12の要因) – メンテナンスに特化
- 作業環境に注目したSHELL (Software ソフトウェア、Hardware ハードウェア、Environment 環境,、Liveware 当事者、Liveware 当事者以外) モデル
- 蝶ネクタイ (bow-tie) モデル
これらモデルの1つ以上を使用することにより、チームが検討しなければならないさまざまな視点を石川ダイアグラムの「中骨/スポーク」に表すことができるようになります。「IAQG の人的要因の根本原因分析」に基づく例を図1に示します。
図 1
IAQFの人的要因の根本原因分析に基づいて
フォーマットした石川ダイアグラムの例
チームのブレインストーミングセッション
チームは、フォーマットした石川ダイアグラムから最初に注目しなければならないポイントを探ります。チームのファシリテーターはまず「中骨/スポーク」のうちの1つを選び、「なぜ?」と問いかけます。これが「なぜの階層」の最初の階層となります。ファシリテーターは続いて、チームに以下を問いかけ、探索を続けます。
- この (直接の) 原因に対応すれば、事象/ハザードを防ぐことができるか?
- できないすると、次のレベルの原因はわかるか?
- わからないとすると、次のレベルの原因として疑わしいものは何か?
- どうしたら、次のレベルの原因をチェックし、確認することができるか?
- このレベルの原因に対応すれば、事象/ハザードの発生を防ぐことができるか?
これでも特定できない場合、ファシリテーターは人的要因の原因が決定するまで、「なぜ」を問いかけ続けます。1つが決定すれば、残りの「中骨/スポーク」に注意を向けて検討します。
複雑な問題の人的要因に関連する「根本原因」を追究するときは、単純な5つのなぜ (なぜなぜ分析) では十分ではないかもしれません。問題は、1つの事象/ハザードが複数の原因や、複数の原因の組み合わせにより起こる可能性もあるということです。縦に掘り下げていく5つのなぜ (なぜなぜ分析) だけでうまく機能するのは、チームによって洗い出されたそれぞれの事象にたった1つの原因しかない場合のみです。
事象とすべての原因間の論理的なつながりは、Whyツリー (あるテーマをツリー状に展開するロジックツリーの1形態) によって明らかにできます。Why ツリーを使えば、発生している事象/ハザードに先立って起こっていたすべての問題をもっとよく検知できる可能性があります。Whyツリーをガイドとして使用せずに、単に「なぜ」と問い続けるだけでは、チームは本当の根本原因全部にたどり着くことはできないかもしれません。
図 2
単純な (垂直) 5つのなぜと「Why ツリー」の比較
Whyツリーでも、ファシリテーターはチームの各視点に焦点を当てますが、第1階層の「なぜ」 (この図では4つ) に代替の答えを提示することができます。すべての第1階層の原因が特定できたら、チームは、人的要因の根本原因を決定するまで、異なる「論理パス」をたどるように指示されます。
ブール論理を用いて、さらに強化することもできます。例えば、チームは異なる「論理パス」のどれかが当てはまると考えるかもしれません – これは「ORゲート」に相当します。同様に、2つ以上の「なぜの質問」を同時に発する必要がある「ANDゲート」が識別されることもあるでしょう。
「作業者が行うべきだったのに、行わなかったことは何か」に焦点を当てる場合は、「スイスチーズ」モデルと呼ばれる「ANDゲート」が有効かもしれません。
人的要因根本原因を検証する
石川ダイアグラムとWhyツリーの方法論を組み合わせて用いれば、複数の根本原因を明らかにすることができるかもしれません、いえ、できる可能性は大いにあるでしょう。これらの原因のそれぞれのうち、もっとも可能性の高いものを導き出すために、チームはそれぞれの原因を精査する必要があります。
「それ故に」テスト
本記事の著者の所属するTEC Transnationalで行っているのは、「それ故にテスト therefore test」を使用して、チームの5つのなぜの作業をチェックする手法です。「それ故にテスト」の目的は、一連の状況のもっとも早いポイントから、事象/ハザードにいたるまでの「因果連鎖」の論理の流れをファシリテーターがチェックすることです。因果連鎖がすべて完了したら、もっとも深いところから、図3に示すように、各記述の間を「それ故に」という言葉で結んで、順番に読んでいきます。
図 3
5つのなぜの「論理の流れ」を逆の順番にたどり、各段階の間に「それ故に」という言葉を足してテストします。逆にして論理パスの意味が通るなら、その論理はおそらく信頼できるでしょう。
チームリーダーは、選ばれた根本原因の記述を声に出して読み上げ、「それ故に」と続けます。するとチームは、逆の順での「論理の流れ」をテストするために根本原因の直前の原因を考えます。このプロセスを5つのなぜの因果連鎖の最後 (すなわち、Whyツリーの第1階層) にたどり着くまで続けます。
このプロセスのどの時点であっても、チームが「それ故に」という言葉を挿入できず、分析の意味が通らないところがあれば、論理に飛躍があるということになります。飛躍があれば、チームはその他の事実でこの飛躍を埋める必要があるでしょう。
「is」と「is not」
根本原因検証のためのその他の方法には、事象/ハザードの最初の記述に戻り、チームは以下の質問を問いかけるというものがあります。
- 何がそうか: 何が間違っているか? (例えば、事象/ハザード)
- 何がそうでないか: 論理的には間違っている可能性があるが、間違っていないのは何か?
これらの体系的な質問では、以下のものに注目することもできるでしょう。
- どの部分が (関わっているか)?
- (その部分の) どこが?
- (物理的な場所/部署) のどこが?
- いつ (問題が発覚したか)?
- いくつの (部分が影響を受けたか)?
- (作業者/監督者は) だれか?
答えがわからない場合、チームがもっと情報を求めることはよくあります。チームは、可能性のあるすべての根本原因 (人的要因) をテストして、意味の通らない原因は消去し、場合によってはそれぞれ「可能性があるか」を百分率で表すこともあります。ファシリテーターは、チームに下の空欄を埋めるよう促します。
「もし ___________________ が ___________________ の根本原因であるなら」
では、どうしたら前提をチェックすることができるでしょうか?
事象/ハザードの根本原因に対応する
人的要因の点からの根本原因 (すなわち、なぜ作業者が何かを間違って行ったか) を決定したら、(可能であれば) 原因を予防するための「管理策」、または原因の発生を検知し、もたらされる結果を軽減するための「管理策」を立てることに注意を向ける方向を切り替える必要があります。
懸念のあるプロセスに通暁した部門横断型のチームは、決定した根本原因を予防、または検知する「管理策」を調査する必要があります。選択肢があることが多く、チームはまずこれらの「管理策」は効果があるか、望ましくない副作用がないか、及び/またはさらなる問題/事象を引き起こすことがないかを検証しなければなりません。コストの影響についても検討する必要があります。
選んだ管理策を展開し、以下について確認します。
- 再発生しない、または
- 発生したときには検知し、リリースしない
その他のツールにも、このプロセスに有用なものがあります。
故障モード影響解析
故障モード影響解析 (FMEA = Failure modes and effects analysis) は、製品/サービス設計において起こり得る不具合 (DFMEA) または製造プロセスにおいて起こり得る不具合 (PFMEA) を特定するための段階的なアプローチでです (図4を参照のこと)。
図 4
FMEA の図解
故障モードという用語は、何かが故障/失敗 (fail) する可能性のある方法 (way)、モード (mode) を意味します。故障 (failures) とは、特に顧客や下流のオペレーションに影響を与えるエラーや欠陥のことであり、潜在的な (ハザード)、または現実の (事象) となり得るものです。
「影響解析」という用語は、これらの故障/失敗 (failures) の結果を検討することであり、その重大度 (重大ではない ～ 壊滅的) を決定します。
蝶ネクタイモデル
蝶ネクタイモデルは、主に航空安全マネジャーが使用するためのものですが、製造のオペレーションに適用することもできます。もともとは別々であったリスク哲学とツールを、適用するために1つの目的にまとめています。
図 5
蝶ネクタイモデル
蝶ネクタイモデルを使用すると、これらのすべての要素がどちらか一方に表示され、蝶ネクタイに似た1つの簡潔な図に視覚化されます。蝶ネクタイモデルは、以下の4つの要素に依存します。
- 引き金となる根本原因 (人的要因)
- 以下に結びつく事象/ハザード
- 製造のオペレーション (すなわち、下流もしくは顧客) への影響
- 事象/ ハザードとその影響に関連するリスク「管理策」 (バリア)
蝶ネクタイモデルの第1の目的は、以下を含む安全事象の流れを示すことです。
- 問題を起こす原因 (脅威) (すなわち、Whyツリー)
事象/ハザードの上流 (すなわち、事象/ハザードの重要地点) に通じる事象 - 事象/ハザードが上から下へ、次々と引き起こされ、下流での組織または製品への悪影響につながる
- 一連の事象における、それぞれのリスク管理策 (FMEAの「検知」と同等) の失敗/成功
パート2では、組織内でどのようにヒューマンエラーに対応したらよいかを見ていきます。
著者について: デイビッド・スクリムシャー (Dr David Scrimshire) は、TEC Transnational Ltd の代表取締役です。TEC Transnational Ltdは製造システムと品質システムの実施、及びそれらのシステムを運用する要員のトレーニングを専門とする企業です。
