正直、万能のアドバイスはできません
まず正直に言うと、いただいた相談そのものに、ものすごく丁寧なアドバイスをするのはちょっと難しいんです。
メンバーの人数やスキル、性格、プロジェクトの遅れ具合、お客さんがそれをどう思っているか。判断に関わる要素がとにかくたくさんあるんですよね。
だから「こうすれば全部解決します」とは言えません。銀の弾丸はないんです。
その上で、進行管理をどうすればいいかという問いには、実はもう答えは明確だと思っています。
WBSとガントチャートをちゃんと運用しましょう。もうこれに尽きるんじゃないかと思います。
プロジェクト管理をディレクターがやるなら、進捗を明確に可視化するのが大前提です。
うちは社内でBacklogを使っているんですけど、担当者、状態、開始と終了のスケジュール、終わっているかどうか。それを全部のチケットに対してちゃんと管理できているかどうかなんですよね。
可視化されると、自分が遅れているのか遅れていないのかが一目瞭然になります。まずはここからだと思います。
遅れたことを責めても、何も進まない
遅れている場合に大事なのは、遅れていること自体を責めても仕方がない、ということです。
もう遅れているんだとしたら、知りたいのは遅れている理由の方なんですよね。
だから「なんで遅れてるんですか？」と感情的に言うんじゃなくて、「遅れてる理由は何ですか？とりあえず状況が知りたいです」という聞き方をした方がいいと思っています。
Webのプロジェクトで遅れる理由は、だいたい要件定義や詳細設計の指示が曖昧だったりする場合が多いんです。
何をどうするのかが明確に書かれていなくて、実装する人が「これどういう意味かな」と迷っている。そういうケースですね。
もう一つは、クリエイティブの方の見込みが甘かった場合。「2日でできます」と言われて、実際は2日で終わらなかった、という話です。
こうなるとディレクターは何を信じたらいいんですかって話になっちゃうので、これはこれで困るパターンです。
ここで大事なのは、事実にフォーカスすることです。なぜ遅れているのか、何が原因なのか。
そこを見ないで感情論になっていくと、今度はクライアントに説明ができなくなるんですよ。
「なんで遅れてるんですか？」と聞かれて「クリエイティブが無理に決まってるじゃないですかって言ってます」なんて、絶対に返せないですよね。それでは、うんとは言ってもらえないですから。
見えない進捗をどう扱うか
精度の話も避けて通れません。ディレクター側が「これ何日でできますか？」と見込む精度も、クリエイティブの人が「これくらいかな」と見込む精度も、どちらも大事なんです。
ただ、全く経験がない人がその精度を高くするのは、正直むずかしいと思います。
仕事を重ねてケーススタディが自分の中に溜まってくると、「しれっと言ってるけど意外とかかるぞ」とか、逆に「これはそんなにかからないんじゃないの？」というのが見えてくるんですよね。
そして、私が特に管理が難しいと感じているのが、サーバーサイドの開発です。
デザインやHTMLなら、「どこまでできましたか？」と聞いたときに、ある程度は見ることができるんです。Figmaを開いてもらうとか、ブラウザでレンダリングしてもらうとか。
でもプログラムは「モジュール作ってます」と言われても何も動かない。コードが100行あれば進んでいて、20行なら進んでいない、というものでもないんですよね。
だから日々の進捗を聞いて「30パーぐらいです」と言われたら、事実上、問答無用で信じるしかない場面があるんです。
それで明後日になって「想定外だったんで、あと2日かかります」と言われる。「昨日までの60パーは何だったの？」と。言語化されないトラブルとして、だいたいこういうことが起きるんですよね。
なので、自分で可視化できないところに関しては、少なくともお客さんに「遅れました」と言わないようなバッファーの取り方をしておかないといけないと思います。
ただ、そのバッファーも工数として請求金額にどう反映するのかという話が出てくるので、一律には取れません。ここが本当に難しいところです。
ディレクターの仕事は、全部のチケットを完了にすること
結局、王道は地味なんです。毎日、その日までにやることが終わっているか、終わっていないか、いつ頃終わるか。遅れているなら何が遅れていて、どうリカバリーできるか。
それを決めるのはディレクターなのか、クライアントなのか、クリエイティブの方なのか。これを一個一個、毎日詰めていくしかないと思っています。
そのときに私が一番大事だと思っているのは、ディレクターの仕事は、全てのチケットを完了にすることだということです。
それ以外をゴールにしてしまうと、ゾンビになったチケットがいっぱい残っちゃうんですよ。
誰が終わらせるのかよくわからない、なんとなく作業は終わってるっぽい。それを毎日「これ終わってます？」と確認する。もう無意味なんですよね。
終わったものは必ず完了にする。凡事徹底です。小さいことですけど、できることをやっていきましょう、という話です。
そして相談にあった「今日までかかります」と言われたら、「終わらなかった理由はどんなことでした？」と聞く。指示が足りなかったならこちらが直すので教えてください、と。
そうやって一個一個潰していくと、もし本当にサボっていて遅れているなら、だんだんちゃんとした理由が言えなくなってくるはずなんですよ。
これは詰めているわけでも追い詰めているわけでもなくて、お客さんからお金をもらってやっている以上、期日を守るのは当たり前のことなんですよね。
だからこそ、そのことをプロジェクトメンバーで共有できる文化を作らないといけないな、と私自身も思っています。
まとめ
進行管理に魔法のような正解はないと、いまの私は思っています。それでも、感情ではなく事実を見て、可視化して、毎日一個ずつ完了にしていく。地味だけど、これが一番確かなやり方なんじゃないかなと感じています。
- 遅れたこと自体を責めず、「遅れている理由は何か」という事実に目を向ける
- サーバーサイドのように進捗が見えない仕事は、お客さんに向けたバッファーを取っておく
- ディレクターのゴールは全チケットを完了にすること。ゾンビチケットを残さない
- 期日を守るのは当たり前という前提を、メンバーで共有できる文化を作る
