コスト見積り

コストの見積りとは何かを理解しプロジェクト遂行に係わるコストの見積り方法について学ぶ
株式会社三菱総合研究所
情報技術研究センター 澤部直太

「プロジェクト管理実践特論」の第9回では、コスト見積もりについて説明します。ここでは、「プロジェクト・コスト・マネジメント」、「コスト見積 り」、「予算化」の話をします。最後に例としてソフトウェア開発における見積もり手法の説明をしたいと思います。

【目次】
slide03.png

今回の範囲はPMBOKにおいては、計画プロセス群の中のコスト見積りとコスト予算化の部分になります。

slide04.png

おなじみのこの表では、「コストマネジメント知識エリア」の中の、計画プロセスの中のコスト見積りとコスト予算化の部分になります。

プロジェクト・コスト・マネジメント

slide05.png

「プロジェクト・コスト・マネジメント」のプロセスは少なく、「コスト見積り」と「コスト予算化」によって計画が終わります。以降はコストコント ロールにおいて、実施中にコストがどのように使われているかということを監視することになります。

コスト見積り

slide06.png

コスト見積りについて考えてみましょう。これまでスケジュールやスコープの話をしてきましたが、コスト見積りというのは実は非常に大事で、コストが 正確に見積もれないとさまざまな悪いことが起こります。まず、コストを少なく見積もってしまった場合には、そのプロジェクトを実際にやってみると赤字に なってしまいます。逆に、コストを多く見積もってしまった場合には、他社の方が安く仕事ができるということになってしまいますので、今度は仕事がもらえな くなってしまいます。

「コスト見積り」のインプットには、「組織体の環境要因」があります。景気の状況もここに含まれます。「組織のプロセス資産」は重要で、どのように コストを見積もるかという方針やテンプレートなどがあります。過去に類似のプロジェクトがあれば、その情報から類推してコストの見積りができます。組織が 持っているプロセス資産というのは非常に重要です。

他に「プロジェクト・スコープ記述書」、「WBS」、「WBS辞書」を使います。どのような作業をするかということがコストを見積もるためのベース になりますので、この三点セットは大変重要です。「プロジェクトマネジメント計画書」の中の「コストマネジメント計画」と「リスク登録簿」については、後 で説明しますが、これがあるということを覚えておいてください。

このようなインプットから実際にコストの見積りをするのですが、あまり複雑な技法はありません。「類推見積り」は、過去の類似プロジェクトのコスト の実績から現在のプロジェクトを見積もる方法です。例えば前に同じようなプロジェクトをやっていてそれが1,000万円でできた場合に、似たような規模で 同じような期間でできるものについては、大体そのぐらいの金額でできるだろうということが類推できます。

「ボトムアップ見積り」は、コスト見積りの中で一番重要なやり方です。なるべく一番下のレベル、例えばアクティビティレベルでコストを見積もり、そ れを足し合わせるという手法です。これは後で説明します。「係数見積り」も後ほどソフトウェア開発の例で説明しますが、過去のプロジェクトのデータをもと にして、それにいろいろな係数を掛けたり足したりして見積り金額を計算する方法です。

「ベンダー入札の分析」は少しわかりにくいと思いますが、例えばあるプロジェクトをやるときに、ほかの会社から見積りをもらいます。その際、全体の 価格以外に細かい見積書が付きます。個別の作業についていくらかかるかが書いてありますので、それを分析してその作業がその金額でできるかどうかを検証す るわけです。

「予備設定の分析」は、スケジュールのところでも出てきましたが、コンティンジェンシーという考え方です。スケジュールのところでは「スケジュー ル・コンティンジェンシー」と言って、期間が延びてしまう可能性を考えたのですが、ここではコストが予定していたものよりもオーバーするかもしれないとい うことを考えます。プロジェクトは積み上げて足し算した予算だけで実行するのではなく、予備費というものを用意しておいて、万が一の時に備えるということ をします。これは会社によって決まったやり方があって、例えば見積もった金額に10%プラスして予備費をとっておく、ある金額以上のものについてはさらに 多くするなどと決まっている場合があります。実際にその予備費をどうやって使っていくかは、「リスクマネジメント」のところで考えます。

