キックオフミーティングとは：システム開発の議題・資料・参加者と発注者が事前に決めること

キックオフミーティングは、プロジェクトの開始時に関係者が初めて全員そろい、目的・体制・日程・進め方の認識を合わせる会議です。システム開発では、契約を結んだ後、要件定義に入る前に発注者とベンダーが開きます。この記事では、システム開発に限定して、議題（アジェンダ）の例、準備する資料、参加者の決め方を発注者の立場で整理しました。あわせて、IPAのモデル契約を下敷きに、キックオフで決めておく会議と議事録のルール、形だけで終わる失敗パターンまで扱います。

まとめ：キックオフは責任者・会議体・承認手順を開発着手前に双方で確定する会議

システム開発のキックオフミーティングで決めるべきものは、雰囲気づくりより運営のルールです。双方の責任者と窓口、定例会の頻度と出席者、議事録を誰がいつまでに作り何日で承認するか、課題と仕様変更を誰が判断するかを、この場で確定させます。

キックオフは2回に分けます。先に発注者の社内だけで開き、決裁者・情報システム部門・利用部門の間で目的と対象外の範囲をそろえ、そのうえでベンダーを交えた合同キックオフに臨む流れです。社内の意見が割れたまま合同キックオフに出ると、ベンダーの前で発注者同士が議論を始め、決めるべきことが何も決まりません。

合同キックオフの冒頭では、背景と目的を発注者が自分の言葉で話してください。ベンダーが説明するのは工程・成果物・体制・課題の管理方法です。90分あれば、資料の読み上げではなく合意の確認に時間を使えます。

キックオフミーティングとは：システム開発で開く時期と定例会・連絡協議会との違い

システム開発のキックオフは契約締結後・要件定義の着手前に開く最初の合同会議

キックオフ（kick-off）はサッカーの試合開始を指す言葉で、プロジェクトの開始を関係者全員で確認する会議を意味します。一般的な社内プロジェクトでは計画がまとまった時点で開きますが、受託開発では開く時期がはっきりしています。

ベンダーとの契約が済み、要件定義に着手する前です。提案や見積の段階で開くと、まだ契約していないベンダーに作業を頼む形になり、費用の負担があいまいになります。逆に要件定義のヒアリングが始まってから開くと、誰がどの業務ルールを決めるのかが定まらないまま、聞き取りだけが先に進む形です。要件定義で発注者が担う作業は要件定義の目的・進め方と成果物で整理しています。

定例会・連絡協議会・ステアリングコミッティと比べたキックオフの役割の違い

システム開発では、キックオフの後に性格の違う会議がいくつも続きます。キックオフで決めるのは、これらの会議の頻度・出席者・決める範囲そのものです。

キックオフは1回きりで、その後の会議の土台を作る会議という位置付けです。定例会の進め方と遅延を見つける運用はプロジェクト進捗管理と会議運用の実務で扱っています。

キックオフは2回開く：発注者の社内キックオフとベンダーを交えた合同キックオフ

社内キックオフで決裁者・情報システム部門・利用部門の認識を先にそろえる理由

発注者の社内では、立場によってシステムに期待することが違います。経営層が気にかけるのは費用と稼働時期、情報システム部門は既存システムとの連携や保守、利用部門は日々の操作のしやすさです。この違いを社内で整理しないまま合同キックオフに出ると、ベンダーは誰の要望を優先すればよいか分からなくなります。

政府情報システムの実務ノウハウをまとめたDS-120 デジタル・ガバメント推進標準ガイドライン実践ガイドブック（2026年6月12日決定版）も、プロジェクト体制の準備を説明する箇所（p.52）で、制度所管・業務実施・情報システムの各部門が別々に動きがちな点を挙げ、会議やコミュニケーションのルールを整え、最初にプロジェクト推進組織のメンバー全員を集めてキックオフを行うよう勧めています。民間の発注者に置き換えると、ベンダーと会う前に社内の関係部門だけで1回集まる段取りになります。

合同キックオフの前に社内で決めておく発注者側の目的・体制など5項目

社内キックオフは30〜60分で足ります。資料はA4数枚でよく、次の5項目を決めて合同キックオフの資料に持ち込みます。

1. プロジェクトの目的と、稼働時に達成している業務上の数値（受注処理の時間を半分にする、など）
2. 対象外の範囲（今回は触らない業務・システム・拠点）
3. 予算と仕様の最終判断者、日々の窓口になる担当者の名前
4. 利用部門から要件定義に出す担当者と、その人が使える時間（週に何時間か）
5. 社内で決まっていない事項の一覧と、いつまでに誰が決めるか

