【マネジメント】マイクロマネジメントより怖い、マクロマネジメントより怖い、なんちゃってマネジメント
はじめに
対象
- マイクロマネジメントは悪いと思っているITエンジニア向け。
- 知らないうちになんちゃってマネジメントしてしまっている方向け。
マクロマネジメント
マクロマネジメントとは、目標やゴールを提示し、方針や目的を共有し、そこに至るまでの過程を全て任せるマネジメントスタイルです。いわゆる放任主義や、かわいい子には旅をさせよに近いやり方ですね。
ITエンジニアの現場では「マイクロマネジメントは悪い！」という言説はよく聞く一方で、マクロマネジメントはその名称自体があまり普及していないようです。
マクロマネジメントを簡単におさらい
マクロマネジメントのメリット・デメリット
メリット・デメリット自体を語ることは記事の趣旨ではないので、気になる方は自分で検索して調べてみてください。ここでは代表的なものを3つずつ抜粋します。
- メリット
- メンバーの自主性・創造性を引き出せる。
- マネージャーの負担が軽減される。
- チーム全体の作業効率・スピードが上がる。
- デメリット
- メンバーのスキル・能力に左右されやすい。
- 誤った方向に進んでいても気付きにくい。
- 手戻り・ミスが発生しやすい。
マクロマネジメントとマイクロマネジメントの関係
IT界隈にはアジャイル開発とウォーターフォール開発という用語がありますが、あれと同じ関係だと考えています。
どこかの誰かが特徴のある事象に名前を付けて、それがたまたま比較されるようになった。どちらが良いとか悪いとかではなく、各々メリット・デメリットがあって適材適所は異なる。そして不勉強な人々が都合の良い面だけ真似しようとして失敗するところまで同じ。
マイクロマネジメントも悪い面ばかりが目立っていますが、短期的な新人研修など教育中、あるいは品質が求められる作業や、リスクのある作業において必要なこともあるでしょう。どの手法も適切に運用されれば良い結果をもたらします。
何なら名前が付いているものなど、幾多もある手法の中のほんの一部でしょう。マイクロマネジメントとマクロマネジメントとの間やその周囲には、名前の付いていないマネジメント方法が沢山あり、特徴によっては◯◯マネジメントのカスタマイズと言われるのです。
マクロマネジメントアンチパターン
頭の中の正解を持ってこい
マクロマネジメントと銘打って全面的に任せたにも関わらず、成果物を提出するとほぼ全てやり直しというパターンです。自分の頭の中の正解と少しでも違う部分があると、例え目的に合致していても修正を余儀なくされます。開発者はエスパーではありません。無理な話です。
こういったケースではまず、目標や方針の共有ができていません。指示する側がゴールを定義できていないのです。どのような状態になっていればよいか、最低限満たすべき条件を共有していません。そして目的が満たせるものであれば、過程を問わないのがマクロマネジメントです。
この条件の抽出は抽象的な頭の使い方をします。個別具体な資料やソースコードの状態を指すのではなく、その資料やコードが果たすべき役割を全うできるかどうかです。しかし正解を求める方は、自分の成果物を正解として、寸分たがわず同じものを求めます。
よくプルリクエストのレビューでこれをやる方がいます。もし頭の中に正解があるのなら、あらかじめ指示に含めておくか、マイクロマネジメントのように細かくチェックするかです。丸投げした後でやり直しさせるのは、離職に繋がる最悪のマクロマネジメントです。
途中の伴走や相談をしない
もちろん全ての条件を書き出すことは不可能でしょう。抜け漏れが見つかることもあるでしょうし、作業を進めていく上で発生したものもある筈です。だからこそ伴走、つまり定期的な進捗率や作業内容の確認が必要になります。
「その件は君に一任した。全て任せるよ」というのは一見、聞こえがいいです。しかしこの手の方、最後の最後に成果物の評価が悪いと他責にします。いいですか、仕事を任せている以上、その責任はマネジメントをしている側にあります。他人事にしてはいけません。
もし分からないことや相談したいことを聞かれたとき、「マクロマネジメントだから細かいことを言わずに任せなければならない」というのは曲解です。必要に応じて適切な情報を提供し、困っているときは指示を出すのではなく、相談という形で方向を修正する。
また途中の過程は問わないと申しましたが、それが企業や個人の信用に関わるリスクを抱えている、あるいはコンプライアンスに違反するようなやり方であれば、やはり途中で待ったをかけるべきでしょう。結果を評価するだけではなく、過程を観測する必要はあります。
このようにマクロマネジメントはマイクロマネジメントよりもずっと難しく、抽象的思考や高度なコミュニケーションスキルが求められるものです。誰にでもできるものではありません。中途半端なコーチングになるくらいなら、やらない方が賢明です。
なんちゃってマネジメントへの対策
本当に怖いのはなんちゃってマネジメント
開発手法それ自体がデメリットや欠陥を抱えている可能性は否定しませんが、炎上に直結するほど大きな問題がある訳ではありません。ウォーターフォール開発は原則として前工程に戻ることを許容していないのに、前工程の決定事項を考えなしにちゃぶ台返しするから問題になるのです。
同様にマクロマネジメントは原則として途中の工程は任せる方法なのに、最後の最後にやり直しを命じ、あたかもそれが作業を振られた側の全責任だとするから問題になるのです。
それはもはやマクロマネジメントとは呼びません。なんちゃってマネジメントです。
世の中には原理・原則や満たすべき条件を無視して、有名な開発手法やマネジメントスタイルを試した結果、その方法が悪だ・デメリットしかないとのたまう方がいます。しかし現場に入って実態を見ると、自分にとって都合の良い側面だけを拾って実施していることが多いのです。
現場の状況に合わせて適宜カスタマイズすることはありますが、その場合も本質を見失わないよう、カスタマイズした部分が実害を発生させないよう、よく理解した上で行う必要があります。
学び続け目の前のメンバーに向き合う
マクロマネジメントを行う場合は、きちんと勉強した上で実施してほしいと思います。世の中にマネジメントに関する書籍や、リーダー論を解いた本や、心理的安全性やファシリティを語る書物が山のように並んでいるのは何故か。それだけ悩む人が多くて売れるということでしょう。
もちろんマニュアルに忠実に行動するだけではなく、目の前のメンバーを見て臨機応変に対処することも大事です。現場やメンバーによっては、そのまま名前の付いたマネジメント手法をあてがうのが適切でないこともあるでしょう。こればかりはチームごとにオーダーメイドになります。
何も知らない外野が「こうしたらいい」「ああしたらいい」と言えることはないです。デートの入門書通りにしたらフラれた、みたいな話になってしまいますからね。向き合うべきは目の前に居るメンバーであって、外野の頭の中に登場する架空のチームではありませんので。
「私も勉強はしているけれど、経験は浅いから粗相があったら申し訳ない。少しずつ改善していくから、どうかよろしくお願いします」と。何事もまず礼儀と敬意と、誠実な態度で応えること。それが分かっていればアンチパターンのようなことは、やらかさない筈ですから。
おわりに
いわゆる仕事の丸投げとマクロマネジメントは紙一重、いやむしろ本当に高いマネジメント能力を持った人がギリギリ成立させるのがマクロマネジメントなんだと思います。今までプレイヤーだけをしていた開発者や、技術だけ・コミュニケーション能力だけの開発者では難しいと思います。
マイクロマネジメントとは別の種類のストレスというと軽く見がちですが、全部作業を終わらせた後に全否定してやり直しというのは、会社やマネージャーから心が離れるのに十分だと思います。むしろマイクロマネジメントよりも厄介なんでないでしょうか。
中途半端なマクロマネジメントをしていないか、もはやなんちゃってマネジメントではないか。この機会に見直してみてはいかがでしょうか。
Discussion