プロジェクト・コスト・コントロールのベーシック
プロジェクト・コスト・コントロールのベーシック (2016-01-11)
プロジェクトのコスト・マネジメントは、計画段階の仕事と遂行段階の仕事に大きく分けることができる。前者はコストの計画=プランニングの仕事で、具体的にはコスト見積および予算設定である。そして遂行段階の方は「コスト・コントロール」とよばれる。
このサイトを以前からよんでおられる読者の方はご存じかもしれないが、わたしは『管理』という日本語は基本的に使わない。かわりに、『マネジメント』とか『コントロール』といった、英語をカタカナ書きにした言葉を使うことにしている。カタカナ言葉の氾濫は好きではないが、管理という語が多義語で、あまりに曖昧な使われ方をするので、コミュニケーションで誤解を生みやすいためだ。誤解というのは、お互いに違うことをいっているのに、それぞれがちゃんと理解したと勘違いすることである。誤解はたんに話が通じないことより、始末に負えない。通じていないのは、その場で両者が分かるが、誤解は両者が気づかずに進んでしまうからだ。たとえば「原価管理」といった場合、片方はCost
Managementというつもりで話し、他方はCost Controlの意味で理解する、といった具合だ。
英語でControlというと、何かの仕組みや対象を、きちんとチェックしたり意図したとおりに正確に動かしたりする、という意味になる。技術系の日本語で言うと『制御』に近い。たとえば工場の検査工程の仕事は、設計通りにモノが製造されているかをテストする仕事で、Quality
Controlとよばれる。あるいは、空港で到着客のパスポートをチェックする仕事は、Passport Controlとよばれる。
一方、Manageという英語の動詞にはどこか、暴れ馬を乗りこなす、といったニュアンスがある。御しがたい相手を何とか従わせる、という風にである。なので、マネジメントという仕事の中には、計画や制御以外に、先読みとかリスク・テークとか決断と交渉といった行為が重要な要素となってくる。入国管理係官の仕事をPassport
Managementと呼ばないのはこのためで、係官に個別にリスクテークや入国判断などしてもらってはまずいからだ。マネジメントというのは、コントロールの上位概念である。Quality
Managementといえば、設計から品質検査までを含む品質の全体像を、なんとか思い通りにしていくことを意味する。
そしてコスト・コントロールとは、コストを意図したベースライン(実行予算)の中におさめていく仕事である。計画通りに収まるよう、モニタリングしながら制御していく。これがコスト・コントロールの目的である。ついでにいうと、英語のCostの方は、「原価」でほぼ誤解が無い。
実行予算の枠内にコストをおさめるためには、二つのことが必要だ。まず、現時点までにいくらのコストを実際に使っているのか。そして、このままでいくと、プロジェクトが完了する時点での最終的なコストはいくらになるのか。これを、コストの費目ごとに把握する。
月ロケットか何かにたとえるならば、現在位置の計測と、着地点の予測である。着地点はロケットの場合、発射時点でかなりの部分が決まる。しかし、航行途上でも大気圏の状況やらエンジンの燃焼具合などで、それなりに予定した航路からの変動がある。そこで、元々ねらった地点に進路をもどすべく、制御するのである。プロジェクトも同じで、コストの着地点は、最初の計画(=コスト見積)の良し悪しで、かなり決まってしまう。しかし、遂行途上でもいろいろな変動要因がある。すなわち、工夫の余地があるということだ。
ここで念のために書いておく。プロジェクトのコスト(原価)とは、つまり、かかる費用のことだ。受注金額(プライス)のことではない。コスト・コントロールのベースラインとなる数値というのは、プロジェクト計画において決めた、実行予算の内訳となる費目別の数値である。
こんな当たり前のことを書くのは、ときにこの両者が混同されているケースを見かけるからだ。たとえば費目の内の、外部発注の比率を議論するとしよう。いろいろな過去のプロジェクトの実績データを掘り出してきて、あのケースでは何%だったとか、比較する。この時の基準は、費用総額に対する比率を議論する必要がある。受注金額に対する比率であってはいけない。なぜなら、受注金額は販売戦略に応じて、意図的に上乗せしたり値引きしたりすることがあるからだ。ある成果物を作るのに、外注コストが6千万円だった。ただ、全部で費用は1億円かかった。だから外注比率=60%となる。かりにこの成果物を1億2千万円で売ることに成功しようと、競合のためやむなく9千万円の赤字で受注しようと、外注比率にかわりはない。
これはつまり、プロジェクト・マネージャーはコスト総額に責任を持ち、セールス側は販売金額に責任を持つ、という責任分担を意味する。そして、
利益 = 販売金額 - コスト総額
なのだから、利益確保はプロマネと営業の共通目標であることを意味する。かりにやむなく9千万円で赤字受注をしたとしても、計画時点のコスト見積の総額である正味原価(Net Cost)は1億円であり、プロマネは1億円以内での達成に責任を持つべし、ということである。かりに社内組織の都合で、プロマネが営業マンを兼ねている場合でも、正味原価と販売価格は区別して考える。そうしないと、後々でコスト分析をして次の見積をするときに、基準となるデータが混乱してしまう。
プロジェクト・コスト・コントロールの仕事は、たった一つの式で表現することもできる。それは次の式だ。
AC + ETC = EAC
ここで、ACとはActual Costの略で、すでに使った実績コストを表す。ETCはEstimate to Completeの略で、これから完了までに必要だと予測されるコストである。そしてEACとは、Estimate
at Completionの略で、完成時点での予想金額を意味する。これらの略号は、今日の現代PM理論で標準的に通用している用語だ。
コスト・コントロールの仕事とは、上の式にあるように、三つの要素からなる。まずACすなわち実績出費を把握すること。つぎに、これからの出費であるETCを推定すること。そして着地点であるEACを計算し、元の目標であった実行予算の枠内に収まらなければ、対策を考えて講じる(普通はETCを下げる方策をとる)ことの三つだ。
ACの把握のためには、組織の出費がきちんと記録されていること、それがプロジェクト単位に仕分け可能になっている必要がある。つまり『プロジェクト制』が確立していることが望ましい。もちろん、どんな企業でも、経理と納税の義務がある以上、出費の記録はとられているはずだ。ただ、どの出費がどのプロジェクトの原価に対応しているかを、区別できるようになっている必要がある。外注先企業に案件Aも案件Bも案件Cもいっしょくたに発注、検収もどんぶり勘定、では、コスト・コントロールができている状態とは言えない。
かりにプロジェクト単位での出費の把握が可能でも、それが迅速に行われないと、やはりコスト・コントロールの役には立たない。日本企業では「月締め」の慣習が強いので、新春まだ松の内の注文も、1月末の注文も、翌月の2月15日頃にまとめて請求され、それが経理部門のチェックを終えて技術部門にフィードバックされるのは2月25日頃、なんて状況は珍しくない。費用が発生してから、実質的にそれが計上把握されるまで、平均1ヶ月くらいかかる。もしプロジェクト全体工期が6ヶ月程度なら、1/6
= 16.7%程度の遅れである。あなたは1日に4時間ずつ遅れていく時計で仕事を計測したいだろうか?(笑)
社内コスト、とくに人件費の把握も、コスト・コントロール実現のための次なるハードルだろう。当たり前だが、関係する社員全員が、きちんと精確にタイム・シートを記録している必要がある。それも、皆がタイム・シートを記入するのが月1回、庶務の担当者に尻をたたかれて慌てて入力、では上と同じだ。タイム・シートには、プロジェクトを識別する番号と、WBSコードが記入されていなければならない。
WBSコード? そんなのがタイム・シートに必要なの? --はい、そうです。プロジェクト・コスト集計は、通常、計画時点で作ったWBSがベースになる。プロジェクト全体を作業(Activity)の集合体に分け、それを階層的に構成したものがWBS(Work
Breakdown Strucuture)である。WBSそれぞれの作業に必要な費用を見積って、全体の実行予算が設定される。この予算額に対して、実際の出費と今後の出費予定がいくらになるのかを、それぞれの作業に対して予測する。それを集計したものがプロジェクト全体コストの着地点になるのだ。
つまり、プロジェクト・コスト・コントロールにおいて、WBSとはコストのロールアップ(集計)構造を示すのである。(→「WBSはコスト見積の基準を規定する」 2012/11/01 参照のこと)。である以上、何野誰夫君が1月第2週にプロジェクトAに使った32時間は、モジュールXの実装Acitivityの仕事なのか、それともインタフェースYの内部設計のActivityの分なのか、対応関係が分からないといけない訳である。
そうしない限り、「このプロジェクトAの時、内部設計と実装にかかった工数の比率は25:47%だったっけ?」という会話が、あとでできなくなるということだし、「要件定義以前と結合テスト以降を除いて、設計と実装についていうと、モジュールXは結局いくら工数がかかることになるのかなあ」という予測が不能になってしまう。
ところが会社というのは不思議なところで、何野誰夫君の32時間の内、残業割増分がつく残業部分は何時間だとか、彼の給料が毎月何円だとかいったお金の細部にはこだわるくせに、32時間が結局どのような仕事に費やされたのか、それは元々何時間分で見積もっていた仕事なのか、といったことはないがしろにされがちだ。お金にこだわるくせに、仕事の内容にはこだわらない。これでマネジメントだのコントロールだのができるはずはない。はっきり言って、プロジェクトの実務の世界では、個人別の給与や残業割り増しなど、どうでもいい。時間あたりの平均単価による標準原価で十分なのである。それより、100時間で終わるはずの仕事が200時間になるかどうかの方が、はるかに重要なのだ。
著書「世界を動かすプロジェクトマネジメントの教科書」https://gihyo.jp/dp/ebook/2015/978-4-7741-7625-3
にも書いたとおり、予算と進捗のコントロールというのは、ある意味で、プロジェクトを引っ張っているリーダーに対し、カーナビを提供する仕事にたとえられる。カーナビは、車のドライバーが運転に集中できるよう、位置測定や走路計算などの補佐してくれる。だからわたしの業界などでは、「コスト・エンジニア」という専門職が存在しており、大規模プロジェクトではプロマネの下に専任のコスト・コントロール・マネージャーというポストを置く。
そして、すべてのプロジェクトにおける見積・実行予算と、その実績データは、コスト・エンジニアリング部門に集約される仕組みとなっている。それが、次のプロジェクトの正確な見積のベースとなるのである。コストの話をすると、とくにIT系では見積手法の話題に関心が向かい、ファンクション・ポイント法だCoCoMoモデルだという議論になりがちだ。それも大切だが、1
Function Pointが、自社の組織では何時間の工数になるのかを推計する基盤は、自社の実績データしかない。より良い見積をしたければ、より適切な実績把握の仕組みを、まず考えるべきなのである。