原因分析フレームワークの使い方~なぜなぜ分析・ロジックツリー・IPOフレームワークを解説~

業務を行っていくうえで、大なり小なりの「ミス」は付き物ですが、何度も同じミスを繰り返し、客先へ損害を与えてしまう事故につながってしまう場合と、ミスが発生してもすぐにリカバリでき、客先に損害を与えずに済む場合の2パターンがあるのは何故か考えたことはありますでしょうか。

結論から言うと「原因分析フレームワーク」を用いて事故の原因を分析したかどうかが大きく影響しています。

今回の記事は、事故を防ぐ手段としての「原因分析フレームワーク」について解説していきたいと思います。

原因分析フレームワークとは

日頃従事している業務で事故や不具合が発生した時、しばしば「個人のミス」を原因にして責任を追及したり、「注意喚起する」といった漠然としたものが再発防止策に決定されたりして、結果的に問題を解決することができずに同じような事故が再発してしまった、ということがあります。

実際の業務を行っていく上で、事故や不具合の原因が特定できず再発防止もできない、というのでは事業の継続性が危ぶまれてしまいますので、多くの企業では、問題解決するために考えるべきポイントがパターンとして落とし込まれ、誰が分析しても同じ原因にたどりつけるようになっている「原因分析フレームワーク」というものを利用しています。

フレームワーク

フレームワークとは一般的に「型」や「枠組み」などと和訳される言葉なのですが、ビジネス用語では「問題解決をするための決まった手順」といった意味で使われており、フレームワークを用いることで以下のようなメリットがあると言われています。

  • 汎用的な機能があらかじめ用意され利用することができる
  • どんな人が利用しても同じ水準の成果物が得られる

その中でも原因分析フレームワークを用いる場合は「どんな人が利用しても同じ水準の成果物が得られる」という点が重要視されており、その視点で原因分析フレームワークが取捨選択されています。

例えば、事故の原因を複数人で分析してみたけど、全員の分析結果がバラバラということになると、どれが本当の原因なのかわからず、効果的な対策を実施することができません。

しかし決まりきった枠組みの中で分析し、多くの分析結果が示す原因を絞り込むことがができれば効率的に対策を実施することができるでしょう。

そういった意味から考えても、様々なフレームワークを学び、どんなフレームワークが自分たちにあったフレームワークなのかを判断していくことが重要となってきます。

今回の記事ではいくつかの原因分析フレームワークを紹介し、どのような場面で利用すべきかを探っていきたいと思います。

ミスをしないエンジニアは「正しい○○」をやっている

様々な原因分析フレームワーク

自分たちにあったフレームワークを探すことが重要、ということが分かったかと思いますので、早速、原因分析フレームワークにはどんな種類があるのかを見ていきたいと思います。

なぜなぜ分析

なぜなぜ分析」とは、何らかの事故が発生した時に「なぜ(問題を引き起こした要因)」を繰り返し提示していき、最終的な問題解決をはかる分析方法です。

事故が発生した後の再発防止策を検討するための分析方法として利用されていますが、「なぜ」を繰り返していく手法を「商品」や「教育」の「なぜ」に応用することで、商品改良や教育効果の改善などにつなげることもできます。

ロジックツリー

ロジックツリー」とは、問題点を「論理の木」というツリーに分解していき、原因や解決策を論理的に探していくフレームワークです。

問題点を「因果関係」で分解していくことになるので、重複や漏れのない分析結果を得られることができ、原因究明や問題の改善策を検討するための方法として利用されています。

IPOフレームワーク

IPOフレームワーク」とは、問題点を「Input」「Process」「Output」の3つに分けて考えるフレームワークです。

最初に「入力内容」「取組内容」「成果物」のあるべき姿を明確に定義していくため、製造過程における品質の安定化や業務の効率化などを検討するための方法として利用されています。

なぜなぜ分析を用いた原因分析

それではまず、「なぜなぜ分析」はどのような方法で分析するのかを見ていきましょう。

なぜなぜ分析の手法

なぜなぜ分析の基本的な考え方は、「真因を特定し、再発防止策を決定する」というものです。

一般的には、問題となる事象に対して5回の「なぜ」を繰り返す、と言われていますが、「なぜ」を繰り返していく過程で「再発防止策につながる真因」を見つけ出すことが重要ですので、真因が見つかった時点で「なぜ」をやめて構いませんが、5回繰り返しても真因が見つからなければ「なぜ」を繰り返していかなければなりません。

同じトラブルを繰り返さない

なぜなぜ分析で真因が特定できれば、問題のほとんどを解決できたと言っても過言ではないでしょう。

逆に言うと、真因が特定できなければ「再発防止策を決定する」という目的が達成できませんので、問題を解決したとは言えません。

