かつてEMをやりたくなかった俺たちへ
これは Engineering Manager Advent Calendar 2021 2日目のエントリです。
簡単に自己紹介すると、今年の3月までメルカリでEM(Engineering Manager)をやっていて、今はメルカリのグループ会社であるソウゾウでIC(Indivisual Contributer)として働いています。バックエンドをメインにフロントエンドも書いており、採用周りもちょっと顔を出したりしています。
さて、このエントリではかつて「EMなんて絶対やりたくない！」と思っていた若かりし自分が抱いていたEMに対するもやもやに対して、IC→EM→ICというキャリアを経たいまの自分が答える、という形式で書いていこうと思います。
EMはやりたくないと思っている方の参考になれば幸いです。
EMって何する人なのかわからない
組織によってEMに求められる役割に違いはありますが、マネージャー経験者の多くが読んでいるであろう『High Output Management』では、マネージャーのアウトプットを以下のように定義しています。
マネージャーのアウトプット = 自分の組織のアウトプット + 自分の影響力が及ぶ隣接諸組織のアウトプット
簡単にいうと、組織の成果を最大化させるということです。
…とここまで書きましたが、全然ピンときてないですよね。わかります。
あなたのEMが普段どんな仕事をしていて、それが自分や自分の属するチームにどんないい影響を与えてくれているかが理解できていないのかもしれません。
もしそうなら、シンプルにEMとのコミュニケーションが足りていません。まずは月に1回ペースでお互いの仕事のことなんかをカジュアルに話す場をセットしてみてはどうでしょうか。そうするとEMがどんなことを考えていて（もしくは考えていなくて）、どんな仕事をしているのかわかってくるはずです。
本来EMからICに対してコミュニケーションをとるのが理想的ですが、EMが忙しすぎたりマネジメントスキルが低く何をしたらいいかわかっていない場合もあるので、ICからもコミュニケーションを取りに行ってみるのをおすすめします。ちょっとハードルが高いかもしれませんが、EMからすると案外ありがたかったりするものです。
EMって何が楽しいの
これは人によるところが大きいと思いますが、自分の場合には楽しいと感じるポイントは3つありました。
- やったことがなく、かつ頑張ればできそうなことにチャレンジしている感覚
- 「チームを成長させる」ために必要な裁量が与えられていること
- 採用にがっつり関わることができる
（1つ目は割愛して）2つ目について説明します。Tech Leadやリードエンジニアと言われるような役割がつくと、思考の高さが自分1人からチーム全体に上がります。そうなると、開発のボトルネックをなくしたり、生産性を上げたり、プロダクト全体の安定性を上げたりといったことを求められるようになるでしょう。
そういったことを続けていると、自身の裁量では対応できないような問題についてEMの判断を仰ぐ場面が出てきます。例えば他チームとの業務分掌や業務フローの適正化であったり、チームへのメンバー受け入れであったり、技術的負債の返済と新規機能開発のバランスであったりします。それらを自分で判断できる裁量がもらえるのはEMとしてやりがいを感じる部分です。
3つ目について詳しい説明は不要かもしれませんが、EMになると多くの場合がっつりエンジニア採用にかかわることになります。書類選考や面接を担当するだけでなく、選考フローや選考基準を作ったりアプローチする人材を選んだりもします。
採用というのはEMにとって最もレバレッジがきく業務の1つであることはもちろん、自分と一緒に働くメンバーを自分で決められるのはエキサイティングです*1。
経営と現場の板挟みになって辛そう
板挟みになることはあります。
組織が大きくなるにつれて経営と現場のコミュニケーションコストが大きくなり、直接的な相互理解が難しくなってきます。そのため、EMの業務の1つとして経営のメッセージを適切に現場に伝え、現場のメッセージを経営に伝えることが求められます。
EMとして辛いというかもどかしさを感じることはありますが、誰かがやらないといけない仕事ですし、現場のメンバーが納得感を持って日々仕事ができるようにするために必要な業務です。ただし、EMのような中間管理職のプロキシを介さずとも、経営と現場で直接的にメッセージをやりとりできる仕組みを会社として設けることは非常に大事だと思っています。
エンジニアとしてのスキルが落ちそう
コードを書く速度は確実に落ちます（キッパリ）。なぜならコードを書く機会が減るからです。
新しい技術トピックを調べたり業務の中でそれを試したりする機会も減るでしょう。
ただ、EMも業務としてメンバーの評価をしたり技術的な意思決定をする場面があるため、ICのときほど技術にdeep diveする時間はなかったとしてもトピックを抑えておく程度の技術的なインプットは必要です。
私がEMになりたての頃はコーディングから離れるのが怖くて毎日コードを書くための時間を確保していましたが、EMとして経験を積んでできることが増えていくにつれて徐々にコードを書く時間は減っていきました。プライベートでコツコツ技術の勉強をするのがあまり得意でないので、チーム内の勉強会に参加したり1on1で詳しいメンバーに知識を教えてもらったりしてなんとかキャッチアップしていました。もちろん、プライベートの時間でコードを書いているEMもいました。
一方で、エンジニアのスキルは最新の技術トピックを知っていたり良い設計ができたりコードを速く書けたりすることだけではありません。
もちろん、そういったスキルを職人的に磨き続け技術的難易度の高い課題を解くことを専門にするキャリアもあります。しかし、ビジネス観点を持ってPMやBizDevと相談しながら開発計画を立てたり、開発プロセスを改善してチームの生産性を上げたりすることもエンジニアのスキルです。
その意味では、EMになったからといってエンジニアとしてのスキルが落ちるわけではなくスキルの幅が広がるという考え方もできます。
…とここまで書きましたがやっぱりコードを書く機会が減るのは自分としてはとても悲しかったです。それもあって今はICに戻りました。
一度EMになったらもうICには戻れなさそう
戻れます。というか戻れました。
1年半のブランクがあったため、開発初期にはLinuxコマンドやらGo言語の仕様やらを思い出すのが大変だったり、さらには今まで触ったことのない技術へのチャレンジやタイトなスケジュールもあいまって頭がパンクしそうでしたし自分のあまりのできなさに落ち込んだりもしました。
しかし、そんな時期も1ヶ月くらいすると慣れて以前と同様にコードを書けるようになっていました。
正直に言うとブランクのある自分がどの程度コードが書けるのか非常に不安だったのですが、思っていたほどのコーディングスキルの衰えは感じませんでした。加えて、PMやCSとのコミュニケーションがスムーズに行えたり、自分から開発仕様を決めるように周りを巻き込みながら推進できたりと、EMをやっていたことによる自身の成長を感じることもできました。
ブランク期間が3年、5年などもっと長かったらこうはいかなかったかもしれませんが、少なくとも1年半程度であれば自分のようなコーディングスキルが決して高くないエンジニアでもICに戻ることはできました。
さいごに
IC→EM→ICというキャリアを経たいまですが、もう一度EMに戻るのも全然アリだなと思っています。
冒頭で書いたとおりEMの役割は組織によって違うので、1度EMをやった組織とまた別の組織でEMをやるのは面白そうだと思うからです。担当するチームやメンバーの成長に少しでも貢献できたり、それによってよいプロダクトがリリースされるのを見るのはICとはまた別のやりがいがあります。
散々ポエムを書きなぐってしまいましたが、ざっくばらんにこのあたりを話してみてもいいよ！という方はぜひmeetyからご連絡ください。
12/3追記：
時期を同じくして弊社のオウンドメディアでも近いことを話しているのでご興味あればこちらもご覧ください。
*1:自分のチームに配属されたエンジニアが微妙だったり、受け入れたくない人を受け入れざるを得なかった経験は誰しもあるのではないでしょうか
『ジェンダーについて大学生が真剣に考えてみた』を読んで考えてみた
きっかけはりっちゃさんのこのツイート。
森さん発言で関心が高まってる今だからこそ、ジェンダーギャップに関心持ったらまず読んで欲しい本。
— りっちゃ (@r1ccha) 2021年2月5日
どれも学術研究やデータに基づいた良書です。
特に、男性で発言しづらいがまず何から学べばいいんだ？と思ってるマネジメントや経営者の方へ。
貼ってる順がおすすめ。 pic.twitter.com/JrNGw1bm4D
最近、D&Iについて興味が出てきて WORK DESIGN(ワークデザイン) を読み始めているのですが、他の本も読んでみたいと思っていたところだったのでポチって読んでみました。
このエントリでは、『ジェンダーについて大学生が真剣に考えてみた』（以下、本書）を読んで自分が考えたことや調べたことを書こうと思います。
続きを読む
エンジニアリングマネージャー1年目で読んだ本
はじめに
2019年を振り返る - るさんちまん に書いた通り、昨年10月からエンジニアリングマネージャー（以下EM）になり1年ちょっと経ちました。
キャリアを通じて初めてのマネージャー職となったため、まずは（組織|チーム|ヒューマン）マネジメントに関する最低限の知識を書籍から得ようと思い新しく本を読んだり以前読んだ本を読み返したりしていました。
年末ということもあり、Amazonの購入履歴をたどりつつ当時考えたことを思い出しながら感想を書いていこうと思います。これからマネージャーになる方へ、少しでも参考になれば幸いです。
読んだ本
経営学の論文やデータをベースに、「なぜ大企業は革新的イノベーションについていけないのか」「男性中心職場での『できる女』の条件」といったよく議論されるいくつかの経営のトピックについて筆者の考察を述べている一冊。
個人的には「日本企業に、ダイバーシティー経営は本当に必要か」の章が非常に興味深く、自身がずっと疑問に思っていたことの一つの回答が得られて頭がスッキリした思いでした。
多様性には「タスク型（能力・経験等）」と「デモグラフィー型（性別・国籍・年齢等）」の2種類あり、前者は組織パフォーマンスにプラスの影響があるが後者は影響なし、もしくはマイナス影響があることが経営学の論文で示されている
— なおぱー (@naopr) 2019年11月3日
エンジニアリング組織論への招待
エンジニアリングとは不確実性を効率よく削減することであり、不確実性は「未来」と「他人」の2種類がある、という前提からアジャイルの概念やメンタリング、組織開発について明快かつ具体的に書かれています。
マネージャーだけでなくエンジニア誰しも読んでおいて損のない一冊です。
エンジニアのためのマネジメントキャリアパス
エンジニアのためのマネジメントキャリアパス ―テックリードからCTOまでマネジメントスキル向上ガイド
- 作者:Camille Fournier
- 発売日: 2018/09/26
- メディア: 単行本（ソフトカバー）
1エンジニアから経営幹部まで、それぞれのポジションで考えるべきことややるべきこと、アンチパターンが非常に具体的に書かれており、自身の役割が変わるたびに何度でも読み返したくなる本です。
1.2章の「管理のされ方」は「上司が自分のことをわかってくれない」と嘆く若手エンジニアや「部下から信頼されていない・評価が低い」と感じているマネージャーにとって役に立つエッセンスが多いと感じます。
今いるメンバーで「大金星」を挙げるチームの法則
マンガ『ジャイアントキリング』に登場するサッカーチームの監督・達海猛が行った（一見非常識な）チームビルディング手法を、実際のビジネスの現場と照らし合わせて紹介する一冊。私はこのマンガのファンでもありEMになる前からこの本は読んでいたのですが、あらためて読み返しました。
アジャイルの文脈でもよく取り上げられるチームの4つのフェーズ「フォーミング」「ストーミング」「ノーミング」「トランスフォーミング」において必要なコーチング手法をわかりやすく解説してくれており、私も実際にこのエッセンスを現場でも取り入れています。
HIGH OUTPUT MANAGEMENT
- 作者:アンドリュー・S・グローブ
- 発売日: 2017/01/11
- メディア: Kindle版
インテルの元CEOがインテル流のマネジメント手法についてノウハウを書き記したマネージャーのバイブル的な一冊。 「マネージャーのアウトプットとは『自分の組織のアウトプット＋自分の影響力が及ぶ隣接組織のアウトプット』」という定義が単純にして本質であると感じます。
抽象的・観念的な話題だけでなく1on1等のミーティングの準備や進め方についのベストプラクティスについても紹介されており、私も「評価フィードバックミーティング前にフィードバック内容をあらかじめ読んでおいてもらってからミーティングを行う」というプラクティスを取り入れるようになりました*1。
おわりに
ここまで書いてきてなんですが、ぶっちゃけて言うと本を読んだだけでいい感じにふるまえるほどマネジメント業務や現場の課題解決は簡単ではないと感じています。ただ、書籍を通して一般的なマネジメントの"型"や先人たちの知恵をうっすらとでも頭に入れておくことによって、自身が直面する課題に対する解決の方向性が見えたり、取りうるアクションの候補を瞬時に思い浮かべることができたりと、プラスの効果があったかなという実感があります。
来年もマネジメントに関するインプットを続けたいと思っているので、おすすめの書籍があればぜひ教えていただけると嬉しいです。
*1:もちろん、評価の内容やメンバーとの関係性・性格によってそうしない場合もあります
認定スクラムマスター(LSM)資格をとった
Scrum Inc.認定資格スクラムマスター研修を受けてきたのでその内容を書いておこうと思います。
研修を受けた動機
現職で2年ほど前からプロダクト組織全体にスクラムが導入されはじめ、私がマネージャーとして担当するチームでもスクラム開発を取り入れるようになりました。
ここ最近社外のアジャイルコーチにアドバイスをもらうことになり、そのアドバイスが的確でチームの課題発見・解決の速度が上がったことにチーム全体が驚きを感じていました。 チームにポジティブな変化が起こるのを見ているうちに、「自分がスクラムのことをもっと知ることはチームへの大きな貢献につながるのではないか」と思うようになりました。
そこで、自分の今の知識がどの程度なのか知ること、また研修を通して実務に生かせるような学びを得ることを目的にスクラム研修を受けることにしました。
スクラムマスター研修といえば私が今回受講したLSM(Licensed Scrum Master)よりもCSM(Certified Scrum Master)のほうがメジャーですが、研修日程の都合から今回はLSMを受講することとしました。
研修概要
今回私が受けたScrum Inc.認定資格スクラムマスター研修は、下記のような研修でした。
- 9時〜18時×2日間
- Zoomでのオンライン開催
- 日本人講師（荒本さん）
- 費用：22万円/人
研修内容
研修は下記の4部構成となっており、それぞれのパートで座学とチームエクササイズを半々くらいの時間配分で行いました。
受講者6人+コーチで1つのチームを作り、チームエクササイズはその固定チームで2日間行っていきます。
チームを組んだ際にはPO(Product Owner)役とSM(Scrum Master)役を決めます。エクササイズのファシリテーションをSMが行い、バックログの作成をPOが行ったりと、擬似的にスクラムチームの業務を体験できるようになっています。 私のチームではSM役とPO役をローテーションすることで全員に学びが得られるよう工夫しました。
残念ながら講義の資料やエクササイズで使ったスプレッドシートは公開NGということでここには載せられないのですが、例として下記のようなエクササイズを行いました。
- チームメンバーがこの研修を通じて達成したいことをストーリーとしてチームのバックログを作る
- 与えられたエピックに対してストーリーを皆で列挙してPOを中心にディスカッションを通じて優先順位をつける
- とあるシチュエーションに対して「あなたがSMならどうする？」を考えてチームでディスカッションする
試験
2日間の研修が終わると、すぐにWebで試験を受けられるようになります。
試験の内容は基本的なスクラムの知識を問うものばかりで、研修の内容を理解していれば解ける問題しかありませんでした。また、試験中に研修資料を見たりググったりしてもよいということを考えると合格は容易と言えるでしょう。
認定スクラムマスター（LSM）に合格したぞ！試験は満点だったぞ（えっへん）！ pic.twitter.com/eBQ0NevOQn
— なおぱー (@naopr) 2020年11月22日
研修を受けた感想
今回私が受けたLSMの対象受講者は「スクラムを経験したことが全くない」「スクラムのセレモニーをいくつかチームでやっている」といった習熟度の方なのかなと感じました。私のチームメンバーもそういった方が多かったです。
そういう意味だとスクラムを曲がりなりにも2年経験しており、スクラムに関する書籍も数冊読破している自分には新鮮味がなく少々物足りない研修でした。
ただ、研修の途中からは「（アジャイルコーチ目線で）チームメンバーの学びをいかに大きくするか」を考えた発言やファシリテーションを行うようになり、マネージャーとしてチームにスクラムについての理解を促す疑似体験ができたのは良い経験でした。
また、自分の今のスクラム習熟度を客観的に見ることができたので、自分の持っている知識が今の環境に偏ったものでなく一般的に通用するものだと認識できたことも収穫でした。
最後に、同時期にCSMを受けた同僚のエントリがとても面白いのでこちらもぜひご覧ください。
