プロジェクトマネジメント2～スコープ・スケジュール・リスクマネジメント～

snack

さて前回の続きで、PMBOKの「10の知識エリア」のスコープ・スケジュール・リスクを見ていくっす。今回はちょっと計算問題も出てくるっすよ。

ボキタロー

げっ、計算問題かぁ。やだなぁ。。。

snack

計算といっても小学生でもできるような簡単なものっすから心配無用っす。

プロジェクトスコープマネジメント

プロジェクトスコープマネジメントでは、プロジェクトを成功させるために必要な作業を過不足なく抽出し、「なにをどこまでやればいいのか」という作業範囲（スコープ）を定義します。

プロジェクトを、成果物スコープ（プロジェクトで作成する成果物の仕様や機能）とプロジェクトスコープ（成果物を完成させるための作業）の両面から必要な作業範囲を分析・管理します。

snack

ザックリ言うと、成果物スコープは「何を作るのか」、プロジェクトスコープは「何をやるのか」ということっす。

なお、一般的にスコープの定義にはWBSを利用します。

WBS

WBS（Work Breakdown Structure）とは、プロジェクトという１つの大きな作業のかたまりを細かい作業に分割して管理する手法です。細かい作業に分割することによって、「何をやればいいのか」「作業にどのくらいの時間・コストがかかるのか」といったことを見積もりやすくなります。

WBSの最下層にある最も小さい作業単位のことをワークパッケージといいます。

プロジェクトスケジュールマネジメント

プロジェクトスケジュールマネジメントでは、プロジェクトをスケジュールどおりに完了するように管理します。

主に次の２つの図を使って、作業の工程や所要時間を見積り、スケジュールの作成や進捗管理を行います。

アローダイアグラム（PERT）

作業工程の流れを図式化したもので、前後の作業の依存関係を考慮に入れたスケジュール作成や進捗管理が可能です。アローダイアグラムでは、次のような記号を使って図を描きます。

上の図では、作業B（２日）と作業D（１日）は合計３日で終了しますが、作業Aが終わるまで次の作業Fを始めることができません。つまり、作業Fを始めることができるのは作業Aが終了する４日目なので、１日待たなければいけないということになります。

クリティカルパス

クリティカルパスとは、プロジェクトにおいて最も時間のかかる経路（もっとも余裕のない経路）をいいます。プロジェクト全体の日数を短縮したい場合は、クリティカルパス上にある作業の短縮が必要となります。

snack

クリティカルパス以外の作業を短縮しても、全体の作業日数は短縮できないっすよ。

上の図の場合、経路は３通り考えられます。

①作業A（4日）→C（1日）→E（3日）：合計8日

②作業B（2日）→D（1日）→F（5日）：合計8日

③作業A（4日）→ダミー（0日）→F（5日）：合計9日

したがって、クリティカルパスは③の経路となります。

ガントチャート

横軸に時間、縦軸にタスク（作業）をとって、計画と実績の進捗状況を所要期間に比例した長さで表した図です。プロジェクトの進捗が計画に比べて、どれだけ進んでいるか（遅れているか）を視覚的に確認することができます。

プロジェクトリスクマネジメント

プロジェクトリスクマネジメントは、プロジェクト遂行において発生するリスクを分析し、リスクへの対応策を実行する管理活動です。

リスクはプロジェクトの進捗状況や外的要因によって変化するため、プロジェクト実行中においてもリスクを監視して、繰り返し分析を行う必要があります。

リスクマネジメントは次のようなプロセスで行われます。

1. リスク特定：リスクを洗い出して特定する。
2. リスク分析：リスクの発生確率や発生時の損失などを分析する。
3. リスク評価：リスク分析の結果からリスクを分類して対応の優先順位を付ける。
4. リスク対応：リスク評価の結果をもとに、どのように対応するのかを決定する。

この一連のプロセスおいて、リスク特定からリスク評価までをリスクアセスメントと呼びます。

リスクマネジメントにおいては、リスクアセスメント（リスクの特定・分析・評価）の結果を基に、リスクへの対応を実施します。なお、リスクへの対応策には回避、軽減、受容、転嫁の４つがあります。

確認○×問題

問1

システム開発のプロジェクトマネジメントに関する記述1〜4のうち、スコープのマネジメントの失敗事例は２つある。

1. 開発に必要な人件費を過少に見積もったので、予算を超過した。
2. 開発の作業に必要な期間を短く設定したので、予定期間で開発を完了させることができなかった。
3. 作成する機能の範囲をあらかじめ決めずにプロジェクトを開始したので、開発期間を超過した。
4. プロジェクトで実施すべき作業が幾つか計画から欠落していたので、システムを完成できなかった。

（出典：令和5年度春期分 問54一部改変）

問2

WBS（Work Breakdown Structure）ではプロジェクトで実施すべき作業内容と成果物を定義するので、作業工数を見積もるときの根拠として使用できる。

（出典：令和4年度春期分 問36一部改変）

問3

作業を縦軸にとって、作業の所要期間を横棒で表した図をアローダイアグラムという。

（出典：令和元年度秋期分 問42一部改変）

問4

図の工程の最短所要日数は70日、最長所要日数は100日である。

（出典：令和2年度秋期分 問55一部改変）

答えを見る

答え：×

各作業が最短で終了した場合のクリティカルパスは、作業A（30日）と作業B（50日）の合計80日となります。作業Cが70日で終わったとしても、作業Aと作業Bが終わらないと全体の作業は完了しないからです。したがって、最短所要日数は80日となります。

一方で、各作業が最長で終了した場合のクリティカルパスは作業Cの100日となるため、最長所要日数は100日です。

問5

次のアローダイアグラムに基づき作業を行った結果、作業Dが2日遅延し、作業Fが3日前倒しで完了した。このとき、作業全体の所要日数は予定と比べて2日前倒しとなる。

（出典：令和5年度春期分 問41一部改変）

答えを見る

答え：〇

まず、予定通りに作業が完了した場合のクリティカルパスを考えます。

・A（2日）→C（4日）→F（5日）：合計11日（クリティカルパス）

・B（3日）→D（1日）→F（5日）：合計9日

・B（3日）→E（1日）→G（5日）：合計9日

次に予定変更後のクリティカルパスを考えます。

・A（2日）→C（4日）→F（2日）：合計8日

・B（3日）→D（3日）→F（2日）：合計8日

・B（3日）→E（1日）→G（5日）：合計9日（クリティカルパス）

クリティカルパスが、変更前の11日から変更後は9日へ、2日短くなります。したがって、作業全体の所要日数は予定と比べて2日前倒しとなります。

問6

プロジェクトは期限が決まっているので、プロジェクト開始時点において全てのリスクを特定しなければならない。

（出典：平成31年度春期分 問37一部改変）

問7

システム開発プロジェクトにおいて、テスト工程で使用するPCの納入が遅れることでテスト工程の終了が遅れるリスクがあり、対応策を決めた。リスク対応を回避、軽減、受容、転嫁の四つに分類するとき、受容に該当する記述はdである。

（出典：令和2年度秋期分 問54一部改変）