**************************************************************
_/_/_/_/_/_/_/  ソフトウェア業界　新航海術  _/_/_/_/_/_/_/_/_/
**************************************************************
第122号  2006/4/10
  ▼  まえがき
  ▼  [ブルックスの法則]　当初のスケジュール
  ▼  [ブルックスの法則]　マイルストーンＡで1ヶ月遅れが発生
  ▼  [ブルックスの法則]　第1回の要員追加
  ▼  [ブルックスの法則]　2名追加したが、遅れは全く変わらなかった
  ▼  [ブルックスの法則]　もとの見積もりになかった仕事が増えたから
  ▼  [ブルックスの法則]　そしてデスマーチへと突入する
  ▼  [ブルックスの法則]　ケース２だともっと恐ろしいことが起こる
  ▼  次回以降の予告


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

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

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

今週号では、架空のプロジェクトを例にして、ブルックスの法則が
成立してしまう仕組みを明らかにします。
（「人月の神話」に出てくる例に少し肉付けをしました。）


先週号はテキスト文だけで表現しましたが、今週号は図を使って
説明します。
下記URLを参照しながら読んでください。
http://www.kei-it.com/sailing/img/mm0410.html



*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
  [ブルックスの法則]　当初のスケジュール
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

昨年12月、あるソフトウェア会社に顧客から「社内で使用する販売管理
システムの開発をお願いしたいのだが・・・」という打診がありました。

そこには「新しい販売販売管理システムは6月から稼動させたいので、
システムテストが完了した製品を5月1日までに納品してください」
という条件が付いていました。

ソフトウェア会社のマネージャが技術者に見積もりをさせたところ、
「3人が作業して4ヶ月かかります」という報告が上がってきたので、
マネージャは3人の技術者を確保し、Ｂ社からの仕事を受注しました。

