公式スキル · マネジメント

チーム憲章

v1.0.0・2026年11月4日更新

ミッション、仕える相手、受け持つことと受け持たないこと、役割、働き方の約束、定例、決め方、指標をまとめたチーム憲章の草案をつくる。

Claude・ChatGPT・コーディング用の AI で使えます。TeamとBusiness では、Pod に入れた公式スキルが改善のたびに自動で最新版になります。

使う場面

• チームができる、統合される、新しいリードを迎える
• 依頼が違うチームに届き、だれが何を受け持つのかだれもわからない

AI に渡すもの

• チームのメンバーとマネージャー
• チームが期待されている成果
• 今の働き方

できあがるもの

ミッション、担当範囲の境界、測れる役割、働き方の約束、決め方のルール、指標をまとめたチーム憲章。

手順

1. ミッションを1文で書く だれに仕え、その人たちにとって何が変わるのか。「新しいお客様が、登録から1日以内に最初のレポートにたどり着けるようにする」。成果のない価値観の言葉は使わない。
2. 仕える相手を挙げる 社内と社外を、優先順に並べる。2つの相手の要望がぶつかったら、この順でどちらを取るかを決める。
3. 境界を引く チームが受け持つもの（システム、業務の流れ、決定）と受け持たないものを挙げ、受け持たないものには担当のチームを書く。「うちではない」項目にはすべて担当を書くか、「担当不明」と印をつける。
4. 役割を決める 繰り返し発生する役割（リード、当番、進行役、ほかのチームからの依頼に答える人）に名前を割り当てる。肩書きではなく、測れる形で書く。「#team-requests に1営業日以内に答える」。
5. 働き方の約束を書く 具体的な決まりを5〜8個。勤務時間とタイムゾーン、チャンネルごとの返信の目安、フィードバックの伝え方、会議を入れない時間、対立の持ち出し方。どれもメンバーが破りうるものにして、守れているか確かめられるようにする。
6. 定例とチャンネルを決める 会議ごとに目的、頻度、長さ、出る人を書き、目的のない会議はなくす。チャンネルごとに何を投稿するかを書く。会議より非同期のほうがよい場面も書く。
7. 意思決定のしかたを決める 決定の種類ごとの既定の方法（一人が相談したうえで決める、チームで投票する、全員が支える必要のある少数の決定は合意で）、最終的にだれが決めるか、合意できないときの代わりの方法。エスカレーションの経路も足す。
8. 指標を2〜4個選ぶ チームが何で評価されるか。わかれば今の値と目標を書く。憲章を見直す時期も書く。このスキルの既定は四半期ごとと、メンバーの加入・離脱のたび。

SKILL.md の全文

AI が読むファイルそのものです。 ダウンロード

---
name: team-charter
description: チーム憲章（チームチャーター）の草案をつくる。ミッション、チームが仕える相手、受け持つことと受け持たないこと、役割、働き方の約束、定例と連絡のチャンネル、意思決定とエスカレーションのしかた、チームを評価する指標をまとめる。マネージャーや創業者が新しいチームをつくるとき、チームを分割・統合するとき、新しいリードを迎えるとき、「これはだれの担当か」の混乱を解きたいとき、チーム憲章、チームのミッション、働き方の約束を頼まれたときに使う。
---

# チーム憲章

チーム憲章は、新しいメンバーや隣のチームが最初の週に聞く問いに答える。このチームは何のためにあるのか、何を受け持つのか、どう働くのか、どう決めるのか。ノートルダム大学メンドーサ・ビジネススクールのテンプレートは、目的、意思決定の進め方、役割と責任、働き方の約束の4つを主な要素に挙げている。このスキルでは、担当範囲の境界と指標を足す。スタートアップのチームがいちばん時間を失うのは「これはだれの担当か」だからだ。

## 使う場面

- 新しいチームができる、2つのチームが統合・分割される、新しいマネージャーが引き継ぐ。
- 依頼が違うチームに届き続ける、または2つのチームが同じものを受け持っていると思っている。
- 人を増やす前に、チームの働き方を書き残しておきたい。
- 一つのプロジェクトの計画（project-kickoff-brief を使う）や、一人に任せる仕事（delegation-brief を使う）には使わない。

