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
Ruby/Javaプログラマー。エンジニアリングマネージャー。 軽度の広く浅いオタク。
チームと組織を磨く 「決めさせる」技術 組織横断課題を動かすための枠組み作りと権限委譲 KomeKaigi 2026 — 2026.10.31 新潟 / こうの(@hk_it7)
1プロダクトを、3チームで チーム A チーム B チーム C どのチームにも属さない仕事 チームを分けた瞬間に、チームの間に「隙間」ができる 2
「誰かがやってくれれば…」 CI が遅い。開発のコンテキストが整っていない 直したい。でも他チームに影響が出たらと思うと手が止まる 結果、誰も手を出さない 意欲の問題ではなく、構造の問題だった 3
まず、他社がどう解いているか調べた 枠組み やっていること エンジニアギルド pixiv 採用・評価・育成を事業部横断で見る職能組織 (2018〜) 委員会制度 ミッションチームと兼務で重要課題へ。 SmartBank (2025〜) 委員長にOKRと人員配置を委譲 チームトポロジー イネイブリングチーム 他チームの障壁を取り除き、能力向上を支援 共通点:横断の仕事に、名前と居場所が与えられている pixiv inside「チームの価値創造を支えるエンジニア職組織『エンジニアギルド』のご紹介」(2019) / inSmartBank「100人の壁を乗り越え る“委員会制度”へのチャレンジ」(2025) / 『チームトポロジー』第5章 4
名前がつくと、見えるようになる ジョシュアツリーの法則 名前を知った翌日から、町中のジョシュアツリーが目に入る 『リーダブルコード』第2章「名前に情報を詰め込む」 名前は、意図を伝えるいちばん短いドキュメント Robin Williams『ノンデザイナーズ・デザインブック』冒頭「ジョシュアツリーの悟り」/ Boswell・Foucher『リーダブルコード』第2章 名前のない仕事は、誰の仕事でもない 5
「分科会」と名前をつけた 相談会 分科会 できること 意見を出す 決める 終わり方 提案して解散 実行して結果を見る 権限 なし その領域の決定権 「横断課題に向き合うチームを作る」と宣言して、名前を与えた 6
0人 最初の募集:立候補ゼロ 全体ミーティングで「やりたい人いますか」と聞いた結果 7
何を、しか言っていなかった 伝えたこと → What(分科会を作ります/こういう課題をやります) 伝えていなかったこと → Why(なぜ自分がこれをやりたいのか) 制度の説明に人は集まらない。 困っていることと、見たい未来に集まる。 8
「なぜやるのか」から話し直した 1. いま何に困っているか(具体的な事実で) 2. なぜ放置され続けるのか(構造の話) 3. 半年後にどうなっていてほしいか 共感したメンバーが集まり、発足 9
事業部には「時間」ではなく「円」で話した 当初の試算(数字はすべて説明用の例) 時給 月収 40万円 ÷ 160時間 = 2,500円/時 改善枠 業務時間の 10% = 月 16時間/人 月次コスト 2,500円 × 16時間 × 3人 = 月 12万円 ← 3人で回す前提 投資額 月 12万円 × 6ヶ月 = 72万円 「時間をください」ではなく「72万円を投資してください」と言う 自分の言葉ではなく、相手のナラティヴの言葉で話す 宇田川元一『他者と働く──「わかりあえなさ」から始める組織論』第2章「ナラティヴの溝を渡るための4つのプロセス」 10
返済期間と、複利 実際に集まったのは2人 → 投資額は 72万 から 48万円 に ← 恩恵を受ける全員分で数える 回収 削減できた時間 × 時給 例 開発者 10人 × 月4時間 = 月40時間 = 月 10万円 返済 48万円 ÷ 月10万円 = 約5ヶ月 一度削った時間は、翌月以降もゼロ円で効き続ける 浮いた時間が、次の改善の原資になる = 複利 撤退ライン:半年で返済の目処が立たなければ、分科会側から止める 11
「この領域は、分科会の決定に従う」 組織のルールとして置いた(お願いではなく) 他チームへの事前相談を必要としない範囲を決めた 反対は分科会に持ち込む。止めるのではなく議論の場所を1つにする 遠慮が消えると、手が動く 12
委譲と放置を分けるのは「最初の一歩」 誰がやるか 課題のブレイクダウン 一緒にやる 解決策のブレスト 一緒にやる コスパ試算(どこから手を付けるか) 一緒に確認する 最終決定 チームが決める 立ち上がりだけフォローを厚くして、決定は渡したまま動かさない 13
最初に出した What から、ズレてもいい 成果に繋がるなら やることを変えていい 最終的な意思決定は、チームのもの 14
で、返せたのか 目標 半年で投資額を回収 = 回収率 100% 実績 半年後の時点で = 回収率 70% 金額ではなく率で見ると、人件費の実額を出さずに話せる 比率なら、規模の違う組織でもそのまま持ち帰れる 撤退ラインを先に引いてあったから、この数字を堂々と見せられる 15
自分たちで「やらない」を決めた 進めていたアプローチを、分科会自身が筋が悪いと判断して切り捨て た 他チームとの調整は、リーダーが防波堤として引き受けた チームは意思決定に集中できた 自走するチームになった 16
枠組みと名前は、横断課題一般に効く 技術負債の解消 / CI・CD の改善 / ドキュメント整備 セキュリティ対応 / 採用・オンボーディング強化 どれも「重要だが、誰の担当でもない」という同じ形をしている 17
まとめ 1. 名前をつけて、枠組みを用意する — Why を自分の言葉で語る 2. ROI と撤退ラインで、事業部を説得し、チームを守る 3. 強い権限を渡し、最初だけ伴走し、最後は決めさせる 18
名前のない仕事に、 名前をつける 枠組みというお結びで、チームを磨き上げる ありがとうございました — こうの(@hk_it7)