はじめに
この記事はモチベーションクラウドシリーズアドベントカレンダー2022の記事です。
リンクアンドモチベーションでエンジニアをやっています。
最近娘が「ウーパールーパー」を認識し、我が家で「ｳｯﾊﾟﾙｯﾊﾟ」と連呼しています。どうもこんにちは。
2022年を振り返って、プロジェクトマネージャーとしてプロダクトのローンチを経験したので、その時にやっていたこと感じていたことを書いていこうと思います。
この記事で伝えたいこと
マイクロマネジメントと言っても濃淡はあるよね
フェーズに合わせてマネジメントスタイル変えようね
マイクロマネジメントってなんだっけ
エンジニアとして仕事をしていると、以下のようなことを耳にしたことありませんか。
「〇〇マネージャーはマイクロマネジメントするタイプだから苦労しそうだね！」
「上司がマイクロマネジメントすぎて心死んだ…」
ありますよね？（迫真）
「マイクロマネジメントしてくれて助かった」とかプラス方面ではあんまり聞かないです。
基本的にマイクロマネジメント=悪が多い印象があります。
そもそもマイクロマネジメントってどんなことを指す言葉なんでしょう？
ウィキペディア - マイクロマネジメント
マイクロマネジメントとは、管理者である上司が部下の業務に強い監督・干渉を行うことで、一般には否定的な意味で用いられる。
ふむふむ。やはりマイナスイメージが強そうですねぇ。
（対義語としてマクロマネジメントという言葉があるのか。へぇ〜）
弊社コラムでもマイクロマネジメントについて取り上げており、
「細かく管理する」と「過干渉なマネジメント」二つの意味合いがあり、否定的なトーンで語られているのは「過干渉なマネジメント」の方なようです。
マイクロマネジメントには、その程度に濃淡があり「細かく管理する」と「過干渉なマネジメント」はそれぞれ分けて考える必要がありそうです。
細かく指示されてイチイチ口出しされるのは誰だって嫌なものです。
そんなマネージャーには「せいなるほのお」を喰らわせてクリスマスの灯火にしてやりたいですね。
マネジメントの意義
次にマネジメントの意義について見ていきます。
マネジメントの父として知られるピーター・ドラッガーさんは「明日を支配するもの」にてこう定義しています。
組織をして成果を上げさせるための道具、機能、機関である
では組織ってどんなものでしょう？
チェスター・バーナードさんの「経営者の役割」によるとこうです。
組織とは意識的に調整された人間の活動や諸力の体系
組織は、⑴相互に意思を伝達できる人々がおり、⑵それらの人々は行為を貢献しようとする意欲をもって、⑶共通の目的の達成をめざすときに、成立する（組織成立の3要素）
個人で開発していればマネジメントなんてものは必要ないです。
ではなぜチームで開発するのかといえば、より大きな成果をより早く創出するためです。
一定の規模のサービスを開発するとなると個人の認知負荷を超えてしまうので脳みその負荷分散をしたくなりますし、並列化できる作業はマンパワーをかけてできるだけ早く価値を届けたくなります。
ただチームで成果を出すには、その中にいる人間という不確実性の高いコンポーネントをつなぎ合わせながら、バーナードさんのいう組織成立の3要素を達成しなくてはなりません。
特にエンジニアはコーディングというDeep Diveな作業を伴うために個人プレイに寄りがちです。エンジニアを集めた開発チームにおいて、メンバーの目線を合わせて生産性高く成果を上げるためには、マネージャーという役割が必要になってくるでしょう。
マイクロマネジメントとマクロマネジメント
階層型組織vs自律型組織、命じるリーダーシップvs委ねるリーダーシップなどの組織論と近しい気がしていますが、マネージャーがメンバーの動向を細かく把握して、場合によっては細かく指示する管理方式をマイクロマネジメント、反対にメンバーに裁量を委ねて俯瞰した立ち位置から自律性を促す管理方式がマクロマネジメントとします。
比較するとそれぞれの特性が浮かび上がります。
| 分類 | マイクロマネジメント | マクロマネジメント |
|---|---|---|
| 成果物の質 | マネージャーに依存 | メンバーに依存 |
| 意思決定のスピード | マネージャーがトップダウンで決めるから早い | メンバーがボトムアップで決めるから時間がかかる |
| 指揮系統 | メンバーが指示を受けて作業する | メンバーが自律的に作業する |
| メンバーの主体性 | 持ちにくい | 持ちやすい |
| 管理コスト | マネージャーに集中 | メンバーにて分散 |
| 拡張性 | マネージャーの工数に限定 | メンバー数に応じてスケーラブル |
それぞれで特徴がありますが、
マイクロマネジメントはマネージャー主体のチームなので、チームの成熟度による影響が少ない反面、マネージャーの器量=チームの限界となりそうです。
一方でマクロマネジメントの場合は、メンバー主体なのでチームやメンバーの成熟度に応じてチームの成果が決まってきそうです。
スタイルによる違いを踏まえた上で、チームが組成されるどのような状態にあるでしょうか。
有名な考え方でタックマンモデルというものが存在します。
- 形成期：チームが形成される
- 混乱期：チーム内で衝突が生じる
- 統一期：共通の規範が形成される
- 機能期：チームとして成果を出す
- 散会期：チーム関係が終結する
どんなチームも自己組織化したアジャイルなチームでありたいものですが、最初からそうはいきません。
チームが組成されてから機能し始めるにはフェーズごとのステップがあるみたいです。
何度もぶつかり合いPDCAを回し続けた先にチームとしてのスタイルがなんとなく確立し、メンバー全員のフォームが整ってきたところでようやく成果が出るといった具合でしょうか。
混乱期〜統一期くらいにかけては、チームが成熟しきっていないためマネージャーが状況を細かく把握し、リーダーシップを発揮して成果創出に導いていく立ち回り（マイクロマネジメント）が有効だと思います。
統一期以降は、メンバーが自律して動けるよう俯瞰して障壁を取り除き、チームやメンバーに役割や権限を移譲していく動き（マクロマネジメント）が有効になるでしょう。
今年を振り返って自分がやってきたこと
混乱期
今年の3月にプロジェクトマネージャーとしての期待で新プロダクトの開発チームにジョインしました。
当時の状況的には混乱期に当たるフェーズで、開発チームの規模的には、エンジニアが10名のぎりぎりピザ2枚を配りきれる程度の人数規模。
ローンチの3ヶ月前で納期に追われながら機能開発しながらもバグが数百件発生しており、プロジェクト全体で課題が散在している状況でした。
こりゃー大変だということで、起きていることを正確に把握するためにとにかく事細かに可視化することに努めました。
- プロジェクト管理系
- WBS
- ロードマップ
- プロジェクトの消化pt
- 個人の消化pt
- テストフェーズでのバグ発見率
- バグの発生と消化曲線
プロジェクトの状況が可視化されることで、課題を要素分解してボトルネックを特定しやすくなりましたし、何よりファクトをもとに意思決定ができるようになったので方向性に対する納得感をチーム全体で醸成することができたと思います。
物によっては「細かく管理すること」という意味でのマイクロマネジメントをしてきたなと思いますが、データ抽出の仕組みを日常業務に落ちていれば過度に干渉されている感覚は低減できます。
得られた効果としては以下のとおりです。
- 定性
- チームの目線が揃った
- ファクトをもとにした振り返りができるようになった
- 定量
- チーム状態把握のための管理工数削減
統一期
プロダクトのローンチ後は、「納期に向けて最小限の価値で動く作る」モードから「仮説検証を繰り返し価値を磨き上げていく」モードに変わります。フェーズ的には統一期に変わっていったと思います。
マネジメントスタイルとしては、マクロマネジメントに舵を切りました。
プロジェクト管理系の可視化に加えて、開発生産性を測る指標を計測し始めました。
- 開発生産性のメトリクス系
- デプロイ時間
-
Four Keys
- デプロイ頻度
- 変更のリードタイム
- 変更障害率
- サービス復旧時間
- DX Criteria
開発生産性指標を測ることで、イケてる開発チームと自チームの差分を明らかにして課題を明確化させました。また各指標ごとに責任者を置くことでメンバー主体の改善サイクルを回せるようになりました。
全員で改善していくというスタイルを文化にするためにチームの行動指針を打ち立てたり、細かいですが朝会のファシリテーターを特定のメンバーの担当からローテーション制にしたりとすることも有効だったと感じています。
得られた効果としては以下のとおりです。
- 定性
- チームが目指す方向性がすりあった
- メンバー主体の改善サイクルが回り始めた
- 定量
- Four Keysのパフォマンスレベル向上（Low→High）
最後に
いかがだったでしょうか。
一般的にマイナスイメージの強いマイクロマネジメントもチームの状態によっては効果を発揮する場面もあります。が、長期的に見たら成長を鈍化させる要因にもなりうるので自立組織を目指してマクロマネジメントに切り替えることが必要になると思います。
また、やり方次第でメンバーの自律性を促しながらも細かな状況を把握するということも可能なのではないでしょうか。
感想や気になる点などあれば、是非コメントなどで教えてください！