icon tsuyukimakoto

速く適応するチームをめぐる読み物

2026/06/18 23:45

※ 商品のリンクをクリックして何かを購入すると私に少額の報酬が入ることがあります【広告表示】

以下は、私の考えをそのまま断定的に書いたものではない。

OODAループの開発チームへの適用やその発展形、Working Out Loud、心理的安全性、Nonviolent Communication、ingressやスタートアップでの経験を踏まえて私が考えていることを伝え、それを「きっとこういうことですよね」という形でCodexや他のAIエージェントを何往復かして文章にしてもらった整理である。2015年に ingress の経験から、組織の中で人がどうつながり、どう動けるようになるのかについてブログに書いているのだが、その少しあとに出た Team of Teams に、個人的に気になる響き合いがあるのは面白いと思っている。

自分の立場としては、そのままの主張というより、いま考えていることの輪郭をいったん外に出したものにあたる。

1. 起点となる問い

AIエージェントを含む開発体制で、いままで通りの計画と分業が機能しにくくなった。

プロダクトを取り巻く環境の変化が速くなり、計画通りに作っても、作っている間に前提が古くなる。 実装や試作が速くなるほど、何を確かめるために作るのか、得られた情報をどう共有するのか、誰がどこで判断するのかが、組織全体が前に進む速度を左右する。

これらは、個人の意思決定、チームと市場のあいだの学習、組織の運用、チームの構造、発話や組織の文化まで、異なる範囲にまたがる課題である。
本稿では、それぞれのフレームワークが扱う範囲を整理し、最後に相互の関係を階層モデルとしてまとめる。

各フレームワークを見る前に、二つの言葉を区別しておきたい。
Stanley McChrystal が Team of Teams で使った、Complicated と Complex の区別である。

Complicated は部品の数が多いが、相互作用が予測可能な系を指す。
スイス時計やジェットエンジンがこれにあたる。
分解すれば理解でき、設計図があれば再現できる。

Complex は部品の相互作用が創発を生み、予測できない系を指す。
都市、生態系、ゲリラ戦、市場がこれにあたる。
分解しても全体の挙動は復元できない。

この区別は、Dave Snowden の Cynefin Framework が広めた整理の一部である。
本来 Cynefin は Clear、Complicated、Complex、Chaotic、Confused の5領域からなり、領域ごとに有効な進め方が違うとする。
本稿では McChrystal の用法に揃えて2区分だけを使うが、Cynefin は領域ごとの行動様式まで扱っている。

20世紀に広まった組織管理の多くは、Taylor 主義に代表されるように、Complicated 系への最適化として組み立てられた。
分業し、標準化し、計測すれば効率が上がるという発想である。
現代のソフトウェア開発と顧客環境は Complex 系であるのに、組織構造は20世紀のままのことが多い。
この不整合が、これから扱う多くのフレームワークが対応しようとしている問題である。
後半では、この不整合のなかで適応を支える条件として、文化と発話を扱う。

2. OODA Loop

OODA Loop は、米空軍大佐 John Boyd が戦闘機パイロットとしての経験をもとに組み立てた理論である。
朝鮮戦争では、MiG-15 に上昇力や高高度性能で優位な面がある一方で、F-86 セイバーには視界や操縦性の強みがあった。
Boyd が重視したのは、そうした個別性能の優劣そのものより、パイロットが状況を見て判断し、機体を操作するまでのサイクルの速さだった。

ループは4つのフェーズで構成される。

Observe(観察)：環境、相手、自分の状態について情報を集める。
Orient(状況判断)：集めた情報を自分の認知マップに当てはめて意味付ける。
Decide(意思決定)：仮説を選んで方針を定める。
Act(行動)：実行し、結果が次の Observe に戻る。

教科書的な紹介では4フェーズが同列に並べられることが多いが、Boyd の原図では Orient が中心に置かれている。
Orient には、文化的伝統、遺伝的素養、過去の経験、新情報、分析と統合という5つの要素が密接に絡んでいる。
同じ事象を観察しても、Orient が違えば全く違う意思決定に至る。

この構造から二つのことがわかる。
まず、観測ツールを増やしても、Orient の質が低ければ意思決定は改善しない。
また、他の視点を持ち込み、自分の前提を疑い、領域をまたぐ知識を加える方が、観測の精度を上げるだけよりも意思決定を大きく変えることがある。

