なぜあなたの考えた施策はしょぼいのか？あるいは『課題⇒施策』の罠

先日、ゴールやコンセプトなど抽象的なことを考える際には、トップダウンアプローチではなく、くさび打ち込み方式でしか考えられないのでは？という話を書いた。

くさび打ち込み方式で本質を探る方法、あるいは目的から議論しない訳

めちゃくちゃ重要だがややこしすぎる話なので、理解してもらえるか心配だった。だが、意外と反響があった。
・無理矢理トップダウンで考えていたので、反省してます
・自分も実はこういうやり方でやっています
・とはいえ、めちゃくちゃ難しい・・
などなど。
「ピラミッドの上（ゴールや戦略）から下（方針や戦術）へ考えるよね」という、世の中の常識に真っ向から反する意見であり、かつ直感にも反するので、この反応は結構嬉しかった。
気を良くして、同じように15年くらい前から社内でのみ提唱している、ややこしい話をもう一つ紹介したい。それは課題と施策を考える順番についての話だ。



世の中では「課題⇒施策」という順で考えよ、と言われている。

課題：入力ミスが多い
↓
施策：チェックリストを活用しよう
みたいな感じだ。
まあ、極めて常識的な考え方だ。


だがこれだとうまくいかない。
やってみると分かるのだが、課題に1:1対応した施策というのは、みみっちい施策でしかない。


★「課題⇒施策」のだめな例
前に同僚がお客さんに提案しようとしていた施策案を例に説明しよう。

課題：やたらと会議が多く、営業活動に専念できない
↓
施策：会議をリストアップし、1つ1つ要不要を検討しよう

一見合理的だ。素直に考えたらこうなりますよね。
で、1つ1つの会議を検討した。
そうすると、それぞれ、それなりの目的があることが分かった。
・全社営業戦略の進捗チェックのための会議
・グループ内で今抱えている案件を整理し、優先順位を決める会議
・製造部門と需要予測を検討する会議
などなど。
結果、なんと、「30個ある会議のうち、2個を廃止し、5個を改善できることが分かりました！」という、華々しい成果が得られた。。。

この時は「おいコラ、ちょっと待て」と直前で止めたので事なきを得た。
でも、他のコンサルティング会社が作った資料で、似たような施策案をいくつも見たことがある。

一歩引いて見れば、クソ施策なことは分かるはずなのだ。でもこういう人々は「課題を挙げ、それに対応する施策を考える」という正しい思考プロセスを経たのだから、これでいいはずでしょ、と思っている。だって合理的だから。
あのね、プロセスが正しいかどうかはどうでもいいのですよ。でも「大騒ぎして、2/30個を廃止」という結論は、確実に正しくないのですよ。
先に上げた「入力ミスが多いからチェックリストを活用しよう」だって、みみっちい施策だ。こうやってチェックリストだらけになった職場がたくさんある。効率は低下し、もちろんミスはたいして減らない。

もう一度書く。
課題に1:1対応した施策というのは、みみっちい施策でしかない。

日本企業の会社員は真面目だ。
だから自分の身の回りの課題（非効率さ）には気づくし、1部署で対処できるような課題はカイゼン済みなことが多い。
つまりいざ「業務改革やるぜ」と改めて調査した時に見つかった課題は、何らかの理由で一部署だけでは対処できないような事情がある。または本質的には課題ではなかったり。
どちらにせよ「課題に1:1対応した施策を考えよう」では、ろくな施策は出てこない。
もしお高いフィーで雇っているコンサルタントがこんな提案しかしてこなかったら、契約打ち切りを真剣に考えたほうがいいですよ・・。


★ではどうすればよかったか？
良い施策を考えるためには、こういう思考プロセスをたどる。

a)現状を見る
b)施策案やら課題候補やら仮説などをとにかくリストアップする
c)全部アタマに入れる
d)「要するにこういう状況ですね」と口に出す
e)それらのいくつかが一気に解決されているToBe像を考える
f)ToBe像に移行するための施策を立案する
g)その施策に対応するいくつかの課題を束ね、「主要課題」と名付ける
h)「こういう主要課題があります。それを解決するための施策がコレです」とプレゼンする

こんな感じだ。
まずd)が結構難しい。複雑な現実を構造化して捉える能力が必要となる。
e)については具体例を2つあげよう。

