- 2025/2/27
- https://2025.emconf.jp/
感想
- これまでEMという役割に馴染みがなかったが、どんな領域をスコープにしてどんなことに悩んでいるのか聞けて勉強になりました
エンジニアリングマネージャーのロードマップ エンジニアリングマネジメントの4次元と生成AI時代の戦い方
広木 大地さん
https://hirokidaichi.github.io/presentation/emconf.html
- EMとは
- EMの4つのP
- People Management
- 人の成長が不確実性を減らす
- Project Management
- 不確実性コーン
- タスクの管理というよりリスクの管理
- Platform Management
- シフトレフトでリスクを早期に発見する
- 失敗できる環境を技術的に用意する
- コード修正の心理的安全性
- 技術的負債は可視化できれば管理できる
- Product Management
- プロジェクトはhowでプロダクトはwhat
- 前者は終わることが大事で後者は終わらせないことが大事
- 終わらせないために仮説検証サイクルを管理する
- グロースサイクル
- 機能を作ることではなくサービスの自律的な成長サイクルを作ることがプロダクトマネジメント
- 顧客体験のサイクル/データ活用のサイクル/認知拡大のサイクル/収益のサイクル
- プロジェクトはhowでプロダクトはwhat
- People Management
- マネジメントとは「なんとかする」こと
- エンジニアリングマネジメントは「価値実現する」ために「なんとかする」こと
- 自分一人で全部できる必要はない
- 必要なものを調達できないといけない
- 生成AIでEMはどう変わっていくか
- ソフトウェアの複雑性は増したが複雑さのコストは下がってる
- 社会の適応領域は拡大し続けてる
- 人の勝ちは高くなって半導体は安くなっている
- 変革/成長/運営のうちの運営は置き換わっていく
- 均質なチームから多様なチームへ
- AIエージェントに開発を頼んでそれらを管理
- AIが提案し人が決める
- 課題を整理して意思決定し環境を整える
- 意思決定する人がボトルネック
- すべてのエンジニアがAIをメンバーに持つEMになる
- EMはそれをオーケストレーションする
プロダクト部門のマネージャー全員でマネジメントポリシーを宣言した記録 〜後日、実践できているか？内容は妥当か？を評価できる仕掛けを添えて〜
piro takaharaさん
- マネジメントポリシー
- ミドルマネージャーがメンバーに対して守ること
- なぜ作ったか
- 情報共有を促しても進まない
- 共通の目標や目指す姿がなかったから
- 組織ビジョンはあったが自分たちの持ち物にできてなかった
- 作り方
- 組織ビジョンを深堀りして要素を分解
- ToBeが実現している状態の具体化
- AsIsとToBeのギャップを考える
- ギャップを埋めるための方法を言語化
- 使い方
- マネージャーは普段の行動の基準とする
- 適用できたら言う
- 適用できてなかったらつっこんでもらう
- マネージャーを目指す人
- 必要な要素を把握するため
- マネージャーは普段の行動の基準とする
- 作ってみて
- 共通の目標は持てた
- 自分たちで作ったからというのもある
- 継続のために
- 作って終わってではダメという指摘
- セルフチェックを開始
- 客観評価もしていきたい
- 新しく入ってくる人への浸透
急成長する企業で作った、エンジニアが輝ける制度
池ノ上倫士さん(Shift)
https://speakerdeck.com/shift_evolve/20250227-rinto-ikenoue
- EM不在での課題
- 個人の成長
- 振られた作業をこなすだけ
- 背景や未来が分からない
- そこを気にせず効率化することがよしとされていた
- 学ぶべきロードマップを作った
- 組織の事業が多様化したことで多様な視点を盛り込めた
- 評価制度や教育制度への反映
- 立場によっ価値観が違う
- 経営とIT技術について議論する場を
- キャリアプラン
- 営業がとってきた案件依存になってしまう
- 適切な案件が適切なチームにつながるように整理
- 営業とエンジニアのアラインメント
- チーム形成
- 属人性が生まれて組織にノウハウがたまらない
- プロダクトライフサイクルの整理
- 開発品質のばらつきが露呈された
- 開発標準ガイドラインの整備
- テスト標準ガイドラインがもともとあった
- 作るのにはコストがかかる
- できる人を連れてきてやらないといけない
- 見積もりや開発のノウハウが共有されるようになった
- コスト効果があるかどうかは求めれらた
- 個人の成長
- 今後取り組むこと
楽しいぞEM拡張パズル！課題と共に役割を広げちゃおう！
笹 健太 さん
https://speakerdeck.com/sasakendayo/emconf-jp-2025-le-siisoemkuo-zhang-hasuru
- エンジニアリングマネジメントの役割
- EMトライアングル
- Technology
- Product
- Team
- それぞれの掛け算
- EMトライアングル
- やることがとにかく多い
- 一部しかやれてなくて悩むことも
- 全部できるスーパーマンである必要はない
- EM拡張パズル
- EMやることを特定
- トライアングルでやれてるところに色つけていく
- 他のロールがやってくれてるところに色をつける
- 色がついてないところがチャンスゾーン
- ビジネスへの影響度からどれにするか決める
- 強みを活かして解決策を検討
- 実行する
- これらを繰り返していく
- EMやることを特定
- 出来てないことが多い方が面白い
- 良くなるところがたくさん
- まとめて一気にやらないこと
- 一番解決したいことから順番に
大規模アジャイルフレームワークから学ぶ "エンジニアマネジメント" の本質
Kittaka shunさん
https://speakerdeck.com/staka121/da-gui-mo-aziyairuhuremuwakukaraxue-buenziniamanezimentonoben-zhi
- SAFe
- ビジネスアジリティを実現するための統合フレームワーク
- 構造
- なぜSAFe
- 同じ方向を向けてないよね問題
- 立場に寄って何に軸足を置くかが違う
- PdMが何を選択するかが難しい
- STが方向性を決めるのである程度定まった状態で進められる
- 立場に寄って何に軸足を置くかが違う
- チーム間のコミュニケーションコストが増える問題
- 複数のプロダクトが強調して価値を生み出すという方向性
- 複数チームが協力して開発する必要がある場面が多い
- チームの中で優先順位が困る
- ARTで情報を同期することで優先度を一元管理できる
- 複数のプロダクトが強調して価値を生み出すという方向性
- EMがEverythingManagerになっちゃう問題
- SAFeだと役割を分担しやすい
- ソリューショ/アーキテクト/組織のそれぞれに責任を持つ立場がある
- どれを誰がやるべきか迷わなくてよくなる
- 同じ方向を向けてないよね問題
- EMトライアングルの役割を分担していくといい
- Technology
- Product
- プロダクトマネージャー
- Team
- リリーストレインエンジニア
- EMはSAFeにおけるシステムアーキテクト/プロダクトマネージャー/リリーストレインエンジニアの組み合わせ
- それぞれの比重は状況によって変わってくる
- どこに比重を置くかはっきりしてると自身を持って取り組めるようになる
わたしがEMとして入社した「最初の100日」の過ごし方
daiksy daiksyさん(はてな)
https://speakerdeck.com/daiksy/emconfjp2025
- マネージャーとしての入社
- 外からマネージャーが入っていくことの難しさ
- 恐怖の大王が入ってくるというイメージ
- 周囲との信頼を築く期間が必要
- 最初の100日
- 最も無能なのに最も期待される状況
- 華麗なビジョンを語るのではなく勉強していくこと
- 100日の過ごし方の事例
- 入社前
- オファーから承諾までの期間で期待値を揃える
- 入社してどんなことをやるか認識をあわせた
- 入社後
- 100日かけて大きい課題を探す
- エンジニア100人全員との1on1
- 1つのチームについて複数人から聞けるのがいい
- タスクリストの作成と公開
- 何をやってるか公開する
- だんだん人に言えない仕事も増えてきた
- 短期的な成果を積んで大きな課題を探る
- エンジニア100人全員との1on1
- 100日かけて大きい課題を探す
- 入社前
- 何か変える際は独断でやらない
- 過去の経緯で大事にされていたこと
- 納得してもらって変えるように
- 100日経過して
- エンジニア世論調査
- 半期ごとのアンケート
- 5段階で3.72
- グループの動きが可視化された
- 課題を探そうとしてるのが見える
- 変化を感じにくい立場の人も多い
- エンジニア世論調査
「共創型エンジニアリングマネジメント」の挑戦と実践
うっしーさん
https://speakerdeck.com/sudo5in5k/gong-chuang-xing-enziniaringumanezimento-notiao-zhan-toshi-jian
- 組織の拡大に対するマネージャーの役割
- 局所最適やサイロ化が進んでいく
- あって仕方ないタイミングもあるが基本的によくない
- マネージャーの成果は自チームのアウトプット+他チームに与えた影響
- 全体最適を意識した持続的な生産性の向上
- 局所最適やサイロ化が進んでいく
- EM + VPoE全員で共創してエンジニア組織の課題に取り組む
- 各EM内の局所最適を抑えるため
- 全体を巻き込んで解決必要な課題もある
- EMのスキルの標準化
サバイバルモード下でのエンジニアリングマネジメント
こにふぁーさん
- Kyashのサバイバルフェーズ
- 2022-2023
- 事業
- ブランドルールや法律の成約で非連続な成長を果たせず
- ポイント還元などで収益構造悪化
- 新たな事業も想定より伸びず
- 組織
- 目先の問題を何とかすることがほとんど
- 全体的に消耗気味でメンバーもマネージャーも退職が増加
- 事業
- 2024-
- 事業
- 目標達成できる組織へ
- 事業見直し収益は改善
- 組織
- 先を見た話をすることも増えてきた
- エンゲージメントは改善しきらず直近も退職は見られる
- 事業
- コスト見直し
- すぐにやった方がよかった
- 収益構造の改善はダイレクトに効く
- 1回やれば積み上げで効く
- インフラのリソース削除とか
- 月に250万くらいの改善
- 自分の不安を紛らわすための1on1をしない
- マネジメントの不安を減らすためのメンバーとの1on1は無意味
- 根本の問題を解決しないと
- 何となくわかってることの答え合わせをしていた
- 退職は切り出されたらもう遅い
- 放置せずに先手で手を打たないと
- 収益構造を理解し提案する
- 共有された事業計画の数字だけを追っていた
- 現状の収益構造を理解してないと提案もできない
- これらはEMの責務なのかという点が曖昧になっていた
- とはいえ誰かがやらないといけないことを放置はできない
- 採用活動を止めない
- 予算が決まってるからその中で考えるしかないと思っていた
- 採用活動自体も労力がかかる
- 予算の調整はトップラインを守れば対応できる
- 縮小するにしても採用活動の文化は止めずに残しておいた方がいい
- 予算が決まってるからその中で考えるしかないと思っていた
- 考える時間軸をのばす
- 炎上してるからとにかく目の前の課題を見ていた
- そうしているとメンバーが消耗してくる
- 何目指してるんだっけみたいになる
- 少し先の未来を示すのはマネージャーの役割
- サバイバルフェーズのマインドセット
- 全部自分の責任と思わない
- もう遅いと思わない
n=1の経験が紡ぐエンジニアリングマネジメントの可能性
- マネージャーのアウトプット
- 組織のアウトプット + 影響を及ぶ隣接組織のアウトプット
- 能力 x 熱量 - 摩擦や制約
- 1on1での質問
- 熱量や摩擦につながる質問をする
- 元気度合い
- 今のブロッカー
- 楽しい度合い
- 出社日
- 抽象的な会話
- 振り返り
- 隣接組織
- 組織内全部
- それらとの摩擦を減らしたい
- 解くべき問題を全体像から考える
- システム思考
- これからのEM
- クラウドの登場による変化
- 将棋AIは昔は人間といい勝負だったが2015-2017で一気に突き抜けた
- 同じように他のことで一気に突き抜けることも想像できる
- 計画に従うより変化に適応する
