S7：AIを中心としたチームを作る

人が増えるほど遅くなるのではなく、意思決定主体が増えるほど速くなる。

このスキルで手に入るもの

各専門分野のパートナーが揃い、全員が同一のOntologyを参照しながら自律的に動く体制の完成です。指示を出さなくても組織が動き、会議は情報共有ではなく意思決定だけに使える——そのシステムを設計します。

---

このスキルの核心：共有Ontologyで組織の知性を統合する

なぜフラット組織はOntologyを必要とするのか

複数人が意思決定に関わる組織では、情報の非対称性が最大のリスクになります。

階層型の組織では、情報はトップダウンで流れます。指示が明確な代わりに、現場の判断は制約されます。一方、フラットな組織では全員が自律して動けますが、全員が違うデータを見て動くと、判断がバラバラになり、組織としての力が出せません。

この問題を解決するのが、共有Ontologyです。

【ヒエラルキー型】

              ┌──────────┐
              │  経営者   │
              └─────┬─────┘
         ┌───────────┼───────────┐
    ┌────┴───┐   ┌────┴───┐   ┌────┴───┐
    │  部長A  │   │  部長B  │   │  部長C  │
    └────┬───┘   └────┬───┘   └────┬───┘
      担当者         担当者         担当者
      担当者         担当者         担当者

  ▶ 情報はトップダウン。承認なしには動けない。


【パートナー型（フラット）】

  ┌─────────┐  ┌─────────┐  ┌─────────┐  ┌─────────┐
  │ A（税務）│  │ B（法務）│  │ C（技術）│  │ D（制作）│
  └─────────┘  └─────────┘  └─────────┘  └─────────┘
        │              │              │              │
        └──────────────┴──────────────┴──────────────┘

  ▶ 全員が対等。上下関係なし。専門性で役割を分担。
  ▶ プロジェクトに応じて横断的に連携する。

共有Ontologyが解決すること

従来のフラット組織の問題：
→ 各自が別々の情報を持っている
→ 認識のズレが生じる
→ 会議で時間を使って情報を合わせる
→ それでも判断がブレる

共有Ontologyがある組織：
→ 全員が同一のデータを参照している
→ AIが同じデータから各人への提案を生成する
→ 会議は「情報共有」ではなく「意思決定」に使える
→ 判断の根拠が揃っているからズレが起きにくい

S1で個人のOntologyを構築するのと同じ発想を、組織全体に拡張します。個人のOntologyが「自分の頭の中の地図」なら、共有Ontologyは「チームの頭の中の地図」です。

フラット組織をさらに発展させると、中心に人ではなく**データ（Ontology）**を置いた構造になります。各パートナーはそれぞれが意思決定主体であり、共有Ontologyから必要な情報とAIの提案を受け取りながら自律的に動きます。

【Ontology中心のパートナー型】

    A（税務）      B（法務）      C（技術）
        ↕              ↕              ↕
  ┌─────────────────────────────────────┐
  │         共有Ontology（AI分析）        │
  └─────────────────────────────────────┘
        ↕              ↕              ↕
    D（制作）      E（財務）      自分（意思決定の中心）

  ▶ 全員が意思決定主体。同一のOntologyを参照し、AIが各パートナーへ最適な提案を生成
  ▶ 情報の非対称性がなくなり、全員が同じ地図で動ける

パートナーがまだいなくても、S7は設計できる

S7の習得に、すでに組織を持っている必要はありません。むしろ逆です。パーティション設計と権限の明文化は、最初のパートナーを迎える前に済ませておくべき準備です。組織ができてから慌てて設計すると、すでに混ざってしまったデータと曖昧な権限を後から分離することになり、何倍も大変になります。

そして、この仕組みは相手が1人でも機能します。S6で関係を持った外注先・税理士・あるいは家族——その1人を「最初のパートナー」と見立てて、権限ファイルを1枚書き、アクションログの共有を試す。それがS7の最小実装です。

