組織図ではなく、顧客価値が流れる単位でチーム境界と相互作用を設計する。調整コストは見えない原価である。

1. 中心命題と、よくある誤読

中心命題と、よくある誤読

本書はストリームアラインド、プラットフォーム、イネイブリング、コンプリケイテッド・サブシステムの四チーム型と、三つの相互作用モードを提示する。ソフトウェア組織論だが、顧客価値の流れと認知負荷を設計する考えはマーケティング組織にも応用できる。 中心にあるのは、四つのチーム型と三つの相互作用モードで価値の流れと認知負荷を最適化するという考えである。フレームワークの名前を覚えるより、どの前提を変える理論なのかを捉えたい。

サービスブループリントと組み合わせると、顧客接点の裏で何チームを横断するかが見える。離脱画面だけでなく、権限待ちやデータ引継ぎを摩擦として扱える。 したがって「顧客価値の流れに沿って長寿命チームを置く」は標語ではなく、対象顧客、観察する行動、比較する代替を明記して使う必要がある。

2. 顧客状況・行動障壁・便益競合で読む

部署別の仕事量でなく顧客が価値を受け取るまでの待ちと引継ぎを観察する。

ローカルのマーケティング知見へ接続すると、属性分類で終わらず、必要が生まれた出来事、達成したい進歩、現在の代替、最後の障壁まで分解できる。

プラットフォームは利用者チームの認知負荷を下げる商品であり、強制的な共通基盤ではない。内部顧客の採用率、セルフサービス率、待ち時間で価値を測る。 同業他社だけでなく、内製、先送り、別カテゴリー、何もしないことも便益競合に含めると、本書を自社へ移せる条件と移せない条件が明確になる。

3. 企業事例へ当てはめる

Amazon：二枚のピザ型チームと内部プラットフォームの経済性を見る。

メルカリ：購入・出品ストリームと共通基盤の責任を分ける。サイバーエージェント：メディア・広告・AI基盤間の依存を読む。ここで見るべきなのは企業名の華やかさではなく、本書の因果がどの顧客状況と事業KPIで成立するかである。

事例を模倣するときは、顧客構成、単価、購買頻度、チャネル、組織能力をそろえて比較する。「チームの認知負荷を超える責任を持たせない」が別企業でも再現するかを、小さな対象と期限を決めて検証する。

4. KPI・PL・BS・CFへの接続

リードタイム、障害復旧、重複開発、人件費、基盤投資の回収へ接続する。

PLでは人数ではなく価値提供単位当たりの総工数を、BS/CFでは共通基盤への先行投資と再利用回数を見る。組織変更の成果を短期人員削減だけで判定しない。 先行指標が顧客数、頻度、単価、継続率、粗利のどこを通り、最終的に売上、営業利益、運転資本、営業CFへ届くかを一続きで置く。

5. 適用限界と反証条件

四分類を組織図へ貼るだけでは機能しない。

顧客価値の流れ、変更頻度、依存、認知負荷を継続的に観察して境界を更新する必要がある。 また、依存関係が増えるほど会議と待ちが膨らみ、見えない固定費が粗利を圧迫する。本書の理論を万能解として扱わず、成立条件と失敗条件をセットで残したい。

実務では「協働・X-as-a-Service・促進を目的に応じて使い分ける」を一つの仮説にし、主要KPI、品質ガードレール、停止条件を各一つ置く。期待した行動差が出ない、または粗利・継続・CFが悪化するなら、実装の問題だけでなく本書から借りた前提そのものを更新する。