# エクストリーム・プログラミング（第Ⅱ部　XPの哲学）
## 第17章　はじまりの物語
XPのはじまりは、1996年2月にクライスラー社の給与計算システムのパフォーマンスを筆者がコンサルタントとして確認した時であった。本番稼働まであと2ヶ月の状況が5ヶ月間変わっていなかった。正しい計算もままならず、チームは不信感を極め、疲れ切っていた。

ここでXPを取り入れ、小さなチームで最初からやり直すことになった。
まずはチームメンバーにインタビューし、繰り返していく毎に少しずつプロジェクトの体制に慣れていった。筆者は必要と感じたものをできる限り取り入れ、それ以外は無視する振り切った内容で最初のXPを始動させた。
デイリーデプロイ、自動テスト等の基礎が整ったチームは、主体となって手順策定やツール作成、スキル取得、人間関係の醸成に取り組んでいった。

最初のタスクであるプロジェクト完了までの見積もりの設定は、ストーリーを作成しレビューし、最初に実装する最小限の機能を顧客に選んでもらうことで、プログラマーが「初めて信頼できる見積もり」とうなる見積もりが完成した。
チームは3週間ごとにストーリーを実装していき、順調に進むと思われた。だが、世の中そう甘くはない。計算は完成したものの、出力部分のテストを怠りエラー。何とか予定の1997年1月より3か月遅れで本番稼働にこぎつけた。

その後3年間稼働の後2000年に停止となった。継続保守されなかった理由として、この頃には言語がSmalltalkからJavaへと変わっており、旧型言語の保守コストがかかるためであった。技術的あるいはビジネス的な手法の変化が予算の優先度を左右するビジネスニーズに変貌していったのである。

だが、プロジェクト自体は成功であった。信頼性が高く保守や拡張も簡単で、アーキテクチャは柔軟で、欠陥率も低かった。また、オブジェクトテクノロジーが大規模なデータ処理に適すると証明し、ビジネス的にも成功であった。
ここからXPが世に広まっていくのである。

## 第18章　テイラー主義とソフトウェア
* **フレドリック・テイラーの「科学的管理法」**：工場の生産性を体系的に向上させる厳密で説得力のある論拠が示されている。
* テイラー主義では**実際の作業を観察したうえで、より良い方法の仮説を立てて実験を行う**のが「唯一最善の方法」である。：**仮説検証の根拠**
* 一方、テイラー主義にはいくつかの欠点もある。
* **仮定が単純**
* 物事は通常計画通りに進む
* 局所最適化が全体最適化につながる。
* 人はほぼ代替可能で、何をすべきかを指示する必要がある。
* **計画立案者（経営）と実行作業者（現場）が分離されている。**：現場の労働者はただの「歯車」にすぎず、**経営陣からの「上から目線」による現場への強要が起こる。** →無意識にこの社会構造が浸透しており、XPには全く適さない。
* **品質管理部門が置かれている。**：**現場の怠慢抑制**のために品質管理を置いた経緯があるが、 **品質とエンジニアリングを分離してしまうと、品質管理の仕事は懲罰的なものになる。** →ソフトウェア開発組織の大部分はテイラー主義。

→変化の激しい時代に実際に動く柔軟性の高い安価なソフトウェアを開発するには、**コミュニケーションとフィードバックを重視し、根付いたテイラー主義の欠点を打ち破らなければならない。**

## 第19章　トヨタ生産方式（→リーン開発）
**トヨタ生産方式（TPS:Toyota Production System）** は、**リーン開発の原点**となる生産方式である。車の製造プロセスにおける**無駄を徹底的に無くしてコストを下げ、利益率の高い**車を多く生み出してきた。
### トヨタ生産方式の特徴
* **現場の全員が、品質に責任を持つ。組織全体が品質部門である。**
* **欠陥を発見すれば即座にラインを停止し、修正に取り掛かる。（→誰もが安心してラインを止められる。心理的安全性も高いのでは？）**
* **最大のムダは「作りすぎのムダ」**

使われないものを作ってしまうと労力の行き場がなく、次の工程ですぐに使われないと情報の価値が失われる。長くなればなるほど保管費用がかさみ、最悪の場合撤去費用もかかる。
**ソフトウェア開発には「作りすぎのムダ」が満ち溢れている。** ドキュメント等の「価値を生み出さないもの」を作りすぎず、デプロイ間隔を短くして次々と使っていく方が良い。
**TPSの多くの側面は、ソフトウェア開発との強い類似性がある。**

