**************************************************************
_/_/_/_/_/_/_/  ソフトウェア業界　新航海術  _/_/_/_/_/_/_/_/_/
**************************************************************
第123号  2006/4/17
  ▼  まえがき
  ▼  [ブルックスの法則]　人月による見積もりの是非
  ▼  [ブルックスの法則]　人月による見積もりは日本独特の商習慣ではない
  ▼  [ブルックスの法則]　要員の最大数は独立したサブタスクの数に依存する
  ▼  [ブルックスの法則]　プロジェクトの月数は順次的制約に依存する
  ▼  [ブルックスの法則]　人は時間に余裕があると、ますます時間をかける
  ▼  [ブルックスの法則]　期間を短縮するとコスト曲線は急上昇する
  ▼  次回以降の予告


*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
  まえがき
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

蒲生嘉達（がもう よしさと）です。

第120号から、ブルックスの法則（遅れているソフトウェアプロジェクト
への要員追加はさらに遅らせるだけだ）について書いています。

「ブルックスの法則」シリーズを最初から読みたい方は、下記を参照
してください。
http://www.kei-it.com/sailing/back_brooks.html

バックナンバーはブログでも公開しています。
ブログ：　http://kei-it.tea-nifty.com/sailing/



*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
  [ブルックスの法則]　人月による見積もりの是非
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

「人月による見積もりが日本のソフトウェア産業をダメにした」という
学者、技術者がいます。

彼らは次のようなことを言います。

(1)人月による見積もりは、日本独特の商習慣である。

(2)それは建築物や橋などのゼネコン的下請け構造型プロジェクトの
　手法をソフトウェア請負開発に応用したものである。

(3)「全体でいくら」という見積もりなら、それを少人数でやって利益を
　出そうという意欲が生まれるが、「1人月○○万円×人月」という
　見積もりだと、かける人数が見えてしまうので、生産性をあげよう
　という意欲が出ない。これが日本のソフトウェア産業をダメにした。

(4)本来、請負契約の場合、仕事の完成を約束すればよいのであり、
　何人月という提案をユーザーに言う必要はない。
　「このシステム開発案件はこの金額だ」とだけユーザーに提示
　すべきである。


例えば、馬場史郎氏が書いた次の記事はその典型です。

「日本のIT業界に巣くう大問題　人月での見積もりがエンジニアをダメにする」
前編　http://jibun.atmarkit.co.jp/fengineer/special/ningetu/ningetu01.html
後編　http://jibun.atmarkit.co.jp/fengineer/special/ningetu/ningetu02.html



*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
  [ブルックスの法則]　人月による見積もりは日本独特の商習慣ではない
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

しかし、人月による見積もりは日本独特の商習慣ではありません。
世界中で行われています。

米国の航空宇宙科学ソフトウェア開発でも、米国企業の社内システム
開発でも、中国やインドへのオフショア開発でも、人月による見積もり
は行われています。

もちろん、他にも様々な見積もり手法があります。
ファンクションポイント法、画面や帳票などの入出力数などです。
しかし、いずれの方法であっても、最終的には「人月」としてまとめ
られます。


ブルックスは「人月の神話」の中で、「人月」を生産性の尺度としては
「疑うべき危険な神話」だとしていますが、コストを「人月」で計算する
ことを否定しているわけではありません。

> コストは実際に人数と月数の積に比例する。が、進捗はそうではない。
> 　　　　　　　　　　　　　（ブルックス著「人月の神話」より）


また、「人月の神話」は30年以上にわたって世界中の学者・技術者
によって研究され、多くの論文が書かれています。
その中の一部の内容が、「人月の神話　二十周年記念増訂版」で紹介
されていますが、コストを人月で計算すること自体を否定している
ものはありません。


近年のPMBOK、CMM、ISO9001でも人月による見積もりについて否定的では
ないと思います。（この部分はまだ調べていませんが・・・。）



*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
  [ブルックスの法則]　要員の最大数は独立したサブタスクの数に依存する
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

