4689 文字
23 分
「こぼれ球を拾う」は組織設計の敗北宣言である
この記事について

Claude(Anthropic)との共同編集により作成されました。

要約
  • ベンチャーで美徳とされる「こぼれ球を拾う」は、責任・権限設計の不在を正当化するレトリックに過ぎない
  • 社会心理学(責任の拡散・リンゲルマン効果)と経営学(グレイナーモデル)の両面から構造的に非合理であることを論証する
  • 〜10人の組織ではこの方式は合理的だが、30〜50人で物理的に破綻する
  • Amazon Two-Pizza TeamのSingle-Threaded Owner、RACIマトリクスなど「こぼれ球が発生しない設計」は存在する
  • こぼれ球を「拾える個人」を称賛するのではなく、「こぼれ球が発生しない設計」を追求すべきである

「こぼれ球を拾う」という表現は、ベンチャー企業で美徳として語られることが多い。しかし本稿では、この表現が責任・権限設計の不在を正当化するレトリックに過ぎず、組織のスケーラビリティを構造的に毀損するものであることを、経営学・社会心理学・組織設計の理論に基づいて論証する。


1. 「こぼれ球」とは何か — 問題の正体#

「こぼれ球を拾う」とは、誰の担当でもないタスクを、気づいた人が自発的に処理することを指す。一見すると主体性やチームワークの発揮に見えるが、裏返せば以下の事実を暗に認めている。

表面上の美徳構造上の問題
「気づいた人がやる」責任者が定義されていない
「自分の仕事じゃなくてもやる」権限の境界が曖昧
「誰かがやらないと回らない」業務設計が破綻している
「チームで助け合う」個人の貢献が評価不能

つまり「こぼれ球」とは、組織設計の欠陥から漏れ出したタスクであり、それを「拾う」ことを美徳とする文化は、欠陥を修正するインセンティブを組織から奪う


2. 社会心理学が示す「こぼれ球」の構造的欠陥#

2.1 責任の拡散(Diffusion of Responsibility)#

社会心理学における「責任の拡散」とは、グループの規模が大きくなるほど、各メンバーが結果に対して感じる個人的責任が低下する現象である^1。「こぼれ球を拾う」文化は、まさにこの責任の拡散を組織的に制度化したものと言える。

4人グループにおける責任拡散の実験では、責任は均等に分散せず、特定の個人に集中する傾向が確認されている^2。つまり「みんなで拾おう」と言っても、実際に拾うのは常に同じ少数の人間であり、それは「助け合い」ではなく「一部の人間への構造的な過負荷」である。

2.2 リンゲルマン効果(Social Loafing)#

1880年代にリンゲルマンが綱引き実験で発見した効果によれば、グループの人数が増えるほど一人当たりの貢献は低下する^3。この効果は曲線的であり、2〜3人目の追加で顕著にパフォーマンスが下がり、6人以降はほぼ横ばいになる^4。

重要なのは、個人の貢献が識別可能である場合にこの効果は軽減されるという知見である^3。つまり「誰の仕事でもない」タスクは、まさにリンゲルマン効果が最大化される条件を満たしている。

2.3 小括:「こぼれ球を拾う」は心理学的に非合理#

現象「こぼれ球」文化との関係
責任の拡散全員の責任 = 誰の責任でもない
リンゲルマン効果個人貢献が不可視 → パフォーマンス低下
社会的手抜き「誰かがやるだろう」バイアスの増幅

解決策は明確で、個人の貢献を識別可能にし、メンバーが自分の役割に不可欠であると感じられるようにすること^3 — すなわち、こぼれ球が発生しない責任設計を行うことである。


3. 経営学が示す成長段階と組織の危機#

3.1 グレイナーの成長モデル(Greiner’s Growth Model)#

ラリー・E・グレイナーが1972年に提唱した成長モデルは、組織の成長を6つのフェーズで捉え、各フェーズの終わりに「危機(revolution)」が訪れるとする^5。

フェーズ成長の原動力終末に訪れる危機
1. 創造性創業者の情熱・プロダクト開発リーダーシップの危機
2. 方向性専門経営者による指揮自律性の危機
3. 委譲権限の分散統制の危機
4. 調整計画・報告体制の整備形式主義の危機
5. 協働マトリクス組織・横断チーム内部成長の限界
6. 同盟M&A・外部パートナーシップ