## 第20章　XPの適用
### XPの難しさ
XPは素晴らしい開発理論であるが、実社会でXPの適用を行うのは**思いのほか難しい。** 自分たちの思い込みや信じたものの影響で、**無駄が生じていることに気づきにくく、習得するには相当な時間と経験が必要なためである。**
XPの採用には多くの方法があり、正しいスタイルというものは無い。自分なりのやり方で問題に取り組み、開発のビジョンを確立していく。
### チームでXPを維持する
チームでXPを行うと、常に**元のやり方に戻ってしまう**リスクを抱える。こうした組織的後戻りは対処が難しい。
さらに悪いことに、組織から見てXPのチームは、XPでない他チームと比べて **「献身的」という主観的な評価で大きく下回る。** これは、計画を守って取り組むゆえに他チームと比べて多くの残業をしておらず、会社に献身的でないと判断されるためである。
**チームは組織の目標達成に尽力することを強調して、自分たちの働き方がどのように目標を支えるのかを示す必要がある。**

### XPを組織に浸透させる
最も有効なのが、**経営幹部の中からXPに理解のある人を見つけることである。**
上層部の理解が得られやすく、会社とのやり取りがスムーズになる。
もっとも、支援してもらえる経営幹部に**説明責任を果たす必要がある。**
一方経営幹部側も、**組織変革は1人からでも始められる。自らが見本を示すことは強力なリーダーシップとなる。** 逆にプログラマーの提案を自ら試そうともせず踏みにじるような対応は信頼を壊す。
**まずは「自分を変えてみる」ことが大切である。** そこからその変化の成果を他の人たちにも広げていけばよいのである。

### 学習とカイゼン
継続的改善は、絶え間なく変えていくというよりも、**何かを変更して効果を観察して、変化の意味を飲み込んで定着させていく**ことの繰り返しである。
つまり、**カイゼン方法が分かった時にすぐに改善し、変化によるフィードバックを得てさらなるカイゼンへと繋げていく**のである。
一方で、新しいプラクティスでパフォーマンスが落ちた場合は、変更を元に戻して根本的な原因の解決にあたるべきである。
カイゼンは、急速に進むチームもあれば大惨事になるチームもある。急速に進むチームには以下の共通点がある。
* チームと組織がXPを受け入れ、**価値を統一させている。**
* チームが**失敗の喪失感等の苦痛を最近味わっており**、劇的な変化を求めている。
* チームに**変化を受け入れられる力**がある。

### コーチの選択
**「コーチ」は、チームの一員であり、独立した視点を持つ。**
最初は改善箇所を特定して、それに対処する実験をリードする。
価値や原則、プラクティスは自分で学んだり、失敗を犯したりするのも良いが、経験した人から学んでも良い。**経験豊かなコーチはチームの「学び」を促進する。**
コーチはコミュニケーションのボトルネックを発見して対応する。チームの不安を解消する重要な役割を果たす。一方で、コーチ自身の経験を基にうまく誘導し、チームにプラクティスを使う気にさせるのも役割の一つである。
**→コーチはチームのプロセス全体に責任を持ち、持続的なペースで働き、継続的な改善を行えるようにする。**

こうしたコーチの選択は、重要かつ困難である。以下のような存在である必要がある。
* **XPの価値を理解し、リードできる存在**
* **経験に裏打ちされた豊富な技術スキルを持つ存在**
* **チームに自立を促せる存在**

### XPを使うべきでないとき
XPを使うべきでないときは、**実際の価値とXPの価値が相容れない組織**である。
具体的には実際の価値が「**秘密、複雑、孤立、臆病、不遜**」である場合、XPの価値とは正反対のため使用すべきではない。