5つ目を省かないでください。未決事項を隠したまま合同キックオフに出ると、要件定義の途中で前提が覆り、手戻りの費用負担でベンダーと揉めます。成功の定義と意思決定者を文書化しないまま始めた案件がたどる経過は、炎上プロジェクトの兆候と発注者側の立て直し手順で扱っています。

合同キックオフの議題：90分のアジェンダ例と発注者・ベンダーが話す項目の分担

90分のアジェンダ例：目的の説明から体制・日程・会議体・次の作業まで8項目

中規模の業務システム開発（期間6か月前後、双方合わせて10〜15名）を想定したアジェンダ例です。時間配分は、説明より確認と質疑に厚く取っています。

資料は3営業日前までに配り、当日は読み上げずに要点と確認事項だけを話す運用にします。説明に60分以上かかる資料は、キックオフの前に分けて説明会を開いてください。

発注者が自分の言葉で話す項目：背景・目的・成功の基準・対象外の範囲

アジェンダの2番目は、ベンダーに代弁させてはいけない項目です。提案書には発注者の課題が書かれていますが、それはベンダーが理解した課題であって、発注者の決裁者が承認した目的ではありません。発注者の責任者が、なぜ今この開発をするのか、稼働後に何がどう変わっていれば成功なのかを数値で話します。

対象外の範囲もここで口に出します。「今回は請求書の発行は扱わない」「本社の業務だけを対象にし、工場は第2期に回す」と全員の前で言っておけば、要件定義で利用部門から対象外の要望が出たとき、窓口担当が断る根拠になります。

ベンダーが合同キックオフで説明する項目：工程・成果物・発注者側の作業と期限

ベンダーのPMは、要件定義から稼働までの工程と、工程ごとに提出する成果物、その承認者を説明します。発注者が特に確認すべきなのは、発注者側の作業とその期限の一覧です。現行業務の資料の提出、テストデータの準備、利用部門へのヒアリング日程の確保、受入テストの実施などがここに並びます。

この一覧に期限が入っていない場合は、キックオフの場で期限を決めてください。発注者側の作業の遅れは、契約上は発注者の責任になることが多く、後から日程の遅れの原因として扱われます。

キックオフで決める会議と連絡のルール：IPAモデル契約の連絡協議会を下敷きにする

責任者と主任担当者を決める：IPAモデル契約の第9条・第10条が定める窓口

IPA（情報処理推進機構）が公開する情報システム・モデル取引・契約書（第二版）は、ユーザ企業・ITベンダ・関連業界団体・法律専門家が参画し、どちらか一方に有利にならないことを目指してまとめられた受託開発の契約の雛形です（2020年12月22日公開）。第9条は、個別契約の締結後すみやかに双方が責任者を選任して書面で通知すること、体制図に記載することで通知に代えられることを定めます。発注者の責任者には、要件定義書・外部設計書・検査仕様書を確定する権限と責任があると書かれています。

第10条は、責任者の下で連絡と調整を受け持つ主任担当者を置き、日常的な連絡・確認・依頼は原則として主任担当者を通じて行うと定めています。キックオフでは、この2つの役を個人名で確定させ、体制図に載せてください。体制図に載せる役割と線の引き方は体制図と役割分担表の書き方で解説しています。

議事録の承認期限：第12条の「異議がなければ承認とみなす」規定を日数で埋める

モデル契約の第二版のひな型（Word）の第12条は、進捗・リスク・共同作業の実施状況・仕様の確認・問題の協議のために連絡協議会を開くと定めています。システム開発の定例会にあたる会議です。同条は、ベンダーが議事録の原案を開催日から一定日数以内に作って発注者に提出し、発注者が受け取ってから一定日数以内に点検し、その期間内に理由を示して異議を述べなければ承認したものとみなす、という手順を置いています。

ひな型では日数が「○日」と空欄のままです。この空欄を埋めるのがキックオフの仕事です。原案は開催から3営業日以内、発注者の点検は受領から5営業日以内のように具体的な数字を決め、議事録には決定事項・継続検討事項・その検討の期限と担当者を必ず書くと合意しておきます。同条7項も、議事録にこの3つを含めるよう定めています。発注者が点検を後回しにすると、内容を読まないまま承認したことになる点に注意してください。

キックオフで決めたことは契約変更にならない：第33条の変更手続きとの関係

