キックオフ
キックオフは、コミュニケーション基盤の整備でどう連絡し合うかが決まり、メンバーが正式に確保された状態で、連絡の仕組みとメンバーを動かし始め、プロジェクトを正式に走らせる起点です。
PM術のキックオフは、新たに何かを決める場ではありません。決めることは、事前準備フェーズと、セットアップフェーズのコミュニケーション基盤の整備で、すでに終わっています。キックオフは、事前に決めたものをメンバー全員で正式に共有・確認し、プロジェクトの起点を全員で握る場です。
共有・確認の場であること以外に、PM術に固有の作法はとくにありません。一般的なキックオフの進め方で問題なく機能します。
キックオフの前に、当てた個人を正式に確保する
キックオフを開く前提として、事前準備フェーズのチーム設計で当てた個人を、契約と稼働コミットで正式に確保しておく必要があります。契約形態の確定、稼働コミットメントの取り付け、開始日の合意といった作業がここに含まれます。いずれも一般的なビジネスの作法で進められる範囲です。
当初当てていた個人が確保できないと分かった場合、空いた役割に代わりの人を当てるだけでは済ませません。事前準備フェーズで成立を判定したのは、当てた個人の編成だからです。代わりのメンバーに当初の個人と同じ見積もりが当てはまるとは限らないので、編成が変わった時点でチーム設計のやり直しに戻ります。
典型的に扱う内容
プロジェクトの目的と最終OUTの共有
最初に扱うのは、プロジェクトが何を目指すものなのか、そして最終的に何を出すのかです。要求定義と提案でクライアントと握ったゴールを、メンバー側にも同じ言葉で渡します。
目的の共有が抜けると、各メンバーは自分の担当範囲だけを見て動くことになり、全体の方向感を見失います。とくにクライアントが最終的に何を喜ぶのかというイメージは、目的の共有なしには伝わりません。冒頭で目的をそろえておくことで、後続の各論が同じ前提のうえで進められるようになります。
フェーズとマイルストンの確認
次に、工程設計で組み立てたフェーズの並びと、クライアントへ提示するマイルストンを共有します。各フェーズでどこまで進んでいる状態を作るのか、節目がいつなのかを、全員が同じ理解で持てるようにします。
内部工程表のすべてを開示する必要はありません。メンバーが自分の担当範囲のスケジュール感をつかめる粒度で渡すのが基本です。クライアント向けのマイルストンと内部工程表の関係は、PM自身が把握していれば足ります。
メンバーの役割と担当範囲の確認
誰が何のオブジェクトを担当し、どのINを受け取り、どのOUTを返すのかを、本人と全員に対して明示します。事前準備フェーズで設計した役割を、キックオフで正式に渡す形になります。
摩擦の予防という観点では、もっとも重要なパートのひとつです。自分が何を求められているか、自分の責任範囲がどこまでかが曖昧なまま走り出すと、進行中に認識齟齬として表面化します。キックオフの場で本人と他のメンバーの双方に対して明示することで、後から「聞いていない」「そう思っていなかった」が起きにくくなります。
コミュニケーションのルールの共有
コミュニケーション基盤の整備で決めた内容を、全員に共有します。どのチャネルで何をやり取りするか、OUTをどう通知するか、異常を検知したときに誰へ連絡するか、といった運用ルールを、走り出す前にそろえておきます。
ルールの共有も、事前に決めたものを渡す場であって、新たに議論する場ではありません。決まっているからこそメンバーは迷わずに済みます。
スケジュールの確認
営業日に並べた内部工程表の主要部分を共有します。すべての詳細を開示する必要はありませんが、各メンバーが自分の担当範囲の作業ペースをつかめる粒度では渡しておきます。
直近で動き出す作業がいつ始まり、最初のOUTがいつ求められるのかが見えていれば、メンバーは初動の準備に入れます。
質疑応答
ここまでの内容について、メンバー側の疑問を吸い上げる時間を取ります。事前に決めたものを共有する場ではありますが、認識齟齬は共有の場面でこそ表面化することが多いため、キックオフで拾えるものは拾っておきます。
質疑のなかで重大な認識のずれが見つかった場合は、その場で結論を出さず、PMが持ち帰って必要な再設計を行います。進行中のPMの動きで言う、異常検知に近い扱いです。
運用の細部は、プロジェクトの規模や性質、クライアントの参加有無、対面かオンラインか、といった条件に応じてテーラーしてください。所要時間も、小規模なプロジェクトなら30分程度、中規模なら1〜2時間程度が目安になりますが、状況次第です。