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

レビュー １．タイム・マネジメントには、（？ ）のプロセスがある。 各プロセスの主なアウトプットは？ ２．WBSでスケジュールを作る流れ 　　各プロセスの主なアウトプットは？ ２．WBSでスケジュールを作る流れ ３．　アクティビティ順序設定の技法？区別？ ４．作業間の依存関係は？ ５．CPM?　PERT? ６．スケジュールの表現形式？ ７．所要期間の短縮技法は？例を挙げて 6.干特图 里程碑 网络图等 7.再見積り（2.4.3.1） ファスト・トラッキング（Fast　tracking） （2.4.3.2） クラッシング（Crashing） （2.4.3.3）

クリティカルパスの例

PMBOKプロセス群と知識エリアのマップ 　　　　　　プロセス群 知識エリア 立ち上げ 計画 実行 コントロール 終結 統合マネジメント プロジェクト計画の策定 プロジェクト計画の実行 統合変更管理 スコープ・マネジメント スコープ計画 スコープ定義 スコープ検証 スコープ変更管理 タイム・マネジメント アクティビティ定義 アクティビティ順序設定 アクティビティ所要期間見積り スケジュール スケジュール・コントロール コスト・マネジメント 資源計画 コスト見積り コストの予算化 コスト・コントロール 品質マネジメント 品質計画 品質保証 品質管理 人的資源マネジメント 組織計画 要員調達 チーム育成 コミュニケーション・マネジメント コミュニケーション計画 情報配布 実績報告 完了手続き リスク・マネジメント リスク識別 定性的リスク分析 定量的リスク分析 リスク対応計画 リスクの監視・コントロール 調達マネジメント 調達計画 引合計画 引合 発注先選定 契約管理 契約完了

コンセプトフェーズでの見積り手法 見積り法 方法 説明 精度 類推見積り Analogous Estimate 類似のプロジェクトの費用を参照 -25%～+75%が目標 パラメトリック見積り Parametric　Modeling 道路工事なら１ｍ単価ｘ何ｍ ＰＧならステップ換算、画面/帳票換算 -20%～＋25%が目標 ボトムアップ見積り Bottom-up　Estimate ＷＢＳのワークパッケージをベースにした詳細見積り -5%～＋10%目標 見積り精度 Order　of　Ｍａｇｎｉｔｕｄｅ コンセプトフェーズ段階のフィージビリティ 概算見積りで詳細データがない 類推見積り 予算化　Ｂｕdｇｅｔ プロジェクト承認のための大枠 パラメトリック　ｏｒ　概略ＷＢＳ -10%～＋25%が目標 確定　Definitive 入札提案書（Bid　Proposal）、入札評価（Ｂｉｄ　　Evaluation）等で使用。仕様書、図面、データ等が必要 WBS

複雑であること。 試行錯誤が必要なこと。 仕様が不明確であること。 補充内容 ソフトウェア開発の見積り 補充内容　　ソフトウェア開発の見積り ソフトウェア開発の見積もりを困難にしている要因 　複雑であること。 　試行錯誤が必要なこと。 　仕様が不明確であること。　

補充内容　　ソフトウェア開発のコスト 　ソフトウェア開発のコストを工程別に分けていくと、次のようになる。 　機能設計 　内部設計 　プログラミング 　単体テスト 　結合テスト 　その他、環境設定など

補充内容 見積もり技法 見積もり技法としては 下記のものが知られている。 類推法 積算法 COCOMO FP法 COCOMO II 補充内容　　　　　見積もり技法 　見積もり技法としては 　下記のものが知られている。 　類推法 　積算法 　COCOMO 　FP法 　COCOMO II るいすい[類推][名词；n]相似；analogy るいすい[類推][名·他サ]类推

補充内容 見積もり技法 類推法 積算法 過去の類似の開発事例から開発規模を類推する手法。 補充内容　　　見積もり技法 類推法 　　過去の類似の開発事例から開発規模を類推する手法。 　　問題点：過去のプロジェクトのデータを役に立つほど蓄積できるのは、大手の開発業者に限られる。しかも現在は開発手法がかなり変化してきているので、過去のデータは役に立たない場合が多い。 積算法 　　必要な作業項目を細分化していって、それらの工数を見積もり合成する手法。ソフトウェア開発においては、開発工程と機能分類のマトリックスで作業項目を細分化する。その細分化された作業項目をどのように見積もるかと言うことについては、この手法では関知していない。

補充内容 見積もり技法 COCOMO FP法 COCOMO II 開発するソフトウェアの行数を把握し、その行数を開発工数に換算する手法。 補充内容　　　　　　見積もり技法 COCOMO 　　開発するソフトウェアの行数を把握し、その行数を開発工数に換算する手法。 　　問題点：まだ開発していないソフトウェアに行数をどのように把握するのかという問題がある。これははっきり言って勘で行うしかない。また同じ行数でも難易度が高いものと低いものがある。つまり換算率が異なる。COCOMOとは、Constructive Cost Modelの略。1981年にベームが開発した手法。 FP法 　　Function Pointの略。システムの画面や帳票、データべースのレコードなどを洗い出し、それぞれの複雑さを点数化して、その値から開発の工数を算出するもの。 　　問題点：大部分の見積もり作業は、これらの要素が確定する以前に行わなければならないという根本的な問題がある。 COCOMO II 　　簡単に言えばCOCOMOにFP法の要素を取り入れたもの。

見積り技法 概要 特徴 使用上の注意 概算法 （類推法） 積算法 （積上げ法） 標準タスク法 CoCoMo ファンク ションポイ ント法 過去に実績のあるプロジェクトをベースとして、 対象となるプロジェクト工数やコストを見積も る。主にプロジェクトの初期段階で行われるこ とが多いです。 見積りコストが安価 で済む。 類似プロジェクトが 過去にあれば信頼性 は高くなる。 過去のプロジェクト実 施者に見積りを依頼 のデータベースを活用 したりする。 積算法 （積上げ法） プロジェクト上で必要となる作業項目をWBSに よって洗い出し、その作業ごとの工数を個別に 見積もる。それから、個別の工数を積み上げて 計算する WBSを細かくすること で、見積り精度向上 させることができる。 WBSを細かくすればする ほど、見積りコストが 上昇する。 標準タスク法 開発工程を標準的な複数のタスクに定義し、そ れぞれ過去の実績から設定された作業工数を与 える（標準タスクテーブル）このテーブルをも とに対象となるプロジェクトの見積りを算出する 積算法を標準化した ものである。標準化 しているため,見積り に統一性があり、 ユーザの理解も得やすい。 標準値の設定に開発規 模などの付加的要件を 反映させ、定期的に標 準値を見直す必要があ る。 CoCoMo プログラムのソースコードの行数で見積りを行う。 過去、主に、アセンブラやCOBOLなど、メインフ レーム中心のソフトウェア開発で利用された。 開発規模を見積もる技 法ではなく、ソース コード行数と工数との 変換技法と考えると理 解しやすい。 ウォーターフォール型 の開発を想定している。 数万から数十万ステッ プ規模の見積りに適し ている。 ファンク ションポイ ント法 （FP法） 画面入力や帳票出力、使用ファイル、外部インタ フェースなどの機能数（ファンクションポイン） によって見積りを進める。開発形態の多様化に対 応して、多くの企業で採用されだした。機能は５ つのタイプ（内部論理ファイル、外部インタェ ースファイル、外部入力、外部出力、外部照会） にわけてカウントされる。 開発環境に影響される ことなく、ソフトウェ アの開発規模を測定す ることができる。 FPは規模の大きさを示 すものなので、開発工 数を求めるには、別途 変換テーブルの作成が 必要となる。 COCOMOⅡ ソースコードの行数から工数に変換すること になっている。工数調整にソフトウェアの再 利用やプロジェクトメンバーの経験などの要 素が重み付けされる。 新規開発のみでなく、 再利用を含んだ開発に も対応することができ 開発のどの時期に見積 もるかによって、３つ のモデル（基本COCOMO、 中間COCOMO、詳細 COCOMO）に分かれる。

標準タスク法の例

ファンクションポイント算定手順 トランザクション 《処理》the transaction.

