メルマガ ソフトウェア業界 新航海術

ホーム

バックナンバー

2010年のシステム開発

航海術


  バックナンバーの全文検索
全バックナンバー(古い号が先)
全バックナンバー(新しい号が先)
5年後のシステム開発
ブルックスの法則
グーグルの衝撃
保存できないエディタ
製造業の呪縛
請負と派遣
永久運動の設計
大きくなるか、小さくなるか
ゴーイング・コンサーン
金持ちソフト会社、貧乏ソフト会社
経営の基準となる数字
借入れと連帯保証
ソフトウェア振替という麻薬
賃金決定の仕組み
SE・プログラマの資質
○:その他

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





[リンク元ページに戻る]    [新航海術ホーム]    [『まぐまぐ!』登録コーナー]

(c)Copyright Kei Co.,Ltd All Right Reserved