---

方法論

STEP 1：生データとAI生成データをパーティションで分ける

複数名でOntologyを運用するとき、最初に設計しなければならないのが**データのパーティション（区画分け）**です。

これをやらないと何が起きるか。AIが編集したデータを別のAIが参照し、そのデータをさらに別のAIが編集し——という連鎖が起きます。誰も書いていない「AI同士が生成し合ったデータ」が組織の判断基準になっていく、最も避けるべき状態です。

原則：生データ（人間が書いたもの）とAI生成データは、必ず別のディレクトリに置く。

【各メンバーの個人ディレクトリ】（書き込み可：本人と本人のAIのみ）

  member-A/                ← パートナーAの個人Ontology
    ├── inbox/        生データ（音声メモ・走り書き）
    ├── ontology/     概念・人物・関係（本人が精査）
    └── actionlog/    行動・意思決定の記録

  member-B/ 、member-C/ …  ← 各パートナーが同構造で運用


【メインOntology】（読み取り専用：各メンバーディレクトリへの書き込み不可）

  main-ontology/
    ├── ontology/       各メンバーから統合された組織の知識
    ├── finance/        財務データのサマリー（S5と連携）
    ├── outsource/      外注案件の共有管理（S6と連携）
    └── research/       ロールマップ・市場リサーチ（S4と連携）

各メンバーはS1と同じ作業を自分のディレクトリで行います。メインOntologyはその結果を定期的に収集・統合しますが、各メンバーのディレクトリへの書き込みは行いません。 この一方向の情報フローが、データの信頼性を守ります。

各メンバーの個人ディレクトリ（生データ → 精査 → 個人Ontology）
                ↓ 読み取りのみ
           メインOntology（統合・分析・全体提案）
                ↓
          各パートナーへのAI提案（書き戻しはしない）

STEP 2：「従業員が増える」ではなく「意思決定主体が増える」と設計する

組織を大きくするとき、「人を増やす」という発想をやめます。代わりに問うべきは——「意思決定主体をどう増やすか」 です。

従業員は指示を受けて動きます。意思決定主体は自分のドメインで判断して動きます。この体制を「文化」ではなく「システム設計」から実現するために、以下の3つをパートナーごとに明確にします。

① 権限移譲の明確化

このシステムは組織構造としての指示出しを全くなしとすることを前提に設計します。誰かが誰かに「これをやって」と指示を出す場面を、設計段階から排除します。「横やり」は悪意からではなく権限の境界が曖昧なことから生まれます。境界が全員に明確であれば、余計な介入は起きません。

## 山田さん（税務パートナー）

### 自律的に判断できること（他メンバーの確認不要）
- 税務上のリスク評価・対応
- 節税スキームの選択・実行
- 税務署への申告・対応全般

### メインOntologyへ報告するだけでよいこと
- 上記の判断結果（事後報告・記録のみ）

### 例外的に確認が必要なこと
- 事業の大きな方針転換に伴う税務設計の変更
- 他パートナーの領域をまたぐ判断が生じた場合のみ

### 他メンバーが介入してはいけないこと
- 上記「自律的に判断できること」の領域全般

② 情報のオープン化とフィードバックループ

各パートナーは自分のOntologyを常にオープンな状態に保ちます。メインOntologyが定期的に収集し、他のパートナーへの提案に反映されます。このサイクルが回り続けることで、組織全体の判断精度が上がっていきます。

③ 意思決定の記録

S1の actionlog/ と同じ仕組みを各パートナーが持ちます。「何を判断し、どんな結果になったか」を記録し続けることが、個人のOntologyを育て、組織の学習速度を上げます。

STEP 3：現代ビジネスに最適化した会議の実現（アクションログの共有）

