見出し画像

マネージャーは何をしているのか?何をするべきなのか?忙しいのか?向いているのはどんな人か?

はじめに

マネージャーになって1年が過ぎたので感想をまとめる。自分は大きめのIT企業に務めている。2023年4月にマネージャー職になって5、6人の部下が出来た。この記事のマネージャーはエンジニアリングマネージャー(EM)を想定している。

マネージャーは何をしているのか?

そもそもマネージャーは何をやっているのか。マネージャーになる前は「マネージャーってなんか忙しそう」ぐらいの解像度だった。

駆け出しマネジャーの成長論

この本はエンジニアリングマネージャーに問わず様々な分野のマネージャーの仕事が整理されていてその全体像を掴むことができる。

この本によるとマネージャーの仕事は具体的に大きく3種類に分類できる。

  • 対人関係の仕事(挨拶屋、ベクトル合わせ屋、連絡屋)

  • 情報関係の仕事(分析屋、伝達屋、宣伝屋)  

  • 意思決定の仕事(変革屋、障害やりくり屋、配分屋、決定屋)

要は人と関わる機会が増え、それに伴って自分を中心に行き来する情報が増え、結果として意思決定の機会が増えるということ。

そして次の挑戦課題がある。

  • 対人関係 → 部下育成、多様な人材活用

  • 情報関係 → 目標咀嚼

  • 意思決定 → 政治交渉、意思決定

  • その他 → マインド維持、プレイヤー/マネジメントバランス

マネージャーは組織の成長に責任を持っている。そのため目標の咀嚼を行い部下の成長を促す必要がある。対立している2者間で上手く立ち回るような交渉や意思決定が求められる場合もある。何より難しいのが、マネージャーになって増えたこれらの仕事とプレイヤーとして元々やっていた作業のバランスを考えるプレイヤー/マネジメントバランスである。

マネージャーになって最初にこの本を読めてとても解像度が上がった。これから新しくマネージャーになる人にもこの本はぜひお勧めしたい。

エンジニアリングマネージャ/プロダクトマネージャのための知識体系と読書ガイド

先ほどの話がすべてのマネージャー向けの話だとすると次の記事はエンジニアリング/プロダクトマネージャー向けになる。この記事ではマネージャーの仕事を4種類に分類して全体像を俯瞰できる。

「強めのEM定義」ではどうでしょうか。ピープルマネジメントに加えて、テクノロジーマネジメントのみならず、プロジェクトマネジメントやプロダクトマネジメントの一部の要件定義能力などが求められることもあります。

エンジニアリングマネージャ/プロダクトマネージャのための知識体系と読書ガイド

自分もマネージャーになってからピープル/テクノロジー/プロジェクト/プロダクトマネジメントに触れるようになったり、機会が増えた。自分の環境では自分は弱めのEM定義に当てはまり、ピープル/テクノロジーマネジメントの割合が多い。

自分が担当する領域で未知のものや、困りごとがあればこの記事を参照して紹介されている本を読むといい。足りない知識を補完してマネージャーとして成長できる。

マネージャーは何をするべきなのか?

マネージャーのやっていることは分かった。じゃあ何が成果になるのか。何を優先するべきなのか。それがこの本で分かる。

HIGH OUTPUT MANAGEMENT

この本では成果とは次のように定義されている。

HIGH OUTPUT MANAGEMENTより

何をするべきかは以下の通りである。

言われてみると当たり前のことが書いてあるように見えるが、だからこそそれをはっきり言語化しているこの本には価値がある。

さきほどあったマネージャーの3つの仕事「対人関係・情報関係・意思決定」とエンジニアリングマネージャーの4象限を自分の中で理解・整理する。それらの活動のテコ作用(コスパ、影響度合い)を判断してどれを優先するべきか状況に応じて考えていく。

組織の中で部下の成長に強い課題感(テコ作用)を感じるのであれば、「ピープルマネジメント」や「対人関係」に時間を使う。目標がメンバーに浸透しておらず、そこにテコ作用を感じるのであれば「情報関係の仕事」「目標咀嚼」に時間を使うということ。様々な情報や選択肢がある中でマネージャーは最適な時間の使い方を検討しなければならない。

ただこれは言うは易しで、自分は目の前の作業に気を取られたりして本質的な課題に時間を使えていなかったりするので改善したい。

マネージャーは忙しいのか?

そうかもしれないし、そうじゃないかもしれない。

マネージャーになると扱う情報の量がとにかく増える。プレイヤー時代に比べ、部下・横組織・上位レイヤーから来る情報が圧倒的に増える。

情報が多いということはそれだけ見える仕事も増える。そこから優先順位を判断する必要があるので、判断疲れは起きやすい。もともとのプレイヤーとしての仕事もある。

じゃあ仕事が忙しいかはそうではなくて、テコ作用を意識して以下3点を適切に実行する必要がある

  • プレイヤー/マネジメントバランスを考えること

  • NOと言うこと。また、何かにYESということは別の何かにNOと言っているということを意識する

  • 権限移譲を行うこと

これが出来ると適度な忙しさになるし、そうじゃないと大変なことになる。特に最初のうちは(そして今も)自分の作業を手放す権限移譲が難しく感じる。

BUILDより

マネージャーに向いているのはどんな人?

個人的には情報量の多いのが好きな人、SlackやZoom、対面などコミュニケーションを苦と感じない人。自分は他の人に比べてSlackコミュニケーションを苦と感じていないのでその点は向いている。

あと向いていないと思っているエンジニアの方へ岩田さんの言葉を届けたい。

岩田さんはエンジニアリングで得た知識をマネジメントや会社経営に活かしていた。エンジニアリングとマネジメントは実は地続きで少し抽象化できると色々と相互に活かせる要素はあるのではないかと思っている。

マネージャーは難しいけれど、自分はそこに面白みがあると感じるのでもう少し続けてみたい。

この記事が気に入ったらサポートをしてみませんか?