問題分析がうまくいかない理由

今回は、「問題がなぜ起きたのかわからない」「原因がうまく掘り下げられない」など、問題分析のやり方で戸惑うケースについて書きます。
結論から言いますと、問題分析がうまくいかない理由は、大まかに下記の３点です。（→経験上）
以下で、それぞれについて説明します。

１．”解決すべき問題”がわかっていない

そもそも、問題そのものを捉えきれていないということが、実際はとても多いです。

現実の問題（事象）は、複数の問題が絡み合っていることがほとんどです。
下図は問題の構造を示したものですが、大小様々な問題が絡まって一つの問題（事象）になり、影響度が大きくなるほど（上に行くほど）、問題がさらに集まって「大問題＝トラブル」を形成していく構造になっています。

問題を適切に捉えるとは、問題が起きている対象を特定し「実害」や「影響」について第3者が見てもわかる状態にすることです。

たとえば、「経理システムで問題が発生し、大変なことになってます！」という報告では、何が起きているのかわかりませんよね。

少し噛み砕いて「A社向け4月リリースの経理システム（Ver1.21）において、勘定コードの設定にミスがあり、月締め処理の際、一部データが二重に計上される問題が生じている」というような内容であれば、いかがでしょうか？
第3者が見て、ある程度は問題の素性がわかるのではないかと思います。

上記は説明の詳細度の違いでは？思われがちですが、”複数の問題を切り分けて、問題を適切に定義する” 部分が大事なところです。

つまり、複数の絡み合った問題とその背景を整理しつつ、実害や影響に着目して、”解決すべき問題を定義する”という行為が問題分析の一歩目として欠かせないポイントになる ということです。

２．問題の構成要素が押さえられていない

仮に問題を適切に定義できたとして、次に、その問題を作り上げた要素がわからないと、原因を掘り下げる相手が特定できず、後々苦労することになります。

具体的には、下記の要素を明らかにする必要があります。
こんな感じ。（下図もあわせて参照）
【モノ】問題に関係するモノ（抽象的な概念も含む）
【コト】問題に至るまでの道のりや背景
【カネ】問題に関連する費用や各種リソース
【情報】問題に関わるすべての情報、データ
【ヒト】問題に関わった関係者

上の要素をクリアにすることで、少なからず問題の根っこは見えてきます。
　　
１の経理システムの例でいえば、こんな風になります。

【モノ】→プロダクトや仕様書、手順書など
・経理システム（Ver1.21）の勘定コードテーブル
・同　月締め処理プログラム、帳票出力プログラム
・詳細設計書、テスト仕様書、テスト結果
・納品したアプリケーション、プログラムのビルド　　・・etc.
　　
【コト】→実行方法・手順・仕組みなど
・実際のテスト手順、確認の方法、レビューの仕組み　・・etc.

【カネ】→実害や影響など
・顧客業務への影響、被害額
・対応コスト　・・etc.

【情報】→工期や期間、作業時間、
・ミスのあったデータ、本来のデータ
・作業担当の実働時間、データ設定時の状況　・・etc.

【ヒト】→担当者など
・作業を担当したエンジニア、レビューアー、リリース担当　・・etc.

３．原因掘り下げのやり方を間違え、思考停止している

問題の構成要素（材料）が出そろったところで、原因の掘り下げを行っていくわけですが、そのやり方次第で根本原因（真因）に行き着けないことが往々にしてあります。

こちらは長くなるのでまた書きますが、１つだけ重要な点をお伝えしておきます。それは、”【ヒト】に関する掘り下げは、他の要素が出そろった所で行う” という点です。

こんな会話があったとします。

A部長：「■■プロジェクトが失敗しそうです」
　　
B役員：「誰がプロジェクトを担当しているんだ？」

A部長：「○○さんです」

B役員：「そうか。あいつはダメだな。まずPMを変えろ。」

A部長：「・・・。」

冗談めいた会話ですが、 これは本当にあった （よくある） 話 です。

実際、他の要素より先に【ヒト】の話が出てくると、問題の掘り下げの議論をすっ飛ばして結論を導くような「思考停止」が起きることがあります。

いかがでしょう？　あなたの周りではこのようなことが起きていませんか？

今回は、問題分析がうまくいかない理由（陥りがちなポイント）について書きました。

もし１つでも思い当たる点があるならば、
「解決すべき問題は何か？（What）」
「問題の根っこはどこにあるのか？（Where）」
という問いかけをご自身で行ってみてください。