チームと組織を磨く「決めさせる」技術 — 組織横断課題を動かすための枠組み作りと権限委譲

111 Views

October 31, 26

スライド概要

KomeKaigi 2026(2026/10/31 新潟・NINNO3)での発表資料です。
https://komekaigi.dev/

おまけスライド: https://www.docswell.com/s/hk_it7/5E1DQE-komekaigi_2026_kouno_omake

1プロダクトを3チームで開発していると、CI改善やコンテキスト整備のような
「全体に関わる改善」に誰も手を出せなくなります。
意欲がないからではなく、「他チームに影響が出たら」「誰かがやるだろう」で
手が止まる構造になっているからです。

この構造を動かすために立ち上げた「分科会チーム」の、失敗と成功の記録です。
最初の募集は立候補ゼロ。そこから何を語り直し、事業部とどう握り、
どこまで権限を渡したのかを話しました。

■ 話していること

・横断の仕事に「名前」をつけると何が変わるのか(他社の制度も3つ調べました)
・事業部には「10%の時間をください」ではなく「◯◯万円を投資してください」と言う
人件費を時給に割り戻した投資額の出し方と、自分から引く撤退ライン
・返済期間と「複利」という見方。そして結果(達成率で報告しています)
・「この領域は分科会の決定に従う」という強い権限の渡し方
・委譲と放置を分けるのは最初の一歩。伴走したうえで、最後は「決めさせる」

■ こんな方に

・複数チーム開発で横断的な改善が進まない現場のリーダー/EM/エンジニア
・メンバーへの権限委譲で、フォローの加減に悩んでいる方

■ 参考にした本・事例

・宇田川元一『他者と働く──「わかりあえなさ」から始める組織論』
・マシュー・スケルトン、マニュエル・パイス『チームトポロジー』
・Robin Williams『ノンデザイナーズ・デザインブック』
・Dustin Boswell、Trevor Foucher『リーダブルコード』
・pixiv inside「チームの価値創造を支えるエンジニア職組織『エンジニアギルド』のご紹介」
https://inside.pixiv.blog/bash/7480
・inSmartBank「100人の壁を乗り越える“委員会制度”へのチャレンジ」
https://blog.smartbank.co.jp/entry/2025/07/02/committee-system-introduction

profile-image

Ruby/Javaプログラマー。エンジニアリングマネージャー。 軽度の広く浅いオタク。

シェア

またはPlayer版

埋め込む »CMSなどでJSが使えない場合

ダウンロード

関連スライド

各ページのテキスト
1.

チームと組織を磨く 「決めさせる」技術 組織横断課題を動かすための枠組み作りと権限委譲 KomeKaigi 2026 — 2026.10.31 新潟 / こうの(@hk_it7)

2.

1プロダクトを、3チームで チーム A チーム B チーム C どのチームにも属さない仕事 チームを分けた瞬間に、チームの間に「隙間」ができる 2

3.

「誰かがやってくれれば…」 CI が遅い。開発のコンテキストが整っていない 直したい。でも他チームに影響が出たらと思うと手が止まる 結果、誰も手を出さない 意欲の問題ではなく、構造の問題だった 3

4.

まず、他社がどう解いているか調べた 枠組み やっていること エンジニアギルド pixiv 採用・評価・育成を事業部横断で見る職能組織 (2018〜) 委員会制度 ミッションチームと兼務で重要課題へ。 SmartBank (2025〜) 委員長にOKRと人員配置を委譲 チームトポロジー イネイブリングチーム 他チームの障壁を取り除き、能力向上を支援 共通点:横断の仕事に、名前と居場所が与えられている pixiv inside「チームの価値創造を支えるエンジニア職組織『エンジニアギルド』のご紹介」(2019) / inSmartBank「100人の壁を乗り越え る“委員会制度”へのチャレンジ」(2025) / 『チームトポロジー』第5章 4

5.

名前がつくと、見えるようになる ジョシュアツリーの法則 名前を知った翌日から、町中のジョシュアツリーが目に入る 『リーダブルコード』第2章「名前に情報を詰め込む」 名前は、意図を伝えるいちばん短いドキュメント Robin Williams『ノンデザイナーズ・デザインブック』冒頭「ジョシュアツリーの悟り」/ Boswell・Foucher『リーダブルコード』第2章 名前のない仕事は、誰の仕事でもない 5