たとえば、「ある制作物の一部に顧客の要望した内容が反映されていなかった」という事故を分析した場合で説明します。
最初の「なぜ」を検討してみたところ「作業者が指示内容を見逃したため」という理由が挙がったのですが、この理由は真因と言えるでしょうか。

答えはもちろんです。

「作業者が指示内容を見逃したため」と作業者のミスを追及したところで、「注意喚起する」といった程度の対策しかとることができませんし、「注意喚起する」ことで「ミスを確実に防ぐことができるか」と言えば、そんなことはあり得ないのは誰でも分かることでしょう。

「注意喚起する」という対策が「再発防止策」として成立しないのであれば、なぜなぜ分析を繰り返し、以下のような分析結果とする必要があります。

なぜなぜ分析
「ある制作物の一部に顧客の要望した内容が反映されていなかった」
1回目のなぜ→「作業者が指示内容を見逃したため」
2回目のなぜ→「チェック担当者も指示内容を見逃したため」
3回目のなぜ→「指示内容が不明瞭だったため」
4回目のなぜ→「作業する前に作業範囲を明文化していなかったため」
5回目のなぜ→「明文化した作業範囲を顧客に提示し、顧客からの同意を得ていなかったため」

顧客からの指示を明文化し、作業範囲の確認を顧客にお願いしておけば、作業する前に「指示を見逃していたこと」に気付けるかもしれませ。

また顧客からの同意を得ておけば、その範囲内で作業をしている限り責任を追及されることもないでしょう。

つまり、この事故の真因は「明文化した作業範囲を顧客に提示し、顧客からの同意を得ていなかったこと」であり、「作業する前に必ず明文化した作業範囲を顧客に提示し、顧客からの同意を得るようにする」ということが再発防止策ということになります。

この事例からも、真因の特定と再発防止策の決定はほぼ同一のものであることが分かるかと思います。

ノウハウの蓄積

「なぜなぜ分析」で原因分析するメリットは、「なぜその事故が起こってしまったのか」を分析することが、そのままノウハウの蓄積につながることではないでしょうか。

前述の事例で言えば「作業前に顧客からの同意を得る」というのが再発防止策となるわけですが、これはマネジメントにおける「SLA管理(サービルレベル管理)」に通じるものがあります。

こういった「業務マネジメントのノウハウを高めることにつながる」という点が「なぜなぜ分析」を導入する時のメリットと言えるのではないでしょうか。

固定観念の打破

「なぜなぜ分析」のデメリットとしては「事故の原因は個人のミス」といった固定観念を打破しなければ、真因にたどりつくことができないことでしょう。

フレームワークとしては「原因を個人のミスにしてはいけない」と設計されてはいるものの、その考え方を正しく理解しなければ真因を特定することができず、再発防止策が決定できないといったことに陥ってしまう可能性もあります。

その点で言えば「どんな人が利用しても同じ水準の成果物が得られる」というメリットを得られるフレームワークとは言えませんので、このフレームワークを使うべきかどうかは慎重に検討する必要があるのかもしれません。

ロジックツリーを用いた分析方法

次に「ロジックツリー」という分析方法を見ていきましょう。

ロジックツリーの手法

「ロジックツリー」では、問題をツリー状に分解し、論理的に原因や問題解決策を探していくことになります。

目的に応じて「What:要素分解」「Why:原因分析」「How:問題解決」「KPI:重要業績評価指標」の4つのタイプがありますので、それぞれどういう目的で使われるのかを見ていきましょう。

What:要素分解ツリー

要素分解ツリーは、物事を網羅的に把握したい時に使うロジックツリーです。
例えば、Macにインストール可能なAdobeソフトウェアの動作環境の洗い出しなどに役立つと言えるでしょう。

ただし、見ていただければ分かる通り、原因を分析するためのフレームワークとは言えないようです。

Why:原因分析

ロジックツリーを使って原因分析する場合は、そのものズバリの「原因分析ツリー」を利用します。

前述した「ある制作物の一部に顧客の要望した内容が反映されていなかった」といった事故の原因を分析する場合、以下のようなツリーとなります。

 

ロジックツリーで分析した場合、「なぜなぜ分析」では言及されなかった「チェック体制のルール」についてが言及されています。

このことから「なぜなぜ分析」での分析結果に比べて「漏れのない分析結果」を得ることができる分析方法と言えるのではないでしょうか。

How:問題解決

問題解決ツリーは解決したい問題に対して改善策を挙げていく手法です。

たとえば、原因分析で「作業範囲を明文化して顧客の同意・確認を得ている?」という分析結果に対しては「作業前に顧客からの同意を得る」という改善策を挙げていきます。

具体的なアクションを検討する必要がある場合に有効な分析方法と言えます。

KPIツリー:重要業績評価指標

