ティール組織はなぜ失敗する?管理を手放す前に必要な「安全」と神経系

不安定な土台で崩れるティール型ネットワークと安全な土台で育つネットワーク

ティール組織を目指して、上司を減らす。承認をなくす。「自由にやっていい」と伝える。それでも現場が動かず、むしろ混乱や責任の押しつけ合いが増える――。

この失敗は、ティール組織の考え方が間違っているからではありません。多くの場合、管理を外す前に、その管理が担っていた安全・情報・役割・フィードバックを別の形へ置き換えていないことが原因です。

ティール組織の5段階と3つの特徴で見たように、セルフマネジメントは「構造がない状態」ではありません。固定的な上下関係に代わる、より透明で分散した構造を持つ状態です。

この記事では、ティール組織がなぜ失敗するのかを、心理的安全性、神経系の比喩、そして私自身の会社立て直しの経験から読み解きます。

ティール組織が失敗する最大の理由

最大の理由はシンプルです。

管理をなくしたのに、管理に代わる回路を作っていない。

従来の階層型組織では、上司が判断し、情報を集め、仕事を割り振り、失敗時の責任を引き受けます。窮屈さはあっても、誰に聞けばよいか、誰が決めるかは分かりやすい。

そこから上司の承認だけを外すと、自由が生まれるとは限りません。

  • どこまで自分で決めてよいか分からない
  • 必要な情報を誰が持っているか分からない
  • 相談すると「自分で考えて」と返される
  • 失敗したときだけ責任を問われる
  • 対立を処理する人も手順もない

この状態は自律ではなく、曖昧さです。ティール組織では、ボスの代わりに助言プロセス、明確な役割、情報の透明性、対立解決の仕組みが必要になります。実際、ティール組織の実践知でも、対立解決のプロセスがなければセルフマネジメントは機能しにくいとされています。

「自由」は、安全があるときに初めて使える

心理的安全性とは、単に仲が良いことでも、厳しい指摘をしないことでもありません。エイミー・エドモンドソンは、チームの中で質問、異論、失敗の報告などの対人的リスクを取っても安全だという共有認識として整理しました。

安全が低い環境では、人は組織の目的より自分の防衛を優先します。

  • 失敗を隠す
  • 余計な提案をしない
  • 上司の顔色を読む
  • 責任が明確になる仕事を避ける
  • 正解が出るまで待つ

この状態で「今日から自分で決めて」と言われても、神経系にとっては解放ではなく、保護を失った出来事になり得ます。

突然責任を渡され防衛反応が起きる組織と段階的な足場で自律する組織の比較
責任を突然落とすのではなく、役割・情報・フィードバック・安全という足場を通して渡していく。

組織を神経系として見ると、失敗の構造が分かる

ここからの神経系の話は、ティール組織が神経科学で証明されたという意味ではありません。組織の反応を理解するためのモデルです。

人間の神経系は、危険を感じると、生存を優先する反応へ切り替わります。組織でも、給料の遅れ、大規模な人員変更、突然の権限移譲、失敗への処罰などが起きると、似た防衛パターンが現れます。

  • Fight:他部署や上司を攻撃し、正しさを争う
  • Flight:面倒な仕事、会話、責任から距離を取る
  • Freeze:指示が来るまで動かない
  • Fawn:本音を隠し、権限者へ過剰に合わせる

このとき、「自発性がない」「ティールに向いていない」と個人の資質だけで片づけると、さらに安全が下がります。実際には、その人が動けないのではなく、組織の回路が「動かない方が安全」と学習している可能性があります。

自走しない人を責める前に、自走すると何が起きる組織なのかを見る。

ティール組織が失敗する6つの典型パターン

1.階層を消せばティールになると思う

組織図を平らにしても、情報と権限が創業者へ集中していれば、実態は変わりません。反対に、役職が残っていても、現場が必要な情報に触れ、助言を得て判断できるなら、分散処理は進みます。

2.「自由にやって」を丸投げにする

自由には境界が必要です。目的、決めてよい範囲、使える予算、相談先、完了条件が見えなければ、自由は責任の移転に見えます。

3.心理的安全性を「ぬるさ」と誤解する

安全とは、何をしても許されることではありません。失敗や異論を出しても人格を攻撃されず、そのうえで仕事の責任は明確に扱われる状態です。高い安全と高い基準は両立します。

4.オレンジやグリーンを飛ばそうとする

KPI、業務手順、役割、専門性というオレンジの力も、対話、共感、価値観というグリーンの力も未整備なまま、ティールだけを導入することはできません。後の段階は、前の段階を消去するのではなく、必要に応じて含み直します。

5.経営者が表面だけ手放す