## 用意するもの

- チームの名前、メンバー、マネージャー。
- チームが何を、だれのために達成することを期待されているか。
- 今していることと、ほかのチームがこのチームに期待していること。
- 今の働き方：会議、チャンネル、ツール。わからなければ既定の案を出し、「[案]」と書く。

## 手順

1. **ミッションを1文で書く。** だれに仕え、その人たちにとって何が変わるのか。「新しいお客様が、登録から1日以内に最初のレポートにたどり着けるようにする」。成果のない価値観の言葉は使わない。
2. **仕える相手を挙げる。** 社内と社外を、優先順に並べる。2つの相手の要望がぶつかったら、この順でどちらを取るかを決める。
3. **境界を引く。** チームが受け持つもの（システム、業務の流れ、決定）と受け持たないものを挙げ、受け持たないものには担当のチームを書く。「うちではない」項目にはすべて担当を書くか、「担当不明」と印をつける。
4. **役割を決める。** 繰り返し発生する役割（リード、当番、進行役、ほかのチームからの依頼に答える人）に名前を割り当てる。肩書きではなく、測れる形で書く。「#team-requests に1営業日以内に答える」。
5. **働き方の約束を書く。** 具体的な決まりを5〜8個。勤務時間とタイムゾーン、チャンネルごとの返信の目安、フィードバックの伝え方、会議を入れない時間、対立の持ち出し方。どれもメンバーが破りうるものにして、守れているか確かめられるようにする。
6. **定例とチャンネルを決める。** 会議ごとに目的、頻度、長さ、出る人を書き、目的のない会議はなくす。チャンネルごとに何を投稿するかを書く。会議より非同期のほうがよい場面も書く。
7. **意思決定のしかたを決める。** 決定の種類ごとの既定の方法（一人が相談したうえで決める、チームで投票する、全員が支える必要のある少数の決定は合意で）、最終的にだれが決めるか、合意できないときの代わりの方法。エスカレーションの経路も足す。
8. **指標を2〜4個選ぶ。** チームが何で評価されるか。わかれば今の値と目標を書く。憲章を見直す時期も書く。このスキルの既定は四半期ごとと、メンバーの加入・離脱のたび。

## 出力の形式

```markdown
# [チーム名]のチーム憲章
**メンバー：** [名前、役割] · **マネージャー：** [名前] · **最終見直し：** [日付]

## ミッション
[1文：だれに仕え、その人たちにとって何が変わるか]

## 仕える相手（優先順）
1. [相手] — [このチームに求めること]

## 受け持つこと
- [システム / 業務の流れ / 決定]

## 受け持たないこと
| 領域 | 担当 |
|---|---|
| [領域] | [チーム、または「担当不明」] |

## 役割
| 役割 | 担当者 | 責任（測れる形で） |
|---|---|---|

## 働き方の約束
1. [具体的で確かめられる決まり]

## 定例とチャンネル
| 会議 / チャンネル | 目的 | 頻度 / 使い方 | 出る人 |
|---|---|---|---|

## 決め方
- [決定の種類] → [方法]、最終的に決める人：[名前]
- 合意できないとき：[代わりの方法]
- エスカレーション先：[名前]、[条件]のとき

## 指標
| 指標 | 今 | 目標 |
|---|---|---|

## 見直し
次回の見直し：[日付] · メンバーの加入・離脱のときにも見直す。
```

## 例

**入力：** 「新しいライフサイクルチーム。三浦（リード）、城田（メールマーケター）、園田（データアナリスト）。役目はトライアルを有料に転換させること。今はオンボーディングメールとナーチャリングのキャンペーンを送っている。アプリ内のオンボーディングはプロダクトチームの担当。営業からときどき単発の一斉メールを頼まれる。フルリモートで、東京とシンガポール。トライアルから有料への転換率は11%。」

**出力：**