それから、予備費と非常に似ていますが、「品質コスト」もここでは考えます。品質コストは、要求事項を満たすためのコストです。お客様から「こうい う品質で欲しい」と言われてもなかなかそこまでたどり着けないことがあります。製品に欠陥がある、ソフトウェアの場合はバグが取り切れないなどの場合に、 それを何とか直すためのコストを考えておくわけです。

「コスト見積り」のアウトプットには、まず「アクティビティコスト見積り」があります。スケジュール・アクティビティに対して見積もった金額が出ま す。「アクティビティコスト見積りの詳細資料」には、どういう根拠でそれを見積もったか、その際に使った前提条件や制約条件が何だったかというのを書いて おきます。このコスト見積りをするときに変更が発生した場合、「要求済み変更」を出すことになります。

slide07.png

ボトムアップ見積りの例として、このスライドのような見積りの例を挙げてみます。ボトムアップ見積りは、一つ一つの作業項目の資源見積りに基づき、 それらを合計することによってプロジェクトの総資源を計算するものです。例えばこの表の一行がアクティビティだと思ってください。小さなアクティビティに 対して、どのぐらいの作業量で、その作業量に対して合計で何時間かかるかを見積もります。その時間にその作業をする人の値段を掛けて、合計でこの作業にか かる実費が計算されます。実費を計算して、間接費25%をさらに追加して、人件費だけではなくて物の値段も足し合わせていくと、この1個の作業をするのに かかる金額が求まります。これらを全部計算してやって、足し合わせたものがプロジェクトの合計値になります。

このように、細かいレベルの計算を全部足し合わせる方法をボトムアップ見積りと言います。

コスト予算化

slide08.png

続いてコスト予算化の話です。アウトプットとしてコストベースラインというものが作成されます。

「コスト予算化」のインプットには、「スコープ記述書」、「WBS」、「WBS辞書」、「アクティビティコスト見積り」、「アクティビティコスト見 積り詳細資料」があります。

「プロジェクトスケジュール」は、予算化のときにスケジュールが変わるかもしれないので、インプットとして扱います。「資源カレンダー」も同様の理 由でインプットになっています。

「契約」は、例えば外注をするときには自分の会社と外注先の会社で交わした契約書に基づいて金額が決まっています。このような契約がある場合には、 その契約も予算化のためのインプットになります。そして「コストマネジメント計画書」を見ながら、コスト予算化をしていきます。

「コスト予算化」のツールと技法には、まず「コスト集約」があります。これはボトムアップ見積りのときに説明したものと同じで、細かいレベルで見積 もったものを足し合わせていくという考え方です。「予備設定分析」は見積りをしたときにとったコンティンジェンシーが本当に正しいものかどうかを、ここで 再度確認します。見積りと同様に予算化のときにもボトムアップではなくて係数見積りをすることが「係数見積り」です。「限度額による資金の調整」は、例え ばあるプロジェクトを進めるときに、最初から幾らまでしかかけられないという制約がかかっていることがよくあります。コスト見積りをしたときに既にそれを 超えてしまっている場合、ではコストを少なくするためにどうしたらいいかということを考えていくことになります。

「コスト予算化」のアウトプットで一番重要なものが、「コストベースライン」になります。コストベースラインは、コストをあらわしたグラフです。横 軸が時間で、時間の経過とともにどのようにコストがかかるかということをグラフで表します。

この講義の初回で、プロジェクトが始まったときにはあまり人やコストがかからず、中盤になってたくさんかかるようになって、最後にコストが要らなく なって急に落ちるグラフがありました。あれと同じように、プロジェクトの立ち上がりの時期にはあまりコストはかからないのですが、徐々にコストがかかるよ うになり、コストベースラインも上昇していきます。プロジェクトの終盤になると、またあまりお金がかからなくなるので横に寝ていくという形になります。こ れがコストベースラインです。

