お役立ちウェブセミナー 第9回

桜の便りが届き始めましたね。
春は新旧入れ替わりの時期。なんとなく仕切り直しなどもしたくなります。
そこで、今回で運輸安全マネージメントについてのウェブゼミを締めくくろうとハイピッチでお送りしますね。

前回は、
2種類の教育・研修について説明しました。
今回からは、事故削減に役立つ情報活用(事故・災害に関する報告)について説明していきます。

「安全マネジメント」では、
“マネジメントシステム”
“プロセス管理”と並んで、
非常に重要なのが、この、
“事故削減に役立つ情報活用”(いわゆる事故削減・撲滅の”切り札” )なのです。

この3点を上手く活用できないと、事故の削減・撲滅は難しいでしょうし、
この3点に精通していないと
「運輸安全マネジメント」のなかでも
「安全マネジメント」の指導は困難でしょう。

では、この、”事故削減に役立つ情報活用”とは、どのようなことでしょうか?

運輸安全マネジメントのベースであるISO9001を運用されている読者の方には、
「”事故削減に役立つ情報活用”とは、ISO9001の”8.5.2是正処置”、”8.5.3予防処置”、”8.4データ分析”が該当しますよ」と言えば、ご理解いただけると思います。

また、ISO14001、OHSAS18001、ISO22000、ISO27001にもまさに「ドンピシャ!」の項目がありますが、ISOは、さておき、
“事故削減に役立つ情報活用”の説明ですが、
まず、”事故削減に役立つ情報”とは、どのような情報なのか?
ですよね。
カンタンに説明しますと、
「ヒヤリハット情報」
「他社や自社の事故情報」です。
専門用語でいいますと「インシデント情報」と「アクシデント情報」と言うのだそうです。
この、ヒヤリハットである「インシデント」や事故である「アクシデント」が発生した場合に事故の予防や再発防止に役立てるという、いわゆる”受け身”の活動も効果はあるのでしょうが、冒頭で説明した、”マネジメントシステム””プロセス管理”と並んで、非常に重要なのが、この、”事故削減に役立つ情報活用”です。

“事故削減に役立つ情報活用”というのは、”受け身”の活動だけでは効果が薄く、
自ら”重箱の隅をつつく”ような積極的な活動が望まれます。

え~?うーん・・・!!
“重箱の隅をつつく、、、”??? とは、どのような取り組みなのでしょうか?
これは、
ズバリ!「ヒューマンエラー対策」です。
もう少し、突っ込んだ説明ですと、「リスク管理」と「ヒューマンエラー対策」です。

ところで、余談ですが、みなさんは、「運輸安全マネジメント」が導入された経緯はご存知ですか?

国土交通省において、「公共交通に係るヒューマンエラー事故防止対策委員会」が実施され、その中で「運輸安全マネジメント」の実施が提唱されました。
検討委員会の名称として”公共交通”という文言が使われていますが、特に”公共交通”に限定したものではありません。
この検討委員会の結論として自動車交通モードの具体的な対策の2つのうちの1つが「安全マネジメント」の導入なのです。
また、検討委員会の中で中小事業者の「安全マネジメント」への取組みについても触れられています。
要するに、ヒューマンエラーに起因する事故防止のために「運輸安全マネジメント」を活用していくことになったのです。

また、「ヒューマンエラー対策」に取組むうえで「リスク管理」は見逃すことができません。

事故削減・撲滅の”切り札”である「リスク管理」と「ヒューマンエラー対策」について詳しく、なるべく判り易く説明していきますね。
この2つについて、どちらを先に説明すべきか・・
通常であれば、「リスク管理」を先に説明すべきですが「ヒューマンエラー対策」を先に説明しますね。

ただその前に、ごく簡単に「リスク管理」の一部である、「リスクアセスメント」を説明したいと思います。
「リスクアセスメント」を日本語に直訳しますと「危険分析」や「危険評価」ですね。
要するに皆さんの会社が処理している業務の「危険分析」を行う事です。
この「危険分析=リスクアセスメント」の実施方法は1種類だけではないですが、私がお勧めしている方法として会社が処理している業務を一つ一つのプロセスに小分けして、その小分けしたプロセスについて”発生の頻度”と”発生した場合の影響度”をもとに評価します。
そして、その評価結果をもとに対策を検討していくのです。