「任せる」と言いながら、自分と違う答えが出た瞬間に介入する。失敗したときだけ権限を取り戻す。これが続くと、現場は「最終的には経営者の正解を当てるゲームだ」と学びます。

経営者自身の神経が不安定なままでは、管理を手放しても、監視、無言の圧、突然の介入という別の形でコントロールが戻ってきます。

6.危機時にすべて中央集権へ戻す

危機時には一時的な集中判断が必要な場合もあります。しかし、理由、対象、期間を示さずに権限を回収すると、「平時の自律は仮のものだった」と伝わります。危機対応後に権限を戻す設計までが必要です。

マイクロマネジメントと放置は、反対ではない

細部まで管理することと、急にすべてを任せて見ないことは、正反対に見えます。しかし、ZPF的な自我OSの視点では、どちらも恐れから起きる場合があります。

  • マイクロマネジメント:失敗が怖いので、自分が全部握る
  • 放置:関係や対立を引き受けるのが怖いので、自由という言葉で離れる

本当のサレンダーは、責任を捨てることではありません。結果を完全に支配しようとするMeを下げながら、場に必要な条件を整え続けることです。これは、サレンダーとDoingをやめることの違いにも通じます。

自走は、一気に任せるのではなく段階的に起こす

私自身、会社の立て直し中にこのことを実感しました。

スクールの動画発信を現場へ移そうとしたとき、最初から「自由に撮って投稿して」と任せても動きません。そこで、まず私が型を作り、撮影のコツを共有し、短い動画で慣れるところから始めました。

次に、ツールや投稿先を増やし、最終的には「何月何日にこの動画を撮る」というタスク管理から、「各自のフォルダに常に3〜4本の編集待ち動画がある」という状態管理へ変えました。Alexに加えてIngridやAaronも加わり、外国人チームの発信回路が育っていきました。

これは、管理を突然ゼロにしたのではありません。

  1. こちらで型を作る
  2. 小さな実践で神経を慣らす
  3. 道具と情報を渡す
  4. タスクではなく維持すべき状態を共有する
  5. 改善提案を本人の回路へ戻す

自走は命令して起こすものではなく、構造ができた結果として起きる状態でした。

管理を手放す前に整えたい5つの安全

1.役割の安全

自分が何を感知し、どこまで決める役割なのかが分かる。役職名より、権限と責任の境界が重要です。

2.情報の安全

判断に必要な数字、顧客の声、進捗、制約へアクセスできる。情報を隠したまま判断だけ求めないことです。

3.相談の安全

相談は能力不足の証明ではありません。影響を受ける人と専門家へ助言を求められる経路を作ります。

4.失敗の安全

失敗を隠すより早く共有した方が評価される。失敗から学ぶ一方、繰り返しや無責任まで曖昧にしないことが必要です。

5.対立の安全

意見が割れたとき、声の大きさや人間関係だけで決まらない。対話、助言、調停、最終判断の経路を用意します。

ZPF視点:リーダーが最初に手放すのは「管理」ではなく恐れ

ティール組織の本質を「他者をどう自走させるか」だけで考えると、再び相手を操作する話になります。

先に問うべきなのは、リーダー自身が何を恐れているかです。

  • 任せた相手が失敗すること
  • 自分より良い方法が生まれること
  • 自分が必要とされなくなること
  • 数字が一時的に落ちること
  • 組織が自分の想定外へ進むこと

この恐れを見ないまま制度だけティールにすると、Meは別の場所から主語を取り戻します。反対に、恐れを消そうとせず観察し、必要な構造だけを整えると、リーダーは命令中枢から調律機能へ移っていきます。

ティール組織とは、管理者がいなくなることではない。恐れが組織の主語でなくなることである。

まとめ:安全は自律の反対ではなく、土台である

ティール組織が失敗するのは、自由が多すぎるからではありません。自由を使える神経回路と構造が育つ前に、保護と判断の仕組みだけを外してしまうからです。

必要なのは、管理を強化することでも、すべてを放置することでもありません。

  • 役割を明確にする
  • 情報を開く
  • 相談と対立解決の経路を作る
  • 小さな責任から段階的に渡す
  • リーダー自身の恐れを観察する

安全があるから人は異論を言えます。失敗を共有できます。自分で判断できます。そして初めて、中央の命令を待たずに全体の目的へ応答できます。

自律とは、支えが不要になることではありません。支えが一人の上司から、組織全体の回路へ移ることなのです。


参考

 

関連記事:組織は巨大な神経ネットワークなのか?経営者・管理職・現場を身体として考える

関連記事:経営者が手放すとは?コントロールの放棄と放置の違いをZPF視点で考える