もう金曜日ですね。ようやく今週の本題にたどり着きました。


■問題発見の問題


以前の記事問題解決のための7ステップでも書きましたように、問題を正確に捉え、その根本原因にたどり着ければ後は技術的問題も多いのですが、多くの場合、この問題認識で失敗します。

その理由として考えられるのが、

  ・あるべき姿が的確に描けない。
  ・現状の認識力と分析力が低く、正確に把握できていない。
  ・ギャップの構造を解明することができないため、問題の本質に迫れない。
  ・実行可能な解決策のみで問題を捉えてしまうため、問題の真相・深層まで対応できず、問題の表面のみの対応となる。

という点。

ここまで、上の3つの理由に対して、問題認識力を上げるための手法について、私のやっている範囲で説明をして来ました。
もちろん、世の一流コンサルタントといわれるような方は、もっと正確にやられているのでしょうけど、まぁ、現状の自分にはこのくらいが精一杯です。

ただ、そんな自分から見ても問題認識が甘い人が多いということは、まぁ「自分は平均値よりは上かな?」とは多少思ってます(^^)ゞ

特に20代の社員に多いのが、この「問題解決のための7ステップ」が意識になく、「問題がある」→「対策をする」と直結してしまい、「それがビジネスにおけるスピードだ」みたいに誤解していること。
スピードが早い人というのは、これらのプロセスを頭のなかで、あるいは水面下で必死に早回ししているのに、その表面に出た部分だけを真似しようとして失敗する人が多いような気がします。

頭では「準備8割」みたいなことが考えられるのに、いきなり動き始めて、その結果大した効果もなく、対策の対策を繰り返すようなことがおおい。ま、そのために自分たちのような年寄りがいる、とも言えるのでしょうけど。


■問題認識力は強化できるか?


どうかすると、「彼は頭の構造が違うから…」「自分は行動することが得意だから」と言って思考停止している残念な人を見かけます。
でも、このブログの趣旨は

 仕事で自分の価値を高めていくのは能力ではなく技術

です。だから、鍛えられないものは紹介しません。

