問題解決の第一歩

ＫＰＴ（keep-problem-try）などを利用してふりかえりする中で、プロジェクト内に、Problem（問題点）が出てきた場合、

　問題点をあげる → 原因を考える → 改善策を考える → …

というステップを踏むことがあると思います。プログラムのバグを発見した場合と基本的な手順は同じですよね。

まぁ、通常のバグを発見した場合と、振り返りでProblemを見出した場合、
「なぜ同じ流れになるか？」と言うと、実はこの２つだけでなく、基本的に、

　世の中の『問題』に対する取扱い方法は、すべて同じ

だからです。これば、トラブルが起きた時の対応でも同じです。友達とケンカした時も同じでしょうし、交通事故を起こしたときでも同じです。

もっと言えば、「問題」も「課題」も同じ「お題」をもらって、そのお題に沿って何かを解決しなければならないのはまったく同じですから、「問題解決」能力が高ければ高いほど、「課題解決」能力も高いと言うことになります。

以前、プロジェクトでの問題解決について流れを説明しましたが、そこでも説明しましたように、「解決」する仕組みはまったく同じで、その対象が「問題」か「課題」かの違いでしかないのです。

しかし、この「問題点をあげる」というステップにおいて、私が第三者としてよくよく観察していると、以下をすっ飛ばしてあげてしまっていることがあるなぁと思う点が散見されます。

　「なぜ、それを問題だと思ってるか？」
　「問題となるまでの具体的な過程は洗い出せているのか？」
　「それによって、誰に、どのような困ったことが起きた（起きる）か？」
　「そのインパクトってどのくらいの大きさか？」

つまり、感情や主観的意見を一切含まない、現状…純然たる事実の情報をしっかりと洗い出し、整理すると言う工程です。これは、実は『問題解決管理』や『変更依頼管理』と言ったプロセスでも、まったく同じことが求められていますが、実際にはあまり現場で行われていません。

その背景には、メンバー、あるいは社員の中に「責任を取りたくない」「自分のせいにはしたくない」という想いがあるのかもしれませんね。そのうえで他責にするわけにもいかないから、問題点のすり替えや、あやふやな情報でごまかして、目先の問題だけをなんとか解決しようとする…。

済んだことを、あえて生し返したくないから「事なかれ」主義に陥ってしまい、「正しい分析」に基づく「正しい再発防止」ができなくなって、また似たような問題が再発する…と言う、負のスパイラルに陥っているのです。

おそらく、いかなる業界の、いかなる企業、いかなる組織でも多かれ少なかれ、こうした問題を抱えているのではないでしょうか。

ですが、この「事実情報」を洗い出す仕組みは、"しなければならない"業界や仕事、シチュエーションはごまんとありますが、逆に"しなくてもいい"業界や仕事、シチュエーションと言うのは、数えるほどしかない（ひょっとすると存在しない）もので、知っておけば、様々な業界、様々な職種、様々なシーンで利用できます。

たとえば、子供のケンカ仲裁でも使えます。
もちろん、大人の仲裁…たとえば夫婦喧嘩などでも使えます。

と言うことは、民事・刑事に限らず裁判などでも同じことになります。
経営上の舵取りでも同じです。

世の中における、問題に対する画一的な流れなのです。

さらに、多くの人はある活動において、終了時に「では、みなさん、今回の活動において Problem（問題点）を出しましょう」と言わると、何か１つでも出さなくてはならないと思い込んでしまい、「これが問題だろう」と（悪意なく）決めつけてしまって、言葉足らずになることがあります。

たとえば、ソフトウェア開発において、一般的なアジャイル開発手法で行われるＫＰＴの場合、週１程度の頻度で、くだらない進捗報告会の代わりに行われたりしますが、そんな中で、なんとなく曖昧な

　「今週やることを絞れていなかった」

というふうにProblemに書き込むよりは、

　「（原因）今週やることを整理しきれていなかった。
　　（結果）作成順序を誤り、完全な成果物にならず、
　　　　　　レビューしてもらうタイミングが遅くなった。
　　（懸念）スケジュールに遅延が出る。
　　（影響）スムーズに進行できず、スイッチングコストも高くて
　　　　　　大きな心的ストレスとなった。」

