キックオフ会議の設計
キックオフ会議を「関係者の顔合わせ」だと思っていると、もったいない使い方になります。全員が一度に集まる機会は、プロジェクト期間中にそう何度もありません。
キックオフの目的は、この先の進め方について、その場で合意を取りつけることです。挨拶と資料の読み上げで終わらせず、決めるべきことを決めて帰ります。
■ 90分の組み立て
0–10分 決裁者に話してもらう
最初の10分は、PMではなく決裁者に話してもらいます。「なぜこのプロジェクトをやるのか」「会社として何を期待しているのか」を、本人の言葉で語ってもらいます。
これは形式的な挨拶ではありません。参加者の多くは通常業務を抱えたまま参加します。上が本気であることが伝わるかどうかで、その後の協力の得やすさが変わります。事前に「5分ほど、目的と期待を話していただけますか」と依頼しておきます。
10–30分 概要シートを読み合わせる
立ち上げ期に作った1枚を、声に出して確認します。黙読ではなく読み上げるのがポイントです。とくに次の2つは必ず確認します。
成功基準 「この状態になったら成功とします。よろしいですか」
スコープ外 「これは今回やりません。ご認識ください」
スコープ外を読み上げると、たいてい誰かが反応します。「えっ、それも入ると思っていました」。その反応こそが、キックオフをやる価値です。終盤で出てくるより、この場で出てくるほうが百倍ましです。
30–45分 マイルストーンと体制
いつ何が終わるかを3〜5個の節目で示し、誰が何を決めるかを個人名で共有します。「この件は◯◯さんに確認します」と全員が分かる状態にします。
45–60分 進め方のルールを決める
意外と軽視されがちですが、ここを決めておくと後の運営がとても楽になります。
定例会議の曜日・時間・出席者
議事メモの配布と確定のルール（当日配布、翌営業日17時までに指摘がなければ確定）
変更を依頼したいときの出し方（誰に、どの形式で）
困ったときに誰に連絡するか
60–80分 懸念を出してもらう
「何か質問はありますか」と聞くと、たいてい沈黙します。代わりに、「心配なことを、一人ひとつずつ挙げてください」と頼みます。全員に順番に発言してもらう形にすると、出てきます。
出てきた懸念は、その場で課題管理表に書き込みます。担当と期限まで決められるものはその場で決めます。「言っても無駄だった」と思わせないことが大事です。
80–90分 次の2週間のTODOを確認
最後に、誰が・何を・いつまでにやるかを読み上げます。参加者が退出する時点で、自分のやることを把握している状態にします。
■ 準備でやっておくこと
資料は前日までに配る 当日配ると読む時間で10分が消えます
決裁者の出席を最優先で押さえる 欠席なら日程をずらしたほうがよいくらいです
「使う人」の代表を呼ぶ 管理職だけの会になると、現場の懸念が出てきません
課題管理表を開いた状態で臨む その場で書き込めるようにしておきます
■ よくある失敗
PMが90分話し続ける 聞く側は疲れるだけで、合意は得られません。話す時間は全体の半分以下に
技術的な詳細に入り込む アーキテクチャの説明は別の場でやります。この場は業務の言葉で話します
その場で決めずに持ち帰る 全員が集まっている場で決められることは、その場で決めます
議事メモを出さない 合意した内容を当日中に配って、はじめてキックオフが完了します
■ 規模が小さいときも、短くやる
5人程度の小さなプロジェクトなら、90分も要りません。30分で十分です。ただし、目的・成功基準・スコープ外・進め方のルールの4つは、規模にかかわらず必ず扱います。
「小さい案件だから」と省略したプロジェクトほど、後から範囲が膨らみます。
■ まとめ
キックオフは、プロジェクトで唯一、全員の認識をそろえられる場です。ここで合意しておいたことは、後の判断の拠り所になります。逆に、ここで曖昧にしたことは、終盤まで曖昧なままです。
次のキックオフでは、「スコープ外の読み上げ」と「懸念を一人ひとつ」の2つだけでも入れてみてください。それだけで会議の性質が変わります。