タスク依存関係とは：FS、SS、FF、SFを解説

タスク依存関係は、プロジェクト作業がどの順序で進められるかを定義します。これを誤ればスケジュールは崩壊し、正しく設定できれば、チームは各作業がいつ開始でき、いつ重複でき、いつ待つべきかを正確に把握できます。

論理的な依存関係のタイプは4つあります。終了・開始関係（FS）、開始・開始関係（SS）、終了・終了関係（FF）、開始・終了関係（SF）です。それぞれが、あるタスクの終了または開始と、別のタスクの終了または開始との間の特定の関係を表します。本記事ではこの4種類すべてを取り上げ、リードタイムとラグタイムを解説し、すべてのプロジェクトマネージャーが知っておくべき4つの依存関係カテゴリを順に説明します。

タスク依存関係とは

タスク依存関係とは、2つのタスクの間にある論理的な関係のことで、一方が他方に対していつ開始または終了できるかを決定します。スケジューリングソフトウェアやプロジェクトマネジメントのネットワーク図では、依存関係にある2つのタスクをそれぞれ先行タスク（関係の中で先に来るタスク）と後続タスク（それによって制約を受けるタスク）と呼びます。

依存関係はタスクの順序と同じものではありません。順序とは物事が起こる順番のことです。依存関係とは、その順番で起こる論理的な理由のことです。この違いは重要です。あるタスクは重複させられる一方、別のタスクは他のタスクが終わるまで待たなければならず、まれなケースでは先行タスクが止まる前に後続タスクを開始しなければならない状況もあるからです。

重要ポイント

• Project Management Instituteの報告によると、スケジューリングの順序付けの不備はプロジェクト超過の三大要因の1つであり、世界全体でプロジェクトの37%においてコストへの影響をもたらしています（PMI Pulse of the Profession、2023年）。
• McKinseyの調査によると、大規模な建設プロジェクトやITプロジェクトは平均でスケジュールを20%超過しており、依存関係の管理不備が主な根本原因として挙げられています（McKinsey Global Institute、2017年）。
• 依存タスクを意図的に重複させるファストトラッキングのようなスケジュール圧縮手法は、遅延プロジェクトの60%で時間を取り戻すために使われています（PMI、2022年）。

タスク依存関係の4つのタイプ

Microsoft ProjectやReworkを含むほとんどのスケジューリングツールは、Project Management Body of Knowledge（PMBOK）が定義する4つの論理関係タイプすべてをサポートしています。それぞれについて、分かりやすい実例とともに見ていきましょう。

FSがデフォルトです。 典型的なプロジェクトにおけるタスク関係の大半は終了・開始関係です。どのタイプを使うべきか迷ったら、ほぼ常にFSが正解です。

SFは例外です。 SFはジャストインタイム製造やシフト引き継ぎの場面で最もよく見られます。SFを頻繁に使っていると感じる場合、それは通常、スケジュールロジックを見直す必要があるサインです。

依存関係のカテゴリとリード対ラグ

4つの論理タイプに加えて、あらゆる依存関係は、その関係がなぜ存在するのかを説明する4つのカテゴリのいずれかにも分類されます。そして、あらゆる依存関係は、スケジュールをより現実的にするためにリードタイムまたはラグタイムで調整できます。

依存関係のカテゴリ

依存関係が必須か裁量かを把握しておくことは、スケジュール圧縮の際に重要です。裁量的な依存関係はファストトラッキング（重複させること）ができますが、必須の依存関係はできません。このトレードオフについてはファストトラッキング対クラッシングの記事で詳しく解説しています。

リードタイムとラグタイム

ラグタイムは、先行タスクと後続タスクの間に待機期間を追加します。骨組み工事を始める前にコンクリートを2日間硬化させる必要がある場合、それはFS依存関係における2日間のラグです。

リードタイムは、後続タスクが先行タスクの終了前に開始できるようにするものです。これをマイナスのラグとしてモデル化すると、FS依存関係における3日間のリードとは、後続タスクが先行タスクの完了より3日早く開始できることを意味します。これが実務上のスケジュール圧縮の仕組みです。

リードもラグも、プロジェクトスケジュールと同じ単位（日数、時間、または先行タスク期間に対する割合）で表されます。

タスク依存関係が重要な理由

依存関係は、プロジェクトスケジュールをつなぎ合わせる結合組織のようなものです。これがないとどのような問題が起こるか見てみましょう。

