ソフトウェア開発及びソフトウェア プロジェクトマネジメント（VII） 北航软件学院 马 平 博士 副教授 maping@buaa.edu.cn

レビュー １．プロダクトスコープとプロジェクトスコープの区別は？ ２．スコープ・マネジメントには、（？ ）のプロセスがある。 　　各プロセスの主なアウトプットは？ ３．プロジェクト憲章の記述項目は？ ４．スコープ記述書とスコープ・マネジメント計画書の明記されるべき事項は？ ５．WBSとは？WBSの役割は？

ソフトウェアプロジェクトのWBS例 ソフトウェア プロジェクト 要求分析 外部設計 内部設計 システム テスト モジュール１ 総合テスト コーディング フェーズ システム テスト モジュール１ モジュール２ モジュール３ 総合テスト マネジメント レビュー ディバーグ 作業分解 成果物分解

第7回 タイム・マネジメント 7.1 アクティビティ定義 7.2 アクティビティ順序設定 7.3 アクティビティ所要期間見積もり 第7回 タイム・マネジメント 7.1　アクティビティ定義 7.2　アクティビティ順序設定 7.3　アクティビティ所要期間見積もり 7.4　スケジュール作成 7.5　スケジュール・コントロール 7.6　システム開発における考慮点

タイム・マネジメントのプロセス 計画のプロセス コントロールのプロセス タイム・マネジメントは次の図に示す ５つのプロセスがある。 　　　　　　　　　　　　　　　 計画のプロセス 　　　　　　　　　　　　　　　　　　　　　　　 計画のプロセス 　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 計画のプロセス 　　　　　　　　　　　　　　　 コントロールのプロセス タイム・マネジメント アクティビティ定義 スケジュール作成 アクティビティ順序設定 アクティビティ所要期間見積り スケジュール・コントロール

7.1 アクティビティ定義 アクティビティ定義 インプット ツールと技法 アウトプット １．ワーク・ブレークダウン 7.1　アクティビティ定義 アクティビティ定義 インプット １．ワーク・ブレークダウン 　　・ストラクチャー（WBS） 2.　スコープ記述書 3．過去の情報 ４．制約条件 ５．前提条件 ６．専門家の判断 ツールと技法 1.　要素分解 ２．テンプレート アウトプット １．アクティビティ・リスト 2.　詳細資料 ３．ワーク・ブレークダウン 　　・ストラクチャー（WBS） 　　更新版

アクティビティ実施時期の決定（スケジュール） 7.1.1　WBSでスケジュールを作る例 WBSでスケジュールを作る流れ WBSワークパッケージ アクティビティ アクティビティの所要時間見積り アクティビティ間の順序関係決定 要員決定 アクティビティ実施時期の決定（スケジュール）

7.1.2 アクティビティの定義の例 作業ID 作業名 作業時間 A．01.01 全体設計完了 … B.00 プロジェクトマネジメント 7.1.2　アクティビティの定義の例 作業ID 作業名 作業時間 A．01.01 全体設計完了 … B.00 プロジェクトマネジメント 172 C.01 全体設計 160 C.02 システムインストール 40 C.03 システムテスト 120 D.01.01 Web　デザイン 16 D.01.02 Web　画面構造設計 24 D.01.03 Web　画面製作 D.02.01 Web　CGI設計 96 D.02.02 Web　CGI製作 552 D.03.01 Web　プログラミング（統合） 112 D.03.02 Web　単体テスト E.01

7.2 アクティビティ順序設定 アクティビティ順序設定 インプット ツールと技法 アウトプット １．プレシデンス 7.2　アクティビティ順序設定 アクティビティ順序設定 インプット 1.　アクティビティ・リスト 2.　成果物記述書 3．強制依存関係 ４．任意依存関係 ５．外部依存関係 ６．マイルストーン(milestone) ツールと技法 １．プレシデンス 　　・ダイアグラム法 　　　（PDM） ２．アロー・ダイアグラム法 　　（ADM） 3.　条件ダイアグラム法 ４．ネットワーク・テンプレート アウトプット １．プロジェクト 　　・ネットワーク図 2.　アクティビティ・リスト 　　更新版 　さて、最後にもうひとつＷＢＳと関連の深い概念を紹介しておきます。それはマイルストーン管理という概念です。 　マイルストーンは日本語に訳すると一里塚という意味です。 マイルストーン管理（あるいはマイルストーン計画）とは 達成したい目標へ向かって、まずステップごとに段階を分け、計画を立てて実施し、その結果の検証をしてこれをもって修正された新たな計画を立て再び実施を行うという方法でプロジェクトを進めていくこと 　つまり、プロジェクトでは計画通りに行かないことは珍しくないので、その場合は計画を変更して再出発することになりますが、始終計画を変更おしていたのでは空中分解してしまします。マイルストーンはその計画の見直しの契機になるものです。 　ですから、プロジェクト計画を作るときには、マイルストーンをどこにとるかは大問題です。これはいろいろな考え方がありますが、基本的にはマイルストーンを何に使うかということから考えるべきです。多くの場合、プロジェクトチーム内での進捗の目安や、チェックなどの目的に使われることが多いですが、その場合にはスケジュール上厳守したいスケジュールをマイルストーンに設定します。顧客との共同作業が発生する場合には顧客の作業の節目をマイルストーンのとる場合があります。いずれにしてもスケジュール管理を円滑に進めるためには重要な概念であることは間違いありません。

