組織課題のエラー原因を調査し、存在を確認し、取り組みが必要な対象か確認することについてまとめます。
問題の掘り下げ方法
大枠の流れは、先日会社のブログにまとめました。
- インプット収集
- 問題発見
- 問題の存在確認
- 問題選定
- 施策の立案
- 施策の遂行
- 施策の影響確認
- 施策の実施結果の周知
今回はエラー原因の調査がテーマなので、3の存在確認のところまでの話をします。
インプット収集
例えば、サーベイ、ご意見箱、個別の報告などから問題の存在を確認するヒントとなる情報を得ます。
ここは、プログラミングでいうログ収集やモニタリングの数値確認に相当しそうです。
問題発見
インプットの中から取り扱う問題を選びます。基本的には最も重要度・緊急度の高いものから順に解決するのがよいでしょう。
逆にやたらと並行して一気に何個も解決しようとすると、通常業務に支障がでたり、作業量が増えすぎて結局どれも着地できずに終わるなどしがちです。
問題を付箋(物理、論理問わず)に書き出し、重要度・緊急度のマトリクスに配置し、そこから最初に取り組む問題を選ぶなどすると議論を進めやすいでしょう。
一旦据え置くことになった他の問題は課題管理ツールに登録して残しておきます。
問題の存在確認
最初に取り組む問題を選んだら、その問題が本当に存在するのかを確認するためにより詳細な情報を収集します。
当事者を含む関係者による対話や、1on1、追加アンケートなど複合的に実施するとよいでしょう。
この話はプロダクト開発でいうニーズとウォンツの話ににています。
インプット収集の流れで得られた情報はウォンツである場合がよくあります。
- 何が問題でそれをしてほしいのか？
- その背景には具体的にどんな出来事があったのか？
- それは理想状態だとどのようなもので、現状とどんなギャップがあるのか？
などを整理することでニーズを明確にしていきます。
ニーズまで明確化した場合
- 本当に解決が必要な問題だった
- 本当に解決できれば好ましいが、費用対効果的に解決コストが高すぎるので様子見したほうが好ましい問題だった
- 単なる認識齟齬で、特別何かしらの解決は必要なかった
- 実は個々人の好みの範囲の話で、解決が必要な問題ではなかった
などのどれかがわかります。
ここで、解決することが好ましい問題であることが把握できたら、ようやく解決施策の検討に入る準備ができたことになります。
ここは、プログラミングでいうデバッグによるバグの原因調査にあたりそうです。
理想状態と現実状態が把握できているところは、エラー原因をUnitTest化して Expected と Actual を記載できてる状態ですね。
例外
例外として、
- 細かく調べなくても原因が明らかである
- 小さな手間で解決可能
などが明白な場合はここまで細かなプロセスを踏まなくてもよいでしょう。
まとめ
過去の経験と照らし合わせると「問題の存在確認」の段階がないケースが多いと感じています。
情報収集から問題を明確にせず一気に解決策の議論に入ってしまうと、
- 実は解決する必要のない問題に時間を使ってしまう
- 問題が明確ではないので、効果のない解決策を選んでしまう
などになってしまいます。
問題は関係者の中ではっきり解決が必要と認識できる状態まで明確化した上で解決に移りましょう。
