それは『放置』か『期待』か ー メンバーが迷わない、EMの任せ方の流儀【EM Oasis #11】 に参加しました。
今年はエンジニアリング・マネジメントを学びたいという気持ちと、タイトルがまさに今の自分の課題感と合っていて楽しみにしていました。
イベントに参加した学びをまとめます。
イベントの概要
EMとしてチームを率いる中で、こんな問いに向き合ったことはありませんか。
「これは任せているのか、それとも放置しているだけなのか？」
「この状況は、本当に“任せられている”と言えるのだろうか。」自律を信じて任せたい。一方で、成果には責任を持つ立場でもある。
そのバランスの中で、チームは本当に自走できているでしょうか。本イベントでは、「放置」と「期待」のあいだを見つめ直し、メンバーが迷わず動ける“任せ方の流儀”を探ります。
引用：https://emoasis.connpass.com/event/386140/
イベント参加の背景
- メンバーの成長を引き出す任せ方が難しい。
- 対象の重要性によっては、『放置』してケガして経験してと思うところもあるけど、なかなか難しい。
- 今年はEMとしてできることを増やしたいと思い、参加。
セッション
【招待講演】naoprさん
メモ
一人目EMとしての入社と役割。
入社当時の課題：CTO、TL多忙
→エンジニア組織のスケールが困難
EMとして入った結果
CTO：エンジニア採用のスケール＆ドライブ、TL：開発に集中
新しい課題：採用業務の停滞、チームマネジメントの希薄化
結果、自分がボトルネックになっていた。
ボトルネックの解消の選択肢：内部登用、TL兼務、EM採用
内部登用：開発の低下を懸念して見送り。魅力付けやキャリア寄り添いできてなかった。
TL兼務：当初の課題再発を懸念し見送り。
結果、EM採用を判断した。
2人目EM採用できた。どのように権限委譲したか。
どの権限を、どういった時間軸で渡すのかが重要だった。
権限：1チームのマネジメント権限+採用
時間軸：入社後、期間でそれぞれ期待値を分けた
6か月で1チームを任せられる状態を目指した。
チームの選定判断軸：
本人の適正が活かせる、ドメイン知識キャッチアップしやすい
最初はICとして入る
入社前から権限委譲の進め方のすりあわせ。
権限委譲のうまくいかなかったふりかえり
・役割分断の細分化ができなかった
・チーム構成での負荷が増してしまった
・暗黙知の引継ぎがなかなかできなかった
内部登用は結果見送りになったが、常に声がけなどはしていた。
EMに興味あるメンバーはいたが、「今すぐ」ではなかった。
学び
その時々での判断と、振り返って改善点を見つけることの重要性を改めて学びました。
特に内部登用と外部採用の話は、事業会社の難しさを改めて学びました。
受託開発だとそもそもゴールがもっと手前になるから、できるできないだけで判断ができてしまいそう。
内部登用と外部採用のどちらか一方ではなく、両軸で進めていく重要性を学びました。
【LT①】放置ではなく、期待を伝えて「自立」を加速させるための神器 by piro.takahara（ぴろ）さん
メモ
「自立」を加速させるための神器
・グレード定義（キャリアラダー）
・責任分担表（RACIマトリックス）
隣の人を手伝うこと明確化。どこに自分が責任を持つか分かるように。
・役割定義
縦：グレード定義／横：責任分担表／Snapshot：役割分担表
放置ではなく活かせるようにしている。
責任分担表の分類：
プロダクトマネジメント、技術マネジメント、ピープル／組織マネジメント
責任分担表のブラッシュアップ：
抽象度と具体のどこに落とすかは、少しずつ試行錯誤しないと分からない。
運用しないと分からない。
学び
マネジメントを構造化する重要性を学びました。。
自分のなかで相手に任せたい役割とその重要性の抽象度が高かったことに気づきました。
自分たちのコンテキストに合わせて整理したいです。
【LT②】扱える不確実性を増やしていく ― スタートアップEMが考える「任せ方」 by 門脇 恒平 (kadoppe)さん
メモ
新しいメンバーに対する仕事の渡し方。
メンバーが扱える不確実性を少しずつ増やしていく。
不確実性とは？タスクの抽象度軸、テーマの大きさ軸、ステークホルダー軸
軸を組み合わせて不確実性を見える化する。
低いところから、高いところへ段階的に任せられるようにする。
・入社前から期待を伝え続ける
・単発ではなく、連続した取り組みを見て伴走する
完全なサポートはできないので、失敗しても擦り傷を負って学んでもらうことも手段とする。
学び
構造化とその掛け合わせの重要性を学びました。
細分化するからこそ難しさの設定ができるし、相手にそのまま渡せるかどうかの判断ができる。
特に失敗しても擦り傷を負って学んでもらう判断は、そうした構造化の上でこそ判断できるとイメージが持てました。
お悩み相談会（テーブルディスカッション）
「失敗させてもよいと思える基準 その後の関わり方」という付箋を貼りました。
聞く一方でしたが、だからこその学びがありました。
特に「EMの内部登用むずくない？」という付箋から発生した、「EMが担うのは遂行に対する責任か、成果に対する責任か」という議論が大きかったです。
EMに求められる成果とは何か？。
受託開発におけるプロジェクトマネージャーは成果目標が求められます。
けど、事業会社でエンジニアに求められる成果目標と、遂行目標はもう少し違うものとイメージができました。
契約によって短期的に手元に入る成果と、事業成長という不確実な動向の上に結果が出る成果とは大きく違うと感じました。
我々は長期的な成果をもっと意識すべきと学びました。
ただ、それが難しいのは短期的な成果が見えやすいからかも知れない。
そのうえで、採用計画の話もとても興味深かったです。
不確実性が高いため、具体的な計画があるわけではなく、変動的な計画に耐えられる状態を用意する、といったイメージを持ちました。
そして、それはEMに求められる成果が不確実性が高いことにも起因するとイメージができました。
短いスパンでの成果ではなく、非連続な成長が求められる。
コンテキストが異なるからこそ、自分との違いが見えて学びの大きい時間を過ごすことができました。
もっとエンジニアリング・マネジメントを学びたくなりました。
貴重な時間をありがとうございました。
感想
改めて多くの大きな学びを得ることができました。
私の課題は、自分とプロジェクトを共にする彼らにどうやって私の役割を委譲していけるかでした。
ただ、私が担うプロジェクト・マネジメントがどういったものかを、体系化・構造化そ、それはなぜ必要なのか、が不充分であることに気づきました。
そして、その整理を行ってからこそ、彼らにどう受け渡していけるかが整理できるイメージが持てました。
また、そのうえで、私の『期待』に事業とは少し異なるバイアスがかかっていることにも改めて気づきました。
それも含めて丁寧に整理して、任せていくことが重要と気づきました。
EM系の勉強会はいつもびくびくしながら参加しています。
けど、その分コンテキストの違いに大きな学びを得ることができます。
今日もありがとうございました。
