プロジェクトのスケジュールはどうやって作成すればいいの？
WBSを作成すればスケジュールは完了でしょ？
スケジュールの立て方を知りたい！
プロジェクトマネジメントにおいて、WBSの作成はとても重要であり、漏れなくダブりなく作業を書き出してWBSを完成させる必要があります。
しかし、無事にWBSが完成しても、スケジュールが完成したわけではありません。WBSだけでは、それぞれの作業の依存関係や順序がわかりません。
WBSが完成したら、次は作業の依存関係や順序を検討し、工数と所要期間を見積もって、作業を行う時期と担当者を決めてスケジュールが完成します。
ここでは、プロジェクトのスケジュールの立て方を6つのステップでわかりやすく解説します。少しでもプロジェクトマネジメントの参考になれば幸いです。
スケジュール完成までの6つのステップ
プロジェクトのスケジュールは、次の6つのステップで作成します。
なお、ここで説明するスケジュールとは日程表のことであり、システム開発のプロジェクトにおけるスケジュールを想定した内容となっております。
- スケジュールに影響する前提条件と制約条件を洗い出す
- WBSを作成する（作業を書き出す）
- 作業の依存関係を確認して順序を決める
- 作業の工数と所要期間を見積もる
- 作業の開始日と終了日、担当者を決める
- 予備期間を追加する
ここからは、それぞれのステップについて詳しく解説します。
①スケジュールに影響する前提条件と制約条件を洗い出す
まずはスケジュールに影響する前提条件と制約条件を洗い出します。
前提条件とは、計画通りに進めるために前提となってくる条件のことです。 実際のプロジェクトで発生するであろう事例を下記に記載します。
- 現在の業務フロー図やマニュアルは存在しないため作成する必要がある
- 対象業務に詳しい実務担当者をプロジェクトメンバーにする
- 経理部門のメンバーはプロジェクト兼務のため、1日の活動時間は3時間以内にする
- 営業部門の業務はシステム化しない（現行のままとする）
- 新システムの操作教育はお客様のキーマンのみとし、全社展開はお客様のキーマンが実施する
- 新システムに合わせて業務を見直す（カスタマイズしない）
制約条件とは、外的要因によって発生し、変更できない条件のことです。プロジェクトに参画する関係者によって発生するもので、プロジェクト計画に制限がかかるようなものです。こちらも事例を記載します。
- 現行システムで利用しているサーバの保守契約が２年後に切れる
- 消費税率が変わる〇〇年〇〇月までにシステム改修する必要がある
- データ連携先のシステムが再構築されるため、それまでに当社のシステムも改修する必要がある
- データ連携先が多いため、サービス停止できるのは年末年始の3日だけで、その期間でデータ移行する必要がある
- 会社が合併する〇〇年〇〇月までに新システムを導入する必要がある
このように、いわゆるヒト（人員）・モノ（物的資源）・カネ（資金）に関する条件はないか、絶対に譲れない期限はないかを事前に確認する必要があります。
また、この事例にはありませんが、開発メンバーのスキルに問題がないか（研修が必要か）、開発用PCや新規導入するサーバ機器の調達、納入時期に問題がないかなど、システム開発側も洗い出しましょう。
②WBSを作成する（作業を書き出す）
次にプロジェクトの作業を洗い出してWBSを作成します。WBSが3つ目以降のステップのベースとなりますので、精度の高いWBSを作成しなければなりません。
WBSの作業の書き出し方やポイントをこちらで分かりやすく解説していますのでご参照ください。
③作業の依存関係を確認して順序を決める
WBSに書き出した作業（ワークパッケージ）の依存関係を確認し、作業の順序を見直して並び替えます。
ネットワーク図
作業の順序や作業の依存関係を表した図をネットワーク図と言います。ネットワーク図を作成すれば、作業の依存関係を明確にすることができ、最適な順番で作業を進めることができます。
ネットワーク図についてこちらで解説しています。よろしければご参照ください。
ネットワーク図の書き方は簡単ですが、プロジェクトマネジメントツール（Microsoft Projectなど）を活用すると効率よく作成できます。
ここでは作業の依存関係のパターンについて説明します。下図を見ながら読み進めてください。
並行関係
複数の作業を同時に実施できる場合、それらは並行関係になる作業です。スケジュールを短縮したい場合、リソース（開発メンバー増員など）を十分に確保して並行で作業を進めるのが有効です。
また、お客様が担当する作業（マニュアル作成やユーザー教育など）とシステム開発は並行に実施できる作業になります。
前後関係
作業を順に実施する場合、それらは前後関係がある作業です。例えば、作業Aと作業Bがあり、作業Bは作業Aが終了しないと開始できない場合、作業Bは作業Aに依存する関係となります。このようにそれぞれ先行と後続の前後関係がある作業を指します。 前後パターンには、この例を含めて4つあります。
| 作業Aー作業Bの 依存関係 | 説明 |
|---|---|
| 終了ー開始パターン | 作業Aが終了しないと、作業Bを開始できない。（一番多いパターン） 例）要件定義が終了しないと設計が開始できない。 |
| 開始ー開始パターン | 作業Aが開始されるまで、作業Bが開始できない。 例）画面設計が開始されないとテーブル項目定義は開始できない。 |
| 終了ー終了パターン | 作業Aが終了しないと、作業Bを終了できない。 例）テストが全て終了しないと開発完了の品質検査は終了しない。 |
| 開始ー終了パターン | 作業Aが開始されるまで、作業Bを終了できない。 例）新システムがサービス開始するまで旧サービスのバッチ処理は終了できない。 |
WBSは、作業を階層で書き出したもので、作業の依存関係はわかりません。依存関係がシンプルな小規模プロジェクトであればWBSだけでも問題ないかもしれません。
ですが、どんなプロジェクトでも、なにかしら作業間には依存関係があり、守らなければいけない順序があるはずです。それらを考慮したネットワーク図を作成することで最適なスケジュールを作成することができます。依存関係がどのパターンに当てはまるかよく考えて作業の順序を検討しましょう。
④作業の工数と所要期間を見積もる
工数の見積もり
それぞれの作業に必要な工数を見積もります。過去の類似プロジェクトや経験から工数を求めたり、担当予定のメンバーに工数の見積もりを依頼してもいいでしょう。
ただし、メンバーに見積もってもらう場合、自信がない者は工数を水増ししたり、逆に自信過剰な者は少ない工数を出している可能性もありますので注意が必要です。 担当者が見積もった工数の根拠を確認して妥当かどうか判断することも大事です。
所要期間の見積もり
工数が算出できたら、次は所要期間を見積もります。所要期間とは、作業が完了するまでにかかる期日のことで、工数と同じになるとは限りません。
例えば、要件定義でお客様とヒアリングを10回行う場合、1回あたり2時間であれば工数は20時間となりますが、1日にヒアリングは1回実施する予定だと所要期間は10日となります。お客様の都合でヒアリングが中止されることもあると思いますので、日程変更の余裕も考慮して10日＋αの所要期間を見積もりましょう。
システム開発会社に委託する場合は、委託会社に見積もりを要求します。この時も同様に、見積もり結果を鵜呑みにせず、見積もり根拠を確認し、プロジェクトの意向から外れる場合は交渉することも重要です。委託先はプロジェクトを一緒に進めるパートナーです。強引な交渉や無理な要求は絶対にしないこと。プロジェクトの目的を達成するために協力してもらえるパートナーを探しましょう。
リスクを想定した所要期間を見積もる方法（3点見積もり）
プロジェクト全体の所要期間は、個々の作業（ワークパッケージ）の所要期間を積み上げて求めるわけですが、それだとリスクが考慮されていません。プロジェクトには必ずリスクが潜んでいます。つまり、リスクを想定した所要期間を見積もる必要があります。
プロジェクトマネジメントの手法にPERTというものがあります。
PERTとは、プロジェクトマネジメントの際に用いられる手法の一つ。特定のプロジェクトの完遂までに必要なタスクを洗い出し、相互関係を明確にすることによってプロジェクトを素早く達成することを目的とする。
引用：ウィキペディア｜PERT
PERTでは、楽観的見積もり、標準的見積もり、悲観的見積もりの3つの見積もりを組み合わせて、最も可能性が高い見積もりを算出します。
| 見積もり種類 | 意味 | 例 |
|---|---|---|
| 楽観的見積もり | 全ての作業が問題なく進んだ場合を想定した所要期間の見積値 （最良の見積値） | 50日 |
| 標準的見積もり | 通常発生すると思われる問題を加味して楽観的見積もりよりも 少し遅延する所要期間の見積値（現実的な見積値） | 60日 |
| 悲観的見積もり | 考えられる問題が多く発生し、作業が最も遅延する所要期間の 見積値（最悪の見積値） | 100日 |
この3つの見積値を以下の計算式に当てはめて見積もりを算出します。
【計算式】全体の所要期間＝(楽観的見積値+4×標準的見積値+悲観的見積値)÷6
上表の例を当てはめると、(50+4×60+100)÷6＝65となり、プロジェクト全体の所要期間は65日と見積もることができます。
このように、プロジェクトのリスク度合いによって標準的見積もり、悲観的見積もり、3点見積もりのいずれを採用するか決めましょう。 ただし、どんなに小さなプロジェクトでもリスクは付きものですので楽観的見積もりは避けるのが無難です。
⑤作業の開始日と終了日、担当者を決める
作業の工数と所要期間が見積もれたら、それぞれの作業の開始日と終了日を決めていきます。③のステップで決めた作業の依存関係や順序を確認しながら、それぞれの作業の開始日を設定します。開始日に所要期間を足したものが終了日になります。
全ての作業の開始日と終了日を設定すると、プロジェクト全体の総所要期間とクリティカルパスが決まります。そして、クリティカルパスにある作業の所要期間の合計が、プロジェクト全体の総所要期間ということです。
クリティカルパスから担当者を決める
プロジェクトの最初の作業から最後の作業までを繋ぐ経路は、作業の依存関係によって複数の経路ができます。その経路のうち、所要期間が最も長くなる経路のことをクリティカルパスと言います。
クリティカルパスの作業はいずれも余裕がなく繋がっています。作業Aが終了後すぐに作業Bを開始し、作業Bが終了後も間を空けずに作業Cを開始するという具合です。
そのため、クリティカルパス上の作業が1つでも遅れると、プロジェクト全体の進捗に影響することになります。まさに、非常に重要（クリティカル）な経路（パス）というわけです。
クリティカルパスの求め方はこちらで解説しています。あわせてお読みください。
プロジェクト全体に影響するクリティカルパス上の作業は慎重に計画する必要があります。そのため、クリティカルパスの作業から担当者を検討するのが良いでしょう。経験豊富なメンバーをクリティカルパスの作業にアサインすることで遅延のリスクを低減し、クリティカルパス上に無い作業（多少遅れても問題ない作業）は経験が浅いメンバーをアサインするなど、 クリティカルパス上の作業を優先して検討し、そこから他の作業へ検討を進めていきます。
担当者をアサインする時に注意すること
マネジメント系時間
進捗報告に関する作業時間や会議時間など、マネジメント系の時間を考慮することが大事です。特にリーダー以上の役割があるプロジェクトメンバーは別途確しましょう。
担当者の生産性
担当者のスキルによって生産性は変わってきます。そのため、スキルに照らし合わせたアサインと教育計画が必要です。経験の浅いメンバーのスキルアップを図るために教育時間が必要ないかを検討しましょう。
担当者の活動時間
前提条件の事例にもあるように、本来の業務とプロジェクトを兼務するため1日3時間しかプロジェクト活動できない担当者がいるかもしれません。担当者の稼働時間を無視したアサインをしないように気をつけましょう。
担当者の非稼働日
有給休暇や特別な長期休暇（会社から個人に与えられる特別な休暇）、定期的な通院など、担当者の非稼働日を考慮しましょう。
外部委託メンバーの増員
システム開発の場合、フェーズが進めば開発要員は増えていきます。システム開発を外部委託することが多いと思いますが、開発要員のアサインには時間がかかります。そのため、どの時点でどのようなスキルを持った要員が必要なりそうかを外部委託先と共有することが重要です。
担当者の負荷を平準化する
全ての作業の担当者を決めたら、次は担当者の負荷を確認します。担当者の作業量を確認し、特定のメンバーに負荷が偏っている場合は作業量を調整して負荷を平準化します。
ひとりの担当者の負荷が、週単位に高い週と低い週があれば、負荷が高い週の作業を低い週に振り分けることができないか検討します。
月単位に特定の担当者に過剰な負荷がかかっている場合は、負荷が少ない担当者に作業を割り当てます。この時、担当者のスキルに不足はないか、既に割り当てている作業と時期が重なっていないかも注意する必要があります。
どうしても負荷の平準化ができない場合、スケジュールを見直したり（作業の順序を変更など）、担当者の増員を検討しましょう。 間違っても、この計画段階で残業時間を含めて計画してはいけません。残業は万が一スケジュール遅延した時の最終手段です。
スケジュールの短縮を検討する
担当者の負荷を平準化した結果、スケジュールが想定している期限より遅れそうなら、クリティカルパス上の作業の所要期間短縮を検討する必要があります。
所要期間の短縮は次の2つの方法があります。
クラッシング
ヒト（人員）・モノ（物的資源）・カネ（資金）を投入して所要期間の短縮を図る方法です。例えば、所要期間が長い作業の担当者（人員）を増やすことで短縮ができないか検討します。基本的に人員を増やせば所要期間を短縮できますが、担当者を倍にすれば所要期間が半分になるような単純な作業ばかりではありません。担当者のスキルや生産性の違いによって短縮できる期間は変わるはずです。
特別なスキルが必要で増員ができない作業であれば、一時的に残業でカバーする方法も一つですが、残業だけで切り抜ける計画では生産性も落ちるため注意が必要です。特別なスキルが必要な作業があれば、事前に研修を行なって増員メンバーのスキルアップを図るように計画を見直すことも大事です。
ファスト・トラッキング
前後関係の作業を並行関係に見直したり、前倒して作業を開始することで所要期間の短縮を図る方法です。例えば､複数台のサーバを購入してセットアップする作業があったとします。サーバを一度に納品されても1台づつしかセットアップできない作業であれば、サーバの納品を複数回に分納してもらうことでセットアップ作業を前倒しできます。
ただし、無理な前倒しには要注意です。 特に要件定義が全て完了していないのにシステム設計を前倒しで着手したり、関連のあるサブシステムの設計が完了する前にプログラム開発に着手することは厳禁です。もし途中で要求が見直されて要件定義が変わったり、設計の仕様変更があると手戻りが発生するためです。あくまでも無理のない範囲で作業の前倒しを検討しましょう。
⑥予備期間を追加する
お客様からの要求変更や、システム開発上の問題発生、社外のデータ連携先からのテスト日程変更など、必ずスケジュールを修正することが起こります。そのため、計画通りにいかないことも想定しておく必要があります。
つまり、スケジュールに予備期間を追加して余裕を持たせるということです。予備期間はスケジュール全体の所要期間に対して10〜15％程度を追加することを検討しましょう。
難易度が高いプロジェクト、長期日程のプロジェクトは多めに設定するのが良いと思います。 ただし、個々の作業に余裕を持たせた期間にしてはいけません。実作業を水増しすると正確な作業期間がわからず進捗管理ができなくなるためです。スケジュールが遅延した時はしっかり対策をした上で、予備期間を取り崩してスケジュールを修正しましょう。
スケジュールが変わるということは、少なからずコストにも影響しているはずです。スケジュールに予備期間を追加すると同じく、コストにも予備費を追加しておきましょう。
システム開発の見積もりについて詳しく知りたい方はこちらもお読みください。なぜ見積もりを失敗するのか、見積もり方法とポイントを解説しています。
スケジュールは一度作成したら終わりではない
スケジュールは一度作成したら終わりではありません。プロジェクトは常に変化していきますので、それに合わせてスケジュールも見直して修正する必要があります。
前述の通り、お客様からの要求変更や、システム開発上の問題発生、社外のデータ連携先からのテスト日程変更など、必ずスケジュールを修正することが起こります。完璧なスケジュールを作成することも難しいでしょうから、単純な見積もりミスもあると思います。
ですので、プロジェクトの変化に合わせてスケジュールを修正し、常にクリティカルパスに影響がないかを確認しながら進めましょう。