補充内容 EVMSで進捗を管理する 全体価値、達成価値、実経費を求める スケジュール差異とコスト差異を求める 　全体価値、達成価値、実経費を求める 　スケジュール差異とコスト差異を求める 　スケジュール効率とコスト効率を求める 　スケジュールとコストを予想する EVMS (earned value management system) EVM / アーンドバリュー・マネジメントシステム / 出来高管理システム 　作業の進ちょくや達成度を（通常は）金銭的に表現したものであるアーンドバリュー（earned value）を統一的な尺度として、プロジェクトのパフォーマンス（コスト、スケジュール）を定量的に測定・分析し、一元的な管理を行うプロジェクト管理手法のこと。 　一般にWBSをベースに必要な工数を算出し、ここから金銭価値で表現した計画を作成し、チェックポイントごとの達成予定額（パフォーマンス・メジャメントベースライン：PMB）を設定する。計画では各作業の金銭総和がプロジェクトの総コストとなる。プロジェクト実施段階でも達成作業量も金銭表現して達成予定額と比較することで、作業進ちょくのスケジュールを定量的に把握する。同時に実出費と達成額を比較することで、コスト面の進ちょくも測定できることになる。 　スケジュール、コストの両面で、計画値からの乖離（かいり）を常時把握することで、プロジェクトのパフォーマンスを動的に測定し、精度の高い完了時期や完了時のコスト予測が可能となる。また、完了遅延や予算超過の程度も予測できるため、プロジェクトオーナーにとってリスク管理の有効なツールとなる。また、PMBOKにおいても、進ちょく管理の基礎的ツールとして位置付けられている。 　歴史的には古く、まず1962年のミニットマンミサイル開発計画で適用され、1967年に米国国防総省の調達規定の一部として、C/SCSC（Cost/Schedule Control Systems Criteria）と呼ばれる35項目の管理基準が設定された。この基準を民生への適用も視野に入れ、米国国防産業協会（NDIA：National Defense Industrial Association）の要望に基づいた若干の修正と用語解説を付加したものがリリースされ、1998年6月には米国規格協会（ANSI：American National Standards Institute）がEVMSの名称で、ANSI/EIA-748-1998として発行した。 　米国では一定額以上の政府系の入札では応札業者に対応が義務付けられており、国防総省やNASAでは大規模なEVMS教育が行われている。カナダ、英国、スウェーデンなどでも国内規格として活用され、日本においても経済産業省がシステム開発プロジェクトの管理手段として採用を推奨している。

アーンド・バリュー・マネジメント アーンド・バリュー・マネジメントとは、 予算および予定の観点からプロジェクトがどのように遂行されつつあるかを定量的に評価するプロジェクト管理の技法である。1967年に米国防総省の調達規則の一部として制定された C/SCSC(Cost/Schedule Control System Criteria)が元となっている。1990年代、クリントン大統領政権下における国家的プロジェクトのパフォーマンス改善を通じて見直され、発展してきた。プロジェクトマネジメント知識体系ガイド (PMBOK) の2000年版では、コスト・マネジメントの技法として言及されて (7.4.2.3) いる。進捗の進み/遅れのような指標（スケジュール差異）も日数/時間という単位ではなくコストを単位として求められる点に特色がある。

補充内容 EVMSで進捗を管理する ワーク・ブレークダウン・ストラクチャー(WBS, Work Breakdown Structure) アーンド・バリュー・マネジメントをプロジェクトに適用しようとするプロジェクト・ マネジャーには 以下に挙げる基本情報が必要である。 ワーク・ブレークダウン・ストラクチャー(WBS, Work Breakdown Structure) 階層化され詳細化された、全てのプロジェクト構成要素のリスト プロジェクトのマスター・スケジュール(PMS, Project Master Schedule) 各タスクの納期と担当者が示されたガントチャート 計画価値(PV, Planned Value) 当該期間末までに完了しているものとして計画された作業の予算 アーンド・バリュー(EV, Earned Value) 当該期間末までに進捗した作業を、その作業の計画価値に対する比から評価した価値 実コスト(AC, Actual Cost) 当該期間末までに実際に投入した総コスト 完成時総予算 (BAC, Budget at Completion) プロジェクトの完了時点におけるPV

補充内容 EVMSで進捗を管理する 次のような評価値を算定することができる コスト差異(CV, Cost Variance) EV - AC（0以上であれば良好） スケジュール差異(SV, Schedule Variance) EV - PV （0以上であれば良好） コスト効率指数 (CPI, Cost Performance Index) EV÷AC（1以上であれば良好） スケジュール効率指数 (SPI, Schedule Performance Index) EV÷PV（1以上であれば良好） 完成時総コスト見積り(EAC, Estimate At Completion) AC + (BAC - EV)÷CPI プロジェクト・マネジャーは、これらの情報を基に次のような評価値を算定することができる。

ＥＶＭＳ （Earned Value Management System） ＰＶ　ベースライン ＡＣ　　実コスト EV　アーンドバリュー ＢＡＣ 完了予算コスト ＶＡＣ：完成時での差異 ＳＶ：スケジュール差異　期間表示 ＳＶ：スケジュール差異　コスト表示 ＣＶ：コスト差異 EV 予測のプロジェクトの時間遅れ 現時点 計画完了時点 ＰＶ ベースライン ＥＶ ＡＣ コスト 時間 ＥＡＣ 完了予測コスト

EVMS：Ｅｒｎｅｄ Ｖａｌｕｅ Management System ・BCWS　Budgeted Cost of Work Scheduled ＝＞ＰＶ 計画された作業に対する予算化されたコストのこと。一般にＳ字カーブを描く。 　　計画された価値　PV　Planed　Value　という。　これが　進捗測定用　ベースラインとなる。 ・BCWＰ　Budgeted Cost of Work Performed ＝＞ＥＶ 指定された段階で完了した作業に対する計画上の予算化されたコストのこと。完了したＷＰの予算化されたコストの累積で計算する。　　　獲得ＥV　Earned　Value　という。 ・ＡCWＰ　Actual Cost of Work Performed　＝＞ＡＣ　指定された段階で完了した作業に対する実際に費やされたコストのこと。間接費も含まれる。 　　　実コスト　ＡＣ　Actual　Cost　という。 ・CV　Cost　Variance　　　　　　　ＣＶ＝ＥＶ－ＡＣ　実際に処理した作業にかかったコストの計画値からの差異 ・SV　Schedule　Variance　　　　ＳＶ＝ＥＶ－ＰＶ　実際に処理した作業の計画からの遅れまたは進みの絶対値 ・EAC　Estimate　At　Completion　EAC＝AC＋（BAC－ＥＶ）／ＰＦ　　完成時予測総コスト 　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　PF　Performance　Factor（CPI　or　SPI　or　CPI×SPI） ・VAC　 Variance　At　Completion　　VAC＝ＥＡＣ－ＢＡＣ　完成時予測総コストと計画時総コストの差異 ・CPI　Cost　Performance　Index　　　CPI＝ＥＶ／AC　実施した作業の計画のコストの実質コストに対する比率の指標 ・SPI　 Scheduled 　Performance　Index　SPI＝ＥＶ／ＰＶ　実施した作業の計画のコストの計画コストに対する比率の指標 ・TCPI　To　Complete　Performance　Index　（BAC－ＥＶ）／（EAC－AC）　現時点以降のＣＰＩを表す。 　　アーンド・バリュー・マネジメント アーンド・バリュー・マネジメントとは、予算および予定の観点からプロジェクトがどのように遂行されつつあるかを定量的に評価するプロジェクト管理の技法である。1967年に米国防総省の調達規則の一部として制定された C/SCSC(Cost/Schedule Control System Criteria)が元となっている。1990年代、クリントン大統領政権下における国家的プロジェクトのパフォーマンス改善を通じて見直され、発展してきた。プロジェクトマネジメント知識体系ガイド (PMBOK) の2000年版では、コスト・マネジメントの技法として言及されて (7.4.2.3) いる。進捗の進み/遅れのような指標（スケジュール差異）も日数/時間という単位ではなくコストを単位として求められる点に特色がある。 日本においても、経済産業省が実証プロジェクトを通じてアーンド・バリュー・マネジメントのガイドラインを策定しているなどの動きがあり、政府の調達案件では今後アーンド・バリュー・マネジメントの技法による管理を行うことを受注の条件とすることも検討されていると言われている。 アーンド・バリュー・マネジメントでは、ある時点までにプロジェクト・チームが完成した成果とプロジェクト開始時に予測した見積りとが比較される。この比較から、プロジェクトが完了状態からどれほど離れているかについての標準が与えられる。既にプロジェクトに投入された作業量から推定することによって、プロジェクト・マネジャーは完了時点までにどれほどのリソースが使用されるかの見積もりを得ることができる。 この技法はクリティカル・パスの概念に基づいている。プロジェクトのパフォーマンスを測定し管理する手法には、他にクリティカル・チェーン法がある。クリティカル・チェーン法では、代わりにバッファ管理を採用している。その理由は、アーンド・バリュー・マネジメントではプロジェクトの制約条件(即ちプロジェクトのクリティカル・チェーン)とプロジェクトの非制約条件(即ちプロジェクト・ネットワーク中のクリティカル・チェーン以外のパス)が明確に区別されないためである。この性質は、時によるとより良いアーンド・バリュー評価を追求しようとするプロジェクト・マネジャーに、クリティカルな作業を犠牲にして非クリティカルな作業の遂行を促進させうるものであり、その結果プロジェクトの完了は遅れてしまう。これは、部分的な評価は全体的な評価に従属するという意識が不足した結果として、局所的な最適化を行ってしまうという問題である。 アーンド・バリュー・マネジメントをプロジェクトに適用しようとするプロジェクト・ マネジャーには以下に挙げる基本情報が必要である。 ワーク・ブレークダウン・ストラクチャー(WBS, Work Breakdown Structure) 階層化され詳細化された、全てのプロジェクト構成要素のリスト プロジェクトのマスター・スケジュール(PMS, Project Master Schedule) 各タスクの納期と担当者が示されたガントチャート 計画価値(PV, Planned Value) 当該期間末までに完了しているものとして計画された作業の予算 アーンド・バリュー(EV, Earned Value) 当該期間末までに進捗した作業を、その作業の計画価値に対する比から評価した価値 実コスト(AC, Actual Cost) 当該期間末までに実際に投入した総コスト 完成時総予算 (BAC, Budget at Completion) プロジェクトの完了時点におけるPV プロジェクト・マネジャーは、これらの情報を基に次のような評価値を算定することができる。 コスト差異(CV, Cost Variance) EV - AC（0以上であれば良好） スケジュール差異(SV, Schedule Variance) EV - PV （0以上であれば良好） コスト効率指数 (CPI, Cost Performance Index) EV÷AC（1以上であれば良好） スケジュール効率指数 (SPI, Schedule Performance Index) EV÷PV（1以上であれば良好） 完成時総コスト見積り(EAC, Estimate At Completion) AC + (BAC - EV)÷CPI

