ゆずたんのAP対策日記

応用情報技術者試験の勉強をブログに残します

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

リスク とは

もし発生した場合に、プロジェクト目標に影響を与える不確実な事象や状態のことを リスク と呼びます。

リスクは 発生する可能性のあるもの であり、既に発生したもの課題 または 問題点 と呼びます。

これらは区別して扱われます。

リスクマネジメント とは

プロジェクトにマイナスの影響を与えるリスクの発生確率と影響を、できるだけ抑えるためにリスクを管理することを リスクマネジメント と言います。

リスクの特定、リスクの分析、リスクへの対応などを行います。

リスク特定

発生する可能性のあるリスクを洗い出す作業です。以下のような方法が用いられます。

リスク分析 (リスクアセスメント)

リスクの 発生確率影響度 を分析する作業です。分析した結果を元に、それぞれのリスクに対して リスク評価 を行います。

分析・評価の方法には、大まかに優先順位付けを行う 定性的リスク分析 (定性的リスク評価) と、数値的に分析する 定量的リスク分析 (定量的リスク評価) があります。

代表的な手法としては、日本情報処理開発協会(JIPDEC)が開発した JRAM (JIPDEC Risk Analysis Method) があります。 2010年 には JRMS2010 を公開しました。

リスク対応

リスク分析の結果をもとに、プロジェクトにとってプラスのリスクは影響を大きくし、マイナスのリスクは影響を少なくするような戦略を策定する作業です。

プラスのリスクに対する戦略
  • 活用
    • 好機が確実に到来するようにする
  • 共有
    • 能力の高い第三者に好機の実行権を与える
  • 強化
    • 好機の発生確率や影響力を増加させる
  • 受容
    • 特に何もせず、発生したら利益を享受する
マイナスのリスクに対する戦略
  • 回避
    • 脅威を完全に取り除くため、プロジェクト計画を変更する (例: リスクヘッジ ... 損失を別のサブプロジェクトの利益と相殺する)
  • 転嫁
    • 脅威による影響の一部または全部を第三者に移転する (例: 損害賠償保険を掛ける)
  • 軽減 (最適化)
    • 脅威の発生確率や影響力を減少させる (例: 個人情報の取扱を厳重にする)
  • 受容 (保有)
    • 能動的な受容
      • 特に何もせず、脅威の発生に備えて時間や資金に予備を設けたりする
    • 受動的な受容
      • 特に何もせず、起きたときに考える

技術的にリスク対応を行うことを リスクコントロール 、資金面で対応することを リスクファイナンス と呼びます。

なお、予算との兼ね合いなどで、影響度の大きいリスクは軽減を行いますが、被害額の小さなものは受容するケースが多く見られます。

それでも残ったら

リスク対応の後に残ってしまったリスクを 残留リスク と呼びます。

Day #5-2 EVM

EVM とは

予算とスケジュールの両方からプロジェクトの進捗を評価する手法の 1つ に、 EVM (Earned Value Management) があります。

PMBOK ではコストコトロールの技法として紹介されています。

  • PV (Planned Value : 計画値)
    • 作業に割り当てられた予算
    • 計画から求められます
  • EV (Earned Value : 出来高)
    • 実施した作業の価値
    • 完了済みの作業に当初割り当てられていた予算
  • AC (Actual Cost : 実コスト)
    • 実際に発生したコスト
    • 実測値から求める

これらの 3つ の値から、次のような分析を行えます。

  • SV (Schedule Variance : スケジュール差異 )
    • {\displaystyle SV = EV - PV}
    • この値が + ならスケジュールは進んでおり、 - なら遅れています
  • SPI (Schedule Performance Index : スケジュール効率指数 )
    • {\displaystyle SPI = \frac{EV}{PV}}
    • 計画を 100% として、どれだけ進んだか表します
  • CV (Cost Variance : コスト差異 )
    • {\displaystyle CV = EV - AC}
    • この値が + ならコストは黒字、 - なら赤字です
  • CPI (Schedule Variance : コスト効率指数 )
    • {\displaystyle CPI = \frac{EV}{AC}}
    • 実コストを 100% として、計画された値が何 % かを表します

Day #5-1 プロジェクトコストマネジメント

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

プロジェクトを決められた予算内で完了させるために行う管理を プロジェクトコストマネジメント と言います。

プロジェクトだけでなく、プロジェクトに関わる要員のコスト管理も重要です。

コスト見積手法

各々のコストを見積もる手法は、いくつかあります。

ファンクションポイント法 (FP 法)

ソフトウェアの ファンクション (機能) を基本にして、その処理内容の 複雑さ から ファンクションポイント を計算してコストを見積もります。

要件が決まり必要な機能が見えてきた段階で見積もりが行えるという特徴があります。

計算には、 5つ のファンクションタイプと 3つ の難易度をもとに計算された 基準値 と、 14個 の特徴を 6段階 で評価した 調整値 を用います。

{ \displaystyle
ファンクションポイント = 基準値 * (0.65 + \frac{調整値}{100})
}

www.itmedia.co.jp

LOC 法

