Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
わたしがEMとして入社した「最初の100日」の過ごし方 / EMConfJp2025
Search
KASUYA, Daisuke
February 26, 2025
Technology
4
1.2k
わたしがEMとして入社した「最初の100日」の過ごし方 / EMConfJp2025
KASUYA, Daisuke
February 26, 2025
Tweet
Share
More Decks by KASUYA, Daisuke
See All by KASUYA, Daisuke
はてなのチーム開発一巡り / Hatena Engineer Seminar 30
daiksy
0
640
ふりかえりカンファレンスLT/Get Wild
daiksy
0
1.8k
スクラムマスターの採用事情 / scrum fest fukuoka 2023
daiksy
0
2.6k
スクラムのスケールとチームトポロジー / Scaled Scrum and Team Topologies
daiksy
1
1.3k
Scrum@Scaleの理論と実装 / RSGT2022
daiksy
2
10k
リモートワークに最適なスクラムチームの人数についての仮説 / Kyoto Agile 2021
daiksy
0
250
スクラムを軸に据えた キャリア戦略 / Scrum Fest Osaka 2021
daiksy
2
7k
インフラ障害対応演習LT版 / evacuation drill of systems
daiksy
1
750
この半年で変わったものと変わらないもの - SaaS開発の現場より / Developers Summit 2020 Summer
daiksy
0
5.1k
Other Decks in Technology
See All in Technology
Classmethod AI Talks(CATs) #17 司会進行スライド(2025.02.19) / classmethod-ai-talks-aka-cats_moderator-slides_vol17_2025-02-19
shinyaa31
0
160
OpenID Connect for Identity Assurance の概要と翻訳版のご紹介 / 20250219-BizDay17-OIDC4IDA-Intro
oidfj
0
440
エンジニアリング価値を黒字化する バリューベース戦略を用いた 技術戦略策定の道のり
kzkmaeda
3
820
Amazon S3 Tablesと外部分析基盤連携について / Amazon S3 Tables and External Data Analytics Platform
nttcom
0
150
依存パッケージの更新はコツコツが勝つコツ! / phpcon_nagoya2025
blue_goheimochi
3
180
PHPで印刷所に入稿できる名札データを作る / Generating Print-Ready Name Tag Data with PHP
tomzoh
0
160
設計を積み重ねてシステムを刷新する
sansantech
PRO
0
110
ホワイトボードチャレンジ 説明&実行資料
ichimichi
0
130
Active Directory攻防
cryptopeg
PRO
8
4.6k
明日からできる!技術的負債の返済を加速するための実践ガイド~『ホットペッパービューティー』の事例をもとに~
recruitengineers
PRO
3
550
Perlの生きのこり - エンジニアがこの先生きのこるためのカンファレンス2025
kfly8
1
230
データマネジメントのトレードオフに立ち向かう
ikkimiyazaki
6
1.2k
Featured
See All Featured
Site-Speed That Sticks
csswizardry
4
390
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
6
560
GraphQLの誤解/rethinking-graphql
sonatard
68
10k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
28
9.3k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
280
13k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
114
50k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
248
1.3M
Art, The Web, and Tiny UX
lynnandtonic
298
20k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
133
33k
4 Signs Your Business is Dying
shpigford
182
22k
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
4
350
Why Our Code Smells
bkeepers
PRO
336
57k
Transcript
わたしがEMとして入社し た「最初の100日」 の過ごし方 id:daiksy 2025-02-27 Engineering Manager Conference Japan 2025
1
2
daiksyの経歴 • 2001年~2014年 SIとかゲーム開発とか • 2014年~2021年 株式会社はてな • 2021年~2024年 他社でEM業
• 2024年~ EMとしてはてなに出戻り 3
daiksyの立場 • はてなの”技術グループ”のマネージャー • マトリクス組織の専門職グループ • エンジニア約100名全員が所属する組織 4
マネージャの入社 5
6 マネージャー入社をメンバーから見た際のイメージ図
パラシュート人事 • メンバーからすると恐怖 の大王が降りてくるよう なもの • 強い権力を持ち、影響が 大きい人がやってくるが 得体がしれない 7
パラシュート人事 • 新しいマネージャーには 組織の変革を期待されて いるので、当然破壊的な 変更も起こり得る • 人々は当然身構えている 8
9 新任マネージャーの自分がこうありたいイメージ図
• 恐怖の大王を演じたいわ けではなく、組織をより 良くする変革者でありた い 10 パラシュート人事
• 周囲との信頼を築く期間 が必要である 11 パラシュート人事
最初の100日と は? • 東京都副知事の宮坂さん • 新任リーダーの最初の動 き方について 12
最初の100日で何をすべきで何をすべきではないか? とくにリーダーが劇的な環境変化に異動、転職、抜擢で放り 込まれるとこの法則(引用者注: ピーターの法則)が強烈に作 用する。なぜなら周りの方が知識や経験があり自分がその組 織内で最もそれがない人になってしまうからだ。一方で、こ の人は何かしてくれるのでは?という期待を関係者からは持 たれる。「組織内で最も無能なのに最も期待される」という 特殊状態を過ごすことになる。 13
https://note.com/mmiya/n/n6196c7b18a3f
最初の100日で何をすべきで何をすべきではないか? 最初の100日でもっともしてはいけないことで共通するのが 「華麗にビジョンを語り戦略を策定して期待値をあげるこ と」はしてはいけない。逆に最初にすべきことはなにか? 「勉強マシーンになること。具体的には資料を読み人に会っ て話を聞きまくる」こと。つまり最初の100日は「口はほど ほどにして耳と目と足を動かせ」ということだ。 14 https://note.com/mmiya/n/n6196c7b18a3f
最初の100日の要点 • 成果を急ぎすぎると「恐怖の大王」に見えてしまう • 最初の100日は現状の理解と信頼の構築に時間を使う • 100日間はちょうど試用期間の3ヶ月と同程度の期間なの で、「試用期間中の動き方」として説明がつきやすい 15
daiksyの 「最初の100日」 19
入社前 20
期待値を徹底的に揃える • オファー提示後、承諾までの期間で期待値を揃えるこ とを徹底した • 仮にdaiksyが「最初の100日」は状況把握を重視した いと思っていても、自分への期待が「最初からどんど ん破壊と変革をしてくれ」だったら期待とズレてしま う 21
期待値を徹底的に揃える • Googleドキュメントに自分が考えていることを書い てCTOと人事部長と共有。そこにコメントをもらう 形式で期待を揃えた • この期待値調整はこちらからお願いした • 出戻りで、すでに関係性のある相手だったのでやりや すかった
22
期待値を徹底的に揃える 23
期待値を徹底的に揃える • 入社当初の動き方 ◦ まずは情報収集から ◦ エンジニア全員と1on1 ◦ 最初は情報収集だけやっていると、「なにをやって る人なの?」となるのでレポーティングはやる
▪ レポーティングの形式について認識あわせ 24
期待値を徹底的に揃える • 最初の100日と、その後のある程度の動き方について 合意ができたのでオファーを承諾 25
そして入社! 26
入社後の最初の動き • 事前にドキュメントで調整済みのことを順番に やるので気持ち的に楽だった 27
入社後の最初の動きや考えたこと • 「所信表明をしない」という所信表明 • 毎朝CTOと1on1 • エンジニア全員1on1 • タスクリストの作成と公開 •
何かを変える際は絶対に独断はしない 28
「所信表明をしない」 という所信表明 29
「所信表明をしない」という所信表明 • グループウェアに以下の文章を投稿 • “daiksyが今技術グループEMとして考えている こと(not 所信表明)” ◦ 急いで方針や戦略を策定することはしません ◦
全員と1on1をします ◦ 情報を集めます ◦ 短期的な成果を積み上げながら、大きい課題を探ります 30
「所信表明をしない」という所信表明 • メンバーとの期待値調整をする意図 ◦ メンバーの中には新しいマネージャーに期待し ている人もいるだろう • ここに書いた内容は全員1on1でも改めて1人ず つに説明をする 31
毎朝CTOと1on1 32
毎朝CTOと1on1 • チーム朝会のようなものが無いので、1日のリ ズムをつくるためにお願いした • 自分の仕事に対するフィードバックを毎日も らって期待値の微調整を行う • これは現在も継続中(主に朝会代わりに) 33
エンジニア全員1on1 34
エンジニア全員1on1 • およそ100人のエンジニア • 150人とされるダンバー数の内側に収まる • 全員の顔と名前を覚えられるはず! 35
エンジニア全員1on1 • マネージャーとしての自己紹介 • 自分がやりたいと思っていることを説明 • 個人ごとの現状把握 36
エンジニア全員1on1 • 1on1の話題テンプレート ◦ 自分の自己紹介 ◦ 今の仕事を教えて下さい ◦ やりがいのあった仕事 ◦
ちょっと嫌だった仕事 ◦ 興味のある技術トピック ◦ 3年後のイメージ 37
エンジニア全員1on1 • 1日におよそ3人ずつ • 1回30分 • 5月8日にスタート • 7月9日に終了 •
9週間で完走 38
エンジニア全員1on1 • 1つのチームや事業の状況について複数人から話し を聞くことで、理解が立体的になった • ある程度みんなの個性を知ることができた ◦ iOSが得意な人、Androidが得意な人、のような 仕事上把握しておきたい個性 39
エンジニア全員1on1 • 「一度話をしたことがある」という状態は強力 ◦ なにかを相談をしたいときにこちらから声をかけるハー ドルが圧倒的に低くなる ◦ 自分に対しても相談しやすくなったと思ってもらえたら (願望) 40
タスクリストの作成と公 開 41
タスクリストの作成と公開 • 「あの人は今なんの仕事してるの?」の防止 ◦ 自分がかつてパラシュート人事でやってきた上長に対し てそう思っていたので、それを反面教師に 42
タスクリストの作成と公開 • タスクリストの登録や、進捗状況は連携機能で Slackのtimes_daiksyに流すようにした • エンジニア全員が入っているチャンネルで日報 を書くようにした ◦ これは徐々に公開できない仕事内容が増えてきたので書 きづらくなり、現在はやっていない
◦ 内容をぼやかして書いてもいいかなと悩み中 43
最初にやるタスク • 右の4象限にあてはめて 発見した課題を整理 • 短期的な成果を獲得する ために右上の範囲のもの に取り組む 44
最初にやるタスク • 難しいものは影響が大き かったり、各所への調整 が必要だったりするの で、100日を経て信頼を 構築してから着手するこ とにする 45
実際にやったこと • 採用業務 • CTO主催の一部の定例の運用を巻き取り • 期末評価の運用 いずれも既存プロセスのまま実施主体を自分に 寄せ、運用しながらプロセスの一部を改善 46
何かを変える際は 絶対に独断はしない 51
何かを変える際は絶対に独断はしない • 過去の経緯やカルチャーを最大限リスペクトする • 事情を知らない自分が安易に手を出すべきではない 52
何かを変える際は絶対に独断はしない • 「変えたい」という提案をした際に、議論が ワッと盛り上がるものがある • それは過去の組織を作ってきた人たちが大事に していることの証拠 • そういったものに対しては絶対に独断をせず全 員が納得するまで耳を傾けて調整し続ける
53
100日が経過したその後 54
100日間の結果を 採点する 55
100日間の結果を採点する • 「エンジニア世論調査」 ◦ はてなの技術組織で半期ごとに実施しているアンケート ◦ 異動希望やキャリア希望、扱いたい技術などをみんなか ら集める 56
100日間の結果を採点する • 「エンジニア世論調査」 ◦ このアンケートに、自分に対する評価を尋ねる質問を入 れた 57
100日間の結果を採点する • 「エンジニア世論調査」 ◦ 「技術グループマネージャ」の就任によって技術グルー プがどのくらい良くなったと感じますか? ▪ 5点満点 ◦ 上記回答の理由を教えて下さい
(自由回答) 58
結果は... 59
100日間の結果を採点する 60
100日間の結果を採点する 61 食べログだったら高得点だが... 優・良・可で言うと可よりちょっと良いくらい?
100日間の結果を採点する • AIによる自由回答欄の要約 ◦ 技術グループ全体の動きが可視化され、以前よりスムーズに仕 事が進むようになったと感じる人が多くいます ◦ 特に、採用活動やチームビルディング、メンターへのサポート といった分野で、具体的な改善を感じている人が複数います ◦
また、技術グループマネージャーが様々な問題を把握しようと 努め、積極的に行動していると感じている人もいます 62
100日間の結果を採点する • AIによる自由回答欄の要約 ◦ 自分自身に直接関わる範囲では変化を感じていない、まだ影響 が及んでいない、または活動内容がよくわからない、という意 見も一定数見られます ◦ 特に、シニアエンジニア以外は変化を感じにくい可能性がある という指摘もあります
63
100日間の結果を採点する • 良くなった実感を持ってもらえたがその影響の範囲 は限定的 ◦ 自分と接点の多い人は実感してもらえている ◦ 半数以上は「よくわからない」「なにをしている のかまだ見えていない」という状態 64
101日目以降 • いよいよ本丸へ着手する • 図の右下の仕事 65
hatena.co.jp/recruit 66 66