「速さ」の解釈にも注意が要る。
単に時間あたりの試行回数を増やすことではない。
Boyd の言う速さは、相手の Orient が機能している間に次の状況を作り出し、相手の認知マップを陳腐化させることである。
相手が Observe で得た情報が古くなり、Orient が機能しなくなる。
ビジネスでは、市場や顧客の変化より速く適応できれば優位に立てる、と読み替えられる。

OODA がソフトウェアのチーム開発で前面に出ることは少ない。
その理由として、いくつか考えられることがある。

第一に、軍事起源の語彙が馴染まない。
「敵の OODA ループの中に入る」という敵対的フレーミングは、社内協働には直訳できない。

第二に、Boyd のオリジナルは単独パイロットの認知過程であり、チームや組織への拡張は彼自身が十分には書かなかった。

第三に、アイデアだけが他のフレームワークに吸収されて見えにくい。
Lean Startup の Build-Measure-Learn、継続的デリバリーの fast feedback loop、Agile の短いイテレーションには OODA と重なる発想があるが、Boyd の名前は前面に出にくい。

第四に、Boyd 自身が著作を残さなかったため、研究や教育のなかで参照されにくく、ソフトウェア業界の標準的な教科書にも組み込まれなかった。

それでも OODA を明示的に使っている領域はある。
組織への応用として広く知られているのが Stanley McChrystal の Team of Teams である。
ほかにも、サイバーセキュリティのインシデント対応、米軍のソフトウェア改革で中核に置かれている DevSecOps や software factory、Donald Reinertsen のプロダクト開発論などで使われている。
Wardley Mapping(Simon Wardley)も OODA を明示的に引用している。
価値連鎖と進化段階(Genesis、Custom-built、Product、Commodity)で事業を地図化し、Orient に役立てる。

3. Build-Measure-Learn

Build-Measure-Learn は、Eric Ries が 2011年の The Lean Startup で提示したフレームワークである。
背景は、Ries が IMVU の CTO 時代に経験した「作ったものが使われない」という根本問題である。
影響源としては、Steve Blank の Customer Development、トヨタ生産方式、そして Ries 自身がしばしば言及してきた Boyd の OODA がある。
特にトヨタ生産方式(大野耐一が戦後のトヨタで体系化した生産システム)は、Lean Startup の語源であり思想の柱である。
ジャストインタイム、自働化、なぜなぜ5回、ムダ・ムラ・ムリの排除といった概念が、BML の思想的な背景にある。

ループは Build、Measure、Learn の3ステップで構成され、Learn の結果として新しい仮説が立ち、次の Build に戻る。

実行は Build から始まるが、設計は逆順で考える必要がある。

Learn：何を学びたいのか、検証すべき仮説は何か。
Measure：その仮説を判定できる指標は何か。
Build：その指標を取るために最小限作るものは何か。

この逆順の発想が抜けると、「まず作り、学びはあとから解釈する」という進め方になり、仮説駆動の学習サイクルではなく、単なる反復開発になってしまう。
Lean Startup の中心にあるのは、ループを回すこと自体ではなく、仮説を検証することである。

MVP(Minimum Viable Product)は、しばしば「動く最小プロダクト」と解釈されるが、本来は「学習サイクルを1周回すために必要な最小限のもの」を指す。

形態は問わない。

スモークテスト MVP：ランディングページだけ作って事前登録数を測る。
コンシェルジュ MVP：人力で1顧客に対応して需要を確かめる。
ウィザード・オブ・オズ MVP：利用者には完成品のように見せ、裏側では人間が手動で処理する。
単一機能 MVP：1機能だけのプロダクト。

Dropbox の初期 MVP は動画1本だった。
Drew Houston が想定機能を3分の動画にまとめて公開し、ベータ登録が一晩で5000から75000に増えた。
一般公開できる製品を完成させる前に、需要があるかという重要な仮説を検証できた。
MVP は品質を下げるための考え方ではなく、検証に必要のない範囲を作らないための考え方である。

Validated Learning(検証された学び)は、進捗の単位を変える発想である。
機能の完成数ではなく、検証された仮説の数で進捗を測る。
指標は、Vanity Metrics(虚栄の指標)と Actionable Metrics(行動可能な指標)に分けて考える。

