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

Embed

Start on current slide

Slide 1

Slide 1 text

藤井大祐 (daitasu) 開発組織の課題解決を加速するための権限委譲　　　　　　　　　　〜する側、される側としての向き合い方〜 2026年3月4日 Engineering Management Conference Japan 2026 千株式会社

Slide 2

Slide 2 text

自己紹介 Name: @daitasu Belong to: Engineering Manager in SEN, Inc. Favorite: TypeScript, Sauna, Cafe, Dinasaurus Community: 　　　Tachikawa.any (第1回 4月開催予定) @daitasu

Slide 3

Slide 3 text

会社紹介写真を中心とした、幼保業界の DXプロダクトを展開

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

Learning Outcome 対象聴衆： ● 自分のキャパシティが限界に達しているEM ● 組織課題に手を出したいが、どう動けばいいか分からないEM このセッションで得られるもの： ● 経営層から権限を引き出すための、委員会制度などの具体的な仕組みと交渉方法 ● 自チーム内で権限委譲を進める際の、期待値の伝え方と可視化、段階的な任せ方のコツ

Slide 6

Slide 6 text

最初に本日の結論

Slide 7

Slide 7 text

権限と責務の委譲は「当事者」と「周囲」をセットで巻き込もう！

Slide 8

Slide 8 text

エンジニアリングマネージャーの役割とは？ “マネージャーのアウトプット　= あなたのチームのアウトプット　+ あなたが影響を与えた他のチームのアウトプット”

Slide 9

Slide 9 text

エンジニアリングマネジメントのキャリアラダーチームの技術リードメンバーテックリード人/チームの管理マネージャーシニアマネージャー複数チームの管理技術部長複数の管理者の管理 CTO/VPoE 経営幹部マネジメントの大まかな例

Slide 10

Slide 10 text

マネージャーは多くの場合、組織の「中間」に存在する

Slide 11

Slide 11 text

エンジニアリングマネージャーが向き合う課題 ① 自分のチームの課題 ② 開発組織全体の課題 ③ 部門間の課題

Slide 12

Slide 12 text

中長期的な成果を目指すほど、より広範囲の課題に直面する 1チームの課題複数チームの課題開発組織の課題経営課題生産性最大化採用予算管理オンボーディング事業計画人事設計技術広報部門間シナジープロダクトロードマップ技術戦略

Slide 13

Slide 13 text

大前提、人は「有限」

Slide 14

Slide 14 text

見るべきものを絞る生産性最大化採用予算管理オンボーディング事業計画人事設計技術広報部門間シナジープロダクトロードマップ技術戦略 EM EM CTO/VPoE 誰が何を担うのか、可視化が重要

Slide 15

Slide 15 text

見るべきものを絞る生産性最大化採用予算管理オンボーディング事業計画人事設計技術広報部門間シナジープロダクトロードマップ技術戦略 EM EM CTO/VPoE 誰が何を担うのか、明示化が重要責務と権限の委譲

Slide 16

Slide 16 text

権限移譲がうまくいっていないとき

Slide 17

Slide 17 text

権限移譲がうまくいっていないとき当事者たちの意思決定は、周囲の人には見えない権限委譲の成立には、「可視化」と「承認」が必須

Slide 18

Slide 18 text

権限と責務のあるべき姿形式的な状態真の成立条件責務の委譲双方の合意・約束例：「頼んだよ！」「はい！」受け手の「内発的な当事者意識」例：「俺が守護神！絶対にやり遂げるんだ！」権限の委譲言葉や書面での明示例：議事録「〇〇に託すことにする」周囲の「社会的承認」例：「この件は〇〇さんに相談すればOKですよね？」委譲の真の成立には「委譲される当人」と「周囲の人」の認知変容(承認)が必要

Slide 19

Slide 19 text

SEN CORPORATION 千の権限委譲される側開発組織の話

Slide 20

Slide 20 text

開発組織の特徴：急激なリード層の増加 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 リード層増加

Slide 21

Slide 21 text

課題は見えてきたが、委譲が急務へマネージャー/リード層から組織の問題提起が増加嬉しい悲鳴だが、既存の体系から責務の見直しが急務に評価制度を見直したい採用を加速化せねば技術広報を強化したいオンボーディングを改善したいちょ、ちょっと待って、、、！ VPoE マネジメント層 VPoE/CTOから巻き取れる課題はないか考え始める

Slide 22

Slide 22 text

上位レイヤーから業務を巻き取る際の3つの壁 VPoEやCTOには、経営陣への説明責任がある説明責任を担保しつつ、実行責任を奪える構造を作らねばならないリソースの壁連携の壁信頼の壁委譲準備もできない忙しい上位層から、どう権限を引き出すか？マネージャー間で連携し、組織としての統制を図れるか？現場に任せても「説明責任」を果たせる状態をどう作るか？