キックオフや定例会で「この機能も入れましょう」と話がまとまっても、それだけでは契約の範囲は変わりません。第12条の1項は、契約と個別契約の内容の変更は第33条の手続きによってのみ行えると明記しています。会議で合意した追加や変更は、変更の内容・費用・日程への影響を書いた書面で、双方の権限者が改めて合意する必要があります。

キックオフでは、この変更をどの手順で進めるかについても確認してください。誰が変更を申し出て、誰が費用と日程の影響を見積もり、誰が承認するかを決めておかないと、定例会の口頭の合意が積み重なり、最後に追加費用の請求として表に出ます。請負と準委任で変わる責任の範囲は委任・請負・受託の違いと契約の選び方で整理しています。

キックオフの資料と参加者：準備する6つの資料と呼ぶべき人・呼ばなくてよい人

準備資料：プロジェクト計画書・体制図・WBS・会議体一覧・課題管理表・用語集

システム開発のキックオフで配る資料は次の6つです。発注者が用意するものとベンダーが用意するものが混ざるため、誰が作るかを先に決めておきます。

• プロジェクト計画書（目的・範囲・体制・日程・リスク。発注者が目的と範囲、ベンダーが日程を書く）
• 体制図（双方の責任者・主任担当者・利用部門代表を個人名で記載）
• WBSまたは工程表（工程ごとの成果物と承認日。ベンダーが作成）
• 会議体一覧（会議名・頻度・出席者・決める範囲・議事録の期限）
• 課題管理表の雛形（起票者・判断者・期限の列を含めたもの）
• 用語集（社内で使う略語や業務用語と、その意味）

このうちプロジェクト計画書が土台になり、他の5つはその付属資料にあたります。計画書に書く項目と発注者・受託側の書き分けはプロジェクト計画書の書き方と分担、課題の起票と完了の判定方法は課題管理表の項目とステータス設計を参照してください。

参加者の決め方：決裁者が冒頭15分だけでも出席すべき案件と利用部門代表の基準

合同キックオフに必ず呼ぶのは、双方の責任者と主任担当者、ベンダーのPMとチームリーダー、発注者側の利用部門代表です。利用部門代表は、要件定義で業務ルールを説明し、受入テストで合否を判断する人を選びます。部門長の名前だけを載せ、実務を知らない人を出席させると、要件定義で別の担当者が呼ばれ、キックオフでの合意が引き継がれません。

決裁者（予算を決めた役員）は、全部の時間に出る必要はありません。ただし開発費が数千万円を超える案件や、複数部門の業務が変わる案件では、冒頭の挨拶と目的の説明の15分だけでも出席してもらってください。決裁者の口から目的が語られると、利用部門が要件定義に人を出す優先度が上がります。

ベンダーの開発メンバー全員を呼ぶ場合の注意：直接の指示と受け取られる発言

キックオフにベンダーの開発メンバーまで全員が出席するのは、顔を合わせる意味で悪いことではありません。注意すべきなのは、発注者側の出席者が開発メンバーに個別の作業を頼む発言です。労働者派遣と請負の区分は、厚生労働省の37号告示関係疑義応答集が示すとおり、契約の形式ではなく実態で判断されます。

双方の全員が参加する会議は、それだけで直ちに偽装請負とされるものではありません。ただし、その場で発注者が特定の開発担当者に作業の割り振りや順序を直接指示すると、請負や準委任の契約でも偽装請負と判断されるおそれがあります。キックオフで「作業の依頼は主任担当者からベンダーのPMへ」と確認しておけば、利用部門の担当者にも線引きが伝わります。

キックオフが形だけで終わる失敗パターンと、開催を見送ってよい小規模案件

ベンダーの説明会で終わる・決裁者が不在・宿題の担当者が決まらない失敗の型

最も多いのは、ベンダーが用意した資料を90分読み上げ、発注者は聞くだけで終わる型です。議事録には「説明を受けた」としか残らず、会議体や承認期限は何も決まっていません。アジェンダの各項目に「確認すること」を1行ずつ書き、会議の最後にその行が埋まったかを全員で見る運用に変えると防げます。

決裁者も責任者も欠席し、窓口担当だけが出席する型も危険です。キックオフで合意した目的や範囲を、後から出てきた決裁者が覆します。責任者の都合が付かないなら、キックオフの日をずらすべきです。

宿題が誰の担当にもならない型もあります。質疑で出た未決事項に担当者と期限を付けないまま閉会すると、次の定例会で同じ議論が繰り返されます。未決事項はその場で課題管理表に起票し、判断者と期限を読み上げてから終えてください。

改修や小規模案件は初回の定例会に統合してよい条件と、統合してはいけない条件

