プロジェクトスケジューリングの決定版ガイド

使用するプロジェクトスケジュールの種類を決定したら、作成を開始します。 このプロセスは、業界、組織、プロジェクトの種類によって異なる場合があります。 しかし、プロジェクト管理の専門家の多くは、以下のステップに従うことを推奨しています：

1. ブレインストーミング・ミーティングを開催します。 ほとんどの専門家は、他の関係者の参加に関わらず、チームミーティングでスケジューリング・プロセスを開始することを推奨しています。 スケジュールの大まかな概要や、議論を始めるアイデアのリストを作成するとよいでしょう。 しかし、会議の主な目標は、プロジェクトに実際に取り組む人々からのフィードバックを求めることです。 

 

 

チームメンバーは、仕事にどのくらいの時間がかかるか、そして自分の能力は何かについて独特なインサイトを持っています。 さらに、この段階でチームを関与させることで、プロジェクトの賛同を得ることができます。 

 

 

また、クライアントや他の関係者からの意見を求めることもできます。 スケジュールに影響を与える可能性のある組織外の要因 (例えば、クライアントの会社や業界のルールや規制など) について、独自のインサイトを得られる場合があります。 
 
このステップでは、上記にリストした関連文書をいくつか参照することをお勧めします。 これらは、プロジェクトの目標、範囲、制約、成果物、成功基準、関係者の期待をよりよく理解するのに役立ちます。

2. 明確で測定可能なマイルストーンを決定します。 マイルストーンとは、プロジェクトの重要なポイントを示すイベントやマーカーです。 その結果、期間は設定できないため、成果物は「マイルストーン」としてカウントできますが、タスクはカウントされません。 むしろ、タスクとは、マイルストーンの達成や成果物の完成に必要な作業です。

主要なマイルストーンには、プロジェクトのキックオフと完了が含まれます。 その他のマイルストーンは、タスクや活動の終了時に発生する場合があります； フェーズ／段階の終わりに； または作業を完了または承認する必要がある時点で。 請負業者が関与する場合、マイルストーンは支払いが行われるタイミングと一致する場合があります。 

ここでは、製品またはソフトウェア開発プロジェクトのマイルストーンの例をいくつかご紹介します：: 

• プロジェクトのキックオフ
• 設計・試作品の承認
• テストのさまざまなフェーズの完了
• 実施
• マーケティングキャンペーンと広告キャンペーンの立ち上げ
• お客様への出荷
• プロジェクトの終了  

3. すべてのプロジェクト成果物を含むWBSを作成します。 上述したように、WBS (プロジェクトスケジュールの一部となる場合もあります) は、プロジェクトのすべての成果物を詳細に記述する必要があります。 組織によっては、成果物の制作に必要なタスクの内訳を含める場合もあれば、含めなくてもかまいません。 WBS は、プロジェクトのスケジュールの中のセクションである場合もあれば、スケジュールの作成時に参照される独立した文書でも構いません。 

この段階では、「クライアントと連絡を取り、プロジェクトの範囲を決め、成果物を完成させる」必要があるとBansalは述べています。 将来的には、範囲クリープ (クライアントがプロジェクトの範囲を拡大する傾向) を避けるのに役立ちます。

4. すべてのタスク／活動の概要と順序。 繰り返しますが、これはWBSに含まれるか、組織に応じてスケジュール自体に詳細が含まれます。 この情報をどこに配置するにしても、成果物を完成させるために必要なすべてのタスクを明確に文書化することが重要です。 これにより、プロジェクトの進行中に目標を達成し、締め切りに間に合うようにするために何をすべきかについての混乱を避けられます。 

実行する必要があるすべてのタスクを規定したら、依存関係を使用して順序を決定します。 そのためには、タスクが互いにどのように関連しているか、またタスクに対する時間やリソースの制約も考慮してください。 

依存性には次の2種類があります：

• 完了から開始へ： 後続タスク (タスクB) の作業を開始する前に、先行タスク (タスクA) を完了する必要があります。 
• 開始から開始へ： 後続タスク (タス B) は、先行タスク (タスクA) と同時に開始します。 

タスクの依存関係を判断する1つの方法は、タスクが論理的適切な順序に並ぶプロセスである「ネットワークロジック」を使うことです。 最初に最も難しいタスクから始めるのが便利な場合があります。 また、各タスクの優先度を定義することで、最も重要なタスクを最初に完了できます。 一連のタスクとそれらの関係を明確に把握すれば、後でスケジュールの競合に対処することができます。

5. クリティカルパスを規定します。 「クリティカルパス解析」とも呼ばれるこのプロセスは、プロジェクトを期限内に完了するために、すべてのタスクや活動を通過するための最適な経路を決定するプロセスです。 プロジェクトを高レベルで見て、最も重要なタスクに分割し、それらのタスクを完了するのにかかる時間に基づいてプロジェクト全体を完了するための時間を計算します。 クリティカルパスの管理は、プロジェクト管理に欠かせない要素です； 重要なタスクが完了していない場合、最終締め切りが遅れる可能性があります。

