R先生との対話(つづき) - トラブルの根本原因をつかむ

トラブル事例からのLessons & Learnsを蓄積しようとしても、技術系ナレッジは多く集まるがマネジメント系の知見が出てきにくいのはなぜか--私の質問に対して、R先生は話を続ける。

「トラブル事象が起きた。そこから何かの教訓を学ぼうとする。これ自体は健全なことだ。誰でも、どんな組織でも失敗は経験する。組織に知性があるとすれば、それは自分の経験から学ぼうとする態度だからな。ところが、君はここで勘違いをしている。たとえば、何か例を挙げて説明しようか。最近のよく知られた問題事象を挙げてみたまえ。」

--そうですね、たとえばメキシコ湾で発生した油田の事故はどうでしょう。日本ではあまり報道されていないようですが、深海から原油を掘り出す海上基地(リグ)が爆発して沈没、原油が流出している事故です。4月20日に事故が起きて以来、2週間ですでに100万リッター近い原油が海底から漏出したと言われています。リグはルイジアナの100Km沖合ですが、海表面を油膜が拡がって、すでに沿岸に漂着被害が及んでいるようで、おそらく過去で最もひどい原油流出事故になるでしょう。

「なるほど。原因や対策は分かっているのかな。持ち主は誰だね?」

--Deepsea Horizonというのが石油掘削基地の名前ですが、油井の所有者は英国のブリティッシュ・ペトロリアム(BP)です。この移動式基地は米国企業が設計して、韓国の造船所で製造されたらしいですね。元の爆発炎上の原因はまだよく分かっていません。BPは、何でも、水深1,500mの海底の原油漏出箇所をふさぐために、100トンの重さの『』を上からかぶせる工事をするつもりのようです。しかし、たとえうまくいったとしても、環境被害も経済的損失も甚大でしょう。

「そう。そこでだ。君ならこの事故のLessons & Learnsはどう書くね?」

--え。だって、まだ問題解決の途中でしょう。今は書けませんよ。何か解決法を書くとしたら、漏出防止用の『箱』を、常時一つは会社で用意しておけ、ということぐらいでしょうか。BPは手元になかったので、あわてて作らせたようですが・・・。

「君はそれが解決法だと考えるのか。それは解決じゃない、『応急措置』というんだ。破損漏洩が起きました、カバーをかけて漏出を止めました--そんなのは、転んでケガをしました、赤チンを塗って絆創膏を貼りましょう。だから救急箱を必ず一つ家庭に用意しておくべきです、と言っているにすぎない。それは問題解決ではない。何かトラブル事象が起きたら、対応策は二種類必要だ。被害を食い止め、現状を可能な限り沈静化する『応急措置』と、そのトラブルを繰り返さないために真の原因を除去する『再発防止』の二種類だ。いうまでもなく、教訓としては後者の方がずっと重要なことは分かるね。」

--はい。

「では、その流出事故の真の原因は何かな。」

--それはまだ分かっていません。油井管の材料欠陥か、操作のミスか、海底気象の急変か、あるいは設備の保全が十分でなかったのか・・。

「むろん、現場をきちんと調べないうちは判断できんね。だが、かりに運転員の操作のミスだったことが分かったと仮定しよう。その場合の再発防止策は?」

--それは、えーと、そうですね、運転マニュアルにしっかり明記する、運転員の教育訓練をきちんとする、といった対策が必要です。

「おや。“しっかり”だの“きっちり”だの、余計な形容詞をつけて何か言ったつもりか、君は? 内容の定義もない、何の意味もない、無駄な装飾語を使って、対策を述べてはだめだ。」R先生は私を睨んだ。「そいつらを省くと、マニュアルに書く、運転員の教育訓練をする、そういう事になるな。そんな当たり前のことを、天下の石油メジャーが忘れたと本当に思ってるのか。じゃあ聞くが、オペレーターがちょっと操作を間違えただけで、大事故になるような設備で良いと思うのか?」

--・・・そうですね。考え足らずでした。

「大いに足らんね。人間はミスをするものだ。機材も摩耗するものだ。天候も変動するものだ。それがいちいち事故の原因になっていたら、現代文明など存在できるはずがない。『ミスをしました』が原因だと報告が来たら、なぜ、ミスをさせないためのフールプルーフ(ポカよけ)が無かったのか、あるいは、なぜミスの結果を封じ込めるフェイルセーフが作動しなかったのか、をむしろ問うべきだ。」

--それで思い出しましたが、今回の事故に関連して、BPは昨年のアセスメント報告書の中で、原油漏出の可能性を想定していなかった、という記事がありました。あれほどHSE(Health, Safety & Environment)に厳しいBPとは思えないことですが・・・。

