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

by ShoheiMitani

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

自己紹介みたにしょうへい三谷昌平 @shohei1913 2020年スマートバンク入社 2024年 Engineering Mananager 2025年サーバーサイド部部長 5人目社員として入社決済 / 入金 / eKYC等のシステム開発を担当 2018年 Fablic入社 → 楽天吸収合併 2014年クオリカ入社ブーススタッフもやってます！

Slide 3

Slide 3 text

Slide 4

Slide 4 text

人が増えたのに全然楽にならない今日の発表

Slide 5

Slide 5 text

人が増えたのにむしろつらみが増えた？今日の発表

Slide 6

Slide 6 text

人が増えてもうまく回り続ける組織を作るには？今日の発表

Slide 7

Slide 7 text

● 2024年まで短期解散のPJチーム中心 ● 案件に合わせてチームを組み直す ● PMFを優先して柔軟なチーム体制 2024年にMission Team制度を導入何が起きたか？プロジェクト A プロジェクト B プロジェクト C プロジェクト D プロジェクト E

Slide 8

Slide 8 text

2024年にMission Team制度を導入何が起きたか？ ● 2024年から長期固定されたチームへ ● チームのナレッジを醸成する ● リリース後も改善責任を中長期で担う PJ A PJ B PJ C サーバーサイドエンジニアモバイルエンジニア他職種 PJ A PJ B PJ C サーバーサイドエンジニアモバイルエンジニア他職種 PJ A PJ B PJ C サーバーサイドエンジニアモバイルエンジニア他職種

Slide 9

Slide 9 text

採用も強化し、人数も増えた何が起きたか？ ● PM/デザイナー/エンジニア ● エンジニアは1.5倍くらいの人数に

Slide 10

Slide 10 text

Mission Team制度により多くの機能をリリース

Slide 11

Slide 11 text

Mission Team制度により多くの機能をリリース

Slide 12

Slide 12 text

Mission Team制度により多くの機能をリリース

Slide 13

Slide 13 text

Mission Team制度により多くの機能をリリース

Slide 14

Slide 14 text

Mission Team制度により多くの機能をリリース

Slide 15

Slide 15 text

No content

Slide 16

Slide 16 text

No content

Slide 17

Slide 17 text

Mission Team制度により多くの機能をリリース

Slide 18

Slide 18 text

● 「カードの決済管理アプリ」から「家計簿アプリ」へと進化 ● 事業の収益性を高めるための施策を複数連動してリリース Missionを達成するためにストーリー性のある機能開発が加速

Slide 19

Slide 19 text

一方その裏で ... 組織課題も顕在化 ...

Slide 20

Slide 20 text

● Mission Teamは事業として重要な施策への選択と集中 ● Missionには位置付けられないが、重要な課題もある ○ 3年以上開発してきた既存機能の保守運用 ○ サービスのスケールに伴うシステム全体の負荷対応 Mission Teamに当てはまらない課題の対応組織課題

Slide 21

Slide 21 text

マトリクス組織の横の仕組みで解決を試みてきた組織課題

Slide 22

Slide 22 text

● 部の週次定例にて横断課題のタスクを管理 ○ 起票されたものを全員で確認 ○ ローテーションでアサイン ● パフォーマンス監視MTGにてシステム状況を監視 ○ 緊急性が高いものは↑のタスクに載せる ● 障害発生時は気づいた人が対処する部での解決の仕組み組織課題

Slide 23

Slide 23 text

● 運用の「仕組み」不全 ● 保守運用課題の優先順位問題 ● 全員野球の限界 1年ほど続ける中で限界が見えてきた組織課題

Slide 24

Slide 24 text

● ルールの周知漏れで作業品質がばらける ○ 新しいメンバーがルールを知らない / 障害発生時の連絡先が漏れる ● オーナーが不明確なことで障害対応が遅れる ○ 「あの人が反応してるから大丈夫」と関与が弱まる ● 前は問題なかった作業で障害が起きる ○ 配信バッチ / 管理画面での操作でDB負荷が高まり、障害につながる運用の「仕組み」不全組織課題

Slide 25

Slide 25 text

● MT開発と保守運用の配分を8:2くらいと決めるが判断が困難 ● 重要だけど緊急ではない横断タスクが後回し ○ 気づかないうちに障害点として影響が広くなる ○ ある日障害/事故で急に優先度が高まる ● 善意や自主性に任せすぎることのマネジメント上のリスク保守運用課題の優先順位問題組織課題

