Web制作に限らないと思いますが、受託業務では、納期に遅れそうなことが起きてしまいます。理由は様々ですが、特にWeb制作に関しては、公開間近までクライアント側と制作者との完成イメージのズレから、ほぼ出来た状態から修正が発生することが多いと思います。
納期が遅れそうな場合、制作ディレクターが調整をすることになります。
この調整の仕方により、クライアントやクリエーターからの評価が大きく分かれると思っていますし、ディレクターの手腕の見せ所のひとつです。
本来は遅れないことがベストなのですが、作業度合いによっては、如何ともしがたい場合があります。
顧客至上主義のタイプだったり、調整が苦手なディレクターだったりすると、100％クライアントの要求を実現すべく、クリエーターに圧力を掛けることがありますが、根性論では乗り切れない事態に対する策は必要です。
私の経験上、いくつか押さえるポイントがあります。
まずは制作側の現状を正確に把握しましょう。
現時点でどのくらいできているのか、要件を満たすまでにどのくらいの作業が残っているのか、いつ頃だったら完成できるのか、遅れた要因は何だったのか、懸念点は何なのか、そもそも完成できるスキルを持っているのか、、、、などです。
一般的なプロジェクト管理では、定期的に進捗を確認しながら問題は早期発見というのが理想なのですが、制作側から正しい情報が報告されているとは限りません。特に、プログラム開発プロジェクトより、Web制作については、工数の読みが甘かったり、担当者のスキルに依存する部分が多く、納期前に判明することが多い気がします。
この時点では、感情論で何とかなる余地はなく、冷静に現状把握に全力を入れます。
クリエーター側から「あと少しで何とかする」という回答のみで、現状を公開しないタイプもいます。ですが、余程信頼しているクリエーターでない限り、一旦作業を止めさせて、現状ヒアリングした方がよいと思います。
情報を集めた時点で、ボンヤリとでも、スケジュール感、完成イメージと段階リリースの構想を作っておくことが重要です。次に述べる、クライアントとの調整前に、現プロジェクトの潜在力を掴んでおかないと、調整後も同じ失敗をすることがあります。
次に、クライアントが最低減到達したい内容を把握します。
納期が遅れる非を謝罪しつつも、クライアント側の要求に無理がある旨を説明します。
たいていの担当者は怒りますが冷静になるまで待ち、ヒアリングします。納期ギリギリに遅延連絡をすると対応策の選択肢がなくなるため、危ないなあと感じた時点で早めに情報を伝えることが大事です。
優先度を確認しましょう。
公開期日を守るのが優先なのか、要件を万全にするのが優先なのか、など状況によって異なります。
製品発表のニュースリリースなど、Web以外の要因と絡んでいる場合は、公開期日が最優先です。ほとんどの場合、タイミングを遅延させることはNGです。
開発絡みでサービス品質を重視するプロジェクトは、多少公開を遅らせても要件を満たすことが最優先となることもあります。またクライアント側の試験運用期間がある場合は、運用側が習得すべき内容を把握して、期日と機能を調整していきます。
クライアントと優先度の認識共有ができたら、段階リリースについて相談をしましょう。
Webサービスは、公開までのスピード感が早いので、完全版を一気に公開しなくてもクライアントの要件を満たすことが多いです。残念ながら、双方にこの認識があるため、直前の修正や仮納品、公開後の差し替えなどが一般化していると思うのですが、そういう文化なのかもしれないと感じています。受託のプロとしては失格かもしれませんが、案件の内容が複雑化していて工数が読みづらかったり、クライアントの発注責任上の相応の知識が不足している場合があり、完全に受託側が悪い、という状況ではないケースが多いような気がします。
段階リリースは、クライアントの要件を満たす策としてはアリなのですが、よくあるパターンとして、要望が追加されたり、更新が発生して公開時の確認工数が増えたり、制作側の工数が増えてしまうことがあるので、案件のコントロールが重要です。最初から嫌な予感がするプロジェクトは、工数算出する際に積んでおくことも一つの解決策です。
状況によっては、クライアント窓口担当の上司・社長向けの報告・パフォーマンス向けに、報告書などの作成が必要になる場合があります。この場合は、クリエーターの資源を使うのは本末転倒なので、ディレクターが対応すべきです。例えクリエーターの責任で遅延した場合でも、ディレクターが対応することのメリットがあります。プロジェクト全体としての進行が止まらないこと、クリエーターとの関係性が良くなることが多いことです。
優先度を確認したら、クリエーター（コーディング、プログラムなど関係者一同）に対して、クライアントとの調整結果を共有します。
妥当なスケジュールだった場合は、関係者一同で頑張るだけですが、その策に無理がある場合も予想されます。
無理が判明した時点で、クライアントに相談します。ここで時間を空けてしまうと最悪な事態になります。対応が後手後手になってしまうと、クライアントに迷惑を掛けてしまうだけでなく、プロジェクトのモチベーション低下、品質が悪くなったり、公開後に瑕疵責任という形で無償対応を余儀なくされたり、賠償問題を持ちかけられたり、、、と悪い方向になります。
スケジュールが妥当かどうか確信がもてない場合は、クライアントとコミットするのは避けましょう。持ち帰り判断とさせてもらうか、その場でクリエーターに確認した方がよいです。
クライアント側、制作側と調整ができたら、再度情報を共有します。
スケジュール表でもテキストでもよいので、関係者にメールでを展開するのは一般的ですが、一方的な連絡事項として投げっぱなしにすると、トラブルになることがあります。
調整役のディレクターが思っているほど、クライアントも制作側も認識していないことが多い気がします。
証拠としてメールを送るのは重要ですが、最重要なのは認識してもらうことです。
特にメールの返信にて、重要な箇所に触れてないことがあります。見てないのか、潜在意識が働いて見てないフリをしている場合もあるので、危ないなあ、と思う場合は、打合せや電話で確認した方がよいです。
関係者一同が共通認識が持てたら、納期調整のディレクションは完了です。
あとは品質チェックを甘くしないように気を配りながら、納品までプロジェクトをコントロールします。
納期調整も一種のトラブルシューティングですが、ディレクターとしては日頃から気をつけておくことがあります。
クライアントの要件を把握するのは当たり前ですが、クリエーターとの信頼関係が重要です。
重要なプロジェクトで組むクリエーターの実力を把握しておいたり、他のプロジェクトを掛け持ちしている場合の稼働時間や、完成させるまでのプロセスのクセ（設計重視だったり、作りながら考えるタイプだったり様々）を掴んでおくと、いざというときに安心して取り組むことができます。
番外編として、
実際に見たよくない例を紹介します。
クライアント側の担当者が遅延を気にして社内報告（おそらく上司）のためだけに、制作ディレクターに問い合わせを
するのは当然ですが、連絡頻度が半端ではなく、30分毎に確認をしていました。受けたディレクターは、その度にクリエーターに「いつできる？」と確認の電話を続け、クライアント側へ報告していました。笑い話のようですが、プレッシャーに耐えられないディレクターはそのような行動を取ってしまいます。
結果的に、クリエーターの作業を分断することになります。クリエーターの作業を分断することは、単純に時間の切り取りでは計れません。集中力を再構築したり、アタマの中の構想が消えてしまったりと、分断前の状態に戻すのに時間が掛かります。フロント側のディレクターがクリエーターの環境を考慮すべきです。
クリエーターが遅れている場合に責任転嫁したい気持ちは分かりますが、報告するだけの確認行為は、余程重要なタイミングではない限り無意味なので、ディレクターとしては避けたいものです。