■問題発見の問題
以前の記事
問題解決のための7ステップでも書きましたように、問題を正確に捉え、その根本原因にたどり着ければ後は技術的問題も多いのですが、多くの場合、この問題認識で失敗します。
その理由として考えられるのが、
・あるべき姿が的確に描けない。
・現状の認識力と分析力が低く、正確に把握できていない。
・ギャップの構造を解明することができないため、問題の本質に迫れない。
・実行可能な解決策のみで問題を捉えてしまうため、問題の真相・深層まで対応できず、問題の表面のみの対応となる。
という点。
ここまで、上の3つの理由に対して、
問題認識力を上げるための手法について、私のやっている範囲で説明をして来ました。
もちろん、世の一流コンサルタントといわれるような方は、もっと正確にやられているのでしょうけど、まぁ、現状の自分にはこのくらいが精一杯です。
ただ、そんな自分から見ても問題認識が甘い人が多いということは、まぁ「自分は平均値よりは上かな？」とは多少思ってます(^^)ゞ
特に20代の社員に多いのが、この「問題解決のための7ステップ」が意識になく、「問題がある」→「対策をする」と直結してしまい、「それがビジネスにおけるスピードだ」みたいに誤解していること。
スピードが早い人というのは、これらのプロセスを頭のなかで、あるいは水面下で必死に早回ししているのに、その表面に出た部分だけを真似しようとして失敗する人が多いような気がします。
頭では「準備8割」みたいなことが考えられるのに、いきなり動き始めて、その結果大した効果もなく、対策の対策を繰り返すようなことがおおい。ま、そのために自分たちのような
年寄りがいる、とも言えるのでしょうけど。
■問題認識力は強化できるか？
どうかすると、「彼は頭の構造が違うから…」「自分は行動することが得意だから」と言って思考停止している残念な人を見かけます。
でも、このブログの趣旨は
仕事で自分の価値を高めていくのは能力ではなく技術
です。だから、鍛えられないものは紹介しません。
と、いきなり結論に行ってしまいました(^^;
が、これまでに上げたフレームワークを
理解するのではなく、身に付ける
だけで、これらの力は強化されます。
身に付けるためには、実際にそれを使ってみて、失敗や成功を繰り返して、自然にそれが使えるようになるまで「
やり続ける」ことです。私が知る限り、これ以外に身につける方法はありません。
この連載では、ロジックツリーやフィッシュボーンチャート、UML、TOC思考プロセスなどを紹介しましたが、それら全てに精通する必要はなく、どれかひとつが徹底的に使いこなせればいいです。そのうち、それらは独立したフレームワークではなく、じつはあるパターンに適応した変形にすぎないというのが、ある日突然わかります。
※これは本当にある日突然視界がひらけるような感じを受けます。なかなか表現が難しいですが。
言葉に出来ないですが、「あぁ、そういうことか」と、スルッと腹に落ちるという感じ。
そうすると、その他のやり方も、ちょっとした構文(書き方)を覚えるだけで、大した苦労もなく使えるようになります。
大切なのは
セットアップ → 行動 → 振り返り/フィードバック
をすること。
行動しないのは論外なので、ビジネス書では、よく「巧遅よりも拙速」のように書かれますが、きちんとセットアップの作業をしておくと、フィードバックするべきこともたくさん発見出来ます。これこそが自分を成長させる問題認識力になるのかもしれませんね。
■全ては語れない
ここまで、問題認識のためにはMECEであること、情報を集めることを強調して書いてきたつもりです。
ただ、
すべての情報を集めようとしてはいけない
ことにも触れておきたいと思います。
情報は100%にはなりません。
だから、すべてを集めようとすれば、あなたの会社人生をかけてやるはめになります。
ですので、まず大きな情報だけ集まったと感じたら、そこで情報収集は一旦終了してください。
次にやるべき作業は、
仮説です。
その原因はこうではないか？
という仮説を立てて、その仮説に対して、肯定する現象、否定する現象に絞って情報収集を再開することです。
これも複数の仮設を立てて、今ある情報だけでその仮説の確からしさを判断し、それでもたらないと思ったところだけに絞って情報収集を行います。
もし、情報が取りにくいものであれば、ちょっとだけその仮説に対して結果が変わるような小さな変更をしてみて、その結果をみてみる事です。それによって変化がいい方向に現れたのを見極めて、今度は自信を持って対策をとることができます。
■再び見える化へ
ちょっと話は飛んでしまいますが、見える化をして、問題を発見できて、課題をみつけ、対策までできたとして、もし、問題の再発の可能性が残るのであれば、せっかく作った見える化の仕組みを徹底的に活用しましょう。
数値でその問題の状況がわかるのであれば、自動的にその数値を収集するような仕組みを作って、その数値が特定の値になったらアラームが出るように考えましょう。それが、「再発防止のための
監視」です。
製造であれば、不良が出るたびに、PCで結果を入力するように(できたら自動で記録できるようにするのがいいですが)しておいて、それを自動集計して、一定値を上回ったらアラームを上げるようにしておきます。
そうすると、あとは人間は忘れていて放置しておいても、一定値をこえるような状態(問題状態)になれば、コンピュータが教えに来てくれます。
普段見なくていい時には隠れていて、必要なときには目立つようになる。そういう仕組みを作っておくのも見える化ですね。
■関連する記事
前の会議が早く終わった、電車が来るまでちょっと時間があるなどのときにどんなことをしていますか？このブログに訪問してくださった方なら、おそらく「時間管理」をきちんとして、仕事においてより効率よく高い成果を出したいと考えて見えることでしょう。ところが、スキマ時間によく使うスマホなどにアクセスロガーを入れてみて、実際にどんなことをしているかと測定してみると、愕然とします。「2ちゃんねる」などのネット掲示板を眺めているぼんやり動画を..
私の会社で聞いてみたら、知らない人が結構多かったので、もしかしたら役に立つかも…ということで、本日はスイムレーンチャートをご紹介します。スイムレーンチャートとはビジネスの世界では、複数のパーティシパント（人、部門、情報システム）が複雑に絡み合ってビジネスプロセスを進行させていく。このようなビジネスプロセスを表す時に、誰がアクティビティを処理するのか直感的に理解できるように、パーティシパントごとにアクティ..
UMLって御存知ですか？またいつものようにWikipediaから引用統一モデリング言語（とういつモデリングげんご、UML、英: Unified Modeling Language）はソフトウェア工学におけるオブジェクトモデリングのために標準化した仕様記述言語であり、グラフィカルな記述で抽象化したシステムのモデル（UMLモデル）を生成する汎用モデリング言語である。最初期の版はラショナルにおいて、グラディ・ブーチ、イヴ..
もう金曜日ですね。ようやく今週の本題にたどり着きました。問題発見の問題以前の記事問題解決のための7ステップでも書きましたように、問題を正確に捉え、その根本原因にたどり着ければ後は技術的問題も多いのですが、多くの場合、この問題認識で失敗します。その理由として考えられるのが、・あるべき姿が的確に描けない。・現状の認識力と分析力が低く、正確に把握できていない。・ギャップの構造を解明することができないため、問題の本質に迫れない..
現状分析の手順現状分析の手順は以前の記事で書きました。それを少し引用します。問題解決の7ステップ問題解決他のための7ステップはまず大きく2つのステップに分けられます。問題認識ステージ課題対策ステージの２つ。さらに問題認識には2つのステップがあって問題設定ステップ問題把握ステップにわかれます。また、課題対策は5つのステップ..
本日は、問題解決の手法の3回目。第2回めで「見える化」についてお送りしましたが、実は問題解決のプロセスを時系列で並べると、こちらが先です。ただ、今回問題認識の手法というテーマで書いていますので、話の流れの都合上、問題を顕在化することを先に持ってきてしまいました。ですので、この記事を読んでもう一度前回の「見える化」に戻って読み返していただけると、この記事の内容が理解しやすいかもしれません。現状分析手法現状分析はパターンがあります。..
■同じテーマの記事
仕事は、大抵の場合、誰かから指示されて、その結果をまた誰かに渡すことで成り立ってます。指示するときや、指示を受けた時にキーポイントになるのは、QQCDR だそうです。仕事の五要素QQCDR私は「QQCDR」という仕事の五要素というやり方を頻繁に使います。それは、Quality(クオリティ・質）Quantity(クオンティティ・量）Cost(コスト)Deadline(..
