プロジェクト・コスト管理 (1)

作成日：2021/08/16

プロジェクト・コスト管理 (1)

プロジェクトはQCD、すなわち Quality (品質)、Cost (コスト)、Delivery (納期) が主要な管理項目と言われます。
今回から2回に分けて、このうちプロジェクトのコスト管理について実践的に解説します。
主にソフトウエア開発の プロジェクト・マネジャー (PM) を対象読者として書いています。
プロジェクト・コスト管理の方法論については PMI (Project Management Institute) の PMBOK®ガイド (A Guide to the Project Management Body of Knowledge) 第6版のプロジェクト・コスト・マネジメントの知識体系が参考になります。
しかしこのコラムでは知識だけではなく主にソフトウエア受託開発を想定した実践的な内容を紹介します。

今年2021年3月に発行された PMBOK®ガイド 第7版 は、756ページあった第6版に対して250ページと大幅に削減されており (いずれも英語版ペーパーバックでの比較)、ITTO (インプット・ツールと技法・アウトプット) による方法論の記載はなくなりました。
今後、ITTO は PMBOK®ガイド からは外だしでPMIからデジタルコンテンツとして提供される予定とのことです。
そのため本コラムでは PMBOK®ガイド 第6版 をベースに解説します。

PMBOK®ガイド と偶然時を同じくして、2021年4月より大企業には収益認識基準が適応されました。
しかし受託開発プロジェクトに関しては、基本的に従来の完成基準、あるいは、工事進行基準での収益認識になります。
収益という言葉は利益を連想しますが、売り上げのことです。
PMは自身のプロジェクトが完成基準（検収によって売り上げが上がる）なのか、工事進行基準（進捗（しんちょく）に応じて売り上げが上がる）なのかを把握する必要があります。
不明であれば上司または経理に確認してください。
工事進行基準の場合は、EVM (Earned Value Method) による正確な進捗管理が必要になります。
今回はコスト見積もりと予算設定、次回はEVMによるコスト・コントロールを中心に解説します。

ソフトウエア開発の見積もり

建築プロジェクトであれば総床面積でおおむね建築物の規模がわかります。
規模がわかれば費用もわかります。ソフトウエアの場合は規模を表すのが難しいので見積もりも難しくなります。
ソースコードの行数は単体テスト以降の工数と相関関係があります。
しかし同じ仕様なら一般的には優秀なアーキテクトと優秀なプログラマーが作った方がコードは短くなりますから規模指標にはなりません。
ファンクション・ポイントは特定の種類のソフトウエア (データベース中心でコードはデータベースへの追加・読み取り・更新・削除を行うアプリ) に対しては規模を表すことができます。
ソフトウエアの種類は銀行の勘定系からCRMまで多岐にわたるので規模を表す汎用 (はんよう) 的な指標はありませんが、概算見積もりの目安として仕様に対する代替指標を使うのが良いでしょう。
画面数と入力フィールドやボタンなど画面要素数、データベースへのCRUD (作成・読み取り・更新・削除) 数、IO数、コマンド数とコマンドの複雑度などです。

見積もりで最も役に立つのは過去のプロジェクトの記録です。
過去のプロジェクトの WBS、設計・実装・テストなどフェーズごとの工数比率、WBSタスクごとの初期予定工数と実績工数、WBSに漏れて後で追加したタスク、ソースコード行数、バグの収束曲線など、過去実績はPMにとっての宝です。
これらでおおよその規模は見積もれますが、コスト見積もりはWBSから導き出す必要があります。

WBSの粒度

WBS (Work Breakdown Structure) とはプロジェクトの作業をすべて階層的にブレークダウンしたものです。
WBSの粒度が大きすぎると正確に進捗を把握できません。
細かすぎるとオーバーヘッドが増してプロジェクト効率が低下します。
WBS階層の末端要素はアクティビティまたはタスクと呼び、必ず成果物があります。
例えばあるモジュールの実装タスクの場合、ソースコードと単体テスト結果がその成果物になります。
ソフトウエアのアーキテクチャが未定の段階では、どのようなモジュールが必要かはわかりません。
その段階では仕様規模とフェーズ比率から推定した概算見積もりは可能ですが、実装コストの詳細見積もりはできません。
WBSとコスト見積もりは段階的に詳細化されていくものです。

以上は PMBOK® の一般知識ですが、ここからは筆者の経験による具体的かつ実践的内容になります。
1つのアクティビティは予想工数を20時間程度にすべきです。
1時間では細かすぎますし、80時間では荒すぎます。
最大でも40時間まで分割すべきです。
特に注意していただきたいのは、コスト見積もりとコスト管理には人月という単位を使わないことです。
人日もだめです。
時間を使います。
PMは時間で進捗の実績を把握します。
各アクティビティの予定工数はその作業担当者自身に見積もらせてください。
担当者も自分の作業を時間で見積もり、時間で工数の実績を記録することに慣れるべきです。
これが正確なコスト見積もりと進捗把握のポイントのひとつ目です。
時間で管理する理由は、プロジェクトにアサインされたメンバーの工数がまるまるプロジェクトに使えることはまずないからです。
詳細は次の節で述べます。