Slide 26

Slide 26 text

● パフォーマンスMTGや部定例MTGへの参加者が増え続ける ○ 人が多く発言機会も少なくなる ○ ただ聞いているだけで1時間が過ぎていく ● 人が多くなればなるほど意思決定の質とスピードが落ちる全員野球の限界組織課題

Slide 27

Slide 27 text

チグハグな人員配置組織課題昔からの慣習で... ここ全部私...?? 忙しいので....

Slide 28

Slide 28 text

人を増やしたのは Mission Teamのため組織課題ここの速度を上げるための採用

Slide 29

Slide 29 text

人を増やしたのは Mission Teamのため組織課題横で見た時の人数も増えている

Slide 30

Slide 30 text

● 昔は少人数が最低限のルールで「よしなにやる」で回してた ● 暗黙知や主体性頼りの組織の限界が見え始めた ● このままの状態で次の1年を乗り越えることができるのか...!?? 人が増えたことに横串の組織戦略が追いついていない組織マネジメントの必要性

Slide 31

Slide 31 text

人数増を“味方”につける効果的で効率性のある保守運用の仕組み化目指したい組織の姿

Slide 32

Slide 32 text

1. 本当に重要な課題を見極めて、先手を打って解決したい 2. 任せられるところは任せて、自分がやるべきことに集中したい 3. 問題に追われるのをやめて、楽しくエンジニアリングしたい３つの "したい" 目指したい組織の姿

Slide 33

Slide 33 text

委員会制度の設立新しく始めたこと

Slide 34

Slide 34 text

● 事業成長を妨げる重要課題に取り組む少人数チーム = 委員会 ● 委員会はその課題解決のための実行と結果の責任を負う ● 何の課題をどう解決していくのか決める権限も持つ ● 委員会は必ず1名の “委員長” を任命し、やり切る責任を負う委員会制度は横断課題を戦略的に解決するための仕組み

Slide 35

Slide 35 text

部の横串で委員会のメンバーを構成する委員会のイメージ図

Slide 36

Slide 36 text

● 横断課題の “器”を作る ○ Mission Teamの狭間の課題を継続的に拾い、重要課題を詰まらせない ● 権限委譲と解決スピード ○ 責任と権限をセットで委譲し、意思決定のスピードを上げる ● 人材育成 ○ 横断課題を通じてスキルアップし、組織の問題解決力を底上げする委員会のコンセプト

Slide 37

Slide 37 text

● EM陣で集まって徹底的に議論 ○ 部の問題は何か？ ○ 将来の成長を妨げるものは何か？ ● 洗い出した課題に優先度をつけて集約 EM陣で議論し部の最重要課題を抽出コンセプト① 横断課題の“器”を作る

Slide 38

Slide 38 text

● SLOの設定と監視 / CIの高速化サービスの品質の維持・向上 ● AIを活用するための環境整備将来必要となる技術領域への投資 ● ブログ / 登壇 / スポンサー技術発信と採用力強化 ● 手順書の整備 / アサイン保守運用業務の負担軽減 4つの課題領域を設定コンセプト① 横断課題の“器”を作る

Slide 39

Slide 39 text

4つの課題領域の関連性と設置した委員会コンセプト① 横断課題の“器”を作る Mission Team 新機能開発品質委員会チーム連携最大化委員会投資委員会広報委員会機能開発でサービスが複雑になるサービスの品質の維持・向上保守運用業務の負担軽減生産性向上採用

Slide 40

Slide 40 text

● 変化が激しい会社の状況に合わせやすくする ● 将来を考え過ぎず、"今" 最重要な課題にフォーカスする ● メンバーも半年単位でやりたいことも変えれるように委員会の活動サイクルは半年コンセプト① 横断課題の“器”を作る

Slide 41

Slide 41 text

上期の委員会と下期の委員会コンセプト① 横断課題の“器”を作る品質委員会チーム連携最大化委員会投資委員会広報委員会パフォ活委員会 DevEx委員会 Ops委員会データ活用委員会広報委員会

Slide 42

Slide 42 text

● RACIチャートにて整理委員長に権限をしっかりと渡しリーダーシップを発揮してもらうコンセプト② 権限委譲と解決スピード RACI 担当 Responsible（実行責任者）委員会に所属する委員 Accountable（説明責任者）委員長 Consulted（相談先）サーバーサイド部全員 Informed（報告先）部長

Slide 43

Slide 43 text

