トラブル対策はこれからあと何回繰り返すかで選択すればよい

週初めから何ですけど、しかし、トラブルは次々と大なり小なり起きますねぇ。先週だって些細なことはあったし、この前のアレはほんとトラブルだったし…。変な言い方ですがトラブルがあること自体が“当たり前”というか“日常”を構成する要素なんじゃないかって思っちゃうくらいです。

トラブルは大なり小なりがあるもので、小さいものはヒヤリ・ハットのレベルから、上流設計の人に言えない間違いを越えたレベルまで様々あるものです。上流設計になればなるほどトラブルの影響範囲とインパクトは重くて、対象となる後続工程は広くなるし、その衝撃度は深いものです。

今時なら何かトラブルが顧客に報告しなければならないようなインシデントであれば、原因特定と暫定対処、本格対処と並んで再発防止が求められるし、対策する方もある意味習慣のように何らかそれらしい再発防止策を打つわけです。

顧客の報告する必要のないものでも、やっぱり「(これ拙いよなぁ。)」と思えばやっぱり何等か手を打つわけで。

トラブルの対策はリスクの対策でもあるので、そのトラブルの影響度と発現する確立を掛け合わせたものがエクスボージャで、これが大きいものから対策しなさいって言うんです。でも、それ正確にはじき出せるんですかね。出来るものもあるだろうし、出来ない＝想定できないものもあるだろうし。でも、何かしないと、であればどうすればいいかって話です。

当たり前と言えば当たり前だし、言われれば「そうだよね。」なんだけれど、エクスボージャの大きなトラブルは対策が大掛かりになりやすいものです。だって、インパクトがあるから発現する確率が少なくてもエクスボージャが大きくなるんだから。

もう一つ、エクスボージャが大きくなるケースが、小物だけど発現する確率が高いものです。これま当たり前と言えば当たり前です。小さいトラブルだけれど、そう何度も何度も出てきて積みあがればそりゃ“チリツモ”だもの。

で、どっちやるか、です。選択しないといけない。リソースも時間も限られるんだから。

ワタシは、これから“あと何回繰り返すか”で選択する基準を設けたらいい、と思うんですよ。

本当に来るのか来ないのかわからないことの対策より、明日、来週、来月、次工程、次の開発線表で“繰り返すことがわかっている方の対策をせよ“、です。繰り返すことのトラブル対策は、トラブルを繰り返すことに“慣れる”ことを防止するし、トラブルを起こしている“プロセスを改選する”ことを日常にするのですよ。

トラブルを変えることが日常のマインドセットも変えて別のトラブルまで防止する期待が得られるんです。