第10回コストマネジメント(コストコントロール体系)

前回はプロジェクトの予算制度にかかわる問題を中心にコストマネジメントについて説明したが、今回はプロジェクトマネジメントにおいて、プロジェクトのコストをどのような観点でコントロールしていくのかをコストコントロール体系をもとに説明する。このコントロール体系を理解することによってプロジェクトのコストは、本来のどのような視点でコントロールすべきなのかがお分かりいただけるだろう。

プロジェクトマネジメントのコストコントロール体系の基本形は米国国防総省(DOD: Department of Defense)や米国エネルギー省(DOE: Department of Energy)で定義されている。どちらもプロジェクトのオーナーとしてプロジェクト予算を管理する立場にあるが、ここで定義されたコントロール体系はプロジェクトの持つ不確実性や曖昧性を充分考慮した、現実的なコストコントロール体系となっていることがよくわかる。

下図に米国エネルギー省で定義されたコストコントロール体系を示すが、このコストコロール体系の各項目の内容を説明しながら、プロジェクトコストマネジメントのあり方を考えてみよう。

img_15.png

図からかわるように、(1)プロジェクトコストは(2)-a契約金額と(2)-c非契約予算の2種類に大きく分かれる。非契約部分にはプロジェクトにかかわる活動費である旅費・交通費、人件費、間接費など企業からみると交渉の対象とならない、必要経費的な内部発生コストが含まれる。国内企業においては、これら非契約予算のなかで外に出て行くお金である旅費・交通費などに焦点があたり、固定費的な人件費や間接費などはプロジェクト予算として定義せず、コントロールの対象にもなっていない企業も多いが、本来はプロジェクトに関わる企業活動のあらゆる費用はプロジェクトに計上すべきであり、それこそが正しくプロジェクトの姿を映し出す方法でもある。このDOEのコスト構造においても、直接部門、間接部門関係なくプロジェクトに関わるすべての社内人件費と間接費がプロジェクト予算として計上されることになる。みなさんが興味がある項目は(2)-bのコンティンジェンシーではないだろうか。

コンティンジェンシー

コンティンジェンシーの考え方は、プロジェクトの持つ不確実性、リスクから出てくるもので、リスク対応に備えた予算である。欧米式のプロジェクトへの合理的な考え方がここに良く現れている。日本企業において、多くの業界のプロジェクトを見てきたが、エンジニアリング業界や先進的なIT業界以外でコンティンジェンシーの発想を持ってプロジェクト運営している企業は皆無に等しい。コンティンジェンシーを持っていないがゆえにプロジェクトマネジャーは予算を変えないようにリスクを回避しようとし、結果として品質への手抜きが発生しているケースをよく見かける。品質への手抜きは、後で手痛いしっぺ返しとして帰ってくる。プロジェクトで発生した品質問題の対応に、企業はコンティンジェシー費用の何十倍、何百倍もの費用を払うだけでなく、さらには自らの社会的信用さえも傷つけブランドイメージを損なうのである。

コンティンジェンシー予算の組み方を見ただけも、日本と欧米のリスクに対する感度の違いがよくわかる。日本の風土やビジネス環境にも大きく依存しているのだと思うが、日本のビジネス環境ではリスクはどうも「何とかなるもの」的な発想が強く、リスクに対しての充分な対応や準備を行わずに実施することが非常に多い。コンティンジェンシーは欧米先進国では普通の考え方となっており、コンティンジェシーを持たずにプロジェクトを進めるケースは逆に珍しい。そのコンティンジェンシーの金額はプロジェクトの潜在リスクの度合いによって大きく異なってくるが、プロジェクトの総額を見積もった後、そのコストにある%を掛けて上乗せするかたちで計上するのが一般的である。また、コンティンジェンシー予算の執行権に対しては、プロジェクトマネジャーの判断で実施される場合もあるが、コンティンジェンシーのなかを2つくらいにわけ、たとえばプロジェクトマネジャーには50%までは自己裁量で使う権限を与えるが、残りの50%に対しては組織マネジメントの意思決定に委ねるようにしているケースも存在する。

