**************************************************************
_/_/_/_/_/_/_/  ソフトウェア業界　新航海術  _/_/_/_/_/_/_/_/_/
**************************************************************
第196号  2007/12/3
『eXtreme Programming（エクストリーム・プログラミング）』
  ▼  まえがき
  ▼  [保存できないエディタ]　(1)4つの価値・12のプラクティス
  ▼  [保存できないエディタ]　(2)XPと他の開発プロセスとの違い
  ▼  [保存できないエディタ]　(3)プロセスとプラクティス
  ▼  [保存できないエディタ]　(4)プロセス中心のスタイル
  ▼  [保存できないエディタ]　(5)プロセス中心の欠点
  ▼  [保存できないエディタ]　(6)プラクティス中心の欠点
  ▼  次回以降の予告


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

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

先週、第195号を書きながら、XP(eXtreme Programming)の「4つの価値」
を思い出しました。

第195号で述べた「良い製品を生み出す環境」はXPの4つの価値とも
似ていると思ったからです。

　第195号：共通の理解という原理に基づいて行動する
　http://kei-it.tea-nifty.com/sailing/2007/11/post_fce9.html


そこで、今回はXPを取り上げます。



*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ]　(1)4つの価値・12のプラクティス
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

XP(eXtreme Programming)の「4つの価値」は次のとおりです。

・コミュニケーション(Communication)
・シンプルさ(Simplicity)
・フィードバック(Feedback)
・勇気(Courage)


これらはシステム開発の基本方針のみならず、そのまま会社の基本方針
にもなり得る素晴らしい指針です。


XPではさらに下記の「12のプラクティス」を定義しています。

・計画ゲーム　　　　　　　　　・小さなリリース
・メタファー　　　　　　　　　・シンプルデザイン
・テスティング　　　　　　　　・リファクタリング
・ペアプログラミング　　　　　・共同所有権
・継続的インテグレーション　　・週40時間労働
・オンサイト顧客　　　　　　　・コーディング標準



*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ]　(2)XPと他の開発プロセスとの違い
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

XP(eXtreme Programming)をウォータフォール型開発プロセスに対する
アンチテーゼだと思っている人もいます。

しかし、XPと他の開発プロセスとの違いは、ウォータフォール型か
反復型かの違いではありません。
XPの対抗馬であるRUP(Rational Unified Prosess：ラショナル統一
プロセス)は、反復型開発プロセスの代表格です。

それでは、XPと他の開発プロセスとの違いは何でしょうか？

先ほど、XPで定義されている「12のプラクティス」を紹介しました。
ここで「プロセス」ではなく「プラクティス」という言葉が使われて
いることに注目してください。
ここにXPを理解する鍵があります。

XPと他の開発プロセスとの違いは、プロセス中心かプラクティス
中心かという違いです。

そして、「プロセス中心 VS プラクティス中心」という問題は、
ソフトウェア開発特有の問題ではありません。
様々なビジネスで昔から存在し、議論されている問題です。

XPの長所も短所も、プラクティス中心主義の一般的な性格として
説明することが可能です。



*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ]　(3)プロセスとプラクティス
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

プロセスとプラクティスの正確な定義について論じ出すと長くなる
ので、ここでは大雑把に次のように捉えてください。

プロセス：業務全体から見た個々の過程

プラクティス：個々の仕事のこなし方



*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ]　(4)プロセス中心のスタイル
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

プログラマの多くは「12のプラクティス」に感動するでしょう。

しかし、そのプログラマもやがてプロジェクトマネージャとなり、
複数のプロジェクトの管理をする立場になると、次のようなことを
やり出します。

・それぞれのプロジェクトを分析し、各種プロセスに分割する。
・個々のプロセスのインプットとアウトプットを規定する。
・各種プロセス内の作業項目を洗い出す。
・プロセス間、プロセス内の無駄な作業を排除する。
・個々の作業項目について、最も合理的なやり方を考え、作業量を
　見積もり、メンバーに仕事を割り振る。
・複数のプロジェクトで似かよった仕事は、同じ方式で行う。
・作業を可能な限り、定型化する。
・臨機応変の仕事や非公式の仕事を排除するというよりも、それを
　定型的な仕事に取り入れる。


これは管理者として正しい姿勢です。

そして、これがプロセス中心のスタイルなのです。



*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ]　(5)プロセス中心の欠点
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

ジョン・シーリー・ブラウンとポール・ドゥグッドは、「なぜITは
社会を変えないのか」の中で、プロセス中心の考え方を「組織に
しっかりとした形と方向性を与える」と高く評価しています。

しかし、同書の中で、彼らは、コピー機の保守技術者の行動を分析し、
厳格なプロセス中心を推し進めると下記の弊害が出てくるという
指摘もしています。

・技術者たちを「横方向の」資源(仲間同士の情報)から切り離してしまう。
・組織を臨機応変の行動や新しいアイデアに対して無関心にしてしまう。
・現場で起きている絶え間ない変化から、組織を切り離してしまう。


ソフトウェア開発においても、厳格なプロセス中心主義を推し進めると、
同様な弊害が出てきます。

XPはそれに対するアンチテーゼなのです。

「プラクティス中心で行こう！」という提案なのです。



*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
[保存できないエディタ]　(6)プラクティス中心の欠点
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

それなら、プラクティス中心主義に欠点がないのかというと、
そのようなことはありません。

下記はジョン・シーリー・ブラウン、ポール・ドゥグッドが「なぜITは
社会を変えないのか」で指摘している、プラクティス中心の危険性です。

・既成の公式や構造の効用をあまり重視しなくなる。
・それ自身があまりにも独立して進化し、そのためにあまりにも
　ゆるやかに組織と「つながれた」状態になる。

XPもまたこのような危険性をはらんでいるのでしょう。



そして、ジョン・シーリー・ブラウン, ポール・ドゥグッドは、
プロセス中心とプラクティス中心のどちらかを選択するのではなく、
両者のバランスをとることが重要だと主張しています。

「グループがそれ自身の新しい知識を十分育てられるだけ緩やかでは
あるが、同時にその知識をプロセスに応用できるだけのしっかりした
つながりの構築」が必要だと主張しているのです。



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

次回発行予定は、12月中旬です。

乞うご期待！！



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

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

したがって、第一の読者としては、慶の社員（正社員・契約社員）及び
慶と契約している個人事業主を想定しています。

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


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

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



--------------------------------------------------
発行：
株式会社 慶
　代表取締役  蒲生 嘉達