---
title: "学習する組織"
chapter: "14"
part: 2-knowledge-areas
status: revised
visibility: public
authors:
  - claude
reviewers: []
revision: 0.1
updated: 2026-05-19
related-skills: []
related-chapters: []
related-knowledge: []
---
# 学習する組織 — マーケティング・チームに学習プロセスを埋め込む

## なぜこのドキュメントを置くか

`marketing-structural-issues.md` で記述したとおり、マーケティングは構造的に「学習しないチーム」を生みやすい。マーケティングサイクルは単なる AI 協働の型ではなく、**組織学習を回すための OS** である。本書では、学習を組織に埋め込むための原則と実装上のヒントを記録する。

## 学習が起きない条件

以下が一つでも成立すると、組織学習は起きにくい:

- **前提が共有されていない**: 「マーケティング」「成果」「顧客」をチームが別の意味で使っている状態。個々のメンバーが「自分は事業のどの課題に効いているか」を答えられない状態。この状態では、振り返りも学びも全員が違うものを指しているため積み上がらない（詳細 `marketing-structural-issues.md` Section 0）
- **失敗が許容されない**: 失敗 = 評価への直接的な打撃。試すこと自体が抑制される
- **失敗の責任が個人化される**: 失敗から得た学びが組織知ではなく個人の汚点になる
- **成功の理由が言語化されない**: 成功した理由を構造化しないため、再現できない
- **新陳代謝がない**: 同じ人間が同じやり方で同じ判断をし続ける
- **外部化で学習機会を失う**: 「とりあえず外注」が組織内の判断経験を空洞化させる

## 学習が起きる条件

逆に、以下が揃うと組織学習は回り始める:

- **失敗できる小さな空間がある**: ロジックも予算も小さく、失敗してもプロダクト全体を毀損しない場が常設されている
- **失敗が組織知に変換される**: 失敗の理由・経緯・学びが `memory/workspaces/active/results/` のような構造化された場に書き戻される
- **成功も同じ粒度で言語化される**: 成功体験が暗黙知に閉じず、再現条件が記述される
- **新陳代謝が前提になっている**: 担当者の入れ替わりを前提に、引き継げる形で知見が残されている
- **判断と責任が外部化されない**: AI も外部業者も「判断の補助」として使い、最終判断は組織内に残す

## AI 時代の新しい責任外部化に抗う

2026 年以降、組織は新しい形の責任外部化に直面する。

> 「AI が言っているから、この施策を打ちました」

このフレーズが日常化するとき、判断はチームの誰の手にも残らない。これまでは個人の判断によってマーケティングの責任を負うという建前があったが、これからは AI に判断を委ねることでチームの誰もが責任を取らない状態が生まれうる。

**AI に委ねる時代に必要なのは、知識そのものではない**。知識に基づいた経験と、それらに基づく分析・判断である。これらを AI 任せにするのではなく、人間が新陳代謝しながら取り入れていく ── すなわち、**学習プロセスをチームに組み込まない限り、マーケティングを活かすことは難しい**。

## マーケティングサイクルは学習サイクルそのもの

マーケティングサイクルの各段階を、組織学習サイクルとして読み直すと以下のようになる:

| マーケティングサイクル段階 | 組織学習における役割 |
|-----------|--------------------|
| **観測・データ収集** | チーム内の情報・認識・課題を表に出す。サイロを解消し、共有された前提から議論を始める |
| **理解・分析する** | 何を理解しているか／していないかを実測する。分かっているふりを許さず、知の凸凹を可視化する |
| **再構築** | 既成の KPI・聖域・「ねばならない」を一旦再構築する。前提を組み替える余白を作る |
| **起動・実装する / 学ぶ** | 自社プロダクトに適合した目標を再構成し、実行・測定し、結果を次の 観測・データ収集に還流する |

サイクルを 1 周まわすたびに、組織は前回より少し賢くなっている ── これが達成できていない マーケティングサイクルは、機械的に手順を追っているだけで学習を生んでいない。

## 実装上のヒント

### 失敗できる空間の作り方

- **新規プロジェクトに小さなブランチを切る**: 既存の本流に影響しないスコープで試行する
- **「学習目的」と明示した実験予算を確保する**: 成果を出すための予算と分けて確保することで、失敗が評価減点にならない構造を作る
- **失敗の事後録を仕組みに組み込む**: `/learn` の「学び」セクションを、成功時にも失敗時にも必ず書く

### 経験を組織に残す書き戻し

- **`memory/workspaces/<slug>/results/`** に、検証された知見と失敗の理由を残す
- **`knowledge/marketing/case/`** に、転用可能な事例として一般化できる学びを残す（自社固有の数字は書かない）。プラットフォーム仕様の変化など、ツール文脈の知見は **`knowledge/marketing/tool/`** に残す
- **個人の頭の中にだけ残る暗黙知を許さない**: 担当者が抜けても再現できる粒度まで言語化する

### 新陳代謝を前提にした設計

- **役割の固定化を避ける**: 同じ人が同じスキルを毎回担当する状態を避ける
- **引き継ぎ可能性をテストする**: 半年ごとに「この workspace を別の担当者に渡せるか」を点検する
- **属人的な口伝を許さない**: 重要な判断は必ず文書化し、Slack の DM で完結させない

### 健全な AI 委譲

- **判断の境界を事前に決める**: AI に委ねるルーチン部分と、人間が必ず判断する部分を切り分ける
- **AI の出力を「叩き台」と扱う**: AI が出した提案をそのまま流さず、必ず 再構築（既成枠を再構築する問い直し）と 起動・実装する / 学ぶ（自社適合の判定）を経る
- **「AI が言ったから」を理由にしない**: AI の出力に依拠した判断であっても、判断責任は人間に帰属させる。`/learn` の差分セクションに「AI 提案のうち何を採用し、何を却下したか、なぜか」を書く

## 関連ドキュメント

- `knowledge/marketing/framework/marketing-cycle.md` — マーケティングサイクルの定義
- `knowledge/marketing/playbook/foundations/structural-issues.md` — 学習が起きにくい構造的背景
- `knowledge/marketing/playbook/knowledge-areas/org-capability/responsibility-design.md` — 責任の所在の設計