では、「ヒューマンエラー」について説明していきましょう。
“ヒューマンエラー”??
これも直訳すると”人間の失敗”でしょうか。
ヒューマンエラー関係の学者さんたちは

           故意
      人災――
災害―――      過失=ヒューマンエラー 
      天災

と、分類する方が多いようですが、
ここでは、人災のうち”故意”も”過失”もヒューマンエラーとして位置付けましょう。
ただ、ここで”天災”を省くことが適切であるのか?
また、ヒューマンエラーの要因として”天災”も考えられることから、前述の分類は参考程度にとどめておきましょう。
でも、ここまで読まれて、ヒューマンエラーとはどのようなものなのか、依然としてよくわからない読者が多いのでは?
では、このように定義してみましょう。

「ヒューマンエラーとは、故意や過失を問わないし、天災も省くものではない」

うーん・・余計わからなくなりました?
では、国交省でよく使用されている定義で行きましょうか?

ヒューマンエラーとは
1 意図した不安全行動
2 意図しない不安全行動

“1 意図した不安全行動”とは、自分でもわかってはいるけど、ついやってしまう不安全な行いですよね。
具体的には、信号が黄色から赤に変わったけどそのまま直進 とか、製造機械の安全装置を取り外したまま使用する などです。

“2 意図しない不安全行動”とは、うっかりミス等ですね。
具体的には、トラック発進時に安全確認を怠った とか、ハッチを閉め忘れた ですが揚げられます。

この御理解していただけたましたか?
この「ヒューマンエラー対策」は、いろいろ使い道が多いのです。
運輸業界の交通事故だけではなく、「伝票の入力ミス」だとか「階段からの転倒」・・・・
これらの問題を「ヒューマンエラー対策」で考えていくと、かなり使えるのです!

これら発生原因は、ヒューマンエラーを引き起こした「本人」と様々な要因が絡み合って引き起こします。
では、その「要因」を分類してみましょう。

1「本人」と「機械・設備」の問題
2「本人」と「しくみ、作業指示等」の問題
3「本人」と「環境(作業環境、天候等)」の問題
4「本人」と「周囲の人々」の問題
それと、
5「マネジメント」の問題 もありますね。

それでは、前述の意図した不安全行動のうち、”信号が黄色から赤に変わったけどそのまま直進”の原因を探ってみましょう。

ここで、認識して頂きたいのは、結果としてはいわゆる信号無視ですが、その原因は様々だという事です。

そこで、原因追究パート1として
なぜ、
“信号が黄色から赤に変わったけれどそのまま直進” したのか?

「信号が見え難かった」

なぜ
“信号が見え難かった” のか?

「西日が反射していたから」

なぜ、
“西日が反射して見え難かった” のか?

「季節・時間によっては西日が信号に直撃し、反射しやすい信号で有った」

以上のように、「なぜ」を3回繰り返した結果、信号事態の機械的な問題が原因であることが判りましたね。
と、同時に
“1 意図した不安全行動”ではないことも判明しました。

現在では、信号に改良が加えられ、発行面に庇(ひさし)をつけたり、角度を変えたり、反射しにくい発光ダイオードが使われるようになったり・・・ですね。

この事例は、いわゆる
“1「機械・設備」の問題”と言えるでしょう。

次に原因追究パート2としてなぜ、同じヒューマンエラーである”信号が黄色から赤に変わったけれどそのまま直進” したのか?を別の観点で追及してみましょう。

なぜ、
“信号が黄色から赤に変わったけれどそのまま直進” したのか?

「急いでいたので」

なぜ、
“急いでいた” のか?

「急がないと遅配になるから」

なぜ、
“遅配になる” のか?

「配車計画に無理がある」

仮に、”配車計画に無理がある”ことが原因で有れば、
「無理のない配車計画を立案する」ことが再発防止につながるでしょう。

この事例は、
“2「しくみ」の問題”と言えるでしょう。
(もちろん、他の考え方もありますね)

但し、「なぜ」を3回繰り返したからと言って、真の原因に到達できるかは不明ですし、最初の「なぜ」に対する答えが違っていれば、何回、「なぜ」を繰り返しても真の原因には到達できないでしょう。
(有る有名企業は「なぜ」を5回繰り返すと言われています)

