orangeitems’s diary

40代ITエンジニアが毎日何か書くブログ

主体性を阻害するマイクロマネジメントの具体的兆候とは

f:id:orangeitems:20220405151727j:plain

 

ああ、マイクロマネジメントやっちまったな、という経験がある。

私とメンバーたちの技術力の差がありすぎるので、どうしたもんかと悩んでいた。いきなりは引き上げられないので地道に腕をつけさせるしかないかな、と。

それは正しいと思う。問題は方法だ。

オレカッコイイ、的な検証をがんばった。手順書もきちんと作った。これを一通りやれば、いろいろ学べるだろう。検証にはそうとう苦労した。私は、また技術力を得ることができた。そしてメンバーは新しい技術をこの手順書によって得られる。WIN-WINだ。

と、思っていた。さっきまでは。

メンバーが言ってきた。「できました!終わりました!」

私が1週間ほどかけて試行錯誤した結果を、彼らは2日くらいでやり遂げた。

それはすごいことなのだろうか、いや、大きな観点が抜けている。この手順書を作り上げるための試行錯誤が彼らにはない。

どこかの国のガイドブックを一冊読んだら、その国のエキスパートになれるみたいな話が目の前で起きたのだ。

多分、手順書にて、なぜその手順が必要か、についてさっぱり情報が抜けているのではないかと思っている。苦労してたどり着いたその手順。私の体は傷だらけだが、彼らは傷どころか、汗一つかいていないではないか。

この事実に愕然とした。きっと、自分で問題意識を持ちゴールを設定し、プロセスは試行錯誤で手に入れた実績と、先人が作った道を「景色いいねー」と見ながら一本の道を進み続けた経験では、雲泥の違いがある、ということだ。

しかも、今後も思いやられた。今回は、私も知らなかった内容だったから検証する価値はあったけれど、例えば私は知っている、彼らは知らない、という内容だったらどうか。私は、知っていることを、手順書に起こさなければいけないのか。それは苦痛だけではないか。WIN-WINにならない。私が一方的に負ける(LOSE)な気がする。だって、私は学ぶことがないのだから。

ははーん、これがマイクロマネジメントなんだな、という実感を得た。私は、事細かにメンバーをプログラミングしようとしていた。そうすると、新しい人が来る度に1からプログラミング?、人が抜ける度にやり直し?。

もっと人間の仕様をふまえた教育をする必要がある。人は基本的にできるなら成長したいと思っている。もしくは思っていない人を成長させることまで、マネジメントが対応する必要はない。学校ではないのだから。

成長できる環境を作り、どう成長したいかは個人の主体性に委ねる。評価するのは上司だが方法まで決める必要は全くない。

成長したいと思わない人は、何も動かないかもしれない。でも、それでもいいという割り切り。こんなことをやりたい、試してみたい、はメンバーから始まる。それは、こうしてみるかい?、親身になってマネジメントが相談に乗る。あくまでも主体は上司ではない。メンバーだ。個々の成長のためにお金を渡すし、時間も渡す。でも考えるのは自分だよ。その方向があからさまに業務とかけ離れていたときでも、同じビジョンが共有できているかを確認するだけでいい。想像もできないことを発明しているのかもしれない。

できる上司ほど、マイクロマネジメントしたがるような気がする。自分と同じように動ければどれだけ楽になるか、でもできない。だから、せめて私のやるようにやってみて、と。

しかし、それでは、コマンドの数だけしか成長しない。コマンドが持つ意味を受け手は考えない。やればいいんでしょ、と。そしてできるのだが、そこからは超えられないのだ。

ああ、マイクロマネジメントやっちまったな、と思うのは、そこにある主体性のないロボットがこっちをじっと見て、「コマンドくれ!くれ!」と圧をかけてきたときだろう。そして、上司はコマンドを作る時間に翻弄され、自分の時間すら取れなくなったときに、ああ、だめだ、と思うのだ。