Lines Of Code の名の通り、ソースコード行数でコストを見積もります。プログラマによってコード行にばらつきがあるため、これに変わって FP 法が普及しました。

COCOMO

Constructive Cost Model の略で、ソースコード行数に担当者の能力や要求の信頼性などで補正をかけ、コストを見積もります。

現在では、ファンクションポイントなどの概念を取り入れた COCOMO II が提唱されています。

三点見積法 (PERT 分析)

見積もりの不確実性を考え、最良ケースの 楽観値 (Co) 、最悪ケースの 悲観値 (Cp) 、最頻ケースの 最頻値 (Cm) の 3パターン の見積もりを加重平均し、コストを計算します。

{ \displaystyle
C_E = \frac{C_O + C_P + 4C_M}{6}
}

数式から最頻値だけ突出して加重していることがよくわかりますね。

また、タイムマネジメントにて紹介した アローダイアグラム は、三点見積法でスケジュールを組み立てる際にアローダイアグラムが使われるため、 PERT とも呼ばれています。

yuzutan-hnk-ap-taisaku.hatenablog.com

補足: 開発規模と開発工数の関係

COCOMO では、システム開発工数を算出する際に次の式を使用します。

{ \displaystyle
MM = 3.0 * (KDSI)^{1.12}
}

MM が工数、 KDSI はソースコードの行数です。

この式から、 開発規模が大きくなると、指数的に開発工数が大きくなる ということがわかります。

Day #4-2 プロジェクトタイムマネジメント

プロジェクトタイムマネジメント とは

プロジェクトを所定の時期に完了させるため、進捗やスケジュールを管理する作業のことを プロジェクトタイムマネジメント と言います。

具体的には、継続的にスケジュールを管理し、進捗に応じて変更したり調整を行ったりすることです。

スケジュールの調整には、よく アローダイアグラム が用いられます。

アローダイアグラム とは

すべての アクティビティ の順序関係と時間を矢印でまとめ、図式化したものを アローダイアグラム と言います。別名 PERT とも呼ばれます。

アローダイアグラムを用いると、 クリティカルパス最早開始日 が簡単に求められます。

https://upload.wikimedia.org/wikipedia/commons/b/b9/Pert_chart_colored.gif By Jeremykemp at English Wikipedia (Transferred from en.wikipedia to Commons.) [Public domain], via Wikimedia Commons

図中の〇印のことを 結合点 または マイルストーン と言い、それらをつなぐ矢印を アクティビティ (作業) と言います。アクティビティは、 WBS で作成したワークパッケージを更に細かく分割した単位でもあります。

アクティビティにごとに見積時間が表され、スタートからゴールまでの作業経路が示されます。結合点に向かって入るアクティビティは、その結合点から出るアクティビティの前提条件となっており、すべてが完了しないと次のアクティビティを開始できません。

上記の図では 作業A が終わらなければ 作業D, E は開始できず、最終的なゴール (50) は 作業C, E, F が全て完了しなければ終わらないということになります。

最早開始日

結合点において最も早く次のアクティビティを開始できる時刻を 最早開始日 または 最早結合点時刻 と言います。

上記の図の結合点 (30) の最早開始日は、 作業A でかかった 3日 となり、結合点 (40) の最早開始日は 作業A + D でかかった 3日 + 1日 = 4日 となります。

しかし、結合点 (50) の最早開始日は (その後にアクティビティがあるとして)

  • 作業F → 作業A+ D + F → 3日 + 1日 + 3日 = 7日
  • 作業E → 作業A + E → 3日 + 2日 = 5日
  • 作業C → 作業B + C → 4日 + 3日 = 7日

のすべてのアクティビティが完了していなければなりません。つまり、最早でも 7日 になります。

なお、このようにスタートから経路を見ていく方法を フォワードパス と言います。

最遅開始日

結合点において最も遅くても次のアクティビティを開始しなければならない時刻を 最遅開始日 または 最遅結合点時刻 と言います。

最早開始日の算出で、上記の図のゴール (50) は最速で 7日 で完了することがわかりました。

そこで、結合点 (30) の最遅開始日を求めようとすると、 作業D, E が遅くてもいつまでに開始しなければいけないかを計算する必要があります。

作業E は 2日 で終わるため、作業開始から 5日目 に作業を開始しても全体のスケジュールには影響を及ぼさないことになります。

作業D は 作業E も合わせて 4 日かかるため、遅くても作業開始から 3日目 に作業を開始しなければなりません。

したがって、結合点 (30) の最遅開始日は、 3日 となります。

同じ計算をすべての結合点で行っていくと、最終的にスタートの結合点の最遅開始日は必ず 0日 になります。

なお、このようにゴールから経路を見ていく方法を バックワードパス と言います。

クリティカルパス

最早開始日と最遅開始日が同じ結合点 (= トータルフロート が 0 の結合点)を結んだラインを クリティカルパス と言います。

つまり時間的余裕がなく、ここが遅れるとプロジェクトのゴールが遅れるということになります。

トータルフロート

それぞれの結合点において、最早開始日と最遅開始日の差で求められる余裕時間です。これが大きいほど、スケジュールが柔軟である (変更に強い) と言えます。

