**************************************************************
_/_/_/_/_/_/_/  ソフトウェア業界　新航海術  _/_/_/_/_/_/_/_/_/
**************************************************************
第132号  2006/6/19
  ▼  まえがき
  ▼  [ブルックスの法則]　オープンソースプロジェクトのリーダの資質
  ▼  [ブルックスの法則]　オープンソースプロジェクトの実態
  ▼  [ブルックスの法則]　指揮命令権のないマネージャ
  ▼  [ブルックスの法則]　命令は良い製品を生み出さない
  ▼  次回以降の予告


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

蒲生嘉達（がもう よしさと）です。

今週号では、「ブルックスの法則」シリーズで書ききれなかった
次の二つのことについて書きます。

・オープンソースプロジェクトの実態
・オープンソースプロジェクトのリーダとマイクロソフトのプログラム
　マネージャとが似ていること


「ブルックスの法則」シリーズに分類します。

「ブルックスの法則」シリーズを最初から読みたい方は、
http://www.kei-it.com/sailing/back_brooks.html　を参照してください。

バックナンバーはブログでも公開しています。
ブログ：　http://kei-it.tea-nifty.com/sailing/



*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
  [ブルックスの法則]　オープンソースプロジェクトのリーダの資質
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

エリック・レイモンド氏は「伽藍とバザール」の中でバザールプロ
ジェクト（オープンソースプロジェクトのこと）のコーディネータ
やリーダに必要な資質について、次のように書いています。
(「伽藍とバザール」http://cruel.org/freeware/cathedral.html 参照)


(1)コミュニティ形成を始めるときには、まずなによりも実現でき
　そうな見込みを示せなきゃならない。・・・（中略）・・・
　絶対不可欠なのが、開発者候補たちに、それが目に見える将来には
　なにか本当に使える代物に発展させられると説得できることだ。

(2)デザイン上の才覚に匹敵するほど――あるいはそれ以上――重要な
　ものがあると思う。バザールプロジェクトは、コーディネータや
　リーダの対人能力やコミュニケーション能力が優れていないとダメだ。

(3)絶対に必要なのは、その人物がほかの人たちのよいデザイン上の
　アイデアを認識できるということだ。

(4)バザールモデルが機能するためには、人を魅了する能力が少し
　くらいでもあると、きわめて役に立つのだ。


オープンソースプロジェクトというとオタクっぽいイメージがあり
ますが、それをうまく機能させるためには、コーディネータや
リーダの対人能力、コミュニケーション能力、さらには人間的魅力が
必要なのです。



*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
  [ブルックスの法則]　オープンソースプロジェクトの実態
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

もちろん、一般のソフトウェア会社での請負開発やパッケージ開発
でも、プロジェクトマネージャ、リーダの対人能力、コミュニケー
ション能力は重要です。
しかし、彼らとプログラマとの関係は、上司と部下の関係です。
指示命令関係が最初から存在するのです。

一方、オープンソースプロジェクトのコーディネータやリーダは、
全く指示命令関係のないボランティアを使ってプロジェクトを進めます。

したがって、上記(1)のとおり、実現できそうな見込みを示し、説得
力のある説明ができなければ、プロジェクト自体が立ち上がりません。
また、上記(3)のとおり、ほかの人たちのアイデアを正しく評価し、
受け入れる能力は、プロジェクトを持続させるために必須なのです。


「ソースをオープンにしさえすれば、全世界を才能プールとして使える」
というようなことを書く学者もいます。
しかし、実際には、オープンソースプロジェクトで人を集めることは、
ソフトウェア会社の社内でプロジェクトメンバーを集めるよりも、
ある意味でもっと難しいことなのです。

> オープンソースの作業に使えるボランティアプログラマの才能の
> 量は限られており、それぞれのオープンソースプロジェクトは他の
> オープンソースプロジェクトとこの限られたプログラミングリソース
> をめぐって競っており、最も魅力的なプロジェクトだけが彼らに使える
> 以上のボランティア開発者を獲得するのだ。
> 
> （ジョエル・スポルスキ著「ジュエル・オン・ソフトウェア」より）


優秀なコーディネータやリーダに率いられた魅力的なプロジェクトに
技術者が集中し、他の大部分のプロジェクトは技術者が不足している
というのがオープンソースプロジェクトの実態です。



*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
  [ブルックスの法則]　コンセンサスを得る以外には選択肢はなかった
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

さて、下記の文章は誰が何について書いた文章でしょうか？

> もしこれらの人々の誰かが私の部下であったなら、製品はそんなに
> 良いものとはならなかっただろう。
> 彼らのあるものは上司にとやかく言うのはまずいと思うかもしれない。
> あるいは、私がうぬぼれや近視眼のために、私のやり方でやるように
> 断固として命令していたかもしれない。
> 実際にはコンセンサスを得る以外には私に選択肢はなかった。
> このような意思決定形式が、正しいことが行われるようにするための
> 最善の方法だった。


「オープンソースプロジェクトのリーダが、自分が率いたオープン
ソースプロジェクトについて書いた文章だ」と言っても誰も疑わない
でしょう。

しかし、実はこの文章は、マイクロソフトのプログラムマネージャ
経験者（ジョエル・スポルスキ氏）が自分が率いたExcel VBAの開発に
ついて書いた文章なのです。

ジョエル・スポルスキ氏によれば、マイクロソフトのプログラム
マネージャは他のソフトウェア会社にはない独特の概念だそうです。
「製品のデザインと仕様を所有するが、プログラマに対する指揮命令権は
持っていない」という不思議な存在なのです。

詳細は第125号を参照してください。
( http://www.kei-it.com/sailing/125-060501.html　または　
http://kei-it.tea-nifty.com/sailing/2006/05/post_a4c0.html )



*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
  [ブルックスの法則]　命令は良い製品を生み出さない
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

一般には、オープンソース陣営とマイクロソフトは、正反対のアプ
ローチを採用していると思われています。

しかし、ジョエル・スポルスキ氏が描くマイクロソフトのプログラム
マネージャ像とエリック・レイモンド氏が描くオープンソースプ
ロジェクトのコーディネータ/リーダ像とは、非常に似ていることに
気づきます。

両者ともに、製品のデザインと仕様を所有しますが、プログラマに
対する指揮命令権は持っていません。

彼らのリーダーシップの源泉は、権力関係ではなく、共通の理解、
コンセンサス、納得なのです。

ジョエル・スポルスキ氏、エリック・レイモンド氏ともに、権力関係
によるリーダーシップは良い製品を生み出さないと主張しています。


オープンソースであろうとクローズドソースであろうと、知的創造物を
作り出すプロジェクトで成功するためには、同じような仕組みが必要だ
ということでしょう。

メンバーの自由な創造と、「共通の理解」がセットで存在すること。
そして、それを実現するために、冒頭の(1)〜(4)で示したような、
対人能力やコミュニケーション能力に優れたリーダが存在すること。



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

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

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

外国系：
・中国は脅威か？

財務系
・資産と費用

経営系：
・壊れ窓の理論

法務系：
・コンプライアンス
・執行役の裁量の範囲と取締役会の決定権

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

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


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

乞うご期待！！



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

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

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

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


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

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