そのときマネージャが想定したスケジュールは、
「図１：当初のスケジュール」
( http://www.kei-it.com/sailing/img/mm0410.html#1 参照)のような
ものでした。

1月から3人を投入し、マイルストーンＡ、Ｂ，Ｃ，Ｄがそれぞれ
1月末、2月末、3月末、4月末に来るようにスケジュールされていました。
マイルストーンＤはシステムテスト完了です。



*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
  [ブルックスの法則]　マイルストーンＡで1ヶ月遅れが発生
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

ところが、2月末時点でマネージャは、「マイルストーンＡの到達が
1月末ではなく、2月末になってしまいました」という報告を受けました。

最初のマイルストーンＡで1ヶ月遅れが発生してしまったのです。

この場合、次の二つのケースが考えられます。

ケース１：マイルストーンＡまでの見積もりのみが甘かった。
( http://www.kei-it.com/sailing/img/mm0410.html#21 参照 )

ケース２：マイルストーンＡ、Ｂ、Ｃ、Ｄまでの全ての見積もりが甘かった。
( http://www.kei-it.com/sailing/img/mm0410.html#22 参照 )


ケース１なら、単にマイルストーンＡまでの見積もりが甘かった
だけなので、マイルストーンＢ、Ｃ、Ｄまでは、当初の想定どおり、
それぞれ1ヶ月ずつかかります。
したがって、このまま行くと、マイルストーンＤに到達するのは
5月末となってしまいます。

一方、ケース２なら、マイルストーンＤに到達するのは8月末となって
しまいます。


今回はケース１だったとして、考察を進めましょう。



*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
  [ブルックスの法則]　第1回の要員追加
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

ケース１だったとしても、5月1日という納期は守れません。

「図２−１：２月末時点での進捗と予想(ケース１)」を見たマネージャは、
「図３：３月からの要員追加」に示されるような要員追加を考えました。
( http://www.kei-it.com/sailing/img/mm0410.html#3 参照)

「図２−１：２月末時点での進捗と予想(ケース１)」では3月から5月
までの作業量は9人月でした。
それを、3月と4月の2ヶ月でこなすためには、4.5名が必要
（4.5名×2ヶ月＝9人月）なので、2名が新たに投入されました。


マイルストーンＢ、Ｃ、Ｄには、それぞれ3月20日、4月10日、4月末に
到達できるはずでした。



*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
  [ブルックスの法則]　2名追加したが、遅れは全く変わらなかった
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

しかし、3月末時点で現場から上がってきた報告「図４：３月末時点での
進捗と予想」( http://www.kei-it.com/sailing/img/mm0410.html#4 )を
見てマネージャは驚きました。

それは、次のようなことを示していたからです。

・3月から2名新たに投入したのに、まだマイルストーンＢに到達していない。
・このまま行くとマイルストーンＤ到達は5月末になる。

「図２−１：２月末時点での進捗と予想(ケース１)」での予想も、
「このまま行くとマイルストーンＤに到達するのが5月末となってしまう」
でした。

つまり、3月から2名新たに投入したのに、遅れ具合は全く変わって
いないのです。

何故このようなことが起きたのでしょうか？



*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
  [ブルックスの法則]　もとの見積もりになかった仕事が増えたから
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

3月以降の仕事量は、「図２−１：２月末時点での進捗と予想」では
9人月だったのに、「図３：３月末時点での進捗と予想」では14人月に
増えています。

2名新たに投入したために、もとの見積もりになかった仕事が増えて
しまったのです。

人が増えると仕事が増える理由は、システム開発という仕事が、下記の
二つの性格を持つ仕事だからです。

・順次的な故に分割不可能な仕事
・分担はできるがサブタスク間でのコミュニケーションが必要な仕事
(第121号　http://www.kei-it.com/sailing/121-060403.html　参照）


新たに投入される技術者がいかに優秀な技術者であっても、ある程度は、
教育・訓練が必要です。
そして、教育・訓練が終了した後も、相互コミュニケーションの負担は
3名よりも5名の方が増えます。

また、もともと3つに分けられていた仕事を5つに分け直さなければならず、
すでに完了している仕事で無駄になるものも出てくる上、システムテスト
に要する時間もより長くなってしまいます。



*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
  [ブルックスの法則]　そしてデスマーチへと突入する
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

しかし、5月1日という納期は守らなければならないので、マネージャは
さらに「図４：４月からの要員追加」
( http://www.kei-it.com/sailing/img/mm0410.html#5 )
のような要員追加をしました。

マネージャは、「図３：３月末時点での進捗と予想」で残っている9人月の
作業を4月1ヶ月で終わらせるためには、9名（9名×1ヶ月＝9人月）が
必要だと考えたのです。
その結果、さらに4名が追加され、総勢9名のプロジェクトになりました。


この「図４：４月からの要員追加」まで来ると、読者も、この
プロジェクトが絶対に納期を守れないデスマーチに入ったということを
直感的に理解できるでしょう。

複雑な相互関連を持つ仕事、つまり、要員を追加すればするほど
遅れていく仕事に変質してしまったのです。
(第121号（４）複雑な相互関連を持つ仕事」
http://www.kei-it.com/sailing/121-060403.html　参照）



*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
  [ブルックスの法則]　ケース２だともっと恐ろしいことが起こる
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

上記考察は「図２−１：２月末時点での進捗と予想(ケース１)」を
前提にしていました。
もしも「図２−２：２月末時点での進捗と予想(ケース２)」だったら、
もっと恐ろしいことが起こります。

マネージャは、3月からの要員追加を2名ではなく6名にしたでしょう。
3月以降に残された作業が18人月、それを3月と4月の2ヶ月で割ると
1ヶ月9人必要だからです。

ケース１よりも、はるかに早い時期にデスマーチが始まります。



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

今週号の話は、他業界にいる人にとっては、まるで戯画のような話
だったと思います。

しかし、今回の話は誇張しているわけでも、特殊な例でもありません。
ソフトウェア業界では、ごくごく日常茶飯事に行われていることなのです。

しかも、日本だけでなく、世界中で、30年以上も同じことが繰り返され
ているのです。



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

・レイモンド氏が「頭数は一つよりは多いほうが絶対にいい」と主張
　している理由。

・「人月による見積もりをしているのは日本だけで、それが日本の
　ソフトウェア業界をダメにしている」という意見には、私は反対します。



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

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

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

法務系：
・コンプライアンス

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


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

乞うご期待！！



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

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

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

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


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

（以下をそのまま転送するだけです。）
---------------------------------------------------
【お勧めメルマガ　ソフトウェア業界　新航海術】
⇒ 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