7.2.1 アクティビティ順序設定の技法 ツールと技法は以下のものがある。 ① プレシデンス・ダイアグラム法（PDM） 7.2.1　アクティビティ順序設定の技法 ツールと技法は以下のものがある。 ①　プレシデンス・ダイアグラム法（PDM） 　　PDMはアクティビティの順序関係を論理的に定義していく手法である。 　　Activity　on　Node（AoN）とも呼ばれる。４つの順序関係（　FS、FF、SS、SF）があり、FS（完了ー開始）が最も一般的である。 ②　アローダイアグラム法（ADM） 　　工程の個々のアクティビティを矢印で表現するもので、ADMは　Activity on Arrow（AoA）とも呼ばれる。順序関係は、FS(完了ー開始)のみ。かつ、ダミー（順序関係を表すのみの、所要期間がゼロの作業）（アクティビティの順序を示すのみで、時間・コストの消費は伴わない）が存在する。 ③　クリティカル・パス（CPM） スケジュール作成技法 １．プレシデンス・ダイアグラム法（PDM：Precedence Diagramming Method） 　・作業（以下場合により“アクティビティ”を“作業”と称す）をノードで表現し、ノード間を、 　 依存関係を表す矢線（アロー）で結んで作業の順序を表現したネットワーク図 　・Activity on Node（AON）とも呼ばれます。 　・作業間には次の４つの依存関係が設定できます。図２も併せて見てください。 　　　FS（Finish-to-Start）　：前の作業が終わると次の作業が始まる。 　　　SS（Start-to-Start） ：前の作業が始まると次の作業も始まる。 　　　FF（Finish-to-Finish）：前の作業が終わると次の作業も終わる。 　　　SF（Start-to-Finish） ：前の作業が始まると次の作業が終わる。 ２．アロー・ダイアグラム法（ADM：Arrow Diagramming Method） 　・作業をアローで表現し、作業間の接続表示にノードを用いて作業の順序を表現した 　 ネットワーク図 　・Activity on Arrow（AOA）とも呼ばれます。 　・作業間の依存関係は、FS（終了－開始）のみが設定できます。 　・ダミー（順序関係を表すのみの、所要期間がゼロの作業）という便宜的な作業を 　 必要とする場合があります。 3. クリティカル・パス(critical path) クリティカル・パスとは、プロジェクトの完成を遅らせないためには絶対に遅らせてはならない工程の組み合わせのことです。言い換えると、前が終わらないと次に進めない工程の組において最も長くなる工程のことであり、クリティカル･パスの長さはプロジェクト全体の長さを意味します。クリティカル･パスでない工程をいくら短縮しても、プロジェクト全体の短縮にはつながりません。プロジェクトマネジメントにおいては、クリティカル・パスを守ることに注力するのが重要になります。

４つの依存関係 作業間には次の４つの依存関係が設定できます。 FS（Finish-to-Start）：前の作業が終わると次の作業が始まる。 SS（Start-to-Start）：前の作業が始まると次の作業も始まる。 FF（Finish-to-Finish）：前の作業が終わると次の作業も終わる。 SF（Start-to-Finish） ：前の作業が始まると次の作業が終わる。

7.2.1 アクティビティ順序設定の技法 先行タスク 後続タスク タイプ ラグ（間隔） C.01 D.01.01 FS ０ D.01.02 7.2.1　アクティビティ順序設定の技法 先行タスク 後続タスク タイプ ラグ（間隔） C.01 D.01.01 FS ０ D.01.02 D.01.03 D.02.01 D.02.02 D.03.01 D.03.02 …

