このnoteで言いたいこと

・今後、プロジェクトマネジメントのニーズは増えそう

・プロジェクトの中でキックオフって雑に扱われがちだけど、プロジェクトの成功においてメチャクチャ重要

・このnoteにキックオフのやり方を書いたから、ぜひやって欲しい

あなたは誰？

8年半ほどWebディレクターをやってました。言い換えるとプロジェクトマネージャー（以下PM）ですね。

案件数でいえば3ヶ月程度の開発案件を50以上はこなしたかと思います。

また仕事の案件や個人的にイベントのPMもやってました。

このnoteを書いた理由

Twitterのタイムラインを見ていたら「今後はチームが大事」的なことを、えとみほさん・motoさん・けんすうさんが立て続けにつぶやいてたんですね。

チームで何かをやる＝プロジェクトなので、チームがたくさん生まれると、おのずとPMのニーズも増えるはずです。

ただ、よく勘違いしてる人が多いのですが、プロジェクトの成果は、たし算ではなくかけ算的に決まります。

何が言いたいかというと、かけ算で質が高まる方向に行けば良いのですが、なにかの拍子に「0」をかけてしまったら、そのプロジェクトの成果が0になる恐れもあります。

「0になることってある？」と思うかも知れませんが、プロジェクトの成果を0にしてしまう地雷は割といたるところに埋まってます。

例えば…

・やらなきゃいけないタスクを誰がやるか明確じゃなくて、締め切りに遅れてプロジェクトがダメになる
・納品形式を勘違いして、作ったものがゴミと化す
・「この日までにできます！」と安易に答えてしまって、結局できなくてプロジェクトが白紙に
etc...

なので先ほど挙げたツイートを見て「これからは個人が集まってチームをやるべきなんだ！」といって安易にチームを組んで、何も考えずにプロジェクトをやると、割と痛い目にあいます。

これ以上、世の中に悲しいプロジェクトを増やしたくない……！

で、プロジェクト管理において「キックオフ」は悲劇を防ぐのに有用なのですが、やらない人が多いんです。

なので、こんなツイートをしました。

すると普段のツイートより反応が良く、またプロジェクト管理のノウハウってSNSでもあんまり見ないし、困る人が今後多くなりそうなので書くことにしました。

キックオフにおいてよくある2つの誤解

キックオフの詳細を述べる前に、キックオフに対する誤解を解いておきます。

1.キックオフは顔合わせ

キックオフは、確かに顔合わせとしての機能もありますが、それだけではありません。

そこを勘違いしてる人が多いため、特に社内で見知った人どうしのプロジェクトだと、キックオフを省略する人の多いこと多いこと…。

キックオフは、曖昧になりがちな「ゴール」「役割分担」「関係者」などを明確にする目的があります。

なので、いくら見知ったメンバーだったとしても、キックオフは案件ごとに必ずやるべきです。

2.キックオフMTGの中で物事を決める

キックオフMTGの中で役割分担やスケジュールを決める人がいますが、それは間違ってます。

なぜなら、MTGで決めようとすると、PMが知らない事実や情報がその場で出てくる恐れがあるからです。

そうなると、PMの思い通りにプロジェクトがコントロールできなくなります。

プロジェクトにおいて、変数は少なければ少ないほど良いです。

逆に分からないことがある、ないし分かったつもりになってるのは、変数が多い状態なので危険です。

キックオフMTGはあくまで共有の場、最終確認の場だと捉えてください。

そのため、キックオフMTGの前にすべての調整は終わってる状態が理想です。

キックオフMTGの目的とその理由

キックオフは、下記の項目について認識をチーム内で合わせるのが目的です。

なぜ、各項目の認識を合わせる必要があるか、その理由も一緒に確認していきましょう。

▼プロジェクトのゴール（終了条件）

プロジェクトには必ず終わりがあります。なので、プロジェクトの終了条件が何なのか？をすり合わせておく必要があります。

