「人を増やすほど遅くなる」のはなぜか？ 停滞を生むサイロ化、統合フェーズの壁
企業でよくある成長期の悩みに、「やりたいことが多すぎて、開発が追いつかない」がある。そこで「人を増やせばスピードも上がるはず」と見込んで増員するも、現実は期待とはうらはらに「現場が疲弊する」ことが起きがちだ。何が問題となってしまうのか、そしてデジタルガレージではどのように改善していったのかを見ていこう。
今回、古賀氏が例として挙げた組織はウォーターフォールで開発しており、AチームとBチームの2チーム体制であった。Aチームはベテランぞろいの既存チームで、プロジェクト全体の品質を担保する。一方、Bチームはジュニア中心の新設チームで、成果物はAチームのレビューを通すことを前提としていた。
チームおよびメンバーを増やしたことによりコミュニケーションコストも増加。人数が増えるほどに調整作業も増え、実作業に使う時間が減少し、成果が出ない不満が蓄積してメンバーの心も削られていく。個人の担当領域も局所化し「自分は何に貢献しているのか」が見えにくくなり、モチベーションの低下も起きていた。
人を増やした一方でアウトプットが生まれない現象の背景には、チーム間で情報共有の断絶が起きていたことがあった。ナレッジが流通しないため、同じミスや「車輪の再発明」が頻発する。さらにAチームのレビュー負荷が高まり、Bチームはレビュー待ちで手が止まるという滞留も発生していた。それぞれが自分の担当を完遂させることに固執し、プロダクト全体の価値を見失いかけていたのだ。古賀氏は「部分最適が積み重なり、結果として全体を殺してしまう構造でした」と振り返る。
さらに古賀氏が「一番の地獄」だったと強調したのは統合フェーズだ。設計から実装まで滞りなく進んだように思えても、統合のタイミングでチーム間に潜んでいたズレが一気に顕在化し、巨大な手戻りが生じてしまう。「これを直してください」「前提が違います」といった緊張を伴うやりとりが延々と続く。「人を増やすほど、統合時に爆発する負債も増える。これが人を増やしても開発が遅くなる正体でした」と古賀氏は説明する。
そこで、このタイミングで古賀氏がBチームにジョインし、改善を進めた。まずはBチームにのみスクラムを導入。さらにBチームがAチームのブランチへスプリントごとにマージし、コンフリクト対応などスクラムに伴う作業はBチームが引き受けることにした。そうすることでAチームの開発を止めず、全体のスループットを落とさないことを優先したのだ。
少しして、転機が訪れる。Bチームが担当する案件がビジネスで最優先となり、AチームのメンバーがBチームに合流することになった。スクラムで順調に開発が進むのを見て、AチームからBチームに移動してきたメンバーが、「今のやり方、正直気に入っています」と明かした。この言葉をきっかけに、当初スクラムに懐疑的だったAチームリーダーの取り組みに対する評価が変わっていった。ここが転換点となり、全体スクラムであるLeSS（Large-Scale Scrum）の導入が決まった。
「強制しない」アプローチで育む共創の文化
LeSSの原理原則はシンプルだ。チーム単位で分けるのではなく、あくまでも1つのプロダクト、1つのバックログ、1つのプロダクトオーナーで扱う。透明性を確保し、観察事実に基づいてプロセスを適応させる経験主義であり、判断軸はあくまでも顧客に届ける価値とする。役割やプロセスを増やすことなく、規模が大きくなっても「スクラムはスクラム」に帰着する。
LeSS導入後、組織にはいくつもの変化が起きた。チームごとに異なる判断をしていた優先順位は、1つのバックログで揃うようになった。特定のシニアに集中していたレビューは、チーム間の協働が日常になった。巨大な手戻りが発生していた統合は、常時統合・継続的学習へと変わり、個人の努力に委ねられていた開発の加速は組織構造で自然発生するようになった。
とはいえ、新たな課題も浮上してきた。「LeSSを導入してみてわかったのは、教科書通りにはいかないという現実でした」と、古賀氏は語る。すでに動いているプロジェクトに適応する場合、立ち上がり時は計画通りに進まず、混乱が生じやすい。
また、どこまで意思決定すべきか、どこまで支援すべきかといった役割のとらえ方がチームごとに異なり、摩擦が生まれることもあった。さらに自己流の解釈で「わかったつもり」「やっているつもり」だと、本来期待する効果が出にくいケースもあった。
その際、古賀氏らが意識したのは、納得感を重視した「強制しない」アプローチだった。プロセスを守ることを目的にせず、現場が腹落ちすることを重視する。問題が顕在化したタイミングで振り返りを促すなど、適切な介入を心がけた。そしてどこで流れが滞っているかを観測した数値に基づいて対話するようにした。
ただし、数値は評価ではなく「健全に価値を生み続けられているか」を見定めるものだ。そこで使用したのが生産性フレームワーク「SPACE」の5つの指標、（1）Satisfaction（幸福度・心理的安全性）、（2）Performance（アウトカム・品質）、（3）Activitiy（活動の量・PR数）、（4）Communication（協調・レビューの質）、（5）Efficiency（流れの良さ・待ち時間）だ。これらの指標は、開発ツールと連携できる分析ツール「Findy Team+」を活用して自動的に計測している。
LeSS導入が組織に好影響を与えていることは、SPACEの指標からも読み取れる。まずSatisfaction指標では、アンケートでの「親しい知人や友人に、このチームで働くことを勧めたいか」の回答が72％から92％へと向上した。こうした心理的安全性の向上は不具合の早期発見や積極的な改善提案につながっている。
Performance指標ではリリース頻度が月に0.5回から2回へと増加。Efficiency指標となる平均サイクルタイムは10日から2日へと短縮された。小刻みにリリースできるようになり、ビジネスの要望にスピーディーに対応できるようになった。
さらに1人あたりの1日の会議時間が0.7時間削減できた。会議の目的を「共有」から「意思決定」に再定義し、会議体を見直したことが大きい。情報共有やドキュメントの見直しに関する調査では84％が高評価であり、満足度の向上も確認できた。
AIは「混乱」から「加速のエンジン」へ！ 構造・評価・文化の土台が技術を最大化させる
AIの活用に関しては、これまでは判断軸がばらばらで使えば使うほど混乱が増幅していた。しかしLeSS導入で目的や優先順位が揃うと、AI活用が一気に加速。古賀氏は「ツールを増やしたからではありません。何を良しとするかの定義が組織の中でそろったことが大きいです。これでAIは加速のエンジンに変わりました」と語る。
ではAIをどこに活用したのか。1例目はチケット作成だ。まずは「1日で終わるサイズ」を基準として定義し、これまで感覚的にやっていた分割をルール化（標準化）したうえでAIに渡した。そのうえでAIにBacklog MCPでチケットを作成してもらい、人間はAIが作成したチケットの要件や妥当性を確認することに専念した。
2例目はコーディング。同社では「Cursor」と「Claude Code」を使用しており、両チームで合意していたコーディング規約や設計ルールをAIに渡すことを前提に整理した。これをバイブコーディングに使用している。結果として、設計思想のズレを書く前段階で防げるようになった。コードの書き方が揃うことで、レビューでの指摘も減少した。古賀氏は「AIは速く書くためだけではなく、ズレを生まないためのガードレールとして機能しています」と話す。
3例目はレビュー。AIは規約やコーディングルールの遵守確認、明らかなバグや抜け漏れの検知、PRの要約・変更点の整理などの「作業」を担う。一方、人間は要件との整合性、設計妥当性、変更価値・効果の確認で、「判断」を担う。この分担によりレビューの質とスピードを両立することができた。
4例目はテストだ。結合テストに向けて、テスト観点を明文化して品質を標準化した。要件定義書やソースコードをインプットとして、AIにテストケースを自動作成させる。Markdown形式で出力するとレビューや管理がしやすくなる。最終的にはテストの実行から結果確認までAIで完結させて、設計・実装・検証のループを高速で回せる状態を目指す。E2EテストでもAIを活用しており、Playwrite MCPでテストコードを自動生成している。仕様理解から、テスト作成、実行、確認までをAIに任せることで、人間が目視で確認する工数を大幅に削減できた。
AI活用の成果としては知識共有と底上げも大きかった。チームごとの品質差を解消できて、誰がどのコードを見ても理解でき、スキルが平準化した。ジュニアメンバーはAIの指摘から学ぶことでスキルが向上し、品質のボトムアップに貢献した。
さらにLeSS導入はビジネスとの協働も変えた。従来は声の大きい順で優先順位が決まっていたが、今ではプロダクト全体で最適化が進んでいる。数か月後のリリース時にもらっていたフィードバックは、2週間ごとのデモで受け取れるようになり、不透明で疑心暗鬼だったトレードオフ判断も共通認識のもとで実施されるように変わった。
ビジネス面でも成果をあげている。顧客からの問い合わせを分析し、開発チームから機能改善を提案するようにった結果、問い合わせ件数は半数ほどに減少。そして何よりも「守り」から「攻め」へ、ビジネス拡大の要求に即座に応えられる体制へと進化した。
この軌跡をステップごとに振り返ると次のような流れだ。
まずはサイロを打破し、LeSSで組織をシンプルにする構造改革から開始。次にSPACEで組織の健康状態を多面的に評価するなかで、心理的安全性が高まり、全体最適を共通言語にする文化を醸成した。この基盤の上で、AIがスピードと品質にブーストをかけられるようになった。古賀氏は「いきなりAIの活用から始めたのではなく、構造、評価、文化を整えたことで、技術の効果が最大化できたという流れです」と説明する。
今回の取り組みを再現するためのポイントは、「小さく始める」「構造を整える」「流れを見る」「納得で変える」「前提を定義する」の5つに集約できる。
最後に古賀氏は次のようにまとめた。
「ここから持ち帰ってほしい問いが3つあります。1つ目は『私たちの開発は、いまどこで滞っているのか』、2つ目は『部分的な正しさより、全体の成果を優先する判断ができているか』、3つ目は『人が判断すべき事と、仕組みに任せるべきことは切り分けられているか』です。いま答えを出す必要はありません。構造の見直しが大きな加速につながることをここから持ち帰っていただけるとうれしいです」
デジタルガレージからのお知らせ
デジタルガレージグループでは多岐に渡る領域で常に最新技術を追求し、自社プロダクトとして社会に実装する仲間を募集しています。詳しくは採用サイトをご覧ください。
