公式スキル · 業務管理・総務

プロジェクトのキックオフ資料

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

目的、成功の指標一つ、やること・やらないこと、マイルストーン、簡易RACIの表、担当つきのリスク、連絡のしかたをまとめた1枚のキックオフ資料を書く。

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

使う場面

• プロジェクト、ローンチ、顧客案件が始まり、全員で見る1枚が要る
• 動いているプロジェクトで範囲やだれが決めるかについて意見が割れている

AI に渡すもの

• 目的と、なぜ今それが大事か
• 目標の日付
• 関わる人と役割
• わかっている制約と決定事項（任意）

できあがるもの

目的、成功の指標、範囲の表、マイルストーン、簡易RACIの役割、リスク、連絡の計画をまとめた1枚のMarkdownの資料。

手順

1. 目的を1〜2文で書く 何が変わるのか、なぜ今それが大事なのかを書く。Asanaのキックオフのガイドは、「何を目指していて、この仕事がなぜ大事なのか」をそろえることを、キックオフでいちばん大事な部分としている。
2. 成功の指標を一つ選ぶ 数字と日付（「6月30日までに40社を新プランに移す」）か、だれでも確かめられる「はい・いいえ」で判定できる基準。Atlassianのキックオフのプレイブックは、こうした基準を「『完了』の共通の定義」と呼んでいる。このスキルの既定は、主要な指標一つと、多くて2つのガードレール（悪化してはいけないこと）。
3. 範囲を、やることとやらないことに分ける やることを3〜6個、やらないことを3個以上挙げる。やらないことは、途中でだれかが言い出しそうなもの。早めに名前をつけておくことが、範囲が膨らむのを防ぐ方法になる。はっきりしない項目は、やることではなく未決事項に入れる。
4. マイルストーンを3〜6個決める どれも日付と担当のある、確かめられる完成物にする（「料金ページをステージング環境に公開」）。作業（「料金ページに取り組む」）にはしない。最後のマイルストーンは、成功の指標の日付にする。
5. 簡易RACIの表を埋める 作業の流れごとに1行。R（実行責任者）は作業をする人、A（最終責任者）は承認して結果に責任を持つ人、C（協議先）は次へ進む前に確認する人、I（報告先）は進み具合を知らされる人。AsanaのRACIのガイドは「一つのタスクにAは一人だけにすべき」としている。このスキルの既定では、プロジェクト全体にも最終責任者を一人置き、資料の冒頭に名前を書く。
6. 主なリスクを3〜5個挙げる それぞれに、何が起こりうるか、起こりやすさ（高・中・低）、今やること、担当一人を書く。手早く見つけるには、Atlassianのプレモーテムを使う。チームが黙って起こりうる失敗を書き出し、いちばん大きな脅威に投票し、上位のリスクごとに担当つきの対策を決める。担当のいないリスクは、計画ではなくただの心配である。
7. 連絡のしかたを書く 日々のやりとりの場所（チャンネル）、進み具合の共有方法（週1回の文章での報告、その曜日と書く人）、集まる日、決定事項を書き残す場所。Asanaのキックオフのガイドは、これをキックオフの標準の項目に挙げている。
8. 未決事項と決定事項を挙げる 未決事項には担当と期限をつける。すでに決まったことは1行ずつ書き、キックオフで蒸し返さないようにする。

SKILL.md の全文

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

---
name: project-kickoff-brief
description: 目的とざっくりしたメモから、1枚のプロジェクトのキックオフ資料を書く。目的とその理由、成功の指標一つ、やること・やらないこと、日付つきのマイルストーン、最終責任者を一人に決めた簡易RACIの役割表、担当つきの主なリスク、チームの連絡のしかたをまとめる。プロジェクトを始めるとき、キックオフ資料、プロジェクト憲章、プロジェクト概要書を頼まれたとき、作業の前にだれが何をするか合意したいときに使う。
---

# プロジェクトのキックオフ資料

キックオフ資料は、作業を始める前に、プロジェクトがなぜあるのか、何をもって「完了」とするのか、だれが何を受け持つのかを全員でそろえるためのものだ。1枚に収める。今月の動きを変えないことは、リンク先の資料に回す。

## 使う場面

- 新しいプロジェクト、ローンチ、移行、顧客案件が始まり、全員で見る1枚が要る。
- 「キックオフ資料」「プロジェクト憲章」「プロジェクトの1枚もの」「キックオフ会議の事前資料」を頼まれた。
- すでに動いているプロジェクトで、範囲やだれが決めるかについて意見が割れている。仕切り直しのために資料を書く。
- 製品仕様書や要件定義書には使わない。製品が何をするかはPRDで書く。この資料は、プロジェクトをどう進めるかを扱う。

## 用意するもの

