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