プロジェクトの成功に欠かせない「キックオフ設計」の考え方
新規事業を作るときや、これまでの事業に対して新しい施策を打つときなど、どのような職種の人でも色々な人とチームを組んで仕事を進めることが多いと思います。
チームとして働くときに重要なのが、お互いが共通認識を持って進めるということ。これができずに進めづらさや失敗を経験した方も多いのではないでしょうか。
プロジェクトが始まるタイミングで、関わるメンバーの認識合わせのミーティングを、私たちは「キックオフ」と呼んでいます。
この記事では、これまでの自分自身の経験や、Goodpatchでのプロジェクトキックオフの様子を見たり聞いたりして学び取ったコツをまとめています。ぜひ、自社におけるプロジェクトのキックオフ、メンバーとの認識合わせにお役立てください。
目次
1. キックオフの目的をはっきりとさせる
キックオフのフォーマットや事例はいくつかネット上にも散らばっていますが、それを活用するプロジェクトの状況や性質は様々です。
ですので、一概にキックオフをフォーマット通りに行えばいいというわけではなく、プロジェクトの状況や性質、そして参加者同士の関係性などに応じたカスタマイズが必要です。
このカスタマイズをするにあたって、当たり前ですが、まずは「何を目的としたキックオフなのか」を整理し明確にする必要があります。
一例ですが、私が関わったプロジェクトのキックオフは以下のような目的で行うことが多かったです。
- チームビルディング
- プロジェクトの前提部分の目線合わせ(ステークホルダーを含め)
- プロジェクト内の権限や関係性の可視化(組織図)
- その後のワークを円滑に進めるための足がかりの作成(プロジェクトマップなど)
また、キックオフの目的をいくら正確に定めても、参加者に意思決定者がいないと、いくらでもちゃぶ台返しが起こる可能性があるため、意思決定者や各ステークホルダーを呼ぶことが非常に重要です。
これができないと、プロジェクトに関わるメンバーでの共通認識を揃えるという大目的は達成されません。
意思決定者の時間が取れない場合でも、キックオフを数グループに分け何回か実施したり、目的を絞って限られた時間で認識を揃えることもおすすめです。
2. キックオフの設計前に、必要な情報を収集する
キックオフというと、プロジェクト開始直後にやることが多いため、全くインプットのない状態のように思われがちですが、実はキックオフの設計をするためには、そのプロジェクトに関係する様々な情報をインプットする必要があります。
そして、このインプットは担当者だけが独りよがりにリサーチをするのではなく、そのプロジェクトにGOサインを出した意思決定者の方や関連する部署の方などとのコミュニケーションや、過去の資料などから、プロジェクトの理解を十分にすることは欠かせません。
例えばクライアントワークの場合は、実際にクライアントの担当者や意思決定者の方と密にコミュニケーションをとり、ありとあらゆる情報を短期間でインプットした上で、同じ土俵で会話ができるようになる必要があります。
ですので、自社事業でもクライアントワークでも、どんな立場の人がどんな情報を持ってこのキックオフに参加するのかを前もって知り、全体の組織図や権限の所在が分かるくらいコミュニケーションをとってインプットをしましょう。
ちなみに、必要な情報が収集できていない状態でキックオフをしてしまうことは、多くの場合失敗につながると私は考えています。
なぜなら、クライアントや担当者とそもそもプロジェクトについての目線合わせができていない状態でいきなりワークしはじめてしまうと、不信感を抱かれてしまったり、キックオフの目的がぶれてしまい何のためにキックオフをするのかが不明瞭になってしまうような確率が高くなるからです。
そうなってしまうと、私自身の経験上、チームメンバーの認識を揃えることがより難しくなり、プロジェクト自体が失敗してしまうケースが多かったように思います。
3. 無理にキックオフで先に進めようとしない
必要な情報のインプットをした結果、クライアントやプロジェクトの状態によっては、無理にプロジェクトを前に進めるためのワークを設計しない方が良い場合もあります。
キックオフの目的によっては、信頼関係のない状態で進めてもせっかくの良いワークも意味がなかったりします。
その場合は、あくまで一例ですが、キックオフの目的を「プロジェクトの理解」と設定するなどして、素直にクライアントやステークホルダーなどから、これまでの経緯やこれからのビジョンを語ってもらうようなキックオフにするのが良いと思います。
場合によってはキックオフをしないという選択や、複数回にキックオフを分けるという選択もあり得ると思います。
4. キックオフの次を考える
キックオフでプロジェクトを前に進めるためのワークをする場合、その成果物が次のどんなワークにどのように活かされていくのかを、進め方のアウトラインを描いて明確にしましょう。
ワークは一つずつやって終わりではありません。
やって終わりにしてしまうと、参加者に何のためにやったのか？と不信感を抱かせてしまうため、キックオフに限らず、何をするにしても今やらなければいけないことと、その結果何を得て次にどう繋げていくべきかをセットで考えましょう。
例えばGoodpatchのキックオフでは、クライアント側の達成したいゴールを分解し、ゴールが達成されることで作られるメリットを、想定されるユーザーとビジネスの両面から意見交換することで、ビジネス的にもユーザー的にもメリットがある意義のあるプロジェクトであるということをチームで確認していくというワークをすることもあります。
もしここで、ビジネスまたはユーザーのメリットのいずれかが欠落している場合は、そのメリットがないままでいいのかどうか議論し、サービスの見落としを防ぐという次のワークに繋げることもできるでしょう。
まとめ
目的を設定しよう
キックオフのフォーマットや事例は万能ではありません。このような世に出ている手法は、目的と合致して初めて機能します。
目的に応じた手段を選択するためにも、目的を整理し明確化してから進めましょう。
プロジェクトについて理解しよう
私は以前担当していた案件で、クライアントの声に耳を傾けずに認識がずれた状態で進めてしまい、失敗をしたことがあります。
何をするにしてもまずは十分なインプットをしましょう。
クライアントや各担当者の方もどうやって進めていくのか不安なはずです。
ですので、まずはこちらから傾聴の姿勢を見せ、プロジェクトの状況や前提、そしてその人たちの想いを理解した上で進めてくれているという安心感や信頼感をお互いに持ちましょう。
プロジェクト初期では、誰もがそのプロジェクトについて何も知らないのは当たり前です。
だからこそ、個人で進めることはせず、まず情報を得るために動きましょう。
クライアントや各担当者にもわからないことがあれば、それを明らかにするワークをキックオフに限らず設計しましょう。
点ではなく線で考える
全てのワークと目的をセットにして考えましょう。
プロジェクトの中でなにかワークを設計するときは、点ではなく線で考え始めることが重要です。
キックオフを設計するときも、そのあとの進め方はどうするのかを加味しながらアジェンダを決定しましょう。
アウトラインとして、WBS的な粒度まで落とさずとも、現時点で見える範囲の達成したいゴール(ユーザーインタビューをするためには、など)に向けて、具体的にどんなワークをするべきかをセットで考えることが重要です。
手一杯になってしまうと、目の前のことだけを解決しようと点で見てしまい、結果どこに向かえばいいのかわからなくなります。
そうなるとプロジェクト全体が迷子になってしまうので、向かう方向を示す立場の方は、周りに相談しながらでも構いませんので、今見える範囲でのゴールまでのアウトラインをひいてみましょう。
最後に
繰り返しになりますが、プロジェクトの状況や性質によって、キックオフの役割や目的は変わってきます。ですので、皆さんも、プロジェクトに応じて柔軟に目的を設定し、それを満たすためのキックオフを設計してみてください。
ちなみに私の場合、プロジェクトを前に進めるための土台として一つのチームになるために、プロジェクトの初期フェーズにおいては、最低限チームビルディングとプロジェクトの理解に多くの時間を割くことが多いです。
また、キックオフは長時間になることが多いため、終業時間に合わせて開始し、そのままキックオフ後にチームのみんなとご飯にいくことでこのプロジェクトに対する想いやキックオフへの感想をお互いに話し合って、チームビルディングを完了させることも多いです。
これから始まるプロジェクトを成功させるためにも、キックオフを活用するのはいかがでしょうか。
よかったらこちらの記事も参考にしてみてください。
