スケジューリングとは？依存関係・稼働日を反映する6ステップ
スケジューリングは、仕事の順序と使える容量を合わせ、実行できる日程を作ることです。希望日を並べるだけでは、同じ人へ仕事が重なったり、承認待ちが工程から抜けたりします。成果物と固定制約を先に確認し、工数・期間・依存関係を区別して組み立てましょう。架空の公開計画を使い、変更時の見直しまで説明します。
スケジューリングで決めるものと必要な入力
決めるのは、各作業をいつ始め、いつ終え、どの条件で次へ渡すかです。入力には成果物、担当、工数の見積、前提となる作業、確認・承認の所要期間、稼働カレンダーが必要です。情報が不足している欄は、適当な値を入れず、誰がいつまでに確認するかを記載します。
基本の流れは、成果物を決める、固定納期を把握する、担当の容量を確認する、期間を見積もる、依存と余裕を照合する、変更履歴を更新する、の6ステップです。順番は一度きりではなく、期間が納期に収まらなければ範囲や担当へ戻って調整します。最初に納期を見ないというルールは必要ありません。
当初の合意を表す計画と、現時点で見込む日付を分けると、状況が伝わりやすくなります。まだ回答を得ていない依存先は、確定値として表示しません。工程表が細かいことより、どの条件が変わると日程が動くかを説明できることが重要です。
成果物・固定納期・担当の稼働日を確認
成果物ごとに、対象範囲と完了条件を確認します。たとえば「LP制作」なら、初稿の提出までか、レビュー反映と公開判定までかで必要工程が違います。外部への約束日、イベント日、素材の利用可能日など、動かせない日付と理由も最初に確認してください。
入力 | 記入例 | 不明なときの扱い |
|---|---|---|
成果物・出口 | 初稿共有後、確認担当が受領 | 確認する担当と回答日を決める |
固定制約 | 公開判定は第12作業日 | 希望日か約束かを確認 |
担当容量 | 制作担当の午前枠を確保 | 別案件との重複を照合 |
稼働日 | 土日・休暇は作業しない | 担当と外部確認者の予定を確認 |
承認条件 | 対象版と判断者を指定 | 決定準備の仕事を工程へ入れる |
同じ日に空きがあるように見えても、必要な技能を持つ担当が使えるとは限りません。社外の確認者にも休暇や受付時間があります。全員が同じカレンダーという前提を置かず、担当と工程に必要な日を確認します。並列工程では同じ担当の二重割当にも注意してください。
未決事項そのものを工程から消すと、決まるまでの時間も消えてしまいます。「契約条件を決める」なら、必要資料を集める担当、決定者、回答が必要な日を明示します。決定結果によって作業量が変わるなら、その分岐を前提やリスクとして残しておきます。
工数と待ちを区別して期間を見積もる
工数は作業量、期間は開始から終了までの幅です。16人時の作業を、1人が1日4時間ずつ行うなら単純計算では4作業日です。2人へ分けられるかは仕事の構造次第で、人数を増やせば必ず半分になるわけではありません。共同作業や引継ぎに必要な時間も考えます。
確認待ちは経過期間として扱い、実際にレビューした人時と分けます。2作業日の確認枠には、確認者の順番待ちが含まれるかもしれません。制作担当が別業務をできるなら、その2日を制作の実工数へ加算しません。ただし、修正が戻る可能性と必要な実作業は別途見積もります。
Microsoftのスケジュール計算の説明は、作業量、割当、期間とカレンダーを区別しています。この区別を参考に、作業日数から休日を飛ばして日付へ変換します。単純な除算の答えを暦日や対外納期と同一視しないようにしましょう。
依存関係・節目・余裕から実行可能性を確認
先行作業を、単なる一覧の順番でなく開始条件として指定します。要件承認の前に実装できないなら、その依存を残します。一部だけ並行できる場合は、何を確定すれば着手できるか、後で修正するリスクを誰が受け入れるかを確認してください。
節目には判定者、対象版、証拠を用意します。作業が終わっていても判断待ちなら、公開可能とは限りません。Microsoftのクリティカルパスの解説も参考に、最終日へ影響する連鎖と余裕を確認します。どの作業の遅れも必ず全体の遅れになる、と決めつけないことが大切です。
余裕の置き方は、未知の工程、外部回答、再確認が必要な場所から考えます。末尾へ一律に10%足すだけで、途中の固定引渡しを守れるとは限りません。積上げで最早の完了見込を求め、固定日から逆算して間に合うかを照合し、無理なら範囲・順序・日付・支援を決定者へ戻します。
記入例：12作業日の公開計画
以下は、必要な担当の容量を確保し、休日を除く第1〜12作業日で考える架空の計画です。Cは顧客確認の経過期間であり、2人日の実労働という意味ではありません。公開判定は第12作業日の終業時に行う節目とし、必要資料が判断時刻までに揃うことを条件とします。
ID | 作業・節目 | 期間 | 先行 | 計画枠 |
|---|---|---|---|---|
A | 要件確定 | 2作業日 | なし | 第1〜2日 |
B | デザイン | 3作業日 | A | 第3〜5日 |
C | 顧客確認 | 2作業日 | B | 第6〜7日 |
D | 実装・確認 | 4作業日 | C | 第8〜11日 |
M | 公開判定 | 0日の節目 | D | 第12日終業時 |
直列の期間は2＋3＋2＋4＝11作業日で、第12日の判定まで1作業日の余裕があります。Cが3作業日へ延びるとDは第9〜12日となり、余裕を使い切ります。この場合、判定に必要な資料が当日の判断時刻までに揃うかを再確認し、同日完了が無理なら公開予定へ影響します。
この1日は普遍的な推奨値ではありません。休日や別案件が入れば日付は変わり、Dの担当が第9日に不在なら同じ計算になりません。Cの回答が段階的に届く場合も、部分着手の安全性と再作業の可能性を確認してから計画を変えます。
変更時の影響・判断・計画履歴を更新
遅れが分かったら、元の納期を消して新しい日付へ置き換えるだけで終えないようにします。当初計画、現在見込、変わった前提、影響する後続、決定者の判断を残します。承認待ちなら、変更案を確定事項として共有せず、回答期限も添えて伝えてください。
記録 | 変更前 | 変更後の見込 | 理由・判断 |
|---|---|---|---|
C確認期間 | 2作業日 | 3作業日 | 確認者の回答可能日変更 |
D実施枠 | 第8〜11日 | 第9〜12日 | Cの後へ移動、担当容量を再確認 |
M公開判定 | 第12日 | 第12日中は条件付き | 資料の完成時刻を確認、責任者が判断 |
対策は作業時間を無理に詰めるだけではありません。範囲を分ける、代替担当を置く、先に確認できる部分を渡す、納期を合意し直すなどを、品質や追加費用への影響と一緒に検討します。作業が減っても承認待ちは短くならない場合があるため、遅れの原因に合う対策を選びます。
毎回同じ場所で止まるなら、次回の期間見積、必要資料、回答者との約束を修正します。日付の移動回数だけで計画の良し悪しを判定せず、早く変化を把握できたか、影響を伝えたか、決定が記録されたかを振り返ります。計画は固定した約束を守るための基準であり、変化を隠すための表ではありません。
更新時は、実績の完了時点と、残作業の見積を分けます。開始しただけで期間を半分消化したと置かず、残る成果物と確認条件から現在見込を出します。進捗率だけでは回答待ちの長さや担当の不在は分からないため、未完了の条件を一緒に確認してください。完了した工程の実績は、次回の類似工程の見積を見直す材料になります。
工程表には更新日と対象版を付け、関係者が最新の見込を確認できる場所を決めます。個人用の予定表へ転記する場合も、元の工程IDや参照先を残すと、日付が違うときに確認できます。週次の報告では、すべての行を読み上げるより、変わった前提と判断が必要な点を取り上げます。見込が変わっていない場合でも、未解決の重要条件が消えたとは考えないようにしましょう。
次に使える関連記事
タスクの進行を施策単位で扱い、月次計画と承認済み予算も確認したい場合は、Xtrategyのプロジェクト機能をご覧ください。Xtrategyでは施策のタスク進行をプロジェクト内で管理し、月次計画と承認済み予算を並べて確認できます。関連する予算・CRM・承認情報へ遷移できます。