エンジニアリングチームのためのプロジェクトキックオフ会議アジェンダ
キックオフミーティングが飛ばしている問い
うまくいったキックオフは、「何を作るか」「誰が何をするか」「いつまでにやるか」についてチームの認識を揃えます。その認識はだいたい3週間ほど保ちます。その後、スコープが膨らみ、ステークホルダーが前提を変え、依存関係がずれ始め、チームは「意見が割れたとき誰が決めるか」を決めていなかったことに気づきます。
ほとんどのキックオフアジェンダが飛ばしている問いはこれです。「何かうまくいかないとき、このチームはどう意思決定するか?」プロジェクト計画の話ではなく、意思決定のフレームワークの話です。フィーチャーをカットする必要が出たとき、スコープを誰がオーンするか? 技術的な制約がプロダクト要件を無効にするとき、チームはどうするか? 2つの部門が異なるものを求めるとき、どのステークホルダーが最終決定権を持つか?
これらの問いはキックオフの段階なら答えやすいです。何もリスクにさらされていないからです。プロジェクト中盤に入ってからでは、全員がポジションを持っているため、はるかに難しくなります。以下のテンプレートは、山場が始まる前にその時間を確保します。
アジェンダ（コピーして使ってください）
所要時間: プロジェクトの複雑さに応じて60〜90分
形式: ファシリテーター進行。主要なステークホルダーと参加者全員が出席するか、開始前に非同期でレビュー済みであること
セクション1 — プロジェクトゴールとスコープ（20分）
- ゴールを一文で述べる: 成功した状態はどんなアウトカムか、可能であれば測定可能な形で
- スコープ内: プロジェクトが具体的に何を届けるか
- スコープ外: このプロジェクトが明示的にやらないこと — 少なくとも3つ列挙する
- 成功基準: チームはどうやってプロジェクトが完了したと判断するか?
- このセクションはEMまたはPMがオーンする。エンジニアは述べられたスコープが実現可能性と合わない場合はプッシュバックする
セクション2 — 役割とオーナーシップ（15分）
- 各ワークストリームに対して、オーナーを一人指名する — チームではなく個人
- プロダクトスコープ、テクニカルアーキテクチャ、対外コミュニケーションについてそれぞれ最終決定者は誰か?
- 主要な意思決定タイプごとに、誰が情報を受け取るか / 誰が相談されるか / 誰が意思決定者か?
- 何も明確でないときに責任を持つプロジェクトリードを指名する
セクション3 — 制約とリスク（15分）
- ハード制約: 締め切り、予算、コンプライアンス、他チームへの依存
- 既知のリスク: このプロジェクトを頓挫させる可能性のある上位3つは何か?
- 各リスクについて: 発生可能性、影響度、緩和策のオーナー
- プロジェクトがキャンセルまたは大幅にスコープ縮小される原因は何か? 今のうちに名前をつけておく
セクション4 — コミュニケーションプラン（10分）
- チームはどのくらいの頻度でシンクするか? どんな形式で?
- 誰に、どのようにステータスアップデートを伝えるか? ステークホルダーが同じチャンネルを望むとは限らない
- プロジェクトのドキュメントはどこに置くか?
- プロジェクトが何かにブロックされたときのエスカレーションパスは?
セクション5 — 未解決の問い（15分）
- 今日答えられない問いをすべて列挙する
- それぞれについて: オーナーと、答えが必要な期日を決める
- 期日とオーナーのない問いは、中盤になっても未解決のままになる
セクション6 — ネクストステップ（10分）
- 実作業を開始するために今後5営業日以内にやるべき3つのこと
- 各ネクストステップに単一のオーナーを置く
- キックオフの議事録をどう共有し、誰に配布するかを確認する
よくあるキックオフテンプレートの問題点
ほとんどのキックオフテンプレートはプロジェクト計画については丁寧ですが、計画が崩れたときの対処については薄いです。きれいなスコープドキュメントとRACIマトリクスを生み出します — それは有用です。しかし「データベースベンダーがプロジェクト中盤に価格を3倍にしたらどうするか?」や「ハード締め切りでフィーチャーが80%しか完成しなければ何を削るか?」への共通の答えは生み出しません。
スコープ外の明示が一貫して欠けているもう一つのポイントです。スコープ内を述べるのは簡単です。スコープ外 — このプロジェクトがやらない3〜4つの具体的なことを列挙すること — は、別の角度からステークホルダーの期待についての同じ会話を強制します。モバイルクライアントが含まれると思い込んでいたステークホルダーが、6週目ではなくキックオフで気づきます。
3つ目のギャップは未解決の問いのセクションです。チームは「準備不足を認めることになる」という感覚から、キックオフで知らないことを表面化したがりません。しかし未解決の答えはプロジェクト中盤のブロッカーになり、中盤のブロッカーはコストがかかります。問いの存在に早く気づくほど、誰かが早くオーナーになれます。
これらのギャップが数か月にわたるプロジェクトでどのようにオーバーヘッドに複利で積み上がるか: ミーティングタックス。
キックオフノートをきちんと残す価値
キックオフドキュメントは、どのプロジェクトでも最も頻繁に参照されるアーティファクトです。スコープが争われるとき、新しいメンバーが加わるとき、ステークホルダーが「キックオフでXって決めなかったっけ?」と聞いてくるとき — そのたびに確認されます。きちんとドキュメント化されたキックオフは、マネジメントしやすいプロジェクトです。
Pavleurはキックオフ全体を自動でキャプチャします。述べられた通りのスコープ、アサインされた役割、名前のついたリスク、オーナー付きの未解決事項、オーナーと期日付きのネクストステップ。誰かがミーティング中にプロジェクト概要、図、または要件書を画面共有した場合、そのビジュアルも議論と並べてレポートに含まれます。音声のみのツールは「誰が何を言ったか」は提供しますが、テックリードが依存関係を説明していたときに画面に表示されていたアーキテクチャ図はキャプチャできません。生成されるレポートは、初日からプロジェクトの信頼できる唯一の情報源として機能します。従来のミーティングキャプチャツールとの比較: Pavleur vs. 他のツール。
参加者について
このプロジェクトで意思決定することが期待されている全員がキックオフに参加するか、作業開始前にフル録画と要約文書を確認すべきです。キックオフを欠席し、2週間後に非公式にスコープを知るステークホルダーは、プロジェクト中盤のスコープ論争の種になります。キックオフの仕事は共通の文脈を作ることであり、共通の文脈は関係者が同じ場にいるときにしか生まれません。