そうしますと、一つのラインで
「なぜ」「なぜ」を行う事にも限界がある場合があります。
これらの手法については別の機会で解説したいと思います。

本日覚えていただきたいのは、
「原因追求の難しさ」と
「原因追求の必要性」です。

この、ヒューマンエラーの原因追求や対策立案の際、重宝する
「SHELモデル」について説明していきます。

「SHELモデル」とは、5つの頭文字です。

L=Liveware(ドライバー本人)を取り囲んだ
S=Software(ソフトウエア)、
H=Hardware(ハードウエア)、
E=Environment(環境)、
L=Liveware(周りの上司、同僚、部下)

イメージ図で示しますと

             E(環境)
   H(ハードウエア) L(本人)  L(同僚等)
             S(ソフトウエア)

と、なります。

では、一つ一つ運送業にたとえて説明しましょう。

L=Liveware(ドライバー本人)は、そのままですね。
S=Software(ソフトウエア)とは、作業指示、手順書、
   運行計画、教育訓練、整備等のソフトにかかわること
H=Hardware(ハードウエア)とは、車両、設備・機械、安全機器
   (デジタコ、ドラレコ、バックアイカメラ等)
E=Environment(環境)、
   天候、時間帯(夜、昼間)、温度、作業環境、車内環境等
L=Liveware(周りの上司、同僚、部下)
   ドライバーに指示する上司、運行管理者。
 部下、同僚、人的要素、組織風土などです。

 また、これら5つの間の関係に「溝」がある場合、
ヒューマンエラーが発生しやすくなります。

例えば、次のような事故の場合・・・

事例1
大雨にもかかわらず、晴れた日のような運転をして、スピードを上げたためスリップ事故を起こした。

事例2
大雨にもかかわらず、上司が、「絶対遅れないように!」とプレッシャーをかけスリップ事故を起こした。

「事例1」の場合は、”L=Liveware(ドライバー本人)” と
“E=Environment(環境)” の関係が
上手く機能していなかった例ですね。
要するに、「ドライバー本人」と「環境」の間に”溝”が出来て発生した事故ですね。

「事例2」の場合は、”L=Liveware(ドライバー本人)” と
“L=Liveware(周りの上司、同僚、部下)” の関係に問題があった例ですね。
これも、「ドライバー本人」と「上司」の間に”溝”が出来て発生した事故です。
そして、厄介なのは、
「SHELの関係や状態は、日々変化する」 ということです。

L:ドライバー本人のドライビングテクニックも変わるし(向上、衰退)、
S:運行計画や作業手順も変わります。
H:また、トラックやバス自体も入れ替えがあるし、性能も変わります。
  安全機器の装着や、性能の変化もあります。
E:天候や時間、作業環境も刻一刻と変化します。
L:周りの人間(上司や運行管理者、経営層)にも変化があります

前述のように、LやS等の単体でも変化しますが、それぞれの関係も変化します。

例えば、「事例1」のような、
ドライバー(L) と 天候(E) の関係は、
変化する典型ですね。

SHEL単体や関係の変化に対することも
ヒューマンエラー対策=事故防止 として重要ですね。
そして、SHEL単体としての原因追求も非常に重要です!
「この事故は、車両部品の金属疲労が原因なのか?、
   それとも、運転ミスと言うドライバーの原因なのか?」
このように、ヒューマンエラーの原因を追及するうえで
SHELは非常に重宝します。

また、更に重要なのは、
「事故発生」→「原因追究」→「再発防止」 です。
その
「再発防止」・・いわゆる対策を立てる際、
SHELで対策を立てればよいのです。

国土交通省で定義されている「ヒューマンエラー」の定義である
1 意図した不安全行動
2 意図しない不安全行動
を再認識しましょう。

“1 意図した不安全行動”とは、
自分でもわかってはいるけどついやってしまう不安全な行い です。
具体的には、信号が黄色から赤に変わったけどそのまま直進 とか、
製造機械の安全装置を取り外したまま使用する 等。

“2 意図しない不安全行動”とは、うっかりミス等です。
具体的には、トラック発進時に安全確認を怠った とか、ハッチを閉め忘れた 等。