「なるほどな。それこそが典型的な『マネジメント要因』なんだ。リスクのシナリオを想定していなかった。だから、適切なフェイルセーフを用意できていなかった。そこでトラブル事象が連鎖的に拡大してしまった。
 元のきっかけは、配管の金属疲労か、つまらぬ操作ミスか、水温の急変か、そんな些細な技術要因だったろう。それは、個別には、技術的な対策ができる。しかし、技術領域での対策を適切に行わせる仕事は、マネジメントの仕事だ。つまり、トラブル事象というのは、必ず技術要因とマネジメント要因とが重なって生じるんだ。あのタイタニック号が、なぜあれほどの被害を出したのか、前に教えてあげたことを覚えているかな。」

--世界最大の“不沈船”だから、という思い込みのために救命用避難ボートを削減して、乗客人数の分だけ用意していなかったからですね。

「そうだ。氷山に接触して、リベットが剥落したなどということは、きっかけでしかない。本来、船というのは、防水壁で浸水区画を遮断すれば、沈没はまぬがれるんだ。しかし、上等客室の居住性を優先するあまり、防水壁を喫水線の上まで立てていなかった。だから沈没した。でも万が一沈没しても、救命ボートが乗客定員分あれば、人の命は救えたはずだ。それが起きたのは、“不沈船”という驕りによって、二重三重のフェイルセーフを全部無意味にしてしまったからだ。
 氷山にしたって、出港時からすでに北大西洋に警告は出ていたんだ。だが、世界一の航路記録を樹立しようとあせった会社が、無理に出航させ、夜間も全速航海していた。どれもこれも、マネジメント要因だ。これだけ危険な環境を自分でこしらえておいて、氷山が事故の原因だった、いや当時の造船施工技術が未熟だった、などと言うのは愚かだ。」
 
--マネジメントが、技術的危険性を増幅したということですか。

「いいかい。小さなトラブルは、いつでも起きうる。問題は、それを抑え込めるか増幅してしまうかの違いだ。その違いは、マネジメントのあり方から来るんだ。小さなトラブルはたいていの場合、技術的に対処できる種類のものだ。だが、適切な対処を怠れば、雪だるま状にすぐ大きな問題に膨れあがって、暴れはじめる。」

--たしかに、最近世間を騒がせた、いくつかのメーカーの品質問題やら偽装騒ぎなんかも、経営側の対処がまずくて、問題を膨らませていましたね。あるいは、ソフトにバグが見つかった場合、それをすぐ認めてユーザに知らせれば小さなトラブルですむものを、かえって無視して騒動になったりします。

「逆に言うなら、小さなトラブルとは、それ自体が一種の『アラート』なのだ。アラートに気づくのも、見て見ぬふりをするのも、マネジメントの態度しだいさ。
 君の勘違いとはね、トラブルの原因分析をすれば、技術起因のものとマネジメント起因のものとに分類できるはずだ、という思い込みだ。両者は必ずワンセットになっている。原因分析をするときは、そこまで掘り下げなかったら、嘘だ。」

--ふうむ。そうすると、「なぜなぜ5回」のような掘り下げが必要ですか。

「はっきり言うと、『なぜなぜ5回』は素人がやると変な方向に行きがちなので、あまり勧めない。ほら、何でもすぐ“政治がわるい”“社会がわるい”と言いたがる手合いが、よくいるだろ。あれと同じだ。うっかりすると、経営者がダメだから、不況のせいだから、という結論になってしまう。これは、根本原因とは言えんのだよ。」

--じゃあ、何が根本原因なのですか。

根本原因というのは、事象の合理的な主原因であり、かつ、当事者にとってマネジメント可能なものを指すのだ。マネジメント可能、というのが大事だ。経営者のレベルとか、経済不況とかは、マネージできんだろ。
 トラブルが起きたとする。現象を調べてみる。すると操作ミスが引き金になっていた。だが、操作ミスを防止するフェイルセーフが働かなかった。なぜ働かないのか? わざとオフにしていたのか、壊れていていざというとき効かなかったのか、元からつけていなかったのか? --こういう風に、さかのぼっていかなければダメだ。きちんとたどれば、たいていは、マネージ可能な仕組みか教育の問題に行き当たる。そいつが根本原因だ。
 世間でよくあるトラブルの分析というのは、すぐに個人の資質を原因にしたがる。ミスの多い人だったとか、スキルが低かったとか。マネジメントの問題でも、リーダーシップが足りないとかなんとか。しかし人間の資質なんて急に変わらない。スーパーマンでなければ務まらないような仕事だとしたら、それは仕事の仕組み自体が間違っているのだ。」
 
--はい。

「17世紀だったか18世紀だったかに、ロンドンで大火があった。それ以降、英国では都市の防火・耐火政策が進んだ。一方、ほぼ同じ頃、江戸でも有名な大火事があった。江戸幕府は何をしたと思う? 火元の人間を、厳罰に処することにしたのだ。どちらが有効な対策か、わかるだろう? そして、どちらがトラブルに本当に学んだかも。」
by Tomoichi_Sato | 2010-05-11 23:18 | ビジネス | Comments(0)
<< モノを買うのか、機能を買うのか R先生との対話 - トラブルか... >>