クリティカルパス解析では、重要なタスクの最も早いおよび最も遅い開始日と終了日を決定し、それらの間の依存関係を推定します。 また、タイミングに影響を与える可能性のある人員やその他のリソース (例えば、プロジェクトの設置や導入フェーズの開始に必要な機器) の可用性も考慮する必要があります。 これにより、プロジェクトの完了に関与するタスクのうち、可能な限り最長の順序を特定できます。

6. タスクの期間を見積もります。 これは、プロジェクトのスケジューリングの最も難しい部分の1つですが、プロジェクトのコストに大きなインパクトを与えるため、最も重要な部分の1つです。 「期間」とは、チームメンバーがタスクを完了させる必要があると予想される勤務時間、日、週、月の数を指します。 

Smartsheetでは、タスクの期間を分単位、時間単位、日単位、週単位で設定できます。 Microsoft Projectでは、コストと時間を見積もるための期間の選択肢が3つあります:

• 固定作業： 作業が所定の数の製品を納品する、または一定時間働くなどの事前に規定された量に基づいている場合。
• 固定期間： この指定は、チームミーティングやマイルストーン・レビューセッションに使用されます。
• 固定単位： これはデフォルト設定であり、特定のタスクに割り当てられたリソースの数と、その作業に利用可能な時間のパーセントを反映します。 例えば、あるタスクに週20時間 (週40時間勤務) の勤務を割り当てられたチームメンバーは、50%の固定単位を持ちます。 

仕事がスケジュールどおりに進み、期日に簡単に間に合うので、クライアントの満足感を維持し、チームメンバーの満足感を維持するため、両者にとって正確に期間を見積もることは重要です。 しかし、タスクの所要時間を過小評価するのは、よくあるプロジェクト管理のミスです。 これにより、プロジェクトは「熱狂的」になり、チームが短時間で多くの作業を完了させ、クライアントが追加の資金を補う必要がある場合に発生します。 この場合、品質に悩まされ、双方の士気が低下します。

「いくつかのバッファータイムを確実にスケジュールに含めます」とBansalは言います。 「物事が常に計画通りに進むとは限らず、バッファータイムは物事を軌道に乗せるために役立ちます。」

タスクの期間には、以下のような多くの要因が影響します：

• チームメンバー個人のスケジュール
• 祝祭日、オフィス閉鎖、直前の緊急事態
• チームとクライアントのミーティングとコラボレーションに費やされた時間
• チームメンバーのスキル、経験、効率のレベル
• プロジェクトの計画と開発中の誤りとコミュニケーションの誤り

しかし、スケジュールの有効性を改善するためにできることがいくつかあります：

• ほとんどの人は常に100%の効率で仕事をしていないことを認識し、それに応じて期間を見積もります
• 類似する範囲とリソース要件を持つプロジェクトの過去のデータを調べた上で、時間見積もりを行います
• ベースラインとして使用できる内部データがない場合は、外部の専門家に相談するか、他の組織が行った類似プロジェクトを調査してください

実際、 Orchestrating Your Success（あなたの成功を調整する）のGailliardは、「過去の情報を引き出してスケジュールを立てれば、他に差をつけることができます。 何もないところから始めるよりも、編集や変更は非常に簡単です。」

7. リソースを見積もります。 もう 1 つの重要なステップは、プロジェクトに利用可能なリソースを決定することです。 チームメンバーの中には、一度に複数のプロジェクトに取り組んでいる人もいるでしょう。それがスケジューリングに競合をもたらします。 リソースの割り当ては 、締め切りを逃したり、特定のチームメンバーに過剰負担を与える事態を防ぐのに役立ちます。 

リソースの可用性を見積もるには、以下を検討してください：

• タスクを完了させるために必要な順序
• チームメンバーの休暇やその他の仕事、会社の休日やオフィスの閉鎖などの時間制限
• クライアントの予算に含めるチームメンバーの数、スキルレベル、1時間当たりの要件などのコスト制限
• チームメンバーのスキルと経験が、特定の期間内に仕事を完了する能力にどのような影響を与えるか

リソース管理機能を備えたプロジェクト管理ソフトウェアを使用すると、このステップをはるかに簡単に行うことができます。 たとえば、 Smartsheetのリソース・ビュー・ダッシュボードを使用すると、複数のプロジェクトにわたる職員の利用可能状況を一目で確認できます。 Microsoft Projectでは、ガントチャート・ビューを使用して、可用性を表示したり、リソースを個々のタスクに割り当てたりすることもできます。 プロジェクト管理プログラムがない場合は、プロジェクト、会社、個人のカレンダーを参照して、利用可能性を確認してください。

「週末、休日、休暇をスケジュールに収め、病気になる可能性も忘れないようにしましょう。 そのため、できるだけ多くの穴埋めを指定してください。」 と Fennemaは助言しています。

前述のWBSセクションで説明したように、各タスクに1つのリソースを「所有者」として割り当てられるように、タスクを細分化すると便利です。」 これにより、実行されている作業をよりきめ細かに制御できます。 

8. 想定に注意してください。 スケジュール中に、タイムラインに影響を与える可能性のある想定を記録します。 これにより、透明性が提供され、後で変更が容易になります。 

