マネージャが部下へするマネジメントとプロジェクトマネージャがメンバへするマネジメントはちょっと違う

ワタシ、すっかり勘違いをしていたことをウィキペディアをみて知ったんですが、マイクロマネジメントはただ指示が細かいとかうるさいとかじゃないんですね。意思決定をさせないとか、マイクロマネジメントをしていると上司が認識していないとか、ちょーネガティブ。細部にこだわるのは強迫観念からきているとか、自信がないからだとか。

確かに、それなりのメンバを見てきて、リーダになるタレント性を持っていないとか、成長しないエンジニアはワタシが関心を寄せない子細なところまで拘ったりしているのをみると、そう言ったエンジニアは「自分で自分をマイクロマネジメントしてたのかなー？」なんて思ってみたりするのは邪推でしょうか。あれをやらなきゃー！あれをやらなきゃー！あれをやらなきゃー！って、やってる風だもんなぁ。そこまでいいよって言っても。

メンバへのマネジメントスタイルは2種類あるのです
メンバへのマネジメントは2種類あると思っていて、その対象のメンバというより「メンバと何を成すのか」と言う目的で全く違いうマネジメントをするようにしています。あ、正直言えば、自然とそうやっていて、あとでマイクロマネジメントという言葉を知ったり、その意味をさらに後から調べて無知さに驚いたり。

部下のメンバのマネジメント
一つ目は、メンバが部下の場合、ワタシの仕事の大部分は育成が占めます。ワタシの後釜、リーダは次のステップに、サブリーダはリーダに、担当はサブリーダに。如何に、今いるポジションのロールから引き上げるか、いや違います。上がってもらうか。そのためにそのメンバに可能なら合った案件で経験を積んでもらう機会を作ること。普段から雑談のように会話をしてリスクを識別すること。そんなことを重ねながらメンバの希望とこちらの希望と結果と次の可能性を考える。

そこには、ウィキペディアに記載されているようなマイクロマネジメントは存在しない。けれど、ワタシのセンサーが働くタイミングでインタビューはする。それ以外は放置と言うか裁量というか。

メンバ全てがそれで自分をコントロールできかどうかと言えば、残念ながら「ない」のだけれど、自分で自分をコントロールできていないように見える人には選択肢を与えるんです。

「自分で裁量を持ってコントロールすること続けるか。」
若しくは、
「自分で課題設定が出来なくて、コントロールをできないならワタシがカウンセラーになるけれど。」
「どちらを選ぶ？」

全員、前者を選ぶんです。それは自分で試行錯誤を続けてくれると言うことでもあるわけで。上手くいかないときの方が多いけれど、「あの課題、滞留していて危なそうだけどどうするの？」とかワタシの閾値でポーリングを掛けることで若しかしたらチェックを忘れているかもしれない課題に気づかせることもあるんだけれど。

そこの背景には、メンバには自分で考えて、自分の意思を持って、自分から行動して欲しい、と思っているからです。

とはいえ、ゴールの時期になってゴール地点を間違っているとわかるとて戻りが大変なので、それこそマイルストーンごとにメンバが自分で修正範囲の中にいるかを教えてもらうんです。

プロジェクトチームメンバへのマネジメント
2つ目は、自分がプロジェクトマネージャのときは、プロジェクトのゴールが明確にあるのでプロジェクトに個別最適化をするんです。そこには、子細な作業指示をすることより、作業の標準化をすることでメンバが変わると作業品質が変わらないように、作業をするメンバによって判断が変わらないように、という目的があるからです。

なので、作業を標準化するし、標準化するさいは、その作業プロセスの案を出して、メンバと会話して、場合によってメンバの案を取り入れて、チームのプロセスを決定するんです。そこにはメンバの意思も入る余地もあるし、自分たちがこれからやる作業に対して真剣に考える機会があるのです。そして、理解して、合意したやり方を徹底する。実際やってみて、うまくいかない、不良なプロセスがあればメンバと協議して改善するんです。

そういったプロセスの標準化と改善の場があるので「これもマイクロマネジメントではないなー。」と思うんですが。どうなんでしょう。

何れのケースにしても、メンバには考えてもらうことはしてもらいますね。だって、ワタシの頭なんてたかが知れていますからねー。それに、自分に判断権がない作業なんて誰も真剣に考えないし、身を入れて作業しないですもん。