プロジェクトっていうのは燃えるものだ。だからしょうがない。
過去の自分が思っていたことです。
確かに、その案件が大きければ大きいほど、それなりの会社も職種も違う人が何ヶ月も集まって仕事するんだから、行き違いもあるし、多かれ少なかれトラブルはあるでしょう。
だからといって「しょうがない」というのは、ちょい違うなと今は思っています。
今回は、今までの経験の中で、燃えにくかった、燃えても取り乱さなくて済んだ場合のことを振り返り、統計的な勝ちパターンを特別にご共有いたします（笑）
IA兼PMって体制が理想
これは特に大型案件に言えることです。
まあ、傾向的に大型案件ほど燃えることが多いので、当てはまることが多いと思う。
PMは、プロジェクトの中での絶対権限者。
スケジュール、予算、アサインの管理権限を持ち、極論PMが「こいつやりにくいな」って思ったらチェンジ可能。赤字になりそうだけど納期優先で人突っ込むっていうような判断もありえます。
クライアントに対しては、上記の権限をもってプロジェクト完了の責任を果たす、最終責任者なわけです。
要は外向きにも、内向きにも、正確なコミュニケーションを図り、会社も職種も違う人をまとめなければいけないんです。
例えば、Webサイトのリニューアルだった場合、
・内外体制
・コンテンツ
・インフラ
・開発、試験
・運用、業務
・KPI
などなどの大項目をMECEにWBSで細分化し、把握しなければならない。
加えて、各工程でアサインされるメンバーのスキルレベルを把握し、工数算出し、どこにどれだけの期間と費用が発生するかを把握する必要がある。
これで基本で、実際はコミュニケーションの行き違いやクライアントの理解レベル（理解してもらう内部のレベル）、デイリーのタスク状況などなど机上の空論では想定できない要因でのズレを都度調整していかなければならない。
これは大変ってことで、細かなWBSや日々の調整は、各工程のPLやディレクターが行い、PMは報告を受けて全体の承認を行うってのがほとんどだと思います。
それでもいいんだけど、基本報告を受けるというスタンスになってしまうと、受け取り方次第で異なる解釈してしまったり、現場との距離が離れてしまう（コミュニケーション取れなくなる）ことで、実情を把握できなくなってしまいがちになる。
だから実際PMがやろうと思えば（鉄人であれば）一人でやりきるのが理想形、無駄が一番ない。
だけど現状PMって職種は特にこっち（Web）の業界だと、これだけの幅広い人とコミュニケーションとれる経験を持った人ってなかなかいない。
※システム業界のPMは違うかもだけど。
では、IAはどうでしょう？
IAは設計図を書く人です。設計図を書くためには、クライアントからまず色々聞かなければなりません。
コンテンツを全部把握しなければなりません。
もちろん自分の書いた設計図が、以降のデザインや開発の指針になってしまうので、デザイナーやエンジニアとコミュニケーションを取りながら実現可能性を加味しなければなりません。
もちろん作りっぱなしにするわけにも行かないので、設計しながら「ここは更新運用されるよね」っていうことも定義しますし、設計書出したときにクライアントとその部分について、業務の話もするわけです。
また、当然ですがユーザビリティの改善を設計に盛り込むわけですから、KPIなどデータの話にも首を突っ込みます。
IAは、それをスケジュール・タスクと言う形にアウトプットしないだけで、実際ほぼ全てのプロジェクトステークホルダとのコミュニケーションをはかり、頭の中では把握しているのです（把握しないと自分の仕事ができないのです）。
実際僕はIAやっていて、WBSをしようという気はあまりないけど、やってと言われたらさほど時間かけずにさっくりできます。
要は、IA業務としては全ての情報を集めた上で、コンテンツ分類と要素分類をやっているところを、タスクで分類すればいいだけなんすよね。
それに、これは経験上の話ですが、IAやっていると、全ての工程のメンバーから色々聞かれたり、現場MTGにも参加したり、クライアント側の定例会議にもほぼ全て出て会話直接説明・会話するので、コミュニケーションの不和が起こりにくいんですよね。
設計工程が終わった後も、テスト段階でも何かと呼ばれるし。
だから、余裕があればIAとPMを兼任してしまうのが、一番円滑にことが運ぶってのが持論。
規模的にそんな余裕ねーよって場合は、PMの補佐として軍師的に立つだけでもだいぶ違うと思う。
徹夜は最後にするな、最初にしろ
これ、ほんとみんな勘違いしている。
でっかい案件にアサインされたときに、みんな心のどこかで思うこと「最後徹夜続きになるんだろうな、、、」
これ迷信、ていうかそうなるのは、全部自分たちのせい。
ほんとに徹夜しなくちゃいけないのはキックオフ前の一週間です。
ここで、どこまで具体的なものを示せるかで決まる。
キックオフってMTGの内の一回、ご挨拶って思ってたら大間違いです。
キックオフは、ステークホルダが一同に介するまたとない機会です。流石にキックオフ欠席するとかあまりないっしょ。
だから、そこに集まった人にこれから大変なこと始まるから覚悟してねってしめす格好の機会なんです。
そう、キックオフに集まる人の中でプロジェクトで今後起こることを理解している人なんてほぼいないのです。
「何かよくわかんないけど、呼ばれたし、でるかー」みたいな人も中にはいるかも知れません。
そんな状態で挨拶だけでキックオフが終わると、その先具体的に進めていくときに、足並みが揃わず、多大に無駄な時間を消費することになります。
では、制作側は良いにしてもクライアントに、これから進んでいくプロジェクトを具体的に理解してもらい、「お、やばっ！気を引き締めてやんないとな」って思ってもらうにはどうしたら良いでしょう？
一般的にキックオフに持参されるもの
・グランドスケジュール
・体制図
・提案時（競合時）の提案資料あればRFP
こんなところでしょうか？
上記をもっていき、まずはお礼と提案書を元に提案内容の振り返りと理解促進、質疑応答。
体制図と合わせてメンバー紹介、ご挨拶、最後に粗々のグランドスケジュールのご説明。
こんな感じで、キックオフをなんとなく行うんじゃないでしょうか？
これは、生ぬるいです。はい。
以下が本当は必要です。
９割方落とし込んだWBS及びアサインリスト、それに伴うガントチャート
粗々のグランドスケジュールなど、まったくもって信用なりません。
何を根拠にそのガントチャートが引かれているのでしょう？
WBSのツールはどれも詳細を階層化すると、親のガントで閉じられるはずです。
詳細タスクを全て洗い出した上で、見づらいから閉じた状態で全体像を示して、やっと信頼できるスケジュールとなるでしょう。
これをやっておくことで、具体的に「あなたにいつどんなタスクをお願いしますね」という話が初めてできるのです。
クライアントは、デジタルのプロジェクトに対して専門家ではありません。
具体的に示さないと、お願い事項が右の耳から入って左に抜けていくものだと肝に命じましょう。
それぞれの工程の内容説明資料
上記のWBSと併用します。
WBS上の文字列とガントチャートだけでは、どんな作業なのか、誰が関わるのか、伝わりません。
特にデジタルのプロジェクトはそもそも横文字が多すぎて、クライアントからしてみれば煙に巻かれているように感じます。
各工程の説明とそのときに誰に何をやってもらうか、その結果として何が提出されるか、を具体的に記載した資料を用意します。
自分はこんな感じのテンプレを使って、ほぼ全行程に対して補足説明をします。
これをやることで、自身がいつ頃どれくらい忙しくなるか、どの工程で何が決まっていないとやばいかを実感してもらうことができます。
6割完成形の要件定義書
最低でも目次と進行に係る章の記載状態が必要です。
要件定義は、キックオフより以降にスケジューリングされてるのになんでキックオフに用意しなきゃいけないの？？？
という疑問にお答えします。
進行に関する決めごとはキックオフ時にやらなければなりません。
なぜなら、それが決まっていないと次のMTGまでの過ごし方がわからず、一週間無駄に過ごしてしまうからです。
体制や連絡系統・役割、承認フロー、ツールやMLのルール、ストレージやドキュメントバージョン管理方法などなど、キックオフから次のMTGの時間にことが進められるか進められないかで1週間も差が出ます。
プロジェクト冒頭では、この一週間は、大した影響に感じないかもしれませんが、納期の希望がある場合、納期直前での一週間の差は生命線になります。
ダメ押しでベースワイヤー（Webサイトであれば最低2階層ベースまで）
僕は、更にこれプロトタイプの状態でもっていきます。
いやいやキックオフでそこまでやる必要ないっしょ？と思う人がほとんどでしょう。
でも経験上、これめっちゃ効果高いです。
提案書ってプレゼンの時間の関係上、いろんなものが端折られてます。
また、よくデザイン案提案のときに出しますが、見た目上の判断基準に利用されるので、サイト全体としての具体性に欠ける場合がほとんどです。
※僕は、ぶっちゃけ提案や競合でデザイン案でジャッジする風習自体にアンチです。
IAという職種の人間であれば、キックオフまでに営業さんなどから入手できる情報や資料、リニューアルであれば既存サイトの状態やもらえているならログデータから、事前に7割の完成形（ヒューリスティック的な理想案）を作れるでしょう。
それを惜しまず出してしまうのです。
前述しましたが、クライアントはデジタルのプロジェクトに知見があるわけではないのです。
だからより具体的なものを求めます。
であれば具体的なものを最初に出して、こちら側に歩み寄ってもらいましょう。
具体的なものが見えると、実感が湧き、それはやる気に直結します。
そうすることで、以降意見が出てきやすくなる土壌を作るのです。
文字ばかりのドキュメントを説明していてもなかなか意見は出てきません。
いや、まぢでこれらをしっかり用意しようとすると、キックオフが一週間後に控えてたら、多分徹夜ありえます。
でもねここでどれだけしっかりしたものを提示できるかで、プロジェクトの質が10倍くらい変わるよ、これ絶対。
※このときもIA兼PMじゃない場合は、IAを巻き込んでやる前提ね。
まず、メンバーがPMに対してほぼ協力的になるし、何より自分自身がほぼ終わりが見えている状態（プロジェクトの中で自分が一番優位に立っている状態）になる。
だから騙されたと思ってやってみ。
それでもプロジェクトは燃える
そうなんです。これだけ準備したり、全体把握できる状態でも、予期せぬ事ってのは起きるんです。
人間がやっていることなのだからしょうがない。
大事なのは、取り乱さないこと。
前述のことをやっておくと取り乱しにくくなる。でも気を抜いて状況をよく見てなかったりすると、一瞬でおいていかれる。
そうなったら、目も当てらんなくなるのね。
だから、常に先回りする動きをPMはやってないといけない。
主観になってはいけない、客観でなければいけない。プロジェクトの中心にいながら、誰よりも遠くから進行を眺めなければならない。
大事なのは、リードするという状況をいつまで続けられるか（基本的には最後まで守り続ける）。
プロジェクトメンバーは進行が進めば進むほど、みな前からタスクをこなすようになってくる。
PMたるもの絶対に前からタスク消化してはいけない。
計画をする人間は、常にケツから考えるのです。
PMが見失わない限り、火は必ず消えるはず。
一つの手段として参考になればこれ幸いです。
あとがき
今回がこのブログの最終回となります。
関係各所の皆さんには、ちょこちょこお伝えしていますが、編集長兼エディターである僕がJクリエイティブワークスを離れるためです（笑）
本当は他のメンバーに引き継いで、技術よりにしたり、自分では見えなかった観点で、続けてほしかったですが、会社の方針としてこのサイトが閉じることになったので、しょうがないですね！
当初このブログは、自身の持たされたチームをより良くしていくための方法論やテクニックを綴り、社外の方にもその過程を共有することで、業界や発注者として業界に関わる方にもお役に立てていただけるようなものを目指していました。
自分もこのブログを始めたとき、会社のチームマネジメントとはどんなものなのか、きちんと理解していなかったと思います。
こちらの記事でも、過去の自らの迷いがよくわかります。
プロジェクトのリーダーとして、案件に関わるメンバーを引っ張るのと、一つの企業のマネージャーとして、人だけでなく売上も含めて自社に貢献するのでは、全く違うベクトルの話で、正直なところ、この4年半、自身のチームに関わってくれた人に100％満足のいく貢献ができたとは言えないでしょう。
結果として、自身はよりプロジェクトに寄る形となり、売上での会社への貢献に終始するようになっていってしまいました。
その中でも、何人かのメンバーとは同じプロジェクトに関わり、プロジェクトの中で自身をどう活かしていくか、与えられた仕事だけではなく、プロジェクトを良くするためにどう立ち回っていけばよいかということを、自身の行動を見せることやスタッフの行動に対してアドバイスをすることで、個々の成長を少しは支援できたかな？と思っています。
最後になりますが、こんな辺境の地のブログを目にしてくれた方、SNSなどを通じていいねしてくれた方、そして自分のスピードに必死についてく来てくれた我がスタッフに感謝します。
いやー、Webって本当に素晴らしいものですね。
それではまたどこかで、さよなら、さよなら、さよなら！