EVMS：Ｅｒｎｅｄ Ｖａｌｕｅ Management System ＥＶＭＳによる進捗管理手法 　１．ＣＶ、ＳＶが１０％の閾値を越えると異常と言う判断を下す。 　２．ＣＰＩ、ＳＰＩが０．９を下回る場合を異常と判断する。 　　　異常を発見一時は、何らかの対応策をとる。 　　　また、ＣＶ、ＳＶ、ＣＰＩ、ＳＰＩが7回連続して悪化の傾向を示したら、 　　　そのプロジェクトまたはＷＰを重点管理する。 　☆　ＶＡＣ＜ＣＶ　最終結果が現在地よりもよくなるという報告が上がったらおかしいと判断できる。 　☆　ＴＣＰＩ＞ＣＰＩ　現時点以降のＣＰＩが過去のＣＰＩより改善される報告が上がったらおかしい。 　☆　算出したＥＡＣ＞＞報告された完成時総コスト　 　　　完成時総コストがＥＡＣよりも大幅に改善された報告書はおかしい。 　★　変更管理　ＣＣＢ　Change　Control　Board　の判断を仰ぐ 　　　EVMSの基盤となるベースラインはスコープ（マネジメントまたは成果物）の変更が 　　　行われたときのみ変更となる。つまり予算の見直し。 　　・プロジェクト全体の変更管理　スコープ、スケジュール、コスト、品質、契約・・・の変更管理

＜ＥＶＭＳ（アーンドバリュー分析＞ ＢＡＣ（Total budget） ＰＶ（ＢＣＷＳ） ＥＶ（ＢＣＷＰ） ＳＶ （ＰＶ－ＥＶ） ＣＰＩ ⑧進捗を管理する ＜ＥＶＭＳ（アーンドバリュー分析＞ （アーンドバリューとは、出来高のこと） ＢＡＣ（Total budget） ＰＶ（ＢＣＷＳ） ＜計画予算コスト＞その時点までにどれだけの仕事が終わっていなければならないか ＥＶ（ＢＣＷＰ） ＜出来高＞実際にはどれだけの仕事が終わっているのか ＜実際発生コスト＞終わった仕事にいくら費用がかかったのか ＜コスト差異＞ ＣＶ＝正：予算以内　　ＣＶ＝負：予算超過 ＳＶ （ＰＶ－ＥＶ） ＜スケジュール差異＞ ＳＶ＝正：計画より早い　　ＳＶ＝負：計画より遅れ ＣＰＩ （ＥＶ/ＡＣ） ＜コスト効率指標＞ＣＰＩ＞1：コストが計画より少ない　　ＣＰＩ＜1：コストが計画より多い ＳＰＩ （ＥＶ/ＰＶ） ＜スケジュール効率指標＞ＳＰＩ＞1：作業が計画より早い　　ＳＰＩ＜1：作業が計画より遅い ＜完成時総予算＞ ＜完成時総コスト見積り＞ ＶＡＣ （ＢＡＣ－ＥＡＣ） 完成時での差異 ＡＣ（ＡＣＷＰ） ＣＶ （ＰＶ－ＡＣ） ＥＡＣ コスト（円） 日 現在 納期 ＡＣ ＣＶ ＢＡＣ ＥＡＣ ＶＡＣ ＰＶ ＥＶ ＳＶ

今日の内容 コスト・マネジメント

第8回． コスト・マネジメント 8.1 資源計画 8.2 コスト見積り 8.3 コストの予算化 8.4 コスト・コントロール 8.1　資源計画 8.2　コスト見積り 8.3　コストの予算化 8.4　コスト・コントロール 8.5　システム開発における考慮点

コストマネジメント

コスト・マネジメントのプロセス コスト・マネジメント コスト・マネジメントは次の図に示す ４つのプロセスがある。 資源計画 コスト見積り ４つのプロセスがある。　　　　　　　　　　　　　　　　　　　　　　　 　　　　　　　　　　　　　　　　　　　　　　　　　計画のプロセス 　　　　　　　　　　　　　　　　　　　　　　　 　　計画のプロセス 　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　コントロールのプロセス コスト・マネジメント 資源計画 コスト・コントロール コスト見積り コストの予算化

8.1 資源計画 資源計画 インプット ツールと技法 アウトプット １．ワーク・ブレークダウン ・ストラクチャー（WBS） 2. 過去の情報 8.1　資源計画 資源計画 インプット １．ワーク・ブレークダウン 　　・ストラクチャー（WBS） 2.　過去の情報 3．スコープ記述書 ４．資源プール記述書 ５．組織の方針 ６．アクティビティ所要期間 　　見積り ツールと技法 1.　専門家の判断 ２．代替案の識別 ３．プロジェクトマネジ 　　メント・ソフトウェア アウトプット １．資源に対する 　　要求事項

8.2 コスト見積り コスト見積り インプット ツールと技法 アウトプット １．ワーク・ブレークダウン １．類推見積り 8.2　コスト見積り コスト見積り インプット １．ワーク・ブレークダウン 　　・ストラクチャー（WBS） 2.　資源に対する要求事項 3．資源レート ４．アクティビティ所要期間 　　見積り ５．見積り関連刊行物 ６．過去の情報 ７．勘定科目表 ８．リスク ツールと技法 １．類推見積り ２．係数モデル見積り 3.　ボトムアップ見積り ４．コンピュータ・ツール ５．他のコスト見積り手法 アウトプット １．コスト見積り 2.　詳細資料 ３．コスト・マネジメント 　　計画書

