「人を増やすほど遅くなる」のはなぜか？ 停滞を生むサイロ化、統合フェーズの壁
企業でよくある成長期の悩みに、「やりたいことが多すぎて、開発が追いつかない」がある。そこで「人を増やせばスピードも上がるはず」と見込んで増員するも、現実は期待とはうらはらに「現場が疲弊する」ことが起きがちだ。何が問題となってしまうのか、そしてデジタルガレージではどのように改善していったのかを見ていこう。
今回、古賀氏が例として挙げた組織はウォーターフォールで開発しており、AチームとBチームの2チーム体制であった。Aチームはベテランぞろいの既存チームで、プロジェクト全体の品質を担保する。一方、Bチームはジュニア中心の新設チームで、成果物はAチームのレビューを通すことを前提としていた。
チームおよびメンバーを増やしたことによりコミュニケーションコストも増加。人数が増えるほどに調整作業も増え、実作業に使う時間が減少し、成果が出ない不満が蓄積してメンバーの心も削られていく。個人の担当領域も局所化し「自分は何に貢献しているのか」が見えにくくなり、モチベーションの低下も起きていた。
人を増やした一方でアウトプットが生まれない現象の背景には、チーム間で情報共有の断絶が起きていたことがあった。ナレッジが流通しないため、同じミスや「車輪の再発明」が頻発する。さらにAチームのレビュー負荷が高まり、Bチームはレビュー待ちで手が止まるという滞留も発生していた。それぞれが自分の担当を完遂させることに固執し、プロダクト全体の価値を見失いかけていたのだ。古賀氏は「部分最適が積み重なり、結果として全体を殺してしまう構造でした」と振り返る。
さらに古賀氏が「一番の地獄」だったと強調したのは統合フェーズだ。設計から実装まで滞りなく進んだように思えても、統合のタイミングでチーム間に潜んでいたズレが一気に顕在化し、巨大な手戻りが生じてしまう。「これを直してください」「前提が違います」といった緊張を伴うやりとりが延々と続く。「人を増やすほど、統合時に爆発する負債も増える。これが人を増やしても開発が遅くなる正体でした」と古賀氏は説明する。
そこで、このタイミングで古賀氏がBチームにジョインし、改善を進めた。まずはBチームにのみスクラムを導入。さらにBチームがAチームのブランチへスプリントごとにマージし、コンフリクト対応などスクラムに伴う作業はBチームが引き受けることにした。そうすることでAチームの開発を止めず、全体のスループットを落とさないことを優先したのだ。
少しして、転機が訪れる。Bチームが担当する案件がビジネスで最優先となり、AチームのメンバーがBチームに合流することになった。スクラムで順調に開発が進むのを見て、AチームからBチームに移動してきたメンバーが、「今のやり方、正直気に入っています」と明かした。この言葉をきっかけに、当初スクラムに懐疑的だったAチームリーダーの取り組みに対する評価が変わっていった。ここが転換点となり、全体スクラムであるLeSS（Large-Scale Scrum）の導入が決まった。