- 目的と、なぜ今それが大事か。なければ一度だけ聞く。「これが終わると、事業やお客様にとって何が変わりますか」。
- 期限や目標の日付。なければ「[日付未定]」と書き、未決事項の最初に挙げる。
- 関わる人とその役割。役割がわからなければ名前を並べ、RACIの表に「[案。キックオフで確認]」と書く。
- 任意：予算、わかっている制約、関連するプロジェクト、すでに決まっていること。

## 手順

1. **目的を1〜2文で書く。** 何が変わるのか、なぜ今それが大事なのかを書く。Asanaのキックオフのガイドは、「何を目指していて、この仕事がなぜ大事なのか」をそろえることを、キックオフでいちばん大事な部分としている。
2. **成功の指標を一つ選ぶ。** 数字と日付（「6月30日までに40社を新プランに移す」）か、だれでも確かめられる「はい・いいえ」で判定できる基準。Atlassianのキックオフのプレイブックは、こうした基準を「『完了』の共通の定義」と呼んでいる。このスキルの既定は、主要な指標一つと、多くて2つのガードレール（悪化してはいけないこと）。
3. **範囲を、やることとやらないことに分ける。** やることを3〜6個、やらないことを3個以上挙げる。やらないことは、途中でだれかが言い出しそうなもの。早めに名前をつけておくことが、範囲が膨らむのを防ぐ方法になる。はっきりしない項目は、やることではなく未決事項に入れる。
4. **マイルストーンを3〜6個決める。** どれも日付と担当のある、確かめられる完成物にする（「料金ページをステージング環境に公開」）。作業（「料金ページに取り組む」）にはしない。最後のマイルストーンは、成功の指標の日付にする。
5. **簡易RACIの表を埋める。** 作業の流れごとに1行。R（実行責任者）は作業をする人、A（最終責任者）は承認して結果に責任を持つ人、C（協議先）は次へ進む前に確認する人、I（報告先）は進み具合を知らされる人。AsanaのRACIのガイドは「一つのタスクにAは一人だけにすべき」としている。このスキルの既定では、プロジェクト全体にも最終責任者を一人置き、資料の冒頭に名前を書く。
6. **主なリスクを3〜5個挙げる。** それぞれに、何が起こりうるか、起こりやすさ（高・中・低）、今やること、担当一人を書く。手早く見つけるには、Atlassianのプレモーテムを使う。チームが黙って起こりうる失敗を書き出し、いちばん大きな脅威に投票し、上位のリスクごとに担当つきの対策を決める。担当のいないリスクは、計画ではなくただの心配である。
7. **連絡のしかたを書く。** 日々のやりとりの場所（チャンネル）、進み具合の共有方法（週1回の文章での報告、その曜日と書く人）、集まる日、決定事項を書き残す場所。Asanaのキックオフのガイドは、これをキックオフの標準の項目に挙げている。
8. **未決事項と決定事項を挙げる。** 未決事項には担当と期限をつける。すでに決まったことは1行ずつ書き、キックオフで蒸し返さないようにする。

## 出力の形式

```markdown
# [プロジェクト名] — キックオフ資料

**最終責任者：** [一人の名前] · **開始：** [日付] · **目標の日付：** [日付、または「日付未定」]

## 目的
[1〜2文：何が、だれにとって変わるのか。なぜ今か。]

## 成功の指標
- **主要：** [数字と日付、または「はい・いいえ」の基準]
- **ガードレール：** [悪化してはいけないこと。なければ削る]

## 範囲
| やること | やらないこと |
|---|---|
| [項目] | [項目] |

## マイルストーン
| マイルストーン（完成物） | 担当 | 日付 |
|---|---|---|
| [マイルストーン] | [名前] | [日付] |

## 役割（簡易RACI）
| 作業の流れ | 実行（R） | 最終責任（A） | 協議（C） | 報告（I） |
|---|---|---|---|---|
| [作業の流れ] | [名前] | [一人の名前] | [名前] | [名前またはグループ] |

## リスク
| リスク | 起こりやすさ | 今やること | 担当 |
|---|---|---|---|
| [リスク] | [高/中/低] | [対策] | [名前] |

## 連絡のしかた
- **日々のやりとり：** [チャンネル]
- **進み具合：** [文章での報告、曜日、書く人]
- **会議：** [どの会議を、どのくらいの頻度で]
- **決定事項の記録先：** [場所]

## 決定事項
- [決定事項を1行で]

## 未決事項
- [問い] — [担当]、[期限]まで
```

## 例