「入力ミスが多い」を例にすると、

・入力ミスが多い
・そもそも、やたらいろんな箇所でデータ入力を繰り返していること自体がおかしいのでは（仮説）
・入力がやたら必要なのは、未だにFAXや紙の伝票が行き来しているから（構造理解）
・なのでデータが発生した時点で1回だけ入力して、そのデータを流せばいい（ToBe像）
・当事者は中身を理解しているから、一番ミスが少ない（例えば本人は自分の名前を滅多に間違えない）
・あれ、こうすると仕事をデジタルにトラッキングできるようになり、ガバナンス不足という課題への対処にもなるぞ（ひと粒で二度美味しい）
みたいなことになる。

「会議が多い」を例にすると、

・多種多様な会議がたくさん開催されている
・意思決定やアイディア創出ではなく、単なる情報提供の会議ばかり（構造理解）
・そもそも、毎回会議で情報を共有せざるを得ないのがおかしいのでは（仮説）
・同僚が抱えている案件を、知りたい人が覗きにいけたほうがいい（ToBe像の種）
・そのためには案件情報、特にステータスを一元管理すべき（ToBe像）
・あれ、こうすると「個人商店的営業で、チームワークが発揮できていない」という
課題への施策にもなるぞ（ひと粒で二度美味しい）
みたいなことになる。

言うまでもなく、このe)のステップ、あるべき姿（ToBe像）を考える所が最大の難所だ。
（eさえあれば、次のfは比較的簡単だ）
構造理解をもとに、色々な課題が解決されたビジョンをポンと思い浮かべなければならない。
だが、難しいのは当然だ。
上でも書いたように、現場でお仕事している人々が、自分の手の届く範囲で解決できるような課題であれば、とっくに解決している。変革プロジェクトでは残された課題に挑むのだから、難しいに決まっている。
「いくつかの課題を一気に解決するものを、アイディアと呼ぶ」というのはマリオを作った宮本さんの言葉だが、変革プロジェクトでも同じことが当てはまる。


本当はd)とe)についてはもう少し丁寧に説明すべきだ。だが10年ほど前に、d)とe)についての社内向けトレーニングを作ったら4時間くらいかかるトレーニングになってしまった。
だからこれの詳細なコツについては、このブログに記すには余白が狭すぎる。（いつかどこかに書くかもしれない）
でも2つ例を挙げたので、なんとなく目指す方向性は理解してもらえたのではないか。


★「いきなり施策」が受け入れられない人々
「現状を分析したところ、こんな施策を打てばいいのではないでしょうか？」と僕らが言い出すと、困惑するお客さんが多い。「どっから出てきたんですか？」と。
「挙がっていた課題はちゃんと解決できるのですか？」とかも。
酷いケースでは、緻密なアタマの方から「論理的じゃない」と怒られたりする。
それほどまでに「まず課題があり、それを解決するための施策を考えよう」という思考プロセスを叩き込まれている。
※これとほぼ同じ文章を前々回のブログにも書きました。

なので、皆さんが受け入れやすいように、
f)ToBe像に移行するための施策を立案する
g)その施策に対応するいくつかの課題を束ね、「主要課題」と名付ける
h)「こういう主要課題があります。それを解決するための施策がコレです」とプレゼンする
こういうステップを踏む。丁寧にやるときは、

「こういう主要課題があります」を現状調査フェーズのまとめの役員報告でプレゼンし、
「それを解決するための施策がコレです」を将来構想フェーズの役員報告でプレゼンする。

そうすると「課題⇒施策」派の方々も安心して聞ける。
実際に施策を考えた人は「色々な現状⇒施策⇒主要課題」という感じなのだが。


★補足
僕が書いた本（主に「業務改革の教科書」と「システムを作らせる技術」）では、あたかも「課題⇒施策」という感じに書かれている。
「施策⇒主要課題」というのは、本に書くにはややこしすぎて、読者を混乱させると判断したためだ。
だが僕らプロのコンサルタントはこのあたりをちゃんと理解しておく必要があるので、社内の研修ではこのブログに書いたようなことをずっと教えている。

★補足2

********関連過去ブログ
地に足のついた働き方改革、あるいはアイディアとは複数の課題を同時に解決すること