KPIツリーは、問題解決ツリーの派生として、KPI(Key Performance Indicate/重要業績評価指標)を設定し、KPIを達成するためのアクションを考えていく手法です。

原因が顧客や外注先などの外部に起因しているような時など、ねばり強く改善していかなければならない場合に有効な分析方法と言えます。

IPO分析を用いた分析

続いて「IPOフレームワーク」という分析方法を見ていきましょう。

IPOと制約条件・成立条件

前述した事例の「ある制作物の一部に顧客の要望した内容が反映されていなかった」をIPO分析を用いて分析した場合、以下のような結果となります。

  • インプット
    顧客の要望の中に不明瞭な要望が含まれていた。
  • プロセス
    顧客の要望に沿って制作作業を実施した。
    顧客に作業範囲の合意をとらずに作業を実施した。
  • アウトプット
    顧客に作業範囲の合意をとらず、制作物に顧客の要望が反映されていない状態で納品した。
  • 制約条件
    納期に余裕がなく、顧客に確認する時間がない。
  • 成立条件
    要望内容に不明瞭な箇所があり、作業対象であることを見逃した。
    チェック担当者も作業対象であることを見逃した。

IPO分析の「成立条件」「制約条件」を検討することで「顧客に作業範囲の合意をとらなかった」という原因に「納期に余裕がなく、顧客に確認する時間がない」という理由があることが分かります。

「あるべき姿」を考えて改善

また、これらの分析結果から、アプトプットである成果物は「客に作業範囲の合意をとった上で納品すべき」という「あるべき姿」がどういうものなのかも分かります。

IPOフレームワークは、「どのような成果物を納品すべきか」といった「あるべきアウトプットの姿」を定義するのに適した手法であると言えるでしょう。

原因分析フレームワークの失敗原因

今回、「なぜなぜ分析」「ロジックツリー」「IPOフレームワーク」といった原因分析フレームワークを見てきましたが、原因分析フレームワークを用いたからと言ってすぐに問題解決ができるわけではなく、実際の業務では、うまく問題解決につながらないことが多く存在します。

最後に、原因分析フレームワークが失敗してしまう原因について探ってみたいと思います。

問題点が不明確

原因分析フレームワークが失敗してしまう大きな原因は「問題点が不明確」という点です。

前述の事例である「ある制作物の一部に顧客の要望した内容が反映されていなかった」という問題も、問題点を漠然と「制作物にミスがあった」といった程度に認識していると「指示が不明瞭だったため作業者が見逃したのか」「チェック体制が不十分で作業漏れに気づかなかったのか」といった深堀りができません。

原因分析フレームワークを用いる場合、問題点を明確に把握しておくことは必須のスキルと言えるでしょう。

個人の問題にしてしまう

「なぜなぜ分析」の時にも少し言及しましたが、「事故の原因は個人のミス」といった固定観念があると原因分析フレームワークは正しく機能しないばかりか、事故の責任を個人に押し付ける悪質なものに変貌してしまいます。

こんな状態で原因分析フレームワークを用いることは有害でしかありませんので、組織や仕組みに原因があるということを前提に原因分析フレームワークを用いるよう意識するとよいでしょう。

経営側の無責任

原因分析フレームワークで真因を特定して再発防止策を提示しても、経営者側が無責任であれば、せっかく提示された再発防止策も実施されることはなく、同じ事故や不具合を何度も繰り返してしまう結果となってしまいます。

組織全体で再発防止策に取り組む必要があるということを全員が理解し、経営者側が率先して行動したり、責任者を定めるなどして再発防止策を進めていくとよいでしょう。

対策へのコストを無視

再発防止策を実施する際のコストを無視するのも、原因分析フレームワークが失敗する原因のひとつです。

日々の業務をこなしながら事故の原因分析も実施するとなると、作業者に相当な負担がかかってしまいます。

その結果、つじつま合わせの原因分析となってしまったり、1つの原因を特定しただけで分析を打ち切ってしまったりといった弊害が発生し、原因分析フレームワークが正しく機能しません。

原因分析や再発防止策を実施するには、相当なコストが発生していることを理解し、原因分析を実施するものには日々の業務を免除するなどして原因分析フレームワークに集中できる環境の構築が必要となってくるでしょう。

習慣化することで得られるメリット

まとめ

いかがでしたか。

今回は原因分析フレームワークというものをまとめて紹介してみました。
特に失敗原因に挙げた事由をみていただければ分かる通り、原因分析フレームワークは正しくやらなければ有害でしかありません。

今回は事故を防ぐ目的としての原因分析フレームワークの解説でしたが、今後、原因分析フレームワークに取り組まなければならなくなった時がありましたら、こちらの記事を思い出していただければ幸いです。

分解力

BLOGコンテンツをパーソナライズします

あなたは現在「プログラミング学習者」ですか?