2007年03月

2007年03月25日

上流、下流、どっちが儲かるの?

このエントリーをはてなブックマークに追加
前回の見積もりの話で、「不確実性のコーン」という図を紹介しました。

システムの開発の工程と見積り精度の関連グラフです。

これにIT業界で仕事を行うときのよくある仕事の分担の例を追記してみました。


不確実性のコーン


さて、この図の分担にある担当ベンダのうち、どこが一番儲かるのでしょうか?

そして、どこが一番もうからないのでしょうか?

この図なしに考えたとき、一番儲けるのは元請けベンダ、そして一番もうからないのは利鞘をたくさん抜かれた末端の三次受け、オフシェアということになります。

しかし、この図を見ると、一番正しく見積もりがおこなえる可能性があるベンダは三次請け、オフシェアのベンダになります。

システムの開発で利益を出すこと。それは求められる品質を持った製品を予算の範囲でいかに原価を抑えて作ることにあります。

そのためには確実な原価の見積りが必要になります。

ということは、これらのベンダの中で確実に儲かる可能性が高いのは三次請け、オフシェアのベンダ、ということになるはずです。
それなのに儲かっていないのはなぜでしょうか?

そもそも下記のような事をしている事が原因かもしれません。

・正しい手法による見積りをそもそもやっていない。

・正確な見積りを出したのにもかからわず、
 受注元の圧力に負けて訂正してしまう。


・正確な見積りの結果、原価がオーバする事が解っていながら、
 全く仕事がないよりかマシと考えて受注してしまう。

これらをやってしまうのは日本の企業が多く、海外の大手オフシェアを行っている会社は、受注元の圧力に負けず、きちんと原価管理をして、確実な儲けを出していると考えられます。

そして、逆に儲からないはずの元請けのベンダで儲かっているところは下記のような事をしているかもしれません。

・工程が進み、原価が予算を上回ることに気づいていながら、
 下請けをうまく説得して、低予算の見積りで仕事を受注してもらう。

・とにかく原価が安い海外オフシェアに早めに出す。

・顧客が原価に対してシビアでないので、
 だいぶ多めの見積り金額で受注している。

さらに見積りもあまり正しく行えそうにないし、あまり元請けベンダのような事もできない下請けベンダあたりは一番損なのかもしれません。

システム開発では、何かと上流が儲かる、上流が偉いという信仰がありますが、ビジネスとして正しく利益を出すことを考えるには、上流、下流のこだわりというものは無くしたほうがよいのではと、最近よく思います。



zeroaka at 05:53|PermalinkComments(0)TrackBack(0)このエントリーを含むはてなブックマーク │システム開発 | 日記

2007年03月06日

ソフトウェア見積り 人月の暗黙知を解き明かす

このエントリーをはてなブックマークに追加
システム開発を行う人であれば、誰でも悩む見積り。

いわずともなく自分も、その一人。
そんな悩みを解消すべく、こんな本を読んでみました。

ソフトウェア見積り 人月の暗黙知を解き明かす

その中でちょっと気になった内容をいくつかあげてみます。


・不確実性のコーン


 プロジェクトの初期の方が、見積りのばらつきが高く、プロジェクトの工程が進むに従って、
 コーンを描くように見積りのばらつきは減っていく、とうものです。
 こんな感じで。

 これについてはいろいろ考えてしまいますので、別の機会にいろいろ話したいと思います。


・見積りに見落としがちなプログラミング作業以外のアクティビティを見積もろう。


 これは基本ですね。
 開発環境のマシンのセットアップ、ドキュメントレビュー、
 パフォーマンスチューニングなど、よくよく考えてみると、いろいろあったりします。


・即興の見積りが首を絞める。


 よくある話ですね。
 「ざっくりどれくらい?」とさりげなく聞かれて適当に答えてしまい、
 その値があたかも正式な見積りであるかのように一人歩きしてしまい、
 後で正確に見積もってみたら、全然かけ離れて足りない工数で大後悔、
 なんて話はホント笑えません。


・規模の不経済


 ソフトウェア開発の規模は10倍になれば、工数も10倍ではなく、
 それ以上の工数を必要とし、生産性は下がり、単体コストはあがるという不経済が発生します。
 これについての原因の例としてコミュニケーション経路の増加を述べています。
 たとえば、10人のチームのコミュニケーションの経路は45、
 3人のチームの場合は3、よって3倍の人数で9倍の経路になると。
 よって見積りには規模による複雑性を考慮にいれる必要があります。


・見積りの政治力学を減らす


 これはソフトウェアの見積りツールを遣ったり、過去の実績値などを軸にした、
 故意の調節が利かない見積りを作りましょうというもの。
 個人の判断など、調節が利くような部分を見積りに残すと、政治的な圧力で、
 結局、相手が望む数字に近づくようになってしまい、正確な見積りとは
 程遠いいものになってしまいます。


・最良のケースの見積りと最悪のケースの見積りの両方を行い比較する。


 楽観的な考えと悲観的な考えの中間をとるのが効果的、ということでしょうか。
 この本には、見積りから期待ケースをとる公式がのっていましたが、
 その公式の根拠は・・・やっぱり結構適当じゃないかと思ったりして。


・標準的な見積りプロセスを使う


 これは先ほどの「政治力学を減らす」にも通じますが、見積りプロセスを標準化することで、
 プロセス自体についての議論の余地=調整の余地がないようにして、
 故意のアウトプットのコントロールを避けましょう、ということです、
 
・WindowsNT3.1の開発とスペースシャトルの打ち上げプロジェクトの工数

 WindowsNT3.1の開発規模はなんと、2000人年。予算にして、2億ドルだそうです。
 びっくりです。
 スペースシャトルの打ち上げプロジェクトはその10倍の規模。
 最新のWindows Vistaの開発工数は一体どれくらいの規模になっているんでしょうか?


と、以上、気になるところについての感想です。

で、結局読んだ全体の感想というと、見積りというのはあくまで予想で、
100%完璧な見積り方法というものはないのかな、と。
見積りした数値に10%以内の誤差しかなければ十分性格な見積もりだとも、
この本は述べています。
しかし、その10%が、カツカツなシステム開発で、
わずかな利益を出すのに必要な部分なんですよね。

ですが、この本で書いてある対策は200%や300%の見積もりミスによる
大惨事を避けることには十分効果があるように思えます。
そういうデスマーチプロジェクト、世の中には多いですからね。

ではでは。




zeroaka at 02:12|PermalinkComments(0)TrackBack(0)このエントリーを含むはてなブックマーク │システム開発 | 日記