クリティカルパスに遅れが生じる場合、トータルフロートで余った人的資源を割り当てるなどの対策を行うことができます。


スケジュール作成方法

それでは、実際にスケジュールを作っていきます。

クリティカルパス

クリティカルパスを計算し、それを基準にトータルフロートを計算し、スケジュールを構築します。

クリティカルチェーン

クリティカルパスをもとにスケジュールを作成する方法では、資源の制限を全く考慮していません。

そこで、資源の限度を考えながらクリティカルパスを修正し、スケジュールを構築します。

クラッシング

スケジュール予定が目標に間に合わない場合、コストとスケジュールのトレードをオフを分析し、 最小の追加コストで最大の期間短縮を行います

ファストトラッキング

スケジュール予定が目標に間に合わない場合、本来順序のある アクティビティやフェーズを並行して行います


スケジュールコントロール

プロジェクトの進捗を監視し、必要に応じてスケジュールを変更するなどします。これを スケジュールコントロール と言います。

クリティカルパス法などで求めた、基本となる スケジュールベースライン をもとに差異を分析し、スケジュールを調整します。

ガントチャート

縦軸にアクティビティ、横軸にカレンダーをとり、作業を行った時間を棒グラフで表現し視覚的に進捗をわかりやすくしたものを ガントチャート と言います。

https://upload.wikimedia.org/wikipedia/commons/5/5b/Tokai_Hairo.jpg By Masaqui [CC BY-SA 3.0 (https://creativecommons.org/licenses/by-sa/3.0)], from Wikimedia Commons

Day #4-1 プロジェクト(人的)資源マネジメント

プロジェクト(人的)資源マネジメント とは

プロジェクトを遂行するチームを作り、メンバがプロジェクトを成功させるために役割と責任を全うするよう管理を行うことを、 プロジェクト(人的)資源マネジメント と言います。

教育技法

プロジェクトの人材育成では、知識中心ではなく実践的な教育技法が用いられます。

  • OJT
    • "On the Job Training" の略。実際の業務を実践しながら教育する。
  • ケーススタディ
    • 具体的な事例を取り上げ詳細な分析を行い、特化した教育を行う。
  • インバスケット

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

プロジェクトスコープ とは

プロジェクトの範囲のことをプロジェクトスコープと言います。プロジェクトスコープには、プロジェクトに必要な条件が 過不足なく 含まれます。

例えば、プロジェクトの 成果物 、成果物の受け入れ基準などが含まれます。逆に、プロジェクトからの 除外項目 を明確に表す必要もあります。

これらを定義する作業を スコープ定義 と言います。スコープ定義では プロジェクトスコープ記述書 に定義した内容をまとめます。

要求事項収集

プロジェクトの目標には、ステークホルダが積極的に関与しています。ステークホルダのニーズを定義する作業を 要求事項収集 と言い、定義した文書を 要求事項文書 と言います。

スコープコントロール

プロジェクトスコープは時間の経過とともに変化してしまいます。とくに、 時間とともに拡大していく傾向 があります。この状態を スコープクリープ と言います。

AT 車でエンジンをかけるとアクセルを踏まなくても進む現象をクリープ (creep) 現象と言いますね。確かに似ている。

スコープクリープが起こるとプロジェクトの成功が危うくなってしまうため、プロジェクトマネージャは適切な スコープコントロール を行う必要があります。

WBS とは

WBS (Work Breakdown Structure) は、プロジェクトで行われる作業を 階層的に要素分解したもの です。

フェーズや成果物の種類で分解したのち、最終的に アクティビティ (実際に行う作業) を割り当てる ワークパッケージ という単位まで分解します。

WBS を作成することで、プロジェクトスコープ全体を系統立てて定義できます。

https://upload.wikimedia.org/wikipedia/commons/5/57/WBS_sample.jpg By Masaqui [CC BY-SA 3.0 (https://creativecommons.org/licenses/by-sa/3.0)], from Wikimedia Commons

WBS は過去の実績を参考にすることで効率的に作成できるため、 WBS テンプレートというひな形を用いて作成されることもあります。

WBS辞書

WBS だけでは表しきれない 作業の詳細な記述 をまとめたものを WBS 辞書と言います。 WBS を補完する意味で用いられます。

Day #2-2 プロジェクトステークホルダマネジメント

ステークホルダ とは

ステークホルダは 利害関係者 のことです。プロジェクトに影響 (利害) を与えるか、プロジェクトによって影響 (利害) が生じる個人や組織です。

具体的には、顧客、スポンサー、プロジェクトチームのメンバ、メンバが所属する組織、商品の納入を行う業者などがステークホルダになります。

プロジェクトステークホルダマネジメント とは

プロジェクトステークホルダマネジメントでは、ステークホルダを明確にすることが目的とされます。

ステークホルダエンゲージメントマネジメントと呼ばれるプロセスでは、ステークホルダの関係や関係度を調整し、適切なものとしていきます。

また、ステークホルダを適切に管理するため、 ステークホルダ登録簿 を作成し、利害や環境などの評価情報をまとめて管理します。