部門横断的なマネージャーとして仕事をしていると、なにかを決めようと思っても自分だけで自由に決められること、というのはそんなに多くなくて、合意形成がとても重要である。
特に自分のような就任半年の新任マネージャーは、まだまだ過去の経緯やカルチャーなどを充分に理解しているわけではなく、自分がよかれと思って考えていることが、結果として過去の経緯を無視してしまっている、というようなこともある。
つまり、自分の意思決定に対するレビューや、叩き台を叩いてもらって合意形成を図る、というプロセスがとても重要だ。
もちろん、どうしても自分の考える理想に由来する施策、などもあるわけで、そういう場合は反対意見があっても押し切って意思決定する場合もある。とはいえ、そのような場合でも、合意形成のプロセスをやったうえで、「ここは自分がやりたいことだからやらせてほしい」と伝達するうえでやるべきだ。そうでないと、周囲から暴君のように見えてしまう。
このような性質の仕事が多くなるわけだから、自分が仕事で最初に出すアウトプットの9割は叩き台ということになる。つまりはアウトプットのほとんどを叩かれるわけである。
自分はエンジニアとしてコードを書く際は、必ずレビューを受けるという文化に身を置いているので、自分のアウトプットに対してレビューを受けることにそんなに抵抗はない。
とはいえ、そんな自分でも指摘事項によっては「しんどいなー」と思うこともある。レビューを受けることが苦手な人もいるというのもわかる。
叩かれるのはしんどいので、そのプロセスを飛ばしてえいや、と出してしまいたい誘惑にかられることはなくはないが、だからといって、周りの意見を聞かずに物事を決めるというのはやるべきではない。過去にも「この人全然自分らの意見を聞こうとせずに勝手になんでも決めるなぁ」と苦手だった上司がいた。
叩き台は叩かれてなんぼなので、どんどん叩かれるべきである。叩かれることに価値があり、そうしてアイデアやアウトプットは磨かれるのだ。