● 委員会の役割は抽象度高く設定されている ○ 期中に発生する様々な課題を柔軟に解決できるように ● 5W1Hは全て自分たちが決めることができる ○ 部長からのオーダーもあるが取り入れるかは委員会が決める ● 代わりに業務調整も委員会メンバーが行う自分たちの興味・好奇心が持てる課題を設定するコンセプト② 権限委譲と解決スピード

Slide 44

Slide 44 text

● 組織が事業が大きくなるほど、EMが全てを把握することは不可能 ● 問題に近い人の方が解像度が高く、適切な意思決定がしやすい ● EMが決めるのではなく、抽象的な課題毎にオーナーを設置する分権型 ~なぜ抽象度高く問題設定をするのか？ ~ コンセプト② 権限委譲と解決スピード

Slide 45

Slide 45 text

● 委員長の意思決定は、部全体に影響を及ぼす ○ 障害によるサービスの被害 ○ 半年後の会社の生産性 ● 意思決定するには様々な調整毎も必要 ○ 委員会のメンバーの時間、工数 ● 意思決定を下し、その結果を見ることが、次の学びになる意思決定の機会を増やすことで、成長する場を提供するコンセプト③ 人材育成

Slide 46

Slide 46 text

● Mission Team内では普段触らない技術やシステムに触れる場 ● 普段働かない人と委員会で一緒になることで交流機会も増える Mission Teamの垣根を超えて、エンジニア間での交流を促すコンセプト③ 人材育成

Slide 47

Slide 47 text

他社事例

Slide 48

Slide 48 text

Spotify 他社事例 "ギルドとは、より有機的で広範な関心のあるコミュニティで、知識、ツール、コード、実践を共有したい人たちの集まりだ。Javaギルド、C++ギルド、Androidギルドのような仕事に関連したギルドがある。（中略）また、興味があれば誰でもどのギルドにも参加することができる。" 引用: https://r3s.jp/magazine/jp/spotify-1?utm_source=chatgpt.com

Slide 49

Slide 49 text

ピクシブ株式会社他社事例 "社内に多数の事業を擁するピクシブにおいて、エンジニアは日々個々の担当する事業価値を高めることに注力しています。そんななかでも、採用・評価・育成といった、事業単位ではなく会社単位で考えていくべき領域に関して、事業部横断で思想を共有・改善していくための仕組みが「エンジニアギルド」です。" 引用: https://inside.pixiv.blog/bash/7480

Slide 50

Slide 50 text

● メルカリ / Nstock / ユーザベース / ギフティ / etc... ● 運営スタイルには各社違いがある ○ 自由に設立・参加できるかどうか ○ レポートラインが整備されているかどうか ● スマートバンクは委員会とメンバーをトップダウンで決定委員会 / ギルドなどの名前で一般的に取り入れられているプラクティス他社事例

Slide 51

Slide 51 text

委員会が生み出した成果

Slide 52

Slide 52 text

● 長らくDBはPrimary 1つで運用 ● Primaryへの負荷で障害に... ● スロークエリの改善 ● リードレプリカの導入を決定 ○ 170以上のAPIの対応を完了 DB負荷による障害の根本対応委員会が生み出した成果

Slide 53

Slide 53 text

● 長時間化バッチの増加 ● 24Hを超えるバッチも出始める ● 危険水準を超えるバッチの検出 ● 計画的に対応を進められるやばいよやばいよメトリクス委員会が生み出した成果

Slide 54

Slide 54 text

● 保守運用業務の手順書 ● 実施日と作業内容・時間を蓄積する ● 次回対応や自動化のインプットに Runbook 委員会が生み出した成果

Slide 55

Slide 55 text

● 10分以上かかるCIの改善 ○ テストの分割や最適化も実施 ● Self Hosted Runner用のPCを購入 ● CI実行時間は半分 ● GHAの運用費も1/3に削減 Github Self Hosted RunnerによるCI高速化委員会が生み出した成果

Slide 56

Slide 56 text

● AIサービス利用ガイドラインの整備 ● 開発者向けのAIツール予算の策定 ● Devinの活用浸透 AI活用推進委員会が生み出した成果

Slide 57

Slide 57 text

● 社内向けのデータ分析AIアシスタント ● AI Agentがクエリを作成して実行 ● 社内の75%以上が活用 Ask ーデータ分析 Agent 委員会が生み出した成果

Slide 58

Slide 58 text

● 25年は46のイベントで登壇 ● 6つのイベントでスポンサー ● 新春エンジニア駅伝ブログ登壇支援、ブログ発信委員会が生み出した成果

