« March 2006 | Main | May 2006 »

April 2006

April 24, 2006

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

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

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

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

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

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


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

(例2)
 みずほ銀行のシステム統合における不具合の問題は、まさに「人月の神話」
 の最近におけるまごうことなき証明だ。
 (慶應義塾大学 國領研究室のホームページ
  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)プログラムマネージャ

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


(2)優秀な人を集める

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

「結局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

|

April 17, 2006

請負開発を人月で見積もる理由

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

|

April 10, 2006

そしてデスマーチへと突入する

**************************************************************
_/_/_/_/_/_/_/ ソフトウェア業界 新航海術 _/_/_/_/_/_/_/_/_/
**************************************************************
第122号 2006/4/10
▼ まえがき
▼ [ブルックスの法則] 当初のスケジュール
▼ [ブルックスの法則] マイルストーンAで1ヶ月遅れが発生
▼ [ブルックスの法則] 第1回の要員追加
▼ [ブルックスの法則] 2名追加したが、遅れは全く変わらなかった
▼ [ブルックスの法則] もとの見積もりになかった仕事が増えたから
▼ [ブルックスの法則] そしてデスマーチへと突入する
▼ [ブルックスの法則] ケース2だともっと恐ろしいことが起こる
▼ 次回以降の予告


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

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

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

今週号では、架空のプロジェクトを例にして、ブルックスの法則が
成立してしまう仕組みを明らかにします。
(「人月の神話」に出てくる例に少し肉付けをしました。)


先週号はテキスト文だけで表現しましたが、今週号は図を使って
説明します。
下記URLを参照しながら読んでください。
http://www.kei-it.com/sailing/img/mm0410.html

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[ブルックスの法則] 当初のスケジュール
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

昨年12月、あるソフトウェア会社に顧客から「社内で使用する販売管理
システムの開発をお願いしたいのだが・・・」という打診がありました。

そこには「新しい販売販売管理システムは6月から稼動させたいので、
システムテストが完了した製品を5月1日までに納品してください」
という条件が付いていました。

ソフトウェア会社のマネージャが技術者に見積もりをさせたところ、
「3人が作業して4ヶ月かかります」という報告が上がってきたので、
マネージャは3人の技術者を確保し、B社からの仕事を受注しました。