```markdown
# ライフサイクルチームのチーム憲章
**メンバー：** 三浦（リード）、城田（メールマーケター）、園田（データアナリスト） · **マネージャー：** 三浦 · **最終見直し：** 11月4日（水）

## ミッション
トライアルの登録者が製品の外で受け取るメッセージを通じて、有料のお客様になる人を増やす。

## 仕える相手（優先順）
1. トライアルのユーザー — 適切な段階で適切なメッセージを受け取る
2. 営業 — フォローすべき、見込みの高いトライアルを受け取る
3. プロダクト — トライアルがどこで離脱するかのデータを受け取る

## 受け持つこと
- オンボーディングとナーチャリングのメールのシーケンス
- トライアル段階のセグメント分けとレポート
- トライアルユーザーへのメールの頻度の決定

## 受け持たないこと
| 領域 | 担当 |
|---|---|
| アプリ内のオンボーディング | プロダクト |
| 営業の単発の一斉メール | 営業（このチームは送る時期の助言だけ） |
| 購入後のお客様向けニュースレター | 担当不明 |

## 役割
| 役割 | 担当者 | 責任（測れる形で） |
|---|---|---|
| リード | 三浦 | 優先順位を決める。トライアル全員への配信を最終的に決める |
| 依頼の窓口 | 城田 | #lifecycle-requests に1営業日以内に答える |
| レポート | 園田 | 毎週月曜12時（日本時間）までにトライアルのファネルのレポートを出す |

## 働き方の約束
1. 全員がそろうコアタイムは日本時間13時〜17時。会議はこの時間帯だけに入れる。
2. Slackは4営業時間以内、メールは1営業日以内に返す。
3. 1,000人を超える配信は、必ずもう一人が確認する。
4. 意見が割れたら長いスレッドではなく、15分の通話で話す。
5. フィードバックは、まず1対1で、できごとから1週間以内に伝える。

## 定例とチャンネル
| 会議 / チャンネル | 目的 | 頻度 / 使い方 | 出る人 |
|---|---|---|---|
| 計画 | その週の実験を選ぶ | 月曜、30分 | 全員 |
| ファネルの振り返り | 数字を読み、変更を決める | 木曜、30分 | 全員 |
| #lifecycle-requests | ほかのチームからの依頼 | 非同期 | 城田が仕分ける |

## 決め方
- 文面と送る時期 → チームに相談したうえで城田が決める
- トライアル全員向けのシーケンスの変更 → 園田のデータを確かめたうえで三浦が決める
- 合意できないとき：三浦が2営業日以内に決める
- エスカレーション先：グロース責任者、ほかのチームと担当範囲でもめたとき

## 指標
| 指標 | 今 | 目標 |
|---|---|---|
| トライアルから有料への転換率 | 11% | [案: 第1四半期末までに14%] |
| トライアル向けメールの配信停止率 | [要確認: ベースライン] | 1回の配信あたり0.5%未満 |

## 見直し
次回の見直し：2月3日（水） · メンバーの加入・離脱のときにも見直す。
```

## 送る前のチェック

- [ ] ミッションが1文で、だれに仕えるかが書いてある。
- [ ] 「受け持たないこと」のすべてに担当が書いてあるか、「担当不明」とある。
- [ ] どの働き方の約束も、破られたときに気づけるほど具体的である。
- [ ] 決め方に、最終的にだれが決めるかと、合意できないときの代わりの方法が書いてある。
- [ ] 指標に今の値があるか、これから測ると書いてある。入力にない目標には「[案]」とついている。

## よくある失敗

- 価値観の言葉だけでミッションをつくる（「卓越、当事者意識」）。だれに仕え、何が変わるかを書く。
- 受け持つことだけを挙げる。摩擦のほとんどは「受け持たないこと」の一覧で防げる。
- どの決定も合意で決めようとする。合意は、全員が支える必要のある少数の決定にとっておく。

チームで使う

AI Skill Pod に追加すると、業務委託の方も含めてチーム全員が、自分の AI から同じ版を使えます。 AI スキルをチームで共有する方法を読む

チームのPodに追加

変更履歴

• v1.0.0 · 2026年11月4日 · First release.