ソフトウェア業界　新航海術　

**************************************************************
_/_/_/_/_/_/_/ ソフトウェア業界　新航海術 _/_/_/_/_/_/_/_/_/
**************************************************************
第195号 2007/11/25
▼ まえがき
▼ [ブルックスの法則]　(1)良い製品を生み出す環境
▼ [ブルックスの法則]　(2)共通の理解( common understanding )
▼ [ブルックスの法則]　(3)コンセンサスを得る( build consensus )
▼ [ブルックスの法則]　(4)「共通の理解/コンセンサス/納得」が大前提
▼ [ブルックスの法則]　(5)基礎知識レベルで共通の認識を
▼ 次回以降の予告

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

蒲生嘉達です。

「ソフト会社の心臓」出版計画は下記のスケジュールで進んでいます。

　11月9日(金)　 初校出し → 校正
　11月25日(月)　初校戻り
　12月7日(金)　 再校出し → 校正
　12月25日(月)　再校戻り
　1月11日(金)　 校了
　1月18日(金)　 印刷所入稿
　2月4日(月）　 見本日
　2月12日(火)　 取次搬入

ここのところ休日は、息子と釣に行く以外は、校正に時間を費や
しています。

さて、今回は1年3ヶ月ぶりのブルックスの法則シリーズです。

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[ブルックスの法則]　(1)良い製品を生み出す環境
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

第132号「オープンでもクローズドでも良い製品を生み出す環境は似ている」
( http://kei-it.tea-nifty.com/sailing/2006/06/post_8949.html )で
次のように述べました。

-----------------（引用始め）---------------------------

一般には、オープンソース陣営とマイクロソフトは、正反対のアプ
ローチを採用していると思われています。

しかし、ジョエル・スポルスキ氏が描くマイクロソフトのプログラム
マネージャ像とエリック・レイモンド氏が描くオープンソース
プロジェクトのコーディネータ/リーダ像とは、非常に似ていることに
気づきます。

両者ともに、製品のデザインと仕様を所有しますが、プログラマに
対する指揮命令権は持っていません。

彼らのリーダーシップの源泉は、権力関係ではなく、共通の理解、
コンセンサス、納得なのです。

ジョエル・スポルスキ氏、エリック・レイモンド氏ともに、権力関係
によるリーダーシップは良い製品を生み出さないと主張しています。

オープンソースであろうとクローズドソースであろうと、知的創造物を
作り出すプロジェクトで成功するためには、同じような仕組みが必要だ
ということなのでしょう。

メンバーの自由な創造と、「共通の理解」がセットで存在すること。
そして、それを実現するために、冒頭の(1)～(4)で示したような、
対人能力やコミュニケーション能力に優れたリーダが存在すること。

-----------------（引用終わり）---------------------------

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[ブルックスの法則]　(2)共通の理解( common understanding )
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

「共通の理解、コンセンサス、納得」についてもう少し考えるために、
「伽藍とバザール」、「ジュエル・オン・ソフトウェア」でそれら
について書かれている部分を原文で読んでみましょう。

下記はエリック・レイモンドが「伽藍とバザール」で引用している
クロポトキンの「ある革命家の回想」の中の一文です。

原文で読みたくなる部分は原文を埋め込んでいます。

------------------------------------
農奴を所有する一家に育ったわたしは、当時の若者たちみんなと
同じように、命令したり指令したり、叱りつけたり罰したりといった
行動の必要性について、まったく疑うことを知らぬままに成年に達した。
しかしかなりはやい時期に、わたしは大がかりな企業を経営すること
になり、自由な人々と交渉することになった。

そしてまちがい一つが重大な結果を招くような状況で、わたしは命令と
規律という原理にしたがって活動するのと、共通の理解という原理に
基づいて行動するのとの差をだんだん理解するに至った。

When each mistake would lead at once to heavy consequences,
I began to appreciate the difference between acting on the
principle of command and discipline and acting on the principle
of common understanding.

前者は軍隊のパレードでは見事に機能するが、実生活において、
目標が多くの重なり合う意志の真剣な努力によってしか達成できない
ような状況では何の価値もない。

The former works admirably in a military parade, but it is
worth nothing where real life is concerned, and the aim can be
achieved only through the severe effort of many converging wills.

　「伽藍とバザール」原文：
　http://www.catb.org/%7Eesr/writings/homesteading/cathedral-bazaar/index.html

　「伽藍とバザール」翻訳：
　http://cruel.org/freeware/cathedral.html

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[ブルックスの法則]　(3)コンセンサスを得る( build consensus )
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

次は「ジュエル・オン・ソフトウェア」です。
原文で読みたくなる部分は原文を埋め込んでいます。

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

Microsoftのプログラムマネージャとして、私はExcelのVisual Basic
(VBA)ストラテジーをデザインし、VBAをExcelにどのように実装すべきか、
微細な詳細にいたるまで完全に仕様化した。
私の仕様書は500ページに及んだ。
Excel 5.0の開発の高みから私の見積ったところでは、毎朝250人の
人々が働きに出て来て、私の書いた巨大な仕様に関わる作業をしていた。

　　　　　・・・（中略）・・・・

奇妙なのは、私が職階の「最下層」にいたということだ。
そう、私には部下は誰もいなかった。
私が誰かに何かしてもらいたいと思ったら、それをするのが正しいと
いうことを納得させる必要があった。

The weird thing was that I was at the "bottom" of the reporting tree.
That's right. NOBODY reported to me.
If I wanted people to do something, I had to convince them that
it was the right thing to do.

　　　　　・・・（中略）・・・・

もしこれらの人々の誰かが私の部下であったなら、製品はそんなに
良いものとはならなかっただろう。

If any of these people had reported to me, the product wouldn't
have been as good.

彼らのあるものは上司にとやかく言うのはまずいと思うかもしれない。
あるいは、私がうぬぼれや近視眼のために、私のやり方でやるように
断固として命令していたかもしれない。

実際にはコンセンサスを得る以外には私に選択肢はなかった。
このような意思決定形式が、正しいことが行われるようにするための
最善の方法だった。

As it was, I had no choice but to build consensus.
This form of decision making was the best way to get the right
thing done.

　「ジュエル・オン・ソフトウェア」原文：
　http://www.joelonsoftware.com/articles/fog0000000034.html

　「ジュエル・オン・ソフトウェア」翻訳：
　http://japanese.joelonsoftware.com/PainlessSpecs/3.html

　第125号：マイクロソフトのプログラムマネージャ
　http://kei-it.tea-nifty.com/sailing/2006/05/post_a4c0.html

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[ブルックスの法則]　(4)「共通の理解/コンセンサス/納得」が大前提
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

ジョエル・スポルスキ氏は、「ジュエル・オン・ソフトウェア」の別の
箇所で、ブルックスの法則を打ち破るためには優秀な人を集めることが
一番重要だとも言っています。

　第124号：マイクロソフトの『ブルックスの法則』対策
　http://kei-it.tea-nifty.com/sailing/2006/04/post_3020.html

また、エリック・レイモンド氏はブルックスの法則を打ち破る
方法としてオープンソースを主張しています。

　第128号：リーヌスの法則
　http://kei-it.tea-nifty.com/sailing/2006/05/post_39f4.html

しかし、「共通の理解、コンセンサス、納得」の重要性を強調して
いるところは二人に共通しています。

優秀な人を雇う作戦で行くにしても、オープンソース作戦で行くに
しても、それがうまく機能するためには下記のことが不可欠なのです。

・共通の理解という原理に基づいて行動すること
　( acting on the principle of common understanding )

・コンセンサスを得ること
　( to build consensus )

・それをするのが正しいということを納得させること
　( to convince them that it was the right thing to do )

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[ブルックスの法則]　(5)基礎知識レベルで共通の認識を
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

「共通の理解、コンセンサス、納得」が「命令、規律」以上に重要
であるということは、システム開発においてだけではありません。

これらは、会社にとって、様々な組織にとって、そしてあらゆる
人間関係にとって、うまく機能するための基盤となるものです。

私はメルマガや出版物で、社内、社外に対し、基礎知識レベルで
共通の認識を作り出していきたいと考えています。

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

次回発行予定は、12月初旬です。

乞うご期待！！

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

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

したがって、第一の読者としては、慶の社員（正社員・契約社員）及び
慶と契約している個人事業主を想定しています。

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

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

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

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

バックナンバーは、発行者サイトまたはブログで、体系として
見てもらいたいので、「まぐまぐ！」でのバックナンバー公開は
最新号のみとなっています。

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

☆筆者の趣味のブログ：身近にいる小動物の図鑑☆
　http://kei-it.tea-nifty.com/small/

--------------------------------------------------
発行：
株式会社 慶
　代表取締役 蒲生 嘉達

**************************************************************
_/_/_/_/_/_/_/ ソフトウェア業界　新航海術 _/_/_/_/_/_/_/_/_/
**************************************************************
第132号 2006/6/19
▼ まえがき
▼ [ブルックスの法則]　オープンソースプロジェクトのリーダの資質
▼ [ブルックスの法則]　オープンソースプロジェクトの実態
▼ [ブルックスの法則]　指揮命令権のないマネージャ
▼ [ブルックスの法則]　命令は良い製品を生み出さない
▼ 次回以降の予告

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

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

今週号では、「ブルックスの法則」シリーズで書ききれなかった
次の二つのことについて書きます。

・オープンソースプロジェクトの実態
・オープンソースプロジェクトのリーダとマイクロソフトのプログラム
　マネージャとが似ていること

「ブルックスの法則」シリーズに分類します。

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

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

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[ブルックスの法則]　オープンソースプロジェクトのリーダの資質
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

エリック・レイモンド氏は「伽藍とバザール」の中でバザールプロ
ジェクト（オープンソースプロジェクトのこと）のコーディネータ
やリーダに必要な資質について、次のように書いています。
(「伽藍とバザール」http://cruel.org/freeware/cathedral.html 参照)

(1)コミュニティ形成を始めるときには、まずなによりも実現でき
　そうな見込みを示せなきゃならない。・・・（中略）・・・
　絶対不可欠なのが、開発者候補たちに、それが目に見える将来には
　なにか本当に使える代物に発展させられると説得できることだ。

(2)デザイン上の才覚に匹敵するほど――あるいはそれ以上――重要な
　ものがあると思う。バザールプロジェクトは、コーディネータや
　リーダの対人能力やコミュニケーション能力が優れていないとダメだ。

(3)絶対に必要なのは、その人物がほかの人たちのよいデザイン上の
　アイデアを認識できるということだ。

(4)バザールモデルが機能するためには、人を魅了する能力が少し
　くらいでもあると、きわめて役に立つのだ。

オープンソースプロジェクトというとオタクっぽいイメージがあり
ますが、それをうまく機能させるためには、コーディネータや
リーダの対人能力、コミュニケーション能力、さらには人間的魅力が
必要なのです。

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[ブルックスの法則]　オープンソースプロジェクトの実態
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

もちろん、一般のソフトウェア会社での請負開発やパッケージ開発
でも、プロジェクトマネージャ、リーダの対人能力、コミュニケー
ション能力は重要です。
しかし、彼らとプログラマとの関係は、上司と部下の関係です。
指示命令関係が最初から存在するのです。

一方、オープンソースプロジェクトのコーディネータやリーダは、
全く指示命令関係のないボランティアを使ってプロジェクトを進めます。

したがって、上記(1)のとおり、実現できそうな見込みを示し、説得
力のある説明ができなければ、プロジェクト自体が立ち上がりません。
また、上記(3)のとおり、ほかの人たちのアイデアを正しく評価し、
受け入れる能力は、プロジェクトを持続させるために必須なのです。

「ソースをオープンにしさえすれば、全世界を才能プールとして使える」
というようなことを書く学者もいます。
しかし、実際には、オープンソースプロジェクトで人を集めることは、
ソフトウェア会社の社内でプロジェクトメンバーを集めるよりも、
ある意味でもっと難しいことなのです。

> オープンソースの作業に使えるボランティアプログラマの才能の
> 量は限られており、それぞれのオープンソースプロジェクトは他の
> オープンソースプロジェクトとこの限られたプログラミングリソース
> をめぐって競っており、最も魅力的なプロジェクトだけが彼らに使える
> 以上のボランティア開発者を獲得するのだ。
>
> （ジョエル・スポルスキ著「ジュエル・オン・ソフトウェア」より）

優秀なコーディネータやリーダに率いられた魅力的なプロジェクトに
技術者が集中し、他の大部分のプロジェクトは技術者が不足している
というのがオープンソースプロジェクトの実態です。

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[ブルックスの法則]　コンセンサスを得る以外には選択肢はなかった
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

さて、下記の文章は誰が何について書いた文章でしょうか？

> もしこれらの人々の誰かが私の部下であったなら、製品はそんなに
> 良いものとはならなかっただろう。
> 彼らのあるものは上司にとやかく言うのはまずいと思うかもしれない。
> あるいは、私がうぬぼれや近視眼のために、私のやり方でやるように
> 断固として命令していたかもしれない。
> 実際にはコンセンサスを得る以外には私に選択肢はなかった。
> このような意思決定形式が、正しいことが行われるようにするための
> 最善の方法だった。

「オープンソースプロジェクトのリーダが、自分が率いたオープン
ソースプロジェクトについて書いた文章だ」と言っても誰も疑わない
でしょう。

しかし、実はこの文章は、マイクロソフトのプログラムマネージャ
経験者（ジョエル・スポルスキ氏）が自分が率いたExcel VBAの開発に
ついて書いた文章なのです。

ジョエル・スポルスキ氏によれば、マイクロソフトのプログラム
マネージャは他のソフトウェア会社にはない独特の概念だそうです。
「製品のデザインと仕様を所有するが、プログラマに対する指揮命令権は
持っていない」という不思議な存在なのです。

詳細は第125号を参照してください。
( http://www.kei-it.com/sailing/125-060501.html　または　
http://kei-it.tea-nifty.com/sailing/2006/05/post_a4c0.html )

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[ブルックスの法則]　命令は良い製品を生み出さない
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

一般には、オープンソース陣営とマイクロソフトは、正反対のアプ
ローチを採用していると思われています。

しかし、ジョエル・スポルスキ氏が描くマイクロソフトのプログラム
マネージャ像とエリック・レイモンド氏が描くオープンソースプ
ロジェクトのコーディネータ/リーダ像とは、非常に似ていることに
気づきます。

両者ともに、製品のデザインと仕様を所有しますが、プログラマに
対する指揮命令権は持っていません。

彼らのリーダーシップの源泉は、権力関係ではなく、共通の理解、
コンセンサス、納得なのです。

ジョエル・スポルスキ氏、エリック・レイモンド氏ともに、権力関係
によるリーダーシップは良い製品を生み出さないと主張しています。

オープンソースであろうとクローズドソースであろうと、知的創造物を
作り出すプロジェクトで成功するためには、同じような仕組みが必要だ
ということなのでしょう。

メンバーの自由な創造と、「共通の理解」がセットで存在すること。
そして、それを実現するために、冒頭の(1)～(4)で示したような、
対人能力やコミュニケーション能力に優れたリーダが存在すること。

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

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

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

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

財務系
・資産と費用

経営系：
・壊れ窓の理論

法務系：
・コンプライアンス
・執行役の裁量の範囲と取締役会の決定権

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

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

次号は、6月26日発行予定です。

乞うご期待！！

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

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

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

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

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

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

**************************************************************
_/_/_/_/_/_/_/ ソフトウェア業界　新航海術 _/_/_/_/_/_/_/_/_/
**************************************************************
第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

**************************************************************
_/_/_/_/_/_/_/ ソフトウェア業界　新航海術 _/_/_/_/_/_/_/_/_/
**************************************************************
第127号 2006/5/15
▼ まえがき
▼ [ブルックスの法則]　オープンソースという大潮流
▼ [ブルックスの法則]　オープンソースと人月の神話問題
▼ [ブルックスの法則]　オープンソースについてあまり語られないこと
▼ [ブルックスの法則]　本メルマガでのオープンソース関連記事
▼ 次回以降の予告

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

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

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

尚、本メルマガで「人月の神話問題」と言った場合は、ソフトウェア開発
一般についての次のような問題を指します。

・ソフトウェア構築は、本来、下記の二つの性格を持っている。
　(1)順次的に連続していて分担できない仕事。
　(2)複雑な相互関係における作業の遂行。
・したがって、要員を追加することが、スケジュールを長引かすことは
　あっても、短くすることはない。

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[ブルックスの法則]　オープンソースという大潮流
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

梅田望夫著「ウェブ進化論」(ちくま新書)によると、グーグルの
システムは全て(OSもDBもミドルウェアも)、オープンソース＋自作
ソフトで構築されているそうです。

同書では、グーグル社チーフ・オペレーションズ・エンジニアのジム・
リース氏の次の言葉を紹介しています。

「数テラバイトのデータ、30億のウェブ上の文書にインデックスをつけ、
毎秒数千リクエストをさばく検索エンジンをいかにして作ったか。
1万台以上のリナックスサーバでできているんだよ。」

「1万台以上」という数字は、2003年春の数字なので、現時点では
さらに増えているでしょう。
梅田望夫氏は、サーバではなくボードで数えると30万台程度接続されて
いると推定しています。

IT業界の今度は、オープンソースを抜きにして語ることはできません。

梅田望夫氏も「ウェブ進化論」の中で、オープンソースを「次の10年
への三大潮流」の一つとしています。（ちなみに、残りの二つは、
「インターネット」と「チープ革命」です。）

> いかにグーグルの技術者が凄くても、オープンソースという大潮流が
> 存在しなければ、情報発電所をゼロベースで作ることはできなかった
> のである。
> 　　　　　　　　　　　　　（梅田望夫著「ウェブ進化論」より）

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[ブルックスの法則]　オープンソースと人月の神話問題
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

日本の多くの学者や技術者がオープンソースを賞賛しています。
しかし、私には、彼らの言説に二つの不満があります。

不満の一つは、人月の神話問題と関連付けて論じられていないという
点です。

今でもオープンソースの教書となっているレイモンド著「伽藍とバザール」
には、「人月の神話」「ブルックスの法則」についての詳細な考察が
あります。

嘘だと思うなら http://cruel.org/freeware/cathedral.html を参照して
ください。
そのページに「伽藍とバザール」の全文が公開されているので、IEの
「このページの検索」機能で「ブルックス」で検索してみてください。
印刷したら35ページ程度の短い論文の中で「ブルックス」が17回も
出てきます。
「伽藍とバザール」の主題は、「オープンソースはブルックスの法則を
超えた」であると言っても過言ではありません。

次号で、人月の神話問題と関連付けてオープンソースを論じます。

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[ブルックスの法則]　オープンソースについてあまり語られないこと
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

もう一つの不満は、日本の多くの学者や技術者によるオープンソース
論はオープンソースの一面しか見ていないということです。

オープンソースに対する批判でよく聞かれるものは次の二つです。

（１）バグは誰が責任を持つのか？
これについては、日本の学者や技術者もよく語ります。

（２）プロのプログラマの商売の邪魔
これについては、公的にはあまり語られませんが、私的な場では
しばしば語られます。

> オープンソースは確かに不思議な魅力を秘めているが、それを苦々
> しく思う人たちも多数存在する。
> たとえばソフトウェア産業のメッカ、シリコンバレーでも、オープン
> ソースの台頭に対し、「じゃあ、俺たちはプロのプログラマーとして
> どうやって住宅ローンを支払っていけばいいんだよ。いちばん
> 難しくて面白いプロの仕事を無償でやって、生計を立てるためには
> やさしいけどつまらない仕事をこなして稼げとでも言うのか」
> みたいな話は今も出続けている。
> 　　　　　　　　　　　　（梅田望夫著「ウェブ進化論」より）

しかし、下記の二点は日本の学者や技術者はほとんど語りません。

・オープンソースを応援する企業には、ボランティアプログラマとは
　別の思惑がある。

・オープンソースの作業に使えるボランティアプログラマの才能は
　無限だというのは幻想にすぎない。

これらの点について、さらに、オープンソースとIT業界の未来予想に
ついて、次号以降で論じます。

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[ブルックスの法則]　本メルマガでのオープンソース関連記事
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

尚、本メルマガで、これまでにオープンソースについて取り上げた
記事は下記のとおりです。

・第117号「オープンソースが苦手とするソフトを作るべき」
　http://www.kei-it.com/sailing/117-060306.html

・第108号「2006年のインフラ、ミドルウェア開発」
　http://www.kei-it.com/sailing/108-060102.html

・第107号「インフラの世界」
　http://www.kei-it.com/sailing/107-051226.html

・第109号「パッケージ・ソフトが置かれている状況」
　http://www.kei-it.com/sailing/109-060109.html

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

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

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

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

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

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

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

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

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

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

乞うご期待！！

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

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

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

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

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

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

**************************************************************
_/_/_/_/_/_/_/ ソフトウェア業界　新航海術 _/_/_/_/_/_/_/_/_/
**************************************************************
第126号 2006/5/8
▼ まえがき
▼ [ブルックスの法則]　生産性が100倍あれば人月の神話など関係ない
▼ [ブルックスの法則]　システム開発のスケジュールの内訳
▼ [ブルックスの法則]　テストは完全に順次的制約に左右される
▼ [ブルックスの法則]　OSやミドルウェアのテストは困難を極める
▼ 次回以降の予告

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

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

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

尚、本メルマガで「人月の神話問題」と言った場合は、ソフトウェア開発
一般についての次のような問題を指します。

・ソフトウェア構築は、本来、下記の二つの性格を持っている。
　(1)順次的に連続していて分担できない仕事。
　(2)複雑な相互関係における作業の遂行。
・したがって、要員を追加することが、スケジュールを長引かすことは
　あっても、短くすることはない。

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[ブルックスの法則]　生産性が100倍あれば人月の神話など関係ない
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

第124号、第125号で述べたように、人月の神話問題に対するマイクロソフト
の解決策は、次のようなものでした。

「結局Microsoftは人月の神話がどうであれ、頭のいい人々をチームに
追加すれば、限界価値は逓減するにしても出力を増加できるということを
発見した。」（ジョエル・スポルスキ）
（　http://japanese.joelonsoftware.com/PainlessSpecs/3.html　参照）

ところで、超優秀なプログラマと平均的プログラマとの生産性の差は、
どのくらいあるのでしょうか？
ロバート・X・クリンジリーは100倍以上だと言っています。

> 正規分布曲線の右端には平均的プログラマの100倍ものコードを書ける
> プログラマがいるのである。・・・（中略）・・・
> 本当に創造的で先端的なプロジェクトの場合には100倍どころか
> 無限倍の生産性があるといってよいだろう。
>
> （ロバート・X・クリンジリー「コンピュータ帝国の興亡」より）

「生産性が100倍あれば人月の神話など関係ない」が、マイクロソフトの
解答でした。

実際に、頭のいい人々を獲得することにかけてのマイクロソフトの
執念はすさまじいものでした。
このことについては、いくつもの証言がありますが、それについては
割愛し、今週号からはマイクロソフトと正反対のアプローチについて
解説します。

オープンソースです。

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[ブルックスの法則]　システム開発のスケジュールの内訳
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

まず、システム開発のスケジュールの内訳について見てみましょう。

「人月の神話」でブルックスは、次のようなスケジュールを推奨して
います。

　1/3　計画
　1/6　コーディング
　1/4　単体テストおよび初期システムテスト
　1/4　すべてのコンポーネントを統合して行うシステムテスト

テストに全体の半分を割り当てています。

30年前に書かれた指針ですが、本メルマガ読者の多くは、これが今でも
通用する指針であることに賛意を示されるでしょう。

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[ブルックスの法則]　テストは完全に順次的制約に左右される
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

また、ブルックスはテストについて次のように述べています。

「スケジュールの中でも、デバッグとシステムテストの期間ほど、
完全に順次的制約に左右されるものはない。」（「人月の神話」より）

確かに、設計やコーディングの場面では、優秀な技術者が画期的な
アイデアや斬新なアルゴリズムを思いついて、進捗が一気に進む場合も
あるでしょう。
このフェーズでは、優秀な技術者と平均的なプログラマの生産性の
差が100倍ということもあり得るかもしれません。

しかし、テストフェーズでは、一連のしっかりしたテストケースを
準備し、それを実行・記録し、コツコツと地道にバグをつぶして
いくしかありません。

このフェーズでは、優秀な技術者と平均的なプログラマの生産性の差は、
設計やコーディングフェーズほどではないでしょう。

ウォータフォール開発プロセスだろうが漸増型開発プロセスだろうが、
また、トップダウンテストだろうがボトムアップテストだろうが、
テスト作業には時間がかかります。
テスト作業は、注意深くコントロールされて順々に進められることが
必要だからです。

したがって、テストは「完全に順次的制約に左右される」のです。

そして、冒頭の「まえがき」で記したとおり、順次的制約が「人月の
神話問題」の原因の一つです。

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[ブルックスの法則]　OSやミドルウェアのテストは困難を極める
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

上記のとおり、テストには膨大な時間と費用がかかります。

それでも画面系のアプリケーションは比較的容易なのですが、OSや
ミドルウェアのテストは困難を極めます。
理由は次のとおりです。

・目に見えない。
・様々なタイミングに依存しているので、再現テストが難しい。
・関連するハードウェア、ソフトウェアとの相性がある。

システム開発の半分の期間はテストに費やされるので、この期間を
短縮できれば、開発期間は劇的に短縮されるはずです。

レイモンド氏はオープンソースではそれが可能だと言います。

詳細は次号で解説します。

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

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

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

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

技術系：
・OSS（オープンソースを持ち上げる人々、オープンソースの実態）
・Linux台頭とSUN
・SEO対策
・WEB2.0
・メーカからの請負、エンドユーザからの請負
　（品質管理、検収、瑕疵担保責任の違い）
・グーグルの衝撃
・PMBOK

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

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

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

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

乞うご期待！！

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

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

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

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

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

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

**************************************************************
_/_/_/_/_/_/_/ ソフトウェア業界　新航海術 _/_/_/_/_/_/_/_/_/
**************************************************************
第125号 2006/5/1
▼ まえがき
▼ [ブルックスの法則]　プログラムマネージャという地位は残った
▼ [ブルックスの法則]　Execl,Accessが成功し、MSN1.0が失敗した理由
▼ [ブルックスの法則]　多くの会社にはプログラムマネージャの概念すらない
▼ [ブルックスの法則]　プログラムマネージャには部下がいない
▼ 次回以降の予告

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

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

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

尚、本メルマガで「人月の神話問題」と言った場合は、ソフトウェア開発
一般についての次のような問題を指します。

・ソフトウェア構築は、本来、下記の二つの性格を持っている。
　(1)順次的に連続していて分担できない仕事。
　(2)複雑な相互関係における作業の遂行。
・したがって、要員を追加することが、スケジュールを長引かすことは
　あっても、短くすることはない。

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[ブルックスの法則]　プログラムマネージャという地位は残った
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

第124号「マイクロソフトの「ブルックスの法則」対策」では、
ジョエル・スポルスキ氏のWEBサイト
( http://japanese.joelonsoftware.com/PainlessSpecs/3.html )
を参考にして、下記のようなことを記しました。

・マイクロソフトでは人月の神話問題を解決するため、チャールズ・
　シモニーのマスタ/スレーブプログラミングを導入したが、全然機能
　しなかった。

・マイクロソフトでは、結局、「頭のいい人々をチームに追加する」
　ことで人月の神話問題を解決した。

・チャールズ・シモニーのアイディアは失敗したが、その中に含まれ
　ていたプログラムマネージャという地位は、Jabe Blumenthal
　（EXCELの設計者）によって、「製品のデザインと仕様を所有する者」
　という意味づけを与えられ、マイクロソフトで今でも重要な役割を
　果たしている。

ジョエル・スポルスキ氏自身も、かつてマイクロソフトで、Excel VBAの
開発を率いたプログラムマネージャでした。

尚、チャールズ・シモニーのアイディアの導入とその失敗については、
ロバート・X・クリンジリー著「コンピュータ帝国の興亡」にも、
ほぼ同じことが、もっと辛らつに書かれています。

> ソフトウェア工場は崩壊し、マイクロソフトはあっという間にほかの
> 誰もがやっている方法でコードを書くスタイルに戻ってしまった。
> しかし、アーキテクトとプログラム・マネージャという階層構造は
> そのまま残った。
> 　（ロバート・X・クリンジリー「コンピュータ帝国の興亡」より）

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[ブルックスの法則]　Execl,Accessが成功し、MSN1.0が失敗した理由
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

人月の神話問題に対するマイクロソフトの解答は、
「頭のいい人々をチームに追加すれば、限界価値は逓減するにしても
出力を増加できる。したがって、超優秀なプログラマーを高給で雇うべき」
でした。

これと対照的なアプローチとしてオープンソースがあります。

しかし、オープンソースについて論じる前に、もう少しジョエル・
スポルスキ氏の言葉に耳を傾けてみましょう。

彼はチャールズ・シモニーのマスタ/スレーブプログラミングの
アイディアは全く評価していませんが、プログラムマネージャという
地位については非常に高く評価しています。

そして、彼は次のように証言しています。

> 強力なプログラムマネージャのいるグループは非常に成功した
> 製品を作り出した：Execl,Access,Windows95が頭に浮かぶ。
> しかし、他のグループ(MSN1.0やWindowsNT1.0)はプログラム
> マネージャを通常無視している開発者たちに仕切られており、
> その製品はあまり成功していなかった。

( http://japanese.joelonsoftware.com/PainlessSpecs/3.html からの引用)　

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[ブルックスの法則]　多くの会社にはプログラムマネージャの概念すらない
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

ジョエル・スポルスキ氏は「多くの会社はプログラムマネージャの
概念すら持っていない」と言っています。
読者の多くは、「そんなことはない。うちの会社にも同じような
立場の人はいる」と反論されるでしょう。

確かに、どこの会社にも、顧客と会い、仕様書を書く人はいるでしょう。

しかし、ジョエル・スポルスキ氏が、プログラムマネージャを雇う
ときに避けるべきだと指摘している3点を読めば、マイクロソフトの
プログラムマネージャは独特なものであることが分かります。

その3点とは、
(1)プログラムマネージャにしてやるとコーダに約束しない
(2)マーケティングの人間をプログラムマネージャにしない
(3)コーダをプログラムマネージャの監督下に置かない
です。

(1)(2)は、「プログラムマネジャーとはプログラマやマーケティングとは
異質の独立したキャリアパスである」という主張であり、詳しくは
http://japanese.joelonsoftware.com/PainlessSpecs/3.html を参照
してください。

(3)が最も重要です。

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[ブルックスの法則]　プログラムマネージャには部下がいない
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

チャールズ・シモニーのマスタ/スレーブプログラミングでは、
プログラムマネージャはマスタ（主人）であり、コーダはスレーブ
（奴隷）でした。
しかし、Jabe Blumenthalによって再発明されたプログラムマネージャは、
「製品のデザインと仕様を所有するが、プログラマに対する指揮命令権は
持っていない」という不思議な地位なのです。

権限を用いず、プログラマを動かすためには、共通の理解
しかありません。
共通の理解が得られないなら、MSN1.0やWindowsNT1.0の
開発の時のように、開発者に無視されても仕方がない存在なのです。

> 奇妙なのは、私が職階の「最下層」にいたということだ。
> そう、私には部下は誰もいなかった。私が誰かに何かして
> もらいたいと思ったら、それをするのが正しいということを
> 納得させる必要があった。

> もしこれらの人々の誰かが私の部下であったなら、製品は
> そんなに良いものとはならなかっただろう。

> 実際にはコンセンサスを得る以外には私に選択肢はなかった。
> このような意思決定形式が、正しいことが行われるように
> するための最善の方法だった。

( http://japanese.joelonsoftware.com/PainlessSpecs/3.html からの引用)　

「Microsoftでは今でもプログラムマネージャと呼ばれる人たちが
飛び回っている」（ジョエル・スポルスキ）としたら、マイクロソフトは
やはり尋常な会社ではないのでしょう。

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

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

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

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

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

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

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

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

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

乞うご期待！！

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

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

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

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

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

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

**************************************************************
_/_/_/_/_/_/_/ ソフトウェア業界　新航海術 _/_/_/_/_/_/_/_/_/
**************************************************************
第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

**************************************************************
_/_/_/_/_/_/_/ ソフトウェア業界　新航海術 _/_/_/_/_/_/_/_/_/
**************************************************************
第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

**************************************************************
_/_/_/_/_/_/_/ ソフトウェア業界　新航海術 _/_/_/_/_/_/_/_/_/
**************************************************************
第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

**************************************************************
_/_/_/_/_/_/_/ ソフトウェア業界　新航海術 _/_/_/_/_/_/_/_/_/
**************************************************************
第121号 2006/4/3
▼ まえがき
▼ [5年後のシステム開発]　30年前の洞察が今でもそのまま通用する
▼ [5年後のシステム開発]　仕事の４分類
▼ [5年後のシステム開発]　人数と時間との関係は仕事によって異なる
▼ [5年後のシステム開発]　人数と時間の関係図についての注釈
▼ [5年後のシステム開発]　順次的であり、且つ、相互関連を持つ
▼ [5年後のシステム開発]　ブルックスの法則への反対意見
▼ 次回以降の予告

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

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

先週号から「ブルックスの法則」について書いています。
久しぶりの「5年後のシステム開発」シリーズです。

「5年後のシステム開発」シリーズを最初から読みたい方は、
http://www.kei-it.com/sailing/back_2010.html
を参照してください。

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

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[5年後のシステム開発]　30年前の洞察が今でもそのまま通用する
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

ブルックス著「人月の神話」は、1974年に書かれた本ですが、ごく
最近の論文にも頻繁に引用されます。
例えば、

> Frederick P. Brooks の古典The Mythical Man-Month からはあちこち
> 引用させてもらった。というのも、かれの洞察はいろいろな意味で、
> まだまだそのまま通用するものだからだ。
>
> 　　　　　　（Eric S. Raymond 著「伽藍とバザール」より）

プロジェクト管理について書かれた著名な本で、「人月の神話」について
言及していない本はないと言っても過言ではありません。

しかし、「人月の神話」で書かれていることは、専門家でなければ
理解できないような難解なことではありません。

新人や素人にも十分に理解できるほど簡単なことを言っているのです。

以下に、「人月の神話」の最も根本的な部分を紹介します。

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[5年後のシステム開発]　仕事の４分類
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

ブルックスは仕事を下記の４つに分類します。

（１）完全に分割可能な仕事。
（２）分割不可能な仕事
（３）分担はできるがサブタスク間でのコミュニケーションが必要な仕事
（４）複雑な相互関連を持つ仕事

そして、それぞれについて、作業人数と完成までに要する時間との
関係を次のように説明します。

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[5年後のシステム開発]　人数と時間との関係は仕事によって異なる
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

（１）完全に分割可能な仕事。

多くの作業者の間でコミュニケーションを図らなくても、仕事が分担
できる仕事です。
ブルックスは、小麦を刈り取る、綿を摘むといった仕事を例にあげています。
この手の仕事は、作業人数を増やせば、完成までに要する時間は単純に
反比例して短縮されます。（下図参照。）

　
人数
　1　***************************
　2　********************
　3　**************
　4　*********
　5　*****
　　　　　月数

（２）分割不可能な仕事

しかし、連続していて分担できない仕事なら、作業人数を増やしても、
完成までに要する時間は変わりません。（下図参照。）
「女性がどれだけたくさん動員されところで、子供1人が生まれて
くるまで10月10日かかることに変わりはない」（「人月の神話」より）

人数
　1　***************************
　2　***************************
　3　***************************
　4　***************************
　5　***************************
　　　　　月数

（３）分担はできるがサブタスク間でのコミュニケーションが必要な仕事

この場合、コミュニケーションを図る労力を、こなすべき仕事量に追加
しなければなりません。
教育、訓練、および相互コミュニケーションの負担が増えるのです。
したがって、人数の増加は（１）の場合ほどには効果的ではありません。
（下図参照。）

人数
　1　***************************
　2　**********************
　3　******************
　4　***************
　5　*************
　　　　　月数

（４）複雑な相互関連を持つ仕事

仕事が複雑な相互関連を持つ場合、コミュニケーションを図るための
労力はさらに増大し、分担によってもたらされた各個人の作業時間
短縮をすぐに上回ってしまいます。（下図参照）

人数
　1　***************************
　2　**************************
　3　***************************
　4　*****************************
　5　********************************
　　　　　月数

「仕事の各部分がそれ以外の部分と個別に調整されなければなら
ないから、そのための労力は、人がn人いれば、n(n-1)/2に比例する。」

「もしその要員が共同で問題解決にあたるための会議が必要になると、
事態は一層ひどくなる。」
　　　　　　　　　　　　　　　　　　（「人月の神話」より）

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[5年後のシステム開発]　人数と時間の関係図についての注釈
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

人数と時間の関係についての上記（１）～（４）の図は、「人月の神話」
で書かれている図を、テキストで書きやすいように少し変えたものです。

「人月の神話」では、
http://www.kei-it.com/sailing/img/man-month.html　のように
書かれています。

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[5年後のシステム開発]　順次的であり、且つ、相互関連を持つ
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

多くのソフトウェア開発作業は、上記（２）の「順次的に連続していて
分担できない仕事」という性格を持っています。

これは、開発プロセスが、ウォータフォール型でなく、漸増型の場合も
同様です。

（第66号「テスト、修正せずに機能追加」参照。
http://www.kei-it.com/sailing/66-050314.html　）

また、チームで開発する場合には、チーム内での教育、訓練、および相互
コミュニケーションの負担が発生します。

そして、サブタスク単位で分割した場合には、そのサブタスクを担当した
チーム間で、相互コミュニケーションの負担が発生します。

したがって、システム開発のプロジェクトは最も成功している場合でも、
（３）の状態であり、少し複雑になると、すぐに（４）の状態になって
しまいます。

「だから、要員を追加することが、スケジュールを長引かすことは
あっても、短くすることはないのである。」（「人月の神話」より）

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[5年後のシステム開発]　ブルックスの法則への反対意見
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

上記、仕事の4分類と、そのそれぞれによって異なる人数と時間の関係は、
システム開発だけでなく、事務、営業、企画、肉体労働などでもごく
日常的に観察できることでしょう。

この理論が、ブルックスの法則の根拠となっています。

そして、ブルックスの法則は今でも、一般には、正しいとされています。

（でも、遅れているプロジェクトへの要員追加は世界中で相変わらず
行われていますが・・・。）

しかし、レイモンド氏は「伽藍とバザール」の中で、ブルックスの法則に
対して次のような反対意見を述べています。
( http://cruel.org/freeware/cathedral.html 参照)

・ブルックスの法則が唯一無二の真理なら、Linux はあり得なかっただろう。

・開発コーディネーターが、最低でもインターネットくらい使える
　メディアを持っていて、圧力なしに先導するやりかたを知っている
　場合には、頭数は一つよりは多いほうが絶対にいい。

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

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

・「人月の神話」の本を読まずに「人月の神話」という言葉だけを
　知ってる人の誤解。

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

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

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

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

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

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

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

乞うご期待！！

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

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

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

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

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

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