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

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