キックオフ資料の構成テンプレート
キックオフは、プロジェクトで関係者全員が一度に集まる、最初で最後に近い機会です。ここで何を伝えるかによって、その後の半年から1年の進み方が変わります。
それなのに、キックオフ資料は「前任者の資料を書き換える」で作られがちです。このページでは、資料の構成と時間配分、記入例、運用のしかたをまとめます。記入例は、事例集の「加美乃フーズ（架空）の生産管理システム刷新」に当てはめたものです。
■ この資料が要る場面（背景・よくある課題）
キックオフ資料が必要になるのは、自分の指示だけでは動かない人が関わるときです。社内の別部門、工場、店舗、ベンダー、そして兼務でこのプロジェクトに入る人たち。
うまくいかないキックオフには、共通した特徴があります。
よくある症状 | 本当の原因 |
|---|---|
会議後、誰も動き出さない | 「今日から誰が何をするか」のページがなかった |
協力を頼むと「本業が忙しい」と断られる | なぜこのプロジェクトが必要かを、相手の言葉で説明していない |
資料が40ページあり、読まれない | システムの機能説明に紙数を使い、判断に必要な情報が埋もれている |
後から「そこまでやると思っていた」と言われる | 「やらないこと」のページがなかった |
判断が要るたびにPMに問い合わせが来る | 「誰が何を決めるか」を伝えていない |
■ このテンプレートの目的
参加者が、翌日から動ける状態にする：理解してもらうことではなく、動いてもらうことが目的です
判断の枠組みを共有する：何を成功とし、どこまでやり、誰が決めるか。この3つが揃うと、PMがいない場でも話が進みます
資料を作る過程で、自分の計画の穴に気づく：7つの問いに答えられない箇所は、計画の弱いところです
逆に、やらないほうがよいことも書いておきます。新システムの機能を細かく説明することです。キックオフの時点では設計もできていませんし、聞き手の多くは機能名を言われても判断できません。機能の話は要件定義の場でします。
■ テンプレートの全体像
標準は10ページ・60分です。1つの問いに1ページ。
ページ | 内容 | 持ち時間 | 作成の担当 |
|---|---|---|---|
P.1 | 表紙（プロジェクト名・日付・版数・作成者） | ― | PM |
P.2 | 今日のゴールと進め方 | 3分 | PM |
P.3 | なぜ、いま、これをやるのか（背景） | 8分 | 事業部門と共同 |
P.4 | 何をもって成功とするのか（QCDと成果指標） | 7分 | PM・事業部門 |
P.5 | どこまでやるのか（やること／やらないこと） | 8分 | PM |
P.6 | 全体スケジュールとマイルストーン | 7分 | PM |
P.7 | 体制と役割（誰が何を決めるか） | 7分 | PM |
P.8 | 会議体と報告のしかた | 5分 | PM |
P.9 | 前提・制約・いま決まっていないこと | 5分 | PM |
P.10 | この2週間で、あなたにお願いしたいこと | 5分 | PM |
― | 質疑 | 5分 | ― |
P.3の作成を事業部門と共同で行う点が、この構成のポイントです。「なぜやるのか」を情報システム部門だけで書くと、どうしても「システムが古いから」になります。それでは現場は動きません。現場が困っていることを、現場の言葉で書く必要があります。
■ 各ページの説明
ページ | 必ず入れるもの | 入れなくてよいもの |
|---|---|---|
P.2 今日のゴール | この会議で「決めること」と「伝えること」の区別 | 参加者の自己紹介（別途行う） |
P.3 背景 | 今の困りごとを数字で／このまま何もしない場合に起きること | 技術的な老朽化の説明 |
P.4 成功の定義 | QCDそれぞれの合格ライン／稼働後に測る成果指標と目標値 | 細かい非機能要件 |
P.5 範囲 | やらないことの一覧と、外した理由 | 機能一覧の詳細 |
P.6 スケジュール | マイルストーン5〜8個／各部門の作業が発生する時期 | WBSの全体（別資料にする） |
P.7 体制・役割 | 意思決定者が誰か／何をその人が決めるか | 全員の氏名と所属の一覧（別紙） |
P.8 会議体・報告 | 会議の名前・頻度・出席者・決めること／依頼の出し方 | 使用ツールの操作説明 |
P.9 前提・制約・未決 | 前提が外れた場合の影響／未決事項の期限と決める人 | すべての前提（重要な5件程度に絞る） |
P.10 お願い | 誰に・何を・いつまでに。名指しで書く | 「ご協力をお願いします」という抽象的な依頼 |
右の列「入れなくてよいもの」も同じくらい大事です。キックオフ資料が30ページを超えるときは、たいていこの列のものが入っています。
■ 記入例：加美乃フーズ 生産管理システム刷新
3工場（関東5ライン・中部4ライン・九州2ライン）の生産管理システムを刷新する、14か月・総額2億9,500万円枠のプロジェクトです。
P.3 なぜ、いま、これをやるのか
項目 | 記載内容 |
|---|---|
いま困っていること | 生産計画を表計算ソフトで手作りしており、作成に週32時間かかっている。3工場それぞれで別々に作っているため、拠点をまたぐ生産の振り替えができない |
数字で見ると | 計画作成の人件費 年間1,920時間／急な受注変更への対応が平均2.5日遅れる／原価の確定が翌月20日 |
このまま何もしないと | 現行システムの保守は2026年3月で終了。それ以降は障害が起きても直せない。製造が止まれば1日あたり約2,800万円の出荷が止まる |
だから今年やる理由 | 保守終了まで残り26か月。構築に14か月かかるため、来年度着手では間に合わない |
「保守が切れるから」だけでは、工場の人は動きません。「計画作成に週32時間かかっている」「製造が止まれば1日2,800万円」という、相手にとっての数字があると、自分の問題として受け取ってもらえます。
P.4 何をもって成功とするのか
軸 | 指標 | 合格ライン |
|---|---|---|
Q（品質） | 稼働後3か月の本番障害 | 5件以内 |
Q（品質） | 製造ラインの停止に至る障害 | 0件 |
C（コスト） | 総費用 | 2億9,500万円以内 |
D（納期） | 全3工場での稼働 | 2025年2月末まで |
P.5 どこまでやるのか
区分 | 内容 |
|---|---|
やること | 受注 → 生産計画 → 実績収集 → 原価計算の4領域／3工場すべて |
やらないこと | ① 需要予測の自動化（実績データが揃ってから第2期で） |
P.10 この2週間で、あなたにお願いしたいこと
誰に | 何を | いつまでに |
|---|---|---|
関東工場 生産管理課 | 現行の生産計画表（直近3か月分）と作成手順のメモを提出 | 1月18日（木） |
中部工場 生産管理課 | 同上 | 1月18日（木） |
九州工場 生産管理課 | 同上 | 1月18日（木） |
各工場 製造課長 | 実績入力を誰がいつ行っているかの現状メモ（A4半ページ） | 1月18日（木） |
経理部 原価担当 | 原価計算の配賦ルール一覧（現行）を提出 | 1月25日（木） |
情報システム部 | 要件定義のヒアリング日程を3工場と調整し、確定 | 1月25日（木） |
このページの作り方にコツがあります。1つの依頼は、相手が30分以内に終えられる量にすることです。「現状をまとめてください」では動きませんが、「A4半ページで」なら動きます。最初の1回を実行してもらえると、その後も動いてくれます。
■ 運用ルール
キックオフは、要件定義の着手より前に開く。着手後に開くと「もう始まっているのに今さら」という空気になります
P.3（背景）は、事業部門の人に話してもらう。PMが話すより、困っている本人が話すほうが伝わります
資料は前日までに配る。当日に初めて見る資料では、質問が出ません
1ページ1問い。10ページを超えたら、超えた分は別紙にする
P.10のお願いは、会議後24時間以内に個別メールで再送する。会議で聞いただけでは忘れられます
欠席者には、資料を送るだけで終わらせない。15分でよいので個別に説明の場を持ちます。欠席した人ほど、後から反対に回りがちです
資料は版数を管理する。スコープが変わったら改版し、変更点を明示して再配布します
6番目は見落とされがちです。キックオフに出られなかった人は、たいてい忙しい人＝影響力のある人です。ここを放置すると、終盤に「聞いていない」が出ます。
■ 活用シーン
場面 | 使い方 |
|---|---|
プロジェクトのキックオフ | そのまま10ページで使う |
フェーズの切り替わり（設計→開発など） | P.3とP.5を省き、P.6以降を更新して30分版で使う |
途中参加メンバーへの説明 | 資料をそのまま渡し、15分で説明する。最新版を1つ持っておくと毎回作らずに済む |
体制が大きく変わったとき | P.7とP.8を更新し、関係者に再配布する |
経営層への中間報告 | P.4（成功の定義）とP.6（スケジュール）を使い、進捗を重ねて示す |
ベンダー側のキックオフ | P.5・P.7・P.8を厚くした版を用意する。範囲と決裁者と依頼のしかたが、ベンダーにとって最も重要 |
■ よくある失敗と直し方
失敗 | 何が起きるか | 直し方 |
|---|---|---|
P.10（お願い）がない | 会議後、誰も動かない | 名指しで、30分以内に終わる依頼を書く |
背景が「システムが古いから」だけ | 現場が自分の問題として受け取らない | 相手の業務が今どれだけ困っているかを数字で書く |
機能の説明に紙数を使う | 資料が40ページになり、読まれない | 機能は要件定義の場へ。キックオフでは扱わない |
「やらないこと」を書かない | 後から要望が膨らむ | 検討して外したものを、理由つきで列挙する |
意思決定者を書かない | 判断が要るたびにPMに問い合わせが来る | 「この領域は誰が決めるか」を領域ごとに明記する |
欠席者に資料を送って終わり | 終盤に「聞いていない」と言われる | 15分の個別説明を必ず行う |
一度作って更新しない | 半年後、資料と実態がずれて使えなくなる | フェーズの切れ目に改版し、途中参加者への説明に使い回す |
■ 導入効果
項目 | この構成でない場合 | この構成の場合 |
|---|---|---|
会議後の初動 | 「良い話を聞いた」で終わり、動き出すのに2〜3週間かかる | P.10の依頼があるため、翌日から動く |
資料の分量 | 30〜40ページ。作成に3〜4日 | 10ページ。作成に1日（うち半日は事業部門との背景の詰め） |
途中参加者への説明 | 都度その人向けに作る | 同じ資料を15分で説明できる |
スコープに関する議論 | 「やると思っていた」が繰り返される | P.5を示して即答できる |
判断が要る場面 | PMに集まる | P.7の役割分担にもとづき、その場で決まる |
加美乃フーズの案件では、キックオフから2週間で3工場すべてから現行の生産計画表が集まりました。これはP.10で工場ごとに名指しで、提出物と期限を書いたからです。「現状を教えてください」だけなら、3工場が揃うのに1か月はかかったはずです。
最後に1つ。この資料を作る過程そのものが、計画の点検になります。7つの問いのどこかで手が止まったら、そこが計画の弱いところです。資料が書けないのは、資料作成が苦手なのではなく、まだ決まっていないからです。