メルマガ ソフトウェア業界 新航海術 |
ホーム |
バックナンバー |
2010年のシステム開発 |
航海術 |
||
全バックナンバー(古い号が先) 全バックナンバー(新しい号が先) ●:5年後のシステム開発 ●:ブルックスの法則 ●:グーグルの衝撃 ●:保存できないエディタ ●:会社の心臓 ●:労働法の森 |
●:製造業の呪縛 ●:請負と派遣 ●:永久運動の設計 ●:大きくなるか、小さくなるか ●:ゴーイング・コンサーン ●:慶2.0 ●:金持ちソフト会社、貧乏ソフト会社 |
●:経営の基準となる数字 ●:借入れと連帯保証 ●:ソフトウェア振替という麻薬 ●:賃金決定の仕組み ●:SE・プログラマの資質 ●:新営業マニュアル ●:新会社法活用術 |
************************************************************** _/_/_/_/_/_/_/ ソフトウェア業界 新航海術 _/_/_/_/_/_/_/_/_/ ************************************************************** 第195号 2007/11/25 ▼ まえがき ▼ [ブルックスの法則] (1)良い製品を生み出す環境 ▼ [ブルックスの法則] (2)共通の理解( common understanding ) ▼ [ブルックスの法則] (3)コンセンサスを得る( build consensus ) ▼ [ブルックスの法則] (4)「共通の理解/コンセンサス/納得」が大前提 ▼ [ブルックスの法則] (5)基礎知識レベルで共通の認識を ▼ 次回以降の予告 *=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= まえがき *=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= 蒲生嘉達です。 「ソフト会社の心臓」出版計画は下記のスケジュールで進んでいます。 11月9日(金) 初校出し → 校正 11月25日(月) 初校戻り 12月7日(金) 再校出し → 校正 12月25日(月) 再校戻り 1月11日(金) 校了 1月18日(金) 印刷所入稿 2月4日(月) 見本日 2月12日(火) 取次搬入 ここのところ休日は、息子と釣に行く以外は、校正に時間を費や しています。 さて、今回は1年3ヶ月ぶりのブルックスの法則シリーズです。 *=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= [ブルックスの法則] (1)良い製品を生み出す環境 *=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= 第132号「オープンでもクローズドでも良い製品を生み出す環境は似ている」 ( http://kei-it.tea-nifty.com/sailing/2006/06/post_8949.html )で 次のように述べました。 -----------------(引用始め)--------------------------- 一般には、オープンソース陣営とマイクロソフトは、正反対のアプ ローチを採用していると思われています。 しかし、ジョエル・スポルスキ氏が描くマイクロソフトのプログラム マネージャ像とエリック・レイモンド氏が描くオープンソース プロジェクトのコーディネータ/リーダ像とは、非常に似ていることに 気づきます。 両者ともに、製品のデザインと仕様を所有しますが、プログラマに 対する指揮命令権は持っていません。 彼らのリーダーシップの源泉は、権力関係ではなく、共通の理解、 コンセンサス、納得なのです。 ジョエル・スポルスキ氏、エリック・レイモンド氏ともに、権力関係 によるリーダーシップは良い製品を生み出さないと主張しています。 オープンソースであろうとクローズドソースであろうと、知的創造物を 作り出すプロジェクトで成功するためには、同じような仕組みが必要だ ということなのでしょう。 メンバーの自由な創造と、「共通の理解」がセットで存在すること。 そして、それを実現するために、冒頭の(1)〜(4)で示したような、 対人能力やコミュニケーション能力に優れたリーダが存在すること。 -----------------(引用終わり)--------------------------- *=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= [ブルックスの法則] (2)共通の理解( common understanding ) *=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= 「共通の理解、コンセンサス、納得」についてもう少し考えるために、 「伽藍とバザール」、「ジュエル・オン・ソフトウェア」でそれら について書かれている部分を原文で読んでみましょう。 下記はエリック・レイモンドが「伽藍とバザール」で引用している クロポトキンの「ある革命家の回想」の中の一文です。 原文で読みたくなる部分は原文を埋め込んでいます。 ------------------------------------ 農奴を所有する一家に育ったわたしは、当時の若者たちみんなと 同じように、命令したり指令したり、叱りつけたり罰したりといった 行動の必要性について、まったく疑うことを知らぬままに成年に達した。 しかしかなりはやい時期に、わたしは大がかりな企業を経営すること になり、自由な人々と交渉することになった。 そしてまちがい一つが重大な結果を招くような状況で、わたしは命令と 規律という原理にしたがって活動するのと、共通の理解という原理に 基づいて行動するのとの差をだんだん理解するに至った。 When each mistake would lead at once to heavy consequences, I began to appreciate the difference between acting on the principle of command and discipline and acting on the principle of common understanding. 前者は軍隊のパレードでは見事に機能するが、実生活において、 目標が多くの重なり合う意志の真剣な努力によってしか達成できない ような状況では何の価値もない。 The former works admirably in a military parade, but it is worth nothing where real life is concerned, and the aim can be achieved only through the severe effort of many converging wills. 「伽藍とバザール」原文: http://www.catb.org/%7Eesr/writings/homesteading/cathedral-bazaar/index.html 「伽藍とバザール」翻訳: http://cruel.org/freeware/cathedral.html *=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= [ブルックスの法則] (3)コンセンサスを得る( build consensus ) *=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= 次は「ジュエル・オン・ソフトウェア」です。 原文で読みたくなる部分は原文を埋め込んでいます。 ------------------------------------ Microsoftのプログラムマネージャとして、私はExcelのVisual Basic (VBA)ストラテジーをデザインし、VBAをExcelにどのように実装すべきか、 微細な詳細にいたるまで完全に仕様化した。 私の仕様書は500ページに及んだ。 Excel 5.0の開発の高みから私の見積ったところでは、毎朝250人の 人々が働きに出て来て、私の書いた巨大な仕様に関わる作業をしていた。 ・・・(中略)・・・・ 奇妙なのは、私が職階の「最下層」にいたということだ。 そう、私には部下は誰もいなかった。 私が誰かに何かしてもらいたいと思ったら、それをするのが正しいと いうことを納得させる必要があった。 The weird thing was that I was at the "bottom" of the reporting tree. That's right. NOBODY reported to me. If I wanted people to do something, I had to convince them that it was the right thing to do. ・・・(中略)・・・・ もしこれらの人々の誰かが私の部下であったなら、製品はそんなに 良いものとはならなかっただろう。 If any of these people had reported to me, the product wouldn't have been as good. 彼らのあるものは上司にとやかく言うのはまずいと思うかもしれない。 あるいは、私がうぬぼれや近視眼のために、私のやり方でやるように 断固として命令していたかもしれない。 実際にはコンセンサスを得る以外には私に選択肢はなかった。 このような意思決定形式が、正しいことが行われるようにするための 最善の方法だった。 As it was, I had no choice but to build consensus. This form of decision making was the best way to get the right thing done. 「ジュエル・オン・ソフトウェア」原文: http://www.joelonsoftware.com/articles/fog0000000034.html 「ジュエル・オン・ソフトウェア」翻訳: http://japanese.joelonsoftware.com/PainlessSpecs/3.html 第125号:マイクロソフトのプログラムマネージャ http://kei-it.tea-nifty.com/sailing/2006/05/post_a4c0.html *=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= [ブルックスの法則] (4)「共通の理解/コンセンサス/納得」が大前提 *=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= ジョエル・スポルスキ氏は、「ジュエル・オン・ソフトウェア」の別の 箇所で、ブルックスの法則を打ち破るためには優秀な人を集めることが 一番重要だとも言っています。 第124号:マイクロソフトの『ブルックスの法則』対策 http://kei-it.tea-nifty.com/sailing/2006/04/post_3020.html また、エリック・レイモンド氏はブルックスの法則を打ち破る 方法としてオープンソースを主張しています。 第128号:リーヌスの法則 http://kei-it.tea-nifty.com/sailing/2006/05/post_39f4.html しかし、「共通の理解、コンセンサス、納得」の重要性を強調して いるところは二人に共通しています。 優秀な人を雇う作戦で行くにしても、オープンソース作戦で行くに しても、それがうまく機能するためには下記のことが不可欠なのです。 ・共通の理解という原理に基づいて行動すること ( acting on the principle of common understanding ) ・コンセンサスを得ること ( to build consensus ) ・それをするのが正しいということを納得させること ( to convince them that it was the right thing to do ) *=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= [ブルックスの法則] (5)基礎知識レベルで共通の認識を *=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= 「共通の理解、コンセンサス、納得」が「命令、規律」以上に重要 であるということは、システム開発においてだけではありません。 これらは、会社にとって、様々な組織にとって、そしてあらゆる 人間関係にとって、うまく機能するための基盤となるものです。 私はメルマガや出版物で、社内、社外に対し、基礎知識レベルで 共通の認識を作り出していきたいと考えています。 *=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= 次回以降の予告 *=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= 次回発行予定は、12月初旬です。 乞うご期待!! *=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= 本メルマガについて *=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= 本メルマガは2003年12月8日に創刊されました。 創刊号 http://www.kei-it.com/sailing/01-031208.html で述べたとおり、 本メルマガのコンセプトは「読みものとしても面白い慶の事業計画」であり、 目的は「事業計画の背後にある基本的な考え方を語ること」です。 したがって、第一の読者としては、慶の社員(正社員・契約社員)及び 慶と契約している個人事業主を想定しています。 また、多くのソフトウェア会社・技術者が直面している問題を扱っているので、 ソフトウェア会社の経営者、管理者、技術者にとっても参考になると思い、 第33号(2004年7月19日号)からは「まぐまぐ!」で一般の方々にも公開する ことにしました。 「まぐまぐ!」での読者数は2007年11月20日現在、643名です。 本メルマガの内容に興味を持つであろう方をご存知なら、是非 本メルマガの存在を教えてあげてください。 (以下をそのまま転送するだけです。) --------------------------------------------------- 【お勧めメルマガ ソフトウェア業界 新航海術】 ⇒ http://www.mag2.com/m/0000136030.htm または http://kei-it.tea-nifty.com/sailing/ または http://www.kei-it.com/sailing/ -------------------------------------------------- このメールマガジンは『まぐまぐ!』 http://www.mag2.com/ を利用して 発行しています。配信中止はこちら http://www.mag2.com/m/0000136030.htm (但し、knextall@kei-it.com には直接配信しています。) バックナンバーは、発行者サイトまたはブログで、体系として 見てもらいたいので、「まぐまぐ!」でのバックナンバー公開は 最新号のみとなっています。 バックナンバーブログ:http://kei-it.tea-nifty.com/sailing/ 発行者Webサイト: http://www.kei-it.com/sailing/ (発行者Webサイトではバックナンバーの全文検索も可能です。) ☆筆者の趣味のブログ:身近にいる小動物の図鑑☆ http://kei-it.tea-nifty.com/small/ -------------------------------------------------- 発行: 株式会社 慶 代表取締役 蒲生 嘉達 |
|
(c)Copyright Kei Co.,Ltd All Right Reserved |