プロジェクトのキックオフ資料：範囲・役割・議題を明確にする

プロジェクトのキックオフ資料では、対象範囲、担当者の責任、最初の確認ポイントをチームで共有します。会議では、次の作業に影響する選択を決めてください。プロジェクト計画を最初から最後まで読み上げる場にはしません。背景説明の長い資料より、簡潔な議題と、その場で確認できる決定記録のほうが役に立ちます。

架空の社内申請ポータルのプロジェクトを考えてみます。初回リリースでは、従業員が備品と出張を申請し、承認者が承認または差し戻しできるようにします。キックオフで決めるのは、アクセス権限の申請もこのリリースに含めるかどうかです。

以下の議題と範囲表は、Presentiでテキストからキックオフ資料の初稿を作る際にも使えます。生成前に実際のプロジェクト情報を加え、会議での決定はスライドやチームの決定記録に残してください。

調整して使える30分のキックオフ議題

短いプロジェクト概要と一緒に、議題を事前に送ります。参加者には、意見が必要な決定と、背景として読む情報を区別して伝えてください。未解決の議論に15分かかると予想するなら、自己紹介の後に押し込むのではなく、その時間を確保します。

これは時間配分の例であり、どのプロジェクトにも当てはまるルールではありません。複数企業にまたがるキックオフなら、契約、セキュリティ、技術設計のために別の打ち合わせが必要な場合もあります。キックオフにすべてを詰め込むのではなく、それぞれの会議を明示します。

対象範囲の選択を見える形にする

「申請ポータルを作る」だけでは、解釈の余地が大きすぎます。リリース範囲をスライドに示し、未決の選択肢は別の行に置いてください。この架空のチームは、次の情報から議論を始めます。

スポンサーは、受け入れ先のチームと連携作業が未定のため、アクセス権限申請を延期すると決めます。選択と理由の両方を記録します。「初回リリースからアクセス権限申請を除外する。IT部門は次の範囲見直しまでに作業を見積もる」。後のスライドで、「延期」を「近日対応予定」に置き換えてはいけません。

組織図ではなく、三つの責任を確認する

誰が作業を進め、誰が成果を受け入れ、誰が範囲を変更できるかを示します。この例では、実行責任者が開発を調整し、運用マネージャーが基準に照らして試験導入を受け入れ、スポンサーが新しい申請種別によってリリース範囲を変えるか判断します。経理の窓口は出張承認のルールを提供しますが、それだけでプロジェクト責任者になるわけではありません。

RACIを使うなら、略号の横に行動を書きます。「最終責任：スポンサー」より「スポンサーが初回リリースの範囲変更を承認する」のほうが具体的です。依存事項については、依頼を送る人だけでなく、受け取る側の担当者も示してください。

PMIの立ち上げ会議のガイドは、目的、範囲に含むものと含まないもの、戦略、リスク、前提、作業の責任を取り上げています。キックオフ資料は、これらを議論に載せるためのものです。プロジェクトの正式な承認や詳細計画の代わりにはなりません。

最初の確認ポイントで何を確かめるかを決める

このチームの最初の確認ポイントは、「試作完了」ではなく、備品申請の流れのテストです。試験参加者が申請でき、承認者が理由を付けて差し戻せて、申請者が結果を確認できる必要があります。運用マネージャーはそのテストを見て、小規模な試験導入に進めるか判断します。

日付の横には前提条件も書きます。経理が承認ルールを提供し、IT部門がテストアカウントを用意する必要があります。どちらかが遅れたら、テスト時間を黙って短縮せず、確認ポイントを見直します。その後の節目も、成果物と受入条件を組み合わせて示してください。その確認日を約束する前に、要員計画のプレゼンで、必要な作業量とチームが実際に使える時間を並べて確認します。

終了前に決定記録を読み返す

会議の最後に、次の記録をその場で埋めて確認できます。

決定：初回リリースには備品申請と出張申請を含める。
対象外：アクセス権限申請と権限の自動付与。
理由：アクセス権限申請の担当者と連携作業が未確定。
次の行動：IT部門が次の範囲見直しに向けてアクセス権限申請の作業を見積もる。
最初の確認ポイント：備品申請を一件提出し、差し戻し、その結果を確認する。
受入責任者：運用マネージャー。
前提条件：テストアカウントと経理の承認ルール。
次回の見直し：[日付と会議の担当者]。

会議後はスライドと一緒に記録を共有します。新しく加わったメンバーも、合意した範囲と議論で出たアイデアを区別できるようにしてください。変更時は履歴を消さず、理由と担当者を添えて決定を更新します。

議題、範囲表、確認ポイントを使って、Presentiでキックオフ資料を作ってみてください。役に立つ資料とは、会議中の見栄えがよい資料ではなく、最初に範囲の疑問が出たときにチームが参照できる資料です。