Vanity Metrics は累計ユーザー数や累計 PV など、右肩上がりにしか見えない指標を指す。
Actionable Metrics はコホート別の維持率、登録からアクティブへの転換率、課金転換率など、改善の打ち手と直接結びつく指標である。
「先週よりユーザーが増えました」だけでは、次の行動を決める判断材料として不十分である。

Innovation Accounting(革新会計)は、不確実性が高い新規事業の進捗を測る仕組みである。
3ステップで構成される。
第一に、MVP で現在地のベースラインを測る。
第二に、各イテレーションで指標を理想値に近づけるよう調整する。
第三に、改善が停滞したら方向転換(Pivot)を判断する。
これがあると、財務指標が動く前の段階でも進捗を語れる。

Pivot(方向転換)は失敗ではなく学習の成果として再定義される。
Ries は本書で10種類の Pivot を分類している。
代表的なものは Zoom-in Pivot(機能を絞る)、Zoom-out Pivot(機能を全体の一部に格下げ)、Customer Segment Pivot(顧客を変える)、Customer Need Pivot(解決する問題を変える)などがある。
Instagram は Burbn という位置情報共有アプリの写真機能だけ残した例としてよく挙げられる。
YouTube も、当初は動画付きのマッチングサービスとして出発し、のちに汎用の動画共有へ広がった例として語られることが多い。

Ries は事業の成長メカニズムを3種類に分類している。

Sticky(粘着)エンジン：新規顧客の獲得率が解約率を上回る。サブスクや SaaS が該当する。
Viral(バイラル)エンジン：バイラル係数が1を超える。SNS や招待制サービスが該当する。
Paid(有料)エンジン：顧客生涯価値が顧客獲得コストを上回る。広告依存型ビジネスが該当する。

一度に1つのエンジンに集中するのが推奨される。
複数同時改善は学習を曖昧にするためである。

2026年時点では、AI コーディングエージェントによって Build にかかる時間と費用が下がっている。
その分、何を測り、結果から何を学ぶかが以前より大きな制約になる。
作り始める前の仮説と検証方法の設計が、組織の学習速度を左右する。

Measure と Learn を継続的に行う方法として、Teresa Torres の Continuous Discovery(2021)がある。
プロジェクトごとに散発的な顧客調査を行うのではなく、プロダクトチームが週次で顧客と接する。
その結果を Opportunity Solution Tree(成果から機会、解決策、仮説検証までを結ぶ樹形図)で整理し、継続的に仮説を検証する方法である。
BML を運用する際に、測りやすい指標だけを追う状態を避ける方法としても参照できる。

4. Team of Teams

Stanley McChrystal が 2015年の Team of Teams: New Rules of Engagement for a Complex World で提示した組織論である。
McChrystal は 2003年から2008年にかけて JSOC(統合特殊作戦コマンド)を指揮し、イラクで Al-Qaeda in Iraq(AQI)と戦った。

JSOC は世界最強の特殊部隊を抱え、装備も訓練も AQI を遥かに上回っていた。
それなのに勝てない、むしろ負け始めていた。

分析の結果、AQI は小さく分散しフラットでネットワーク化された組織だった。
情報をリアルタイムに共有し、現場で即決し、行動して、次の標的に移っていた。
JSOC は階層的で縦割りで、決裁が中央に上がり、現場が動くまでに AQI は次の都市にいた。

McChrystal の診断はこうである。
個々の特殊部隊は世界最強の「チーム」だったが、組織として「チーム OF チーム」になれていなかった。
これが書名の意味である。

JSOC の問題は Complicated 向けに設計された組織が Complex 環境に置かれたことだった。
20世紀の軍事組織はテイラー主義的な分業と階層で最適化されていた。
21世紀の脅威であるネットワーク型の敵に対しては、この設計が機能しない。
Complex な環境に合わせて組織の運営を変える必要がある、というのが本書の主張である。

McChrystal が進めた変革には、二つの柱がある。

Shared Consciousness(共有意識)は、全員が全体像をリアルタイムで共有している状態を指す。
JSOC で象徴的だったのは、O&I Brief(Operations & Intelligence Briefing)である。
毎日90分の会議に全世界の関係者数千人がオンラインで参加し、各部隊の作戦、収集情報、直近の動きを共有した。
下級兵士から将官まで同じ会議を聞いた。
秘密保持より速度と適応を優先する選択である。