ＰＤＭ法によるプロジェクト・ネットワーク例 　　　　　　　　　　　　　　　　　　FS 　　　　　　　　　　　SS 機能仕様書 作成 ② 5日 導入サポート 計画書作成 ③ プロジェクト ④ 分析レビュー 実施 ⑤

PDM法の例

ADM法の例 No. アクティビティ 所要期間 先行タスク A 要求分析 ２５ ― B 設計 １８ A C コーディング １３ B D 　― B 設計 １８ 　A C コーディング １３ 　B D 単体テスト １０ 　C E システムテストケースの作成 １２ F 総合テストケースの作成 １５ G 総合テスト ５ 　D,F H システムテスト ７ 　G,E

ADM法の例（１） 　　　　　　　２５　　　　　　　　　　　　　１８　　　　　　　　　　　１３ 　　　　　　　　　　　A　　　　　　　　　　　　　　B　　　　　　　　　　　　C　　　　　　　　　　　 　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　１０　 　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　１５　　　　D　 　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　F 　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　１２ 　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　G　　　５ 　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　E　　　　　　　　　　　 　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　H　　　７ １ ７ ６ ５ ４ ３ ２

ADM法の例（２） 　　　　　　　２５　　　　　　　　　　　　　１８　　　　　　　　　　　１３ 　　　　　　　　　　　A　　　　　　　　　　　　　　B　　　　　　　　　　　　C　　　　　　　　　　　 　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　１０　 　　　　　　　　　　　　３　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　１５　　　　D　 　　　　　　　　　　I　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　F 　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　G　　　５ 　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　１２ 　　　　　　　　　　　 　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 E 　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　H　　　７ １ ７ ６ ５ ４ ３ ２ ２’

7.3 アクティビティ所要期間見積り アクティビティ所要期間見積り インプット ツールと技法 アウトプット 1. アクティビティ・リスト 7.3　アクティビティ所要期間見積り アクティビティ所要期間見積り インプット 1.　アクティビティ・リスト 2.　制約条件 3．前提条件 ４．資源に対する要求事項 ５．資源能力 ６．過去の情報 ７．識別されたリスク ツールと技法 １．専門家の判断 ２．類推見積り 3.　定量ベース所要期間 ４．予備時間 　　（コンティンジェンシー） アウトプット １．アクティビティ所要期間 　　見積り ２．見積りの根拠 ３．アクティビティ・リスト 　　更新版 　　　　　　　　 　　 　　

7.4 スケジュール作成 スケジュール作成 インプット ツールと技法 アウトプット 1. プロジェクト・ネットワーク図 7.4　スケジュール作成 スケジュール作成 インプット 1.　プロジェクト・ネットワーク図 2.　アクティビティ所要期間見積り 3．資源に対する要求事項 ４．資源プール記述書 ５．カレンダー ６．制約条件 ７．前提条件 ８．リードとラグ ９．リスク・マネジメント計画書 １０．アクティビティ属性 ツールと技法 １．数理解析 ２．所要期間の短縮 3.　シミュレーション ４．資源平準化の経験則 ５．プロジェクトマネジメント 　　・ソフトウェア ６．コード体系 アウトプット １．プロジェクト 　　・スケジュール 2.　詳細資料 ３．スケジュール 　　・マネジメント計画書 ４．資源に対する要求事項 　　更新版

スケジュールの表現形式 グラフ、テーブル等 日付のプロジェクトネットワーク図 ガンとチャート図 マイルストン …

アウトプットの表現形式（Ⅰ） ガントチャート図の例 他の例

ガントチャート図の例（Ms Projectにより）

7.4.1 スケジュール作成技法 ① スケジュール作成までのプロセス （2.4.1.1） スケジュール作成技法 （2.4.1.2） 7.4.1　スケジュール作成技法 ① スケジュール作成までのプロセス （2.4.1.1） スケジュール作成技法 （2.4.1.2） プレシデンス・ダイアグラム法の適用例 （2.4.1.3） ５つの基本値とクリティカル・パス （2.4.1.4） 日程計算の方法（2.4.1.5） アロー・ダイアグラム法の適用例 （2.4.1.6） ダミー （2.4.1.7）

