仕事の目標設定によくある3つの誤解　上司の“嫌な突っ込み”が教えてくれた課題解決の本質 [2/2]

HOWツリーの落とし穴に注意

じゃあ、課題がわかって、目標が定まったら、具体的に解決策を考える。

「HOWツリー」は超有名なツールなのかな。研修とかではよく扱っていて、ロジックツリーとかHOWツリーにまとめます。課題があって、解決策を書いて、評価基準を書く。まぁ、あるよねと。

ただ、これ、終盤なんですが、ここでズコッてこける場合があります。HOWツリーは要注意です。失敗例その1「課題ではなく『テーマ』を書いてしまう」。

せっかく課題に取り組むのに、HOWツリーに売上アップとか利益アップみたいなテーマを書いちゃう。そうすると、アイデアは360度、何でもよくなってしまう。そういう話じゃないですよね。左に書くのは課題です。

また「解決策が一択」。「これです」みたいな。「いや、ほか、ないの？」っていう気になります。そして「評価基準が曖昧」。点数付けってよく見ますよね。「これ、5点、3点、1点。これ、なんでこれ、3点なの？　3点と4点の違いは？」みたいな。「高松さんがこれを5点に持っていきたいだけじゃないの？　これ、解決策2でやりたいだけでしょう？」という。

これだとなかなか会社の稟議が通らない。でも、これ以外にやり方があるのか。ちょっと工夫したいと思います。

点数評価には説得力が必要

（スライドを示して）具体的なHOWツリーはこんなふうにできます。まぁ、できるんだけど、先ほど申し上げたとおり、まずは点数ですね。「これ、なんでこれ4点なの？」とか、「結局、合計点が高いのがいいの？」って言われると、「まぁ、そうですね」って、それ以上、説得力は上げられない。

つまり、やっぱり現実的には解決策を点数評価する難しさがあると思います。「絶対ダメだ」と言うつもりはありませんが、難しさは認めなきゃいけません。

その1「期待効果を測定できるのか」。「どれくらいの効果があるんですか？」とか、「コスト削減、どれくらいできるんですか？」とか、「売上はあとどれくらいできるんですか？」とか。やったことがないのに証明できないよねという。

そして下にいきましょう。「制約条件を満たしていればいいんじゃないか？」。「コスト」「時間」と書いていますが、コストは低いほうがいい、高いほうが悪い。時間はかからないほうがいい、かかるとダメ。「いや、そうだけど、それだけで評価していいんだっけ？」。

つまり、コストや時間がかかったとしても、効果がめっちゃでかければいいじゃないですか。

制約条件。「コストはいくら以上は使っちゃダメだよ」とか、「時間はこれくらい使っちゃダメだよ」というのの中であれば、費用対効果とかで見るべきじゃないか。

結果評価から条件チェックへの転換

そして、その3「合計点が高い施策が一番良いのか？」というところで、こんなのはもう、「もう1個増やして、こっちを1位にしようかな？」みたいに、さじ加減でいくらでもできちゃうよねという。それはなかなか稟議が通りません。

じゃあ、どうするか。結果評価ではなく、条件チェックという方法もあるんじゃないかなと（思います）。つまり今までは右側、「解決策はどんな成果を出すのかな？」「どういう結果が期待できるか？」で評価しようとしていました。

そうじゃなくて、左側、「解決策は成果を出す条件を満たしているだろうか？」。つまり、見えていない問題を発見するところで、「こういう課題に取り組んだらここまでいけるぞ」って（いう道筋は）、もう見えているわけです。

だから目標を達成するためには、「解決策はどういう条件を満たしているか」という条件をチェックして、「その条件を満たしているんだったら、もうゴーでいいんじゃないの？」という（決め方もできます）。

つまり、解決策には満たすべき条件がある。現状があって、目標、課題がある。こういう課題に取り組んだらこの目標にいけるっていうのは、仮定ではありますが計算しているわけです。今は解決策を考えている。だからその解決策を考えるには、ちゃんと現状から目標にいくための条件を満たしているかをチェックする。
　

より良い未来を作るための条件は何か？　

さらに目的との合致。「うちの会社は環境を大切にしているよ」っていう会社が環境を破壊する施策はしないわけです。また、制約条件。「ヒト・モノ・カネ・データ」。ないものは使えません。

解決策をいろいろ考えるんですが、結局考えた後にどう説得するかでつまずくところが多い。じゃあ、どうやって説得するか。

解決策には満たすべき条件が3つあります。「目標を達成し、成果を出す」。つまり、その目標を達成する成果を出すための条件はこういうことだよ、課題に取り組んだらここまでいけるよと計算しています。自分で条件を明文化するんです。そして「目的と合致する」。そして「制約条件を満たす」というかたちで条件をチェックする。

条件が全部満たなくて、ちょっとここは怪しいなっていうところがあれば実験をすればいいだけです。もちろんやらないとわからないこともあるわけなんですが、一部実験することによってわかることもあるでしょう。

今まではやってもいないのに「期待していいか？」というかたちで、結果を評価するから無理があった。

だけど、目標を自ら定めているわけなので、「そこにいくための条件は何か？」と考えればいいんじゃないでしょうか。

というところで、みなさま、お付き合いいただきありがとうございます。今回の本では、見えていない問題を発見して解決するプロセスのエッセンスをお伝えいたしました。

本書ではより詳細を書いていますし、ケーススタディとして、ある会社の見えていない問題を発見するプロセスも書いています。

もちろん見えていない問題だけじゃなくて、見えている問題の解決も大事なので、もう欲張りまして、前半は見えている問題の解決を書きました。後半、メインのパートでは、見えていない問題を発見し解決するプロセスについてまとめさせていただきました。

というわけで、なんとか時間内に入ったという感じでございますが、みなさんのお役に立っていれば幸いでございます。