Empowered Execution(権限委譲した実行)は、意思決定権を必要な情報を持つ現場に近い階層へ移すことである。
McChrystal たちは、透明性を高めたうえで、現場に近いところへ判断権限を移す必要があると繰り返し述べている。

権限委譲は Shared Consciousness が前提であることに注意が要る。
全体像を共有していないチームに権限を委ねれば、各チームの判断がばらばらになりかねない。
McChrystal の表現を借りれば、リーダーは「Eyes on, Hands off」(全部見える、だが手は出さない)に徹する。
役割は指示者から園芸家(Gardener)に変わる。
環境を整え、栄養を与え、各チームが自律的に育つようにする。

この二つを支えるために、いくつかの仕組みも導入された。

バグダッドには巨大な作戦センターを作り、CIA、FBI、NSA、各特殊部隊が同じ部屋で働くようにした。
書類のやり取りで情報共有していた状態からの転換である。

Embedded Liaisons(派遣連絡員)として、各組織から最も優秀な人材を選び、他組織に半年単位で出向させた。
これにより組織をまたぐ人のつながりができ、信頼が築かれた。

共通言語と共通プロセスとして、異なる部隊が同じ用語と同じ報告フォーマットを使うように整えた。
O&I Brief は、異なる組織のあいだで情報を説明し直す負担を減らした。

透明性の方針も反転させた。
通常は「Need to know」(必要な人にだけ)であった情報共有方針を、「Need to share」(共有しない理由を説明しろ)に変えた。
共有しない側に、その理由を求める方針へ変えたのである。

組織内の知識の流通を別の角度から見た理論として、野中郁次郎と竹内弘高の SECI モデル(1995)がある。
共同化(暗黙知から暗黙知へ)、表出化(暗黙知から形式知へ)、結合化(形式知から形式知へ)、内面化(形式知から暗黙知へ)の4段階の螺旋として組織の知識創造を捉える。
McChrystal の O&I Brief は、SECI で言えば共同化と表出化の場を組織規模で作る試みと読める。
1986年の Takeuchi と Nonaka の HBR 論文がラグビーの陣形を比喩に使い、これが後のアジャイル開発の Scrum の語源になっている。

5. Team Topologies

Matthew Skelton と Manuel Pais が 2019年に出版した書籍 Team Topologies: Organizing Business and Technology Teams for Fast Flow で提示したフレームワークである。
DevOps Topologies という Web サイトに蓄積された現場知見を体系化したものである。

背景にあるのは Conway の法則である。
1968年に Melvin Conway が定式化したもので、「システムを設計する組織は、その組織のコミュニケーション構造をそっくりまねた設計を生み出す」と述べる。
組織図と相似形のシステムができる、ということである。

この観察を逆向きに使ったのが Inverse Conway Maneuver(逆 Conway 操作)である。
作りたいアーキテクチャに合わせて組織を設計する。
チームの境界が、システムの境界を生む。

チームタイプは4種類に整理される。

Stream-aligned：価値の流れ(プロダクト、顧客ジャーニー、サービス)に沿って end-to-end の責任を持つチーム。組織の多くの業務を担う中心的なチームとなる。
Platform：Stream チームの認知負荷を下げる社内サービスを提供するチーム。社内 Kubernetes 基盤チーム、CI/CD 基盤チームなどが該当する。
Enabling：Stream チームに一時的に伴走して新しい能力を習得させるチーム。SRE 横断チーム、セキュリティ伴走チームなど、コーチ役を担う。
Complicated-subsystem：特殊な専門知識が必要な領域を担当するチーム。動画コーデック、機械学習モデル、決済精算ロジックなどを、他のチームから切り離して担当する。

多くのチームは Stream-aligned であるべき、というのが本書の主張である。
それ以外の3タイプは Stream を支援する存在である。

相互作用モードは3種類に整理される。

Collaboration：2チームが密に協働する。多くの情報を交換できる一方で、認知負荷も高い。不確実な領域を探索するときに、期間を限って使うことが推奨される。
X-as-a-Service：一方が他方に明確な「API」でサービス提供する。定常運用に向いており、境界が安定してから採用する。
Facilitating：Enabling チームが Stream チームを伴走支援する。新技術導入や能力ギャップ解消の場面で使われる。

