プロジェクトの「お金」の管理、難しく考えすぎていませんか?
プロジェクトマネジメントを学ぶ中で、PMBOKを開いてみたものの、「アーンド・バリュー分析(EVA)」や「残余作業効率指数(TCPI)」といった見慣れない専門用語が並び、そっと本を閉じたくなった経験はありませんか?
「自分の担当している現場では、こんな複雑な計算はしていないけれど、プロジェクトマネージャーとして失格なのだろうか……」と不安に思う方もいるかもしれません。
でも、安心してください。PMBOKに書かれている理論は非常に重要で網羅的ですが、プロジェクトの性質や立場によって、どこに重点を置くべきかは大きく変わります。
今回は、PMBOK第8版における「財務の監視・コントロール(Monitor and Control Finances)」の基本を押さえつつ、とくに日本のIT業界に多い「請負開発」の現場において、プロジェクトマネージャーが本当に意識すべきお金の管理について、私の実体験を交えながら紐解いていきます[1]Project Management Institute, Inc., The Standard for Project Management and A Guide to the Project Management Body of Knowledge (PMBOK® Guide) – Eighth Edition, **第2部 … Continue reading。
PMBOK第8版における「財務の監視・コントロール」の概要
まずは、PMBOK第8版で定義されている「財務の監視・コントロール」の基本を確認しておきましょう。
このプロセスは一言で言えば、「プロジェクトの支出を継続的に追跡し、予算内に収まるように管理し、必要に応じて軌道修正を行うこと」です。プロジェクトの開始から終了(クローズ)まで、全体を通じて継続的に実行されます。
プロセスの目的と主な利点
最大の目的は、プロジェクト全体を通じてコスト・ベースライン(計画時のコスト基準線)を維持することです。
コストの実績を監視することで、計画からのズレ(差異)をいち早く察知し、リソースの再配分や是正措置といった「プロアクティブ(先見的)な意思決定」が可能になります。
主なインプット・ツール・アウトプット(ITTO)
PMBOKでは、この管理を行うための具体的な要素が定義されています。
- 主なインプット(前提となる情報):
プロジェクトマネジメント計画書(コスト・ベースラインなど)、作業パフォーマンスデータ(実際に発生した支出や実コスト)など。 - 主なツールと技術(管理の手法):
- アーンド・バリュー分析(EVA): コストとスケジュールの実績を総合的に測定・評価する手法。
- 残余作業効率指数(TCPI): 残りの予算内で目標を達成するために、今後どれくらいの効率で作業しなければならないかを算出する指標。
- 予備分析: リスクに備えた予備費がまだ十分に残っているかを評価します。
- 主なアウトプット(結果として出るもの):
作業パフォーマンス情報(予算との差異分析結果)、完了時コスト予測(EAC)、変更要求(予算の調整申請)など。
このように、コストの逸脱を検出し、是正措置(Corrective Actions)を実施してプロジェクトの財務的な健全性を保つことが、標準的な理論とされています。
自社開発と請負開発で異なる「財務管理」の実情

