**************************************************************
_/_/_/_/_/_/_/  ソフトウェア業界　新航海術  _/_/_/_/_/_/_/_/_/
**************************************************************
第128号  2006/5/22
  ▼  まえがき
  ▼  [ブルックスの法則]　「人月の神話」は13ページの短いエッセイ
  ▼  [ブルックスの法則]　そう簡単には解決することができない問題
  ▼  [ブルックスの法則]　初期段階で協調性のある人を追加する
  ▼  [ブルックスの法則]　コードを私物化せず、みんなでデバッグする
  ▼  [ブルックスの法則]　レイモンドによる「ブルックスの法則」の否定
  ▼  [ブルックスの法則]　リーヌスの法則
  ▼  次回以降の予告


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

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

第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.



*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
  [ブルックスの法則]　「人月の神話」は13ページの短いエッセイ
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

「人月の神話」の原題は、「The Mythical man-month : essays on 
software engineering」です。

長大な学術的論文ではなく、15章(二十周年記念増訂版では19章に
増えています)からなるエッセイ集です。

その中の第2章が「人月の神話」であり、それは日本語訳された本で
13ページに過ぎない短いエッセイです。

そこで言われていることは、要約すれば次のようなことです。

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

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

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

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

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

詳しくは、第121号、第122号を参照してください。
第121号　http://www.kei-it.com/sailing/121-060403.html
第122号　http://www.kei-it.com/sailing/122-060410.html


*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
  [ブルックスの法則]　そう簡単には解決することができない問題
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

30年前にかかれたこの短いエッセイが、なぜ今でも話題になるの
でしょうか。

それは、ここでブルックスが指摘した問題がソフトウェア開発と
いうものの本性から発生する宿命的とも言える問題だからです。
そう簡単には解決することができない問題なのです。

この問題のためにこれまでに提起されてきた解決策を列記して、
「ブルックスの法則シリーズ」は終了とします。



*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
  [ブルックスの法則]　初期段階で協調性のある人を追加する
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

下記の二つは、他の学者の意見で、ブルックス自身が「人月の神話
　二十周年記念増訂版」で紹介しているものです。

（１）初期段階での要員追加

> スケジュールの初期段階で要員を追加することは、後から追加する
> よりはるかに安全な戦術だ。（アブデル・ハミッド、マドニック）

（２）協調性のある人を追加する

> 開発プロジェクトに後から追加される新要員は、チームプレイヤー
> としてプロジェクトの中に勢いよく飛び込んで仕事をしようとする
> 意欲の持ち主でなければならず、工程自体を変更または改善しようと
> する人ではいけない。（R.D.ストツク）


両方とも今でも通用する極めて実際的なアドバイスです。
ブルックスもこれらを「要員追加による破壊的影響を最低限に
とどめるためのアドバイス」と評価しています。



（３）頭のいい人々をチームに追加する

この解決策については、第124号「マイクロソフトの「ブルックスの法則」
対策」( http://www.kei-it.com/sailing/124-060424.html )を参照
してください。


*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
  [ブルックスの法則]　コードを私物化せず、みんなでデバッグする
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

（４）コードを私物化せず、みんなでデバッグする

> 「エゴのないプログラミング」を論じるなかでワインバーグが述
> べたのは、開発者たちが自分のコードを私物化せず、ほかのみんなに
> バグを探したり改良点を見つけたりするよう奨励するようなところでは、
> ソフトの改善がほかよりも劇的にはやく生じる、ということだった。
> 　　　　　　　　　（レイモンド著「伽藍とバザール」より）


オープンソースとは、ワインバーグが主張する「エゴのないプログラ
ミング」を、インターネットを介して、世界的な規模で行おうという
ものだと言ってもよいでしょう。


*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
  [ブルックスの法則]　レイモンドによる「ブルックスの法則」の否定
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

（４）オープンソース

上述のとおり、ブルックスの法則が成立する理由は、ソフトウェア
構築というものが本来次の二つの性格を持っているからです。

(A)順次的に連続していて分担できない仕事。
(B)複雑な相互関係における作業の遂行。


レイモンド氏は「伽藍とバザール」の中で、少なくともベータテスト
以降については、この二つを真っ向から否定しています。


(A)順次的に連続していて分担できない仕事ではない。

> 実際問題として、デバッガたちの作業重複によって生じる理論的な
> 無駄は、Linux の世界ではほとんど問題にされないようだ。
> 「はやめしょっちゅうのリリース」の効果の一つとして、すでに
> フィードバック済みのバグフィックスをすばやく広めることで
> そういう重複をなくせるということがある。
> 　　　　　　　　　（レイモンド著「伽藍とバザール」より）


(B)複雑な相互関係における作業の遂行ではない。

> デバッグするにはデバッガは開発コーディネータと多少のやりとりは
> 必要だけれど、デバッガ同士では大した調整は必要ない。だから、
> 開発者を加えることで発生する、幾何級数的な複雑性と管理コスト
> 増大という問題には直面しないですむというわけだ。
> 　　　　　　　　　（レイモンド著「伽藍とバザール」より）


*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
  [ブルックスの法則]　リーヌスの法則
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

そして、レイモンド氏は新たに下記を「リーヌスの法則」と呼びます。
（リーヌスとは、Linuxを作ったリーヌス・トーヴァルド氏のことです。）

「ベータテスタと共同開発者の基盤さえ十分大きければ、ほとんど
すべての問題はすぐに見つけだされて、その直し方もだれかには
すぐわかるはず。 」

私は、第126号でソフトウェア開発の半分はテストだと指摘しました。
( http://www.kei-it.com/sailing/126-060508.html　参照 )

しかし、パッケージ製品やオープンソース製品の場合には、ベータ
テストにかける時間が、請負開発の場合よりもはるかに大きいので、
開発におけるテストの割合は半分ではきかないでしょう。


> 開発モードが高速なやりとりに基づくものになっていると、開発と
> 拡張はデバッグの特殊なケースになってくる。
> 　　　　　　　　　　　　　　　（「伽藍とバザール」より）

ベータテストの結果発生する拡張までも含めると、ベータテストだけ
でも開発全体の80%位を占めるのではないでしょうか？

このベータテストが高速化するなら(LinuxやApacheのような成功例では
本当にそうなっています）、確かにオープンソースは人月の神話問題を
超えたと言えるでしょう。

オープンソースについては書き残したことが多々ありますが、それは
別のシリーズで書きます。



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

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

技術系：
・OSS（オープンソースを持ち上げる人々、オープンソースの実態）
・Linux台頭とSUN
・SEO対策
・メーカからの請負、エンドユーザからの請負
　（品質管理、検収、瑕疵担保責任の違い）
・グーグルの衝撃
　（本を読むこと、ネットで読むこと）
・オブジェクト指向再論
・PMBOK

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

法務系：
・コンプライアンス
・取締役と執行役員

労務系：
・雇用契約、裁量労働制、個人事業主
・景気回復、新卒の採用難、2007年問題

営業系：
・売れる営業マン


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

乞うご期待！！



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

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

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

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


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

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