今回も引き続きパフォーマンス情報の絡み合いについて解説する。前回は絡み合いの全貌を俯瞰する按配で述べたが、今回はもう少し掘り下げて、個々のプロジェクトマネジメントフレーム（以下本稿ではＰＭフレームと略記する）の統合のロジックと、それらがWBS／WPとどのように関わるかを紹介する。ここに登場するフレームはＦＢＳ，ＷＢＳ，ＲＢＳとＣＢＳ、ＯＢＳ、及びスケジュールとアクティビティー注１である。
注１：スケジュールはコード体系とは異質のものであり、アクティビティーもまた作業項目を羅列したもので体系ではないが、プロジェクトパフォーマンスを云々する際には作業項目と時間情報は不可欠であるのでここでの考察に加えた。
念のため以下にコード体系の内容を簡単に説明する.

【ＦＢＳ】Function Breakdown Structure：ものごとを行うためにはそれを実行する機能が必要である。裏返せばプロジェクト遂行は“まずそれに必要な機能(Function)を確保し、これを（メンバーの誰かが）実行すること”とも言える。
【ＯＢＳ】Organization Breakdown Structure：一般的には担当者を責任・権限の大きさに従って階層的に表わしたものであるが、プロジェクトマネジメントで用いる場合はマネジメント機能との関連（どの職位の者がどのマネジメント機能を司るか）を明確にしておくことが大切である。
【ＲＢＳ】Resource Breakdown Structure、【ＣＢＳ】Cost Breakdown Structure：コストや遂行資源を割り当て、消費量や額をモニターするための資源或いはコスト費目体系である。
【ＷＢＳ】Work Breakdown Structure：一般的には作業を階層的に体系化したものであるが、プロジェクトマネジメントで用いる場合はWork Element(WE)、Work Package(WP)の概念を伴う。

　【ＰＭフレームの絡み合い：ＦＢＳ〜アクティビティー〜ＷＢＳ／ＷＰ】

　では仕事を行うための機能がプロジェクトのパフォーマンスにどのように繋がるかというところから始めよう。
　何等かの”仕事（Work）をする”ことはそれを達成するために必要な“機能を働かす”ことである。この理屈はプロジェクトのような大きな仕事であっても同様で、それを果たすのに必要な機能の種類と処理する量が、身近の手間仕事に比べて格段に多くなるだけの違いである。日常のルーティン化した仕事では上記の視点は既にマニュアル化されているので不要であるが、開発性が高い、未経験の度合いが大きい場合は原点に戻って機能設計から始めることがより大切となる。

　図７−１のフローに従ってマネジメントフレームの相互関係を説明する。
�@左端は事業に必要なＦＢＳである。　�Aこれらの機能うちプロジェクトの作業遂行に必要な機能が細かくは各Activityに、場合によっては大括りでＷＰ等に採用される。（図の中央）。�B採用された機能はＷＥ或いはＷＰの「作業範囲・作業項目」として集約される（上図右端）。

図７−１　FBS〜Activity〜WE/WPの関係

【ＰＭフレームの絡み合い：ＲＢＳ／ＣＢＳ〜アクティビティー〜ＷＢＳ／ＷＰ】

　資源コード、アクティビティー、作業量及びＷＢＳの関係を図７−２を用いて説明する。
�@プロジェクトは会社の事業管理の下で運営される。即ちプロジェクト遂行には経営資源を使う。経営資源は事業の費目管理コード（ここでは資源費目コードが関わる）の枠組みの中で管理される。�Aプロジェクトの作業遂行に必要な資源量は資源費目コード体系の下で積算され、Activity に割り付けられる。�Bこの割り付けられたデータはＷＰに集計され、�CＷＢＳの構造を通して集計される。
　　　　

　　

図７−２ 資源〜Activity〜WBS/WE/WPの関係　　　　　　図７−３　コスト〜Activity〜WBS/WE/WPの関係

　プロジェクトのコストマネジメントの対象は大部分は資源調達費（人工費や機材購入費）である。上述のアクティビティー毎の作業量積算で得た資源所要量を基に、資源調達予定単価を歩掛けして資源コスト（人件費、機材費等）の予定額が確定する。コストには他に一般経費などもあるが、これらは多くの場合ＷＥやＷＰに割り付ける。

　資源情報と同様にコストコードからＷＢＳまでの関係を図７−３を用いて説明する。�@経営資源のうち本項ではコスト費目コードが対象となる。�Aプロジェクトの作業遂行に必要な費用はコスト費目コード体系の下で積算され、Activity に割り付けられる。�Bこの割り付けられたデータはＷＰに集計され（上図中央左寄から右への流れ）、�CＷＢＳの構造を通して集計される（上図左端の階層構造でマネジメントに必要は塊に集計）。

【ＰＭフレームの絡み合い：スケジュール処理された時間情報〜ＷＥ／ＷＰ】

　作業スケジュールで処理された時間情報がどのようにしてＷＰやＷＥの時間情報に繋がるかを図７−４で説明する。
�@アクティビティーでは割り付けられた機能を使って作業することを先のＦＢＳとアクティビティーの絡み合いの項で説明した。�Aここでアクティビティー遂行に必要な時間データが得られる。一旦アクティビティーの時間情報が得られれば、後はＷＢＳの構造に従って、�BＷＰに含むアクティビティーの時間を纏めてＷＰの時間情報を、�C更に複数のＷＰの時間情報を纏めてＷＥに・・・という具合に集計することで各管理単位の時間情報が得られる。

図７−４ FBS〜作業ｽｹｼﾞｭｰﾙ〜WE/WPの関係

(注) Activity上では資源量は図７−２で取り敢えずは一義的に決まるが、そのままではプロジェクトの全体期間で不都合（資源手配が出来なくてプロジェクト全体納期遅れなど）が起こる。この問題に対処するのがＷＰでの実行計画段階での山積／山崩などのＱＤＣＳのトレードオフ及びスケジュールのシュミレーションである。ここでは同じＷＰに含まれる複数のActivity間はもちろんのこと、親となるＷＥに含まれる仲間のＷＰとの間でも同様のトレードオフが為される。

【ＰＭフレームの絡み合い：見積値〜出来高勘定〜Activity〜ＷＰ／ＷＥ〜パフォーマンス情報】

　プロジェクトのパフォーマンス情報でＫｅｙとなるＥＶ：Earned Value（出来高）を得るための情報フローを説明する。出来高を定量的に捉えるためには、その元となる数値データが必要である。これにはプロジェクトの作業見積で得るデータを利用する。このデータは四つの目的に使われる。具体的には（�T）その作業項目の達成に要する資源量の見積りに、（�U）その作業項目の達成に要する期間の見積りに、（�V）必要コストの積算に、そして（�W）作業の進捗状態を定量的に捉えるために使用する。これらの用途の詳細説明は別稿に譲るとして、ここでは�Wの使い方が本項の目的である。

　作業見積データを得て成果情報を得るまでの情報フローを図７−５で説明する。まず�@積算して得たデータは次の通り使う。�A資源予算管理のため（図７−５のＡの線）および�B作業の原価値として（図７−５のＢの線）。この２種類の使い方は一般に行われる原価管理とさほど違いはない。プロジェクトの成果コントロールで用いられる場合は�C監視対象毎に進捗を想定し、これに�DＷＰ毎→�EＷＥ毎に集計すること、及びこの値をプロジェクトの進捗に応じて定期的に累積記録することである。

図７−５　出来高勘定〜WE/WPの関係