7.4.1.1 スケジュール作成までのプロセス (1)「スコープ定義」プロセスでWBSを作成する。 7.4.1.1　スケジュール作成までのプロセス (1)「スコープ定義」プロセスでWBSを作成する。 (2)「アクティビティ定義」プロセスでWBSの最下層（ワークパッケージ）をさらに要素分解してアクティビティを定義する。 (3)「アクティビティ順序設定」プロセスで各アクティビティ間の順序関係を明確にする。 (4)「アクティビティ所要期間見積り」プロセスで各アクティビティの所要期間を見積る。 (5)「スケジュール作成」プロセスでネットワーク図を完成させ、プロジェクト全体のスケジュールを作成する。

7.4.1.１　スケジュール作成までのプロセス

7.4.1.2 スケジュール作成技法Ⅰ １．プレシデンス・ダイアグラム法 7.4.1.2　スケジュール作成技法Ⅰ １．プレシデンス・ダイアグラム法 （PDM：Precedence Diagramming Method） 作業をノードで表現し、ノード間を、依存関係を表す矢線（アロー）で結んで作業の順序を表現したネットワーク図。 ・Activity on Node（AON）とも呼ばれます。 ・作業間には次の４つの依存関係が設定できます。 FS（Finish-to-Start）　：前の作業が終わると次の作業が始まる。 SS（Start-to-Start） ：前の作業が始まると次の作業も始まる。 FF（Finish-to-Finish）：前の作業が終わると次の作業も終わる。 SF（Start-to-Finish） ：前の作業が始まると次の作業が終わる。

作業をアローで表現し、作業間の接続表示にノードを用いて作業の順序を表現したネットワーク図。 7.4.1.2　スケジュール作成技法Ⅱ ２．アロー・ダイアグラム法 （ADM：Arrow Diagramming Method） 　作業をアローで表現し、作業間の接続表示にノードを用いて作業の順序を表現したネットワーク図。 Activity on Arrow（AOA）とも呼ばれます。 作業間の依存関係は、FS（終了－開始）のみが設定できます。 ダミー（順序関係を表すのみの、所要期間がゼロの作業）という便宜的な作業を必要とする場合があります。

7.4.1.3　プレシデンス・ダイアグラム法の適用例

7.4.1.4 ５つの基本値とクリティカル・パス ES（Early Start）：最早開始日（その作業を始めうる最も早い日） 7.4.1.4　５つの基本値とクリティカル・パス ES（Early Start）：最早開始日（その作業を始めうる最も早い日） EF（Early Finish）：最早終了日（最早開始日に作業を始めた時の予定終了日） LS（Late Start） ：最遅開始日（その作業を遅くとも始めなければならない限界日） LF（Late Finish）：最遅終了日（その作業を遅くとも終えなければならない限界日） TF（Total Float）：全余裕日数（その作業が持つ総余裕日数。これを使い切ると後に続く経路はクリティカル・パスとなる） 　クリティカル・パス （Critical Path）：TF=0 の作業の経路（最長経路すなわち工期）

7.4.1.5　日程計算の方法 ・前進計算 ES =［先行作業のEFの内、最も遅いEF ］+ 1 EF = ES + DUR - 1　　（DUR：作業期間） ・後退計算 LF =［後続作業のLSの内、最も早いLS ］- 1 LS = LF - DUR + 1 ・全余裕日数の計算 TF = LS - ES = LF - EF

7.4.1.5　日程計算結果 ネットワークについて日程計算をすると次のようになります。

7.4.1.6　アロー・ダイアグラム法の適用例

7.4.1.7　ダミー 　ダミーとは、 　アロー・ダイアグラム法で作業の順序関係を正しく図示するために導入された、作業の順序関係のみを規定する所要期間ゼロの「みせかけの作業」です。 　プレシデンス・ダイアグラム法ではダミーは必要ありません。

7.4.2　スケジュール作成技法 ② ◆　PERT　 （2.4.2.1） 　（Program Evaluation and Review Technique） ◆　３点見積法 （2.4.2.2） ◆　スケジュール・リスク分析 （2.4.2.3） ◆　モンテカルロ・シミュレーション （2.4.2.4） 【モンテカルロ(Monte Carlo)法】 乱数を用いたシミュレーションを何度も行なうことにより近似解を 求める計算手法。解析的に解くことができない問題でも、十分多くの回数シミュレーション を繰り返すことにより、近似的に解を求めることができる。