すべての案件で正式なキックオフが要るわけではありません。既存システムの改修で、前回と同じベンダー・同じ担当者が関わり、期間が2か月以内の案件なら、独立したキックオフは過剰です。初回の定例会の冒頭20分で目的・範囲・発注者側の作業を確認し、議事録に残せば足ります。

反対に、初めて取引するベンダーとの案件、利用部門が2つ以上ある案件、既存システムの刷新でデータ移行を伴う案件では、統合してはいけません。会議体と承認期限を決める場を持たないまま進めると、最初の議事録の承認でつまずき、要件定義の確定が遅れます。

発注者側に進行役がいない場合にPMO支援で立ち上げを外部に任せる範囲

中堅・中小企業では、社内キックオフの段取りから合同キックオフの資料確認までを担える人がいないことがあります。窓口担当が通常業務と兼務している場合、ベンダーが用意した資料をそのまま受け入れることになり、発注者側の作業の期限や承認期限が発注者に不利な形で決まりがちです。

この場合は、発注者の立場で社内キックオフの論点整理、会議体と議事録のルール案づくり、ベンダーの工程案の確認を担う外部支援を入れる方法があります。一創の要件定義・RFP作成・PMO支援では、受託ベンダーとは別の立場で、発注者側の体制づくりと立ち上げの会議の設計に関わります。外部に任せる場合も、目的の説明と最終判断は発注者の責任者が行ってください。

キックオフミーティングのよくある質問：所要時間・挨拶・オンライン開催・議事録

システム開発のキックオフについて、発注担当者から寄せられることの多い質問をまとめました。

キックオフミーティングの所要時間はどれくらいですか？

中規模の業務システム開発なら90分が目安です。60分では体制と会議体の確認が終わらず、質疑の時間がなくなります。2時間を超える場合は、資料の説明が長すぎる兆候です。ベンダーの工程説明や画面のデモは別の説明会に分け、キックオフは合意の確認に絞ってください。発注者の社内キックオフは30〜60分で足ります。

キックオフミーティングの冒頭の挨拶は誰が何を話せばよいですか？

発注者の決裁者か責任者が、3〜5分で話します。内容は、この開発を決めた理由、稼働後に期待する変化、利用部門への協力の依頼の3点で十分です。ベンダーへの儀礼的な挨拶を長くする必要はありません。決裁者が出席できないときは、責任者が決裁者の言葉として目的を代読すると、出席者に経営判断であることが伝わります。

オンラインでキックオフミーティングを開いても問題ありませんか？

オンラインでも開けます。ただし初めて取引するベンダーとの案件や、利用部門が複数ある案件では、対面か、少なくとも全員がカメラを付けた形をおすすめします。オンラインでは質問が出にくいため、議題ごとに指名して確認を取り、チャットに出た質問は議事録の継続検討事項に転記してください。録画する場合は冒頭で全員の同意を取ります。

キックオフミーティングの議事録は誰が作りますか？

受託開発ではベンダーが原案を作り、発注者が点検して承認する形が一般的です。IPAのモデル契約の第12条もこの手順を前提にしています。キックオフの議事録は、以後の会議体と承認期限を決めた最初の記録になるため、決定事項・継続検討事項・その担当と期限が書かれているかを発注者が必ず確認してください。点検期限を過ぎると承認したとみなされる運用にしている場合は特に注意が要ります。

キックオフミーティングは英語や略語で何と呼びますか？

英語では kick-off meeting、または project kickoff と書きます。社内の資料で使われる略語は、KOM（Kick Off Meeting）や KO といった表記です。外資系のベンダーや海外拠点が関わる案件では、kickoff の後に開く定例を weekly status meeting、決裁者が出席する会議を steering committee と呼ぶことが多いので、用語集に対応表を入れておくと混乱を防げます。

関連記事

• システム開発の流れとは？工程の全体像と各フェーズのポイントをわかりやすく解説：キックオフの後に続く工程の全体像
• システム開発のプロジェクト管理とは？進め方・QCDと工程/品質/リスク管理と発注側の役割【2026年版】：立ち上げ後の進捗・品質・リスク管理
• PMOとは？役割・種類とPMとの違い｜システム開発でPMOを外部に任せる判断：キックオフの段取りを外部に任せる判断
• リスク管理表の作り方：発生確率・影響度の項目と課題管理表との違い、更新の運用：キックオフで共有するリスクの管理表
• RFPとは？提案依頼書の意味・目的・記載項目と目次テンプレートを解説：キックオフの前段にあたるベンダー選定の文書