うぃっす、僕です。
先日、スケジュールの作り方について投稿したところ、少し反響があったので需要があるかと思いコラムを書かせていただきました。
その時の投稿↓
どの制作会社でもある課題『クライアントがスケジュールを守ってくれない』についてみんなはどう対応してる？
— タケ（幸野剛士）東京Webディレクター🦒 (@takelogtake) February 28, 2025
『あらかじめ少し余裕をもったスケジュールを作って、それを調整する感じでうまくやり繰りしてる』って感じかしら？
※クライアントを落とすような表現。非常によくない。皆さんマネしないように。
プロジェクトを進めるうえでほぼ間違いなく必要になるスケジュール。とくに所属先や人によって使うツールや作り方など多種多様かと思いますが、『プロジェクトを達成することを目的として作成されている』という点では全員等しく同じではないでしょうか？
今回はその『スケジュール』の作り方について解説してみたいと思います。
これがワイの作り方や(`･ω･´)b
スケジュールを作成する際に確認しておきたいこと
まず、スケジュールを作るにしてもそのプロジェクトの内容や納期、必要な素材や環境などを確認、調査、整理が必要です。これを怠るのは冷蔵庫に何が入っているか分からない状態で急にカレー作るようなもんです。
最低でもポークかビーフかチキン、野菜があるか、ルーは買いに行く必要があるか程度は確認しておきましょう。
以下、クライアントとプロジェクトにあわせて使い分けて確認しておきましょう↓
- 希望納期
→いつまでに公開したいか(完了にしたいか)確認しておきましょう。またその公開日は状況次第で後ろにズラすことが可能かもかくにんしておくと、トラブルが発生した時、あるいは追加要件で作業が増えてしまったときに進行を見直すことができるので必ずかくにんしておきましょう。 - 何をしたいのか
→コーポレートサイトのリニューアルなのか、新規ページの作成なのか、LPなのか印刷物なのか、当然ですが明確に何を作りたいのか確認しましょう。注意点としてはクライアントは同じ業界で働いているわけではないため作りたいものを表現するときに使用する言葉が異なるケースがあります。その点だけ注意して確認しましょう。参考サイトとかがあるといいかもしれません。※以前「バナーを作ってほしい」と言われたことがありますが実際に作ったのはWebサイトのメインビジュアル(キービジュアル)でした。 - それは何枚作成が必要なのか
→例えばコーポレートサイトのリニューアルが100ページの場合と1000ページの場合だと工数もプロジェクトの進め方、アプローチも大きく変わります。なので必ず何枚(何ページ)必要になるのか確認しましょう。ただし、クライアントはWebのプロではないので漏れてしまうケースがあります。さらに既にあるサイトをいじる場合は仕様によっては対象外のページにも影響が出る可能性があるので(というかほぼ確実に出ます)、最終的に対応が必要なページ数を把握するために要件定義をする期間を設けるようにしましょう。 - 納品方法
→プロジェクトによっては『データを納品することで完了』となるものや、公開作業まで対応して終わりになるものがございます。大手企業の場合だとサーバへのアクセス権限はいただけないケースが殆どになるため、この場合多くは『データ納品』となるでしょう。クライアントやプロジェクトによって変わってくる部分になるので必ず確認しておきましょう。 - アクセス解析の有無
→みんな大好きGA4やアクセス解析系のツールのお話です。既にサイトに仕込まれている場合は『規定のタグ・コード』が存在するため、それを入れることになると思います。クライアントからすると「言わなくてもそれくらいはやるもんじゃないの？」って思われがちの要件になるので漏れないように注意が必要です。また、まだGA4など使ったことがない、でも使いたいというケースもあるので運用方法とセットでヒアリングしてみるのをおすすめします。 - 素材支給の確認
→素材を購入する必要があるのか、支給してもらえるのか、支給日はいつ頃になりそうなのか、いつまでにもらわないとサイトへの反映が間に合わなくなるのか、確認して会話しておきましょう。ありがちなのが「写真はクライアント側で撮影するんだけど、撮影日が公開ギリギリになる」です。注意が必要です。また購入が必要になる場合はライセンスの観点と誤って購入した際の費用負担の懸念があるためクライアント側に購入していただくように促すことをおすすめします。 - 開発環境の確認
→既にある本番環境に直接つくっちゃうぜ！というケースは置いといて、殆どが開発環境を準備し作成を進め、合意が取れたら本番環境へ移設するという流れになると思います。クライアントやプロジェクトによってはこの開発環境が既に用意されているケースがあるのでキチンと確認しておきましょう。無い場合はこちら側で環境構築を行う必要があります。その場合は環境を用意する際に本番環境と出来るだけ近い環境を用意しないといけないので注意が必要です。開発環境を用意する際は事前にエンジニアに注意点を聞いておくとよいでしょう。※開発環境では動いたけど本番環境では動かないとかならないように。 - 公開する際の担当、日時の確認
→公開する際、クライアント側で対応してもらえるケースとこちらで行うケースがあります。なので必ず誰(どこ)が対応するのか確認しておきましょう。また、その際は日時も確認しておきましょう。休日に公開が必要な場合、深夜公開が必要な場合で勤務先への説明や許可が必要になったりします。Web制作の正念場になるところですね。がんばりましょう。 - 商流の確認
→例えば、エンドクライアントへの確認までに『自社』→『代理店』→『エンドクライアント』という風に1社入る場合、この間の1社との連携が悪くなるとスケジュールが遅延する危険性が増します。また、代理店がエンドクライアントへ説明しやすくするために資料の作成が必要になるケースも出てくるので必ず商流を確認しましょう。思っているより工数は増えますし、提出物も増えたりします。 - 連絡手段の確認
→みなさんSlack派ですか？チャットワークですか？プロジェクトによってはメールだったりLINEになるケースもあります。普段使い慣れていないツールでやり取りをしないといけなくなるとストレスと負担が大きくなるので必ず確認しておきましょう。初めて触るツールが出てきたら最低1日はそのツールを触る時間をもらえるといいかもしれません。 - 支払いサイト(期間・間隔)の確認
→長期に渡るプロジェクトになると気になるのが『毎月支払ってくれるのか』『プロジェクト完了時に総支払いなのか』になります。会社によっては申請などでややこしくなって入金に時間がかかるケースも出てきます。生きていくためにはお金が必要なのでサクッと確実に確認しておきましょう。 - 契約書、見積書、発注書の確認
→言わずもがなです。制作会社を経験したことのないフリーランスだと、このあたり無知なケースもあったりして驚くことがあるのですが(すみません他意はないです)、仕事をするうえで自分を守るためにも契約書を必ず確認して(取り交わして)おきましょう。また、発注書をいただいてから仕事をするようにしましょう。悲しいことに『口頭約束でもらった仕事が正式発注じゃなかったから失注する』ということが毎年どこかで起きています。悲しみを減らすためにも必ず書面で発注書をもらいましょう。プロジェクトによってはざっくり勘定の見積書を提出して要件定義で必要な作業を確認して正式見積を出して、そこから正式発注となるケースもあるのでクライアントとの関係性を踏まえて対応したいですね。 - 請求する際に必要になるエビデンス有無
→クライアントやプロジェクトによっては毎月の請求にあわせて『作業完了報告書』や『何をつくったのか証明する資料』が必要になるケースがあります。地味にこれに工数を取られるケースがあるので長期のプロジェクトのときはそれを踏まえて対応する必要が出てきます。クライアントには「請求書送らせてもらうときに追加で用意しないといけないものってありますか？」とサクッと確認しておきましょう。 - 公開後に残作業が発生しないか確認
→制作したものによっては公開後に少しだけ調整したドキュメントを提出するケースがあります。仕様書やガイドラインなんかはそれにあたります。公開するとどうしても気が抜けてしまうので注意が必要です。必ずスケジュールに抑えておきましょう。 - デザイナー、エンジニアのリソース確認と確保
→当然ですが、ディレクター1人で何かを作ったりするようなプロジェクトは殆どありません。規模が大きくなればなるほど人員は必要になりますし、その人の時間も確保しておく必要があります。なので必ずデザイナーやエンジニアを確保しておくのと、もしその時点でプロジェクトの要件がある程度見えていたら共有し説明しておくといいでしょう。気づかなかった漏れとか発見してもらえるケースがあるので早め早めに確保しておきましょう。 - 祝日の確認
→最近は便利なツールが増えたので気にしなくてもよくなってきましたが、長年同じフォーマットのExcelでスケジュールを作成・管理している場合、誤って祝日をカウントしてしまったまま作成してしまうことがあります。この1日のズレに過去何人も泣いているので必ず含まれていないか確認しておきましょう。 - クライアントの長期休暇など
→エンドクライアントの担当者、あるいはその担当者の上長が2週間不在となる。そんなときプロジェクトが完全に止まってしまうケースがあります。そうならないように長期不在のときの承認フローの確認、代理が立てられるかの相談、その期間を避けたスケジュール作成など会話しつつ、うまく調整(便利なことば)しましょう。
けっこう重要なことを書いたつもりなので拡散してね(`･ω･´)b
上記のような要素をスケジュールを作る前に確認しておくと精度の高いスケジュールを作成することが可能です。もちろん「それは進行してみないと分からない・変わってくるから回答しづらい」という部分も出てくると思うので、そのあたりはプロジェクトの前半部分で『要件定義』というフェイズを設け、そこで会話をして課題ができるだけクリアになるように対応しましょう。
（ ＾ω＾）・・・
（ ＾ω＾）・
（ ＾ω＾）話がなげーよ
では実際にスケジュールを引いてみましょう
例えば、ある日ふだんから付き合いのあるお客様から突然こんなメールが来ました。
“お世話になっております。
弊社で作成中の○○製品なのですが、これを今後売っていきたいのでLPを作成してほしいです。
作成していただくLPは公開後に自社のサイトからもアクセスさせたいと思っています。
5月中に公開したくです。
お手数ですが、見積とスケジュールを来週の水曜日までにお願いできますでしょうか？”
やったぜ。仕事や。じゃあ見積とスケジュールを作るか、、、お礼のメール書くか、、、
“お世話になっております！
ご依頼ありがとうございます！
承知いたしました！
早速、御見積とスケジュールを作成してまいります。
もし、既にどんなページにしたいか参考ページがございましたら
御見積やスケジュールに反映させたいのでご共有いただければと存じます。
また、『実はこんな風にしたい！』あるいは『こういうのは困る』的なことがございましたら
あわせてご連絡いただけますと幸いです。
ひとまず
・LP1本分
・アニメーション無し
・御社サイトから導線設置複数
の想定で御見積とスケジュール作成進めてまいりますので
よろしくお願いいたします！”
※ここでヒアリング用のシート作って送付するといったテクニックもあり
※御見積とスケジュール作成するうえでこれは聞いておきたい。ということを確認するイメージです。
上記のように相手が急いでいそう＆時間があまりないときは『こういう想定で作るから気になることがあったら連絡してね』と伝えておくとお互い楽に進みます。
もちろん、しっかり内容を確認してから作成するのもありです。
状況と関係性を考慮して対応しましょう。
では本題に戻ってスケジュール作成です。
僕ならこんな感じに作ります。
作成したスケジュールがこちらです↓
解説すると(照らし合わせてご確認ください)
- だいたい1発、2発で合意を取れる前提でスケジュールを組んでいます
→何回やり直しが発生しそうかはプロジェクトによって変わってくるので、楽観的なスケジュールを組むと大変な思いをするのですが、逆に2発程度で合意をもらうつもりでスケジュールを組まないと長期間にわたって苦労をするので基本的にやり取りは2往復位で終わる前提で作成されるのを推奨します。※例えばデザインは2回で合意を取る。など - 見積、スケジュール作成の期間を入れています
→見積もスケジュールも作るのに工数がかかるので、それ自体もスケジュールに入れています。このあたりは勤務先によってルールが変わってくるところですが、個人的には作業の1つではあるので入れるのを推奨します。 - 作成、提出、確認期間、FB、FBの内容確認、調整、再提出、、、
→上記のように1つ1つ細かく分けています。細かく分けてスケジュールを作成すると、どうしても日数が膨らんでしまうのですが、あえて膨らまして作成し、それで問題があるようだったら項目を統合、あるいは日数を削って調整することを推奨します。最初から日数や項目を削ってスケジュールを作成してしまうと漏れに繋がる原因になるのであえて最初は多めに日数を盛りつつ、項目は分けて作ってみましょう。 - 原稿と素材の支給、metaのFIXは実装前に
→テキスト原稿、画像(動画)素材、meta情報は実装中の後半でも取り込んで対応することはできるケースがほとんどだとは思いますが、実装前に指定するのを推奨します。理由としては2つあり、1つはエンジニアが実装する際に情報が整っていない状態だと気持ちがよくないのと、また、もう1つは締め切りを後半に持ってきてしまうと間に合わなかったときに負荷が大きくなってしまうからです。 - 予備日をあえて1日いれる
→この1日という日数事態に意味はあまりないです。ただクライアントとお互いに『1日も猶予のないプロジェクト』という認識を持ってしまうとお互いに余計な焦りが生まれかねないので、そういった意味で1日でも最低入れておくとよいです。個人的には2日、3日くらい取れると熱いです。
と、だいたいこんな感じです。
重要なのは
項目は細かく分けて日数を膨らましてつくる→クライアントと確認を取る→問題がなければそのまま
かなと考えております。
「もっと早く公開したいからスケジュールを調整してほしい！」と指摘されたら、細かく分けた項目のどことどこを統合させるか、あるいは削るかをデザイナーとエンジニアと協議してスケジュールのスリム化を目指しましょう。
さいごに
コーポレートサイトの新規作成、フルリニューアル1000ページ、撮影ありの特設サイト作成、、、などなど他にもいろんなプロジェクトがあります。アニメーションやディティールに拘ったりすると更に複雑で細かいスケジュールになると思います。プロジェクトごとに着手する手順も違ければ、それぞれにかける日数も大きく変わるのでスケジュール作成に自信がない方は周りの知見ある人にアドバイスをもらうことをおすすめします(`･ω･´)b
また、プロジェクトというものは鶴の一声で方向転換してしまうケースもあります。そのため、定めたスケジュールを守ることに固執しすぎないように、常に柔軟に調整できるように行動することをおすすめします。※例えば予定より早められる項目があるなら早める。とか。
コラムで解説すると少しわかりづらかったかもですが、参考になっていたら幸いです。
参考になってたらSNSとかコミュニティ内でも拡散してね(`･ω･´)b
ではまた👋