コンティンジェンシーの予算を導入している企業はおおむねリスクマネジメントの仕組みがある程度整備されている企業であり、逆にコンティンジェシーの予算が導入されていない企業はリスクマネジメントに対しての対応が弱い企業と見てもよいであろう。

マネジメントリザーブ

次に(2)-a契約金額は、(3)-b契約予算と(3)-a利益に分かれることになる。利益は受注企業の利益そのものであるが、なぜ利益など出てくるのか不思議に思うかもしれないが、欧米ではTime & Material, Cost & Fee などといった受注側の費用を明らかにして、利益分も予算として計上し、プロジェクトの進行に合わせて受注側が実績費用と利益分を発注側に要求し、清算する方式が存在するためである。 この場合は、発注側が利益保証を行ってプロジェクトをすすめるので、受注側はコストについてはかなり詳細に明らかにする責任を持ち、場合によっては発注側の監査を受けるケースもある。また、(3)-a利益については、業界の相場を考慮し交渉の過程で決まってくるが、利益分はコストに対するパーセンテージの数字が契約で取り決められ、その契約において決められた利益率が担保されることとなる。

しかし、日本においては、契約形態のほとんどは一括請負契約(ランプサム契約)であり、受注者は請け負った金額ですべてをやり遂げ、リスクも受注者側が負う契約形態が多い(近年はプロジェクト一括の契約では受注者のリスクが大きすぎるので、プロジェクトをいくつかのステージに分割し、ステージごとの一括契約を行うケースが増えてきている)ので、このように契約予算と利益を分ける必要はないであろう。

次に契約予算は(4)-aベースライン予算と(4)-bマネジメントリザーブに分けられる。 ベースライン予算とはプロジェクトが守るべき目標予算である。では、マネジメントリザーブとは一体どういった予算なのかを少しお話しする。これは、受注者がプロジェクトをコントロールするために用意された予備的予算であり、予見できない状況に備えて蓄えている予算である。このコスト体系においては、プロジェクトの遂行者である受注者の判断で使える予算であり、プロジェクトの目標であるスケジュールやコストが達成できないという、マネジメント上のリスクに対応して使用する予算である。たとえば、スケジュールが全体的に遅れがちでこのまま行けば納期が間に合わないと判断されたとき、残りの作業のスケジュールを短縮して納期を守らせるような何らかの対応を迫られる。システム開発プロジェクトでは要員を増強したり、建設プロジェクトでは建設機器を増やしたり、スケジュールを加速するための対策を取ることになる。この場合は、人員の増強や設備の増強などはプロジェクトの条件としては想定していないものであり、ベースライン予算には当然組み込まれていないが、費用としては追加で発生せざるを得ない予算となる。

マネジメントリザーブは、一般的にはプロジェクトマネジャーだけでなく、組織レベルの意思決定を受けて執行されるが、その場合はコストはベースラインに組み込まれ、予算としてコントロールすべき対象となってくる。

コントロールアカウント

ベースライン予算は二つの項目に分けて管理されることになる。(5)-aコントロールアカウント(Control Account)と(5)-b非配分予算(Undistributed Budget)であるが、まず非配分予算について少し説明する。非配分予算の概念をプロジェクト単位で利用している日本の企業は稀であろう。だが、この概念を理解することは予算をコントロールするという意味では重要なことであり、知っておいて損はないと思う。非配分予算の適用はどちらかというと、長期的なプロジェクトにおいて合理性を持つ。プロジェクトが1、2年程度あればプロジェクトの全体像をある程度掴むことは可能であり、プロジェクトを実行するために予算を持って運営すればそれで問題はない。しかし、プロジェクトが数年以上の期間を持った場合はどうであろうか。プロジェクトは投資活動であり、プロジェクトに対してのコストを知る必要があるが、たとえば5年先の作業の内容を詳細に見積もることに何の意味があるだろうか。見積もりは出来るにしても、すべてが仮定であり、プロジェクトが進むにつれ実体が明らかになり、実施すべき内容は仮定とは大きく違ってくることは容易に想像がつく。

