スーパーマンに頼らない"分権型組織"で作る強い開発チーム

EMConf JP 2026
https://fortee.jp/emconf-2026/proposal/d0d2f29d-32e3-4137-9b3b-72d08cbbe5c3

Transcript

1. スーパーマンに頼らない 分権型組織で作る強い開発チーム EMConfJP 2026
2. 自己紹介 み た に し ょ う へ い 三谷 昌平 @shohei1913 2020年 スマートバンク入社 2024年 Engineering Mananager 2025年 サーバーサイド部 部長 5人目社員として入社 決済 / 入金 / eKYC等のシステム開発を担当 2018年 Fablic入社 → 楽天吸収合併 2014年 クオリカ入社 ブーススタッフもやってます！
4. 人が増えたのに 全然楽にならない 今日の発表
5. 人が増えたのに むしろつらみが増えた？ 今日の発表
6. 人が増えても うまく回り続ける組織を 作るには？ 今日の発表
7. • 2024年まで短期解散のPJチーム中心 • 案件に合わせてチームを組み直す • PMFを優先して柔軟なチーム体制 2024年にMission Team制度を導入 何が起きたか？ プロジェクト A プロジェクト B プロジェクト C プロジェクト D プロジェクト E
8. 2024年にMission Team制度を導入 何が起きたか？ • 2024年から長期固定されたチームへ • チームのナレッジを醸成する • リリース後も改善責任を中長期で担う PJ A PJ B PJ C サーバーサイド エンジニア モバイル エンジニア 他職種 PJ A PJ B PJ C サーバーサイド エンジニア モバイル エンジニア 他職種 PJ A PJ B PJ C サーバーサイド エンジニア モバイル エンジニア 他職種
9. 採用も強化し、人数も増えた 何が起きたか？ • PM/デザイナー/エンジニア • エンジニアは1.5倍くらいの人数に
10. Mission Team制度により 多くの機能をリリース
11. Mission Team制度により多くの機能をリリース
12. Mission Team制度により多くの機能をリリース
13. Mission Team制度により多くの機能をリリース
14. Mission Team制度により多くの機能をリリース
17. Mission Team制度により多くの機能をリリース
18. • 「カードの決済管理アプリ」から「家計簿アプリ」へと進化 • 事業の収益性を高めるための施策を複数連動してリリース Missionを達成するためにストーリー性のある機能開発が加速
19. 一方その裏で ... 組織課題も顕在化 ...
20. • Mission Teamは事業として重要な施策への選択と集中 • Missionには位置付けられないが、重要な課題もある ◦ 3年以上開発してきた既存機能の保守運用 ◦ サービスのスケールに伴うシステム全体の負荷対応 Mission Teamに当てはまらない課題の対応 組織課題
21. マトリクス組織の横の仕組みで解決を試みてきた 組織課題
22. • 部の週次定例にて横断課題のタスクを管理 ◦ 起票されたものを全員で確認 ◦ ローテーションでアサイン • パフォーマンス監視MTGにてシステム状況を監視 ◦ 緊急性が高いものは↑のタスクに載せる • 障害発生時は気づいた人が対処する 部での解決の仕組み 組織課題
23. • 運用の「仕組み」不全 • 保守運用課題の優先順位問題 • 全員野球の限界 1年ほど続ける中で限界が見えてきた 組織課題
24. • ルールの周知漏れで作業品質がばらける ◦ 新しいメンバーがルールを知らない / 障害発生時の連絡先が漏れる • オーナーが不明確なことで障害対応が遅れる ◦ 「あの人が反応してるから大丈夫」と関与が弱まる • 前は問題なかった作業で障害が起きる ◦ 配信バッチ / 管理画面での操作でDB負荷が高まり、障害につながる 運用の「仕組み」不全 組織課題
25. • MT開発と保守運用の配分を8:2くらいと決めるが判断が困難 • 重要だけど緊急ではない横断タスクが後回し ◦ 気づかないうちに障害点として影響が広くなる ◦ ある日障害/事故で急に優先度が高まる • 善意や自主性に任せすぎることのマネジメント上のリスク 保守運用課題の優先順位問題 組織課題
26. • パフォーマンスMTGや部定例MTGへの参加者が増え続ける ◦ 人が多く発言機会も少なくなる ◦ ただ聞いているだけで1時間が過ぎていく • 人が多くなればなるほど意思決定の質とスピードが落ちる 全員野球の限界 組織課題
27. チグハグな人員配置 組織課題 昔からの慣習で... ここ全部私...?? 忙しいので....
28. 人を増やしたのは Mission Teamのため 組織課題 ここの速度を上げるための採 用
29. 人を増やしたのは Mission Teamのため 組織課題 横で見た時の人数も 増えている
30. • 昔は少人数が最低限のルールで「よしなにやる」で回してた • 暗黙知や主体性頼りの組織の限界が見え始めた • このままの状態で次の1年を乗り越えることができるのか...!?? 人が増えたことに横串の組織戦略が追いついていない 組織マネジメントの必要性
31. 人数増を“味方”につける 効果的で効率性のある 保守運用の仕組み化 目指したい組織の姿
32. 1. 本当に重要な課題を見極めて、先手を打って解決したい 2. 任せられるところは任せて、自分がやるべきことに集中したい 3. 問題に追われるのをやめて、楽しくエンジニアリングしたい ３つの "したい" 目指したい組織の姿
33. 委員会制度の設立 新しく始めたこと
34. • 事業成長を妨げる重要課題に取り組む少人数チーム = 委員会 • 委員会はその課題解決のための実行と結果の責任を負う • 何の課題をどう解決していくのか決める権限も持つ • 委員会は必ず1名の “委員長” を任命し、やり切る責任を負う 委員会制度は横断課題を戦略的に解決するための仕組み
35. 部の横串で委員会のメンバーを構成する 委員会のイメージ図
36. • 横断課題の “器”を作る ◦ Mission Teamの狭間の課題を継続的に拾い、重要課題を詰まらせない • 権限委譲と解決スピード ◦ 責任と権限をセットで委譲し、意思決定のスピードを上げる • 人材育成 ◦ 横断課題を通じてスキルアップし、組織の問題解決力を底上げする 委員会のコンセプト
37. • EM陣で集まって徹底的に議論 ◦ 部の問題は何か？ ◦ 将来の成長を妨げるものは何か？ • 洗い出した課題に優先度をつけて集約 EM陣で議論し部の最重要課題を抽出 コンセプト① 横断課題の“器”を作る
38. • SLOの設定と監視 / CIの高速化 サービスの品質の維持・向上 • AIを活用するための環境整備 将来必要となる技術領域への投資 • ブログ / 登壇 / スポンサー 技術発信と採用力強化 • 手順書の整備 / アサイン 保守運用業務の負担軽減 4つの課題領域を設定 コンセプト① 横断課題の“器”を作る
39. 4つの課題領域の関連性と設置した委員会 コンセプト① 横断課題の“器”を作る Mission Team 新機能開発 品質委員会 チーム連携 最大化委員会 投資委員会 広報委員会 機能開発でサービスが複雑になる サービスの品質の維持・向上 保守運用業務の負担軽減 生産性向上 採用
40. • 変化が激しい会社の状況に合わせやすくする • 将来を考え過ぎず、"今" 最重要な課題 にフォーカスする • メンバーも半年単位でやりたいことも変えれるように 委員会の活動サイクルは半年 コンセプト① 横断課題の“器”を作る
41. 上期の委員会と下期の委員会 コンセプト① 横断課題の“器”を作る 品質委員会 チーム連携最大化委員会 投資委員会 広報委員会 パフォ活委員会 DevEx委員会 Ops委員会 データ活用委員会 広報委員会
42. • RACIチャートにて整理 委員長に権限をしっかりと渡しリーダーシップを発揮してもらう コンセプト② 権限委譲と解決スピード RACI 担当 Responsible（実行責任者） 委員会に所属する委員 Accountable（説明責任者） 委員長 Consulted（相談先） サーバーサイド部全員 Informed（報告先） 部長
43. • 委員会の役割は抽象度高く設定されている ◦ 期中に発生する様々な課題を柔軟に解決できるように • 5W1Hは全て自分たちが決めることができる ◦ 部長からのオーダーもあるが取り入れるかは委員会が決める • 代わりに業務調整も委員会メンバーが行う 自分たちの興味・好奇心が持てる課題を設定する コンセプト② 権限委譲と解決スピード
44. • 組織が事業が大きくなるほど、EMが全てを把握することは不可能 • 問題に近い人の方が解像度が高く、適切な意思決定がしやすい • EMが決めるのではなく、抽象的な課題毎にオーナーを設置する 分権型 ~なぜ抽象度高く問題設定をするのか？ ~ コンセプト② 権限委譲と解決スピード
45. • 委員長の意思決定は、部全体に影響を及ぼす ◦ 障害によるサービスの被害 ◦ 半年後の会社の生産性 • 意思決定するには様々な調整毎も必要 ◦ 委員会のメンバーの時間、工数 • 意思決定を下し、その結果を見ることが、次の学びになる 意思決定の機会を増やすことで、成長する場を提供する コンセプト③ 人材育成
46. • Mission Team内では普段触らない技術やシステムに触れる場 • 普段働かない人と委員会で一緒になることで交流機会も増える Mission Teamの垣根を超えて、エンジニア間での交流を促す コンセプト③ 人材育成
47. 他社事例
48. Spotify 他社事例 "ギルドとは、より有機的で広範な関心のあるコミュ ニティで、知識、ツール、コード、実践を共有したい人 たちの集まりだ。Javaギルド、C++ギルド、Androidギ ルドのような仕事に関連したギルドがある。（中略）ま た、興味があれば誰でもどのギルドにも参加するこ とができる 。" 引用: https://r3s.jp/magazine/jp/spotify-1?utm_source=chatgpt.com
49. ピクシブ株式会社 他社事例 "社内に多数の事業を擁するピクシブにおいて、エン ジニアは日々個々の担当する事業価値を高めること に注力しています。そんななかでも、採用・評価・育 成といった、事業単位ではなく会社単位で考えてい くべき領域に関して、事業部横断で思想を共有・改 善していくための仕組みが「エンジニアギルド」で す。" 引用: https://inside.pixiv.blog/bash/7480
50. • メルカリ / Nstock / ユーザベース / ギフティ / etc... • 運営スタイルには各社違いがある ◦ 自由に設立・参加できるかどうか ◦ レポートラインが整備されているかどうか • スマートバンクは委員会とメンバーをトップダウンで決定 委員会 / ギルドなどの名前で一般的に取り入れられているプラクティス 他社事例
51. 委員会が生み出した成果
52. • 長らくDBはPrimary 1つで運用 • Primaryへの負荷で障害に... • スロークエリの改善 • リードレプリカの導入を決定 ◦ 170以上のAPIの対応を完了 DB負荷による障害の根本対応 委員会が生み出した成果
53. • 長時間化バッチの増加 • 24Hを超えるバッチも出始める • 危険水準を超えるバッチの検出 • 計画的に対応を進められる やばいよやばいよメトリクス 委員会が生み出した成果
54. • 保守運用業務の手順書 • 実施日と作業内容・時間を蓄積する • 次回対応や自動化のインプットに Runbook 委員会が生み出した成果
55. • 10分以上かかるCIの改善 ◦ テストの分割や最適化も実施 • Self Hosted Runner用のPCを購入 • CI実行時間は半分 • GHAの運用費も1/3に削減 Github Self Hosted RunnerによるCI高速化 委員会が生み出した成果
56. • AIサービス利用ガイドラインの整備 • 開発者向けのAIツール予算の策定 • Devinの活用浸透 AI活用推進 委員会が生み出した成果
57. • 社内向けのデータ分析AIアシスタント • AI Agentがクエリを作成して実行 • 社内の75%以上が活用 Ask ー データ分析 Agent 委員会が生み出した成果
58. • 25年は46のイベントで登壇 • 6つのイベントでスポンサー • 新春エンジニア駅伝ブログ 登壇支援、ブログ発信 委員会が生み出した成果
59. 委員会制度をうまく回すために 工夫したこと
60. • 全社定例で委員会の実績を積極的にアピール • 部の課題を共有することで、活動意義や重要性を知ってもらう • 解決が進捗していることを示し、信頼してもらう 社内で活動をアピールし仲間を増やす 活動しやすい環境づくり
61. • 委員会の活動の重要性を明確に示し仲間になってもらう • 相手目線でメリットがあることをしっかり伝える ◦ 「デプロイが定期的に失敗する」→「Mission Teamの施策が出したいときに出 せない状況を解決してる」 ◦ 「AIのガイドラインを作っている」→「AI活用を推進することでMission Teamの 開発スピードが早くなる」 Mission Teamのリーダーは MTを優先してほしい 活動しやすい環境づくり
62. • 若手にも委員長のポストを積極的に抜擢 ◦ Mission Teamでは役割が固定されていることも多い ◦ 様々なポジションを経験する機会を増やしたい • シニアエンジニアをまとめたり、様々な意思決定が求められるなど 絶好の成長の機会 グレードや年次に関係なく委員長に抜擢する 次世代リーダーの育成方法
63. • AI活用やインフラ、イベント参加が伴うものにはお金がかかる • エンジニアはお金の使い方が 下手 苦手な人が多い ◦ 使える金額感がクローズドだと新しい取り組みに消極的になる ◦ ちょっと待ってね...と言われるだけでも、遠慮してしまう • お金の相談をされたときに嫌な顔をしない。むしろ背中を押す 予算マネジメントを徹底し、何にいくら使えるかを正確に把握する 意思決定スピードの向上
64. • 去年のサブイベントでの発表 ◦ くんさんの発表 ◦ 予実管理の重要性を学んだ • 予実管理のやり方がいいなと思って、真 似して取り入れた エンジニアリング 💰Moneyジャー 予算マネジメント
65. • 毎月実績状況を更新 • 不要なもの足りないものを確認 • 定期的に経営陣と交渉し予算見直し • 聞かれればすぐ答えれる状態に 予算のトラッキング用シートを作成 予算マネジメント
66. • 新しい技術を試したい人の背中を押す ◦ Self Hosted Runner ◦ Cloudflare ◦ AI Agent • 「いいじゃん」「面白そう」「やってみようよ」 委員会の活動が個人のスキルやキャリアを伸ばすことに繋がって欲しい 続けて楽しい環境を作る
67. EMとしての学び
68. • 課題解決を自主性の高さに任せすぎない ◦ 視座や視点、オーナシップがめっちゃ高いスーパーマンもいる ◦ 一方、「やりたいけどやっていいのか分からない」と待ってる人もいる ◦ 自主的にやりたいこと = 組織が必要としていることばかりではない • 全員の力を合わせるには強制力という "仕掛け"が絶対に必要 ◦ 責任を持ってもらいつつ、クリエイティビティが発揮されるような環境を作ること が大事 委員会という "強制的な遊び場 " から多くのものが生まれた EMとしての学び
69. • どの課題領域でも信頼して任せられるメンバーがいる幸せ ◦ 任せることでその人のスキルや性格の理解度も上がる • 任せずにマネージャーだけで抱えていたと思うとゾッとする ◦ 多くても1/5くらいしか解決できなかったと思う 任せられるというのは幸せなこと EMとしての学び
70. • 委員会は銀の弾丸ではない • Mission Teamの佳境タイミングでは動きが遅くなる ◦ 他のメンバーによるサポートで対応したり ◦ Mission Teamのリリーススケジュールに合わせた計画が求められる • 委員長には変数が多いProject Managementが求められる • 課題によっては委員会とば別の常設組織を作る方が良い MTと委員会のタスク調整は引き続き難しさがある EMとしての学び
71. 終わりに
72. • 人や組織がうまく回っていないところを見つけて、治水工事のように 流れを整えていくところは楽しい • 隣でみんなが楽しく開発しているのを見ると嬉しいですね EMのやりがい
73. ご清聴ありがとうございました