そうでないと、プロジェクトと関係ないタスクをやってしまったり、終わったと思い込んでたら実は終わってなかった…といった事件が起きます。

特にお客さまに納品したら終わるプロジェクトだと、納品形式をミスってやり直し…そんな悲劇も数多く見てきました。

またリスク回避だけでなく、みんなで同じ方向を向いて一致団結するためにも、ゴールは確認しましょう。

▼関係者のリスト

他の会社が関わるプロジェクトで起きがちなのが「突然、相手の会社の知らない誰かが、ちゃぶ台をひっくり返す」問題です。

これ、マジでプロジェクトを白紙にする威力を持つ時があります。

悲劇を起こさないためには、プロジェクトの「決裁フロー」を確認し、決裁に関わる人や部署を洗い出しておきましょう。

ちなみに社内でも同様です。

よくあるのが、法務部がプロジェクトが終わりかけのときに「法律上のリスクが高いんで…」等の理由で待ったをかけるパターンです。

法務部の方は、やるべきことをやってるだけで、何も悪くありません。リスクを事前に察知できなかったPMの責任なので、関係者リストの作成と共有は怠らないようにしましょう。

▼役割分担

PM「このタスク、進んでないよね？」
A「それ、Bさんがやると思ってました」
B「いや、Aさんがやるとばかり…」

「プロジェクトあるある」な会話です。

役割分担が明確になっていないと、タスクを誰がやるかあいまいになり、宙ぶらりんになりがちです。

また役割分担が決まってないと、タスクごとに誰が担当するのか決める必要が出てくるので、コミュニケーションコストも増大します。

なので役割分担はしっかり決めておきましょう。

▼決め方のルール

プロジェクト内では進め方だったり仕様だったりルールだったり、何かと「決める」シーンが多く登場します。

その時「どうなったら決定なのか？」が明確になってないと、メンバーも動いていいか分からなくなったり、決定してないアイデアを進めてしまったりします。

前述の「関係者のリスト」「役割分担」も関わってくるのですが、誰に決定権があるのか、どうやって決めるのか（合議制なのかどうか）を事前に調整しておきましょう。

▼会議体

プロジェクトを進めるにあたって必要となる会議が何なのかも重要です。

会議は主に2つあって、進行を定期的に確認する定例と、物事を決める会議があります。

特に重要なのは定例です。

定例をしないと、タスクの進行の遅れや漏れを把握できなくなります。

また定期的に顔を合わせることで、メンバーの健康状態や気分の把握もできます。

他プロジェクトにも参加してる人がいる時は、いつ、どれくらいの時間で、どれくらいの頻度で、どんな進め方で定例を実施するのか調整して決めておいたほうが良いです。

▼スケジュール

プロジェクトはたいてい期間が決まってますので、どれくらいの期間でこのプロジェクトをやり遂げないといけないのかを確認する必要があります。

スケジュールの引き方はPMの腕の見せ所です。個人的におすすめなスケジュールの引き方は後述しますが、スケジューリング力でプロジェクトがうまくいくかどうか決まるといっても過言ではありません。

たいていトラブルになるのもスケジュールです。また時間は代替が効かないので、特に注意をする必要があります。

▼マイルストーン

プロジェクトの規模にもよりますが、細かくスケジュールを共有してもなかなか理解されづらいので、マイルストーンを置いてチーム内で共有とスマートに進められます。

特に大きかったり長期的なプロジェクトほど、どの時点で何ができてないといけないのかを分かる形で共有しておかないと、「スケジュールが終わるまでにすべて完成してれば良いでしょ？」と夏休みの宿題的に進めてしまう人が出てきたりします。

定例である程度防げますが、マイルストーンの共有でも二重に防いだほうが安心です。

▼管理ツール

どのツールを使うのかは、プロジェクト進行でけっこう重要です。