チームが完了できない作業に着手してしまう。 タスクAが終わる前にタスクBが始まると、Bに取り組むチームは作業の途中で行き詰まり、待つか、やり直すかを迫られることがあります。これは無駄と苛立ちを生みます。

クリティカルパスが見えなくなる。 クリティカルパス法は、依存関係が正しくマッピングされている場合にのみ機能します。依存関係が抜けていると、アルゴリズムは誤った最短プロジェクト期間を算出し、開始前からスケジュールが狂ってしまいます。

フロートが失われる。 フロートとスラックの計算は、完全に正確な依存関係ロジックに依存しています。依存関係が誤っていれば、実際にどのタスクに余裕があるのかが分からなくなります。

変化が予測不能に連鎖する。 あるタスクが遅れると、その後続タスクも遅れます。ただしそれは依存関係がマッピングされている場合に限られます。マッピングされていなければ、対応が手遅れになるまでその波及効果に気づけません。

よくある間違い

実際のプロジェクトで最も頻繁に見られる依存関係のエラーです。

習慣的にすべてFSにしてしまう。 すべてのタスクが終了・開始関係というわけではありません。SSやFFの方が実態に合っている場合でもFSをデフォルトにすると、スケジュールが不自然に長くなり、並行して進められる作業が見えなくなります。

裁量的な依存関係を省略してしまう。 チームは「柔軟だから」という理由で、ハードロジックだけをモデル化してソフトロジックを省くことがあります。しかし文書化されていないソフトな依存関係は、将来のチームメンバーが品質やベストプラクティスを損なう形でタスクを並べ替えてしまう原因になります。

外部依存関係を無視してしまう。 ベンダーが資材を納品しないとチームがそれを設置できない場合、それは外部のFS依存関係です。これを見落とすと、納品を依頼してすらいない段階で設置作業が始まるようにスケジュール上表示されてしまいます。

タスクではなくリソースに依存関係を追加してしまう。 よくある落とし穴は、作業そのものが順序付けを必要としているからではなく、同じ人が両方を担当するという理由でタスクをリンクしてしまうことです。リソースの制約はリソース平準化で対処すべきであり、タスク依存関係をでっち上げることではありません。作業分解構成図の段階は、この2つの論点を切り分けるのに良いタイミングです。

スコープ変更後に依存関係を見直さない。 スコープが変わると、一部の依存関係は無意味になり、新しい依存関係が発生します。依存関係の見直しは、統合変更管理プロセスの標準的な一部です。

タスク依存関係のマッピング方法

ステップ1：WBSからすべてのタスクを洗い出す

完全な作業分解構成図から始めます。まだ特定していないタスクの依存関係をマッピングすることはできません。順序付けを始める前に、すべての成果物をワークパッケージまで分解しておく必要があります。

ステップ2：各タスクの先行タスクを特定する

タスクリストを一つずつ確認しながら、「このタスクが開始または終了する前に、何が起こる、あるいは少なくとも始まる必要があるか」を問いかけます。先行タスクを持たないタスク（いつでも開始できる）もあります。ほとんどは1つか2つの先行タスクを持ちます。中には複数持つものもあります。

ステップ3：正しい関係タイプを割り当てる

先行タスクと後続タスクの各ペアについて、その関係がFS、SS、FF、SFのいずれであるかを判断します。自問してみてください。後続タスクを引き起こすのは先行タスクの終了か、それとも開始か。そして引き起こされるのは後続タスクの開始か、それとも終了か。

ステップ4：必要に応じてリードまたはラグを追加する

タスク間に必須の待機期間（硬化時間、承認期間、出荷リードタイムなど）がある場合はラグを追加します。後続タスクが先行タスクの終了前に開始できる場合はリードを追加します。ここは正直に設定してください。水増しされたラグは実際のフロートを隠してしまい、非現実的なリードはチームを手戻りに追い込みます。

ステップ5：チームで検証しネットワーク図を作成する

実際に作業を行う人たちに依存関係マップをレビューしてもらいましょう。彼らは、机の前で1人で作業するどのPMよりも早く論理の誤りに気づきます。検証が済んだ依存関係は、ネットワーク図、クリティカルパス分析、そしてガントチャートの基礎になります。

タスク依存関係の実例

依存関係が実務上どのように現れるかを示す、3つの一般的なプロジェクトシナリオを紹介します。

ベストプラクティス

すべきこと：

