トラブル発生時の「体制図」と「いきさつフロー図」を描けているか(なぜなぜ分析でヒューマンエラー撲滅)

Home » 媒体 » ITpro » トラブル発生時の「体制図」と「いきさつフロー図」を描けているか(なぜなぜ分析でヒューマンエラー撲滅)
ITpro, IT・インターネット コメントはまだありません



 失敗した原因を探るうえで重要な点は、情報の抜け・漏れを最小限に抑えることだ。「そんなの当たり前。誰でも分かっている」と思うかもしれない。企業によっては「ウチは網羅的に情報を収集するために観点を定めて整理しているから、抜け・漏れはほとんどない」と思っている人も少なくない。

 しかし現実は大きく異なると、私は考えている。トラブルの原因を追究する目的で、なぜなぜ分析を始める前にきちんと観点を定めて網羅的に情報を収集・整理していたとしても、所詮はその場にいたメンバーが気づいた範囲の議論にとどまることを、多くの人が意外と分かっていない。だから、メンバーが気づきにくい情報は全く挙がってこないまま、なぜなぜ分析を始めてしまう。これでは的確な再発防止策を導けるとは思えない。

 肝心な情報が抜け落ちたまま「なぜ?」を繰り返しても、問題の核心にメスが入っていかなければ、同じミスの繰り返しを止める再発防止策は導けない。結果的に原因を見誤って「誤認逮捕」になるか、原因追究が暗礁に乗り上げてしまう。

 しかも大多数の企業では情報を取集したうえで、それらを「箇条書きにして整理する」ケースが非常に多い。これで網羅的に情報を「整理」できたと勘違いしている人を大勢見かける。

 箇条書きは一見すると、簡潔に整理された情報のようだ。そのため、必要な情報が抜け・漏れなく網羅されているかのような錯覚を起こしやすい。だが私に言わせれば、箇条書きで情報をまとめているだけでは、情報の抜け・漏れはなくならない。

 では、どうすれば、情報の抜け・漏れを防げるか。気づきにくい情報をすくい上げるには、どうすればよいのか。

情報の抜け・漏れを防ぐには2つの「図」を描く

 結論を先に言うと、情報の抜け・漏れを抑えるには「図」を描くべきだ。図を描くことで、気づきにくいところまで情報を拾い上げやすくなる。これは私が長年なぜなぜ分析を続けてきて実感した、体験に基づく結論である。

 ただし、1つ条件がある。なぜなぜ分析に参加するメンバーのなかに最低1人は、分析する対象の業務知識や実務経験がある人を加えることだ。該当業務の素人がいきなり、図を描けるはずがない。仮に描けたとしても業務知識や実務経験がないので、細かいところまではどうしても気づけない。

ダメな「体制図」の例。縦に並べて描くのはNG

(出所:マネジメント・ダイナミクス)

[画像のクリックで拡大表示]

 それでは、どんな図を描いたらよいのか。例えば、新商品開発やシステム設計といった業務での失敗の原因を追究する場合。まず最初に「どのような体制で開発や設計の業務が実施されていたのか」を表す組織の図を描く。私はこれを「体制図」と呼んでいる。

 体制図は、該当組織やチームに部長がいて、課長がいて、担当者が数人いてといった人員構成と、各自がどんな役割を持って業務に当たっているのかを確認するためのものだ。メンバーだけでなく、指示や連絡、承認の流れも書き込む。分析対象とする問題に関連しそうな部署がほかにあれば、その組織も体制図に加える。

 こうした体制図を描こうとすると多くの会社では、例えば顧客側の体制と自社の体制、協力会社側の体制の3つがあった場合、それら3つを右上の図のように「縦」に並べて描く人が多く見られる。

 しかし縦に並べて描くのは、私の経験からすればNGである。下の図のように「横」に並べて描く。

良い「体制図」の例。横に並べて描く

(出所:マネジメント・ダイナミクス)

[画像のクリックで拡大表示]

 なぜ縦ではなく、横に並べて描くのか。それは指示や連絡、承認の流れを体制図で確認しやすいからだ。横に並べて図を描いたほうが理解しやすい。社内では部署ごとに上司から部下までの職位が決まっている。その職位には決められた役割と責任があり、それに基づいて業務が行われていなければならない。横に並べることで、企業間の情報の流れは横向きの矢印、企業内のやり取りは縦の矢印といった具合に分けられ、分析しやすくなる。

「体制図」には組織の所属メンバーとともに、指示や連絡、承認の流れを書き込む

(出所:マネジメント・ダイナミクス)

[画像のクリックで拡大表示]

 体制図を描く最大の目的は、問題となっている案件の業務が、きちんと組織的に行われていたのかを、最初に再確認するためだ。もし曖昧な点があれば、誰がどういった役割を持ち、何に対して責任を負っているのかを改めて考えるきっかけにする。これが再発防止策を考えるうえでの第一歩になる。

 定型業務が対象なら、なぜなぜ分析の前に体制図を描く必要はないかもしれない。逆に定型業務がほとんどないような部署では「必ず体制図を描いてみる」必要がある。非定型業務は図にしてみないと、情報の流れや責任範囲がよく分からないからだ。

 だから体制図を最初に描き、どのようなメンバーが何に、どこで関わっているのかをはっきりさせる。それが問題解決の糸口になる。






コメントを残す