6.

「分科会」と名前をつけた 相談会 分科会 できること 意見を出す 決める 終わり方 提案して解散 実行して結果を見る 権限 なし その領域の決定権 「横断課題に向き合うチームを作る」と宣言して、名前を与えた 6

7.

0人 最初の募集:立候補ゼロ 全体ミーティングで「やりたい人いますか」と聞いた結果 7

8.

何を、しか言っていなかった 伝えたこと → What(分科会を作ります/こういう課題をやります) 伝えていなかったこと → Why(なぜ自分がこれをやりたいのか) 制度の説明に人は集まらない。 困っていることと、見たい未来に集まる。 8

9.

「なぜやるのか」から話し直した 1. いま何に困っているか(具体的な事実で) 2. なぜ放置され続けるのか(構造の話) 3. 半年後にどうなっていてほしいか 共感したメンバーが集まり、発足 9

10.

事業部には「時間」ではなく「円」で話した 当初の試算(数字はすべて説明用の例) 時給 月収 40万円 ÷ 160時間 = 2,500円/時 改善枠 業務時間の 10% = 月 16時間/人 月次コスト 2,500円 × 16時間 × 3人 = 月 12万円 ← 3人で回す前提 投資額 月 12万円 × 6ヶ月 = 72万円 「時間をください」ではなく「72万円を投資してください」と言う 自分の言葉ではなく、相手のナラティヴの言葉で話す 宇田川元一『他者と働く──「わかりあえなさ」から始める組織論』第2章「ナラティヴの溝を渡るための4つのプロセス」 10

11.

返済期間と、複利 実際に集まったのは2人 → 投資額は 72万 から 48万円 に ← 恩恵を受ける全員分で数える 回収 削減できた時間 × 時給 例 開発者 10人 × 月4時間 = 月40時間 = 月 10万円 返済 48万円 ÷ 月10万円 = 約5ヶ月 一度削った時間は、翌月以降もゼロ円で効き続ける 浮いた時間が、次の改善の原資になる = 複利 撤退ライン:半年で返済の目処が立たなければ、分科会側から止める 11

12.

「この領域は、分科会の決定に従う」 組織のルールとして置いた(お願いではなく) 他チームへの事前相談を必要としない範囲を決めた 反対は分科会に持ち込む。止めるのではなく議論の場所を1つにする 遠慮が消えると、手が動く 12

13.

委譲と放置を分けるのは「最初の一歩」 誰がやるか 課題のブレイクダウン 一緒にやる 解決策のブレスト 一緒にやる コスパ試算(どこから手を付けるか) 一緒に確認する 最終決定 チームが決める 立ち上がりだけフォローを厚くして、決定は渡したまま動かさない 13

14.

最初に出した What から、ズレてもいい 成果に繋がるなら やることを変えていい 最終的な意思決定は、チームのもの 14

15.

で、返せたのか 目標 半年で投資額を回収 = 回収率 100% 実績 半年後の時点で = 回収率 70% 金額ではなく率で見ると、人件費の実額を出さずに話せる 比率なら、規模の違う組織でもそのまま持ち帰れる 撤退ラインを先に引いてあったから、この数字を堂々と見せられる 15

16.

自分たちで「やらない」を決めた 進めていたアプローチを、分科会自身が筋が悪いと判断して切り捨て た 他チームとの調整は、リーダーが防波堤として引き受けた チームは意思決定に集中できた 自走するチームになった 16

17.

枠組みと名前は、横断課題一般に効く 技術負債の解消 / CI・CD の改善 / ドキュメント整備 セキュリティ対応 / 採用・オンボーディング強化 どれも「重要だが、誰の担当でもない」という同じ形をしている 17

18.

まとめ 1. 名前をつけて、枠組みを用意する — Why を自分の言葉で語る 2. ROI と撤退ラインで、事業部を説得し、チームを守る 3. 強い権限を渡し、最初だけ伴走し、最後は決めさせる 18

19.

名前のない仕事に、 名前をつける 枠組みというお結びで、チームを磨き上げる ありがとうございました — こうの(@hk_it7)