社内に閉じたプロジェクトなら決まったツールがあるとは思いますが、社外が絡む場合やフリーランス同士のプロジェクトの場合、ツールの選定を誤るとプロジェクトがスムーズに進行できなくなりがちです。

今回のプロジェクトメンバーが普段何を使ってるかや、プロジェクトの特性に応じてツールを選びましょう。

▼使えるリソース

プロジェクトは限られたリソースの中で、最大限クオリティの高いアウトプットを出すことが求められます。

なので、使えるリソースが何なのか全員で共有しておくと良いでしょう。

例えばWebサイトを作る時に、使える画像が何があるか分かっておくとデザイナーさんが動きやすい…といったことです。

キックオフの進め方

キックオフの目的や重要性を理解できたところで、キックオフの具体的な進め方を見ていきましょう。

▼プロジェクトで何をやるか決まる

プロジェクトは、何をやるか決まって、はじめて動き始めます。

何をやるか？については一般的にPMは関わりません。どんなプロジェクトをやるか決める人が「プロデューサー（違う名前の場合もあります）」で、決まったプロジェクトを実際に進める人が「ディレクター（PM）」です。

この2つがなぜ分かれているかと言うと、プロデューサーは「理想ベース」、PMは「現実ベース」で物事を考えてしまいがちなので、何をやるか？についてPMが考えてしまうと現実に即した「できること」しかやらなくなってしまい、プロジェクトのゴールが低くなってしまうからです。

このあたりは議論の余地がある部分です。理想だけで突っ走るプロデューサーもいたりしますが、そうすると結局、実現不可能なプロジェクトが降ってくるなんてこともありますから。

ただ個人的な感覚でいうと、分かれていたほうが最終的に良いプロジェクトになるなぁと感じています。

プロジェクトが決まると、使えるリソースも決まってくるので、その中で最大限のクオリティのものを作り上げるのが、PMの腕の見せ所の1つです。

▼ゴールの確認

どうなったらプロジェクトは終わりなのかを確認しましょう。

ちなみにプロジェクトのゴールに、解釈の余地を入れてはいけません。

計測可能なゴールにしないと、解釈のズレが生じて、チーム内でゴールの認識がずれてしまいます。

▼人をアサインする

自由に人をアサインできるとも限りませんが、可能であれば何をつくるかから逆算して、どんな人が必要か検討しましょう。

何が得意で何が苦手か。目の前のことをひたすらやるほうが得意なのか、俯瞰できるタイプなのか。そういった特性を見極めて、バランスの良いチーム作りを目指します。

▼役割を決める

アサインしたメンバーとそれぞれコミュニケーションをして、役割分担をします。

特定の作業（開発・デザイン等）をする人が複数いる場合、だれがコミュニケーションの窓口になるのか決めておくと、やり取りがスムーズです。

▼関係者を洗い出し、決め方を決める

社内外問わず、コミュニケーションを取って洗い出しましょう。

特に決裁フロート決裁者を意識して洗い出し、あわせて決め方を決めておきましょう。

▼スケジュールとマイルストーンを検討する

スケジュールをブレイクダウンして、マイルストーンやタスクを洗い出します。

慣れているプロジェクトだったり、プロジェクトが異様に大きい場合は粒度低めでも良いですが、慣れないうち（リスクが読めない場合）は、すべてのタスクを洗い出して、タスクごとの期限を決めておくと安心です。

その時に一人で勝手にスケジュールを決めるのではなく、分担した役割の人ごとにスケジュールを確認します。

おすすめのスケジュールの引き方なのですが、最低2種類、最大3種類引くと良いです。

それは自分用、チーム用、クライアント用の3つ。クライアントがいないときは2つで大丈夫です。

クライアント用は1番余裕のあるスケジュールを、チーム用はそれよりかは余裕がないスケジュールを、自分用は本当のデッドラインのスケジュールを書いておきます。

プロジェクトにはトラブルがつきものです。

