天の月

ソフトウェア開発をしていく上での悩み, 考えたこと, 学びを書いてきます(たまに関係ない雑記も)

エンジニアリングマネージャーのしごと - Forkwell Library #5に参加してきた

forkwell.connpass.com

こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。

会の概要

以下のイベントページから引用です。

これまで Forkwell のイベントで登壇されたエキスパートの方々は、先達が記した書籍から「気づき」を得て実践し、振り返り、再現性のある「学び」として身に付けていく中で、実績を築いてこられました。

しかし、日々限られた時間の中で知識や情報をアップデートし続けるのはそう簡単ではありません。 Forkwell Library では、著者・訳者・実践者らを登壇者として招き、そんな思いを抱えた開発者の皆さまが「学びのきっかけ」を得られる勉強会を目指します。

今回の第5回目では2022年8月26日に出版の最新刊『エンジニアリングマネージャーのしごと』を取り上げます。翻訳者である吉羽 龍太郎氏をお招きしてエンジニアからエンジニアリングマネージャーになるためのノウハウをお聞きしていきます。

会の様子

Ryuzeeさんの基調講演

時間の都合上本の詳細な内容説明は難しいということで、本全体で根幹をなすような部分の説明をしてくれました。

エンジニアリングマネージャーが関わる領域

テックリードといった他の似た役職と比べて、ピープルマネジメントを主とするような関わり方が一般的になるという前提を最初に共有してくれました。

エンジニアリングマネージャーのキャパシティ

稼働率100%の危険性はワインバーグ先生からも話がされていますが、マネージャーは特にそういった部分が大事になってくるため、まずは自分自身のキャパシティが整理整頓できている状態を作るのが重要だというお話がありました。

この状態を作るためには様々なツールがある*1ので使用するツールは個人が選べばいいということでしたが、考える時間が明確に確保できる状態になるというお話しでした。

マネージャーのアウトプット(アウトカム)

マネージャーはチーム全体のアウトプット(=自分のチームのアウトプット+自分が影響を与えた他のチームのアウトプット)が自身のアウトプット*2となるため、自分がどれくらい熱心に働いてもダメで、チームがどれくらいアウトプットを出しているのか？を常に気にする必要があるというお話が出ていました。

マネージメントのしごと

マネージメントのしごととして、以下の4分類が紹介されました。

  • 情報収集(1on1、雑談、メール...)
  • 意思決定(採用決定、面接候補者決定、PRレビュー...)
  • ナッジング(様々なロールの人へ提案、ベストプラクティスの共有)
  • ロールモデル(残業しないこと, 勉強会での発表, 積極的に褒める...を率先して示す)
移譲

マネージャーは自身で手を全て動かすのではなく、人に仕事をやってもらうことが必要なため、デリゲーションポーカーなどを活用して移譲する範囲を人や仕事ごとに決めることが重要だというお話が出ていました。

また、移譲のアンチパターンである、丸投げや自分のやり方の押し付けは絶対にやってはいけないという話もありました。

マネージャーとしての不安

マネージャーはメンバーやチームの仕事に対して不安を覚えることが多いですが、この対応策として、マネージャーは全部が自分通りになることはない(自分が全てをコントロールすることはできない)ことを理解しておくことが重要だというお話がありました。

また、自身の仕事に対して自分でコントロールできる度合いを整理しておくことで、ストレスの軽減が図れるというお話も出ていました。

スタッフの仕事

理想論にはなってしまうものの、仕事に合った人を調達するのではなく、人に合った仕事を調達することが重要だという話が出ていました。

また、当然ながら人によって仕事の好みや興味は変わるため、人ごとに仕事を割り当てることが重要だということです。

1on1

個人の目標設定やキャリア、プロダクトの話...非常に多岐にわたる話を1on1ではするため、1on1のスキルを高めるのは重要だというお話が出ていました。

また、これだけ多岐にわたる話をする場であるため、一ヶ月に一回の頻度では全然足りず、2週間に1回が最低限、できれば1週間に1回は1on1をやった方がいいということでした。

まとめ

「マネージャーはスタッフのために存在するものである」ということを意識しようという話がこれまでの話を踏まえたまとめとして紹介されていました。

Q＆A

よろヒヒーンって原著ではなんて書かれていたのか？

"Hello new neighbor!"だそうです。*3

技術に強みはないEMは成立するのか？

チームの会話やチームで発生する課題は必然的に技術的な話題が多いため、技術的な会話が全然わからないというのは無理だけれども、ある程度話が理解できるレベルならテックリードといった別ロールの人に技術的な部分はフォローを任せ、主領域であるピープルマネジメントに尽力するのは一つの手だというお話が出ていました。

