 |
想定外リスク発生時のリスクマネジメントとトラブル対応時の心得 斎藤 雅敏：4月号
〇はじめに 東北地方太平洋沖地震で犠牲になられた方々のご冥福をお祈りし、被災者の皆様に心からお見舞いを申し上げます。 また東北のみならず日本全国が“復興”に向けてチカラを集め、発揮していく事を願ってやみません。 〇“想定外”リスク発生時のリスクマネジメント考 リスクマネジメントでは、リスクを把握･特定し、発生頻度と影響度によって採る対策を決定するものです。この観点から言うと、今回の大震災については正に“リスク管理”の対象外に措かれる事態だと考えられます。 結果、どうなったか。 指示系統が失われ、地震、津波、火災が発生する。 原子炉が破綻しつつある。そのときどうすべきか。 想定外のリスクが発生した場合、リスクマネジメントとしてのアプローチはどうすればよいか？という観点から考えたいと想います。 経験上から言うと、トラブル発生時には、目の前の事象に対処するチーム(実行チーム)、コントロールするチーム(戦術チーム)に分けて行動するべきです。 何故分けるべきなのか。 トラブル対応に当るチームは目の前のトラブルに集中するべきであるから、です。 トラブルの規模が大きくなればなるほど、報告資料作成や各方面窓口とのコミュニケーションが増えていきます。そこをうまく切り分け、迅速に対応出来なければ、現場に当る人間の負荷が高まり、解決出来る事柄が少なくなってしまうためです。 また外側から見ていると「どうしてこんなことも気が付かないのだろう」ということがありますが、トラブルの当事者からしてみれば、目の前のトラブルを収束させる事に注力するため、他のことが見えないことがあります。 だからこそ、冷静な視点からチェックする体制、細かいレベルでのフォローアップなどが戦術チームに求められてきます。 戦術チームがすべき事は他にもあります。トラブル対応しているうちに挙がってくる様々な問題の色分けです。今解決すべきこと、出来ること、広げないことを色分けて方針を決定する。上層部と掛け合って“組織として”どうするべきかを決定し、実行チームに渡す。 こうして戦術チームと実行チームに分担して対応する事により下記の効果が期待出来ます。
但し注意すべき点として｢戦術チームが実行に入り込まない｣コトが上げられます。 色々“問題点”が見えるので、つい口出ししたくなるのですが、実際にやっている部分に任せることが必要です。 以上の点を踏まえて、戦術チームと実行チームとの“あるべき姿”を考えて、うまく連携が取れるように日頃から訓練しておく必要があります。 またトラブル対応が済んでからは、今回の対応の振り返り及び今後の対策方法を練っておく必要があります。これはいわゆる｢PDCA｣サイクルのCheck－Action 部分に相当するものです。 次の計画を立てる際には、今回のトラブルはリスク管理の範囲内に治めるのか、優先すべきかも考慮に入れるべきです。 今回の大震災をレアケースとして受け留めるか、起こり得る事象として捉えるか、判断が難しいことになるでしょう。理想を言えば今回発生分を超えるリスクが発生してもカバー出来ることが望ましい。だがそれには相応のコストと時間が掛かります。優先順位も発生するし、“あるべき姿”を見据えたスタートをしなければならない部分も当然あるでしょう。 また定期点検的なPDCA(備品の点検、見直しも含めて)も必要になっていきます。
〇トラブル対応に際して トラブルが発生するとパニックを起こしてヒステリックに｢何故発生したんだ！どうしてくれるんだ！｣という方が“マレに”見受けられますが、それはトラブル対応時にはマイナス要因でしかなく、そんな方が上司だったりコントロールの立場に居た場合、個人的には箱につめてどこかに隔離したい衝動に駆られます。 (それを何とか収めるのも、トラブル対応時の重大解決要素、ではありますが) 逆にどっしりと構えて｢何かあったらオレが受け留める。お前達はトラブル解決に注力しろ｣という上司だとしたら。それはもう言う事ありませんね。 お客様のためにも、またその上司にこれ以上の迷惑を掛けないためにも、チーム一丸となってチカラを出す事が出来るでしょう。 私が経験してきた中で、トラブル対応時に必要と想われるコトを3つ上げます。 【まず落ち着くこと】 これは非常に重要です。緊急であればあるほど、大事であればあるほど、落ち着くコト。遠回りでも確実な事を選ぶ。 対応が速くても、後々障害が出たら元も子もありません。チェックとリカバリ方法は押さえておく。 【”現場”の話しを良く聞くコト】 システム上”有り得ない”コトだとしても、自分が操作して再現出来なくても｢日常使っている現場の声｣は正しい。 そこに問題のヒントは必ず隠されています。まず問題が上がってきた現場の声を良く聞きましょう。そしてその人の“考え”を聞きましょう。システム知識は無いかも知れませんが、現場で培ってきた経験がそこにはあります。そして“イレギュラーを感じ取る勘”は、私達より優れている事は間違いありません。 ソコに“システムとしてどうあるべきか”という全体像を交えて考えていくのが必要になります。 【｢めんどくさい｣と感じたコトはさっさと対応するコト】 トラブルというものは(ヒトが関係する場合は特に) 後になれば成る程、深く大きく痛くなって行きます。これは確実に言える事です。何故ならば「面倒くさい事＝一番大きなトラブル」だからです。トラブルは必ずそこで止まるモノではありません。常に周囲に影響を与え続けています。 「これは月次処理のデータだから後回しでも構わない」 そう判断したものが日々集約されていき、月次処理時にとんでもない結果になった事があります。 自分が｢めんどくさいなぁ｣と感じた事は、イコール優先順位が一番高いものとしてスケジュールするよう、心がけて下さい。 〇まとめ ｢トラブル対応｣というものは、出来れば避けて通りたい、でも“必ず起こり得る”事象です。その時に当り、如何にコトを収めるか。如何に範囲を広げず、収束に向かわせるか。 日々トラブルに立ち向かう皆様へ。あなた方のおかげで“その”システムは成り立っています。 それを“誇り”として、目の前の問題から目を背ける事無く立ち向かって下さい。 あなた方の“プロジェクト”が成功し続ける事を願っています ☆ご意見、ご感想はtwitterにてお待ちしています！ Twitter_id： ma_onpu ハッシュタグ： #pm_cafe |
 |