ソフトウェア請負開発を人月で見積もる理由は、ソフトウェア開発が
次のような性質を持つからです。

> プロジェクトの月数は順次的制約に依存している。
> そして、要員の最大数は独立したサブタスクの数に依存する。
> 　　　　　　　　　　　　　（ブルックス著「人月の神話」より）


第122号の架空のプロジェクトでは、技術者による当初の見積もりは
「3人が作業して4ヶ月」でした。
( http://www.kei-it.com/sailing/122-060410.html　参照 )

第122号では、ストーリー展開の都合上、その見積もりが誤っていた
ことにしました。
しかし、もしも、その見積もりが正しかったとすると次のようなことが
言えます。

それは、文言どおり「3人が作業して4ヶ月」であり、「4人が作業して3ヶ月」
ではないのです。

つまり、彼が「3人」と指定してきたということは、サブタスクの数が
丁度3つに分けやすいということです。
それを無理に4つに分けても期間は短縮できません。



*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
  [ブルックスの法則]　プロジェクトの月数は順次的制約に依存する
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

また、彼が「4ヶ月」と指定してきたということは、ソフトウェア開発
作業の順次的制約から来るものです。

もちろん、個々の作業で見ると、プログラマによる能力差は、著しい
ものがあります。
しかし、要件定義からリリースまでに至るソフトウェア開発作業は、
様々な作業の連鎖です。

> 大規模プログラム開発は多くの仕事から構成されており、その内
> いくつかは最初から最後まで連鎖している。
> 　　　　　　　　　　　　　（ブルックス著「人月の神話」より）


ソフトウェア開発作業が複数の人が関わる連鎖した作業である以上、
超優秀な技術者でも、最低これだけはかかるという期間があるのです。

ウォーターフォール開発プロセスの場合、ソフトウェア開発作業が
順次的性質を持つことは直感的に理解できますが、漸増的開発プロセス
の場合、それが少し分かりにくくなっています。
しかし、漸増的開発プロセスには漸増的開発プロセスなりの手順が
あり、やはり順次的性質を持っているのです。

（第66号「漸増的開発、失敗のシナリオ」
http://www.kei-it.com/sailing/66-050314.html　参照）


したがって、たとえ、運良くサブタスクをうまく4つに分解できた
としても、個々のサブタスクにかかる月数が以前よりも短くなるとは
限りません。
「4人が作業して3ヶ月」になるのではなく、「4人が作業して4ヶ月」
になる可能性の方が高いのです。



*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
  [ブルックスの法則]　人は時間に余裕があると、ますます時間をかける
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

サブタスクの数が人数を決め、ソフトウェア開発作業の順次的性質が
月数を決めた結果として、最適な見積もりが「3人が作業して4ヶ月」
だったとしましょう。


そして、ここで営業が顧客に「3人が作業して5ヶ月」という見積もりを
提出し、余分な3人×1ヶ月をそのまま会社の利益にしようとしたとします。

首尾よく見積もりが通った場合、営業は社内の技術者にはそのことを
隠さなくてはなりません。
さもなければ、本当に「3人が作業して5ヶ月」かかってしまうからです。


> コスト曲線は、計画されたスケジュールが最適のものより長くなるに
> つれ上昇する。人は時間に余裕があると、ますます時間をかけるものだ。
> 　　　　　　　　　　　　　（ブルックス著「人月の神話」より）



*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
  [ブルックスの法則]　期間を短縮するとコスト曲線は急上昇する
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

もしも営業が、総額を増やす見返りとして期間を短縮する見積もりを
出して、仕事を取ったらどうなるでしょうか。

例えば「5人が作業して3ヶ月」という見積もりにしたら、
「5人×3ヶ月＝15ヶ月」なので、もとの「3人×4ヶ月＝12ヶ月」よりも
総額では3ヶ月増えています。
1ヶ月の期間短縮というサービスの代わりに・・・。

営業がこれで会社に貢献したと思ったら大間違いです。
悲惨な結果が待っています。

> コスト曲線は、計画されたスケジュールが最適のものより短くなると
> 急上昇する。
> 投入された要員の人数には関係なく、計算された最適スケジュールの
> 四分の三より短い時間内で成功したプロジェクトはほとんどない！
> 　　　　　　　　　　　　　（ブルックス著「人月の神話」より）




*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
  次回以降の予告
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

今週号では、見積もりについての基本的な考え方についてお話ししました。

実際の業務では、基本から少しはずれて、無理をしなければならない
ことは多いでしょう。

しかし、基本を知った上ではずれるのと、知らずにはずれるのとでは
大きな違いがあります。


次回以降で、次の方向で考察を続けます。

・オープンソース運動の理論的指導者であるレイモンド氏が、
　ブルックスの法則に反して「頭数は一つよりは多いほうが絶対にいい」
　と主張している理由。



また、次号以降では次のようなテーマも取りげていきます。

技術系：
・OSS（贈与と交換、ピアレビュー）
・SEO対策
・WEB2.0
・メーカからの請負、エンドユーザからの請負
　（品質管理、検収、瑕疵担保責任の違い）
・グーグルの衝撃
・PMBOK

外国系：
・中国は脅威か？

法務系：
・コンプライアンス
・ボード（取締役会）の重要性

労務系：
・雇用契約、裁量労働制、個人事業主


次号は、4月24日発行予定です。

乞うご期待！！



*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
  本メルマガについて
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

本メルマガは2003年12月8日に創刊されました。
創刊号 http://www.kei-it.com/sailing/01-031208.html で述べたとおり、
本メルマガのコンセプトは「読みものとしても面白い慶の事業計画」であり、
目的は「事業計画の背後にある基本的な考え方を語ること」です。

したがって、第一の読者としては、慶の社員（正社員・契約社員）及び
慶と契約している個人事業主を想定しています。
彼らには慶社内のメーリングリストで配信しています。

また、多くのソフトウェア会社・技術者が直面している問題を扱っているので、
ソフトウェア会社の経営者、管理者、技術者にとっても参考になると思い、
第33号(2004年7月19日号)からは「まぐまぐ！」で一般の方々にも公開する
ことにしました。
「まぐまぐ！」での読者数は2006年3月27日現在、472名です。


本メルマガの内容に興味を持つであろう方をご存知なら、是非
本メルマガの存在を教えてあげてください。

（以下をそのまま転送するだけです。）
---------------------------------------------------
【お勧めメルマガ　ソフトウェア業界　新航海術】
⇒ http://www.mag2.com/m/0000136030.htm　または
 　http://www.kei-it.com/sailing/　
--------------------------------------------------

このメールマガジンは『まぐまぐ！』 http://www.mag2.com/ を利用して
発行しています。配信中止はこちら http://www.mag2.com/m/0000136030.htm
（但し、web@kei-ha.co.jp it@kei-it.com には直接配信しています。）

発行者Webサイト: http://www.kei-it.com/sailing/
（発行者Webサイトではバックナンバーの全文検索も可能です。）

バックナンバーはブログでも公開しています。
ブログ：　http://kei-it.tea-nifty.com/sailing/


--------------------------------------------------

「厳選！優良案件情報ブログ」では、エンドユーザ直、持ち帰り可、
高単価案件を掲載しています。
もしも興味をお持ちの案件がありましたら、ご一報ください。
URL：http://kei-it.tea-nifty.com/gensen/
ID：gensen
パスワード：gensen

--------------------------------------------------
発行：
株式会社 慶
　代表取締役  蒲生 嘉達
　y_gamou@kei-ha.co.jp
　Webシステム開発事業部　http://www.kei-ha.co.jp
　ITサービス事業部　http://www.kei-it.com
　人材コンサルティング事業部　http://www.k-bank.jp
　TEL：03-5951-8490

☆　コピーや配布をされる時はご一報ください　☆
☆　このメルマガに対するご感想・ご質問はこちらにお寄せください。　☆
　　　　　　　　　　　 office@kei-ha.co.jp