Slide 23

Slide 23 text

解1 ：リソースの壁を突破する判断するだけの状態をつくる(当事者意識の証明) 決裁者としては、成果の解像度が粗いと判断が難しい自分が思う理想の組織体制を Figma に整理人事と共にブログを作成し投稿者を募る OKR導入を検討し、組織目標を仮定して自チームで導入可視化で課題感の目線を揃える運用の流れをトライアルで構築自分の脳内を可視化し、実例を作る(成果と反省を作る)

Slide 24

Slide 24 text

解2 : 横の壁（マネージャー間の合意）を突破する EM / PdM 全員によるワークショップで、組織課題についての洗い出しを実施

Slide 25

Slide 25 text

解3 : 信頼の壁（説明責任）を担保する半期の注力テーマを4つまで絞る委員会制度を定め、週次の部会でレポート 1. 最初に半期の目標、マイルストンを策定 2. 週次の部会でVPoE/CTO/取締役からフィードバック(縦軸の承認) 3. 適宜、マネージャー全体でのワークショップ等を実施(横軸の承認)

Slide 26

Slide 26 text

結果(される側) ● 半期で各テーマごとにマネージャー主導で多くの課題解決をリードできた ● 人事や広報など、マネージャーとコーポレートの連携が強化され、会社全体としての動きへと接続された

Slide 27

Slide 27 text

SEN CORPORATION 千の権限委譲　する側自チームの課題解決の話

Slide 28

Slide 28 text

自チームの特徴事業部制チームで、マネジメント配下に PdM/デザイナー/エンジニアが存在 ◎ ✕ ● 組織的な壁がなく、統制が早い ○ AI の利活用推進など ● 職能を超えた振る舞いがしやすい ○ デザイナーが開発する等 ● 職能単位の役割が明文化されない ○ 責任の所在が曖昧 ● 意思決定がマネージャーに集約されやすい

Slide 29

Slide 29 text

のしかかる課題は山積み退職ラッシュや組織再編などもあり、あらゆるボールを受け持つことに

Slide 30

Slide 30 text

全然MTGに来ない私毎日5-6h MTG がデフォに。全くチームMTGに来ない人へ。。。

Slide 31

Slide 31 text

マネージャー不在で回るチームへ。意思決定オーナーの言語化が必要

Slide 32

Slide 32 text

1:1の合意：目標設定面談で個人との目線を揃える目標設定とは別に、自分の「なりたい像」を書いてもらう各自のWill とチーム状況を紐づけて期待値を設定 (内発的な当事者意識の醸成) 合意

Slide 33

Slide 33 text

1:N の開示：全メンバーへの期待値を「文字」として開示「MGRとして託したいこと」としてチーム全体にそれぞれへの期待を開示誰が何を期待されているか、メンバー同士で分かる状態をつくる (縦軸の承認の開示) 開示

Slide 34

Slide 34 text

横軸の承認： ① ドラッガー風エクササイズメンバー同士に書いてもらうことで、双方向の期待合わせ(横軸の承認)を促す横軸の承認緑：自分の得意なこと・強み青：どんなことを期待されていると思うか黄：他のメンバーに期待することはなにか

Slide 35

Slide 35 text

横軸の承認：② デリゲーションポーカー意思決定の委譲を促すワークショップ意思決定から離れるほど右に進む横軸の承認

Slide 36

Slide 36 text

横軸の承認：② デリゲーションポーカー as-is と to-be の自分の位置にアイコンを配置誰が何を決めるのかを承認(認知変容)する横軸の承認

Slide 37

Slide 37 text

意思決定の場づくり権限が明示されても、「意思決定の場」がないと軌道に乗らない場

Slide 38

Slide 38 text

意思決定の場づくり：① ADRの作成 ADR（Architecture Decision Record）を作成し、デイリーMTGで合意。技術に限らず、仕様案、デザイン相談、なんでもOK。場 Github Discussion のQ＆Aを採用

Slide 39

Slide 39 text

結果(する側) ● 自身がチームに介入する機会が減りつつも、チームの生産性は向上し、プロジェクトが安定稼働へ ● ビジネスサイドから自分に対するメンションが減り、意思決定をするメンバーに直接飛ぶように変わった ● 自身からの委譲だけでなく、テックリードやPdMから他メンバーへの意思決定の委譲も加速した

Slide 40

Slide 40 text

まとめ責務と権限を渡すには、するもされるも認知醸成が不可欠受け手の「内発的な当事者意識」周囲の「社会的承認」

Slide 41

Slide 41 text

するもされるも権限の縦と横の「可視化」と「場作り」は概ね変わらない

Slide 42

Slide 42 text

権限と責務の委譲は「当事者」と「周囲」をセットで巻き込もう！