エンジニアリングマネージャーの仕事

Transcript

1. エンジニアリングマネージャーの仕事 Yuhei Nakasaka 1
2. （注） このスライドは私の脳内にあるエンジニアリングマネージャー(以下、EM)についての 考えを雑にダンプしてLLMに作成してもらったものです。 2
3. なぜこのスライドを作ったのか なぜEMが必要なのかわかりにくい EMの仕事は全体像が見えにくい EMとしての自分の現在地が知りたい 3
4. なぜEMが必要なのか 開発は人数が増えるほど難しくなる 依存関係が増える 意思決定の論点が増える 役割の境界が曖昧になりやすい 短期成果と長期投資が衝突しやすい 放っておくと現場の善意で回し始める 強い個人に調整が集中する 採用、育成、評価が後回しになる 技術負債や運営負債が見えづらい チームごとにやり方がばらつく EMは、開発そのものを代わりに行う役割 ではなく、 開発が継続して成果を出せる状態を作る役割 と捉えると位 置づけが見えやすい。 4
5. EMの仕事が説明しづらい理由 見えやすい仕事だけでも広い 進捗確認や意思決定 1on1や評価フィードバック 技術判断や障害対応 採用や配置調整 見えにくい仕事も多い 会議体や運営ルールの設計 育成と後継者づくり 技術負債や基盤投資の計画 ロードマップや投資判断への参加 EMの仕事は、現場を前に進める仕事 と あとから効いてくる仕事 が同時に存在するため、 「何をしている人か」を 一言で言いづらい。 5
6. 仕事を整理する2つの軸 業務カテゴリ プロダクト: 何を作るか、なぜ作るかを つなぐ プロジェクト: 開発を前に進める ピープル: 人を通じて成果を出す テクノロジー: 継続的に作れる状態をつ くる 影響範囲 時間軸: 短期 〜 長期 人数: 個人 〜 組織 6
7. 4つの業務カテゴリ プロダクトマネージメント 事業目標と開発を接続し、実現可能性・投資対効果・ 継続運用性の観点で意思決定に関わる仕事。 Why/Whatの定義。 プロジェクトマネージメント 計画、進行、合意形成、リスク対応を通じて、開発を 前に進める仕事。 ピープルマネージメント 採用、育成、評価、配置、関係性の維持を通じて、人 を通じて成果を出す仕事。 テクノロジーマネージメント 技術方針、品質、開発生産性、運用継続性を成立させ るための仕事。 7
8. 影響範囲 短期 × 個人 今の案件や特定メンバーの詰まりを取り、その場の成 果を前に進める。時には自分が開発を行う。 短期 × 組織 複数人・複数チームが同時に動くための運営、可視 化、同期をつくる。 長期 × 個人 特定メンバーや特定チームの将来価値を高める。 長期 × 組織 組織の再現性、採用力、技術継続性をつくる。 目の前で忙しく見える仕事ほど 短期 に寄りやすい。 一方で、EMの価値は 長期 と 組織 に効く仕事をどう積み上げるかでも決まる。 8
9. 業務カテゴリ x 影響範囲の具体例 影響範囲 プロジェクト プロダクト ピープル テクノロジー 短期 × 個人 進捗確認 ブロッカー除去 合意形成 仕様レビュー MVP調整 リリース判断 1on1 フィードバック コンフリクト対応 技術レビュー 環境改善 属人化解消 短期 × 組織 可視化 レポーティング 横断調整 KPI起点の改善提案 投資対効果の説明 配置最適化 制度運用 エンゲージメント施策 監視運用 障害運営 生産性計測 長期 × 個人 計画設計 依存関係整理 実現可能性評価 課題抽出 育成計画 OJT 後継者育成 技術選定 アーキテクチャ方針 負債返済計画 長期 × 組織 運営ルール改善 ポートフォリオ設計 ロードマップ参加 技術投資方針 採用広報 評価制度 カルチャー形成 技術方針 標準化 CI/CD改善 9
10. 短期 × 個人に現れやすい仕事 カテゴリ 典型的な仕事 現場の具体例 プロダク ト 仕様レビュー、MVP範囲調整、品質水 準の調整 UI仕様に抜けている権限、監査ログ、通知条件を実装観点で詰め る プロジェ クト 進捗確認、遅延要因の特定、ブロッカ ー除去 他部署承認が止まっている案件で、関係者を集めてその日のうち に意思決定を取る ピープル 1on1、行動改善フィードバック、悩み 相談対応 他職種との認識ずれで疲弊しているメンバーに論点整理や同席支 援を行う テクノロジ ー 技術的意思決定のレビュー、開発環境 改善 ライブラリ導入案を、将来の運用負荷まで含めてレビューする 目の前の詰まりを取る仕事。未熟な組織/チーム/プロダクト・ジュニアなEMはここに時間が寄りやすい。 10
11. 短期 × 組織に現れやすい仕事 カテゴリ 典型的な仕事 現場の具体例 プロダク ト KPI起点の改善提案、投資対効果の説明 新機能追加より、入力途中離脱率の高い画面改善を優先す ると説明する プロジェ クト 開発状況の可視化、会議運営、横断調整 完了率ではなく、残論点・リスク・次の意思決定ポイント を1枚で共有する ピープル 人員配置の最適化、制度運用、エンゲージメ ント施策 案件特性に合わせて、新規開発に強い人と運用改善に強い 人を組み替える テクノロ ジー 監視運用、障害対応プロセス、DORAなどの 指標の運用改善 変更失敗率が高いため、レビュー強化ではなく段階リリー スと自動化を優先する 複数人が同時に動くための運営の仕事。現場の安定度に直結する。 11
12. 長期 × 個人に現れやすい仕事 カテゴリ 典型的な仕事 現場の具体例 プロダク ト 実現可能性評価、課題抽出、開発コス ト見積もり 将来のマルチテナント化を見据え、今の認可設計のままでは崩れ ると伝える プロジェ クト 開発計画、マイルストーン設計、依存 関係整理 4か月後の大型リリースに向けて、工程を週単位で引いて着地条 件をそろえる ピープル 目標設定支援、育成計画、後継者育成 レビュー同席 → 小規模設計主担当 → 設計レビュー主導の順で 育成計画を組む テクノロ ジー 技術選定、アーキテクチャ方針、技術 負債返済計画 全面刷新ではなく、認証 → テスト → バッチ監視の順で四半期ご との改善計画を引く 将来価値を作る仕事(計画作り)。緊急度が低く見えやすいが、先送りすると後で効く。 12
13. 長期 × 組織に現れやすい仕事 カテゴリ 典型的な仕事 現場の具体例 プロジェク ト 運営ルール改善、ポートフォリオ調 整 「着手条件を満たさない案件はスプリント投入しない」など運営ル ールを定める プロダクト ロードマップ参加、技術投資方針 新規事業展開を見据えて、共通会員基盤や権限基盤への投資を提案 する ピープル 採用要件定義、評価制度、カルチャ ー形成 「Ruby経験者」ではなく、曖昧な要件下で設計判断できる人と要 件を定義する テクノロジ ー 技術方針、技術標準、CI/CD改善 新規画面はTypeScript必須、APIはOpenAPIで管理、のような標 準を定める 組織の再現性を作る仕事。短期の成果だけでは測りにくいが、組織の差が出やすい領域。 13
14. 1つの仕事が複数象限にまたがることもある 仕事 目先で効く先 長く効く先 会議体の設計と運 営 短期 × 組織: 情報同期、意思決定、ブロッカー 共有 長期 × 組織: 運営ルールとして再現性が残る 心理的安全性の醸 成 短期 × 組織: 相談や障害共有がしやすくなる 長期 × 組織: チーム文化として定着する 技術負債の返済計 画 長期 × 個人: 特定チームの変更容易性が上がる 長期 × 組織: 全体の保守性や基盤投資方針に波及 する 唯一の正解に厳密に分類するというより、主作用がどこにあるか を置き、 必要なら副作用先もあわせて見ると扱 いやすい。 14
15. EM Work Visualizer これまでの考えをベースにして、EMとしての現在地を可視化できるツールを作った。 https://em-work-visualizer.pages.dev/ 業務カテゴリごとに設定されているタスクを選択すると影響範囲に応じた位置にプロットさ れる。プロットされている位置を元に自分が今どのカテゴリの仕事をどの影響範囲でできて いるかが可視化できる。 15
18. このツールの用途 1. 週次の棚卸し 自分の時間が短期 × 個人に寄りすぎていないかをチ ェックする。 2. チーム課題の診断 問題を「人の頑張り不足」ではなく、どのカテゴリ・ どの象限が弱いかで見る。 3. 役割分担 TL、PdM、EMでどの領域を誰が主に持つかを会話し やすくする。 4. 育成と評価 EM候補に何を経験してもらうか、どこが不足してい るかを具体化する。 18
19. まとめ EMの仕事はプロジェクト/プロダクト/ピープル/テクノロジー の4カテゴリで整理できる さらに、短期 〜 長期 と 個人 〜 組織 の影響範囲で見ると、仕事の性質が見えやすくなる 目先の仕事から長期×組織に効く仕事をどう積み上げるかが職位の違いになりそう EM Work Visualizerを使った。これを使えばEMとして現在地の把握や他の役職の人たち とのコミュニケーションにも使える(かも)。 19