時間単価

PMは予定工数を予定コストに変換するためにプロジェクトメンバーの時間単価が必要になります。
時間単価を決めるのはPMの責任ではないので上司に確認します。
通常は事業損益に責任を持つ事業部単位に時間単価を決めます。
月給48万円のプログラマーの所定勤務時間が月に160時間なら時間単価は3000円、という単純なものではありません。
プログラマーには賞与も支給されるでしょうし、会社としては福利厚生費も必要です。
次にプログラマーが160時間まるまるプロジェクトに使えるとは限りません。
受注のために提案や見積もり作業をしても失注すれば１円の売り上げにもなりません。
休暇も研修も必要でしょう。
プログラマーにかかる労務費を、プログラマーが売り上げに直結するプロジェクトに使える時間で割ったものが、プログラマーの時間単価になります。
通常は職種や職能に応じて時間単価は異なります。
プロジェクト・コストに関するPMの責任は時間単価を使ったコストの予定と実績になります。
一方で事業部としては、稼働率が想定よりも低く予定単価と実単価が異なれば、事業部のすべてのプロジェクトが黒字でも事業部としては赤字になる場合もあります。
これは事業部長の責任です。

コスト・ベースライン

WBSの末端アクティビティの予定工数 (時間) に時間単価を掛けたものが、そのアクティビティの予定コストになります。
それをすべて足したものがプロジェクトの予定コストです。
しかし工数 (人月) と期間 (カ月) には互換性がありません。
5人が10カ月でできる仕事は、25人が2カ月ではできません。
プロジェクトは短期間になればなるほど、大規模になればなるほど、プロジェクトメンバーが増えるので非効率になります。
作業内容が同じでも工期がコストにも影響します。
工期を考慮した予定コストをプロジェクトのコスト・ベースラインと呼びます。

次にバッファーです。
筆者の経験では20時間と予定していたタスクに30時間かかったとしてもプロジェクト・コストには大きなインパクトはありません。
しかし抜けていたタスクがあると大きなインパクトがあります。
そのことからも過去のプロジェクトの WBS はPMにとって宝と言えます。
また途中での設計変更も大きなインパクトがありますが、これは避けられません。
プロジェクトは必ず予定外の作業が発生しますが、WBSの個々のアクティビティごとにバッファーを持つのは管理が難しくなるので良くありません。
プロジェクト全体でコストバッファを持つべきです。
そして変更管理のたびにそのバッファーを消費します。
このバッファーのことをコンティンジェンシー予備 (contingency reserve) と呼びます。

ユーザーの追加要望による仕様変更要求は、プロジェクト・スコープの変更になりますから QCD にインパクトがあります。
受注前にお客さまと変更管理プロセスを合意しておく必要があります。
お客さまと合意の上で仕様変更バッファーを用意すると良いでしょう。
仕様変更による追加コストはこちらのバッファーを使います。
仕様変更が少なくて予算が余れば、操作トレーニングなど別の作業に使えます。
お客さまとの信頼関係が前提になりますが、私の経験ではこの方法はうまくいきました。
プロジェクトを複数サイクルに分け、あるタイミングを過ぎた仕様変更は次の開発サイクルに回す方法もうまくいった経験があります。
複数サイクルで主要な機能から段階的に実装・リリースしていく手法は、仕様変更対策だけなく１サイクルの開発規模を小さくできるので効率的です。

初心者のPMはフラットに毎月の工数配分をしがちです。
しかし要件定義やアーキテクチャ設計に多人数のメンバーを投入できませんので、このような工数配分は非現実的です。

実際にはモジュールごとの設計と実装に入るとプログラマーを投入しますので、毎月の工数配分は下図左のようになります。
この工数配分を元にコスト・ベースラインを計算すると下図右のようなS字カーブになります。

まとめ

このような計画を作るのにカレンダーと電卓と Excel だけで行うと大変な労力がかかります。
Microsoft Project をはじめとするプロジェクト管理ツールはPMにとっては必須の道具と言えるでしょう。
次回は、このS字カーブのコスト・ベースラインを EVM での進捗管理、およびプロジェクト完了時のコスト予測をしていく方法について解説します。
お楽しみに。

ご意見・ご感想をお聞かせください

Xcodeでの開発用にはMacレンタルをご利用ください。

追加で開発用機材が必要な時にご利用ください。