Slide 59

Slide 59 text

委員会制度をうまく回すために工夫したこと

Slide 60

Slide 60 text

● 全社定例で委員会の実績を積極的にアピール ● 部の課題を共有することで、活動意義や重要性を知ってもらう ● 解決が進捗していることを示し、信頼してもらう社内で活動をアピールし仲間を増やす活動しやすい環境づくり

Slide 61

Slide 61 text

● 委員会の活動の重要性を明確に示し仲間になってもらう ● 相手目線でメリットがあることをしっかり伝える ○ 「デプロイが定期的に失敗する」→「Mission Teamの施策が出したいときに出せない状況を解決してる」 ○ 「AIのガイドラインを作っている」→「AI活用を推進することでMission Teamの開発スピードが早くなる」 Mission Teamのリーダーは MTを優先してほしい活動しやすい環境づくり

Slide 62

Slide 62 text

● 若手にも委員長のポストを積極的に抜擢 ○ Mission Teamでは役割が固定されていることも多い ○ 様々なポジションを経験する機会を増やしたい ● シニアエンジニアをまとめたり、様々な意思決定が求められるなど絶好の成長の機会グレードや年次に関係なく委員長に抜擢する次世代リーダーの育成方法

Slide 63

Slide 63 text

● AI活用やインフラ、イベント参加が伴うものにはお金がかかる ● エンジニアはお金の使い方が下手苦手な人が多い ○ 使える金額感がクローズドだと新しい取り組みに消極的になる ○ ちょっと待ってね...と言われるだけでも、遠慮してしまう ● お金の相談をされたときに嫌な顔をしない。むしろ背中を押す予算マネジメントを徹底し、何にいくら使えるかを正確に把握する意思決定スピードの向上

Slide 64

Slide 64 text

● 去年のサブイベントでの発表 ○ くんさんの発表 ○ 予実管理の重要性を学んだ ● 予実管理のやり方がいいなと思って、真似して取り入れたエンジニアリング 💰Moneyジャー予算マネジメント

Slide 65

Slide 65 text

● 毎月実績状況を更新 ● 不要なもの足りないものを確認 ● 定期的に経営陣と交渉し予算見直し ● 聞かれればすぐ答えれる状態に予算のトラッキング用シートを作成予算マネジメント

Slide 66

Slide 66 text

● 新しい技術を試したい人の背中を押す ○ Self Hosted Runner ○ Cloudflare ○ AI Agent ● 「いいじゃん」「面白そう」「やってみようよ」委員会の活動が個人のスキルやキャリアを伸ばすことに繋がって欲しい続けて楽しい環境を作る

Slide 67

Slide 67 text

EMとしての学び

Slide 68

Slide 68 text

● 課題解決を自主性の高さに任せすぎない ○ 視座や視点、オーナシップがめっちゃ高いスーパーマンもいる ○ 一方、「やりたいけどやっていいのか分からない」と待ってる人もいる ○ 自主的にやりたいこと = 組織が必要としていることばかりではない ● 全員の力を合わせるには強制力という "仕掛け"が絶対に必要 ○ 責任を持ってもらいつつ、クリエイティビティが発揮されるような環境を作ることが大事委員会という "強制的な遊び場 " から多くのものが生まれた EMとしての学び

Slide 69

Slide 69 text

● どの課題領域でも信頼して任せられるメンバーがいる幸せ ○ 任せることでその人のスキルや性格の理解度も上がる ● 任せずにマネージャーだけで抱えていたと思うとゾッとする ○ 多くても1/5くらいしか解決できなかったと思う任せられるというのは幸せなこと EMとしての学び

Slide 70

Slide 70 text

● 委員会は銀の弾丸ではない ● Mission Teamの佳境タイミングでは動きが遅くなる ○ 他のメンバーによるサポートで対応したり ○ Mission Teamのリリーススケジュールに合わせた計画が求められる ● 委員長には変数が多いProject Managementが求められる ● 課題によっては委員会とば別の常設組織を作る方が良い MTと委員会のタスク調整は引き続き難しさがある EMとしての学び

Slide 71

Slide 71 text

終わりに

Slide 72

Slide 72 text

● 人や組織がうまく回っていないところを見つけて、治水工事のように流れを整えていくところは楽しい ● 隣でみんなが楽しく開発しているのを見ると嬉しいですね EMのやりがい

Slide 73

Slide 73 text

ご清聴ありがとうございました