「想定を明確に記載する」と、Trump ExcelのBansalは助言しています。 「例えば、私のプロジェクトでは、クライアントが必要な報告書を受け取ると想定し、クライアントはそうでないと想定していました。 これが大きなコストへの影響につながったのです。」

別の例として、経験豊富なチームメンバーが当該タスクを完了すると想定された場合は、これをスケジュールに記入する必要があります。 そうすれば、経験の少ないチームメンバーが後にタスクに割り当てられた場合、プロジェクトマネージャーはその想定を確認し、そのメンバーに対応するためにタスク期間に余分な時間を組み込みます。 経験の少ない作業者であれば、タスクの完了が遅くなる可能性があるため、この想定を含めないと、プロジェクトの遅延が発生する可能性があります。

9. リスクを決定し、記録します。 プロジェクトに関わるリスクを解析することで、それに合わせてスケジュールを立てることに役立ちます。 特定されたリスクと未特定のリスクの両方に対処するための時間を必ずスケジュールに追加するようにしてください。 

リスクの例としては、以下のようなものがあります： 

• リソースを利用できない
• 間違った期間の見積もり 
• 経験の少ないチームメンバーが行っているタスク 
• チームのメンバーが不慣れな新しいテクノロジーの使用
• プロジェクトの範囲やスケジュールの要素に関するチームとクライアントの間の誤解

リスクを特定したタスクに「リスク乗数」を追加することが良い実践です。 リスク乗数とは、リスクの深刻度とタスクを予定通りに完了することの重要性に基づいて、スケジュールに追加される時間のパーセントです。 特にリスクの高いプロジェクトでは、リスク管理のためだけに追加のタスクをスケジュールに盛り込むことで、潜在的な遅延をカバーするために余分な資金を確保できます。

Beyond the Chaos（混沌を越える）のFennemaは、このステップの重要性を指摘しています。 「未知の事態や不測の事態に対処するための時間をスケジュールには必ず含めておく必要があります。 完璧に進むプロジェクトはありません」と彼女は言います。

BrandExtractのBishopもまた次のことを推奨しています。「プロジェクトのスケジュールを確定する前に、潜在的なリスクを特定します。 私がレビューに1週間を計画していますが、クライアントは承認を得るために2週間かかることを知っている場合、前もって取り組む必要があります。」

10. スケジュールの見直しと修正。 おめでとうございます、あなたはスケジュールを完了しました! それでは、すべてをレビューし、それが正確であることを確認し、必要な変更を行います。 

スケジュールを確認して、次の点を確認します：

• タスクの開始日と終了日は職員の利用可能性に合わせて調整されている 
• マイルストーン、成果物、タスクの開始日と終了日は現実的である
• 適切なリソースが適切なタスクに割り当てられている
• 休暇、休日、設備の利用可能性などのスケジュールの制約が考慮されている
• すべてのタスクに依存関係がある
• マイルストーンのない大きな仕事がない
• 特定されたリスクと未確認のリスクに対応するために、余分な時間が含まれている
• スケジュールはプロジェクトのクリティカルパス解析と一致する

スケジュール作成の前後にチームとミーティングを行い、実施可能性に関するフィードバックを得ましょう。 Gailliardは、「プロジェクトチームとタスク、リソース、コストを検証する」ことを勧めています。 代わりに、チームメンバーに彼らの時間、タスク、リソースの見積もりを聞いて、次にそれらがご自分のものと合っているかどうかを確認することもできます。 

Fennemaは、クライアントや顧客と相談することも提案し、「作業を行う人と一緒にスケジュールを作成した後は、納品を期待している人から賛同を得て、利用可能で、テスト期間中やリリース時などに作業できることを確認すること」を提案します。

リソースを適切に分配していない場合は、「リソース平準化」と呼ばれる手法を使用できます。 これには、タスクの順序や割り当てを並べ替えて、仕事がチームメンバーに均等に分割されるようにし、潜在的に利用できないリソースに備えるといった作業が含まれます。 プロジェクト管理ソフトウェア・プラットフォームの中には、リソース平準化を行う場合もあれば、利用可能性を検証するために、カレンダーを使って手動でこのプロセスを行うこともできます。

スケジュールを確認するもう1つの方法として、「what-if（仮説）」シナリオ解析があります。 これには、シミュレーションを使用して、プロジェクトの遅延やコスト超過など、さまざまなネガティブなシナリオのリスクを測定します。 その後、これらのリスクのインパクトを比較し、発生時に備えて緊急計画を立てます。 繰り返しますが、リスクの高いタスクには必ずリスク乗数を追加してください。 ソフトウェアシステムによっては「what-if」解析を行う場合もあります。 

レビューが完了し、スケジュールが承認されると、「ベースライン・スケジュール」が作成されます。 スケジュールは生きた文書であるため、プロジェクトのライフサイクルを通じてさまざまなポイントで修正されるかもしれませんが、ベースライン・スケジュールを使用して実行フェーズを開始します。 プロジェクトが始まったら、実際のタイムラインとコストをベースライン・スケジュールで予測した内容と比較できます。