Re: エンジニアリングマネージャーでいるのがつらくなったときは
はじめに
自分もチームリーダー→プロジェクトリーダー→プロジェクトマネージャーと役割が変わっていった時に、同じようなことを考えたことがあったなと思い出しました。
私の場合
マネージャーはチーム・組織を開発するのが仕事
海外子会社に出向してある製品開発に携わることになり、ガラッと環境が変わりました。最初はプロジェクト管理として入り、次にソフトウェア部門のマネージャー、プロジェクトリーダーと役割が拡大していきました。実装作業から離れ、協力会社・取引先との打ち合わせ・調整・マネジメントが主業務となり、社内の面談でも自分の成果を伝えることが難しいなと感じるようになりました。
1年ぐらい炎上するプロジェクトと格闘したのち、ある時の上司との面談で「うまくできていたのか、できていなかったのかまったく手応えがない」と打ち明けたところ「協力会社・取引先からプロジェクトに参画してもらって助かっていると感謝の言葉が来ていただろ、あれが全てだ」とコメントをもらいました。
その時から私のマネージメントに対する認識が変わったことを覚えています。 エンジニアの開発対象がコード・ソフトウェアであるように、マネージャーの開発対象はメンバ・チーム・組織・開発プロセスです。メンバが直面している課題を解決し、チーム・組織全体での成果を引き上げることがお仕事です。 マネージメントに対する認識が変わった後では、開発チーム・プロジェクトが「雰囲気良く協力し合い」、「技術的・組織な課題に対処できており」、「スケジュール通り進捗」していればそれを自分の成果として上司に伝えています。何度か上司が変わりましたが、変わらず良い評価をもらえています。
チームの雰囲気を察知する
職場の人間関係に対して常にアンテナを張っていなければいけない気がする不安 ・Slackから目が離せない ・あそこで話している人たち、何を話しているのだろう?
「人を管理する」と捉えると上記の発想になりやすい気がしますが、「チーム・組織を良い状態に引き上げる」と考えると少し違った手が打てます。
例えばこんな感じです。
- 定期的に振り返り(KPT)を実施してもらい、問題として上がってくる内容に目を通す。
- チームで解決できない問題を「リーダー・マネージャーに対処してほしい問題」としてあげてもらい、付箋で壁に貼るなどして皆が見える場に置く
- 上がってくる課題に対して「何らかの施策」を「早急に打つ」。根本原因に迫れれば良いが、効果はやってみないとわからないので小さな一歩でもとりあえず試してみる。課題をあげても対応されないと士気が下がるので早くに対応する。
- 問題はいつ、どのようなものが上がってくるかわからないので自分の時間は空けておく。むしろ暇なぐらいが良い。
- 時間ができたらまめに職場を歩き回り、メンバと会話する。「さんぽ」と自称して、話しかけてもらうハードルを下げる。色々な問題がカジュアルに出てくるようになる。
要は問題を提起するやり方がメンバに定着し、改善する流れがつくれれば細かく見張る必要は減っていきます。
プレイヤーに未練はないの?
次々新しいものが出てくる実装・技術を身につけてスキルアップしていくことは楽しいですが、マネジメントも同様に学ぶものが多くあります。
私は「仕事をうまく回せるチームを"再現性"を持たせて作れるか」をテーマにして取り組んでいます。 同じメンバ・同じチーム・同じプロダクト・同じ課題に直面することはなく、課題に対する施策も効果があるものもあればそうでないものもあるのがマネジメントだと思っています。
今の自分の自己評価は「30〜40人のソフトウェアエンジニアをまとめて、1つの製品をアジャイルに開発できる」です。これがゴールではなく、この先には「ビジネス・バックオフィスもまとめて全社でアジャイルにやる」、「100〜200人、もしくはそれ以上の人数で大規模アジャイル開発を実現する」といったチャレンジがあると考えています。
スーパーマンリーダー、プレイングマネージャーに対するスタンス
いたらラッキーだけど、いないと回らないチーム・組織になってしまった時点でマネジメントの負けかなと考えています。
- チームの単一ボトルネックに容易になりうる
- メンバの尊敬を集めるかもしれないが、「自分はリーダー・マネージャーになれない」という先入観を与えてしまうかもしれない
- メンバに任せるべきところを任せられず、チームとしての成長を阻害する要因になるかもしれない
おわりに
マネジメントはマネジメントの面白さがあると思います。
