 |
プロセス１０：コストコントロール |
◆トップダウン見積もりとボトムアップ見積もり 見積もりの方法を大雑把に分けると、トップダウン見積もりとボトムアップ見積もりがある。これらは見積もりの目的によって使い分けられることが多い。 トップダウン見積もりはいくつか方法があるが、代表的なものは ・過去の類似プロジェクトの見積もりの転用、類推 ・複数の専門家や経験者の分析 の２つである。トップダウン見積もりが使われる局面は、営業、プロジェクトの企画などで、プロジェクト全体のコストの概算をし、予算の決定をしたい場合が多い。文字通り、トップダウンなので、積算をするイメージではない。 これに対して、ボトムアップ見積もりは、作業単位や、要員単位、システム機能単位、モジュール単位など、何らかの単位に注目して、見積もりを行い、それを積算して総コストを見積もる方法である。最も一般的な方法は、作業（ワークパッケージ）に注目して積算するＷＢＳ見積もりと、システムの機能に注目して見積もるＦＰ法（ファンクションポイント法）がある。こちらは主に実際の作業や仕様を反映させたコストの見積もりをしたい場合に用いられるが、逆に、見積もりと同時に作業内容を明確にしたり、あるいは、システムの使用を明確にするといった位置づけをすることもある。 見積もりを行うときに、一つ大きな問題になるのは、見積もりコストである。見積もりの精度は見積もり技術の問題のように捉えられ勝ちである。確かに、ＩＴ系の見積もりの状況を見ると、これなら大丈夫という手法が見当たらず、そのようにな傾向があることは事実であるが、一方で、そのような状況の中でも費用をかければ、詳細度を増すことができ、見積もりの精度は向上することも事実である。トップダウンの見積もりの場合には、基準になる事例などの精度に依存する部分が大きいが、ボトムアップの見積もりでは費用をかければ見積もり精度は確実に向上するので、トレードオフの問題として捉える方が適切である。 そのように考えた場合、トップダウン見積もりとボトムアップ見積もりは、うまく組み合わせていくことが必要である。例えば、計画のための見積もりをする際にも、類似案件を引っ張り出してきて、過去の見積もりを転用する部分、パラメトリックな調整部分（例えば、システムのユーザ数が異なるときにユーザ数をパラメータにしてシステムの開発費用を見積もるといったこと）、新規に見積もりを行う部分と分け、新規部分には、ＦＰやＷＢＳ見積もりを適用するといった工夫が求められる。 ◆見積もりの問題点 見積もりの問題点は二つに分けて考える必要がある。ツールの問題とマネジメントの問題である。 ツールの問題は大きく分けると二つある。一つは見積もり手法に起因する問題である。この問題というのは、手法そのものの妥当性の問題と、手法の運用に関する問題がある。例えば、ソフトウエアの規模を見積もる方法でＬＯＣ（Line Of Code）という方法がある。これは、要求仕様から開発するプログラムのコード数を推定し、そのコード数と１コード当りの生産性から全体の工数見積りをする方法で、ＣＯＢＯＬなどのプログラム言語を利用してソフトウエアを開発する場合には精度が高いが、関数型の実装環境に対する妥当性は怪しいといわれている。これが手法の妥当性に起因する問題である。 二つ目は、手法の運用に起因する問題である。例えば、ＦＰ法に対して、機能に注目して見積もりをすることの妥当性に異議をはさむ人は少ない。しかし、機能とは何かということに関する認識は人により異なり、ＦＰ法ではそれが調整項目という見積もり調整パラメータの違いとして出てくるため、人により見積もり結果が異なることが多い。これはまさに運用の問題である。 見積もりの問題というと、以上のような問題がよく出てくるのだが、現実問題として見積もりの精度に大きな影響を与えているのはこれらの問題より、むしろ、マネジメントの問題である。マネジメントの問題とは ・どのような前提、制約を置くのか ・どういうタイミングで見積もりを行うのか ・作業量の変化をどのように管理し、見積もりに反映していくのか が大きい。極論すれば、これらをうまくやっていれば、どのようなツールを使っていても精度の問題はクリアできる。 これらは一見、別々の問題のように見えるが、実は、相関の強い問題である。この３つの中でベースになるのはタイミングの問題である。タイミングの問題はやっかいな問題で、プロジェクトマネジメントとはこうあるべきという姿が明確であっても、相手のある話だからだ。タイミングで分岐点になるのは仕様確定の前かあとかという点である。仕様確定のあとであれば、規模、複雑さなどさまざまな情報を使って見積もりを行うことができるので精度が上がるということになるのだが、必ずしもそのようなフェーズマネジメントができないケースの方が多い。仕様確定の作業を開発の流れの中で行わなくてはならないケースだ。そのような場合には、推測が入らざるを得ない。 また、仕様が確定したつもりでも、潜在的な顧客の要求が隠れているようなケースも多い。この場合も結局同じことになる。 そこで、大切になるのが、前提、制約の客観性である。推測をするということは何らかの仮定をするということになるが、その仮定が主観的なものであり、第三者が見た場合に妥当性のないものであれば、推測を含む見積もりの数字そのものが主観的だということになる。 さらに、前提、制約を適切に設定していたとしても、状況の変化で見積もりが変わることが少なくない。例えば、顧客のビジネスの環境が変わったのでシステムの仕様を変更したいといったことだ。 ◆見積もりの精度を上げるには 以上の問題を踏まえて、見積もりの精度を上げるためにどのような方策が取れるかを考えてみたい。 まず、ツールの問題に関しては、手法を模索するより、運用を強化していくほうが賢明である。ここは実は難しいポイントがある。上に述べたように、ＣＯＬに力を入れ、かなり精度を出していた企業は結構多い。しかし、プログラミングパラダイムの変化とともに、過去のものになってしまったような経緯がある。今だとＦＰで注目する機能という単位が普遍性があるように思えるが、これにしても将来的にプログラムの自己生成を行うような環境がでてくればＣＯＬと同じ運命をたどる可能性がなくはない。ただ、機能に注目することは非常に柔軟性の高い方法であることは間違いない。そこで、やはり、手法を決めてその手法を使いこなしていくようなアプローチが必要だろう。 その際のポイントは標準化である。これはモジュールの標準化・再利用の問題と絡んでくるが、インプリメントの環境に依存しない機能単位の標準を設定し、そこで組織としての標準的な工数・規模を設定し、それをブラシアップしていくことにより、見積もりの精度を上げていく。 ただし、見積もりというのは単なる分析ではなく、ＷＩＬＬも含まれている。つまり、これだけでのコストで開発する方法を考えるという側面もある。従って、単に統計的な意味での標準見積もりを設定するだけではなく、作業そのものを標準見積もりに近づけていくという努力も必要である。 次に、見積もりタイミングに合わせた見積もり数字のマネジメントをしていく。その第一歩は見積もりの時点での前提、制約を顧客と共通認識することである。この中には、見積もり時点の対象スコープ、不確定部分で将来的に出てくる変動要因（リスク要因）に対する共通認識を持つことが重要である。 その上で、プロジェクトの進行の中で見積もりを精度の高いものにしていくために、プロジェクトチーム、顧客の中ですべきことを明確にし、それを共有しておく必要がある。 この作業の中で、これらを含めて、不確定要素の整理をしておくことが肝要である。まず、不確定要素の大きい作業や仕様を洗い出し、 ・顧客に明確化の責任があるもの ・プロジェクトチーム側に明確化の責任があるもの ・前提、制約に依存している作業 ・リスクになるもの の４つに分けておくと、見積もりの精度向上の責任が明確になり、プロジェクトの中での見積もりの運営がスムーズに進む。 このような作業を行う際に、コストテーブルをつくり、それをベースにして行うことが望ましい。コストテーブルについては次回解説する。 （2004/02/12号より抜粋） ■アクティビティ１：プロジェクトコストと原価 ■アクティビティ２：見積もりの作り方と精度向上 ■アクティビティ３：コストテーブルと原価企画 ■アクティビティ４：コストコントロールの進め方 > 2004/02/05 アクティビティ１：プロジェクトコストと原価 ◆今回のテーマへの問題意識 ◆原価とは何か ◆プロジェクトにおける原価計算 ◆プロジェクトコスト ◆プロジェクトマネジメントコストをどう考えるか > 2004/02/12 アクティビティ２：コストテーブルと原価企画 ◆トップダウン見積もりとボトムアップ見積もり ◆見積もりの問題点 ◆見積もりの精度を上げるには > 2004/02/19 アクティビティ３：コストテーブルと原価企画 ◆コストテーブル ◆コスト構造 ◆コスト項目について ◆コストはいつ決まるのか ◆原価を企画する > 2004/02/26 アクティビティ４：コストコントロールの進め方 ◆コントロールするとは ◆コストのコントロール ◆楽観値を実現する ◆コストの外部化 |
|
購入はこちら |
|