と、いきなり結論に行ってしまいました(^^;
が、これまでに上げたフレームワークを

 理解するのではなく、身に付ける

だけで、これらの力は強化されます。

身に付けるためには、実際にそれを使ってみて、失敗や成功を繰り返して、自然にそれが使えるようになるまで「やり続ける」ことです。私が知る限り、これ以外に身につける方法はありません。

この連載では、ロジックツリーやフィッシュボーンチャート、UML、TOC思考プロセスなどを紹介しましたが、それら全てに精通する必要はなく、どれかひとつが徹底的に使いこなせればいいです。そのうち、それらは独立したフレームワークではなく、じつはあるパターンに適応した変形にすぎないというのが、ある日突然わかります。
※これは本当にある日突然視界がひらけるような感じを受けます。なかなか表現が難しいですが。
 言葉に出来ないですが、「あぁ、そういうことか」と、スルッと腹に落ちるという感じ。
 そうすると、その他のやり方も、ちょっとした構文(書き方)を覚えるだけで、大した苦労もなく使えるようになります。

大切なのは

    セットアップ → 行動 → 振り返り/フィードバック

をすること。
行動しないのは論外なので、ビジネス書では、よく「巧遅よりも拙速」のように書かれますが、きちんとセットアップの作業をしておくと、フィードバックするべきこともたくさん発見出来ます。これこそが自分を成長させる問題認識力になるのかもしれませんね。


■全ては語れない


ここまで、問題認識のためにはMECEであること、情報を集めることを強調して書いてきたつもりです。
ただ、

 すべての情報を集めようとしてはいけない

ことにも触れておきたいと思います。

情報は100%にはなりません。
だから、すべてを集めようとすれば、あなたの会社人生をかけてやるはめになります。

ですので、まず大きな情報だけ集まったと感じたら、そこで情報収集は一旦終了してください。
次にやるべき作業は、仮説です。

 その原因はこうではないか?

という仮説を立てて、その仮説に対して、肯定する現象、否定する現象に絞って情報収集を再開することです。

これも複数の仮設を立てて、今ある情報だけでその仮説の確からしさを判断し、それでもたらないと思ったところだけに絞って情報収集を行います。

もし、情報が取りにくいものであれば、ちょっとだけその仮説に対して結果が変わるような小さな変更をしてみて、その結果をみてみる事です。それによって変化がいい方向に現れたのを見極めて、今度は自信を持って対策をとることができます。

■再び見える化へ


ちょっと話は飛んでしまいますが、見える化をして、問題を発見できて、課題をみつけ、対策までできたとして、もし、問題の再発の可能性が残るのであれば、せっかく作った見える化の仕組みを徹底的に活用しましょう。

数値でその問題の状況がわかるのであれば、自動的にその数値を収集するような仕組みを作って、その数値が特定の値になったらアラームが出るように考えましょう。それが、「再発防止のための監視」です。

製造であれば、不良が出るたびに、PCで結果を入力するように(できたら自動で記録できるようにするのがいいですが)しておいて、それを自動集計して、一定値を上回ったらアラームを上げるようにしておきます。
そうすると、あとは人間は忘れていて放置しておいても、一定値をこえるような状態(問題状態)になれば、コンピュータが教えに来てくれます。

普段見なくていい時には隠れていて、必要なときには目立つようになる。そういう仕組みを作っておくのも見える化ですね。

■関連する記事

リンクリストを活用する

私は「リスト」をいろいろ作ります。リストのいいところは、なんでもかんでも一覧で見えてしまうこと。たとえば、何か買い物に行くのであれば、メモ帳に「買うものリスト」を作ってますし、OneDriveには「ほしいものリスト」、Outlookには、「タスクリスト」や「ToDoリスト」「やらないことリスト」などなど。本日はこのリストの中でちょっと変わり種。リンクリストのご紹介リンクリストリンクリストは、単体でリストとして存在し..

タスクの多重管理

仕事は多次元あなたは仕事の管理をどうやってやっているでしょうか?GTD(Getting Things Done)などの「仕事」や「やるべきこと」の管理ルールはあるものの、実際にタスクを作ってみると「管理するのはは難しい」と感じてました。ちょっと用語が難しいので、以下、GTDの規則に従って複数の活動をまとめたもの=プロジェクト1回の作業で終わるもの=タスクと呼ぶことにします。例えば、新規事業を起こすというプロジェクトがあったとします。こ..

良かったことほど分析する

個人であれ、組織であれ、重要なことはおきたことから教訓を得て教訓から次の行動を帰ることです。それをしなかったら、おそらく成功はしないでしょうし、成長もしないでしょう。そういう意味で、振り返りはとても大切だと思っているのですが、どうも「振り返り会」をすると、ほぼ「反省会」になっちゃう。失敗したこと、うまく行かなかったことはもちろん、同じ失敗を繰り返さないように工夫しないといけないのは確かですが、反省ばかりしていると、そのうち..

問題認識の手法5―問題を発見する

もう金曜日ですね。ようやく今週の本題にたどり着きました。問題発見の問題以前の記事問題解決のための7ステップでも書きましたように、問題を正確に捉え、その根本原因にたどり着ければ後は技術的問題も多いのですが、多くの場合、この問題認識で失敗します。その理由として考えられるのが、・あるべき姿が的確に描けない。・現状の認識力と分析力が低く、正確に把握できていない。・ギャップの構造を解明することができないため、問題の本質に迫れない。・実行可能な解決策..

問題解決の7ステップ2

昨日の記事で問題が発生してから解決するまで、大きく7つのステップがあり、大きく問題認識ステージ課題対策ステージに分けられると説明しました。本日はこの第2のステージ課題対策ステージについて説明します。ただ、ちょっと長文になってしまったので、このステージも2回に分けてお送りします。課題対策ステージ課題対策ステージは以下の5つにわかれました。課題設定ステップ課題解決ステップ総合評価ステップ解決実行ステップ結果評価ステップ本日はこの内..

リストの活用方法

おそらく、皆さん、いろいろなツールでタスクリストを管理していると思います。『あなたはなぜチェックリストを使わないのか』という本に、発展途上国で医者に対して手術のためにチェックリストを導入したら、医療事故(手術をしたことによる合併症の発症)が半減したという報告が書かれていました。この他にも、飛行機は発着の前後にあらゆる階層の人がチェックリストを使って作業のチェックをしているのは有名ですね。でも実はリストには弊害があって..

■同じテーマの記事

問題認識の手法4―現状分析2

現状分析の手順現状分析の手順は以前の記事で書きました。それを少し引用します。問題解決の7ステップ問題解決他のための7ステップはまず大きく2つのステップに分けられます。問題認識ステージ課題対策ステージの2つ。さらに問題認識には2つのステップがあって問題設定ステップ問題把握ステップにわかれます。また、課題対策は5つのステップにわかれます。課題設定ステップ課題解決ステップ総合評..