ohbaryeが2018年に書いた記事を唐突に振り返ってみる*1。
全体的に登壇した系のイベントレポートが多い。その権化というかまとめとしての一位の記事は「読みました」って言ってくれる人が多くて嬉しかった。
技術記事の割合が少ないので今年はもう少し増やしていきたい
valid,invalidの2018年ブックマークランキングベスト32(累計1023ブックマーク)
generated by 年間ブックマークランキングジェネレーター
*1:振り返るのが遅いので一部2019年の記事が入っている
Facebookにおけるエンジニアリングマネジメント (Inside Facebook Mobile ep.5)
Inside Facebook Mobile という podcast の以下のエピソードが面白いと @hotchemi さんから教えてもらったので聞いてみた。
Inside Facebook Mobile について
この podcast のことはよくわかっていないが、上述の放送回は Facebook の London オフィスで働く Balazs 氏が彼のプロジェクトや経歴・現在の仕事について話す回だった。
50分ほどのエピソードのうち後半（28:45あたり以降）はまるまるエンジニアリングマネジメントについて語っており、印象に残る点が多かった。
メモ
ホストの2人が質問して Balazs 氏が答えていくスタイル。なので質問を見出しにして回答や語られたことを箇条書きでメモした*1。
How do the transition happen?
- もともとやりたかったこと。キャリアの早いうちにマネジメントぽいことを少しやっていた。
- 仕事で人を助けることに興味がある
- 一方コーディングも大好きなのでマネジメントの仕事をするかどうかは迷った
- 最初は半年ぐらいマネジャーをやって、その後はいちプログラマに戻ろうかと思っていたが、そうならなかった
思ったよりハマった
Facebookではマネジャーになることはプロモーションではない
- マネジャーはサポートする役割
マネジャーと技術
マネジャーになるということはコードを書くのをやめるということ？テクニカルバックグラウンドがなくてもマネジャーになれる？
- テクニカルバックグラウンドなしにマネジャーにはなれない
- Facebookのマネジャーは全員スーパーテクニカル
- ミーティングのリード、チームの方向性を決めるのはマネジャーではなくシニアエンジニアの役割
- マネジャーとして最も大事なことの一つはエンジニアのサポート
- テクニカルリーダーというより人々のサポーター
テックリードとマネジャーの違いは？
- 良い例がある、今の自分のチームにシニアエンジニアがいて、チームのことは全部彼女がやっている
- ミーティングのファシリテーション、チームのミッションづくり、ロードマップ作成、チームメンバーの技術面での成長のために1-on-1もやっている
- 私はガイダンスを行ったり、オフサイトをやったりとか…(笑)
1-on-1のスタイルは？
- 人によってぜんぜん違う
- 大事なのはhave it consistently、マネジャーが助けられるように問題を話してくれるとか、そういう信頼を築くため
- weeklyで全員とやっている
- 常にお願いしていることは、1-on-1はエンジニア（メンティー）のための時間
- 内容はキャリア開発、テクニカルな議論、現状の共有など
良いマネジャーに必要なスキルは？
- 大きな誤解の一つは、良いマネジャーであるには良いエンジニアであること、というもの
- ぜんぜん違う専門性、エンジニアキャリアの延長線上でもない
- とはいえエンジニアの専門性があることは、メンバーの話を理解したり共感するために大事
- one of the key things is empathy
- good communication skills
- エンジニアの成功で幸せを感じることができるか
- いちエンジニアとして以前はhigh achieverだった
- あれもこれもリリースできた！でも自分は何もやっていない！
- そんな状況でも思ったより喜べた、というのが印象深い
どんなトレーニングがある？
- 内部トレーニングがいっぱいある
- （Balazs氏が所属するLondonオフィスでは）マネジャーになったときはトレーニングがぜんぜんなかったんだけど、マネジャーになってから1年後にできたので受けてみたらすごく良かった
- 1年前に欲しかった〜、既に知ってることだ〜
マネジャーになるプロセス
Facebookの外からマネジャーとして入社することはある？
- マネジャーの採用計画はある
- しかしとても経験豊富な人しか採用しないし、技術にも明るくなければいけない
- マネジャーへのインタビュープロセスはエンジニアに対するものとほぼ同じ
- ホワイトボードコーディングテストもある、でも現時点でどれだけコードを書けるかというより最盛期にどれだけだったかを測る
- これはとても難しいことがある
フィードバック
- オープンなフィードバックを行うカルチャーは自分がFacebookに残る理由
- 誰もが誰もに深みのあるフィードバックを送る
- フィードバックの仕方に関するトレーニングがある
- performance feedback every half year
- マネジャーはフィードバックをそれぞれのエンジニア、カスタマー、パートナー、同僚などから集める
- マネジャーは改善すべきこと、何にフォーカスするかを考える
- ときにはオープンで厳しいフィードバックをすることもあるが、これをいかに効果的に行うか学ぶことができる
- これは4年間で最も自分を変えたことの一つ
- 今ではフィードバックを貰うのを心待ちにしている
- ときには厳しいフィードバックを自分も受けたことはあるがとても有意義だった
- フィードバックは他人を打ちのめすものではなく成長を助けるものと理解
- Facebookの良いところは、受け取ったフィードバックに基づいて何を改善するかをマネジャーと一緒に考えるところ
- マネジャーからの一方向でなく双方向で送り合うのが本当に良いカルチャー
良いマネジャーになるには？
エンジニアにとっての成長は最新の技術をおさえたり、たくさん機能を作ったり改良したりすることが挙げられる
- エンジニアリングの分野ほど急速に変化はしないけど大切なことを学ぶ
- 脳のはたらきとか社会のはたらき、抽象的な事柄
- 読書したり、最新の情報を漁ったり、コミュニケーションに関するスキルについていかに小さくても学んだり
- こうした学問は、たとえば何も話してくれないメンバーと向き合うとか、マネジャーとしてとても役に立つ
チームの目標・ロードマップ
- Facebookはとてもボトムアップな会社
- 強くて賢い人を雇ってミッションを見せる、あとは何をするかは各々に見つけさせる会社
- エンジニアが解決すべき問題を見つけてマネジャーやチームと議論する
- 皆で「最もインパクトが大きいやるべきこと」を話す
- 入社してマネジャーに自分のキャリアや強みを話したら、マネジャーからは「それじゃあ何やりたい？」
- 何をしたいかを決めると同時に、それがベストな選択であると示すことも各自の責任になっている
いま挑戦していることは？
- かつては自分の行動や自分が達成したことに対してresponsibleだった
- 今はチームの成功に対して責任を持っている
- 自分のゴールはインパクトをもたらすようなdeliverが自律的にできるチームを作ること
- チームに「○○をしろ」と言うことはできない
- 有能な人を連れてくるのもマネジャーの仕事
- （エンジニアからマネジャーになっての）マインドセットの変化は大きく、チャレンジング
- Facebookにはたくさんのスモールチームがあり、誰もが好きなことをできるので百のスタートアップの集合みたいになっている
- 他のチームがやっていることをちゃんと把握してコンフリクトしたり被ったりしないようにするのはマネジャーの仕事であり、これもまた挑戦
Further more
"Facebook Engineering Management" とかでググると他にも情報が出てくるので知りたい人は読んでみると良さそう。
「Facebookでの Engineering Manager ってどんな感じ？」という質問に対して、management は人やチームによって大きく変わるので唯一の答えはなさそうだ、という回答。
podcast で語っていたような「社内に100のスタートアップがある」とか、社内のチームによって働き方が全く違うというのに真実味がある。一方、マネジャーが何に対して責任を持つかは不変的だということも書いてある。
Glassdoor には従業員からのレビューが載っている。Pros にも Cons にもワークライフバランスが挙げられており、これもチームによって全く違いそう。
同時通訳がいるときのプレゼンで気を付けること
前回の記事で書き忘れていたのだが、RSGT2019で行ったプレゼンでは日→英の同時通訳 (interpreter) の方に付いていただいた。
通訳付きのプレゼンをするのは自分にとって初めての経験であり、予想外だったことやうまくいかなかったことがあったのでメモしておく。
準備からプレゼンまでの流れ
おそらく通訳の方・会社・イベント・言語など様々な変数で変わるのだろうが、今回は以下の流れで行った。
- 事前に資料を提出する
- 事前に資料を見ながら打ち合わせをする
- プレゼンをする
- お礼を言う
1. 事前に資料を提出する
RSGT2019ではイベントの1~2週間前には資料を提出するように案内があった。
自分の観測範囲では「テック系のイベントでそんなに早く資料準備してるやつ、おるか…??」という雰囲気なのだが、通訳者の方に事前に資料を読んでもらう工程が挟まるので締切は無論守ったほうが良い。
また、提出後の資料の大幅な訂正は止めたほうが良い。
今回ナルホドと思ったのだが、通訳者は資料を印刷して紙にメモを書き込んでいた*1。そのため提出後に修正していると直前の打ち合わせ（最悪の場合、本番）になって「あれ、手元の資料と投影資料が違う…!?」という問題が起きる。
自分も前日に訂正していたのだが、Google slidesを使っていたので打ち合わせのときにはお互い最新の状態を参照して話ができるだろうと高をくくっていた。が、ダメ…っ！「すみません、こちら修正してまして…」と頭を下げることになった。また、別の登壇者の資料はだいぶ激しく変わっていたようで、打ち合わせの際に資料を印刷し直したりしていた。
2. 事前に資料を見ながら打ち合わせをする
イベントの開始前または休憩時間を利用して通訳者との打ち合わせを行う*2。今回は20分の発表のために12分ほどの打ち合わせを行った。
まず最初に聞かれたのは「一番伝えたいことはなんですか？」という質問だった。なるほど、すごく良い質問ですね...!!
次が「話の構成・骨子を教えてください」というもの。今回の自分の発表はケーススタディだったので「1. 前提共有、2. 事例紹介、3. 得られた学び」という簡単なステップを説明した。「1のステップを5~6分で終わらせるつもりです」のように時間配分を伝えると「その情報があると大変助かります」と褒められた。今回に限って言うと、20分の発表の間に2名の通訳者が入れ替わりつつ進めるスタイルだったので、どこで区切るかが明確でよかったというのもある。
そのあとはスライドを一枚一枚めくりながら内容をあっさり説明していく。
専門用語や固有名詞がある場合は都度説明を行う。専門用語として使われる英単語が決まっている場合はそれを伝える。他にも"Kata (型)"のような日本語でそのまま輸出されているような概念はあえて訳さないでくれ、と伝える必要がある。
スライドに書いているけど触れないところ・スライドに書いていないけど話すことなども伝えていく。このへんはちゃんと練習して流れを作れていないと実りある打ち合わせにならないと思う。特にスライドに書いていないけど話すことを伝えることが通訳者にとっては大事だと仰っていた。今回の自分のスライドは文字が多めだったのだが「スライド上には絵だけ、口頭で補足する」のようなスタイルだともっと打ち合わせが大変になっていたかもしれない。
あとで調べて知った話なのだが、ジョークや笑いどころを伝えるのは文化の違いなどのために表現が難しいらしく、設ける場合は事前に伝えると良いらしい。自分のギャグを自分で説明するという大変恥ずかしい思いをしそうなのでこれは辛そう…。
余談だが、発表持ち時間とスライド枚数の相関はなんとなく通訳者の方々も感覚値として持っているようで、今回の20分でスライド70枚超えという自分の状況に対して「本当に20分で終わりますか？」というツッコミをもらった。
3. プレゼンをする
あとは打ち合わせ通りやるだけ、なのだが普段のプレゼンとは違って幾つか気をつける必要があった。打ち合わせで話した流れ・内容からなるべくはずれないようにする、ゆっくりしゃべる、一文を短くする、断定口調で言い切る等々。切りの良いところで休憩がてら水を飲んだりもした。
まぁ正直やっている最中は同時通訳のことを気にかけている余裕がほとんどなく、こんな感じ↓なのだが…。
通訳の方にゆっくり喋ってくださいって言われたのにオタク文法の早口でまくしたててしまった#RSGT2019
— 広島の粗大ゴミ (@ohbarye) January 10, 2019
通訳の方も「あまりに早口だと内容が"落ちる"ことはある」と仰っていたのでこれは実に良くないです。
ちなみに今回は質疑応答の時間は取れなかったのだが、もし英語で質問があればそれを日本語に同時通訳してもらうのだと思う。
4. お礼を言う
通訳の方を捕まえてお礼を言う。こちらにとっては休憩時間だとしても通訳者は次のプレゼンに備えていることもあるので邪魔しないよう気をつける。
気を付けることまとめ
一連の流れを踏まえて同時通訳がいるときのプレゼンで気を付けることをまとめる。一部は通訳がなくても当たり前のことだが、より重要性が増すものとして記述する。
事前準備
- 資料は早めに「完成」させ、期限通りに提出する
- 「完成」とは資料を書き上げるだけでなく発声練習を通じて表現や構成が磨き込まれた状態
- 資料は文字多めのほうが通訳者としては安心かも
- スライドとは別にスピーカーノートを用意して共有するのであれば文字少なめでも大丈夫だと思う
- 提出後は資料を修正しない
- ほんの少し（言い回しを変えるぐらい）ならまだ大丈夫だがページが増減するレベルだとやばい
- 最も伝えたいこと、話の構成をすぐに説明できるようにしておく
- 時間配分（アジェンダのn番目でm分ぐらい経過している想定）を決めておく
- プレゼン内で触れる専門用語や概念の英語表現を調べておく
- ジョークを挟むなら事前に相談する
個人的にはイベントの1週間以上前に複数回の練習を終えて練度を高めた状態の資料を提出するのが一番むずかしいな…
プレゼン
主に話し方
- 打ち合わせで話した流れ・内容からなるべくはずれないようにする
- ゆっくり喋る
- 一文を短くする
- 断定口調で言い切る
- 主語を明言する
- 可能なら良い感じに休憩を挟む
- 終わったらお礼を言う
そしてこの記事を書きつつ今更ながら自分の発表がどのように英訳されたのかがすごく気になってきたので、「通訳内容を誰かに頼んで録音しておいてもらう」というのも次の機会があればやってみたい。
同時通訳付きでいつもと違うプレッシャーはあったものの勉強になってよかった、今となっては同時通訳無しはイージーモードなはずだ!!
#RSGT2019 で『プロダクトの「負債」を「機能」と呼び直すために』というプレゼンをしました
Regional Scrum Gathering Tokyo 2019に初参加してきた。
発表した
「応募してみたらどうか」という"圧"を感じたので勢いで応募してみたら、期限ぎりぎりだったにも関わらず選んでもらえた!!
『プロダクトの「負債」を「機能」と呼び直すために ーA/Bテストを用いた"価値"の定量化ー』
内容は過去にQuipper Product Team blogで書いた記事でもあるし、Rails Developer Meetupでも発表したもの。なのでそのまま再演するのはどうかなぁと思ったのだが、幸いにも聴衆があまり被っていなさそうということでほとんどアレンジせずにいくことにした。
新しいフィードバックが貰えると良いなと思っていたら本当に貰えて良かった。
また、初めて通訳つきのプレゼンをしたのだが、いったいどのように訳されていたのか、とても気になる…。
通訳の方にゆっくり喋ってくださいって言われたのにオタク文法の早口でまくしたててしまった#RSGT2019
— 広島の粗大ゴミ (@ohbarye) January 10, 2019
皆さんの発表
それぞれの発表に触れると長くなってしまうので、特に印象に残っているもの3つまで。
#RSGT2019 ちゃんとやってるのに なんかうまくいかないスクラム からの脱出 - Speaker Deck
今回いちばん得るものが大きかったというか、自分の問題意識に近いと感じたプレゼンだった。
ここめっちゃ良い / "「期待」はスクラムと相性がよくない" "スクラムは現実を見せ続ける" / “number-rsgt2019-tiyantoyatuterufalseni-nankaumakuikanaisukuramu-…” https://t.co/BuE4pToxpZ
— 広島の粗大ゴミ (@ohbarye) 2019年1月9日
自分のチームでは去年の暮れから初めてスクラムをやりはじめたのだけど、なんとなくチームや自分が背伸びしてしまうような感覚があった。ベロシティが低いときの不安とかプランニングでアイテムを積んでいくときの根拠ない自信とか。そういう気持ちの大部分は期待しすぎていたのかなーと腑に落ちたりした。
そういう期待もあってか、全体としての未着手領域を減らすとか色んなことを並行で進めるとかいうことに意識が向いていてぜんぜん一本道じゃないな、と実感できた。休み明けはこの辺の整理からちゃんとやっていく。
また、@bufferingさんはオンライン上で見知っていたのだけど一度も話せていなかったものの、RSGT2019でようやくお会いすることができて良かった!! @ama_ch さんも交えた立ち話からも高密度で得るものがあった。
ファシリテーションの難しさと楽しさ - Speaker Deck
業務でよくファシリテーションするんだけど、誰から学んだわけでも深く掘り下げたわけでもないのでとても気になっていた内容。わりと自分がファシリテーション下手ー特に喋りすぎるという点においてーだという"現実"が見えたので良かった。
そのときサーバントリーダーはどう振る舞うか - Speaker Deck
Engineering Manager Meetupでも熱くなれそうな話題。3日目にはRochelle Koppさん、Kinugawaさんと同じテーブルでディスカッション出来たのも良かった。
サーバントリーダーの話、完全に #em_meetup で盛り上がる話題だ#RSGT2019
— 広島の粗大ゴミ (@ohbarye) 2019年1月10日
聞き手としては、全く実践したことがないもしくは上司が旧来型なので苦労しているみたいな層が中心だったのかもしれない。EM Meetupの参加者層だと、実践したうえでの発見や学び・悩みといった内容でもう一歩先の議論が始まりそうな気がした。
所感
ぜんぜん関わったことないコミュニティなのでいろいろ新鮮だった。イベントのそこかしこで会話が生まれていて、そういう"場"づくりができているのが凄いと感じた。（ふつう初対面の人どうしでそんなに話さなくないか？ってぐらい）
一方、Not for meかなと思った点も無くはなく… ビジネスモデルや会社の状況が自分とかなり遠い人もけっこう多く、問題意識や悩み事が（僕が話した限りでは）噛み合わないなと思うこともあった。（クライアントからの無茶ぶりとか、ぎすぎすして心理的安全性がゼロとか、スクラムをやらせてもらうための説得とか、上司が非技術者だとかトップダウンで最悪 etc. 自分はそういう問題に当事者としての真剣味がないので議論やアドバイスになりにくい）
だがやっぱりすごい知見に溢れ、自分の課題より遙か先を歩いている人々が集まっていたのも事実で、そこからは本当に真摯に学ばせてもらった。
マネジメントスタイルの選択基準、一貫的スタイルを持つことの困難
マネジメントスタイルは対象となるメンバーだけでなく、時々の状況や幾つかの要因によって変えるべきものだという話です。
本記事は『HIGH OUTPUT MANAGEMENT』を読んだうえで自分の観測範囲と経験に照らし合わせた感想なので、詳細が気になる方は同書の第12章を読むことをおすすめします。
続きを読むNode学園祭 #nodefest で『貢献できるOSSの見つけ方 -完結編-』という発表をしてきました
最後*1のNode学園祭で『How to find "Good First Issues" / 貢献できるOSSの見つけ方 -完結編-』という発表をしてきました。
発表
半年間、自分を騙しながらアウトプットに積極的になってみた - valid,invalid に書いたように今年はこれまでより一層アウトプットを意識した年で、そのアウトプットの少なくない割合を占めた OSS Contribution において遭遇した課題とそれをどのように乗り越えたかを中心に話しました。その過程で作った goofi というアプリケーションの話も盛り込みました。
資料
所感など
はじめての30分枠
まず30分枠の発表は初めてだったのでまずはそのあたりから。
最初に思ったのは、何よりも流れが大事で、課題設定とその共有に失敗すると30分空振りし続ける羽目になるだろうということ。流れさえちゃんと用意できていれば途中である程度時間をコントロールでき、時間の余裕が落ち着いて話すことに繋がると感じました。これは5分LTや10分だと難しいかなと。
早期練習（しなさい）
ただ、資料を作っただけでは所要時間が読めないのでとにかく練習が大事…そんなことはやる前からわかっていたものの、一回の練習に30分かかるので腰が重いという問題がありました。放って置くとやらないまま直前を迎えそうだったので、初めての通し練習（＋2回目）は同僚に聴衆役をお願いすることにし、予めスケジュールに入れました。
同僚の前で、Google documentにフィードバックを書いてもらう方式の発表練習を2回してその結果をぜんぶ反映させたらすごく改善された実感がある。めちゃめちゃありがたい🙏 #nodefest pic.twitter.com/TJEQQ1l3nL
— 広島の粗大ゴミ (@ohbarye) November 22, 2018
最後の最後にレビューをお願いするのではなく1回目の練習からフィードバックを貰ったおかげで軌道修正が早期に行えて最高でした。このあたりは以下の記事で書いたテクニックです。
Node学園祭について
自分の出番までは完全に精神が終わっていました。
登壇当日は早く終わってほしい気持ちが先行して他人の発表を聞く余裕が未だにぜんぜんない
— 広島の粗大ゴミ (@ohbarye) November 23, 2018
唯一楽しめたのは紀尾井タワー2階のランチというザマです。
#nodefest lunch pic.twitter.com/g3ZhMC8PxO
— 広島の粗大ゴミ (@ohbarye) November 23, 2018
面白そうなセッションがいっぱいあったのでこれは本当に勿体なかった。
最後に
資料を作りながらなんとなく今回の発表が今年の集大成のような気がしていました。時期もやり方もばらばらだった自分の過去のアウトプット (pull requests、コード、ブログ、思想、アイデア) を集めているうちに点と点が繋がる感触がありました。
そう思っているとなんと発表練習を聞いた同僚から「全体的にohbaryeさんの今年の全てが詰まっている感じがして他人事ながら勝手に感極まるものがあった」というフィードバックがあり、僕もまた感極まってました。
そんな感極まりループの外でこんなこともありました。
#nodefest で「 #emfm に出てた方だったんですね」と言われて驚きつつ、 #emfm の勢いを感じる
— 広島の粗大ゴミ (@ohbarye) November 23, 2018
風…なんだろう吹いてきてる確実に
アウトプット疲れも少なからずあるのですが、別ベクトルの活動の点が繋がってくるような体験を経てやはり今は射撃しつつ前進するしかないのだという気持ちを新たにできて良かったです。
今年の残る活動機会は Engineering Manager Meetup #3 ぐらいかと思いますが最後まで走り抜けたいと思います。 ウオーッ
Engineering Manager Meetup #2 をやりました & 第3回の告知 #em_meetup
Engineering Manager Meetup #2 を開催しました。
engineering-manager-meetup.connpass.com
前回は開催直後に熱と勢いだけで6,744字の雑文を書いてしまったので、今回は開催から約2週間経ってクールダウンした状態で振り返り記事を書いてみました。結果なんと5,044字に収まり、約25%の削減に成功です。
@aomoriringoさんにより振る舞われた至高のハム
3行まとめ
- 第1回に引き続き盛り上がりを見せたことで再現性があるとわかった
- 回を重ねることやBYOB*1など、主体的参加を促す工夫ができそう
- 第3回はプレゼンありの形式でやります。2018-12-14(金) connpass ページはこちらです
Engineering Manager Meetup とは?
イベント開催の動機や趣旨については Engineering Manager Meetup をやります - valid,invalid を、第1回のようすについては Engineering Manager Meetup #1 をやりました #em_meetup - valid,invalid をご参照ください。
当日のようす
@beppu01 さんがまとめてくださった togetter や、参加者の皆さんによるブログをシュッと貼っておきます。
- 悩めるエンジニアリングマネージャが『Engineering Manager Meetup #2』に参加した #em_meetup - dskst's diary
- Engineering Manager Meetup #2 に行ってきた - progrhyme's tech blog
- Engineering Manager Meetup #2に飛び込んできた。 - どこぞのエンジニアなマネージャーだった人のブログ。
- Engineering Manager Meetup #2に参加しました - アルパカログ
書いてくださった皆さん、本当にありがとうございます！（漏れていたら申し訳ありません、お伝えいただければシュッと足します）
OST再考
第1回と同じくOST（オープンスペーステクノロジー）でのディスカッションを採用しました。OSTをご存知無い方は OST（オープン・スペース・テクノロジー）｜キーワード｜HUMAN VALUE をご参照ください。
さて、第1回にて同方式を実施した結果が掛け値なしに最高だったわけですが、果たしてその結果に再現性があるのかどうか。その疑問に答えるためにEngineering Manager Meetup第2回もOSTを採用しました。
結論から言うなれば、再現性は有り寄りの有りでした。
「OSTは何について話し合うのかを参加者主導で決めるうえに、ファシリテーションも何もかもが参加者に委ねられています。なのでこの会が有意義なものになるかどうかは皆さん次第です」
この前説を毎度しておりますがこれは本当にその通りで、Engineering Managementやその周辺領域に関心や情熱があり、互いに意見を交わしたりファシリテーションをいとわない方が集まった時点で結果が約束されました。
印象に残った話
Engineering Managerをどう育てるか
@otoyo0122さんがファシリテーターとなったテーマ。こちらに僕も参加しました。
テーマ「Engineering Managerをどう育てるか」
— 広島の粗大ゴミ (@ohbarye) 2018年10月26日
- テックリードなどに比べて、志向する人がいない
- そもそも何やってるか知られてない
- やっている人が楽しくないとやりたいと思えない
これは #emfm 案件ですねhttps://t.co/eItf1t8qbH #em_meetup pic.twitter.com/6R68lcuOqg
EM.FMでも語られていた話題だったのでpodcastをオススメしつつ、Engineering Managerが何をやっているのか、何が楽しいのかを伝えないことには始まらんなという話をしました。
とはいえ、技術の話をするのと全く同じように語るわけにもいかないよな、という指摘も出ました。特に"失敗談"。ポストモーテムとして語られることにとても価値がある一方、チームやメンバーの話をする場合それを聞いた当事者がどう思うかに気を配る必要があったり。（解決したならまだしも、「ローパフォーマーに困っている」「チームの雰囲気が悪い」みたいな現在進行系の話だと余計にきつそう）
Engineering Managementの話題は人に関わるセンシティブなところがあるので一歩間違えたりすると特定の人を傷つけたりするおそれがある。そのために気後れしている部分も少なからずあるのではないか、という雑談で悩み相談みたいなことができたのも良かった。
また、マネージャとしてのオンボーディングにも話が移り、「あなたは○月✗日からマネージャです、特にトレーニングも支援もないけどがんばりましょう！」みたいなやり方で成功すると思っているとしたら正気でないという突っ込み。社内に先達がいないのならマネージャ研修やコンサルタント・技術顧問登用などを使ってでもEngineering Managerの立ち上がりはしっかりサポートすることが大事。
エンジニアリングマネジメントの勉強法
このセッションに参加された@progrhymeさんのブログから引用します。
このトピックには私を含め5名の人々が集まったのですが、どうやら私のように「エンジニアリングマネジメントを学びたい」という人が多く集まったようです。 どの人もマネージャーになって1年未満ということでした。
勉強法としては以下のような方法が挙げられました:
- 結論 「EM Meetupに来続ける」
😂
まぁーーーーーー、そうなんですよねぇ…！
僕の周囲もお手本みたいなものがあったわけでも人に教わったわけでもなく、どうにかして「知ってる人に聞いてみたい」という思いでEngineering Manager Meetupを始めたのでした。OSTを選んだのも自分が聞きたいことを知っている（かつ情熱がある）人に聞けるから、です。
おかげで色んな情報が入ってくるようになりはしましたが唯一解の存在しない問題ばかりなので、今でも射撃しつつ前進中です。
お前ら（Engineering Manager）の転職
お前らというか俺たちなのでは…ｗ
テーマ「お前ら（Engineering Manager）の転職」
— 広島の粗大ゴミ (@ohbarye) 2018年10月26日
- 「マネージャをやめてプレイヤーに戻りたくて…」と言って来る人はいるが「マネジメントをやりたくて！」と言いながら入ってくる人がいない問題ｗ
- 良いEMをどうやって見極めるか、のあたりすごく面白そう#em_meetup pic.twitter.com/jVlMDI04zN
このセッションには不参加だったのですが、@aomoriringoさんが書いてくれた模造紙にはすごくわかりが深いワードがならんでいます。
詳しくはEngineering Manager Meetup #2に飛び込んできた。 - どこぞのエンジニアなマネージャーだった人のブログ。をどうぞ。
Engieering Managerもしくはそれに近いポジションでやっている業務が果たしてポータブルスキルなんだろうか〜という話があったが、自分の最近の考えはこんな感じ：
マネジメント系の本を読んだり学んだりすればするほどにいちプレーヤーとしても強くなっていく確信があるので単なる二分法で終わらせないでほしい
— 広島の粗大ゴミ (@ohbarye) 2018年11月9日
だし、それがポータブルなものになるかどうかは、月並みながら自分次第と捉えている。（が、同じジョブタイトルでもおそらくぜんぜんやっていることが異なる可能性がある…例えばめちゃめちゃ社内政治とかをメインにやっている人とは抱えているものが違う）
「マネージャをやめてプレイヤーに戻りたくて…」と言って門戸を叩く人はいるが「マネジメントをやりたくて！」と言いながら来てくれる人がいない問題。採用をやっている中でもこれはよく聞くところだが、掘り下げると各々が携わっている"マネジメント"にはとてもばらつきがある。そこを見逃すと噛み合わなくなりそうだな〜と思ったり。
その他にもいろいろ触れたいテーマはあるのですが長くなりすぎるのでこのあたりで。
総評・運営反省
前回の“”経験者“”がテーブルのファシリテーション等でリードしたり、BYOB (Bring Your Own Beer) スタイルで「飲み食いしたいものは各自持参」としたことで参加者がイベントを作っている感じが出ていたように見えました（途中の買い出しとかは文化祭ぽかった）。おかげでこのイベントでなら開示して大丈夫だという“”心理的安全性“”が醸成され、前回を上回るような“”"熱い“”"テーマが多数産まれたのかもしれません。
BYOBの結果、人よりかなり多くお金を出してくださった方もいたと思うのですがそのあたりが曖昧な感じになってしまったのは反省です。この場を借りてお礼申し上げます🙇
また、やっぱりOSTのあとに懇親会があると良いですね。そして懇親会があるならやはり金曜開催が良い！
オフ会のすすめ
上述の通り、"Engineering Managementやその周辺領域に関心や情熱がある"方さえ集えばいくらでも本イベントの再現はできます。なので、「OST良かった」ないし「参加したかったけど行けなかった」という方はぜひイベント外でもオフ会をやってみてほしいですね！
第3回はプレゼン形式
初回・2回と続いてOSTをやったのですが第3回はプレゼン形式を試してみます。
engineering-manager-meetup.connpass.com
形式は違えどOSTのときと変わらない主体的参加をしてくれる方々が集まってくれることを期待します。主体的参加のイメージ：
- 発表内容・テーマについて登壇者にフィードバックを行う（イベント内外問わず）
- 発表内容・テーマについて参加者同士で議論する
- 発表内容・テーマについて考えた内容をTwitterやブログに公開する
こうした行動を起こすことでイベント全体での学びが最大化されれば良いなという思いがあります。さらに盛り上げていくぞ！ウォーッ
*1:Bring Your Own Beerの略。好きな飲食物を好きなだけ、参加者に用意いただくスタイル
