儲からない見積(2)~なぜ見積工数をオーバーするのか

愛知万博とか、海外旅行とか、だいぶ寄り道しましたが、やっと、この路線に戻ってきました。
前回「儲からない見積(1)」は、工数を見積もる時のマージン、工数から金額を見積もる時のマージンについての話題でした。私のいた職場では、このどちらのマージンも十分に考慮されていないために、ギリギリの(というか足りない)見積になっていたのです。
今回は、工数についてもう少し突っ込んでみます。


人件費ベースの見積に関わらない人にとって、「工数」という言葉は、あまりなじみが無いかもしれませんね。
単位は人月とか人日。エンジニアが1人で1ヶ月かけて行う仕事の工数は1人月。4人で5ヶ月なら、4×5=20人月。人月と人日の換算は、1人月=20人日でやっていましたが、これは年間の休日を125日とした理想的な環境の場合。私の職場でも、正確には1人月=20.5人日でした。
では、システムを作るのに必要な工数は、どうやって見積もればいいのでしょうか?
大型汎用機上で動作するシステムをCOBOLで開発する様な場合であれば、実績も十分にあって、不確定要素も少ないです。システムの機能を洗い出せば、あとは、処理形態や難易度によって設定された工数を集計して、全体の工数を算出することができます。他の動作環境や開発言語でも、実績のあるものであれば、同様に見積もることが出来るはずです。
しかし、動作環境や開発言語の経験が少ないとなると、工数の実績などありません。しかし、それが既に世の中に出回っている技術であれば、不慣れだから工数を上乗せするなんていう見積では、競争力がありません。明確な理由が無ければ、実績のある従来の技術や競合他社の工数と同等か、それより少なく見積必要があります。
今までに経験の無い新しい技術に手をつけるということは、どうしても見積もった工数が足りなくなる原因になります。新しい技術への投資と考え、実績を重ねるうちに、不慣れなときに損した分を回収できれば良いのですが、この世界の技術の進歩は待ってくれません。回収が出来る前に、新しい技術に挑戦することになる可能性が高いです。
ところで、システムを作り上げるのに必要な工数は、システムの機能を洗い出せば、それだけで算出できるでしょうか?
前述の、大型汎用機上のCOBOLのシステムであれば、開発環境も本番環境も既存のものが使えますので、機能ごとの工数をもとに全体の工数を算出しても、大きくずれることはありません。
しかし、UNIXサーバやPCのシステムとなると、話は別です。たとえ、開発環境に既存のものが使えたとしても、本番環境については、システムごとに用意する場合がほとんどです。また、開発環境がPCの場合は、開発要員の数だけ開発環境を準備する必要があるので、既存の開発環境だけで足りるとは限りません。さらに、新しい技術を用いて開発する場合、その技術の調査と、開発要員の教育も必要です。
ハードウェア、ソフトウェアの構成の検討と導入、ネットワークの検討と導入、開発用PCの調達と設定、開発技術に関する調査と教育。大きなシステム開発のプロジェクトであれば、これらの業務を専門に(あるいは他のプロジェクトと兼任で)行う担当者を置くことが出来ます。また、一部の業務は、ハードやソフトの販売元からエンジニアが派遣される場合もあります。しかし、小さなプロジェクトであったり、エンジニアが派遣されない様なハード/ソフトを使ったりする場合、もともとSEやプログラマとして参加しているだれかが、これらの業務を兼務することになります。
私の場合、システムの技術調査や設備管理をする部署にいた経験があるので、この手の仕事が回ってくることが良くありました。嫌いな仕事じゃないので構わないのですが、必要な仕事であればちゃんと見積に入れておきたいものです。設計や開発の仕事の他に、これらの仕事をしたことにより発生する時間外労働のコストは、どこが負担でしょう?
見積もった工数より、実際の工数が多くなってしまう原因は他にもたくさんあります。私が知らない原因もたくさんあるでしょう。とにかく、見積もった工数より、実際の仕事は多かったということです。ここまでに書いた、技術面での原因の他にも、事務処理や、ユーザの都合など、いろいろあります。
・見積や契約などの業務をリーダー格のSEが兼務することになった。
・プロジェクトルームの場所の問題で、移動時間が長い。
・開発環境の設備の都合で、資料のプリントアウトに時間がかかる。
・開発環境にトラブルが発生した。
・ユーザに開発場所を貸してもらった結果、無関係なPCサポートをすることになった。(これは工数増加じゃないかな…)
・ユーザの要望で、進捗会議にはリーダーだけでなく他のSEも出席する必要があった。
・ユーザの都合で、ユーザとの打合せは、ユーザの部署ごとに複数回行う必要があった。
 ...
いずれにしろ、工数が見積をオーバーしてしまうと、金額面だけでなく、スケジュールや人員の面でも問題が出てきます。可能な限り、余裕のある工数見積をしたいものです。
そう言えば、工数増加の原因として、一番よくあるものが抜けてました。
開発途中で発生する、機能の追加、あるいは、仕様の変更です。
しかし、この場合、見積の前提となるものが変わっているので、工数が増えるのは当然。問題は、工数増加分の費用をどうするかです。
ユーザの都合によるものなのか、要件のヒアリングが下手だったのか。ユーザ企業の経営体制の変更や、法令への対応などの明確な理由がない限り、システムを開発する側が負担するケースがほとんどでしょう。せめてスケジュールだけでも猶予してもらえれば助かるのですが…

“儲からない見積(2)~なぜ見積工数をオーバーするのか” への 1 件のフィードバック

  1. 儲からない見積(3)~工数×単価では見積もれないもの

    気分の乗ってるうちに、シリーズ第三弾。
    普通に考えれば、売上が仕入+経費より十分に多ければ、儲かるはずです。特別な事情がなければ、仕入より安く売るはずは無いので、儲からないのは経費が予定以上となる場合。
    コンピュータシステムの開発を受託する場合、経費.

コメントは受け付けていません。