« April 2006 | Main | June 2006 »

May 2006

May 29, 2006

時間と成果が比例しない仕事の労働者派遣はどうあるべきか

**************************************************************
_/_/_/_/_/_/_/ ソフトウェア業界 新航海術 _/_/_/_/_/_/_/_/_/
**************************************************************
第129号 2006/5/29
▼ まえがき
▼ [派遣と請負の間] 準委任契約と労働者派遣契約を分かつもの
▼ [派遣と請負の間] 注文か命令か?費用の償還請求か時間管理か?
▼ [派遣と請負の間] 成果と費やした時間が比例しない
▼ [派遣と請負の間] 裁量労働型の労働者派遣
▼ [派遣と請負の間] 派遣、業務請負に関するバックナンバー
▼ 次回以降の予告

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

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

下記は日経ITPro「IT業界のタブー「偽装請負」に手を染めてませんか 」
( http://itpro.nikkeibp.co.jp/article/OPINION/20060113/227252/ )
からの引用です。

> 偽装請負とは,書類上は請負契約もしくは業務委託契約(以下,
> 請負契約)でありながら,開発・運用担当者を実質的に「派遣」
> として働かせて利益を得る行為のことをいう。
> ちなみに客先に常駐すること自体は違法ではなく,労働者への指示や
> 時間管理をしていることが問題となる。

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[派遣と請負の間] 準委任契約と労働者派遣契約を分かつもの
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

確かにコーダ、テスター、オペレーター、初級プログラマの仕事を
請負契約でやっていて、顧客が労働者への指示や時間管理をしているなら、
偽装請負にあたる可能性が高いでしょう。

しかし、上級プログラマ、SEなら、たとえ一人で客先常駐作業をして
いる場合でも、労働者派遣契約よりも、請負契約の方が自然だと私は
思います。

上級プログラマ、SEの仕事は本質的に自由裁量の余地がある仕事であり、
それ故に、労働者派遣はなじまないからです。
(第54号「準委任と人材派遣を分かつもの」
http://www.kei-it.com/sailing/54-041220.html 参照。

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[派遣と請負の間] 注文か命令か?費用の償還請求か時間管理か?
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

SEが一人で客先常駐作業をするとき、確かに顧客からの注文を受け
ながら仕事をします。

例えば、進捗会議などにSEが出席して、その席上で顧客から要望が
出され、SEが受諾するということもあるでしょう。

【問1】
これは、請負における「注文」なのでしょうか?
それとも労働者派遣における「指図」「命令」なのでしょうか?

また、時間清算も行われています。

例えば、「月の稼動実績が180時間を越えた分は30分単位で時間清算
する」というように。

【問2】
これは請負(準委任)における「必要な費用の償還請求」なのでしょうか?
(弁護士や公認会計士などの典型的な準委任契約でも時間清算は
あります。)
それとも労働者派遣における「分単位の時間管理」なのでしょうか?

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[派遣と請負の間] 労働時間と成果が比例しない
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

上記「問1」「問2」については別の機会に論じるとして、
今回は、仮にSEの1人常駐を労働者派遣で運用するとしたらどのような
運用になるのかという点から論じてみましょう。

事務職や製造業の職工では、労働時間と成果はだいたい比例します。
そして、労働者派遣はそのような、労働時間と成果がほぼ比例する
ような仕事を前提としています。
したがって、分単位の時給清算となります。

しかし、SE・PGの場合、労働時間と成果は比例しません。
そのため、多くのソフトウェア会社は、「生産性の低い人ほど残業が
増え給料が高くなってしまう」という問題に悩まされています。
長年雇用し、技量が分かっている正社員を使っても時間と成果が
比例しないのです。

SEの常駐作業を労働者派遣で運用する場合には、同じ問題を顧客が
抱えることになるでしょう。

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[派遣と請負の間] 裁量労働型の労働者派遣
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

SE/PGの世界に本当に労働者派遣を普及させるためには、「時間と成果が
比例しない仕事の労働者派遣はどうあるべきか」という難問を解決しな
ければなりません。

この問題を解決するためには「裁量労働型の労働者派遣」という
考え方を導入する必要があるかもしれません。

「裁量労働」というのは、大枠で目標は与えられているが、仕事の
進め方などは、すべて自分の裁量で決めていく仕事のことです。

裁量労働については、その業務を通常処理するためにはどの程度の
時間を労働するとみなすのが適当であるかについて労使で協定をした
ときは、その時間労働したものとみなすという制度が、労動基準法で
定められています。これを「裁量労働制」と言います。

但し、裁量労働制を採用しても、みなし労働時間を超えた時間外労働
手当はありますし、深夜労働手当や休日出勤手当もあります。
(この点は多くの経営者が誤解しています。)

もしも本当にSE/PGの世界に労働者派遣を普及させたいなら、SE/PGの
仕事の裁量労働性(「制」ではない)を直視し、「裁量労働型の労働者
派遣」について議論しなければなりません。
また、それは不可能ではありません。
しかし、そのような議論がなされているという話は聞いたことが
ありません。

但し、弁護士や社会保険労務士の派遣を認める特区ができるという
話は聞いたことがあります。
これは、裁量労働型の労働者派遣の突破口になるかもしれません。

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[派遣と請負の間] 派遣、業務請負に関するバックナンバー
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

これまで、派遣、業務請負について解説した記事は下記のとおりです。

第52号「人材派遣業は指揮命令権のレンタル業」
http://www.kei-it.com/sailing/52-041206.html

第53号「大手業務請負会社の業務請負」
http://www.kei-it.com/sailing/53-041213.html

第54号「準委任と人材派遣を分かつもの」
http://www.kei-it.com/sailing/54-041220.html

第55号「ソフトウェア業務請負の最大の問題点」
http://www.kei-it.com/sailing/55-041227.html

第57号「「人材登録型の業務請負」を狙う大手派遣会社」
http://www.kei-it.com/sailing/84-050718.html

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

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

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

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

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

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

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

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

乞うご期待!!

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

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

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

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

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

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

|

May 22, 2006

リーヌスの法則

**************************************************************
_/_/_/_/_/_/_/ ソフトウェア業界 新航海術 _/_/_/_/_/_/_/_/_/
**************************************************************
第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年前にかかれたこの短いエッセイが、なぜ今でも話題になるの
でしょうか。

それは、ここでブルックスが指摘した問題がソフトウェア開発と
いうものの本性から発生する宿命的とも言える問題だからです。
そう簡単には解決することができない問題なのです。

この問題のためにこれまでに提起されてきた解決策を列記して、
「ブルックスの法則シリーズ」は終了とします。

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[ブルックスの法則] 初期段階で協調性のある人を追加する
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

下記の二つは、他の学者の意見で、ブルックス自身が「人月の神話
 二十周年記念増訂版」で紹介しているものです。

(1)初期段階での要員追加

> スケジュールの初期段階で要員を追加することは、後から追加する
> よりはるかに安全な戦術だ。(アブデル・ハミッド、マドニック)

(2)協調性のある人を追加する

> 開発プロジェクトに後から追加される新要員は、チームプレイヤー
> としてプロジェクトの中に勢いよく飛び込んで仕事をしようとする
> 意欲の持ち主でなければならず、工程自体を変更または改善しようと
> する人ではいけない。(R.D.ストツク)


両方とも今でも通用する極めて実際的なアドバイスです。
ブルックスもこれらを「要員追加による破壊的影響を最低限に
とどめるためのアドバイス」と評価しています。

(3)頭のいい人々をチームに追加する

この解決策については、第124号「マイクロソフトの「ブルックスの法則」
対策」( http://www.kei-it.com/sailing/124-060424.html )を参照
してください。


*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[ブルックスの法則] コードを私物化せず、みんなでデバッグする
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

(4)コードを私物化せず、みんなでデバッグする

> 「エゴのないプログラミング」を論じるなかでワインバーグが述
> べたのは、開発者たちが自分のコードを私物化せず、ほかのみんなに
> バグを探したり改良点を見つけたりするよう奨励するようなところでは、
> ソフトの改善がほかよりも劇的にはやく生じる、ということだった。
>          (レイモンド著「伽藍とバザール」より)


オープンソースとは、ワインバーグが主張する「エゴのないプログラ
ミング」を、インターネットを介して、世界的な規模で行おうという
ものだと言ってもよいでしょう。


*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[ブルックスの法則] レイモンドによる「ブルックスの法則」の否定
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

(4)オープンソース

上述のとおり、ブルックスの法則が成立する理由は、ソフトウェア
構築というものが本来次の二つの性格を持っているからです。

(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

|

May 15, 2006

巷のオープンソース礼賛論に対する不満

**************************************************************
_/_/_/_/_/_/_/ ソフトウェア業界 新航海術 _/_/_/_/_/_/_/_/_/
**************************************************************
第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回も
出てきます。
「伽藍とバザール」の主題は、「オープンソースはブルックスの法則を
超えた」であると言っても過言ではありません。

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

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

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

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

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

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

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

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

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

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


これらの点について、さらに、オープンソースと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

|

May 08, 2006

開発の半分はテスト

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

|

May 01, 2006

マイクロソフトのプログラムマネージャ

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

|

« April 2006 | Main | June 2006 »