**************************************************************
_/_/_/_/_/_/_/  ソフトウェア業界　新航海術  _/_/_/_/_/_/_/_/_/
**************************************************************
第124号  2006/4/24
  ▼  まえがき
  ▼  [ブルックスの法則]　ブルックスの法則の妥当性についての議論がない
  ▼  [ブルックスの法則]　遅れてしまった場合の対策は？
  ▼  [ブルックスの法則]　ソフトウェア開発一般について困ること
  ▼  [ブルックスの法則]　マイクロソフトの「ブルックスの法則」対策
  ▼  次回以降の予告


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

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

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


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

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


ブルックスの法則は、英文だと、
「Brooks's Law：Adding manpower to a late software project makes it later.」
です。



*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
  [ブルックスの法則]　ブルックスの法則の妥当性についての議論がない
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

「ブルックスの法則」についての言及は、コンピュータ雑誌や技術者・
学者のホームページでしばしば見かけます。

しかし、私は、それらの中で「ブルックスの法則が本当に正しいのか」
という議論が行われているのを見たことがありません。

技術者も学者も、「ブルックスの法則は正しい」ということを前提にして
記事を書いています。


（例１）
　ブルックスの法則：
　不勉強で現場認識の甘い脳天気な経営者と管理職の連中は知らないが、
　現場で修羅場を経験したことのある人間なら誰しも知っている、
　「遅れているソフトウェアプロジェクトへの要員追加はさらに遅らせるだけ」
　という至極当たり前のことを述べたもの。
　（真・コンピュータ用語辞典
　　http://glossary.tank.jp/t0C42.html　）

（例２）
　みずほ銀行のシステム統合における不具合の問題は、まさに「人月の神話」
　の最近におけるまごうことなき証明だ。
　（慶應義塾大学　國領研究室のホームページ 
　　http://www.jkokuryo.com/class/sentan2004/Brooks/oda.htm　）



*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
  [ブルックスの法則]　遅れてしまった場合の対策は？
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

しかし、ブルックスの法則が成り立ってしまうということは、本来、
ソフトウェアを開発する側にとってみては、困ることのはずです。


第120号「遅れが生じた場合の有効な対策は？」
 http://www.kei-it.com/sailing/120-060327.html で、私は次の指摘を
しました。

> もしもブルックスの法則が正しいとすると、プロジェクトに遅れが
> 生じた場合、次の二つしか対策がないことになります。
> 
> (1)要員追加はせず、スケジュールを立て直す。
> 　（新しいスケジュールではたっぷり時間をとる。）
> 
> (2)要員追加はせず、仕事を縮小する。
> 


遅れてしまった場合の対策は、納期を遅らせるか、機能縮小しかない
のでしょうか？



*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
  [ブルックスの法則]　ソフトウェア開発一般について困ること
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

しかし、それだけではありません。

ブルックスの法則は一言で述べると、「遅れているソフトウェア
プロジェクトへの要員追加はさらに遅らせるだけだ」ですが、
もう少し長く述べると、次のようになります。


○ソフトウェア構築は、本来、下記の二つの性格を持っている。

　(1)順次的に連続していて分担できない仕事。
　　→人をいくら追加しても完了時期は変化しない。

　(2)複雑な相互関係における作業の遂行。
　　→仕事の各部分がそれ以外の部分と個別に調整されなければなら
　　　ないから、そのための労力は、開発者数の 2 乗で増大する。

○したがって、要員を追加することが、スケジュールを長引かすことは
　あっても、短くすることはないのである。

（第121号「順次的であり、且つ、相互関連を持つ」
http://www.kei-it.com/sailing/121-060403.html 参照）


つまり、ブルックスの法則は、必ずしも遅れているプロジェクトに
ついてだけの法則ではありません。
ソフトウェア開発一般についての次のようなことを言っているのです。

「作成するソフトウェアが複雑になればなるほど、要員追加の効果が
逓減し、コストのみ高騰し、スケジュールは遅延する。」



*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
  [ブルックスの法則]　マイクロソフトの「ブルックスの法則」対策
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

ソフトウェアが年々、高度化し複雑化するにもかかわらず、このような
法則が成り立ってしまっては、ソフトウェア会社は困ってしまいます。

とりわけ、Windows、MS-Office、IEのような超巨大ソフトウェア製品群を
開発しなければならないマイクロソフトにとって、ブルックスの法則は
深刻な問題でした。

元マイクロソフト社員が書いた下記のページを読むと、マイクロソフトが
ブルックスの法則についていかに真剣に考えていたかが分かります。

http://japanese.joelonsoftware.com/PainlessSpecs/3.html
(ジョエル・スポルスキ「やさしい機能仕様-パート3」)

ジョエル・スポルスキ氏によれば、マイクロソフトは下記の二つの
方法で、ブルックスの法則を乗り越えたそうです。


（１）プログラムマネージャ

ジョエル・スポルスキ氏によれば、マイクロソフトでは、プログラム
マネージャ（プロジェクトマネージャではない）は製品のデザインと
仕様に専念し、プログラマは正しいコードを書くことに専念するそうです。
通常プログラムマネージャ1人にプログラマが5人いるそうです。
プログラマはプログラムマネージャとだけコミュニケーション
すればよいので、コミュニケーション量の増加はO(n2)ではなくO(n)に
なるから、ブルックスの法則を乗り越えられるという理屈です。


（２）優秀な人を集める

しかし、ジョエル・スポルスキ氏はプログラムマネージャ制度を
高く評価する一方で、優秀な人を集めることが一番重要だとも言って
います。

「結局Microsoftは人月の神話がどうであれ、頭のいい人々をチームに
追加すれば、限界価値は逓減するにしても出力を増加できるという
ことを発見した。私がいたころExcelチームには50人のプログラマがいたが、
25人のチームよりは生産的であっただろう。2倍とはいかないが。」
（ジョエル・スポルスキ氏）



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

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

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



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

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

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

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

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


次号は、5月1日発行予定です。

乞うご期待！！



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

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

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

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


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

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