プロジェクトが始まると、最初に行うことの1つがキックオフミーティングです。目標を説明し、スケジュールを共有し、役割と責任を整理します。クライアント、社内チーム、外部のパートナー企業が同じ全体像を見てスタートするための、大切なプロセスです。
ところが実際のプロジェクトでは、キックオフをしたのに同じ問題が繰り返されます。「これは誰が決めるのですか？」「要件の変更はどこまで受けられますか？」「課題が起きたら誰に報告すればいいですか？」「QAで見つかった問題は、リリース前に必ず止めるべきですか？」「外部のパートナー企業は、どんな基準で成果物を提出すればいいですか？」
プロジェクトのキックオフは、単なるスケジュールの共有ではありません。プロジェクトに参加する人たちが、同じ判断基準を持つためのオンボーディングのプロセスです。
プロジェクト参画が難しい理由
プロジェクトは、会社へのオンボーディングより複雑なことが少なくありません。新入社員は会社に一度なじめばよいのですが、プロジェクトメンバーはプロジェクトごとに異なる背景、クライアント、スケジュール、リスク、役割構成を理解しなければなりません。
特にITプロジェクトでは、次の要素をすばやく共有する必要があります。プロジェクトの目標、主なステークホルダー、役割と責任、スケジュールとマイルストーン、変更要求のプロセス、リスクと課題の管理方法、QAとリリースの基準、コミュニケーションのチャネル、成果物の提出基準。
こうした内容を資料にまとめることは必要です。しかし、資料を共有したからといって、全員が同じように判断できるわけではありません。
事例：パートナー参画のWeb構築
新しいブランドサイトの構築プロジェクトを考えてみます。社内のPMO、プランナー、デザイナー、マークアップエンジニア、開発者、外部のパートナー企業が一緒に働きます。キックオフでは、WBS、スケジュール、成果物の一覧、報告体制が共有されます。
しかし実際に進めていくと、次のような状況が起きます。クライアントが、デザイン工程の途中で新しいコンテンツ枠を追加したいと依頼してきます。デザイナーは画面を修正する必要があり、マークアップエンジニアはレイアウトへの影響を、開発者はCMSの構造変更の可能性を確認しなければなりません。PMOは、スケジュールとスコープへの影響を整理する必要があります。
このとき、プロジェクトに新しく参画したメンバーが最初に知るべきなのは、「誰が忙しいか」ではありません。この依頼がプロジェクトのスコープとスケジュールにどう影響するかを確認する手順です。こうした判断基準を事前に学んでいないと、プロジェクトはすぐに揺らぎます。
キックオフ研修はシナリオにできる
プロジェクトのキックオフで説明する内容をゲーム型のクエストに置き換えると、より学びやすくなります。
クライアントが、デザイン確定の直前に新しいセクションの追加を依頼してきました。プロジェクトメンバーとして、最初にやるべきことは何でしょうか。
- クライアントの依頼なので、すぐに反映すると答える。
- まずデザインチームに修正作業を依頼する。
- 依頼内容を整理し、スケジュール・スコープ・開発への影響を確認する。
- キックオフのときになかった内容なので、無条件に断る。
この問題は、単に正解を当てるためのものではありません。プロジェクトで変更要求をどう扱うべきか、どんな順番で確認すべきか、どんな情報を整理すべきかを学ぶためのものです。
職種ごとに違うクエストを
プロジェクトのオンボーディングで大切なのは、全員に同じ研修をしてはいけない、ということです。PMO、開発者、デザイナー、マークアップエンジニア、プランナーは、同じプロジェクトにいても、それぞれ見るべきリスクが違います。
同じ状況でも、職種ごとに問題を変えて組み立てられます。
- PMOのクエスト：スケジュール遅延の可能性が出たとき、クライアントに報告する前に何を整理すべきでしょうか。
- 開発者のクエスト：APIのレスポンス構造が変わったとき、フロントエンドの画面への影響をどう確認すべきでしょうか。
- マークアップエンジニアのクエスト：スマートフォンの画面で新しいセクションのレイアウトが崩れたとき、最初に確認すべきCSSの条件は何でしょうか。
- プランナーのクエスト：「もう少し高級感のある見せ方にしてください」という依頼を、どう具体的な要件に落とし込むでしょうか。
- デザイナーのクエスト：CTAが複数ある画面で、ユーザーの主な行動をどう視覚的に区別するでしょうか。
このように組み立てれば、プロジェクトのキックオフ研修は説明だけで終わりません。それぞれの職種が、実際に直面する判断の場面を事前に経験できます。
First Runでの適用方法
First Runは、こうしたプロジェクトのオンボーディングをRPGのクエスト構成に置き換えられます。基本のデモはMake Feelbetterという架空のIT企業から始まりますが、実際に導入する際は、会社やプロジェクトの状況に合わせてカスタマイズできます。
たとえば、会社名やプロジェクト名を実際の組織に合わせて変え、プロジェクトのキックオフ用のマップを構成し、クライアント・PMO・開発者・デザイナーのNPCを追加できます。実際のプロジェクトのWBSをもとにクエストを作成し、よく起きる課題をシナリオ問題に変換し、完了基準と結果レポートを構成できます。
新しい参画者は、プロジェクトの資料を読んで終わりにするのではなく、実際のプロジェクトで起こりうる状況を事前に経験します。プレイ結果のレポートでは、職種別の強み、改善が必要な領域、おすすめの復習クエストまで確認できます。
プロジェクト参画のクエスト例
スケジュール遅延の報告クエスト
状況：開発スケジュールが3日遅れる可能性が出てきました。まだ確定ではありませんが、QAのスケジュールに影響するかもしれません。
問い：PMOとして、最初にやるべきことは何でしょうか。
正解の方向：遅延の原因、影響範囲、代替スケジュールを整理したうえで、社内共有とクライアントへの報告の基準を確認する。
学習ポイント：スケジュール遅延は、単に「遅れます」と伝えることではありません。影響と代替案をあわせて整理する必要があります。
要件の明確化クエスト
状況：クライアントから「トップページを、もう少しインパクトのあるものにしてください」と依頼されました。
問い：プランナーとして、次に投げかける質問として最もよいものは何でしょうか。
正解の方向：どんなユーザー行動を強めたいのか、参考にしているサイトや優先順位は何かを確認する。
学習ポイント：あいまいな表現はデザインの好みの問題ではなく、目的と基準を確認すべき要件です。
QAのGo/No-Go判定クエスト
状況：リリース前日、特定のブラウザで決済ボタンが動作しない不具合が見つかりました。
問い：リリースするかどうかを判断する前に、必ず確認すべきことは何でしょうか。
正解の方向：影響を受けるユーザーの範囲、決済成功率への影響、回避策の有無、修正にかかる時間、クライアントへの報告の要否を確認する。
学習ポイント：Go/No-Go判定は勘ではなく、影響とリスクの基準で行う必要があります。
まとめ
プロジェクトのキックオフは、単なる開始のミーティングではありません。プロジェクトに参加する人たちが、同じ基準で判断できるようにするためのオンボーディングのプロセスです。スケジュール、スコープ、リスク、コミュニケーション、QAの基準を資料だけで伝えると、実際の場面でまた揺らぐことがあります。
しかし、それをシナリオクエストに置き換えれば、新しい参画者やパートナー企業は、プロジェクトの文脈をより早く理解できます。First Runは、こうしたプロジェクトのオンボーディングをゲーム型のクエストに変える実験であり、ツールでもあります。新しいプロジェクトを始めるたびに同じ説明を繰り返しているなら、その説明をクエストに置き換えてみてはいかがでしょうか。
実務シナリオをクエストで体験してみませんか
プロジェクトのキックオフ研修をゲーム型のオンボーディングに変えたい方は、First Runのデモをプレイしてみてください。 ゲームを始める