• スケジューリング上の都合ではなく、作業の実態を反映した依存関係タイプを使う
• 各裁量的な依存関係がなぜ存在するのかを文書化する。プロジェクトスケジュールへの簡単なメモが、後々の混乱を何時間分も防ぎます
• スコープ、リソース、タイムラインが変わるたびに依存関係を見直す
• 依存関係のマッピング後にフロートとスラック分析を行い、スケジュールにどこ余裕があるかを見つける
• 依存関係マップをプロジェクト計画文書にリンクし、ステークホルダーがスケジュールロジックを理解できるようにする

すべきでないこと：

• リソースの制約を強制するために依存関係を追加する。そのためにはリソース平準化を使う
• 外部依存関係を忘れる。ベンダーの納品、規制当局の承認、クライアントの承認は実際のスケジュールリスクです
• すべての依存関係が終了・開始関係だと決めつける。すべてFS関係で組み立てられたスケジュールは、ほぼ確実に必要以上に長くなります
• 本物のシフト引き継ぎやジャストインタイムのシナリオでない限りSFを使う。ほとんどのチームメンバーとほとんどのスケジューリングツールを混乱させます
• チームレビューを省略する。紙の上では正しく見える依存関係ロジックも、実際に作業する人が見ると崩れることがよくあります

よくある質問

最も一般的なタスク依存関係タイプは何ですか。

終了・開始関係（FS）が圧倒的に最も一般的です。これは最も自然な作業順序、つまりタスクBが始まる前にタスクAが終わっていなければならない、という関係を反映しています。ほとんどのプロジェクトスケジュールでは、FSが全タスク関係の70〜90%を占めています。

必須の依存関係と裁量的な依存関係の違いは何ですか。

必須の依存関係（ハードロジック）は、製品をリリースする前にテストを完了させる必要がある、といった変更不可能な物理的または契約上の現実を反映しています。裁量的な依存関係（ソフトロジック）は、ベストプラクティスやチームの判断に基づく望ましい順序を反映しており、スケジュール圧縮が必要な場合には変更できます。

1つのタスクが複数の先行タスクを持つことはありますか。

あります。多くのタスクは、開始するまでにいくつかの先行タスクが終了または開始することに依存しています。プロジェクトマネジメントのネットワーク図では、これは複数の矢印が1つのタスクノードに集約する形で表示されます。そのタスクは、すべての先行条件が満たされるまで開始（またはタイプによっては終了）できません。

ラグタイムとリードタイムの違いは何ですか。

ラグタイムは、先行条件が満たされた後に遅延を追加します。リードタイム（マイナスのラグ）は、先行条件が完全に満たされる前に後続タスクを開始できるようにします。どちらも、4つの依存関係タイプのいずれにも適用できる修飾要素です。

タスク依存関係はクリティカルパスとどう関係していますか。

クリティカルパスとは、プロジェクトネットワークを通る依存タスクの中で最も長い連続経路のことです。これは、すべてのタスク依存関係が正しくマッピングされている場合にのみ計算できます。依存関係が欠けていたり誤っていたりすると、実態を反映しないクリティカルパスが算出され、予測される完了日が信頼できないものになります。計算方法についてはクリティカルパス法の記事でさらに詳しく解説しています。

---

依存関係のマッピングは、スケジュールを組み立てる際に最初に行うことの1つでありながら、状況が変わったときに更新することを最後まで忘れがちな作業でもあります。このギャップこそが、プロジェクトのタイムラインが崩れる場所です。依存関係ロジックを常に最新に保ち、チームで検証し、作業に合った正しい関係タイプを使いましょう。そうすればスケジュールは実態に即したものになり、クリティカルチェーン・プロジェクトマネジメント分析は正確になり、チームは何が何に依存しているかを正確に把握できます。

依存関係のつながりを視覚的に表現したものについては、マイルストーンチャートとネットワーク図のガイドをご覧ください。また、プロジェクトが構造化されたガバナンスモデルを使用している場合、PRINCE2手法のプロダクトベース計画に関するセクションでは、ステージゲートフレームワークの中で依存関係がどのように機能するかを解説しています。

関連記事

• ネットワーク図：プロジェクト全体のタスク依存関係を視覚的に表現する方法
• クリティカルパス法：依存関係を使って最も長い経路を見つけ、締め切りを守る方法
• フロートとスラック：依存関係をマッピングした後にスケジュールの柔軟性を理解する
• ファストトラッキング対クラッシング：裁量的な依存関係を調整してスケジュールを圧縮する方法
• 作業分解構成図：あらゆる依存関係をマッピングする前に構築しておくべき基礎