**入力：** 「稼働中の顧客120社を、古い請求ツール（ビルワイズ）からStripeに移す。キックオフは4月7日、ビルワイズは6月30日に解約。責任者は田村、連携の実装は森、顧客へのメールは石井、経理の吉田が新しい請求書のひな形を5月1日までに承認する必要がある。社長の高橋は、7月1日の価格改定の前に終わらせたい。森の計画：4月24日までに社内のテスト用アカウント5件がStripeのテストモードで正しく請求されること、6月12日までに全顧客を本番に移すこと。石井は5月15日までに案内を送り、各社の移行の1週間前にリマインドを送り、上位20社には電話する。やらないこと：解約済みの顧客の履歴、セルフサービスの請求ポータル、会計システムの変更。心配：登録済みのカードが移せないかもしれない。切り替えの月に二重に請求されるかもしれない。決済の失敗が増えてはいけない。やりとりは #billing-migration、田村が金曜に報告を書き、火曜に20分集まる。決定事項はプロジェクトの資料に書く。移行中は価格を変えないことは決定済み。吉田は、解約後1か月ビルワイズを閲覧のみで残すかを知りたい。」

**出力：**

```markdown
# Stripeへの請求移行 — キックオフ資料

**最終責任者：** 田村 · **開始：** 4月7日（火） · **目標の日付：** 6月30日（火）

## 目的
7月1日の価格改定の前に、全顧客をビルワイズからStripeに移す。新しい価格を一つのシステムで始め、ビルワイズを解約できるようにする。

## 成功の指標
- **主要：** 6月30日までに、稼働中の顧客120社のうち120社がStripeで請求されている。
- **ガードレール：** どの月も、二重請求や請求漏れの顧客がいない。決済の失敗が今の月間の水準以下にとどまる。

## 範囲
| やること | やらないこと |
|---|---|
| 稼働中の契約と登録済みカードの移行 | 価格の変更（決定済み：移行中は変えない） |
| 経理が承認した新しい請求書のひな形 | 解約済みの顧客の履歴の移行 |
| 移行の前後の顧客へのメール | 新しいセルフサービスの請求ポータル |
| ビルワイズの解約 | 会計システムの変更 |

## マイルストーン
| マイルストーン（完成物） | 担当 | 日付 |
|---|---|---|
| Stripeのテストモードで社内アカウント5件が正しく請求される | 森 | 4月24日（金） |
| 請求書のひな形を承認 | 吉田 | 5月1日（金） |
| 顧客への案内メールを送信 | 石井 | 5月15日（金） |
| 120社すべてがStripeで本番稼働 | 森 | 6月12日（金） |
| ビルワイズを解約 | 田村 | 6月30日（火） |

## 役割（簡易RACI）
| 作業の流れ | 実行（R） | 最終責任（A） | 協議（C） | 報告（I） |
|---|---|---|---|---|
| 連携とデータの移行 | 森 | 田村 | 吉田 | 高橋 |
| 請求書 | 森 | 吉田 | 田村 | 石井 |
| 顧客へのメール | 石井 | 田村 | 吉田 | 高橋 |

## リスク
| リスク | 起こりやすさ | 今やること | 担当 |
|---|---|---|---|
| 登録済みのカードが移せず、顧客が入力し直すことになる | 中 | ビルワイズのサポートに、Stripeへのカードの書き出しに対応しているかを今週聞く | 森 |
| 切り替えの月に、両方のシステムで請求される顧客が出る | 中 | Stripeで始めた当日に、その社のビルワイズの契約を止める。毎日チェックリストで確かめる | 森 |
| 顧客が案内を読まず、変更に気づかない | 高 | 5月15日までに案内を送り、各社の移行の1週間前にリマインドを送る。上位20社には石井が電話する | 石井 |

## 連絡のしかた
- **日々のやりとり：** #billing-migration
- **進み具合：** 毎週金曜に田村が文章で報告
- **会議：** 毎週火曜に20分の確認
- **決定事項の記録先：** プロジェクトの資料の「決定事項」の節

## 決定事項
- 移行中は価格を変えない。

## 未決事項
- 解約後1か月、ビルワイズを閲覧のみで残すか — 吉田、[キックオフで決める期限]まで
```

## 送る前のチェック

- [ ] 目的になぜ今かが書いてあり、成功の指標が日付つきの数字か「はい・いいえ」の基準になっている。
- [ ] やらないことに、だれかが言い出しそうな項目が3つ以上ある。
- [ ] どのマイルストーンも、担当一人と日付のある完成物である。
- [ ] RACIのどの行にもAがちょうど一人いて、資料の冒頭にプロジェクトの責任者が一人書いてある。
- [ ] どのリスクにも、今やる対策と担当一人がある。
- [ ] 入力にない名前、日付、数字が入っていない。抜けは「[日付未定]」と書くか、未決事項に挙げている。
- [ ] 1枚に収まっている。

## よくある失敗

- だれも確かめられない成功の指標を書く（「請求を改善する」）。どんな数字や基準ならそれを示せるかを聞く。
- やらないことを空にしておく。4週目の言い争いはそこから始まる。
- 1行に最終責任者を2人置く。2人とも同意が要るなら、一人をA、もう一人をCにする。

チームで使う

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

チームのPodに追加

変更履歴

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