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
20240301_cocone_EMゆるミートアップvol6_LT資料
Search
cocone
March 07, 2024
Programming
0
870
20240301_cocone_EMゆるミートアップvol6_LT資料
cocone_EMゆるミートアップvol6_LT資料
cocone
March 07, 2024
Tweet
Share
More Decks by cocone
See All by cocone
Cocone_Research_Center_2025.pdf
cocone
0
120
2024_cocone-avatarservice.pdf
cocone
0
2k
2024_cocone-wellbeing
cocone
0
4.8k
2023夏季合同企業説明会ココネ
cocone
0
360
cocone TECH TALK Vol.6 - リアルタイム対戦xバックエンドアーキテクチャ
cocone
0
590
cocone TECH TALK Vol.6 - ココネグループのブロックチェーン MOOI Network とのバックエンド連携
cocone
0
510
cocone TECH TALK Vol.6 - Kotlin バックエンドアーキテクチャ of アバターサービス
cocone
0
540
ココネ株式会社 会社紹介
cocone
0
130k
cocone corporation(JPN)Letter for Designer
cocone
0
760
Other Decks in Programming
See All in Programming
ライブ配信サービスの インフラのジレンマ -マルチクラウドに至ったワケ-
mirrativ
1
260
Webinar: AI-Powered Development: Transformiere deinen Workflow mit Coding Tools und MCP Servern
danielsogl
0
150
フロントエンドのmonorepo化と責務分離のリアーキテクト
kajitack
2
130
DockerからECSへ 〜 AWSの海に出る前に知っておきたいこと 〜
ota1022
5
1.8k
GUI操作LLMの最新動向: UI-TARSと関連論文紹介
kfujikawa
0
1k
A Gopher's Guide to Vibe Coding
danicat
0
170
MCPで実現するAIエージェント駆動のNext.jsアプリデバッグ手法
nyatinte
4
210
モバイルアプリからWebへの横展開を加速した話_Claude_Code_実践術.pdf
kazuyasakamoto
0
230
Honoアップデート 2025年夏
yusukebe
1
830
STUNMESH-go: Wireguard NAT穿隧工具的源起與介紹
tjjh89017
0
380
AHC051解法紹介
eijirou
0
610
Flutterと Vibe Coding で個人開発!
hyshu
1
260
Featured
See All Featured
Build The Right Thing And Hit Your Dates
maggiecrowley
37
2.8k
Building an army of robots
kneath
306
45k
KATA
mclloyd
32
14k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
367
26k
Into the Great Unknown - MozCon
thekraken
40
2k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
667
120k
Optimizing for Happiness
mojombo
379
70k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
PRO
183
54k
Optimising Largest Contentful Paint
csswizardry
37
3.4k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
34
3.1k
Building Adaptive Systems
keathley
43
2.7k
Reflections from 52 weeks, 52 projects
jeffersonlam
351
21k
Transcript
2024.03.01 EMゆるミートアップ vol.6 〜LT会〜 ココネ株式会社 / Yuji Saito 脱・「当日のサプライズ」
EM/TL体制にしたら、徐々に発生しつつあった「当日のサプライズ」を改善する事ができた 本日お話すること 2 参考:「エンジニアリングマネージャーのしごと」 6章より 「評価面談が、苦痛を伴ってはいけません」 迷信5 : 面談は当日のサプライズであるべきだ
3 本発表の前提条件
▪こんな経歴の発表者です CRMパッケージ企業 / SIチーム 株式会社ダーツライブ 株式会社ヴァリューズ ココネ株式会社 社会に出てプロジェクトマネジメントを含めたSIerムーブを一通り叩き込まれ、その後は 自社開発エンジニアの道へ。前職ではプレイングマネージャーとして競合分析商品のバッ クエンド設計,
AWS Foundational Technical Review(FTR)の適用なども担当。 現職ではweb3サービスに従事した後、昨年EM組織立ち上げと共にEMという道へ。 CTO室としてEM横断組織のリーダーも担当し、エンジニア組織的な話にも関わりつつ 1事業のEMとして個別具体的なチームメンバーの目標設定・評価も担当しております。 自己紹介 齋藤裕志( Yuji Saito ) 近影 4
▪こんな会社です 前提条件 / 会社の特徴 5 デザイナーがたくさん! 食堂のご飯がおいしい! 社内にジムやBarがある! ヨガやマッサージも!
サラダバーがある!!
▪こんな評価制度です ・期末に被評価者がセルフレビューとして5段階評価し、評価者も5段階評価をします。 前提条件 / 評価制度 6 https://speakerdeck.com/cocone/handbook2022?slide=37
▪こんな開発組織でした(〜2023/07) ・だいたい100人規模になってきた ・サービスごとに10〜20人のエンジニアが関わる ・開発リーダーが「技術」も「人」も見る、プレイングリーダーとなる 前提条件 / エンジニア組織と規模と過去 7
▪こんな開発組織になりました(2023/07〜) ・EMをサービスごとに選出、配置 ・テックリード(TL)をクライアント、サーバーにそれぞれサービスごとに配置 前提条件 / エンジニア組織と規模と現在(問題が解決した姿) 8
9 本題
▪被評価者から見た「評価の時期」 「当日のサプライズ」問題とは(弊社の場合) 10 そもそも何を書けば良いのか分からない どの粒度まで書けば良いのか分からない 5段階どれ付ければ良いのか分からない ▪評価者から見た「評価の時期」 自己評価が高い!!! 自己評価が低い!!! けど通達するしかない!!!
まさに苦痛を伴う評価面談となる (ことが起きうる構造が危ぶまれた) ぶっつけ本番で提出 (が発生し得る) 「当日のサプライズ」 な通達 (が発生し得る)
▪経緯 ・開発リーダーが「技術」も「人」も見ていました 「当日のサプライズ」問題が発生するメカニズムの一例 11 ・リーダー会議で「技術」の話の比重も減ってゆきます ・併せて徐々に 1on1 の時間が低減するケースが発生してゆきます ・特に「評価のすり合わせ」の時間が低減するケースも発生するようになりました ・こうして徐々に「当日のサプライズ」へと向かう悪い土台が出来てしまいます
・近年、プロジェクトも、エンジニアも増えてきました ・すると「人」の問題も増えてきます。「人」の問題は緊急度も優先度も高いです
12 EM/TL体制になりました
▪「期初に目標設定をすること」をEMの責務として定義 ・グレード表(キャリアラダー)を再度浸透させた。入社時期によっては、せっかく作ら れている制度への認識が弱いケースもあった。 ▪定期的な1on1をEMの責務として定義 ・「やったほうが良い」ではなく責務として定義した ▪EM横断組織で毎週定例MTGを行った ・「人」の問題はEM横断組織の定例会で集約するようにした ・課題が発生したら「じゃあEM定例で」という1つのフローが産まれた ・定例として存在することが重要な定例 ・「なんかEMがいると、色々良いという空気」も産まれた
EM体制で行ったこと(抜粋) 13
▪被評価者から見た「評価の時期」 「当日のサプライズ」問題はどうなったか 14 普段から目標をすり合わせてるので安心 評価を書く時に粒度を相談できる 目標を意識していた ▪評価者から見た「評価の時期」 期末にやるのは「まとめ」 相手もこちらも構えずにできる 評価面談から苦痛を伴う要素がなくなった
「日々の延長」 という感覚 「日々の延長」 という感覚 評価のズレがゼロに近くなった
▪良かった点 ・実際に「いつもの延長みたいな感じで書けば良いんですよね!」という声を頂いた ・5段階評価の、被評価者と評価者のズレがほぼ発生しなかった(被評価者が低めに出し てしまうという話は一部あったが、これは全くストレスの無い調整である) ・「EM/TL体制になって良かった」という声が多数寄せられた ▪課題点 ・当然 1on1 の時間に追われることにはなる ・言っても属人的になんとかしていることは否めない
・次のEMどうしよう話への対応(何とかなりそうだが、仕組み化が難しい) 結果 15
16 所感
▪思ったこと ・冷静に考えると「そりゃそういう課題が起きるでしょ」&「そりゃそうすれば解決する でしょ」という話ではあります ・でも起きます(本に書いてあるくらいですから!)。 ・どこで整備をするかは会社とフェーズによって当然異なると思いますが、もし同じくら いの会社規模で困っている組織があれば、この事例が一助になれれば幸いです。 ただ、当然、やるべきことを愚直にやっていく他なく、 「人の課題に対する銀の弾丸は、人と向き合い続けることである」 みたいなフレーズは頭に浮かびました。 まとめ的なもの
17
18 ご清聴ありがとうございました! ※宣伝 SoftwareDesign 3月号にも冒頭に EM/TL体制のインタビューが載ってます!