0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

ぼっちアドベントカレンダー by bon10Advent Calendar 2024

Day 9

エンジニアリングマネジャー入門:信頼、組織、対話の極意

Last updated at Posted at 2024-12-09

今回の記事は「エンジニアリングが好きな私たちのためのエンジニアリングマネジャー入門」を読んだうえで、自分が気になった部分をピックアップします。

信頼大事

マネジャーはもうほぼこれに尽きます。どうでもいい人に言われる「それは正しいことですか」と信頼している人に言われるそれの言葉の重みはめちゃくちゃ違います。そして信頼は積み重ねるのことが難しい一方で、なくすのはとても簡単です。
一度なくした信頼を再度積み重ねるためには、それ相応の努力と地道な下積みが必要となります。

自分も大事

とはいえ、信頼を得るために自分を犠牲にしていては意味がありません。実体験としても断言できます。
メンバーに対してもマネジャーとして 「こういうことをやります(こういうことはやりません)」 というような説明書をドキュメントとして残しておくと良いでしょう。
そしてそれをプロジェクトの進行やプロダクトの状況に応じて都度修正することもおすすめします。定型化された1on1のドキュメントの冒頭に毎回リンクを載せておくとかでもいいですね。

いびつな組織構造を作らないこと

この書籍に書かれている内容ではないのですが、EMという仕事を通じて他のチームのEMと大きく異なる組織構成は個人的に辛くなりやすいというものがあります。
というのも、わりと構成の違うチームだけ独特のレポートラインができちゃって、「ほかはうまくいってるのに、なんかうちだけちがくね?」という疑問や不安、苦悩が、経験上生まれやすい気がするからです。

図で見てみましょう。

image.png

上図の場合はチームCだけが、この上にいるであろう上司、あるいは組織横断型であれば直属の上司(EMの上司)というレポートラインがチームA,Bとは違った形となってしまうため情報伝達や仕事の進め方、考え方などのパズルをチームCのEMが考えることとなります。大体の場合以下の理由で苦労します。

権限が足りない(あるいは過剰)

例えばPMとしての役割も兼務せざるを得ない立場だと、そのへんの融通を利かせようとして自分が何やってるかわからなくなるパターン。さらにチーム構成図に出てこない上司がいる場合、自分がやりたいことをいちいち上司を通さないと無理なパターン

内情をうまく説明できない

直属の上司またはPMに対して自チームと自分の役割を明確にすることが難しく、何をしてどう立ち回っているか(それがプロジェクト・プロダクトにどう影響しているか)を説明するのが難しい

チームメンバーに疑問をもたれやすい

「PMとしてのボス」と「EMとしてのボス」と「メンバーとしてのボス」の顔を使い分けていると、結局こいつ何なん?というやつ

自分の評価をしづらい

ここまで述べてきたとおり「自分は何者か」という哲学的な命題に立ち向かっているうちにプロジェクトもプロダクトも進行するため、重要な自分の評価視点が抜け落ちがちになる。

解決策としては、個人としてちゃんと自分の仕事(役割)の軸を持つこととそれを周知すること、組織的にはいびつな構造をなるべく排除するとかレポートラインの明確化を図ってチームとして機能するように組み替えるかなどすると良さそうですね。

1on1はテンプレ化しましょう

雑談する1on1が月に1回あっても良いと思いますが、基本的にはドキュメント化してテンプレにしたほうがやりやすいだろうなーとこの本を読んで思いました。

たまたまXを見ていたら、以下のスライドについて言及してる投稿を見かけてこれ便利そうだなと思ったので、私もパクリたいと思います。

EMが「自分でやる」のは最終手段

本にも書かれていますが、EMの大切な仕事の1つは メンバーのキャリア育成と成長支援 です。
マネジャーとしては戦略と方向性を示してあげることに注力し、それを明確に説明することが重要です。
私の場合、思い返せば「この人は自分のアピールが苦手だけど得意領域での仕事はずば抜けたセンスあるし、他チームと組ませてアピールできれば個人評価にもちゃんとした証拠が残るよなー。そうすれば絶対昇給できるよなぁー」という理由でそのメンバーを組織横断プロジェクトにぶっこんだことがありました。が、カッコ内の自分の考えを1on1で明確に説明し、自分がどう考えているかを伝えたかどうかが曖昧なので、多分伝えてないんでしょう。これは反省点です。

ということでEMのみなさん、メンバーに期待していること、自分が戦略・エンジニアリングの方向性について考えていることがあるのであれば、それを明文化するなり1on1で言葉にして伝えるなり(もちろんドキュメントも残しつつ)しましょう!

対話重要

この書籍でコーディングについて言及されているのは、Part3のChapter17くらいです。つまり書籍の中の1割もないのです。
とにかく話さんことには始まりません。自分の考えをコロコロ変えるにしても、その変遷について毎回説明するしかメンバーに自分の思考を追体験してもらうことはできません。
部下から「お前の1on1意味ないねん、スキップさせてや」と言われてからが勝負です。めげずに会話を続けましょう!(並行して1on1の内容の修正と信頼の獲得にも努めていきましょう……)

心が折れそうなときは、人ではない何かと会話するか夜空を見上げることをおすすめします!

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?