キャッシュフローの話ですが、実際にプロジェクトとしてコストベースラインのグラフの形でコストがかかっていきます。コストに対する支払いは、か かったときにすぐお金を払うというわけではなく、それより遅れてお金を支払います。実際にそのプロジェクトから出ていくお金の流れ(キャッシュフロー)は 時間が少し遅れる、という関係を覚えておいてください。

講義の後半で学習しますが、プロジェクト遂行時に、今どのぐらいコストを使っているかということをこのグラフの中に書くことによって、プロジェクト が遅れているのかどうか、コストを使い過ぎているのかどうかなどを調べていくことができます。

ソフトウェア開発におけるコスト見積もり手法

slide09.png

ソフトウェア開発のコスト見積り手法について、簡単に説明していきます。ソフトウェアの開発規模は、途中で要求仕様が変わったり、お客さんが協力し てくれなかったりすると非常に影響を受けます。スコープ・マネジメントのところで学習したように、最初にスコープをきちんと決めてプロジェクトを進めるこ とが大前提なのですが、ソフトウェア開発の場合はスコープが非常に動きやすいという特徴があります。

ソフトウェアとはお客様が使う物を作るのですが、そのお客様がどういうものが欲しいかを具体的に言ってくれない場合がよくあります。「よくわからな いけれどこんなものを作って」と言われて、実際に作ってみると、「実はこういうものは欲しくなくてこんなものが欲しかったんだ」と、作った後で言われるこ とがよくあるのです。そういう意味で、ソフトウェア開発というのはプロジェクトマネジメントにとって非常に難しい分野だと思います。

コストの話では、プロジェクト開始時にそのソフトウェア開発でいくらかかるかという開発コストを計算するのはとても難しいです。まだ設計もしていな いソフトウェアについて、それがどのぐらいかかるかというのを正確に見積もるのは難しいことが理由です。お客様の要求がぼんやりとわかった段階で何とか見 積もろうとするので、いろいろな人が実際に苦労しているというのが現状です。

具体的な手法の話に入ります。まず、概算法というものがあります。これは見積りをする人に経験がある場合、見積りをする人の主観と技術力を使って、 大まかな金額を見積もる方法です。例えば、「このシステムを開発するのに500万円でできます」、あるいは「これはもうちょっとかかります」といったこと を、見積りをする人が経験や勘や度胸を使って算出します。これは非常に危ないやり方なのですが、今までソフトウェア開発ではこのような方法を使ってきまし た。

その他に、おおよその値を出すのに使う、類推法があります。過去の類似プロジェクトの実績コストから推測する方法です。同じようなプロジェクトを過 去にやっていると、そのプロジェクトで幾らかかったがわかりますので、それに基づいて今回は幾らかかるだろうと推測するというものです。特徴は、要件定義 の前に、ある程度のコストの推定ができることです。問題は、同じようなソフトウェア開発をやったことがない場合には使えないことです。その場合はこれまで は前述の概算法を使ってきました。

slide10.png

これではとてもプロジェクトのコストマネジメントはできないということで、いくつかの手法が開発されています。例えばCOCOMOというモデルがあ ります。1981年に開発されているのでそれほど新しくないのですが、ソースコードの行数を使って開発規模を見積る手法です。開発規模を見積もった上で、 式を使って開発工数を計算します。基本的な考え方としては、サイズ(開発規模)が開発工数に関係します。さらに、開発工数が開発期間に関係します。これ で、人が何人ぐらい全体でかかるかという規模と、3カ月かかるものなのか6カ月かかるものなのかあるいは1年かかるものなのかといった期間を計算するとい う手法です。

ソースコードの行数に基づく手法なので、実際に今回の成果物がどのぐらいのソースコードの量になるかをまず見積もらなければいけません。ソースコー ドの量はある程度設計が進んだ後にならないとわからないので、プロジェクトが立ち上がってすぐというときにはなかなか使いにくいという欠点があります。た だし、こういうモデルを使って計算すると、ある程度見積りの精度が上がります。

slide11.png

