開発組織の課題解決を加速するための権限委譲 -する側、される側としての向き合い方-

2026.3.4 「Engineering Management Conference Japan 2026」における登壇資料です。
https://2026.emconf.jp/
https://fortee.jp/emconf-2026/proposal/bcaf220f-3b1a-46ce-9b3c-1771aa0b6669

Transcript

1. 藤井 大祐 (daitasu) 開発組織の課題解決を加速するための権限委譲 　　　　　　　　　　〜する側、される側としての向き合い方〜 2026年3月4日 Engineering Management Conference Japan 2026 千株式会社
2. 自己紹介 Name: @daitasu Belong to: Engineering Manager in SEN, Inc. Favorite: TypeScript, Sauna, Cafe, Dinasaurus Community: 　　　Tachikawa.any (第1回 4月開催予定) @daitasu
3. 会社紹介 写真を中心とした、幼保業界の DXプロダクトを展開
4. 本日のお話 開発組織の課題解決を加速するための権限委譲 　　　　　　〜する側、される側としての向き合い方〜
5. Learning Outcome 対象聴衆： • 自分のキャパシティが限界に達しているEM • 組織課題に手を出したいが、どう動けばいいか分からないEM このセッションで得られるもの： • 経営層から権限を引き出すための、委員会制度などの具体的な仕組みと交渉方法 • 自チーム内で権限委譲を進める際の、期待値の伝え方と可視化、段階的な任せ方のコツ
6. 最初に本日の結論
7. 権限と責務の委譲は 「当事者」と「周囲」をセットで巻き込もう！
8. エンジニアリングマネージャーの役割とは？ “マネージャーのアウトプット 　= あなたのチームのアウトプット 　+ あなたが影響を与えた他のチームのアウトプット”
9. エンジニアリングマネジメントのキャリアラダー チームの 技術リード メンバー テックリード 人/チームの管理 マネージャー シニアマネージャー 複数チームの管理 技術部長 複数の管理者の管理 CTO/VPoE 経営幹部 マネジメントの大まかな例
10. マネージャーは多くの場合、 組織の「中間」に存在する
11. エンジニアリングマネージャーが向き合う課題 ① 自分のチームの課題 ② 開発組織全体の課題 ③ 部門間の課題
12. 中長期的な成果を目指すほど、より広範囲の課題に直面する 1チームの 課題 複数チームの 課題 開発組織の 課題 経営課題 生産性最大化 採用 予算管理 オンボー ディング 事業計画 人事設計 技術広報 部門間シナジー プロダクトロードマップ 技術戦略
13. 大前提、人は「有限」
14. 見るべきものを絞る 生産性最大化 採用 予算管理 オンボー ディング 事業計画 人事設計 技術広報 部門間シナジー プロダクトロードマップ 技術戦略 EM EM CTO/VPoE 誰が何を担うのか、 可視化が重要
15. 見るべきものを絞る 生産性最大化 採用 予算管理 オンボー ディング 事業計画 人事設計 技術広報 部門間シナジー プロダクトロードマップ 技術戦略 EM EM CTO/VPoE 誰が何を担うのか、 明示化が重要 責務と権限の委譲
16. 権限移譲がうまくいっていないとき
17. 権限移譲がうまくいっていないとき 当事者たちの意思決定は、 周囲の人には見えない 権限委譲の成立には、 「可視化」と「承認」が必須
18. 権限と責務のあるべき姿 形式的な状態 真の成立条件 責務の委譲 双方の合意・約束 例：「頼んだよ！」「はい！」 受け手の「内発的な当事者意識」 例：「俺が守護神！絶対にやり遂げるんだ！」 権限の委譲 言葉や書面での明示 例：議事録「〇〇に託すことにする」 周囲の「社会的承認」 例：「この件は〇〇さんに相談すればOKです よね？」 委譲の真の成立には「委譲される当人」と「周囲の人」 の認知変容(承認)が必要
19. SEN CORPORATION 千の権限委譲 される側 開発組織の話
20. 開発組織の特徴：急激なリード層の増加 Before After プロダクトA (メイン事業) プロダク トB プロダク トC EM 1名 (PdM兼務) EM 1名 (PdM兼務) PdM 1名 (EM兼務) メンバー 20人程度 メンバー 5人程度 メンバー 10人弱 VPoE • EM or PdMが兼務で1プロダクトを担い、 プロジェクト遂行で手一杯 • VPoE 1人で組織/技術/プロダクトと経営 との橋渡しを全て担う • CTOが参画し、経営層の責務分割が進む • リード層が急増し、EM/PdM が揃う状態へ • 組織課題に向き合う余力が生まれる プロダクトA (メイン事業) プロダク トB プロダク トC EM 1名 PdM 1名 EM 2名 PdM 3名 PdM (EM兼務) メンバー 20人程度 メンバー 5人程度 メンバー 10人弱 VPoE プラット フォーム 情シス QA SRE R＆D リード層増加
21. 課題は見えてきたが、委譲が急務へ マネージャー/リード層から 組織の問題提起が増加 嬉しい悲鳴だが、 既存の体系から責務の見直しが急務に 評価制度を 見直したい 採用を 加速化せね ば 技術広報を 強化したい オンボーディ ングを 改善したい ちょ、ちょっと待っ て、、、！ VPoE マネジメント層 VPoE/CTOから巻き取れる 課題はないか考え始める
22. 上位レイヤーから業務を巻き取る際の3つの壁 VPoEやCTOには、経営陣への説明責任がある 説明責任を担保しつつ、実行責任を奪える構造を作らねばならない リソースの壁 連携の壁 信頼の壁 委譲準備もできない忙し い上位層から、どう権限 を引き出すか？ マネージャー間で連携し、 組織としての統制を図れ るか？ 現場に任せても「説明 責任」を果たせる状態 をどう作るか？
23. 解1 ： リソースの壁を突破する 判断するだけの状態をつくる(当事者意識の証明) 決裁者としては、成果の解像度が粗いと判断が難しい 自分が思う 理想の組織体制を Figma に整理 人事と共に ブログを作成し 投稿者を募る OKR導入を検討し、 組織目標を仮定して自 チームで導入 可視化で課題感の 目線を揃える 運用の流れをトライアルで 構築 自分の脳内を可視化し、実例を 作る(成果と反省を作る)
24. 解2 : 横の壁（マネージャー間の合意）を突破する EM / PdM 全員によるワークショップで、 組織課題についての洗い出しを実施
25. 解3 : 信頼の壁（説明責任）を担保する 半期の注力テーマを4つまで絞る 委員会制度を定め、週次の部会でレポート 1. 最初に半期の目標、マイルストンを策定 2. 週次の部会でVPoE/CTO/取締役から フィードバック(縦軸の承認) 3. 適宜、マネージャー全体でのワークショッ プ等を実施(横軸の承認)
26. 結果(される側) • 半期で各テーマごとにマネージャー主導で多くの課題解決を リードできた • 人事や広報など、マネージャーとコーポレートの連携が強化され、 会社全体としての動きへと接続された
27. SEN CORPORATION 千の権限委譲 　する側 自チームの 課題解決の話
28. 自チームの特徴 事業部制チームで、マネジメント配下に PdM/デザイナー/エンジニアが存在 ◎ ✕ • 組織的な壁がなく、統制が早い ◦ AI の利活用推進など • 職能を超えた振る舞いがしやすい ◦ デザイナーが開発する等 • 職能単位の役割が明文化されない ◦ 責任の所在が曖昧 • 意思決定がマネージャーに集約さ れやすい
29. のしかかる課題は山積み 退職ラッシュや組織再編などもあり、あらゆるボールを受け持つことに
30. 全然MTGに来ない私 毎日5-6h MTG がデフォに。 全くチームMTGに来ない人へ。。。
31. マネージャー不在で回るチームへ。 意思決定オーナーの言語化が必要
32. 1:1の合意：目標設定面談で個人との目線を揃える 目標設定とは別に、自分の「なりたい像」を書いてもらう 各自のWill とチーム状況を紐づけて期待値を設定 (内発的な当事者意識の醸成) 合意
33. 1:N の開示：全メンバーへの期待値を「文字」として開示 「MGRとして託したいこと」としてチーム全体に それぞれへの期待を開示 誰 が 何 を期待されているか、 メンバー同士で分かる状態をつくる (縦軸の承認の開示) 開示
34. 横軸の承認： ① ドラッガー風エクササイズ メンバー同士 に書いてもらうことで、 双方向の期待合わせ(横軸の承認)を促す 横軸の承認 緑：自分の得意なこと・強み 青：どんなことを期待されていると思うか 黄：他のメンバーに期待することはなにか
35. 横軸の承認：② デリゲーションポーカー 意思決定の委譲 を促すワークショップ 意思決定から離れるほど右に進む 横軸の承認
36. 横軸の承認：② デリゲーションポーカー as-is と to-be の自分の位置にアイコンを配置 誰が何を決めるのかを承認(認知変容)する 横軸の承認
37. 意思決定の場づくり 権限 が 明示 されても、 「意思決定の場」がないと軌道に乗らない 場
38. 意思決定の場づくり：① ADRの作成 ADR（Architecture Decision Record） を作成し、デイリーMTGで合意。 技術に限らず、仕様案、デザイン相談、なんでもOK。 場 Github Discussion のQ＆Aを採用
39. 結果(する側) • 自身がチームに介入する機会が減りつつも、チームの生産性は向上し、プロジェク トが安定稼働へ • ビジネスサイドから自分に対するメンションが減り、意思決定をするメンバーに直接 飛ぶように変わった • 自身からの委譲だけでなく、テックリードやPdMから他メンバーへの意思決定 の委譲も加速した
40. まとめ 責務と権限を渡すには、するもされるも 認知醸成が不可欠 受け手の「内発的な当事者意識」 周囲の「社会的承認」
41. するもされるも 権限の縦と横の「可視化」と「場作り」は 概ね変わらない
42. 権限と責務の委譲は 「当事者」と「周囲」をセットで巻き込もう！