😽

EMになって気づいた「時間に頼るマネジメント」からの脱却

に公開

はじめに

フロントエンドエンジニアとして働いていた時は、時間をかければ何とかなると思っていました。

しかしEMになってから、それが通用しない現実に直面しました。
どれだけ時間を使っても、チームの成果は比例しないことに気づきました。むしろ、私が“作業”に逃げている間に、チームの課題は少しづつ積み上がっていきました。

「今日はこれだけ進めることができた」と思っても、それは実際は進んでいるのではなく自己満足にすぎず、時間を使っている=仕事をしているという思い込みが、チーム全体の前進を止めていたと思います。

時間でコントロールしようとする癖

EMになった当初は、“エンジニア時代のパターン”を継続していました。タスクを細かく分解して、自分の手で進めて、夜まで作業する。でもそれは 「自分の成果」を最大化する仕事術で、
「チームの成果」を最大化するマネジメント術ではありませんでした。

特に、mtgや1on1、PRレビューなど“非作業時間”が増えると、振り返った時に「何もしていない」と錯覚して焦り、焦りから予定を詰め込み、また時間で解決させようとする完全に悪循環でした。

タスク管理を「時間」から「影響」に切り替える

このままではまずいと思い、タスク管理を根本から見直しました。
ベースとして考えたのは「どれだけ時間を使うか」ではなく、「どれだけ影響を与えられるか」 です。
マネージャー職になると「時間を使った量」より「他の人が動けた合計量」が肝になってくるためこのように考えました。

具体的に3つの視点で整理しています。

  • 影響範囲:自分/チーム/組織
  • 影響が及ぶ時期:即効くか、3ヶ月後に効くか
  • 再現性:一度きりか、仕組み化できるか

これをもとに次のように行動を変えた。(正確には変えている途中)
特に影響範囲が広い場合は優先度を高めて対応する。

  • 「自分がやった方が早い」仕事は、他メンバーが対応できるように仕組み化
  • 「今週すぐ効く」仕事は、短期集中で片付ける
  • 「3ヶ月後に効く」仕事は、メンバーを巻き込み先に備える

結果、作業時間は減ったが、意思決定と支援の質が上がっている気がします。

「働く時間」ではなく「動く構造」を設計する

EMの仕事は、自分が動くことではなく、チームが自走できる構造を作ることだと思います。
自分の作業時間を増やしてもチームの成果は増えず、むしろ、私が「動かない勇気」を持つことで、メンバーの動きが仕組み化されて良い形ができます。

「時間に頼らず、仕組みで動くチームを作る。チームの成果を最大化する」
EM経験を通して、これこそがEMとしての“生産性”だと思いました。

まとめ

  • EMになり、時間で安心しようとする癖に気づけた
  • タスクを「時間」ではなく「影響」で整理すると、焦りが減る
  • チームが動ける仕組み、構造を作ることが、EMの最重要タスク

Discussion