これら発生原因は、ヒューマンエラーを引き起こした
「本人」と様々な要因が絡み合って引き起こします。
では、その「要因」を分類してみましょう。

1「本人」と「機械・設備」の問題
2「本人」と「しくみ、作業指示等」の問題
3「本人」と「環境(作業環境、天候等)」の問題
4「本人」と「周囲の人々」の問題
それと、
5「マネジメント」の問題 もありますが、
1「本人」と「機械・設備」の問題
2「本人」と「しくみ、作業指示等」の問題
3「本人」と「環境(作業環境、天候等)」の問題
4「本人」と「周囲の人々」の問題

こそ、SHELモデル と言う事をお気つきですか?
次のように表記すれば、わかりますね。

1「本人:L」と「H:機械・設備」の問題
2「本人:L」と「S:しくみ、作業指示等」の問題
3「本人:L」と「E:環境(作業環境、天候等)」の問題
4「本人:L」と「L:周囲の人々」の問題

「SHELモデル」という文言をはじめて聞く方も多いと思います。

最初は、混乱しがちですが、実は、明快ですね。

説明文章にすると読む気が失せるような配列とくどさになってすいめせん。

では、一つ一つ運送業にたとえて説明しましょう。

L=Liveware(ドライバー本人)は、そのままですね。
S=Software(ソフトウエア)とは、
作業指示、手順書、運行計画、教育訓練、
整備等のソフトにかかわること
H=Hardware(ハードウエア)とは、
     車両、設備・機械、安全機器
(デジタコ、ドラレコ、バックアイカメラ等)
E=Eivironment(環境)、
     天候、時間帯(夜、昼間)、温度、作業環境、車内環境等
L=Liveware(周りの上司、同僚、部下)
     ドライバーに指示する上司、運行管理者。
部下、同僚、人的要素、組織風土
などです。

これら、5つの要因に「溝」が生じた場合に
エラー・・いわゆる、事故 が発生します。

例えば、
中心のL=Liveware(ドライバー本人)と
H=Hardware(ハードウエア)に
「溝」がある場合を想定してみてください。

どのようなものがあると思いますか?
たとえば、、、、

ドライバー本人(L)と
ハードウエア(H)ですから、この際、
ハードウエア=トラック で考えてみましょう。

いろいろな事例が考えられますが、
事故原因になるモノを幾つか列挙しますね。

・2トン車を10年運転していたが、慣れない4トン車を運転して事故発生
・いつもはバックアイカメラ装着車両で運行していたが、
 未装着車両を運行し事故発生
・本日から運転する車両の運転席からの視界が
今までの車両と異なり視界不良で事故発生

などです。
もちろん、ドライバー本人(L)単独や
ハードウエア(H:トラック)単体としても
事故原因になることもあります。

以上が、「SHELモデル」の考え方。
これに、「Management」を追加してみましょう。
要するに「SHEL + Management」です。
通常の「SHELモデル」に
「Management」の考え方をプラスするのです。

但し、場合によっては、
「Management」は、
SHELの中の
「L=Liveware(周りの上司、同僚、部下)」に
含まれていると捉えることもできますが、
今回は、敢えて、別枠で考えてみましょう。

「SHEL + Management」で重要なのは
一つ一つのSHELを取りまとめたり、
「溝」を無くすためには、
「Management」が不可欠と言う考え方です。

「Managemento=管理」を適切にすることにより
各SHELの不協を無くし、
エラー=事故 を防ぐというものです。
次に、「SEELモデル」と同様の「4M(5M)」について説明しましょう。
これは、

Man(ドライバー本人)、
Machine(車両、機械・設備、安全機器等)、
Media(環境の要素:天候、作業環境)
Management(管理体制、制度)
及び
Mission(作業目的、達成手段)

のことです。
ヒューマンエラーが起こる原因は、
必ず、この4M(5M)にあるという考えに立っています。
よくよく見てみると、
「SHELモデル」に共通するものがありますね。
それにしても、文章で説明するのは厄介ですね。
頭の中ゴチャゴチャ?
基本的な教育指導方法の組み立て方はここまでにして

次回4月からはテーマを新たにお役立ちウェブゼミを
展開していきます。
本日まで読んで頂いた皆さま。本当にありがとうございました!