こぼれ球を拾う」文化が機能するのはフェーズ1の範囲内に限定される。フェーズ1では、小規模で非公式なチームが流動的な役割分担で動くことが合理的であり、それ自体は問題ではない^5。

しかし、フェーズ1からフェーズ2への移行にはリーダーシップの危機を克服する必要がある。この危機は、「非公式なリーダーシップ構造ではもはや不十分になり、調整の問題が表面化し、より専門的な経営構造の必要性が明らかになる」^5 ときに発生する。

こぼれ球を拾い続ける」とは、フェーズ1に留まり続けようとすることに他ならない。

3.2 30-50人の壁 — 最初の構造転換点#

複数の研究と実務的知見が、30〜50人が「こぼれ球方式」の限界点であることを示している。

  • ダンバーの研究によれば、30〜50人で非公式な創業チーム文化はスケールしなくなる。近接性と直感で回していたものが混沌に変わる^6
  • 50人時点で、CEOが情報のハブとして機能できなくなる。コミュニケーション経路数は20人で190、50人で1,225、100人で4,950に膨れ上がる^7
  • 80人前後で各チームが独自のワークフローを発展させ、チーム間連携が非効率化する^7
  • 120人前後で文化の浸透が困難になり、新メンバーは創業者の意図を理解できなくなる^7

あるフィンテック企業では、55人から130人へ成長する過程で内部機構の崩壊により、年間売上成長率が45%から18%に急落した事例が報告されている^7。

3.3 コミュニケーション経路数の爆発#

N人の組織における双方向コミュニケーション経路数は N(N-1)/2 で計算される。

人数経路数増加率
5人10
10人454.5倍
20人19019倍
30人43543.5倍
50人1,225122.5倍
100人4,950495倍
150人11,1751,117.5倍

5人の組織で10本だった経路が、50人になると1,225本になる。「こぼれ球」が発生したとき、それに気づける確率も、誰が拾うべきかの暗黙的合意も、この経路数の爆発に比例して崩壊する。


4. 「こぼれ球が発生しない」組織設計は存在する#

「こぼれ球を拾う」文化を正当化する側の暗黙の前提は、「タスクの漏れは不可避であり、それを拾える人材が優秀なのだ」というものである。しかし、世界的に成功した組織は「こぼれ球が発生しない設計」を追求している。

4.1 AmazonのTwo-Pizza TeamとSingle-Threaded Owner#

Amazonのジェフ・ベゾスが導入したTwo-Pizza Team(2枚のピザで賄える6〜10人のチーム)ルールは、チームサイズ自体が目的ではなく、自律性と説明責任(accountability)の確保が本質である^8。

各チームにはSingle-Threaded Leader(単一責任リーダー)が配置され、プロダクトやサービスに対するエンドツーエンドのオーナーシップを持つ^8。さらに各チームにはシニアリーダーシップと合意したFitness Function(単一の重要ビジネス指標)が割り当てられ、チームのP&Lに相当する指標として機能する^9。

このモデルでは、「こぼれ球」は設計上存在しない。すべてのタスクは特定のチームとリーダーのオーナーシップ下にあり、チーム間のインターフェースも明確に定義されている。

4.2 RACIマトリクス — 責任の解像度を上げるフレームワーク#

RACI(Responsible / Accountable / Consulted / Informed)マトリクスは、各タスクに対する役割を明確化するプロジェクトマネジメント手法である^10。

役割定義人数制限
Responsibleタスクを実行する人複数可
Accountable最終承認・説明責任を持つ人必ず1人
Consulted意思決定前に相談される人複数可
Informed進捗を通知される人複数可

ここで重要なのは、Accountable(説明責任者)は各タスクにつき必ず1人というゴールデンルールである^10。「こぼれ球を拾う」文化はこのAccountableが不在の状態を常態化するものであり、RACIの原則に真っ向から反する。

4.3 「権限なき説明責任」の破壊力#

500人以上のプロジェクトマネージャーを対象とした研究では、「権限の欠如」がプロジェクト失敗の原因の第2位(1位は目標の不明確さ)であった^6。

チームメンバーが結果に対する説明責任を負わされながら意思決定権を持たないという「権限なき説明責任」(Accountability without Authority)は、成長企業において蔓延しやすい。こぼれ球を拾った人間が、そのタスクの結果に暗黙的に責任を負わされる一方で、リソース配分や優先順位付けの権限は持たない — これは人材の消耗を加速させる構造的欠陥である^6。


5. 成長段階ごとの処方箋 — いつ「こぼれ球体制」を脱するか#

