HOME > PMウェブ・サービス > PM課外授業 > PMBOK ドリルダウン-PM定量化の実践技術(9)、リスクマネジメント(25)
■PMBOK ドリルダウン！_No.25
PM定量化の実践技術（９）
2005.05.25
今日は、ＷＢＳを用いた「進捗管理」について考察してみたいと思います。
【定量的数値による管理の必要性】
検討作業等の定量的な定量的な作業もその結果をとりまとめたものを生産物として、検討項目数等で進捗管理を行なう等、本来は定性的作業についても定量的数値で進捗管理を行なう必要があります。
例え、詳細作業計画を生産物の単位で定量的に計画することが困難であったとしても、進捗状況を曖昧な「％」で収集することはできるだけ避けるべきだと思います。
（筆者の経験では、１日〜５日以内で完了できる大きさまでＷＢＳを分割し、達成率は、［０−１００％］を活用するのが、適切であると考えます。）
【実績データの集約・蓄積】
【ＷＢＳとコントロールのレベル】
ＷＢＳとコントロールレベル（例）
| レベル | 名称 | 内容 |
| １ | プロジェクト名 | プロジェクト機能名称 |
| ２ | サマリー | 管理フェーズによる主要作業区分（マネジメントレベル） |
| ３ | ワークグループ | ワークパッケージを集約した区分 |
| ４ | ワークパッケージ | ワークレベルでの計画・管理 とくに原価集約単位として有効な最少作業の管理単位（ワークレベル） |
| ５ | アクティビティ／タスク | ワーク・パッケージを構成する個々の作業 この作業の時間、原価の集約がワークパッケージ |
【役割と責任】
更に、管理階層の工程作業計画上の役割を定めます。
計画責任者の主な役割（例）
| 担当 | 構成員 | 主な役割 |
| プロジェクト計画責任者 | ＰＭ | プロジェクト全体の全工程にわたる以下の項目の計画を行なう 。 ・ 経費 ・ ＷＢＳ第２レベルの作業方針 工程作業計画書の承認を行なう |
| 工程作業計画責任者 | ＰＬ | 自ユニット（組織）内作業の当該工程における以下の項目の計画を行なう。 ・ ＷＢＳ第３レベルの作業定義と詳細工程の見積り ・ ＷＢＳ第２レベルスケジュール |
| タスク計画責任者 | チームリーダー | 自チーム内作業の当該工程における以下の項目の計画を行なう。 ・ タスクへの分割（ＷＢＳ第４レベル以下への分割） ・ タスクの作業量と日単位スケジュール ・ タスクの作業担当者 |
体制と役割の設定ができたら、いよいよプロジェクト計画書を基に、ＷＢＳを分割して、作業計画書を展開していきます。具体的な作業の進め方は、次回説明します。
リスクマネジメント (25)
前回は、定量的リスク分析の技法として、デシジョン・ツリー分析をご紹介しました。
本日は、リスク・シミュレーションツールを活用した、定量的リスク分析をご紹介します。
【KnowledgePLANを活用したリスクシミュレーション】
＜例＞
ある金融系商品システムの機能拡張作業を行ないます。開発言語は、ＣＯＢＯＬで、追加・変更・削除・移行機能の規模は、１００ＦＰ（約１０，０００ステップ）です。
この案件については、制約条件があります。それは、納期（３ケ月以内）、コスト（８００万円）です。品質については、特に、顧客から目標が示されていません。但し、リリース後いつも品質の問題で、顧客と問題を起すことが多いので、この案件を始める前に、納品時点で、顧客にどの位の不具合も納品されることになるのかシミュレーションをしておく必要があります。
さて、皆さんが、この案件のリーダーの立場でしたら、社内の見積りデータ、見積りモデルを活用して、潜在不具合、納品不具合、不具合除去率を予測することができますか？
このKnowledgePLANを活用する場合、以下の情報を事前に与える必要があります。
１．規模に関する情報（ＦＰ、あるいは、ステップ、ｅｔｃ）
２．プロジェクト属性（スコープの確定状況、要員スキル、開発環境、ｅｔｃ）
品質（Ｑ）、コスト（Ｃ）、納期（Ｄ）は、バランスの問題ですから、上記の例では、ＣＤに制約を持たせると、品質上の問題が発生することになります。
KnowledgePLANでは、１０，０００件以上の過去情報を基に、今回の案件に近い情報を導き出し、情報を提供してくれます。
上記の例では、以下のような計測情報が算出されます。
| 潜在不具合 | 除去される不具合 | 納入される不具合 | 不具合除去率 |
| １８６ | ８６ | １００ | ４６％ |
この数字を上司に提示すると、当然、納入される不具合が多すぎる！！ 何とかしろ！！ということで、制約条件の見直しが可能か？ あるいは、制約条件はそのままで、品質向上策（レビュー強化、プロトタイプ実施、顧客関与を強める…）が実現できるかの検討を始めることになります。
ここでは、このツールの良し悪しを議論するのではなく、シミュレーションツールを活用する場合には、以下の点について留意する必要があることをお伝えします。
シミュレーションは、モデルを使ってある現象が起きる結果を模擬的に生成する方法です。
利点は、
・ １つ１つ手で実施するよりも効率的に解を得られます。
・ 複雑なモデルでも想定結果が得られます。
欠点は、
・ 使うモデルの良し悪しが結果の精度を左右します。
・ どんなプロジェクトでも同一モデルが使える訳ではありません。
・ モデルが複雑だった場合、原因（入力）と結果（出力）の関係を見つけにくい場合があります。
筆者は、KnowledgePLANをリスクシミュレーションの有効なツールと判断して活用しています。但し、以下の点のついて留意する必要があります。
１．KnowledgePＬＡＮが使いこなせるには、一定の時間と、ノウハウが必要となります。
２．KnowledgePＬＡＮが持っている見積知識ＤＢだけに頼るのではなく、自社の見積りデータを蓄積し、次回の見積り時に再見積もり時に再利用するメカニズムを構築することが、より精度を向上させる上で不可欠になると思います。
本日はここまでにします。お疲れさまでした。