なぜチームを増やしても開発は速くならないのか？ ― LeSS × SPACE × AIで見えた、生産性を阻害する構造と打破した壁

開発が停滞していた組織において、最大のボトルネックは個人のスキルやツールではなく、「チーム間の壁（サイロ化）」にありました。
本セッションでは、LeSS 導入によって組織構造に手を入れ、チーム間の分断を解消していく過程と、その中で生まれた変化を紹介します。
一方で、変化を感じつつも、チーム内で目標や認識を揃え、組織として説明することの難しさにも直面しました。そこで SPACE フレームワークを用いて開発生産性を可視化したことで、対話・学習・改善がどこで滞っていたのかが明確になっていきました。
また、構造改善を前提として初めて効果を発揮し始めた AI 活用の実例も共有します。
組織・プロセス・AIをどう組み合わせれば、開発生産性を持続的に高められるのか、その再現可能なヒントをお伝えします。

Transcript

1. なぜチームを増やしても 開発は速くならないのか？ 2026.02.19 LeSS × SPACE × AIで見えた、生産性を阻害する構造と打破した壁
2. 自己紹介 古賀 みゆき 株式会社デジタルガレージ DG Technology本部 • 新卒入社以来、フルスタックとしてWebアプリケーション開発 • 2025年 DG参画（フリーランス→正社員） • 現在のミッション： ◦ プロダクト開発の推進（品質・速度・持続性） ◦ 開発プロセス改善（スクラム運用・可視化・継続的改善） • 価値観：心理的安全性を基盤に、アジャイルとAIで成果を最大化 • 一児の母 • 猫が好き 2
3. デジタルガレージ：会社概要 設立 1995年8月17日 創業者 林 郁 代表取締役 兼 社長執行役員グループCEO 伊藤 穰一 取締役 兼 専務執行役員 Chief Architect 所在地 東京都渋谷区（本社） 米国カリフォルニア州サンフランシスコ (米国子会社) 上場市場 東京証券取引所 プライム市場［証券コード4819］ 従業員数 1,321人 ※25年3月時点 デジタルガレージ：会社概要 3
4. デジタルガレージ：事業内容 国内最大級の決済事業やマーケティング事業などの基盤事業群、新規事業開発、スタートアップ投資事業を展開 4
5. やりたいことが多すぎて開発が追いつかない 状況打開のために増員を決定。 しかし、現実に起きたのは加速ではなく「疲弊」でした。 5
6. 背景：当時のチーム構成と役割 Aチーム（既存） •成熟した既存チーム •ウォーターフォール開発 •Bチーム成果物のレビュー・フォローを担当 Bチーム（新設） •ジュニア中心の新設チーム •ウォーターフォール開発 •成果物はAチームレビュー前提 6
7. チーム規模拡大に伴う課題 人数が増えるほど指数関数的に調整が増え、実作業が 削られる 「人は増えたのにアウトプットが出ない」という不満 の蓄積 各メンバーの担当領域が細分化・局所化し、自分が開 発したものがどのような価値を生んでいるのかが見え ず、モチベーションが減衰 コミュニケーションコストの急増 期待値と実開発速度の乖離 個々人の貢献感の低下 7
8. アウトプットが生まれない構造 情報共有の断絶 チーム間でナレッジが流通せず 、同じミスや車輪の再発明を繰 り返す 設計・レビュー滞留 Aチームのシニア層にレビュー 負荷が集中。Bチームは待ち時 間で手が止まる 全体最適の欠如 「自分たちの担当分」を終わらせ ることに固執し、プロダクト全体 の価値を忘れる 8
9. 停滞を生む「統合」の巨大な壁 設計から実装までは各チームで進みますが、「統合」フ ェーズで巨大な手戻りが発生 数ヶ月にわたる遅延と、数えきれないほどの修正依頼。 「これが人を増やしても遅くなる」正体です。 見えない仕掛品の蓄積 設計/実装 設計/実装 統合 衝突 9
10. 影響可能な範囲からの改善 Bチームのスクラム化 Aチームはウォーターフォールを維持。私はBチー ムにジョインし、影響を与えられる範囲からスク ラムを導入 「痛み」の引き受け BチームがAチームのブランチへスプリントごとに デプロイ。コンフリクト対応などの面倒な作業をB チームが引き受けることで合意 10
11. 転換点：体験が生んだ意識の変化 「今のやり方（スクラム）が気に入った」 ビジネスの優先順位がBチーム案件に移り、Aチームのメンバー がBチームに合流。順調に進む開発を見て、Aチームのリーダー の評価が劇的に変化 レトロスペクティブでメンバーの本音が漏れ、全体スク ラム=LeSSの導入が決定した瞬間でした。 11
12. LeSS (Large-Scale Scrum) 1プロダクト、1バックログ、1PO。大規模でも「スクラムはスクラム」 12
13. LeSS の原理原則：組織のシンプル化 経験主義 透明性を確保し、観察事実に基 づいてプロセスを適応させる 顧客中心・全体最適 チーム間の利害ではなく、エンド ユーザーに届く価値で判断する Scrum is Scrum 役割やプロセスを増やさず、スク ラムの核心を大規模に適用する 13
14. LeSS 導入後：組織の劇的な変化 項目 Befor (サイロ化) After (LeSS) 優先順位 チームごとに異なる判断 1バックログで目的を統一 レビュー 特定シニアに負荷集中 チーム間協働が「日常」に 統合 フェーズ末期の巨大手戻り 常時統合・継続的学習 加速の要因 個人の頑張り 構造改善による自然な加速 14
15. LeSS 導入後：新たな課題 既存プロジェクトは“途中からの適用”になるため、立ち 上がりは計画通りに進みにくい 意思決定や支援の仕方がチームごとにブレて摩擦が生ま れる 都合の良い解釈で“部分適用”してしまい、「やっている つもり」で効果が出にくい 教科書通りには進まない実態 役割の捉え方にチーム差が残る 「分かったつもり」の形骸化 15
16. “強制しない”アプローチ 納得感を重視 プロセス遵守を目的化せず、現場 の違和感が熟すのを待つ 適切な介入 問題が顕在化したタイミングで振 り返りを促し、自発的変化を待つ 事実に基づいた対話 評価のためではなく、現象をその まま見るために数値を計測し、「 どこで流れが滞っているか」を探 索する 16
17. SPACE 「健全に価値を生み続ける」ための生産性フレームワーク 17
18. 多角的な事実観測：SPACEフレームワーク Satisfaction 幸福度・心理的安全性 Performance アウトカム・品質 Activity 活動の量（PR数） Communication 協調・レビューの質 Efficiency 流れの良さ・待ち時間 18
19. SPACE: Satisfaction & Well-Being 92 % 心理的安全性の定量的向上 特に「親しい知人や友人に、このチームで働くことを勧めたい。」が大幅に 改善。チーム間の競争が「共創」へと変化しました。 Before: 72% → After: 92% この安心感が、隠れた不具合の早期発見や積極的な改善提案に繋がっています。 Positive Response 19
20. SPACE: Performance & Efficiency リリース頻度 0.5回 2回 / 月 小刻みなリリースが可能になり、ビジネス要望 への即応性が向上 平均サイクルタイム 10日 2日 手戻りや待ち時間が減り、着手から完了までの 期間が大幅に短縮 20
21. SPACE: Communication & Collaboration 1人あたりの1日の会議時間 サーベイ 0.7 時間/日 削減 84 % 高評価 会議の目的を「共有」から「意思決定」に再定義 し、会議帯を見直し。会議時間を大幅に削減 情報共有の方法やドキュメントの見直しにより、 満足度が向上 21
22. AIの活用が加速 「何を良しとするか」の定義が揃ったことで、 AIは人間の混乱を増幅させる道具から、加速のエンジンへ変わった 22
23. AI活用事例：チケット作成 基準の統一 「1日で終わるサイズ」を基準化 暗黙知の明文化 良い分割例をルールにし、標準化 人の役割 AIが作ったチケットの要件と妥当性の確認に集中 AIがチケットを作成 Backlog MCPを使用して、チケット作成をAIに任せる 23
24. AI活用事例：コーディング 設計思想のズレを未然に防止 統一されたコーディングを実現 レビュー指摘が減少 両チームで合意した細かな規約をルール化し、 バイブコーディングに使用 24
25. AI活用事例：レビュー AIが担うレビュー（作業） • 規約・コーディングルールの遵守確認 • 明らかなバグ・抜け漏れの検知 • PRの要約・変更点の整理 人が担うレビュー（判断） • 要件との整合性の確認 • 設計妥当性の確認 • 変更価値・効果の確認 25
26. AI活用事例：テスト 結合テスト × AI • テスト観点を明文化し、品質を標準化 • 要件・ソースコードからテストケースを自動生成 • Markdown形式で出力 • テスト実行・結果確認までをAI上で完結 E2Eテスト × Playwright × AI • 自然言語でシナリオを指示 • Playwright用テストコードを自動生成 • ブラウザ操作・実行・結果取得を自動化 26
27. AI活用事例：知識共有と底上げ 人は意思決定に集中 AIに作業は任せ、人は本質的価 値の創出に直結する意思決定に フォーカスする 品質のボトムアップ ジュニアメンバーもAIの指摘か ら学び、スキルが向上 スキルの平準化 「チームによる品質差」が消え 、誰がどのコードを見ても理解 できる状態に 27
28. ビジネスとの協働改善 項目 Befor (サイロ化) After (LeSS) 優先順位 声の大きい順 1プロダクト全体での最適化 フィードバック 数ヶ月後のリリース時 2週間ごとのデモと対話 トレードオフ 不透明で疑心暗鬼 共通認識を持っての判断 28
29. ビジネス成果：加速のその先へ 問い合わせ件数の減少 問い合わせを分析し、開発チームから機能改善を 提案。その結果、問い合わせ件数を大幅に削減 価値創出の増加 「守り」から「攻め」へ。ビジネス拡大の要求 に即座に応えられる体制へと進化 29
30. 進化の軌跡 構造改革 サイロを打破し、LeSS で組織をシンプルに STEP 1 多面的評価 SPACEで健康状態を 正しく測る STEP 2 文化醸成 心理的安全性を高め、 全体最適を共通言語に STEP 3 技術加速 AIを規約遵守に活用し、 更なるブーストをかける STEP 4 30
31. 再現するためのヒント 開発は「人数」ではなく 「構造と流れ」 で速くなる 小さく始める 影響可能な範囲から改善 リスクを抑え、確実な成功体 験からスケール 流れを見る 待ち・滞留・手戻りを可視化 ボトルネックを特定し、リード タイムを最小化 納得で変える 問題が見えた瞬間に振り返る 鮮度の高い課題に対して、チ ーム全員で合意形成 構造を揃える 1プロダクト・1バックログ 優先順位の一元化により、 チームの迷いを排除 前提を定義する 規約・判断基準を揃えてAI活用 標準化されたプロセスが、AIに よる加速の土台 31
32. 今日、持ち帰ってほしい3つの問い 私たちの開発は、今どこで「滞っている」のか？ 部分的な正しさより、全体の成果を優先する判断ができているか？ 人が判断すべきことと、仕組みに任せるべきことは切り分けられて いるか？ 32
33. 33 ご清聴ありがとうございました