解像度が粗い組織はどの程度まで負荷なく成長可能なのか、どの段階でこぼれ球を拾う体制を脱していかなければいけないのか。組織規模ごとの移行ロードマップを示す。

Stage 0:〜10人(許容範囲)#

この段階では、こぼれ球方式は合理的である。全員が全情報にアクセスでき、コミュニケーション経路数は最大45本。暗黙的な役割分担が機能し、調整コストは低い。

ただし、この段階であっても意識的にこぼれ球方式を採用していることが重要である。「たまたまうまくいっている」のと「この規模では合理的だと理解して採用している」のでは、次の段階への移行準備に決定的な差が出る。

Stage 1:10〜30人(移行準備期)#

ここで移行の種を蒔かなければ手遅れになる。

  • 5〜8人の自律的なスクワッドに分割し、各スクワッドに明確なプロダクト領域のオーナーシップを与える^11
  • 意思決定フレームワーク(RAPID等)を導入し、「誰が決めるか」を明文化する^11
  • オンボーディング、インシデント対応、コードレビューなどの最初のプレイブックを作成する^11

Stage 2:30〜50人(第一の壁)#

こぼれ球方式が物理的に破綻するポイント。

  • コミュニケーションは非同期ファースト(RFC、プロダクトブリーフ、意思決定ログ)に移行^11
  • チーム間インターフェースを明文化し、Team API(オーナーシップ、リクエストプロセス、SLA)を定義^11
  • エンジニアリング専任マネージャーを雇用(8〜12人のエンジニアがいてテックリードが50%以上の時間をピープルマネジメントに費やしている場合)^12

Stage 3:50〜150人(構造転換期)#

ここまでこぼれ球体制を引きずった組織は高確率で機能不全に陥る。

  • 構造化された週次・月次オペレーションリズムを痛みが来る前に導入^7
  • 文書化された意思決定プロセスを整備^7
  • 廊下での会話に代わる公式コミュニケーション構造を構築^7
  • グレイナーモデルのフェーズ2〜3への移行を明確に意識する

6. 「こぼれ球を拾え」は何を隠蔽しているか#

「こぼれ球を拾う」という表現が好まれる本当の理由は、以下の不都合な事実を美化する機能を持っているからである。

  1. 経営者の組織設計能力の不足 — 業務分掌・権限設計をできていないことを「柔軟な組織」と言い換えている
  2. 採用・人員計画の失敗 — 必要な人数がいないことを「少数精鋭」と言い換えている
  3. 評価制度の不在 — 誰が何をしたか追跡できないことを「チームプレー重視」と言い換えている
  4. 構造的過負荷の個人責任化 — 組織の欠陥を、拾わなかった個人の「当事者意識の欠如」にすり替えている

特に4点目は深刻である。こぼれ球が拾われなかったとき、批判されるのは「拾わなかった個人」であり、「そもそもこぼれ球が発生する組織設計」ではない。これは本質的に構造的問題の個人責任化であり、体育会的精神論の典型である。


7. 結論#

論点結論
「こぼれ球を拾う」の本質責任・権限設計の不在を美化するレトリック
許容される規模〜10人程度まで(コミュニケーション経路数45以下)
移行準備を始めるべき規模10〜30人
構造的に破綻する規模30〜50人
理論的根拠責任の拡散、リンゲルマン効果、グレイナーの成長モデル
代替手段RACI、Single-Threaded Owner、Team API

「こぼれ球を拾う」は10人以下の組織における現実的な対処法であり、それ自体を否定する必要はない。しかし、それを組織文化や美徳として制度化し、成長後も維持しようとすることは、社会心理学的に非合理であり、経営学的に危険である。

ベンチャー企業が成長とともに機能不全に陥る大きな要因のひとつは、この「こぼれ球を拾う」精神論を、責任・権限の明確な設計で置き換えることに失敗することにある。こぼれ球が発生すること自体が問題なのではない — こぼれ球の発生を前提とし、それを拾うことを美徳とする文化が、構造的改善を阻害することが問題なのである。

組織が10人を超えたら、「こぼれ球を拾える人」を称賛するのではなく、「こぼれ球が発生しない設計」を追求すべきである。


補足: 記載内容の妥当性検証(2026-05-01時点)#

検証方法#

社会心理学の学術論文(Ingham 1974、責任拡散に関するPMC論文)、経営学の確立されたモデル(Greiner 1972)、AWS公式ドキュメント、組織設計に関する実務記事を主な情報源とした。各主張について、複数の独立した情報源との整合性を確認した。

