Skip to content

Archives

  • 2022年1月
  • 2021年12月
  • 2021年11月
  • 2021年10月
  • 2021年9月

Categories

  • カテゴリーなし
Trend RepositoryArticles and guides
Articles

プロジェクト・スケジュール・ネットワーク・ダイアグラム。 定義|用途|例

On 11月 4, 2021 by admin

あなたはプロジェクトの活動をスケジュールする必要があるときは、プロジェクトのスケジュールネットワーク図の使用を検討したいと思うかもしれません。 これは、アクティビティ間の相互依存性を考慮したアクティビティの順序を決定し、文書化するための実績のあるテクニックです。 また、Project Management Instituteのフレームワーク(PMBOK®第6版、6.3.3.1)でも提案されています。

  • プロジェクトスケジュールネットワーク図とは?
  • プロジェクトネットワークダイアグラムは何のために使用されますか?
  • How Do You Create a Schedule Network Diagram?
  • スケジュール・ネットワーク図の例
  • 活動と論理的関係
  • プロジェクトスケジュールネットワーク図の作成と理解
  • プロジェクトスケジュール管理への影響
  • 結論

プロジェクトスケジュールネットワーク図とは?

PMIのプロジェクトマネジメント知識体系ガイド(PMBOK®第6版)では、「活動の順序付け」プロセスの出力タイプとして、プロジェクトスケジュールネットワーク図が挙げられます。

プロジェクトスケジュールネットワーク図は、これらの活動の間の論理的な関係に対処するために、活動をスケジュールする必要がある順序を示しています。

Example of a Project Schedule Network Diagram.

それは通常、活動を表すノードと順序や依存関係を示す矢印から構成されている。 それはおそらくプロジェクトスケジュールネットワーク図の最も一般的なタイプです。

プレゼンテーションの別の形式は、名前が示すように、アクティビティが矢印として表示され、ノードが論理的な関係を表す「矢印上の活動」(AOA)メソッドです。

Example of an Activity-on-Arrow Project Schedule Network Diagram.

プロジェクト日程ネットワーク図の作成手法は、今回説明する優先度図法(例含む)である。 依存関係の4つのタイプは、

  • 終了に終了(FF)、
  • 終了に開始(FS)、
  • 開始に開始(SS)、および
  • 終了に開始(SF)です。 例えば、finish to start依存関係では、後継者が開始するために先行者が終了していなければならない。

    依存関係とは別に、プロジェクトスケジュールダイアグラムは、リードとラグを表示することができます。 これらは、この記事で詳しく説明しているアクティビティのタイミングとスケジューリングの特徴です。

    プロジェクトネットワークダイアグラムは何のために使用されますか?

    プロジェクトネットワークダイアグラムは、アクティビティのシーケンスを開発および文書化するために使用されます。 これは「プロジェクトスケジュールマネジメント」の知識エリアに属し、スケジュールネットワーク分析やクリティカルパス法(PMBOK®, ch.6.5.2.1) などの他のスケジュール管理手法の入力として利用されます。

    プロジェクトでは、シーケンスや依存関係、またステークホルダーコミュニケーションにこのタイプのダイアグラムを使うことも可能です。 しかし、大規模なプロジェクトでは、多くの場合、すべてのアクティビティの依存関係とシーケンスをプロジェクト全体のスケジュールと期間にリンクする、かなり詳細で複雑な作業ドキュメントになります。

    スケジュールネットワーク図は、活動のスラックとフロートおよびリードとラグを文書化するためにも使用されます。

    How Do You Create a Schedule Network Diagram?

    スケジュールネットワークダイアグラムの関連入力は、定義済みアクティビティのリスト、これらのアクティビティの推定期間とそれらの間の論理関係(依存性とも呼ばれる)である。

    スケジュール ネットワーク図を描くには、

    1. 開始点を描く、
    2. 詳細や追加データなど、図の(将来の)ノードにアクティビティを挿入する(以下の説明を参照)、などが必要になります。
    3. 論理的関係の種類を表す矢印でアクティビティを接続します (先行ダイアグラム手法の記事で説明しています)。
    4. 各関係に、依存関係のタイプ (SS、FS など)、必須か任意か、リードとラグ、およびスケジューリングに関連するその他のデータなどの詳細を追加し、
    5. ダイアグラムのエンドポイントを作成します。

      アクティビティによく追加する詳細には、最短開始日と最長終了日、アクティビティの重要度のほか、ワーク パッケージまたは作業内訳構造への参照が含まれます。

      スケジュールネットワークダイアグラムを作成するためにアクティビティ・オン・アロー(AOA)法を好む場合、アクティビティを矢印として、依存関係をノードとして描画する。 しかし、入力データの要件、すなわちアクティビティのリスト、論理的関係、リードとラグは同じであり、ユーザが提供する必要がある。

      適切なソフトウェアが手元にない場合、または小規模で複雑でないプロジェクトで作業する場合、Visio や PowerPoint などの標準オフィス ソフトウェアを使用して(下の例の図を作成するために使用した)図を手動で作成することも可能です。

      スケジュール・ネットワーク図の例

      このセクションでは、プロジェクトのスケジュール・ネットワーク図でシーケンスと文書化が必要なアクティビティのセット(簡略化)を紹介します。 この事例の一部は、先行ダイアグラム手法の例でも使用されています。 PDMの記事で、これらのアクティビティ間の論理的関係をどのように特定し、分類したかの詳細をご覧ください。

      この例は、IT開発および実装プロジェクトについてです。 しかし、スケジュールnetworkdiagramの作成と使用は、そのsubjectmatter.

      活動と論理的関係

      プロジェクトは、フェーズ

      • 設計、
      • 開発、
      • 実装、
      • テストと
      • ソフトウェアをデプロイすることから構成されている。

