キックオフ会議の準備｜目的・対象外・役割・次の行動を合意する

キックオフ会議は、資料を読み上げて開始を宣言するだけの場ではありません。目的・範囲・役割・進め方を共有し、最初の行動へつなぐ場です。全員が集まってから前提を考えると、会議中に決められない項目が増えます。事前に合意済みと未決を分け、最後に何が残るべきかを定めましょう。

会議前に目的と範囲を確認する

目的は「システムを作る」だけでなく、どの業務をどの状態へ変えるかを説明します。測定方法が未決ならその旨を示し、確定した成果のように話さないようにします。対象業務、対象外、主な成果物、制約、前提を整理します。細かい仕様をすべて決める場ではないので、仕様を決める場と承認経路を案内します。事前資料には確認してほしい点を添えます。「参考資料多数」より「対象外に認識違いがないか」を依頼した方が準備の方向がそろいます。必要な回答が会議前に集まるよう、窓口と締切も示します。

参加者は肩書きだけで選ばない

責任者、実行メンバー、業務側の判断者、影響を受ける部門を確認します。運用担当や利用者側の窓口を後から探すことにならないかを点検します。全員が全時間参加する必要はありません。判断が必要な議題、意見を聞く議題、周知だけの議題を分け、参加範囲を相談します。判断者が欠席するなら、代理に権限があるか、会議後の確認になるかを明記します。出席者の賛同を、欠席者の承認と扱わないようにします。

初回会議でそろえる項目

小規模な業務改善を想定した説明用です。時間配分は未決の数に応じて調整してください。

合意済みの項目は毎回再議論せず、変更の必要があるかを確認します。未決をその場で無理に解決せず、必要な材料と判断期限を定めます。

不確実性も説明する

「納期厳守」だけでなく、納期に影響する前提を共有します。業務側の回答期限、外部環境の提供時期、兼任メンバーの稼働枠などです。懸念を出した人が消極的と見なされる会議では、問題が後から見つかりやすくなります。人物批判でなく条件と影響を確認する発言を受け止め、管理先へ記録します。不安の列挙だけで終わらず、確認担当と期日を残します。会議で解決するもの、調査するもの、責任者の判断が必要なものを分けます。全員が賛同するまで議論することが唯一の進め方ではありません。

終了条件と会議後の動きを確認する

最後に目的・範囲の認識差、未決、最初の行動を読み合わせます。「全員理解」より、誰が何を提出するかを確認した方が実行につながります。議事録では決定・未決・行動を区別します。最新版資料と正式な管理表へリンクし、会議後に正本が複数生まれないようにします。初回の更新日と次回会議日が決まれば、開始後の空白を減らせます。キックオフ直後に計画が変わることもあるので、変更の連絡経路も共有します。未決を隠さず、次に動ける状態を到達点にしましょう。

次に確認したい実務ガイド

• スコープ定義書の書き方｜対象外・前提・完了条件まで合意する
• RACIの作り方｜実行者と責任者を分けて役割の空白を見つける

PMO実務テンプレート・確認表の一覧から、目的に合う記事を探せます。

参考情報とこの記事の位置づけ

開始時に目標・優先事項等をそろえる考え方を確認しました。時間配分や進行例は独自作成です。 Atlassian：Project Kickoff（確認日：2026年10月11日）。記入例・確認表は当サイトが説明用に作成したもので、実在の案件・実績ではありません。

議事録の書き方も必要な作業に合わせて参照してください。

アイキャッチ写真：Headway / Unsplash。職場の実写ではなくイメージ写真です。