チームタイプの組み合わせごとに、適した相互作用モードがある。
たとえば Platform と Stream-aligned では X-as-a-Service、Enabling と Stream-aligned では Facilitating が基本となる。

チーム設計の基準となるのが認知負荷(Cognitive Load)である。
人が扱える複雑性には上限があり、チームの責務が認知負荷の上限を超えると、成果を出しにくくなる。
そのため、チーム分割は人数や機能数だけでなく、そのチームが日常的に扱う複雑さの種類で考える必要がある。

Team API という概念も導入されている。
各チームは外部に対して明示的なインターフェース(コード API、Slack チャンネル、Wiki、責任範囲、業務時間)を持つ。
他チームは「あの人に聞かないとわからない」状態を脱せる。

チームは長く維持することを前提とする。
プロジェクトごとに人を集めて解散する「プロジェクト型」ではなく、継続するチームが仕事を引き受ける「プロダクト型」を採る。
チームの学習曲線を活かすためである。

書籍はアンチパターンも明確に扱っている。
DevOps、SRE、セキュリティに関する仕事を完全に別チームへ切り出すと、Stream-aligned チームとのあいだに依存が増えやすい。
そのため、必要に応じて Enabling チームが伴走し、Stream-aligned チーム自身が必要な能力を身につける形が推奨される。

Spotify モデル(Squad、Tribe、Chapter、Guild の組み合わせ)との違いも整理しておく。
Spotify モデルは組織の人の所属構造を語ったものであり、Team Topologies はチーム同士の相互作用とアーキテクチャの関係を語ったものである。
両者は扱う対象が違う。
Spotify 自身が、自社の事例をそのまま設計図として写すべきではないと繰り返し説明して以降、Spotify モデルは参照事例として扱われることが増えた。
Team Topologies は、チームの境界と相互作用を設計するための、より明示的な方法を示している。

Team Topologies がチーム構造を扱うのに対し、Marty Cagan の Empowered Product Teams(2020)は、Stream-aligned チームに何を任せ、どう運営するかを扱う。
機能リストを渡す Feature Team ではなく、解くべき問題と望む成果を渡し、What と How を自律的に決めさせる Empowered Team が望ましい、というのが Cagan の主張である。
Product Discovery と Product Delivery を並行して走らせる Dual Track Agile、PM とデザイナーとエンジニアからなる三役(Trio)などの運用論を伴う。

6. 心理的安全性

心理的安全性は、Amy Edmondson が 1999年の論文で導入した概念である。
Harvard Business School の教授で、組織行動学の研究者である。

チームが対人リスクを取っても安全だという、メンバー間で共有された信念を指す。
質問、懸念、ミス、新しいアイデアを口にしても、罰せられたり屈辱を受けたりしないと互いに信じている状態である。

居心地の良さや人間関係の良好さと混同されやすいが、別物である。
心理的安全性は対人リスクの認知に関わる概念であり、意見の対立が起きない状態を意味しない。

Edmondson は、職場で「声を上げる」行為には常に潜在的損失があると示した。
4つの対人リスクとしてまとめられている。

質問する：「無知だと思われる」(Ignorant)。
ミスを認める、助けを求める：「無能だと思われる」(Incompetent)。
懸念や問題点を指摘する：「ネガティブだと思われる」(Negative)。
提案する、異論を述べる：「押しつけがましいと思われる」(Intrusive)。

合理的な個人の防衛戦略は、これらのリスクを避けるために黙ることである。
Edmondson はこれを self-protection や impression management と呼ぶ。

職場で安全性が低いと、各人が自分を守るために黙ることを選ぶ。
組織内で共有される情報には、各人の自己防衛による選別がかかる。
悪い知らせが上に届かず、弱い兆候や失敗、反対意見が共有されにくくなる。

Google の Project Aristotle(2012年から2016年)は、心理的安全性がビジネスの領域で広く知られるきっかけになった。
180のチームを調査した結果、メンバーの能力や構成だけではチームの成果を説明できなかった。
チーム内でどのような規範が共有されているかが重視され、その最初に挙げられたのが心理的安全性だった。

2023年に Edmondson は Right Kind of Wrong を出版し、自身の概念の誤用に対する整理を加えた。

心理的安全性は、居心地をよくするために仕事の基準を下げることではない。
高い基準を保ちながら、プレッシャーのある状況でも事実や懸念を伝えられる状態を指す。
心理的安全性と高い基準(Performance Standards)は両立する。