しかし何かトラブルがあっても時間的な余裕があれば挽回できます。

余裕がないと、トラブルが起きたら遅延するor最終的なアウトプットの質が落ちるリスクがあります。

もしスケジュール的にどうしても余裕がないのであれば、リスクをプロジェクトの決裁者やクライアントに伝えないといけません。

伝え漏れると、プロジェクトが失敗したら評価が低いとPMの責任になります。しかし本来は無理なスケジュールを要求してきた人にも責任はあるので、そこはハッキリさせておかないと自分の身を守れなくなります。

▼会議体を検討する

主に定例の時間や頻度を調整します。

よく朝会を何も考えずに設定しちゃう人がいますが、朝だとエンジニアの人がいない等の理由で意味をなさなくなる可能性があるなら、夕方にやるといった調整が必要です。

定例は「進捗確認」がメインですが、困ってることを吸い上げてプロジェクトの阻害要因を把握するようにしましょう。

プロジェクトメンバーが集まっているので、困ったことを言うとその場で解決案が出る可能性が高く、その場で決まらなくても別で解決案を決める会議を開くといった行動が起こせます。

定期的に困ったことを言える場があると、メンバーも安心してプロジェクトを進められます。

▼ツールを検討する

主にコミュニケーションおよびプロジェクト管理を目的としたツールを選定します。

勝手に決めるのではなく、メンバーに聞いた上で決めましょう。

よく使われるのは

・コミュニケーション
Slack、ChatWork
・プロジェクト管理
Backlog、Trello、スプレッドシート

あたりでしょうか。

ゴールが決まってるウォーターフォール式のプロジェクトであればガントチャートが作りやすいツール、都度タスクを決める（IT業界で言うところの「アジャイル」）ならTrelloあたりが良い気がします。

個人的にはAsanaが両方の機能を内包してて気に入っています。

ちなみにAsana内でコミュニケーションも完結するので、プロジェクト系のコミュニケーションはAsanaでも良いのではと感じてます。

あ、ステマじゃないよ！

▼キックオフのドキュメントを書いて共有する

ここまで調整&整理をしたら、ドキュメントにまとめます。

キックオフの目的は「認識のすり合わせ」です。その際に共有した内容にズレがあってはいけないため、わざわざ時間を合わせて、なるべく対面でMTGをするわけです。

なのでドキュメントに残しておくと、よくある「言った言わない問題」にもなりづらいですし、事前に共有することで、プロジェクトにおける新しい課題がキックオフ前に見つかる可能性もあります。

▼キックオフMTGの実施

ここまできて、やっとキックオフMTGが開催されます。

でもここまでやっておけば、キックオフMTGも30分程度で終わらせられます。

完璧なプロジェクトなんてない

ここまで、あくまで理想的なプロジェクトの進め方を書いてきました。

しかし、現実に即してみると「チームメンバーが不十分」とか「スケジュールが全然ない」といった「穴」が開いている場合がほとんどです。

その場合は、まず「穴」によるリスクを決裁者に共有しましょう。

PMはこれはできる、これはできない、と判断せずにいると、プロジェクトに悲劇が起こりがちです。「やらなきゃいけないから」と無理をして徹夜とかしてもクオリティは担保できませんし、チームメンバーへの思いやりに欠けています。

リスクを共有すれば、もしかしたらリソースの補充を検討してくれる可能性もあります。プロジェクトを良くするために必ず共有してください。

またチームメンバーにもその「穴」は共有しましょう。

穴が開いていたとしても、なるべくリスクは回避しておきたい所。

なのでキックオフの前に各メンバーに相談し、その上でなるべく解決法を見出しておきましょう。

キックオフ、めちゃめちゃ大切です。

プロジェクトの成功はキックオフとその準備で8割決まると思います。

ないがしろにせずキックオフをしっかりやれば、プロジェクトはきっとうまくいくでしょう。

世の中に楽しいプロジェクトが増えることを願っています。