## 第21章　エクストリームの純度
### 私のチームはエクストリームですか
上記のような質問に、Yes/Noや数値的答えを期待するのはおかしい。
本質的な質問は「**チームメンバーが納得できることを、持続可能な方法でやっているのか**」である。
**チームが分散しており、理論的にXPでなくても、プラクティスは実践でき上手く回っているチームも多い。** XPはあくまでガイダンス、チャレンジ、説明責任を提供するために、価値や原則、プラクティスが用意されている。大切なのはXPクラブの会員になることではなく、**人間関係とプロジェクトの成功である。**
### 認証と認定
コンピューティングの分野では、法的責任を負うような認証は存在しない。
代わりに、リーダーの認定モデルが魅力的である。
ラ・レーチェ・リーグでは、組織の代表者とリーダーが、**自らの振る舞いに全面的な責任を担い、自己申告した内容にお互いが同意したことを公認する。** 価値が統一され、**公の「認定」** がなされたことになる。
このモデルは、現在のコンピューティングの分野で行われている認証よりもはるかに良い。XPのプラクティスを取り入れ、XPerとなり、徐々に明確な存在感が確立され、**雇用者と被雇用者の期待を一致させる**ことができれば、リーダーとして相互同意できるだろう。

## 第22章　オフショア開発
オフショア開発とは、小さなチームが全員同席している、**XPのプラクティスを生かしやすい「スイートスポット」以外にXP適用する**開発方法である。
オフショアという言葉には権限の不均衡が伴うため、ここでは「**マルチサイト（複数拠点）**」に置き換える。
**XPはマルチサイトでも運用可能である。**
### マルチサイト開発で重視すべきこと
* 距離が離れているため、**コミュニケーションはより密に取る。**
* **シンプリシティの実現**をより重視する。
* チームメンバーの**多様性をリスペクト**する。
* 一部プラクティスの修正する。
* **単一のコードベース**は互いの接点として重要になるため、より達成を重視する。
* **相互利益の原則**に則る。
* 誠実さをみせ、**説明責任を果たす。**

### ソフトウェア開発の未来
これまで大規模で高コストな説明責任を果たさない請負業者が牛耳っていたソフトウェア業界に、小規模で低コストで説明責任を果たすXPチームが挑み、置き換わっていくだろうと筆者は予測する。
各国が今後既得権益を守れば、コストの低い国々がカイゼンのインセンティブを持てず、ソフトウェア開発は停滞するだろう。
世界中のプログラマーが開発の様々な無駄を排除する動きが広がれば、グローバル市場は活気づき、多くの雇用がもたらされるだろう。
あらゆるプログラマーが価値の高いソフトウェアを生み出す挑戦を受け入れてほしいと筆者は願っている。

## 第23章　時を超えたプログラミングの道
チームの成功には、チームと関係者による**不均衡の解消**が欠かせない。
互いに**同じ関心ごと**を持ち、**同じ方向**を向いていなければならない。
こうした**調和とバランスこそXPの大きな狙いの一つ**である。それ自体もいいことであるが、**集まった同士の絆を強くすること**こそが最も大きなタスクである。
かつて建築家のアレグザンダーが複数のビジョンを理解し、両方の観点を組み合わせて調和する取り組みを行ったが、ソフトウェア開発では材料や人間関係に縛られていないため、**独自のバリューを持ったプロダクトやサービスを生み出す機会を持っている**のは、アレグザンダーと比べて大きな強みである。
そのためにも、チームの中で権限や責任を共有する担当者を設置する取り組みが必要である。失敗のリスクはあるが、**個々人ができることをやってチーム全体で協力し、チームワークを発揮できれば、想像を超えた成果を上げることができる。**
近年バイオロジーが勢力を伸ばしており、コンピューティングはこのままでは抜かれてしまう。**次の50年にソフトウェアの居場所を用意できるような取り組み**が求められる。

## 第24章　コミュニティとXP
**コミュニティは、経験を共有したり安全に話せる場所を提供する空間である。** ソフトウェア開発を支える偉大な遺産である。
コミュニティでは、新しい経験を評価したり、聞いてほしい話に耳を傾けたりと、**お互いに支え合い、受け入れてもらえる安心感が必要である。**
また、コミュニティは外の視点を取り入れることで**共に勉強する場**にもなり、コメント一つに責任を持つ**説明責任を果たす場**にもなる。

## 第25章　結論
**最初に自分自身をカイゼンしなければ、何も始まらない。
XPのカギは誠実性である。つまり、本当の価値と調和した行動をとることである。**

**XPの価値は、ビジネスの世界で実践すべきものである。快適な生活のみならず、関係者全員がお互いリスペクトした人間関係によって新しい動き方を開発するのである。**

###### tags: `読書`