この考え方は、McChrystal が透明性と高い軍事基準を両立させようとしたことと重なる。
本稿では、心理的安全性を Shared Consciousness を支える条件のひとつとして位置づける。
ここで述べているのは概念上の接続であり、両者の直接の因果を主張するものではない。
情報共有の仕組みを整えても、懸念や異論が実際に共有されるとは限らない。
発言しやすさを左右する文化も必要になる。

7. Nonviolent Communication

Marshall Rosenberg が 1960年代から70年代にかけて体系化した発話フレームワークである。
Rosenberg は臨床心理学者で、人権運動の現場で対立解決の手法として NVC を発展させた。

4つのステップで構成される。

Observation(観察)：評価を含まず、何が起きたかを描写する。
Feeling(感情)：自分が今どう感じているかを述べる。
Need(ニーズ)：その感情の背後にある自分の必要や価値観を明らかにする。
Request(要望)：具体的かつ実行可能な要望を伝える。要望は相手が拒否できるものとして提示する。

中心にあるのは、観察と評価を分けることである。
Rosenberg は「観察と評価を混ぜると、相手は批判として受け取る」と繰り返し強調した。

コードレビューを例に取ると、観察と評価が混ざった発話と、分離された発話の差が見えやすい。

「このコード、雑だね」は評価から始まっており、コードへの評価なのか、書いた人への評価なのかが曖昧である。
NVC 化すると、たとえば次のようになる。
「この関数は400行ある(観察)。レビューしていて全体像を把握しきれず不安を感じる(感情)。保守しやすい状態を保ちたい(必要)。責務ごとに分ける案を一緒に検討できないだろうか(要望)」。

「いつも報告が遅い」は評価であり、行動を改善する手がかりを与えない。
NVC 化すると、「今日のミーティングで、初耳の障害が3件あった(観察)。対応が遅れることに焦りを感じた(感情)。事前に状況を把握できる状態にしたい(必要)。日次の共有チャンネルを試してみませんか(要望)」となる。

NVC 化された発話では、批判の焦点が「人」ではなく「起きていること」に移る。
評価を観察から切り離すことで、相手の人格ではなく、具体的な状況や行動を話題にしやすくなる。

心理的安全性を損ないにくい発話にするうえで、NVC から参照できる点は3つある。

第一に、観察と評価を分離する習慣である。
受け手の自衛反応は、評価そのものに対して起きやすい。
NVC は4ステップの最初に観察を置くことで、具体的に観察できる事実から話を始めやすくする。

第二に、感情とニーズを自分の側で明示する点である。
「君は遅い」(相手への評価)ではなく、「私は不安を感じる、判断のスピードを保ちたいから」のように、自分の内側を言語化する。
この話法は「I-message」と呼ばれることがあるが、それ自体は NVC 固有ではなく、Thomas Gordon の Parent Effectiveness Training(1970)に源流がある。
NVC では、観察から始める4ステップの枠組みの中に組み込まれて使われる。

第三に、Request と Demand の違いを意識する点である。
NVC の Request は、相手が断っても罰や非難で応じないことが条件である。
文法的に疑問形にすれば Request になるわけではなく、拒否を受け入れる準備が話し手の側にあるかどうかが分かれ目になる。

これらの習慣によって、発話する側が萎縮しにくくなり、受け取る側も攻撃されたと感じにくくなる可能性がある。

NVC には限界もある。
形式的に感じられること、権力の非対称性を扱わないこと、武器化される(「NVC で話してください」と相手を黙らせる用法)こと、緊急時には不向きであることが、よく指摘される批判点である。
万能の道具ではないが、平時のコードレビュー、設計、プロセス改善など、丁寧なやり取りができる場面では使いやすい。

NVC と同じく、対立や率直な発言を扱うフレームワークや運用はほかにもある。

Crucial Conversations(Patterson ら, 2002)：利害が大きく感情が高ぶる場面に特化したフレームワーク。
Radical Candor(Kim Scott, 2017)：「Care Personally かつ Challenge Directly」の2軸で整理した発話モデル。Google や Apple での経験を基盤としている。
Difficult Conversations(Stone, Patton, Heen, 1999)：Harvard 交渉学プロジェクトから派生した。「What happened」「Feelings」「Identity」の3層モデルで構成される。
Blameless Postmortem(Google SRE, 2010年代)：評価より事実の確認を優先し、個人攻撃を避ける運用である。NVC と同一ではないが、観察と非難を切り分ける点では近い。