COCOMOを改良したCOCOMO IIという手法が最近はよく使われるようになってきました。COCOMOと基本的な考え方は同じなのですが、3つのモデルを用意しています。「アプリケー ション組立モデル」は、プロジェクトの初期段階でユーザインタフェースのプロトタイピングなどをつくるときにまず適用するモデルです。さらにもう少し進ん で、要求事項はほぼ確定したがまだソフトウェアのアーキテクチャ(構造)がわからない段階で使うモデルというのもあります。「ポストアーキテクチャモデ ル」は、ソフトウェアのアーキテクチャが決まった段階で使うモデルです。下に行くほど、見積りの精度は上がっていきます。このようにフェーズに分けた手法 がCOCOMO IIです。

slide12.png

COCOMOではプログラムソースコードの行数を使っているので、まだ見積もりにくいところがあります。そこでさらに考え出されたのがファンクショ ンポイント法という手法です。これは、データの入出力などのユーザに見える機能に着目します。ファンクションポイントと書いてあるように、ソフトウェアの 機能の量に着目して、そのソフトウェア開発の規模を定量化します。これは国際的に標準化もされている手法です。

slide13.png
slide14.png

概略を説明します。ソフトウェアを、コンピュータの中で行われる「データファンクション」というグループと、使う人とコンピュータの間でのやりとり に関係する「トランザクションファンクション」と呼ばれるもの、この2つに大きく分け、さらにその中を5つのファンクションに区分して計算します。

まず、データファンクションには2つあります。ILFとは、今回つくるソフトウェアが変更するデータです。例えば給与計算のソフトウェアをつくると きに、実際にその金額が入っているものがILFです。それに対してEIF(マスターデータとも呼ばれる)は、今回つくるプログラムでは変更しないもので す。給与計算のプログラムでは、例えば人の名前などがEIFになります。

トランザクションファンクションは3つあります。まずEI(外部入力)は、ユーザがこのプログラムに対して入れる入力です。例えばキーボードから入 力したデータなどです。EO(外部出力)は、このプログラムがユーザに対して表示するものです。EOを出すために内部データが書きかわって出てくるという のが特徴です。EQ(外部参照)は、同じようにユーザに示すのですが、中のデータは書きかえないで、ただ情報が表示されるだけという機能です。

以上の5つに分けて見積りをしようというのがファンクションポイント法になります。この手法の利点は、ユーザから見える機能だけで見積りをしようと していますので、早い段階から見積りができるということです。残念なことに、ここでは機能だけしか考えていません。非機能要件と言われているものはこれで はなかなか考慮できません。例えば、このプログラムでは1秒以内に答えを返さなければいけないといったことは表現できないのです。

slide15.png

さらにもう少し進んだ見積り手法である、CoBRA法という手法も紹介します。これまで説明してきたように、ソフトウェア開発の見積りは非常に難し く、さまざまな組織で試行錯誤しているのですが、組織的に統一された見積りモデルというのは実はあまりありません。類推法というのが先ほどありましたが、 類推法ができるためには過去にいろいろなプロジェクトをやっていないと類推できません。しかし、そういうデータをあまり持っていない会社はどうすればよい でしょうか。これを解決しようとしている見積りモデルがCoBRA法になります。

CoBRA法のポイントとしては、経験豊富なプロジェクトマネージャと少しの過去のプロジェクトデータがあれば、それで見積りができるというような モデルを考えたところです。プロジェクトの実績とプロジェクトの変動要因を入れることによって、今回見積りたいプロジェクトについて見積りの工数を計算し ます。

slide16.png

CO(コスト超過要因)は、プロジェクトマネージャの知識や経験に基づいて定義していきます。ベースライン(生産性)を過去のプロジェクトデータか ら計算します。この2つを使って、開発規模とベースラインとコスト超過要因を式に当てはめて、全体の工数を求めます。

CoBRA法でいろいろなプロジェクトを実際に計算をしてみると、比較的良好な結果が得られます。

プロジェクトの最初の段階でなるべく精度の高い見積りをするために、CoBRA法などの手法が開発されてきましたが、ソフトウェア開発では最初の段 階で規模が見積もれないのであれば契約を分けるという考え方もあります。まずは設計までを行います。設計するとソフトウェアの開発規模がかなりわかってき ますので、開発は次の契約で実施するのです。