少し長くなりますが、こうした書き方にするとより因果関係や未来のリスクがハッキリします。付箋何枚か分けて書けば問題ありません。重要なのは、短文報告で全てを理解した気になるだけの自己満足なマネジメントをすることよりも、きちんと整理されて、未来予測が可能になり、どう対策すればいいかが検討できる状態にすることです。

その意味では、必ずしも定量的でなくてもいいでしょうし、感覚的なものでもかまいません。どんな些細なものであっても、放置し続けていれば、いずれ大きな問題となる可能性があるからです。

このあたりに対する具体的な情報がないと、次の「原因を考える」「改善策を考える」のステップにおいて、

　・「問題は本質的な設定となっているのか？」
　　「解決する価値が他の問題と相対的にどうなのか？」
　　　という議論や判断ができない
　・「問題」と言う認識が共有できず、共感してもらえない

ということが起きます。ただの報告会になってしまい、参加した全員の意欲を削ぎ、且つガントチャート上に存在しない時間を消費させ、スケジュールを圧迫させるだけで、結局メンバー全員に残業を強制するだけのマネジメントになってしまいます。

もし自分以外がこういった形で問題点をだしていたら、上記の問いをそのまましてみましょう。そのときには、責めるような雰囲気にならないように、「念のため、誤解が無いか確認したいんですけど…」みたいな枕詞をつけると良いと思います。

問題解決管理や変更依頼管理の委員会でもあれば、こうしたプロセスにしておくと非常にスムーズに進行が可能になるでしょう。ドット投票やペイオフマトリクスなどを用いれば、問題点にも重みがつけられ、お互いに問題そのものに対する共通の意識も芽生えるようになります。

ドット投票

ペイオフマトリクス

ドット投票は、ブレインストーミングなどの結果をすばやく優先順位付けしたり、重み付けをしたい場合などに用いられる方法論です。リーダー一人の裁量では決められない場合などに、迅速にアイデアの優先順位をつけることができます。

ペイオフマトリクスは、縦軸に「成果」、横軸に「難易度」や「コスト(かかる時間等)」をとり、マトリクス上に、複数の案をマッピングして、「効果＝高」×「難易度＝易」の象限にある案を優先的に検討します。「ペイオフ（Payoff）」には様々な意味がありますが、ここでは「対効果」「対結果」、「マトリックス（matrix）は「行列」の意味と捉えてください。

どの方式にもいえることですが、重要なのは、客観的に評価できるという点です。

もしも、自分の中にＡ案とＢ案が浮かんできたとします。でも、他人からはＣ案やＤ案が出てきましたが、今まで自分では思いつきもしなかった方法だったとします。このような時、得てして個人的に優秀な人ほど、自分の過去に成功体験イメージが強い案以外を否定しかねません。自分自身の中の蓄積されたデータの中には、前例がないからです。

このような時、『切り口』となるテーマ次第ではありますが、冷静に客観視するためには、こうしたマトリクスを用いた方がいいでしょう。

たとえば、「新商品開発」などの場合は、ターゲット層や規模、成熟度などの"外部市場"と、自社の持つスキルや技術、割り当てられる人材などの"内部環境"をかけ合わせてみるといいかもしれません。

企業運営や事業方針などは、SWOTなどを使うことがありますね。コンサルティングの方以外では、あまり使いこなせているイメージがありませんが、

私はたまたまQMSやISMSなど、国際規格のマネジメントシステムの構築や運営をしていたので、こうした考え方はスッと馴染んでいます（国際規格のマネジメントシステムでは、基本的に６章でこうした外部/内部の分析を定義されているのです）。

こうしたマトリクスは、視覚的にも理解しやすくなるため、相手への説得手段としても、大いに活躍できます。

　・頭の中を整理しやすい
　・冷静に客観視できる
　・視覚効果が高い
　・説得や交渉にも有利になりやすい

と言った効果を考えると、問題解決のためのツールとして大いに活用するべきではないでしょうか。