8. 文化の三層

Edgar Schein が組織文化研究の基礎理論として提示したモデルである。
1985年初版の Organizational Culture and Leadership で体系化された。
組織文化を3つの層として捉える。

Artifacts(人工物)：スローガン、ポスター、行動規範文書、社内の什器、服装、儀式など。
目に見える表層であり、新入社員でも最初に気づける。

Espoused Values(掲げられた価値観)：「我々はこう振る舞うべき」と公式に語られる規範。
ミッションステートメント、バリュー、行動指針として明文化されることが多い。

Basic Assumptions(基本的前提)：言語化しなくても全員がそう判断する暗黙の共通認識。
組織が長年の経験を通じて学習し、無意識に共有するに至った前提である。

3層は別々に存在するのではなく、互いに関係している。
表層にスローガンや行動規範を掲げても、価値観として共有され、日々の判断の前提にならなければ文化としては定着しない。
基本的前提として共有された価値観は、新しく入った人の判断にも影響する。

人ではなく課題そのものに向けて議論する、という意味の企業バリュー「『こと』に向かう」を例にすると、3層の関係がわかりやすい。
バリューを掲げただけの段階では、人工物の層にとどまる。
社員が規範として認識し、議論のなかで使うようになれば、掲げられた価値観として共有されている。
厳しい指摘を受けたときにも「これは人ではなく『こと』に向けた指摘だ」と当然に受け止めるようになれば、基本的前提として定着している。

価値観が基本的前提として定着するには、具体的な行動を繰り返す必要がある。
リーダーが自ら実践し、フィードバックの場で繰り返し説明し、評価制度や入社時の学習内容にも組み込む。
バリューは、スローガンと日々の行動が一致して初めて、判断を支える仕組みになる。

9. 100人の壁

本稿では、組織が初期メンバー数人から数十人、そして100人前後へ伸びる過程で、文化や意思疎通の断絶が表面化する局面を「100人の壁」と呼ぶ。
Dunbar の数(およそ150)の議論と関連づけて語られることもあるが、100という値そのものに厳密な根拠があるわけではない。
以下は確立された理論ではなく、既存研究と筆者自身の体験を重ねて考えるための作業仮説である。

筆者は、人が増えると違うモチベーションの人が入ってくるために心理的安全性が失われる、という説明を耳にすることがあった。
筆者の経験にも一部は当てはまるが、人材の違いだけでは説明しきれない現象が残る。
動機の違う人が入ったことに加えて、安全性を支えていた構造上の条件も同時に弱くなった、と考える方が観察と合う。

筆者が経験した小規模組織では、明示的な安全装置がなくても心理的安全性が高く見えることがあった。
発話の対人リスクを高める構造条件が、まだ表面化していなかったためだと考えている。

組織の規模が大きくなると、少人数のころに暗黙に成り立っていた条件がまとめて弱くなる。
整理のために4つに分ける。

物理的近接性：少人数の時は全員が同じ空間にいて、会話が自然に共有されやすい。
規模が大きくなるにつれて物理的に分断される場面が増え、明示的な情報共有経路がないと知り得ない情報が出てくる。

共有された履歴：初期メンバーは創業期の苦労を共有しており、同じ物語の中にいる。
新規メンバーはその物語の外から入ってくる。

役割の重複：少人数の時は誰もが何でもやり、「自分の専門領域」という意識が薄い場面が多い。
規模が大きくなるにつれて専門特化が進み、自分のロールから外れた発言の心理的コストが上がっていく。

直接的な利害一致：少人数の時は事業の成否がそのまま個人の成否と一致しているケースが多い。
規模が大きくなるにつれて、給与で働く構成員の比率が増え、利害が間接化していく。

この4条件が弱くなると、Edmondson の4つの対人リスクが意識されやすくなる。
人数が増える局面でそれらが重なるため、安全性の感覚が急に変わったように見える。

原因を「人」だけに求めると、筆者が経験した範囲では説明が足りなくなる場面が多かった。
同じ人が、5人の組織と100人の組織では異なる行動を取る、という観察も繰り返してきた。
動機が同質であっても、構造が違えば発言コストが変わる、と整理する方が、観察と整合する。

