この記事は、SEN アドベントカレンダー2025の 24日目の記事です！
はじめに
こんにちは！千株式会社でエンジニアリングマネージャーをしている daitasuです。
皆さんは普段、権限移譲をどのようにされていますか？
組織の中で、下記のような課題はありませんか？
- 誰が意思決定すべきか分からずボール落ちになる
- リーダーやマネージャーが仕事を持ちすぎてしまっている
- 課題は分かっているがやっていいのかよく分からない
チームの課題解決に向けた方針、ロードマップの策定、仕様のFIX、技術負債の解消の進め方、システム設計の決め方などなど。
プロダクト開発の現場では、様々な意思決定の場に直面します。
こうした意思決定を円滑に進めるためには、「誰」が「どんな」権限を持っているか、 権限の移譲 と チーム内の共通認識 が非常に重要です。
本日は、こうした権限移譲について、筆者が普段意識している
- 権限移譲は、期待役割を「当事者」と「その周り」に合わせて開示しよう
というテーマについて事例を交えてお話します！
権限移譲のアンチパターン
こんな経験はありませんか？
- 自分が上司に何を期待されているのかがよく分からない
- 「〇〇さんには、チームリーダーを今後担ってほしい」と口頭では言われたが、なんとなく動きづらい
- チームリーダーやステークホルダーが話してる内容が異なり、誰の方針に従えばよいか分からない
- この人は「こうします」と話しているが、それは上の人達と認識が揃っている？
※ あまり「上の人達」という言葉は好きではないのですが、組織の権限上で分かりやすいようにこの言葉で表現してます
上の図は極端な例ですが、実際こうした場面はよく起こります。
では、どのようにしていくと上手く権限移譲が回るのでしょうか？
よく権限移譲の問題で、 「責務」と「権限」はセット という話が出ることがありますが、 筆者はこの「責務の委譲」と「権限の移譲」を下記のように捉えています。
- 責務の委譲 = 責任感(オーナーシップ)の委譲
- 上記の上司が口頭で託し、それを委譲される側が引き受けた状態です
- 「これを自分が成す」という責任感はここでボールが合意が取れたことになります
- 権限の移譲 = その人が決定を行い、まわりがその人の方針に 「同意可能な構造」ができていること
- 上記の問題が起きる理由はこちらだと捉えています
- チームの共通認識が成せていない
- 言葉として明示されておらず、受け取り方が人によってズレている
- ツール等の実質的権限が付与されていない、といった仕組み上の問題も含んでいます
- 上記の問題が起きる理由はこちらだと捉えています
Case1. チーム全員への期待値を言語化する
筆者の場合、チームの目標設定の際に、チーム全員への「マネージャーから託したいこと」 として期待値をみんなに見えるようにしています。
- 組織目標
- チーム目標
- 個人目標
と評価査定の観点では棚卸しがなされるのですが、それぞれの「個人目標」はセンシティブなものでもあるので、評価者しか見れないケースが多いです。
しかし、「マネージャーが何を託したいと思っているか」はあくまで マネージャーの思い 。
むしろチーム全員に開示した方が良いものだと考えています。
開示することで、メンバーとしては「個人目標」を立てやすくなりますし、他の人が何を期待されているのかが見えることで、その人とのコミュニケーションもしやすくなります。
Case2. チーム全員で期待値をすり合わせる
私たちのチームでは、メンバーが変わったタイミングなど、定期的にドラッガー風エクササイズというものを行っています。 (GMO ペパボさんのワークを参考にさせていただいています)
3つの色の付箋を用いてワークを行います。
- 自分のアイコンの箇所に置く付箋
- 緑：自分の得意なこと・強み
- 青：どんなことを期待されていると思うか
- 他者のアイコンの箇所に置く付箋
- 黄：他のメンバーに期待することはなにか
これにより、
- チームメンバーが自分に期待してくれていることの把握
- 自分が発揮したいバリューの共有
- 自分が発揮したいバリューとまわりの期待の認識のズレの理解
が出来ます。
例えば、新卒エンジニアの方やプロダクトマネージャーだと下記のような感じです！
| プロダクトマネージャー | 新卒エンジニア |
|---|---|
 |
 |
Case3. デリゲーションポーカー
- マネージャーからの期待値の言語化と開示
- チームメンバーからの期待値の言語化と開示
これらが終わったことで、それぞれが「自分に期待されていることはなにか」「他のメンバーが期待されていることはなにか」が見えるようになってきました。
しかし、これだけだと、「期待」が見えただけで具体的な 権限移譲 にはなりません。
上記を踏まえたうえで、もう少し粒度を落とし、
「どの意思決定」は「誰」がするのか？ まで明示したいです。
私たちのチームでは、デリゲーションポーカーというフレームワークを用いて行っています。
職種ごとの責務について目線を揃える
まず前提として、各職種はどんな役回りなのかの目線合わせから行います。
- プロダクトマネージャーとは？
- エンジニアリングマネージャーとは？
- テックリードとは？
- プロジェクトマネージャーとは？
下記の記事から引用しつつ、自チームで職種理解を深めてました。
- エンジニアリングマネージャ/プロダクトマネージャのための知識体系と読書ガイド
- プロジェクトマネージャー（PjM）とプロダクトマネージャー（PdM）、プロダクトオーナー（PO）の違いとは
- PM, PdM, PjM, PL, PMOの役割の違い
- 「EMはテックリードがやらないすべてのことを」 “困難さを理解している”からこそできる、“二人三脚”の進め方
チーム全員で自分の「今」と「今後ありたい位置」の意思決定権を明示する
デリゲーションポーカーには、一部アレンジを加えています。
7段階の権限のうち、真ん中の4番を「全員で話し合って決めること」として、左に行くほど「意思決定を行う主体」となり、右に行くほど「決定の主体から離れる」ようになります。
この7つの項目に対し、
- As-is: 自分は今どの位置にいるか
- To-be: これからどの位置になっていきたいか
の2点を書いてもらいます。
このワークは、
- 技術関係
- プロダクト関係
- プロジェクト関係
- ピープル・チーム関係
で様々な意思決定を区分けし、全員が参加することを重要視しています。
これにより、
- 当人のオーナーシップの形成 = 責務の委譲
- まわりが意思決定に同意可能な状態(共通認識)の形成 = 権限の移譲
を図っています。
Case4. 全員で決める場は、Github Discussions に集約する
デリゲーションポーカーにおける4番「全員で話し合って決めること」や３、５番の「叩き作ったんですがどうでしょう？」は、新たな役割に慣れていくまでは、場の提供とセットとしないとやりづらさが生まれます。
そのため、事前に Github Discussions に決議したいことを記載いただき、日々のデイリースクラムの後に、「相談会」というものを設けて決めるようにしています。
こちらの話については、以前別記事に書いたためそちらもご参考ください。
まとめ
この記事では、筆者が大事にしている 権限移譲は、期待役割を「当事者」と「その周り」にも開示しよう というテーマに際して、
「責務」の観点と「権限」の観点を解釈し直し、様々な方法で共通認識を図っている事例を紹介しました！
こうした委譲は定期的なアップデートが必要なため、今後も継続的にトライしていこうと思います！
明日のSEN Advent Calendar 2025は、最終日！ 🎉 弊社のCTO ytake さんの記事です。
ぜひご一読ください！！！
We are hiring !
千では、チームのパフォーマンスを上げたり、技術改善を牽引していくエンジニアリングマネージャーやテックリードを積極的に募集してます！