そのような場合、予算を細かくすることはほとんど意味がなく、投資的採算的な観点からの予算枠が重要な意味を持ってくる。予算枠は事業収益性に直結し、プロジェクトの存在意義にも関係するため、ある程度の精度で抑える必要があるからである。非配分予算とは、プロジェクトのスコープとして扱う予算ではあるが、ワークパッケージとして細かく見積もられ予算化されていない概算予算を意味する。

では、次のコントロールアカウントについて説明する。コントロールアカウントまたはコストアカウント(Cost Account)と呼ばれるもので、プロジェクトのWBS(Work Breakdown Structure)のなかでも示されるものであり、コストコントロールを行うための基本単位である。 通常、コントロールアカウントにおいスケジュールとコストが統合されマネジメントできるようにデータモデルが作られ、コンロールアカウントには、スコープ情報、コスト情報、スケジュール情報、進捗情報、実績のコスト情報などが集まってくるようになり、時間軸でコストと業務進捗をコントロールできるようになる。業界によってその大きさは異なってくるが、ソフトプロジェクトでは1億円~10億円程度、ハードプロジェクトでは5億~50億と幅を持つことになる。大きすぎると十分な管理が行き届かないし、あまり細かくしても管理工数が増えすぎその割にはコントロールする金額も少ないため成果も出しにくいので、コントロールアカウントの大きさはプロジェクトのコストをマネジメントするにおいても非常に重要なポイントである。

ワークパッケージ

コントロールアカウントの内容は実際にマネジメントを行うためにいくつかコントロールしやすい単位に細分化される。細分化は、プロジェクト成果物や成果物グループごと、あるいは特定の目的を達成するための作業群に対して行われ、その細分化された1つの単位をワークパッケージと呼ぶ。ワークパッケージはプロジェクトのWBSにおいての最小単位でもあり、プロジェクトスコープを明確にする基本単位でもある。コントロールアカウントの目的がプロジェクトのスコープ、コスト、スケジュールを統合し、パフォーマンスを測定しながらマネジメントを行う基本単位に対して、ワークパッケージは実施すべき成果物や作業群の進捗をマネジメントする単位となる。ワークパッケージを特定することによって達成すべきスコープや内容が明らかとなり、実現のために必要とするコストやリソースを見積もり、責任者を決め実現のためのスケジュールを作ることで、より現実的な計画が可能となり、コントロールもやりやすくなる。つまり、コントロールアカウントにおいては、ワークパッケージは予算・スケジュール・進捗を管理する基本単位であり、各ワークパッケージの状況を見極めながらコントロールアカウントにおけるコストマネジメントを遂行することになる。

ワークパッケージへの細分化とその計画を策定することによって、コントロールアカウントの目的達成の可能性は格段に向上することになるが、さらにワークパッケージは具体的な活動単位まで落とし込まれ、アクティビティとして計画され担当者や実施組織などのリソースが割り当てられコントロールされるようになる。このように、コントロールアカウントは、成果物の基本構成単位となるワークパッケージ、実作業の基本単位となるアクティビティと分解し、それらを計画・コントロールすることによって与えられた予算やスケジュールの達成をより確実にしていく。また、コントロールアカウントにおいて、成果物や作業内容は明らかであるが具体的なアクティビティまで明らかになっていないものが存在する。このようなパッケージをプラニングパッケージと呼び、実施すべき内容と予算は立てておくが、アクティビティレベルまでは展開せずに、パッケージレベルまでで認識し、プロジェクト全体の計画として組み入れておく。ただ、プラニングパッケージは出来るだけ早くアクティビティレベルまで細分化し、実務レベルまで落としこむことが望ましい。

以上、コストコントロールの体系を説明したが、自社でのコストコントロール体系との違いは明らかになったであろうか?