この仮説では、100人の壁における心理的安全性の低下を次のように捉える。
近接、履歴、役割の重複、利害の一致といった暗黙の条件が弱くなる一方で、発言を奨励する制度、透明性、リーダーによる弱みの開示といった明示的な仕組みがまだ整っていない。
その移行期間に断絶が起きる。

「壁」と感じるのは、暗黙の機構が崩れる速度に、明示の機構の構築が追いつかないからだ、というのが筆者の見立てである。
人材の違いだけでは説明できない、組織設計の側に着目する余地がある。

この仮説に立てば、失われた暗黙の条件を明示的な仕組みで補うことになる。

物理的近接性の喪失には、定期的な全社同期会、公開された Slack チャンネル、横断的な勉強会が役立つ。
共有された履歴の喪失には、オンボーディングで創業時の経緯を伝えることや、行動規範の文書化が考えられる。
役割の重複の喪失には、クロスファンクショナルな取り組み、Enabling チーム、ジョブローテーションが考えられる。
直接的な利害一致の喪失には、ストックオプション、評価制度の透明性、バリューの明文化が考えられる。

特に役割が分化したあとの発言コストに対しては、第8節で取り上げた「『こと』に向かう」のような、組織全体で共有されるバリューが役立つことがある。
明文化されたバリューだけで4つの条件すべてが補えるわけではないが、明示的な安全装置を組み立てる手がかりにはなる。
こうしたバリューは、100人規模の断絶を経験した組織が、あとから明文化していくものの一例として読める。

10. 階層モデルとしての統合

これまでに扱ったフレームワークは、組織の異なる範囲を扱っている。
ひとつの階層モデルに並べると、互いの関係を整理できる。

市場とプロダクトチームのあいだでは、Build-Measure-Learn が学習の進め方を示す。
チームは市場や顧客の反応を測り、仮説を更新する。

チーム同士の関係では、Team Topologies がチームの境界、相互作用モード、認知負荷を扱う。
Team of Teams は、組織全体で情報を共有し、現場で判断するための運用原理を扱う。

個人やチームが環境を観察し、判断して行動する過程は、OODA Loop で整理できる。
Observe、Orient、Decide、Act は、個人にも組織にも当てはめられる。

いずれの範囲でも、必要な情報が共有され、適切な場所で判断されなければならない。
情報を共有する仕組みには、Team of Teams の O&I Brief や Team Topologies の Team API がある。
発話の質を捉える概念として、Edmondson の心理的安全性がある。
発話の方法は NVC が扱い、文化として根付いていく過程は Schein の3層モデルで説明できる。
これらは一続きの手順ではなく、組織内の情報共有を別々の角度から捉えるためのものである。

100人の壁は、この整理全体を組織の成長過程に当てたときに見える現象として読める。
それまで暗黙の調整で済んでいた個人、チーム、組織、市場のあいだに、明示的な仕組みが必要になる。
必要な仕組みと文化を同時に整えるのは難しく、その移行期間が「壁」として現れる。

この階層モデルを使うと、チームがうまく回らない原因を切り分けやすくなる。
個人の認知が遅いのか、チームと市場の学習が止まっているのか、チームの構造が崩れているのか、チーム間の情報の流れが詰まっているのか。
原因に応じて、参照すべきフレームワークも変わる。

各フレームワークに共通しているのは、フィードバックを受けて判断を更新し続けることである。
Complex 環境で組織が適応し続けるためには、各層で速いフィードバックループを維持し、そこで共有される情報の質を文化によって支える必要がある。
仕組みと文化が両方そろって初めて、組織は環境より速く学習できる。

冒頭で、AIエージェントを含む開発体制では、いままで通りの計画と分業が機能しにくくなったと書いた。
その背景には、環境の変化に合わせて目的、制約、優先順位を更新し、それを組織内で広く共有する必要が高まったことがある。
実装や試作の高速化は、この必要性をさらに強める。
AI が業務の文脈を参照できるように情報を整えていく流れは、人間の組織で情報を広く伝え、判断の前提をそろえることとどこか重なって見える。
ただし、人間の組織では前提を共有するだけでは足りない。
その前提に照らして異論を出せることと、前提をどう解釈するかまで文化として共有することが、これまで以上に必要になるのではないだろうか。

参考文献

Prev Entry