EMがエンジニアからリスペクトされるには？

誠実であり普段の行動から自身が見本となるような行動を率先していれば、技術的にすごい強みがなくてもリスペクトされると思うという話が出ていました。

また、どんな人に対しても安定して(態度を変えずに)接せるかどうかというのも、かなり重要なポイントだということです。

EMのキャリアパスはどのように考えると良い？

エンジニアのためのマネジメントキャリアパスの話が参考になるというお話が出ていました。

ただ、ラダーを必ずしも上げる(チームリーダー→EM→CTO...)必要は別にないので、自身がどういう風になりたいか？というのを考えることが重要だということです。

EM/PM/PdM/テックリードの責任分界点は？

組織によって責任分界点は違うため、一般的な定義を知ろうとすることよりも、自分の組織でどのようなことがそれぞれのロールで求められているか？が重要だというお話が出ていました。

ただ、世間的にはこうだよね、という理解と大幅なずれはまずいということです*4

EMのアンチパターンは？

詳細は本を読んでほしいということですが、日本でよくあるアンチパターン&Ryuzeeさんが考える最大のアンチパターンとしては、PMとEMの兼任を挙げてくれました。

PMはどうしてもデリバリーのプレッシャーがかかるため、ピープルマネジメントを軸に置くEMとは相性が悪いということです。

こういった状況になったときは、シニアエンジニアやテックリードをはじめとした違う人に、PMやEMの移譲をしていくことが重要だということでした。

訓練したメンバーの転職を防ぐには給与以外の要素だと何があるのか？

給与以外と書かれているもののの、やはり給与はとても重要だということでした笑
EMがもし給料を調整できないならエスカレーションするなりした方がいいという話をしていました。

また、それ以外であれば、やはり仕事が面白いかどうか？を本人が実感できていることが重要だということです。

プレイングマネージャーとなっているEMのアンチパターンは？

プライマリーロールの責務を果たすことがまず重要だということです。(EMの責任を全て果たした上で時間が余っているのなら、プレイングしても良い)

また、似たようなパターンとしてSM兼開発者も紹介されていました。
SM兼開発者としてチームに入ると、本人が思っている以上にチームに与える弊害*5は大きいということです。

コーチングなどのスキルをEMではどのように学んでいるのか？

(コーチングスキルが必要かどうかの議論も含めて)正直人や現場によるものの、コーチングの講座を受けるなどが方法として挙げられるということでした。

Ryuzeeさん個人が大事だと思うEMの能力

文章を書くスキル(言語化能力)はかなり重要だと思うとお話をしてくれました。

書いて添削してもらって...というサイクルを回すことで上達できるということです。

EMになるためにまずは何からやるか？

人との関わりがある仕事なので､メンターを務める等、人と関わるタスクをこなしていくことが第一歩ではないかという話が出ていました。

一緒に働いてる人を積極的に助けていくことで、周囲からのFBによってチーム内でもEMとしての素養が認められるのでは？ということです。

EMのアウトプットの方程式は単純な足し算ではなく、比重が変わってるのではないか？変わってくるとしたらどういう能力がEMには求められるのか？

人数などの変数によって比重が変わってくるのは間違いないということでした。
そういった話も踏まえ、課題を具体と抽象で行ったり来たりするのは重要ではないか？ということです。

なお、面倒を見切れる人数は成熟度が高くても10人が限界で、成熟度が低ければ5~7人くらいになると思うということでした。

リファクタリングやEOL対応など不確実性の高い単発タスクをスクラムチームにアサインするのを難しく感じているのだがどうすれば良いか？

解決したい問題の規模感や仕事を進める戦略はエンジニアがプロフェッショナルなので、最終決定権をEMが担う場合があったとしても、エンジニアを信頼して良いのでは？ということでした。

会全体を通した感想

質問もTLもかなり活発で、EMという仕事の注目度の高さや難しさを実感しました。

久しぶりにRyuzeeさんがRyuzeeさん節でプレゼンをしてくれる姿を見ることができて、とっても楽しかったです。

*1:Microsoft TODO, gmail, obsidian...

*2:この書籍でいうアウトプットはアウトカムの概念に近いため、アウトカムとして理解してよい

*3:なお、皆さんご存知の通り(?)みほらぶさんが訳された部分らしいです笑

*4:例えばSMといいつつPMとかは代表的なだめパターン

*5:開発者としての提案でも、SMとしての提案だと受け取られるなど、ロールの判別ができなくなったりコマンドコントロールになったりしてしまう...