■PMBOK ドリルダウン！_No.21
　　PM定量化の実践技術（５）

前回は、ファンクションポイントを、ＰＭの活動でどう活用するのか、品質メトリックスの活用について筆者の実践経験を基に話しをしました。
最近、究極の進捗管理としてＥＶＭ（アーンドバリューマネジメント）が良く取り上げられます。この議論は、別途行なうこととして、今回は、ファンクションポイントを、進捗管理でどう活用するかについて実践経験をお話します。
では教室の戸を開けましょう。

まず、こんな素朴な問題（スケジュールの遅れはどうして起きるのか？）について考えてみましょう。
プロジェクトの症状としては、マイルストーンや成果物の完成時期が、計画または約束の日時から著しく遅れることを言います。
　 その重症度合いは、計画からの乖離が、５０％以上（最悪）、２５％以上（悪い）、１０％以上（やや悪い）、１０％未満（そこそこ）と言った状況ではないでしょうか。
　 プロジェクトが進むにつれてこの問題に悩まされることになり、かつ乖離が発生すると重態になりがちです。要件定義段階での乖離はまれですが、設計、コーディング、文書作成と工程を経るに従い、そしてとくにシステム統合、テスト、欠陥除去に至って乖離幅は大きくなる傾向があります。
　 何故、この問題に悩まされるのでしょうか？主な原因は、４つ考えられます。

1. 作成時点ですでに達成不可能なスケジュールであった。
2. スケジュールを作成後、マイルストーンで達成すべき作業範囲や成果物が増大した。
3. スケジューリング、見積作成、計画作成の方法論が不適切であった。
4. 当該企業が、過去のプロジェクトの有用なデータを収集していなかった。

それでは、これらの原因に対する予防法は、あるのでしょうか？
　 この問題に悩まされる場合でも、その損害を最小にするための対策は、以下のとおりありそうです。

1. プロジェクトの見積り時に、見積り過去実績、市販されている見積りツール・ＤＢを活用する
2. プロジェクトの計画時に、市販されている計画作成ツール（ＭＳ−ＰＲＯＪＥＣＴ等）を使用する
3. 要求仕様が増大する場合には、その増加量を機能的尺度（ファンクションポイント）によって定量的に把握する
4. 詳細な作業まで含めた、ソフトウェア開発のデータ測定を企業文化として定着させる

今回の説明で、筆者が提案したいのは、３の要求仕様の増大をその増加量を機能的尺度（ファンクションポイント（ＦＰ））によって定量的に捉え、そのＦＰを進捗管理で活用する方法です。

プロジェクトで管理する進捗管理表は、次の２種類を作成します。

• 毎週管理：工程別（詳細設計・ＰＧ設計・ＰＧＭ・システムテスト）進捗管理表
• 毎月管理：総合進捗管理表

サブシステム毎に、システム全体に占める“重み付け”を求め、更に重み付けを工程別に按分し、サブシステム毎の週単位の工程別進捗＊按分値を積み上げて、工程別進捗管理表を作成します。
　 また、上記工程別進捗管理表の値を積み上げ、月末時システム全体の進捗管理を行なうため、総合進捗管理表を作成します。
　 サブシステム毎の“重み付け”の計算式は以下のとおりです。

重み付け＝開発規模（ＦＰ）／全体の開発規模（ＦＰ）＊１００＋追加（調整）ウェイト

　 注：追加（調整）ウェイトは、単純に開発規模で作業量を按分することが出来ないため（難易度により作業量が異なるため）、サブシステム間で作業量を調整する値です。 工程別按分値（基本設計〜システムテスト）までの全作業量に占める各工程の割合は、以下の通りとしました。
　
　　詳細設計按分値 ＝重み付け＊１８％
　　ＰＧ設計按分値　＝重み付け＊２０％
　　ＰＧＭ按分値　　 ＝重み付け＊４１％
　　システムテスト按分値 ＝重み付け＊２１％

• サブシステム毎の規模（ＦＰ）で求めます。
• サブシステム毎の単純重み付けを求めます。
  単純重み付け＝サブシステム毎の開発規模／全体の開発規模＊１００
  
• 必要に応じ、追加（調整）ウェイトを設定し、最終的な重み付けを決定します。
  重み付け＝単純重み付け±追加（調整）ウェイト
• サブシステム別重み付けを工程別に按分します。
  ここまでのシートイメージは下図の通りです。

工程別・サブシステム別の進捗を求め、週単位に工程別の進捗管理表、グラフを作成します。

総合グラフは、下図のイメージです。