検証結果#

主張評価根拠
責任の拡散:グループ規模↑で個人責任↓✅ 正確Darley & Latané (1968) 以来の確立された知見。PMC掲載論文で追試済み
リンゲルマン効果:2〜3人目で顕著に低下、6人以降横ばい✅ 正確Ingham et al. (1974) の原著論文に基づく
グレイナーの成長モデル6フェーズ✅ 正確Greiner (1972, 1998改訂) の原著に基づく。6フェーズ目は1998年の改訂で追加
30〜50人で非公式文化が破綻✅ 正確複数の独立した情報源(Dunbar研究、スタートアップ実務文献)で一致
コミュニケーション経路数 N(N-1)/2✅ 正確組み合わせ計算として数学的に正確
Amazon Two-Pizza Team / Single-Threaded Owner✅ 正確AWS公式ドキュメント(aws.amazon.com)に基づく
RACI の Accountable は必ず1人✅ 正確RACI の標準的なベストプラクティスとして広く認知
「権限の欠如」がプロジェクト失敗原因の第2位⚠️ 要注意出典記事(Medium)の元データへのリンクが確認できず、具体的な調査機関名が不明
フィンテック企業の成長率低下事例(45%→18%)⚠️ 要注意PM Guru記事からの引用だが、具体的な企業名・原著論文は非公開
ベンチャー失敗率90%⚠️ 要注意定義・対象範囲により大きく変動する数字。文脈依存性が高い

注意・補足#

  • グレイナーモデルの各フェーズに具体的な従業員数の閾値は原著では定義されておらず、本記事の「30〜50人」等の数値は他の研究・実務知見との統合によるものである
  • ダンバー数(約150人)は2021年のBiology Letters誌掲載論文で方法論的批判を受けており、特定の数字に過度に依存すべきではない。ただし「認知的限界が存在する」という大枠の主張は依然として支持されている
  • 「こぼれ球を拾う」という表現自体は日本のベンチャー文化に特有であり、英語圏の文献に直接的な対応概念はない。本記事では「ownership gap」「diffusion of responsibility」等の概念を対応させている

総合評価#

資料の主要な論理構成(社会心理学的根拠、組織成長理論、代替手段の提示)はいずれも確立された学術的・実務的知見に基づいており、全体として信頼性は高い。一部の具体的事例・数値については一次情報源の確認が困難なものがあるが、論旨の根幹には影響しない。


参考文献#

  1. Diffusion of Responsibility - Group - iResearchNet https://psychology.iresearchnet.com/social-psychology/group/diffusion-of-responsibility/
  2. Responsibility Diffusion in Cooperative Collectives, Personality and Social Psychology Bulletin, 2002 https://journals.sagepub.com/doi/10.1177/0146167202281005
  3. Ringelmann effect - Wikipedia https://en.wikipedia.org/wiki/Ringelmann_effect
  4. Ingham, A. G. et al. “The Ringelmann effect: Studies of group size and group performance”, Journal of Experimental Social Psychology, 1974 https://www.sciencedirect.com/science/article/abs/pii/002210317490033X
  5. Greiner’s Growth Model - FourWeekMBA https://fourweekmba.com/greiners-growth-model/
  6. The Scaling Trap: When Startups Eat Their Own https://paddo.dev/blog/the-scaling-trap/
  7. From 50 to 150 Employees: Preventing Operational Chaos - PM Guru https://www.pmguru.org/insights/scaling-50-to-150-employees/
  8. Amazon’s Two Pizza Teams | AWS Executive Insights https://aws.amazon.com/executive-insights/content/amazon-two-pizza-team/
  9. Amazon’s “two-pizza teams”: The ultimate divisional organization https://jasoncrawford.org/two-pizza-teams
  10. What Is a RACI Chart? | Coursera https://www.coursera.org/articles/what-is-raci-chart
  11. How to Scale Distributed Product Teams From 10 to 100+ https://intelligentfuturetech.com/blog/scaling-distributed-product-teams-2025/
  12. SmithSpektrum Blog: Engineering Team Structure 2026 https://smithspektrum.com/blog/engineering-team-structure-2026
「こぼれ球を拾う」は組織設計の敗北宣言である
https://yurudeep.com/posts/essay/2026/20260502/
作者
ひらノルム
公開日
2026-05-02
ライセンス
CC BY-NC-SA 4.0