7.4.2.1 PERT PERT（Program Evaluation and Review Technique） PERTは、1950年代後半に米国海軍ポラリス・ミサイル開発プロジェクトで実用化された日程計画・管理のための技法としてあまりにも有名です。なお、同様の技法として、費用との関係を見ながら工期短縮を図ることをねらいとしたCPM（Critical Path Method）も、同じ頃にデュポン社工場建設のために実用化されています。 PERTの用法の一つとして、確率・統計理論を用いてプロジェクトに内包するスケジュール・リスクを分析することが挙げられます。例えば、各作業の所要期間を１通りではなく、楽観値、最可能値、悲観値の３通りで見積り、個々の作業のバラツキ具合を基にプロジェクト工期のバラツキ具合を予測して、スケジュール達成の可能性を予見するなどのように使われます。これを３点見積法と呼びます。

7.4.2.2 　３点見積法

　ベータ分布の期待値(平均)・分散・標準偏差：

　7.4.2　工期算出の前提 工期の平均と分散 　工期はクリティカル・パスにある各作業の平均日数の和で求められ、その分散もクリティカル・パス上の各作業の分散の和で求められる。（平均と分散の加法性） 工期の分布 　このときの分布は中心極限定理（個々の事象の分布を重ね合わせると正規分布に近づく）により正規分布にしたがう。

計算結果 　　計算の結果、このプロジェクトの平均工期は10.50日、その標準偏差は0.90日となりました。

7.4.2.3　スケジュール・リスク分析 　

7.4.2.4　モンテカルロ・シミュレーション 　モンテカルロ・シミュレーションはリスク分析でよく使われる技法です。これは、乱数を用いて幾度もシミュレーションを繰り返し、その結果得られる測定値の平均で真の値を推定しようというものです。解析的に解を求めることが難しい問題に有効な方法です。 　　　試行回数：　1000回　　　平均値： 10.96　　標準偏差：　1.09

7.4.3 スケジュール作成技法 ③ ―スケジュール短縮技法 7.4.3　スケジュール作成技法 ③ ―スケジュール短縮技法 スケジュール短縮技法を３つ紹介する。 再見積り（2.4.3.1） ファスト・トラッキング（Fast　tracking） （2.4.3.2） クラッシング（Crashing） （2.4.3.3） 　crash・ing ━━ a. 全くの, 根っからの, ひどい.

7.4.3.1　再見積り ◆再見積り 再見積りは最初に採るべきアプローチで、各作業の所要期間見積りは正確かどうか、つまり、正しい前提条件のもとで適切な方法で見積ったかどうかを再度確認します。 さらに、見積りの際に判明した課題は解決できるのか、識別されたリスクへの対処方法はあるのか、これら課題やリスクへの対応により各作業の所要期間見積りは短縮可能か、逆に短縮により新たに生じるリスクは何か、などの点も併せてレビューし、結果としてクリティカル・パスが短縮可能かどうか調べます。 なお、各作業の所要期間が変わるとクリティカル・パスも変わる場合があるので注意が必要です。

7.4.3.2 ファスト・トラッキング ファスト・トラッキング 7.4.3.2　ファスト・トラッキング ファスト・トラッキング 　　　ファスト・トラッキングは現実にはよく使われます。これは、特にクリティカル・パス上の作業間の順序や依存関係を見直し、リソース上の制約を考慮しながら並行作業を増やすことで工期を短縮する技法です。 　　　ファスト・トラッキングではリスクの予見が重要です。即ち、工期短縮の効果と、短縮により新たに生じるリスクを的確に認識しておくことです。また、短縮によるクリティカル・パスの変化にも注意します。

ファスト・トラッキングの例 例Ⅰ 前作業の完了を待って開始する後作業を、その完了を待たずに先行開始して並行して作業します。 例Ⅰ　前作業の完了を待って開始する後作業を、その完了を待たずに先行開始して並行して作業します。 例えば、詳細設計が完了する前に、設計がある程度できている部分からコーディングを開始するなど。この場合、詳細設計の完了レビューが行われていないため、コーディングに手戻りが発生するリスクがあります。 なお、この前倒しした期間をリードと呼びます。 例Ⅱ　プロジェクト・ネットワークの構造を変えることで、並行作業を増やす 例えば、作業間の依存関係のうち、FS（終了－開始）の関係をSS（開始－開始）やFF（終了－終了）の関係にできれば、その部分のパス（経路）が直列パスから並列パスになるのでスケジュールの短縮に効果があります。 　リードについては後で説明します。

