« 採用が事業モデルを決める | Main | ブルックスの法則の根拠 »

March 27, 2006

ブルックスの法則は正しいか?

**************************************************************
_/_/_/_/_/_/_/ ソフトウェア業界 新航海術 _/_/_/_/_/_/_/_/_/
**************************************************************
第120号 2006/3/27
▼ まえがき
▼ [5年後のシステム開発] 「ブルックスの法則」とは
▼ [5年後のシステム開発] 遅れが生じた場合の有効な対策は?
▼ [5年後のシステム開発] 再スケジュールも規模縮小もできない
▼ [5年後のシステム開発] 頭数は一つよりは多いほうが絶対にいい(?)
▼ 次回以降の予告


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

蒲生嘉達(がもう よしさと)です。

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

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

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

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[5年後のシステム開発] 「ブルックスの法則」とは
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

「ブルックスの法則」とは、フレデリック・P・ブルックス,Jr.が
「人月の神話」の中で述べている次のような法則です。

   遅れているソフトウェアプロジェクトへの要員追加はさらに
   遅らせるだけだ。


この法則は、ソフトウェア開発に関する様々な書籍や雑誌の中で言及
されているので、本メルマガの読者なら、ご存知の方が多いと思います。

失敗したプロジェクトの管理者を批判する文脈でよく使われます。
例えば、次のように・・・。

「『遅れているプロジェクトへの要員追加はさらに遅らせるだけ』
ということは、現場で修羅場を経験したことのある人間なら誰でも
知っていること。
しかし、不勉強で現場認識の甘い管理者は、プロジェクトに遅れが
生じた場合、要員を投入するだけで早く完了できると短絡的に考えて
しまう。
彼らはソフトウェア開発というものをまったく理解していないのだ!」


しかし、私は批判された管理者にも同情します。
彼らは次のように言うでしょう。

「でも、要員追加以外に手は無かったじゃないか。」
「たとえ結果的に効果が出なかったとしても、あの場面で要員追加
しなければ、お客様もプロジェクトメンバーも納得しなかっただろう。」

私は、これも真実だと思います。

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[5年後のシステム開発] 遅れが生じた場合の有効な対策は?
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

私は、「管理者はブルックスの法則を理解していない」と批判する側も、
次の点で無責任だと思います。

・プロジェクトに遅れが生じた場合の有効な対策を提示しているわけ
 ではない。
・ブルックスの法則の正しさを疑っていない。


もしもブルックスの法則が正しいとすると、プロジェクトに遅れが
生じた場合、次の二つしか対策がないことになります。

(1)要員追加はせず、スケジュールを立て直す。
 (新しいスケジュールではたっぷり時間をとる。)

(2)要員追加はせず、仕事を縮小する。


実際にブルックスも「人月の神話」で、納期も仕事も変えないままでの
要員追加を「破滅的」「狂気が潜んでいる」と批判する一方で、上記
二つの対策を推奨しています。
そして、特に「仕事を縮小する」が「現実的には、この対応が一番
とられやすい」としています。

> 開発チームがスケジュールの遅れを見つけた場合、遅延による二次
> コストは非常に高いため、これが唯一取り得る手段となる。
> マネージャーにとって唯一の対応策は、仕事を正式に慎重に削減
> してスケジュールし直すか、あるいは性急なデザインと不完全な
> テストによって暗黙のうちに仕事が削減されるのを待つかである。
>
>         (ブルックス著「人月の神話」より)

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[5年後のシステム開発] 再スケジュールも規模縮小もできない
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

ブルックスは、1964年~1965年にかけてIBMでOS/360メインフレーム用の
オペレーティングシステム開発マネジャーを担当し、その経験を基に
「人月の神話」を著しました。

当時のIBMのように圧倒的な力を持った企業が、自社製品を作る場合には、
上記二つのどちらでも採用できるでしょう。

しかし、現在の日本の中小ソフトウェア企業が請負開発をする場合には、
(1)も(2)も極めて困難です。

その理由は下記のページが参考になります。


第8号「ポスト産業資本主義の時代」
http://www.kei-it.com/sailing/08-040126.html
> 経済のグローバル化はあらゆる業種において、地域的な差異性を
> 消し去り、標準化を進めます。
> 標準化ということは同じ土俵で戦うということです。
> 同じ土俵で差異性を確保するため、企業は、激烈な低価格化競争、
> 短納期化競争に突入しました。


第109号「安くて気の利いたものしか売れなくなる」
http://www.kei-it.com/sailing/109-060109.html
> ソフトウェアのコモディティ化が進むということは、ソフトウェア開発
> における効率の高さが極限まで求められる

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[5年後のシステム開発] 頭数は一つよりは多いほうが絶対にいい(?)
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

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


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

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


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

まず、ブルックスの法則が成り立つ根拠をブルックス自身がどのように
語っているのかを見てみます。
そこには、時代を超えて通用する深い洞察があります。

次いで、レイモンドが、ブルックスとは反対に何故「頭数は一つよりは
多いほうが絶対にいい」と主張しているのか考えてみます。

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

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

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

技術系:
・贈与と交換
・ピアレビュー

外国系:
・中国は脅威か?


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

乞うご期待!!

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

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

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

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


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

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


|

« 採用が事業モデルを決める | Main | ブルックスの法則の根拠 »