8.2 見積り段階と見積り方法の適用例 フェーズ タスク 初期見積り 概算見積り 詳細見積り 8.2　見積り段階と見積り方法の適用例 定義 機能設計（分析） システム設計 開発 導入 適用 システムの 目的を定める 機能設計 プロジェクト計画 機能設計レビュー システム基本設計 システム詳細設計 設計レビュー プログラム設計 プログラム製作 システムテスト システムテストレビュー 納入／設置 システム 導入支援 適用支援 保証サポート フェーズ タスク 　　　　　初期見積り　　　　　概算見積り　　　　　　　　詳細見積り 　　・　類推見積り　　　　　　・　係数モデル見積り　　・　係数モデル見積り　　　　　　　　　　　　　　　　　　　　　　 　　　　例：　（画面数＋帳票数）　　　　　　例：　SPR法　　　　　　　　　　　　　例：　IFPUG法 　　　　　　　　X定数 　　　・　係数モデル見積り　　・　ボトムアップ見積り　　・　ボトムアップ見積り　　 　　　　　例：　Early FP法 　　　・　ボトムアップ見積り Early Function Point Counting 開発初期段階でのFPカウント方法 (This page is also available in Dutch and in Japanese) NESMA（Netherlands Software Metrics Association）では、システム開発の初期段階で使用できる二つのＦＰカウント方法を開発した。： FP概算法 (estimated function point count) FP試算法 (indicative function point count) (後者のFP試算法は、"オランダ方式 (the Dutch method)"としてＦＰＡリストサーバ／カナダ ケベック大学運営に、載っている。) ここでは、FPカウントの二つの異なる方法と、その適応性、検証の結果について説明する。   次の内容で説明を進める。 IFPUG法：The（detailed）Function point count FP概算法：The estimated function point count FP試算法：The indicative function point count IFPUG法、FP概算法、FP試算法の比較例 どのカウント方式をいつ使えば良いか １００以上のプロジェクトのデータによる検証結果  IFPUG法：The（detailed）Function point count IFPUG法は正式のカウント方法で、下記の手順で行う。 全てのファンクションについて、ファンクションタイプ (ILF, EIF, EI, EO, EQ) を決定する。 全てのファンクションの複雑度 (Low, Average, High) を評価する。 未調整ファンクションポイントを計算する。 概略の説明へ戻る FP概算法：The estimated function point count FP概算法は、下記の手順で行う。 全てのデータファンクション (ILF, EIF) の複雑度をLowに、 全てのトランザクションファンクション (EI, EO, EQ) の複雑度をAverageとする。 従って、正式のカウント方法との唯一の違いは、その複雑度の評価をファンクション毎に行うのではなく、デフォルト値で決める点である。 概略の説明へ戻る  FP試算法は、下記の手順で行う。 データファンクション (ILF, EIF) の数を決定する。 アプリケーションの未調整FP値を下記の計算で求める。 FP試算値 (FP) = 35 x ILFの数 + 15 x EIFの数 即ち、このFP試算値は、論理ファイル (ILF, EIF) のみに基づいて算出される。 FP試算法は、下記の仮定に基づいている。 ILFには、平均して、３つのEI (ILFに対する追加、変更、削除）と、２つのEO、１つのEQを伴う。 EIFには、平均して、１つのEO、１つのEQを伴う。 概略の説明へ戻る IFPUG法、FP概算法、FP試算法の比較例 この節では、三つのFPカウント方法を簡単な事例で説明する。事例は、顧客データと製品データを維持管理し、供給者データを参照するアプリケーションである。 より正確なFP値を求めるには、より詳細なユーザ要求仕様が必要となる。そのため、この事例では三つの方法をFP試算法、FP概算法、IFPUG法の順番で説明する。 FP試算法 ユーザ要求： ユーザは、顧客データと、製品データを維持管理し、供給者データを参照することを要求している。. この（ラフな）仕様でも、FP試算法には十分である。 ILF: 顧客データ、製品データ EIF: 供給者データ   データファンクション ファンクションタイプ ＦＰ値 (デフォルト) 顧客データ ILF 35 製品データ 供給者データ EIF 15  　  FP試算値  85 fp FP概算法 FP概算法を行うには、トランザクション・ファンクションについての情報も必要なので、より詳細なユーザ要求が必要となる。 ユーザは、顧客データに対して、追加、更新、削除、及び照会、そして、計算データを含む４種類のレポートを要求している。 ユーザは、製品データに対して、追加、更新、削除、及び照会、そして、計算データを含む１つのレポートを要求している。 ユーザは、供給者データに対して、供給者番号での照会機能と集計結果の帳票出力を要求している。 これら、より詳細なユーザ要求仕様には、実際のトランザクション・ファンクションの総数が示されていて、FP概算法が可能になる。.   データ／トランザクション  ファンクションファンクション  タイプ 複雑度 ＦＰ値 (未調整値) Low 7 5  　  顧客データの追加 EI Average 4 顧客データの更新 顧客データの削除 顧客データの照会 EQ 顧客レポート１ EO 顧客レポート２ 顧客レポート３ 顧客レポート４  　  製品データの追加 製品データの更新 製品データの削除 製品データの照会 製品関連のレポート  　  供給者番号照会 供給者関連のレポート  　   FP概算値 　 IFPUG法 IFPUG法を行うには、ファンクションタイプ (ILF, EIF, EI, EO, EQ) 毎の数だけでなく、個々の機能について複雑度 (Low,Average,High) も決める必要がある。 FPA法では、データファンクションとトランザクションファンクションの複雑度は、その機能に関連するDET,RET,FTRに基づいて決まる。このため、ユーザ要求（この事例のFP概算法の説明で記述しているが）をより詳細に分析する必要がある。つまり、どのDETとFTRがトランザクションファンクション (EI,EO,EQ) で使われているか、どのようなRETとDETでデータファンクション (ILF,EIF) が構成されているか、である。 このようにユーザ要求の詳細な分析をすると、その結果、例えば以下のようにFP値が求められる。   データ／トランザクション  ファンクション ファンクション ＦＰ値  (未調整値) 10 High 6 3  　   FP値 　 結論 この特殊な事例では、三つのカウント方法が、85FPで同じ機能規模となった。計測結果は、通常同じとはならないが、かなり近い値となる。この報告の最後に、FP概算法とFP試算法の精緻な検証結果を載せる。 概略の説明へ戻る 正式のFPカウント方式は、もちろん概算法や試算法に比べ、より正確である。しかし、より多くの時間と、より詳細な仕様を必要とする。 どのカウント方式を使うかは、プロジェクトマネージャの判断と、システムのライフサイクルのフェーズに依存している。 多くのアプリケーションに適用した結果、FP試算法は、驚くほど良い見積もり結果を示している。データモデルは、ほとんど労力を掛けずに作成または入手できるため、多くの場合FP試算法で算出する事は比較的容易である。 概略の説明へ戻る およそ１００の開発済みのアプリケーションのデータを使用し、NESMAではFP概算法及びFP試算法の精度について調査を行った。 提供されたアプリケーションについて、３通りのカウント方法で同時に測定した。その結果を下記の２つのグラフに示す。 FP概算値(縦軸)と正式なFP測定値(横軸)の相関    FP試算値(縦軸)と正式なFP測定値(横軸)の相関 どちらのケースも、良い相関（直線的な）を示している。しかしながら、試算法のグラフにおいては、いくつかのケースで、かなりの差異（50％に到るずれ）が見られる。これが、FP試算法を使用する際の注意点である。このカウント方法の強みは、非常に短い時間で、アプリケーションのラフな規模見積りができることである。  出力の数が平均に比べ多い（または少ない）場合には、35や15という係数を変更することが必要になるだろう。しかし、この方式の考え方は、一般的に使用できるものである。 FP概算法での見積結果と、正式な計測結果とは非常に近い値となっている SPR法　 昨今、プロジェクト管理に対する意識の向上と共に、プロジェクト管理ツール（以下、PMツール）を導入＆活用する企業／組織／プロジェクトが増えてきています。 しかし、PMツールを導入するだけでは実際には十分な効果を上げることはできません。プロジェクト管理を成功させるためには、信頼性の高いプロジェクト計画を策定できるかどうかが前提条件となります。 高精度で信頼できる計画を策定するためには、ベースとなる経験的データが必要となります。しかしながら、経験的データとして精度の高い実績データを蓄積している組織は決して多くなく、大多数の組織はタスクの漏れや、サービス残業などの工数が集計されていないため、一般的に30％、多い時には70％もの工数が未集計となる傾向があるようです。このような経験的データを元に計画を策定しますと、当然のことですが過小見積りの計画となってしまい、プロジェクトの途中で要員追加の必要性が生じたり、納期に間に合わなくなってしまうといった問題が発生してしまいます。 KnowledgePLAN は、開発元である米国SPR社のコンサルタントによって世界中から集められた豊富なプロジェクト実績-”知識ベース”-と、ソフトウェアの開発における様々な要因（人的、技術的、プロセス的等々）の状況や変化が、対象となるプロジェクトの生産性や品質にどう影響するかをコントロールする”見積りアルゴリズム”により、あらゆるソフトウェア開発に対して高精度な見積り（プロジェクト計画の策定）を実現できるツールです。 この強力な知識ベースと見積りアルゴリズムにより、世界標準的な工数・工期・成果物量・欠陥数を見積ることができます。特に未経験のソフトウェアタイプの開発や、はじめてのプラットフォームでの開発など、予測の難しい開発に対しても、KnowledgePLANの持つ経験を活かして、客観性の高い計画の策定ができます。 KnowledgePLANが扱う、プロジェクトサイズの規模尺度には、FPA（ファンクションポイント法）とコード行数の2種類が指定できるようになっております。FPAにおいては、世界的に高い支持を得ているIFPUG法のほか、SPR簡易法、システム系ソフトウェアの開発に対応したフィーチャーポイント法を選択できます。コード行数においては、言語毎の生産性情報がツール内に豊富に保持されておりますので、殆どの言語が指定できます。 知識ベース内の全実績データは、規模をファンクションポイント値で捉えており（コード行数からの逆算法によるファンクションポイント値も含む）、これから計画策定しようとするプロジェクトの規模尺度に、ファンクションポイントで指定することが、KnowledgePLANの効果を最大限に引き出す有効な手段となります。 規模は、プロジェクトの進行状況によって、その規模の信憑性や正確性が変化しますが、KnowledgePLANでは3種類の規模設定方法を用意しておりますので、プロジェクトライフサイクルの中で使い分けることにより、段階的に見積り精度を高めていくことができます。 プロジェクト計画の策定においてもっとも重要なことは、 ・プロジェクトに要するすべての作業項目が明確になっていること ・個々の作業項目の正確な工数、成果物量、品質データを収集＆蓄積できること と言っても過言ではありません。 KnowledgPLANでは、作業項目（タスクカテゴリ）が約150種類に分類されておりますので（追加も可能）、項目の見落としを減らしたり、その実績収集も容易にできるよう構築されております。 KnowledgePLAN を使ってプロジェクトの実績データを豊富に蓄積しましたら、オリジナル知識ベースを構築されることをお勧めします。一番信頼できる経験的知識は、世界標準の知識ベースでも日本標準の知識ベースでもありません。自社標準こそが一番価値のある知識ベースなのです。 知識ベースのカスタマイズ機能はオプション（別途、費用が必要）となっております。このオプションは本体のご購入時以外にも、ご必要になったときに、あとから追加することもできます。 KnowledgePLANをご利用になられる対象者としては、以下のような方または部門を想定しております。

8.3 コストの予算化 コストの予算化 インプット ツールと技法 アウトプット １．コスト見積り 2. ワーク・ブレークダウン 8.3　コストの予算化 コストの予算化 インプット １．コスト見積り 2. ワーク・ブレークダウン 　　・ストラクチャー（WBS） 3．プロジェクト・スケジュール ４．リスク・マネジメント 　　計画書 ツールと技法 １．コストを予算化する 　　ツールと技法 アウトプット １．コスト・ベースライン

コストの見積りと予算の配賦の方法 実績ベースの見積り 分析ベースの見積り 統計的総和による見積り 予算の配賦

8.4 コスト・コントロール コスト・コントロール インプット ツールと技法 アウトプット １．コスト・ベースライン ２．実績報告書 8.4　コスト・コントロール コスト・コントロール インプット １．コスト・ベースライン ２．実績報告書 3．変更要求 ４．コスト・マネジメント 　　計画書 ツールと技法 １．コスト変更管理システム ２．実績測定 ３．アーンド・バリュー 　　・マネジメント（EVM） ４．追加の計画 ５．コンピューター・ツール アウトプット １．コスト見積り改訂版 ２．予算更新版 ３．是正処置 ４．完成時総コスト見積り ５．プロジェクト終結 ６．教訓

8.5 システム開発における考慮点 資源計画では、契約書、プロジェクト計画書、WBSに基づいて明確にする項目. 8.5　システム開発における考慮点 資源計画では、契約書、プロジェクト計画書、WBSに基づいて明確にする項目. コスト見積りでは、プロジェクト予算として含める項目. コストの予算化では、システム開発における予算を、通常は３種類で算定する。 コスト・コントロールはアーンド・バリュー・マネジメント（EVM）を使用して行う。

8.5.1 システム開発における考慮点① ① 所要スキルと所要人数 ② 設備 8.5.1　システム開発における考慮点① 資源計画では、契約書、プロジェクト計画書、WBSに基づいて明確にする項目. ①　所要スキルと所要人数 ②　設備 ③　購入ソフトウェア、開発ツール、検査ツールなどのソフトウェア、及び購入データや購入する知的財産権 ④　サービス ⑤　プロジェクト作業場所、備品、消耗品

8.5.2 システム開発における考慮点② ① 労務費（クラス別単価を使用） ② 調達費（請負外注費） ③ 設備費（ハードウェア機器） 8.5.2　システム開発における考慮点② コスト見積りでは、プロジェクト予算として以下の項目を含める。 ①　労務費（クラス別単価を使用） ②　調達費（請負外注費） ③　設備費（ハードウェア機器） ④　ソフトウェア費（購入ソフト・開発ツール・検査ツール等） ⑤　サービス費（保守費、教育費、セットアップ費） ⑥　経費（フロア費、用力費、設備・消耗品など）

8.5.3 システム開発における考慮点③ ① プロジェクト見積り原価 （システム開発のための希望単価をベースに算定） 8.5.3　システム開発における考慮点③ コストの予算化では、システム開発における予算を、通常は以下の３種類で算定する。 ①　プロジェクト見積り原価 　　　（システム開発のための希望単価をベースに算定） ②　プロジェクト受注金額 　　　（受注競争のために出した戦略的金額であり、適正マージンを含む） ③　プロジェクト予定原価 　　　（リスクや値引き交渉などの原価削減努力を考慮した原価であり、 　　　ベースラインとする）

8.5.4 システム開発における考慮点④ ① 作業の出来高は成果物ベースで評価する。 ② 費用は期間に運動した費用のみ抽出する。 8.5.4　システム開発における考慮点④ コスト・コントロールはアーンド・バリュー・マネジメント（EVM）を使用して 　　次のように行う。 ①　作業の出来高は成果物ベースで評価する。 ②　費用は期間に運動した費用のみ抽出する。 ③　作業に要した費用は実績作業期間と作業者の単金を掛け合わせて 　　　算出する。 ④　出来高グラフで表示する。 ⑤　予実対比でプロジェクト完了時のコストを予測 ⑥　コストが超過しそうであれば是正処置を考える。

復習とまとめ ケーススタディ

ＰＭの枠組み プロジェクト マネジメントの 主要要件 1. プロジェクト 統合マネジメント 2. プロジェクト 範囲のマネジメント 3. プロジェクト 時間マネジメント 4. プロジェクト コストマネジメント 5. プロジェクト クオリティ マネジメント 6. プロジェクト 人材マネジメント 7. プロジェクト コミュニケーション 8. プロジェクト リスクマネジメント 計画 実施 コントロール 完了 立ち上げ 完了管理 開始 範囲の計画 範囲の定義 活動の定義 活動の一連性 活動期間の見積 スケジュール開発 リスクマネジ メント計画 リソース計画 コスト見積 コスト予算策定 開発計画 クオリティ計画 組織計画 メンバーの確保 実行計画 全体の変更管理 範囲の変更管理 スケジュール 変更管理 コスト変更管理 成果報告 リスクの モニタリングと リスクの明確化 リスクアセスメント リスク量の算出 リスク対応計画 コアプロセス 促進プロセス 範囲の確定 クオリティ保証 チーム開発 情報提供

2000年度版 契約の完了 ﾌﾟﾛｼﾞｪｸﾄの完了手続き 終結のプロセス 遂行のプロセス コントロールのプロセス 立上げのプロセス ﾌﾟﾛｼﾞｪｸﾄの立上げ ｽｺｰﾌﾟ変更管理 ｽｹｼﾞｭｰﾙ管理 ｺｽﾄ管理 品質管理 ﾘｽｸ管理 進捗管理 変更管理 補助的プロセス 情報の配布 ﾌﾟﾛｼﾞｪｸﾄﾁｰﾑの育成 品質保証 引合 発注先選定 契約管理 ﾌﾟﾛｼﾞｪｸﾄ計画の実施 ｽｺｰﾌﾟ計画 ｽｺｰﾌﾟ定義 作業定義 資源計画 作業順序設定 所要期間見積り ｺｽﾄ積算 ｽｹｼﾞｭｰﾙ作成 予算設定 ﾌﾟﾛｼﾞｪｸﾄ計画策定 計画のプロセス コアプロセス 成果物の検収 品質計画 ｺﾐｭﾆｹｰｼｮﾝ計画 ﾌﾟﾛｼﾞｪｸﾄ組織計画 要員の調達 ﾘｽｸの特定 ﾘｽｸの定量化 対応策の策定 調達計画 引合計画 出典：「ＰＭＢＯＫ」をもとに作成 2000年度版 リスク管理計画 ﾘｽｸの定性分析 ｽｺｰﾌﾟの照合

ＷＢＳ(Work Breakdown Structure)の作成 スコープ定義書はプロジェクトのＷＢＳを作成すること。 スコープの定義と責任分担 ＷＢＳ(Work Breakdown Structure)の作成 スコープ定義書はプロジェクトのＷＢＳを作成すること。 作業１ 作業２ 作業３ 作業４ 作業５ 作業６ 作業７ 組織１ 組織３ 組織２ 組織７ 組織６ 組織５ 組織４ ＣＡ ＷＰ ＷＢＳ－ＯＢＳマトリックス WBS OBS ＷＰ：Work　Package ＣＡ：Cost　Account

RAM：responsibility assignment matrix : 責任分担表 S:承認、A:審査、P:支援 担当 Ａ Ｂ Ｃ Ｄ Ｅ F 要件定義 Ｓ Ｐ 外部設計 内部設計 コード作成 テスト 総合テスト アクティヴィティ

ネットワークロジック図（スケジュール作成） PDM法 開始 仕事Ａ 仕事Ｂ 終了 仕事Ｇ 仕事Ｆ 仕事Ｅ 仕事Ｄ 仕事Ｃ ＰＤＭ　：　Ｐｒｅｃｅｄｅｎｃｅ　Ｄｉａｇｒａｍｍｉｎｇ　Ｍｅｔｈｏｄ 仕事Ｃ 仕事Ｂ 開始 終了 仕事A 仕事Ｅ 仕事Ｄ 仕事G ADM法 ＡＤＭ　：　Ａｒｒｏｗ　Ｄｉａｇｒａｍｍｉｎｇ　Ｍｅｔｈｏｄ 仕事F

ガントチャートとPERT ガントチャート PERT 期 間 仕 事 Ａ Ｂ Ｃ Ｄ 高 最可能値（m） PERT加重平均＝期待値 長 短 高 低 所要期間予測 楽観値（a） 悲観値（b） 最可能値（m） PERT加重平均＝期待値 ＝(a＋4×m＋b)／6 ベータ分布 期　　間 仕　事 Ａ Ｂ Ｃ Ｄ ガントチャート PERT

コストの予算化 Ａ 楽観値 Ｂ 最可能値 Ｃ 悲観値 期待値 Σ 標準偏差 Σ二乗 要件定義 ５０ ７０ １００ ７１．６７ ８．３３ ６９．４４ 外部設計 ４０ ５１．６７ ５ ２５．００ 内部設計 １２０ １５０ １２１．６７ コード作成 １７０ ２００ １７１．６７ テスト ６０ ８０ ６１．８ ２５ 総合テスト ３．３３ １１．１１ 全体 ４３０

予算の配賦方法 ＭＲ Project Budget プロジェクト予算 割り当てされた予算 ＵＢ コストアカウント部分 未確定部分 実績測定ベースラインＰＭＢ(performance measurement baseline) ＭＲ Project Budget プロジェクト予算 割り当てされた予算 ＵＢ コストアカウント部分 未確定部分 ＷＰに割り当て ＰＰ 直接 ＡＥ 間接 ＭＲ：management reserve UB:undistributed budget PP:planning package AE:apportioned effort WP:work package PMB:performance measurement baseline 計画中のパッケージ ＰＭに与えられた予備費 部門間接 今割り当てられない予算

作 業 内 容 リスト ①プロダクツと明確な目標を設定する ②プロダクツを管理可能なところまで分解する ③作業の相互関係を考える 作　業　内　容　リスト ①プロダクツと明確な目標を設定する ②プロダクツを管理可能なところまで分解する ③作業の相互関係を考える ④作業の所要期間を見積もる ⑤スケジュールを作成する ⑥コストを積算する ⑦予算のベースラインを設定する ⑧進捗を管理する

＜プロジェクトのメンバーとその顧客は、良く話し合い両者の合意を得る＞ ①プロダクツと明確な目標を設定する ・プロジェクトが成功裡に完成したかどうか判断できる定量的な基準を示す。 ・定量的でない目標の設定（「顧客満足」など）は大きなリスクを伴う。 主要なプロダクツ プロジェクト 成果物・サービス コスト プロジェクトの 定量的な達成目標 品質 スケジュール ＜プロジェクトのメンバーとその顧客は、良く話し合い両者の合意を得る＞ ＜合意事項を文書化する＞

プロダクツを管理可能なところまで分解する手法 ＜ＷＢＳ(Work Breakdown Structure）＞ ②プロダクツを管理可能なところまで分解する プロダクツを管理可能なところまで分解する手法 ＜ＷＢＳ(Work Breakdown Structure）＞ レベル１ プロダクツ レベル２ レベル３

どこまで分解するの？ ＷＢＳの目的は、プロダクツを 管理可能なコンポーネントに分けること 管理可能なコンポーネントとは、 ②プロダクツを管理可能なところまで分解する ＷＢＳの目的は、プロダクツを 管理可能なコンポーネントに分けること 管理可能なコンポーネントとは、 ①コスト、作業所要期間、資源所要量の正確な見積りが可能であること ②当該作業の責任と権限を明確化できること である すなわち、ＰＭは、プロダクツをＷＢＳを用いて ①コスト、作業所要期間、資源所要量の正確な見積りが可能なところ ②当該作業の責任と権限を明確化できるところ まで分解する必要がある。 レベル１ プロダクツ レベル２ レベル３ 出典：「ＰＭＢＯＫ」をもとに作成

ＷＢＳ作成の留意点 ＜MECEに分ける＞ MECEとは、 Mutually ＝要素が互いに ②プロダクツを管理可能なところまで分解する ＷＢＳ作成の留意点 ＜MECEに分ける＞ MECEとは、 Mutually ＝要素が互いに Exclusive ＝重複がなく（原意：排除しあっていて） Collectively ＝集めると Exhaustive ＝全体を尽くす

＜ケーススタディ＞ ＜４人分の事務所＞を新設する。 期限は３ヶ月。予算は200万円以内。 第１レベル 第２レベル ②プロダクツを管理可能なところまで分解する ＜ケーススタディ＞ ＜４人分の事務所＞を新設する。 期限は３ヶ月。予算は200万円以内。 基礎 外装 内装 許可取り付け 工事計画 基礎・土台 屋根ふき 壁枠・屋根枠 外壁 塗装 仕上げ 電気器具 床総仕上げ 清掃 冷暖房 絶縁 タイル ドア 第１レベル 第２レベル 電気配線 窓

＜練習問題１＞ あなたが最近手がけたプロジェクト、あるいは現在予定しているプロジェクトの中から、主要なプロダクツを取り出し、それをもとにＷＢＳを作成してください。 分割はレベル２まで。 時間10分（ひとりの方に５分程度で発表してもらいます）

③作業の相互関係を考える 工事 計画 壁枠・ 屋根枠 電気 配線 冷暖房 絶縁 器具 床総 仕上 ﾌﾟﾛｼﾞｪｸﾄ 開始 許可 取付 基礎 土台 屋根 ふき タイル ドア 塗装 清掃 終了 外装 内装 外壁 窓

あなたが作ったＷＢＳをもとに、作業間の相互関係を設定してください。 ③作業の相互関係を考える ＜練習問題２＞ あなたが作ったＷＢＳをもとに、作業間の相互関係を設定してください。 時間10分（ひとりの方に５分程度で発表してもらいます）

④ 作業の所要期間を見積もる ＜数学モデルで所要期間を見積もる＞ 期待値±σ×１に収まる確率 68.26％ ④　作業の所要期間を見積もる ＜数学モデルで所要期間を見積もる＞ Ｔｏ－最も楽観的な作業期間の予測値（Optimistic） Ｔｍ－最も起こりそうな作業期間の予測値（Most likely） Ｔｐ－最も悲観的な作業期間の予測値（pessimistic） Ｔｅ（作業期間の期待値）＝ 6 Ｔｏ＋４Ｔｍ＋Ｔｐ σ(作業期間の標準偏差）＝ Ｔｐ－Ｔｏ 期待値±σ×１に収まる確率　68.26％ 期待値±σ×２に収まる確率　95.46％ 期待値±σ×３に収まる確率　99.73％

④作業の所要期間を見積もる 相対的な発生確率 短い 長い Ｔｍ（最も起こりそうなケース） Ｔｐ（悲観的ケース） 期待値＝（Ｔｏ＋4Ｔｍ＋Ｔｐ）/６ 出現する期間値 高い 低い Ｔｏ（楽観的ケース） 出典：「PMBOK」より抜粋

④作業の所要期間を見積もる

あなたが作ったＷＢＳをもとに、作業の所要時間を見積もってください。 ④作業の所要期間を見積もる ＜練習問題３＞ あなたが作ったＷＢＳをもとに、作業の所要時間を見積もってください。 時間10分（ひとりの方に５分程度で発表してもらいます）

＜これまでやったこと、今からやることの確認＞ ｽｺｰﾌﾟ計画 ｽｺｰﾌﾟ定義 作業定義 資源計画 作業順序設定 所要期間見積り コスト積算 ｽｹｼﾞｭｰﾙ作成 予算設定 ﾌﾟﾛｼﾞｪｸﾄ計画策定 ①プロダクツと明確な目標を設定する ②プロダクツを管理可能なところまで分解する ③作業の相互関係を考える ④作業の所要期間を見積もる ⑤スケジュールを作成する ⑥コストを積算する ⑦予算のベースラインを設定する ⑧進捗を管理する 進捗管理 ＋

クリティカルパスとは、フロートが０以下になっている作業チェーン ⑤スケジュールを作成する ＜クリティカルパスを見つける＞ 作業名 作業 期間 （ＥＳ：最早開始日） （ＥＦ：最早終了日） （ＬＳ：最遅開始日） （ＬＦ：最遅終了日） ＜フロートとは＞ （最遅終了日）－（最早終了日） （最遅開始日）－（最早開始日） クリティカルパスとは、フロートが０以下になっている作業チェーン フロート＞０　→　その作業のスケジュールは動かす余裕がある。 フロート＝０　→　その作業のスケジュールはクリティカルである。 フロート＜０　→　計画しなおさないとその作業はできない。 ※クリティカルパス＝緊急経路 ※フロート＝余裕

＜ＥＳ、ＥＦを見つける＞ Ａ Ｂ Ｄ Ｃ Ｅｘ．１ ⑤スケジュールを作成する 作業名 ４ ３ ５ １ ④ ⑤ ７ ９ ⑩ １３ 計算方向 期間 ＥＳ （最早開始日） ＥＦ （最早終了日） ＬＳ （最遅開始日） ＬＦ （最遅終了日） Ａ ４ １ ④ Ｂ ３ ⑤ ７ Ｃ ５ ９ Ｅｘ．１ 計算方向 Ｄ ⑩ １３

＜ＬＳ、ＬＦを見つける＞ Ａ Ｂ Ｄ Ｃ Ｅｘ．２ ⑤スケジュールを作成する 作業名 ３ ４ ５ ７ ９ １０ １３ ⑨ ⑩ １ ④ 期間 ＥＳ （最早開始日） ＥＦ （最早終了日） ＬＳ （最遅開始日） ＬＦ （最遅終了日） Ｂ ５ ７ Ｃ ９ Ｄ ４ １０ １３ Ｅｘ．２ 計算方向 ３ ⑨ ⑩ Ａ １ ④

⑤スケジュールを作成する ＜クリティカルパス＞ Ａ Ｂ Ｃ Ｄ ５ ３ ＬＳ ７ ＬＦ ９ １０ １３ １ ４ ＥＳ ＥＦ

ケーススタディのクリティカルパスを見つけてください。 時間10分（ひとりの方に５分程度で発表してもらいます） ＜練習問題４＞ ケーススタディのクリティカルパスを見つけてください。 時間10分（ひとりの方に５分程度で発表してもらいます） ⑤スケジュールを作成する 工事 計画 15 許可 取付 16 電気 配線 10 冷暖房 5 タイル 塗装 3 基礎 土台 壁枠・ 屋根枠 屋根 ふき 絶縁 ドア 器具 2 床総 仕上 窓 1 外壁 清掃

⑥コストを積算する （単位：千円）

⑥コストを積算する 相対的な発生確率 低い 高い Ｔｍ（最も起こりそうなケース） Ｔｐ（悲観的ケース） 期待値＝（Ｔｏ＋4Ｔｍ＋Ｔｐ）/６ 出現する金額 Ｔｏ（楽観的ケース） 出典：「PMBOK」をもとに作成

⑦予算のベースラインの設定 コスト（千円）

⑧　進捗を管理する ＜プロジェクトの目標＞ 期限は３ヶ月。予算は200万円以内。 コスト（千円）

ＥＶＭＳ （Earned Value Management System） ＰＶ　ベースライン ＡＣ　　実コスト EV　アーンドバリュー ＢＡＣ 完了予算コスト ＶＡＣ：完成時での差異 ＳＶ：スケジュール差異　期間表示 ＳＶ：スケジュール差異　コスト表示 ＣＶ：コスト差異 EV 予測のプロジェクトの時間遅れ 現時点 計画完了時点 ＰＶ ベースライン ＥＶ ＡＣ コスト 時間 ＥＡＣ 完了予測コスト

EVMS：Ｅｒｎｅｄ Ｖａｌｕｅ Management System ・BCWS　Budgeted Cost of Work Scheduled ＝＞ＰＶ 計画された作業に対する予算化されたコストのこと。一般にＳ字カーブを描く。 　　計画された価値　PV　Planed　Value　という。　これが　進捗測定用　ベースラインとなる。 ・BCWＰ　Budgeted Cost of Work Performed ＝＞ＥＶ 指定された段階で完了した作業に対する計画上の予算化されたコストのこと。完了したＷＰの予算化されたコストの累積で計算する。　　　獲得ＥV　Earned　Value　という。 ・ＡCWＰ　Actual Cost of Work Performed　＝＞ＡＣ　指定された段階で完了した作業に対する実際に費やされたコストのこと。間接費も含まれる。 　　　実コスト　ＡＣ　Actual　Cost　という。 ・CV　Cost　Variance　　　　　　　ＣＶ＝ＥＶ－ＡＣ　実際に処理した作業にかかったコストの計画値からの差異 ・SV　Schedule　Variance　　　　ＳＶ＝ＥＶ－ＰＶ　実際に処理した作業の計画からの遅れまたは進みの絶対値 ・EAC　Estimate　At　Completion　EAC＝AC＋（BAC－ＥＶ）／ＰＦ　　完成時予測総コスト 　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　PF　Performance　Factor（CPI　or　SPI　or　CPI×SPI） ・VAC　 Variance　At　Completion　　VAC＝ＥＡＣ－ＢＡＣ　完成時予測総コストと計画時総コストの差異 ・CPI　Cost　Performance　Index　　　CPI＝ＥＶ／AC　実施した作業の計画のコストの実質コストに対する比率の指標 ・SPI　 Scheduled 　Performance　Index　SPI＝ＥＶ／ＰＶ　実施した作業の計画のコストの計画コストに対する比率の指標 ・TCPI　To　Complete　Performance　Index　（BAC－ＥＶ）／（EAC－AC）　現時点以降のＣＰＩを表す。 　　アーンド・バリュー・マネジメント アーンド・バリュー・マネジメントとは、予算および予定の観点からプロジェクトがどのように遂行されつつあるかを定量的に評価するプロジェクト管理の技法である。1967年に米国防総省の調達規則の一部として制定された C/SCSC(Cost/Schedule Control System Criteria)が元となっている。1990年代、クリントン大統領政権下における国家的プロジェクトのパフォーマンス改善を通じて見直され、発展してきた。プロジェクトマネジメント知識体系ガイド (PMBOK) の2000年版では、コスト・マネジメントの技法として言及されて (7.4.2.3) いる。進捗の進み/遅れのような指標（スケジュール差異）も日数/時間という単位ではなくコストを単位として求められる点に特色がある。 日本においても、経済産業省が実証プロジェクトを通じてアーンド・バリュー・マネジメントのガイドラインを策定しているなどの動きがあり、政府の調達案件では今後アーンド・バリュー・マネジメントの技法による管理を行うことを受注の条件とすることも検討されていると言われている。 アーンド・バリュー・マネジメントでは、ある時点までにプロジェクト・チームが完成した成果とプロジェクト開始時に予測した見積りとが比較される。この比較から、プロジェクトが完了状態からどれほど離れているかについての標準が与えられる。既にプロジェクトに投入された作業量から推定することによって、プロジェクト・マネジャーは完了時点までにどれほどのリソースが使用されるかの見積もりを得ることができる。 この技法はクリティカル・パスの概念に基づいている。プロジェクトのパフォーマンスを測定し管理する手法には、他にクリティカル・チェーン法がある。クリティカル・チェーン法では、代わりにバッファ管理を採用している。その理由は、アーンド・バリュー・マネジメントではプロジェクトの制約条件(即ちプロジェクトのクリティカル・チェーン)とプロジェクトの非制約条件(即ちプロジェクト・ネットワーク中のクリティカル・チェーン以外のパス)が明確に区別されないためである。この性質は、時によるとより良いアーンド・バリュー評価を追求しようとするプロジェクト・マネジャーに、クリティカルな作業を犠牲にして非クリティカルな作業の遂行を促進させうるものであり、その結果プロジェクトの完了は遅れてしまう。これは、部分的な評価は全体的な評価に従属するという意識が不足した結果として、局所的な最適化を行ってしまうという問題である。 アーンド・バリュー・マネジメントをプロジェクトに適用しようとするプロジェクト・ マネジャーには以下に挙げる基本情報が必要である。 ワーク・ブレークダウン・ストラクチャー(WBS, Work Breakdown Structure) 階層化され詳細化された、全てのプロジェクト構成要素のリスト プロジェクトのマスター・スケジュール(PMS, Project Master Schedule) 各タスクの納期と担当者が示されたガントチャート 計画価値(PV, Planned Value) 当該期間末までに完了しているものとして計画された作業の予算 アーンド・バリュー(EV, Earned Value) 当該期間末までに進捗した作業を、その作業の計画価値に対する比から評価した価値 実コスト(AC, Actual Cost) 当該期間末までに実際に投入した総コスト 完成時総予算 (BAC, Budget at Completion) プロジェクトの完了時点におけるPV プロジェクト・マネジャーは、これらの情報を基に次のような評価値を算定することができる。 コスト差異(CV, Cost Variance) EV - AC（0以上であれば良好） スケジュール差異(SV, Schedule Variance) EV - PV （0以上であれば良好） コスト効率指数 (CPI, Cost Performance Index) EV÷AC（1以上であれば良好） スケジュール効率指数 (SPI, Schedule Performance Index) EV÷PV（1以上であれば良好） 完成時総コスト見積り(EAC, Estimate At Completion) AC + (BAC - EV)÷CPI

EVMS：Ｅｒｎｅｄ Ｖａｌｕｅ Management System ＥＶＭＳによる進捗管理手法 　１．ＣＶ、ＳＶが１０％の閾値を越えると異常と言う判断を下す。 　２．ＣＰＩ、ＳＰＩが０．９を下回る場合を異常と判断する。 　　　異常を発見一時は、何らかの対応策をとる。 　　　また、ＣＶ、ＳＶ、ＣＰＩ、ＳＰＩが7回連続して悪化の傾向を示したら、 　　　そのプロジェクトまたはＷＰを重点管理する。 　☆　ＶＡＣ＜ＣＶ　最終結果が現在地よりもよくなるという報告が上がったらおかしいと判断できる。 　☆　ＴＣＰＩ＞ＣＰＩ　現時点以降のＣＰＩが過去のＣＰＩより改善される報告が上がったらおかしい。 　☆　算出したＥＡＣ＞＞報告された完成時総コスト　 　　　完成時総コストがＥＡＣよりも大幅に改善された報告書はおかしい。 　★　変更管理　ＣＣＢ　Change　Control　Board　の判断を仰ぐ 　　　EVMSの基盤となるベースラインはスコープ（マネジメントまたは成果物）の変更が 　　　行われたときのみ変更となる。つまり予算の見直し。 　　・プロジェクト全体の変更管理　スコープ、スケジュール、コスト、品質、契約・・・の変更管理 EVMS：Ｅｒｎｅｄ　Ｖａｌｕｅ　Management　System 　

＜ＥＶＭＳ（アーンドバリュー分析＞ ＢＡＣ（Total budget） ＰＶ（ＢＣＷＳ） ＥＶ（ＢＣＷＰ） ＳＶ （ＰＶ－ＥＶ） ＣＰＩ ⑧進捗を管理する ＜ＥＶＭＳ（アーンドバリュー分析＞ （アーンドバリューとは、出来高のこと） ＢＡＣ（Total budget） ＰＶ（ＢＣＷＳ） ＜計画予算コスト＞その時点までにどれだけの仕事が終わっていなければならないか ＥＶ（ＢＣＷＰ） ＜出来高＞実際にはどれだけの仕事が終わっているのか ＜実際発生コスト＞終わった仕事にいくら費用がかかったのか ＜コスト差異＞ ＣＶ＝正：予算以内　　ＣＶ＝負：予算超過 ＳＶ （ＰＶ－ＥＶ） ＜スケジュール差異＞ ＳＶ＝正：計画より早い　　ＳＶ＝負：計画より遅れ ＣＰＩ （ＥＶ/ＡＣ） ＜コスト効率指標＞ＣＰＩ＞1：コストが計画より少ない　　ＣＰＩ＜1：コストが計画より多い ＳＰＩ （ＥＶ/ＰＶ） ＜スケジュール効率指標＞ＳＰＩ＞1：作業が計画より早い　　ＳＰＩ＜1：作業が計画より遅い ＜完成時総予算＞ ＜完成時総コスト見積り＞ ＶＡＣ （ＢＡＣ－ＥＡＣ） 完成時での差異 ＡＣ（ＡＣＷＰ） ＣＶ （ＰＶ－ＡＣ） ＥＡＣ コスト（円） 日 現在 納期 ＡＣ ＣＶ ＢＡＣ ＥＡＣ ＶＡＣ ＰＶ ＥＶ ＳＶ

＜ＰＭの手法を用いて仕事の効率化を図る＞ ＜戦略計画の策定＞ ・戦略的中期経営計画策定 ・地域活性化ビジョン策定　など １．現状把握 　　-作業① 　　-作業② 　　-作業③ ２．課題設定 ３．対策の検討 -作業① ４．計画書作成 作業① １．現状 作業② ③-１ 作業③ ③-２ ２．課題 戦略策定 ③-３ ３．対策 ４．計画書

現在の仕事にどう活かせるか 作業順序の設定 ｽｹｼﾞｭｰﾙの作成 ＷＢＳ 所要期間の見積り 予算ﾍﾞｰｽﾗｲﾝと進捗管理 コスト積算 ③-２ ③-１ ④-１ ｽｹｼﾞｭｰﾙの作成 ③-３ ③-１ ③-２ ③-３ ④-１ ５ ３ ４ ＷＢＳ 現状 課題 戦略策定 作業② 作業③ 作業① ③-２ ③-３ ③-１ 対策 計画書 所要期間の見積り 予算ﾍﾞｰｽﾗｲﾝと進捗管理 ③-１ コスト（円） 日 現在 納期 ＡＣＷＰ ＣＶ ＢＡＣ ＥＡＣ ＶＡＣ ＢＣＷＳ ＢＣＷＰ ＳＶ ③-２ ③-３ ④-１ ④-２ コスト積算 ③-１ ③-２ ③-３ ④-１ ④-２

１．現状把握 ２．課題設定 ３．対策の検討 ４．計画書作成 Ｗｈｙ？ Ｓｏ Ｈｏｗ？ ＜原因追求＞ ＜解決策の具体化＞ どの部分を？ 現在の仕事にどう活かせるか １．現状把握 　　-作業① 　　-作業② 　　-作業③ ２．課題設定 ３．対策の検討 -作業① ４．計画書作成 問題 Ｗｈｙ？ Ｓｏ　Ｈｏｗ？ 重点 課題 ・問題の根本原因を把握し、それに対する重点課題を設定する。 ・その上で、重点課題を具体的なアクションが行えるところまで分解する。 ＜原因追求＞ ＜解決策の具体化＞ どの部分を？ 具体的にどのようにして？ ・問題の根本原因の解決を効率的、効果的に行うことが可能となる。 ・結果、お客様の満足度の向上が期待できる。 その効果は？