リード（Leads）とラグ（Lags） リード： 　リード： 　後続作業の開始を前倒しするような論理的順序関係の修正。例えば、10日間のリードがあるFS（終了－開始）の依存関係では、後続作業は先行作業の終了よりも10日前に開始することができる。 　ラグ： 　後続作業の開始を遅らせるような論理的順序関係の修正。　例えば、10日間のラグがあるFS（終了－開始）の依存関係では、後続作業は先行作業が終了して10日間経たないと開始できない。 　リード（Leads）とラグ（Lags） 　作業間の依存関係に時間的なずれがある場合、それを把握するためにリードとラグが使用されます。リードはファスト・トラッキングで適用されます。

7.4.3.3　クラッシング（1） プロジェクトの計画段階における、クラッシングの一般的な手順は次の通りです (1)　クラッシング対象作業の選定： 通常はクリティカル・パス上の作業がクラッシングの対象になります。対象作業の選定は、プロジェクトの事情に即した観点から適宜な方法で行います 　よく使われる方法 短縮コスト（１日当りの必要コスト）の小さい作業から優先順位づけする。 なるべく早い段階で行う作業の優先度を上げる。（予見していないリスクの対応などのために時間的な余裕を持ちえる） 所要期間の長い作業の優先度を上げる。（短い作業に比べ短縮の影響が少ない） 要となる作業の優先度を上げる。（多くの後続作業への影響を減じる）

7.4.3.3 クラッシング（2） (2)必要リソースの手当て 7.4.3.3　クラッシング（2） (2)必要リソースの手当て 　（当該プロジェクトの中で手当てする場合）： 選定された作業と並行した、スケジュールに余裕のある作業のうち、必要かつ適切なリソースがあり、リソース供出後の影響の少ない作業からリソースを振り向ける。 (2)´必要リソースの手当て 　（当該プロジェクトの外から手当てする場合）： 選定された作業に対して、そのプロジェクトの外部から必要かつ適切なリソースを投入する。 (3)　クリティカル・パス再計算： 　　クリティカル・パスを再計算して短縮効果を確認する。 (4) (1)→(2)（(2)´）→(3)を、 　　短縮目標が達成されるか、または短縮可能限界まで繰り返す。

7.5 スケジュール・コントロール スケジュール・コントロール インプット ツールと技法 アウトプット １．プロジェクト ・スケジュール 7.5　スケジュール・コントロール スケジュール・コントロール インプット １．プロジェクト 　　・スケジュール 2.　実績報告書 3．変更要求 ４．スケジュール 　　・マネジメント計画書 ツールと技法 １．スケジュール変更管理 　　システム ２．実績測定 3.　追加の計画 ４．プロジェクトマネジメント 　　・ソフトウェア ５．差異分析 アウトプット １．スケジュール更新版 2.　是正処置 ３．教訓

7.5.1 ケジュール・コントロールの対象 ケジュール・コントロールの対象 WBS WBS コード ワーク パッケージ タイム・マネジメント 7.5.1　ケジュール・コントロールの対象 ケジュール・コントロールの対象 　　　　　　　　　　　　　　　　　　　　　WBS 　WBS 　コード 　ワーク 　パッケージ 　タイム・マネジメント 　コスト・マネジメント 　　　管理対象 作業１２ 作業１２２ 作業１２３ 作業１２33 作業１２34 アクティビティ

7.6　システム開発における考慮点 アクティビティ定義での考慮点 所要期間見積りでの考慮点 スケジュールの作成の考慮点

7.6.1 システム開発における考慮点① アクティビティ定義での考慮点 7.6.1　システム開発における考慮点① アクティビティ定義での考慮点 ①　アクティビティ・リストには、プロジェクトのために実施されるすべての活動を列挙する ②　アクティビティ定義の中には、顧客担当の作業や関連する他ベンダーの作業も含める。 ③　各工程の準備作業もアクティビティとして明確に定義する。

7.6.1 システム開発における考慮点2 所要期間見積りで以下の点を考慮する ① インプット 7.6.1　システム開発における考慮点2 所要期間見積りで以下の点を考慮する ①　インプット ②　見積りでは、妥当性（だとうせい）や実現可能性評価を得る。 ③　見積りを左右する要因 ④　見積りは、プロジェクトマネージャも必ず確認する。

7.6.3 システム開発における考慮点 ③ スケジュール作成では、以下の点を考慮する。 7.6.3　システム開発における考慮点　③ スケジュール作成では、以下の点を考慮する。 ①　プロジェクト・カレンダとして稼働日、稼働時間を考慮していること。 ②　ファスト・トラッキングを行わない計画を作成してみて、そのときの終了日と要求されている終了日との差異を重要な情報として扱う。 ③　スケジュール・コントロールのルールを決めておく。