そのときマネージャが想定したスケジュールは、
「図1:当初のスケジュール」
( http://www.kei-it.com/sailing/img/mm0410.html#1 参照)のような
ものでした。

1月から3人を投入し、マイルストーンA、B,C,Dがそれぞれ
1月末、2月末、3月末、4月末に来るようにスケジュールされていました。
マイルストーンDはシステムテスト完了です。

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[ブルックスの法則] マイルストーンAで1ヶ月遅れが発生
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

ところが、2月末時点でマネージャは、「マイルストーンAの到達が
1月末ではなく、2月末になってしまいました」という報告を受けました。

最初のマイルストーンAで1ヶ月遅れが発生してしまったのです。

この場合、次の二つのケースが考えられます。

ケース1:マイルストーンAまでの見積もりのみが甘かった。
( http://www.kei-it.com/sailing/img/mm0410.html#21 参照 )

ケース2:マイルストーンA、B、C、Dまでの全ての見積もりが甘かった。
( http://www.kei-it.com/sailing/img/mm0410.html#22 参照 )


ケース1なら、単にマイルストーンAまでの見積もりが甘かった
だけなので、マイルストーンB、C、Dまでは、当初の想定どおり、
それぞれ1ヶ月ずつかかります。
したがって、このまま行くと、マイルストーンDに到達するのは
5月末となってしまいます。

一方、ケース2なら、マイルストーンDに到達するのは8月末となって
しまいます。


今回はケース1だったとして、考察を進めましょう。

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[ブルックスの法則] 第1回の要員追加
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

ケース1だったとしても、5月1日という納期は守れません。

「図2-1:2月末時点での進捗と予想(ケース1)」を見たマネージャは、
「図3:3月からの要員追加」に示されるような要員追加を考えました。
( http://www.kei-it.com/sailing/img/mm0410.html#3 参照)

「図2-1:2月末時点での進捗と予想(ケース1)」では3月から5月
までの作業量は9人月でした。
それを、3月と4月の2ヶ月でこなすためには、4.5名が必要
(4.5名×2ヶ月=9人月)なので、2名が新たに投入されました。


マイルストーンB、C、Dには、それぞれ3月20日、4月10日、4月末に
到達できるはずでした。

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[ブルックスの法則] 2名追加したが、遅れは全く変わらなかった
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

しかし、3月末時点で現場から上がってきた報告「図4:3月末時点での
進捗と予想」( http://www.kei-it.com/sailing/img/mm0410.html#4 )を
見てマネージャは驚きました。

それは、次のようなことを示していたからです。

・3月から2名新たに投入したのに、まだマイルストーンBに到達していない。
・このまま行くとマイルストーンD到達は5月末になる。

「図2-1:2月末時点での進捗と予想(ケース1)」での予想も、
「このまま行くとマイルストーンDに到達するのが5月末となってしまう」
でした。

つまり、3月から2名新たに投入したのに、遅れ具合は全く変わって
いないのです。

何故このようなことが起きたのでしょうか?

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[ブルックスの法則] もとの見積もりになかった仕事が増えたから
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

3月以降の仕事量は、「図2-1:2月末時点での進捗と予想」では
9人月だったのに、「図3:3月末時点での進捗と予想」では14人月に
増えています。

2名新たに投入したために、もとの見積もりになかった仕事が増えて
しまったのです。

人が増えると仕事が増える理由は、システム開発という仕事が、下記の
二つの性格を持つ仕事だからです。

・順次的な故に分割不可能な仕事
・分担はできるがサブタスク間でのコミュニケーションが必要な仕事
(第121号 http://www.kei-it.com/sailing/121-060403.html 参照)


新たに投入される技術者がいかに優秀な技術者であっても、ある程度は、
教育・訓練が必要です。
そして、教育・訓練が終了した後も、相互コミュニケーションの負担は
3名よりも5名の方が増えます。

また、もともと3つに分けられていた仕事を5つに分け直さなければならず、
すでに完了している仕事で無駄になるものも出てくる上に、システムテスト
に要する時間もより長くなってしまいます。

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[ブルックスの法則] そしてデスマーチへと突入する
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

しかし、5月1日という納期は守らなければならないので、マネージャは
さらに「図4:4月からの要員追加」
( http://www.kei-it.com/sailing/img/mm0410.html#5 )
のような要員追加をしました。

マネージャは、「図3:3月末時点での進捗と予想」で残っている9人月の
作業を4月1ヶ月で終わらせるためには、9名(9名×1ヶ月=9人月)が
必要だと考えたのです。
その結果、さらに4名が追加され、総勢9名のプロジェクトになりました。


この「図4:4月からの要員追加」まで来ると、読者も、この
プロジェクトが絶対に納期を守れないデスマーチに入ったということを
直感的に理解できるでしょう。

複雑な相互関連を持つ仕事、つまり、要員を追加すればするほど
遅れていく仕事に変質してしまったのです。
(第121号(4)複雑な相互関連を持つ仕事」
http://www.kei-it.com/sailing/121-060403.html 参照)

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[ブルックスの法則] ケース2だともっと恐ろしいことが起こる
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

上記考察は「図2-1:2月末時点での進捗と予想(ケース1)」を
前提にしていました。
もしも「図2-2:2月末時点での進捗と予想(ケース2)」だったら、
もっと恐ろしいことが起こります。

マネージャは、3月からの要員追加を2名ではなく6名にしたでしょう。
3月以降に残された作業が18人月、それを3月と4月の2ヶ月で割ると
1ヶ月9人必要だからです。

ケース1よりも、はるかに早い時期にデスマーチが始まります。

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

今週号の話は、他業界にいる人にとっては、まるで戯画のような話
だったと思います。

しかし、今回の話は誇張しているわけでも、特殊な例でもありません。
ソフトウェア業界では、ごくごく日常茶飯事に行われていることなのです。

しかも、日本だけでなく、世界中で、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


|

April 03, 2006

ブルックスの法則の根拠

**************************************************************
_/_/_/_/_/_/_/ ソフトウェア業界 新航海術 _/_/_/_/_/_/_/_/_/
**************************************************************
第121号 2006/4/3
▼ まえがき
▼ [5年後のシステム開発] 30年前の洞察が今でもそのまま通用する
▼ [5年後のシステム開発] 仕事の4分類
▼ [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年後のシステム開発] 仕事の4分類
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

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

(1)完全に分割可能な仕事。
(2)分割不可能な仕事
(3)分担はできるがサブタスク間でのコミュニケーションが必要な仕事
(4)複雑な相互関連を持つ仕事


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

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

(1)完全に分割可能な仕事。

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

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


(2)分割不可能な仕事

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

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

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

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

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


(4)複雑な相互関連を持つ仕事

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

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


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

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

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

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

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

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

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

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

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


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

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

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

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

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[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

|

« March 2006 | Main | May 2006 »