- 「対案無き批判は禁止」はもっともらしく聞こえるが・・・
- そもそもA案とB案は違う
- A案とB案の「よりましな方」を進めるのか?
- 事前に把握できる落とし穴は塞いでおく
- 批判はしっかり吐き出させた方が実はうまくいく
- PDCAサイクルをしっかりと
それでダメになった例を何度も見てるけどなぁ… https://t.co/dRGB7Oe2Pj
— ヘッドハンティングされた元公務員 むらた部長CEO(つぶやきツッコミ部長) (@muratamanager) 2021年1月11日
Twitter上で議論をする気は全くないのでやんわりと。
「対案無き批判は禁止」はもっともらしく聞こえるが・・・
もっともらしく聞こえるかもしれませんが、学級会レベルのナンセンスな話だと思っています。
提案した者が、ダメ出しを食らうことを甘受せず、感情的に「だったらテメェ、もっといい案だせよ!」と言っているに過ぎません。
これを言いだす提案者は自らの器の小ささを自覚すべきですね。
では、なぜ、「対案無き批判は禁止」を禁止した方がよいのか説明します。
そもそもA案とB案は違う
「対案無き批判は禁止」というルールが設定されると、A案に問題があると考えたものはわざわざB案を用意しなければなりません。
もちろん、A案とB案は別物なので、B案があってもなくてもA案の問題点が解消するわけではありません。A案を遂行するにあたりB案を用意するというのは全く意味がありません。
A案とB案の「よりましな方」を進めるのか?
A案の良し悪しを議論するはずが、B案が出現することによって、「A案とB案のどちらを選択するか」という議論に陥ってしまうことがあります。(心理学でいうところの「ダブルバインド」)
そもそもA案とB案は別物ですから、A案が良ければ進める、B案も良ければ進める、逆にA案がダメならやめる、B案もダメならやめる、となるべきです。
事前に把握できる落とし穴は塞いでおく
当初の議論で批判を封じ込めてしまうと、事前に把握できる問題点を見失うことになります。計画段階で分かっている問題点は実行する前に手を打っておく方が得策です。
「クレーマーこそ最大の理解者」
一番危険な人物は、プロジェクトの実行者でありながら無関心な者です。
取り返しのつかないミスを犯してしまうことにないように・・・。
批判はしっかり吐き出させた方が実はうまくいく
実行する前に批判を吐き出させた方が実はうまくいきます。批判をため込んだまま実行に移した場合、プロジェクトの実行途中につまずいた段階で批判が噴出したり、協力してもらうはずの人物の協力が得られなかったりと、あとから阻害要因になることが多々あります。
問題点は吐き出させてクリアにしておく。事前に手を打つ、あるいは責任者が「そういうリスクも理解したうえで進める」と明確にする、など、プロジェクト全体の共通課題と認識することで、実行に移した後の批判を封じ込めることが可能です。
PDCAサイクルをしっかりと
特に行政などへの批判で「PDCAのPばかり」と計画ばかりで実行にすすまない、というものがありますが、実際に行政の失敗例を見ると、計画段階でお粗末なものや、トップの思い付きを無理に実行したトップダウン型の失敗例が多いのです。
許容できる範囲の失敗で収めてPDCAを高速化も大事ですが、ちょっと考えればうまくいかないのが分かっているのに実行に移すのは愚の骨頂。やはり、批判にも耳を傾けてさらに計画に磨きをかけることで、より大きな成果が期待できるようになると思います。