活動は以下の通りです:

  1. モジュールAの技術設計(期間:10日)、
  2. モジュールBの技術設計(期間:10日。 5日間)、
  3. モジュールAの開発(期間:15日間)、
  4. モジュールBの開発(期間:20日間)、
  5. モジュールBの機能Fの開発(期間:5日間)、
  6. モジュールBの機能Fの開発(期間:20日間)。 1日)、
  7. モジュールAの実装(期間: 5日)、
  8. モジュールBの実装(期間: 7日)、
  9. モジュールAのテスト(期間: 6日)、
  10. モジュールBのテスト(期間: 10日)、
  11. 統合テスト(期間: 5日)、
  12. デプロイ(期間: 1日)です。

最初の5つのアクティビティは、FF、FS、SS、SFの論理的関係を持っています。

これらの論理的関係に加えて、アクティビティのこのシーケンスでは、リードとラグがあります:

  • The testing of module A can start 4 days after the implementation of that module has started, therefore it is a SS dependency with 4 days lag time.これは、モジュールAのテストが、そのモジュールの実装が開始されてから4日後に開始される可能性があります。
  • 統合テストは基本的にモジュールのテスト後に開始される予定です(FSの関係)。 しかし、これはハードロジックではなく、モジュールBのテストが80%完了した時点で、すでに統合テストは開始できるのである。

このテクニックにまだ慣れていない場合は、図解された例も付いているこのラグとリードの紹介を読んでください。

プロジェクトスケジュールネットワーク図の作成と理解

これをプロジェクトスケジュールネットワーク図に移すと、次のような結果になる。

この例のプロジェクトスケジュールネットワーク図

こうした図を作るために、最初のステップはこれらの活動間の論理関係を明らかにすることだ。 これらの関係のタイプは活動の順序を定義し、それらはこの図表の矢によって表される。

依存関係の最も単純なケース、すなわち終了から開始の関係では、後継者が開始できる前に先行アクティビティが最初に終了しなければならない。 これは、先行アクティビティから後続アクティビティに矢印を引くことで図に表されます。

アクティビティ「testing of moduleA」の遅れ(遅れ時間4日)は、アクティビティの経路の総所要時間を延長するため、正の数として示されている。

「統合テスト」アクティビティのリードは、逆の理由で負の数で示されている。

プロジェクトスケジュール管理への影響

あなたは、アクティビティの各列に沿って矢印をたどると、リードとラグタイムと同様に持続時間を追加して、パスの期間を決定することができます。 モジュールAの設計から配置までのパスは、次のアクティビティで構成されています:

  • モジュールAの技術設計(期間:10日)、
  • モジュールAの開発(期間:10日)。 15日)、
  • モジュールAの実装(期間:5日)、
  • モジュールAのテスト(期間:6日)、
  • 統合テスト(期間:5日)、
  • デプロイ(期間:1日).

その特定のパスの合計期間は、それ自体がプロジェクトであれば、44日(10+15+5+4+4+5+1)です。

しかし、これは我々のサンプルプロジェクトの正しい期間ではありません!

モジュールBのパスでは、統合テストが始まる条件である「モジュールBのテスト80%終了」(45日)に到着するのに長い時間がかかっています。 モジュールAのパスが統合テストの先行アクティビティ(モジュールAのテスト)を終了するには最低でも34日しかかからないため、モジュールAのパスがモジュールテストを終了するのを「待つ」必要がある。 この “待機時間 “はまた、slackor float.

結論

スケジュールネットワーク図は、プロジェクトの活動の順序と論理的関係の有用な視覚化です。 矢印をたどり、関係の種類だけでなく、リードとラグを考慮に入れると、pathandの期間を決定することができ、最終的には、プロジェクトのcritical pathを識別することができます

活動の順序は、最近のプロジェクト管理ソフトウェアによってontendoneですが、それは活動間のthedependenciesと順序とプロジェクトスケジュールに与える影響を理解することが重要です。 これは、通常、スケジューリングに関するいくつかの質問があるように、PMP試験のために重要であるだけでなく、プロジェクトスケジュールinpractice.

私たちの専用のsection.Inでスケジューリング技術についての詳細を読む

のためのものである。

コメントを残す コメントをキャンセル

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

アーカイブ

  • 2022年1月
  • 2021年12月
  • 2021年11月
  • 2021年10月
  • 2021年9月

メタ情報

  • ログイン
  • 投稿フィード
  • コメントフィード
  • WordPress.org
  • DeutschDeutsch
  • NederlandsNederlands
  • SvenskaSvenska
  • DanskDansk
  • EspañolEspañol
  • FrançaisFrançais
  • PortuguêsPortuguês
  • ItalianoItaliano
  • RomânăRomână
  • PolskiPolski
  • ČeštinaČeština
  • MagyarMagyar
  • SuomiSuomi
  • 日本語日本語

Copyright Trend Repository 2022 | Theme by ThemeinProgress | Proudly powered by WordPress