さて、ここまでPMBOKの概要を見てきましたが、IT業界で請負開発(受託開発)に携わっている方の中には、「なんだか自社の実情と少し違うな」と違和感を覚えた方もいるのではないでしょうか。
実は私自身も、PMBOKの「財務管理」に関する記述を読むと、「自社で独自のサービスやプロダクトを開発していく事業会社」を強く念頭に置いているように感じます。予想収益や期待されるコスト削減効果までをプロジェクトのスコープに含めているため、用語が非常に高度になっているのです。
では、請負開発の現場における実情はどうでしょうか。
例えば、「社内システムがほしいA社(発注者)」と、「その開発を受託したB社(受注者)」がいるとします。
- A社(発注者)の視点:
B社から提示された見積り金額で契約し、その通りにシステムが納品されれば、基本的にお金(追加費用)の心配はありません。 - B社(受注者)の視点:
契約した金額(売上)が決まっている中で、開発にかかるコスト(主にエンジニアの人件費・工数)が超過して「赤字」にならないよう、厳しく管理する必要があります。
つまり、請負開発の現場において「財務の監視・コントロール」を実際に汗をかいて行っているのは、主に受託側のプロジェクトマネージャーなのです。
現場で役立つ活用シーン:受託側PMが本当に守るべきライン
請負開発のプロジェクトマネージャーになった場合、PMBOKに登場するような高度な財務用語をすべて使いこなす必要はありません。
受託側がすべき財務管理の本質は、非常にシンプルです。それは、「当初の予定(見積もり)」と「実際の作業(実績)」を見比べ、コスト超過にならないかをチェックすることです。
IT開発におけるコストの大半は「人件費(作業工数)」です。
「この機能の開発には2人で1ヶ月(2人月)かかる」と見積もって受注したのなら、実際にその期間・人数で終わるのかを監視し続けます。もし「予想以上に仕様が複雑で、あと0.5人月追加しないと終わらない」となれば、それはプロジェクトの利益を削る「コスト超過(差異)」を意味します。
このズレにいち早く気づき、チーム内で作業を効率化したり、発注者と仕様の調整を行ったりして赤字を防ぐことこそが、受託現場での最大の活用シーンです。
財務の監視における注意点とリスク
シンプルなチェックで良いとはいえ、気をつけるべきリスクはあります。それは、「コスト超過の兆候を放置してしまうこと」です。
「少し遅れている(工数が多くかかっている)けれど、後半で巻き返せるだろう」という根拠のない楽観視は、プロジェクトにおいて非常に危険です。後半になればなるほど、取れるリカバリー策(是正措置)の選択肢は狭まっていきます。
また、発注者からの「ちょっとした仕様変更や追加のお願い」を、予算の調整(追加費用の請求など)を行わずに安請け合いしてしまうことも、受託側のコストを圧迫する大きな要因になります。計画からの変更が発生した際は、PMBOKでも定義されている「変更要求」のプロセスをしっかり踏むことが重要です。
実践ステップ:今日からできるシンプルなコスト管理
難しく考えすぎず、明日からすぐに始められる財務管理のステップをご紹介します。
- 見積もり時の根拠(ベースライン)を手元に置く:
「どの機能に、誰が、どれくらいの時間をかける予定だったか」がわかる資料を確認します。 - 定期的に「実績」を記録する:
週に1回などの頻度で、チームメンバーが実際に使った時間を集計します。 - 「予定」と「実績」を引き算する:
(予定工数)−(これまでに使った工数)=(残りの工数)。この「残りの工数」で、本当にこれからの作業を終わらせることができるかを考えます。 - 足りない場合はすぐに行動する:
残りの工数では終わらない(赤字になる)とわかったら、すぐに上司に相談する、メンバーをサポートする、発注者と要件を再調整するなどの「是正措置」に動きます。
専門的なツール(PMIS)がなくても、表計算ソフト一つで十分に立派な「財務の監視・コントロール」が実践できます。
まとめ:予算管理はプロジェクトを守るための盾
PMBOK第8版の「財務の監視・コントロール」は、一見すると難解な用語が多いですが、その本質は「計画と実績のズレを早期に発見し、プロジェクトの健全性を守ること」に他なりません。
とくに請負開発においては、「当初の予定」と「実際の作業」を定期的に見比べるという基本アクションを徹底するだけで、プロジェクトの炎上や赤字を大きく防ぐことができます。難しく考えすぎず、まずは手元の工数管理から始めてみてください。あなたのその地道な管理が、チームとプロジェクトを守る最強の盾になります。
注
| ↑1 | Project Management Institute, Inc., The Standard for Project Management and A Guide to the Project Management Body of Knowledge (PMBOK® Guide) – Eighth Edition, **第2部 セクション2.4.2.4(64-65頁)および第4部「Inputs and Outputs」(733-734頁)**より要約・翻訳。以下、PMBOK第8版(英語版)と略記。 |
|---|

