プロジェクトの明暗を分ける時【システム開発見積もりの問題と回避策】

システム開発における見積もりは、システム開発の成功失敗をわける、ひとつの大きなポイントです。

僕も長年、プロジェクトリーダー、マネージャを経験してきましたが、見積もりが大幅にショートしてしまったプロジェクトは、実に大変になることもあります。

自分が若いとき、もう２０年以上前に経験したプロジェクトで、実際の見積もりと実際にかかった人月とで１桁（１０倍）違ったものがありました。

そのときは、とある実験プロジェクトだったので、成果を出すためにあえて少なく見積もったのもありましたが、結果はさんざんでした。

プロジェクトに参加した８人の当初メンバーのうち、４人が入院し、別の一人が会社にこなくなり辞めました。

なんとかもちこたえたのは、８人中３人だけ。見積もりにこれだけ差があると、半分以上が倒れるプロジェクトにすら成り得るということです。

今では考えられませんが、確か１か月の残業時間は２５０時間くらい（稼働時間ではありません、残業時間です）でした。

僕はそれ以来、見積もりだけはミスしないように、いろいろなやり方を調べました。

今回は、システム開発の肝ともいえる見積もりについてです。

見積りの問題点

見積もりの最大の問題は、「ほとんどのコスト見積りは低すぎる傾向がある」というところにあります。

なぜ低くなってしまうのでしょうか。
いくつかの要因があると思っています。

要因のひとつは、この程度であれば、３日くらい、というマネージャの誤った作業時間の把握の仕方がまずあげられます。
マネージャーが優秀である場合は、自分は３日でできた、というとらえ方でつかんでいる可能性もあるし、未熟な場合は、たぶんという類推で間違った答えを出していることもあります。

実際に未熟な、または優秀であっても現場から離れて指示だけしているマネージャーは、現場で発生している課題や発生しそうなリスクを織り込めないので、その分の工数がショートする可能性があります。

また、プロジェクトは生きているので、そのプロジェクト特有で実施しないといけない項目だとかがあったりするし、そもそも必要なタスクや機能がもれていたり、前提条件に書いていないために、想定以外のタスクをやらないといけなくなったりもします。

さらには、見積もる側だけではなく、お客様からの要望や、期待にこたえようとする気持ちが見積もりを短くしてしまうこともあります。

つまり、「目標」を「見積り」としてしまうのです。

見積もるのが厳しい場合には、相応以上のリスクをみたり、時間的な余裕が交渉できそうなら、見積もりの回答までに期間をもらうなど、見積もりをすることは、プロジェクトメンバーも含めたあらゆる責任を背負っているくらいの気持ちで、数字を出すのは慎重にすべきです。

僕は、見積もり出す側になったこともあれば、出してもらう側になったことも数多くありますが、概要だけを話して概算どれくらいですか？と聞いても、できるマネージャーはその場では答えないことが多いです。

もちろん、会社のルールとして金額は上位承認とか、組織的なＰＭＯチームが承認していないと出せない、とかいうルールがあるのかもしれませんが、多くの人員に責任がある立場では、簡単には答えないですね。

ある時、確か会社の会社の予算立案の時期に無理に、
「難しいでしょうけど、おおよその概算の数字をだしていただけませんか」とお願いしたことがあります。

その時の答えは、

「今なら、１億という数字しかだせません」

というものでした。

ちなみに、自分のその時のそのプロジェクトのおおよその費用感覚は、１千万から２千万の間でした。
相手の方もおそらく感覚的にはそうつかんでいたはずです。それでも１億という回答。

見積もりの提示は、迅速も大事ですが、そのくらい慎重になってもいいと考えています。

システム開発の見積もりの問題を回避する策

見積もりが甘くて、小さな数字を出してしまうのを避けるために何をすればよいのでしょうか。

見積もり問題回避のための実施項目を、下記にあげてみました。

・複数の方法での見積り

プロジェクトの見積もりは、ＫＫＤ（経験・勘・度胸）から、実際に細かく積み上げる方法までいくつかのやり方があります。
また、複数の方法を組み合わせることで抜け漏れを防ぐこともできます。
あるメインの方法を決めて、それに対して検証する意味でも、複数のやり方、できれば複数の人での見積もりを実施するべきです。

・ツール/過去実績を活用

見積もり根拠として、類似プロジェクトの過去の実績は強い味方になります。
組織としてプロジェクトを実行する力をあげるためにも見積もりと実績の積み上げは重要ですが、実績平均といかなくとも、過去の類似プロジェクトを参考に、算出したほうが、見積もり精度があがるし、他者への説明にも信頼性がまします。

・プロジェクトのリスクを見積もりとして考慮

リスク管理については別記事も書いてますが、可能性の高いリスクは、その回避策などをあらかじめ見積もりに加算しておくのは大切です。

先読みがプロジェクトの成功の秘訣【プロジェクトのリスク管理項目】

・前提条件の確認、見積り前提の提示

見積もりができない場合には、一定の想定をしてそれを見積もり前提として提示します。

例えば、扱うデータ量、オンライン画面のレスポンスなどの性能に関する内容や、マスタメンテ機能は見積もり範囲外などと、機能範囲の絞り込みとか、そのプロジェクトにとって、やるやらないで見積もりが左右される場合には、前提としてしっかりと明示します。
「見積もりを出すときには、必ず見積もり前提をつける」

これは、自分の中の提出ルールにしてしまってもいいくらいに、大切なことだと考えています。

僕はそうしてたし、一緒に仕事をしたメンバーにも必ずそうするように伝えていました。

・成果物の定義、記載レベルの発注元との認識あわせ

見積書に、成果物「仕様書一式」とか「設計書一式」などと記載してあるのを見たことがありますが、成果物は一覧化し、その成果物の内容（レベル）もお客様と認識あわせておいた方が問題がおきません。

設計書などの成果物は可能であれば、目次レベルでの調整が望ましいです。

・見積りのレビューの徹底（有識者レビュー）

見積もりは複数人で、経験豊富な人に確認してもらうのは大切です。
現場にはいりすぎると視えなくなったり仕方がないと流されるときがありますが、プロジェクト外から客観的なチェックは、そういうなれ合いから一歩離れたところから、プロジェクトを適正化するのに役立ちます。

そういう意味で、ＰＭＯ組織をもつ企業が増えているのかもしれません。

・開発対象（プログラムの機能開発）外の工数も必要時は見積り

開発機能面だけに着目して、品質、特に性能やセキュリティ等の非機能側面を保証するための工数が漏れることがあります。
例えば、下記のようなもの
非機能テスト（性能保証、チューニング）、運用定義、切替
各種管理業務（進捗、課題、報告）
データの移行、ユーザテスト支援等

どこまでの受注範囲か、スコープを明確にして、範囲に入っている場合には見積もりを、範囲外の場合には見積もり前提にその旨を明記するようにすべきです。

以上、システム開発の見積もりの問題を回避する方法をいくつか説明いたしました。

繰り返しになりますが、見積もりはシステム開発の要となる仕事になります。
慎重になりすぎてもチャンスを逃すことがありますが、規模見積もりのミスは、プロジェクトメンバーを不幸にするリスクにもなります。

見積もり方法を学び、慎重に対応していくことが大切と思います。

プロジェクトの悩み事へのご支援

これまでの経験やノウハウをもとに、プロジェクトに対するコンサル、ご支援/ＰＭＯ、プロジェクトマネージャの育成などを実施しております。

本記事をお読みいただきご興味のある方、ご支援・ご相談などは、遠慮なく下記よりご連絡いただけると幸いです。

https://simpleonesoft.com/project_support/