会議の最適化は、現代ビジネスにおいてセンターピンに位置する機能と言っていいほど重要です。組織が大きくなるほど会議の重要性は高まりますが、裏を返せば、会議をAX（AI Transformation）できなければ、無駄な時間と無駄なコストをそのまま増大させていくだけになります。会議の数が増えるほど組織が遅くなる——この構造的な問題を、アクションログの共有とAI解析によって根本から解決します。

各メンバーが actionlog/ に記録し続けるデータ——何を行い、何を考えているか、何に不足を感じていて、どこに助けを必要としているか——をメインOntologyが収集し、共通のAIが全員分を横断的に解析します。メンバー同士が直接コミュニケーションを取らなくても、AIが相互補助を自動的に提案できます。

各メンバーのactionlog/（自律的に記録）
         ↓ 定期収集
    メインOntology（横断解析）
         ↓
  AIが相互補助アクションを提案
  ・AさんはBさんの○○に協力できる
  ・CさんとDさんは△△を共有すべき
  ・今週のチーム全体のボトルネックは□□
         ↓
    MTGで確認・意思決定・合意形成

この体制では、MTGの役割が根本的に変わります。

従来のMTG：
  各自が口頭で近況報告 → 情報を合わせる → 何となく決める

アクションログ共有後のMTG：
  事前にAIが全員のログを解析
        ↓
  相互補助アクションの提案リストを全員が確認
        ↓
  MTGでは「提案に同意するか」「優先順位をどうするか」だけを決める

情報共有はAIが済ませます。人間が集まる時間は、判断と合意だけに使います。

（MTG前のAI依頼例）

「main-ontology/ の全メンバーのactionlog/ を読んでください。
今週のアクション記録を横断的に解析し、以下を出力してください：

1. 各メンバーの現在の状況サマリー（1人3行以内）
2. メンバー間で相互補助できるアクションの提案
3. チーム全体のボトルネックと優先対応事項
4. 今週のMTGで意思決定が必要な事項のリスト」

---

S7が目指す組織のカルチャー

S7の方法論を貫く根幹は、技術や仕組みではなくカルチャーの設計にあります。会社の運営で最も重要なのは、参加する各メンバーそれぞれの意思決定が尊重される文化を作ることです。

アクションログの共有と共有Ontologyによって、各メンバーの動きは透明化されます。透明性は監視ではありません——「この人がどう動いているか」が見えることで、その判断を信頼できる土壌が生まれます。見えないから疑う。見えるから信頼できる。この順序で組織の信頼は作られます。

もしこの体制が作れなければ、どうなるか。現代ビジネスのスピードについていくためには、「チームを持つより、一人＋AIのほうが速い」という結論になります。そう感じさせる組織は、すでに機能していません。

AIにより最適化された意思決定補助があることで、各メンバーが自らの価値観と考えで自由に動き、働いた分だけ適切に評価される組織——それぞれの意思決定が尊重され、信頼がシステムの中に設計されている組織。人が増えるほど遅くなるのではなく、意思決定主体が増えるほど速くなる。それがこのフレームワークの到達点です。

---

達成の目安

S7の達成は2段階で確認します。第1段階は、パートナーがいなくても完了できます。 設計図が先にあるから、人が加わった瞬間にシステムが動き始めます。

第1段階：体制の設計（一人でも完了できる）

• 個人ディレクトリとメインOntologyのパーティション構成図を作成した
• 権限ファイル（自律的に判断できること・報告だけでよいこと・例外）のテンプレートを、最初のパートナーを想定して1枚書いた
• 生データとAI生成データを別ディレクトリに分ける原則を、自分のmyprojectで実践している

第2段階：チームでの運用（パートナーが加わってから）

• 各パートナーの権限範囲が人物ファイルに明文化されている
• 各パートナーが actionlog/ で意思決定を記録している
• MTG前にAIでアクションログを横断解析し、相互補助提案を生成した記録がある
• 自分がボトルネックにならない業務の流れが完成している

関連スキル

• 前提となる → S6：スタッフ管理をAIで行う
• この軸の完成で → Milestone 2 へ