# エクストリーム プログラミング（第I部　XPの探究　第1章～第9章）
## 第1章　XPとは何か
エクストリームプログラミング(XP)は、仕事の邪魔になっている習慣やパターンを手放すソーシャルチェンジな取り組みである。
また、自分のできることをオープンにして、未熟な思い込みを克服して、自分の居場所を見つける自己超越プロセスでもある。
そして、そのプロセスの中で開発者としてビジネスに繋がるコードを書くことである。
以上から、生産性向上と成功による自信は、良好な人間関係・良好なビジネスを作り出す。

XPではベストを尽くし、失敗してもその結果を受け入れる心構えが大切である。そのためには成功に向けた準備が必要である。
### XPの方法論の特徴（第1版）
* 開発サイクルが短時間である。
* 迅速なフィードバックを得られる。
* 計画手法がインクリメンタル（漸進的）である。
* 実装スケジュールが柔軟である。
* 問題の状況把握や、欠陥修繕に素早く取り掛かれるよう、自動テストを信頼している。
* システムの構造や意図を伝えるために、ソースコードなどを信頼し、口頭のコミュニケーションが大切である。
* 熱心な故人がお互いに協力し合う。
* チームメンバーの短期的な動機と、プロジェクトの長期的な利益の両方につながる。

### XPの方法論の特徴（第2版）
* 軽量である。
* 顧客に価値を持たすために必要なものだけを実施する。
* あらゆる規模のチームに使える。
* 急速な変化や要件に対応できる。

成功の鍵は個人の努力よりも、「人と人」のビジネスに関わっていることを受け入れることである。

### XPとは何か（まとめ）
* 効果のない古い習慣を捨て、効果のある新しい習慣を選ぶ。
* 自分が今日やるべきことを十分に理解する。
* 明日をより良くしようとする。
* チームのゴールに貢献した自分を評価する。
* ソフトウェア開発で人間としての欲求を満たす。

## 第2章　運転を学ぶ
運転とは、車を正しい方向に走らせるのではなく、常に注意を払って軌道を修正していくものである。
注意・適応・変更こそがXPのパラダイムである。
顧客はシステムの内容を「運転」し、チーム全体は開発プロセスを「運転」する。
こまめに軌道修正を加えて、短期間でデプロイしながら、ゴールに向かっていける。
一方、顧客はソフトウェアが次にどこに向かうかを毎週決める必要がある。チームの中の顧客は、目指したい地平線を心に留めておく必要がある。

## 第3章　価値・原則・プラクティス
* **プラクティス**：技術的な知識の理解→日常的な取り組み（テストを先に書き始める等）
* **価値**：ある状況における好き嫌いの根源→目にするものや考えていることなどを判断する基準に。
* **価値はプラクティスに目的を与え、プラクティスは価値の証拠となる。→価値は明確に。**
* 価値は普段の生活でも同じ価値観であることが望ましいが、プラクティスは状況によって大きく異なってくる。
* **原則**：分野に特化した活動の指針のこと。価値とプラクティスのギャップを埋めてくれる存在。
* **プラクティス（この本を読む）があってもXPができるようになるわけではない。実際にやってみて原則を学び、コミュニティーで自分の価値を共有していく必要がある。**

## 第4章　価値
開発に関わる人間は、プロダクト制作で**何が重要であるかの感覚**を持っている。だが、その感覚が正しいとは限らない。
よく知らないのに個人的な価値観で知っていると勘違いし、個人行動に集中してしまうのはチーム活動として大問題である。
最も重要なのは**チームが共通のスタイルを目指すかどうか**である。
### 開発を導く5つの価値
* **コミュニケーション**：**チーム活動で最も重要な項目**である。誰かが問題の解決策を知っているにもかかわらず、それが変更権限者に伝わらないのは問題である。また、情報の欠如により問題が発生することもある。そこで、問題発生時には**コミュニケーションの欠如が原因かを調べて**対処する一方、チーム内で問題及び解決方法を共有する**チームコミュニケーションの場**を設けると良い。
* **シンプリシティ**：「**最もシンプルで、うまくいきそうなものは何ですか？**」最も知的な項目で、シンプルな解決策を目指す。シンプルすぎてうまくいかないものではなく、無駄な複雑性を排除するシンプルなものが求められる。**コミュニケーションからシンプリシティは生まれ、シンプリシティはコミュニケーション量を少なくできる。**
* **フィードバック**：経験する前に方向性を決めてしまうとすぐにダメになる。これは**不確実性による変化が避けられない**ためである。これを乗り切るためには、フィードバックが必要である。
* **正しくつくる方法がわからない場合（仮説検証が必要）、今日は正しくても明日は違う可能性がある場合、全てを正しく作ろうとして時間がかかり過ぎてしまう場合（ウォーターフォール型？）** は、最初から正しい方向性を決める**例外になるケース**である。
* フィードバックには、アイデアへの意見や実装したときのコードの状態、テストの書きやすさ、実行しやすさ、実行したアイデアが機能しているか等、様々な種類がある。
* **勇気**：チームを支配する**恐怖に立ち向かう価値**である。時に行動の姿勢として、時に忍耐として現れる。ただし、価値のバランスを考えずに最優先にするのは良くない。
* 勇気を持った真実の告白は、コミュニケーションや信頼の強化につながる。
* 勇気を持って新しい解決策を見つければ、シンプリシティが促進される。
* 勇気を持って現実の具体的な答えを求めれば、フィードバックが生まれる。
* **リスペクト**：これまでの4つの価値は、リスペクトを指し示している。関係者は人間として等しく重要である。そして、人間性と生産性を同時に高めるには、チームに対する個人の貢献をリスペクトする必要がある。
* その他：安全性、セキュリティ、予測可能性、生活の質など。

## 第5章　原則
### 人間性（Humanity）
人間性の原則によって、多くの方法論がその効果を失っている。欲求を満たさず、弱さを認めず、強さを生かせないソフトウェア開発は必要ない。
まずは以下の項目が必要である。
* **基本的な安全性**：身体や生活に危害が加わるようなものが存在しないこと。
* **達成感**：所属する社会に貢献する機会や能力。
* **帰属意識**：グループに所属して、承認や説明責任を受け取ったり、共通の目標に貢献したりすること。
* **成長**：スキルや視野を広げる機会。
* **親密な関係**：他人を理解して、他人から深く理解されること。
以上はビジネスニーズと個人の欲求の両方を満たすものである。
チームによるソフトウェア開発が難しいのは、個人の欲求とチームのニーズのバランスを保つことである。
優れたチームとは**メンバーたちが信頼関係を築いてから共に働き、全員が自分らしくいれるチームである。**
また、私生活の話題、個人的な話題、オープンな話題と**うまく区別できれば、仕事のコミュニケーションが効果的になる。**
### 経済性（Economics）
コスト度外視の技術的な成功は、ビジネス的には失敗である。
ビジネスバリュー、ビジネスゴール、ビジネスニーズを満たさなければならない。
* 貨幣のタイムバリュー：時が経てば経つほどバリューは高くなる。早めにお金を稼ぎ、あとでお金を使う方がバリューは高い。
* インクリメンタルな設計：設計投資を最終責任時点まで遅らせる。**不確実性に対応しやすい。**
* 利用都度課金：フィーチャーのデプロイ直後から収益を得られる。
* システムやチームのオプションバリュー：他のタスクへの再利用できるコードなどはバリューを高める。
### 相互利益（Mutual Benefit）
あらゆる活動は、**関係者全員の利益**となる必要がある。**最も重要で、最も難しい原則である。**
コンピュータービジネスは人間のビジネスであり、仕事上の人間関係を維持することが大切である。
一方で大量の内部ドキュメントなど、相互利益を破壊するプラクティスもある。
相互利益とは、現在の自分、将来の自分、顧客に対する利益を求めるプラクティスである。（3者winな関係）
### 自己相似性（Self- Similarity）
自然では、うまくいった形状を見つけるとあらゆる所で採用しようとする。
ソフトウェア開発も同様に、規模が違っても解決策はあらゆる開発で採用されている。
ただし、単純にコピーしても他の環境で上手くいくとは限らない。
### カイゼン（Improvement）
完璧は形容詞ではない。動詞である。
**カイゼンは、明日をより良くするために必要な気づきや理解を追い求めながら、今できる最高の行動をとることである。**
カイゼン自体はすぐに着手できるが、一朝一夕で完璧になるわけではない。
インクリメンタルな設計で長期計画をカイゼンしていけば、うまく機能させられる。
テクノロジー（プログラミング言語）はどんどんカイゼンされたのに、開発組織は硬直してきた歴史がある。**この両者のカイゼンを調和させることがカギとなる。**
### 多様性（Diversity）
チームで問題を解決するには、**様々なスキル、考え方、視点を組み合わせて考える必要がある。**
**多様性には衝突がつきものである。** だがそれは憎み合っているのではなく、2通りの解決策が提示されたということである。
相手の意見をリスペクトしたうえで自分の言い分を主張すれば、コミュニケーションは円滑になる。
**チーム全体のプラクティス**であることを忘れずに。
### 振り返り（Reflection）
**優れたチームはなぜ（Why）を考えて仕事をしている。なぜ成功し、なぜ失敗したのか。ミスを隠そうとはせず、その原因を明らかにして学ぼうとするのである。**
アジャイルのプロセスではチームが過去を振り返る場（レトロスペクティブ）を設けているが、こうした公式の場以外にも、個人がそれぞれの過ごし方を振り返って「なぜ仕事をしているのか」を考える必要がある。また、食事会などで複数人で振り返ることもできる。
### 流れ（Flow）
**ソフトウェア開発の流れとは、全ての開発作業を同時に行い、価値のあるソフトウェアの安定した流れを生み出すことである。**
「ビッグバン」インテグレーションは、できるだけ大きな塊で価値を届けようとする。デプロイやインテグレーションが減り、フィードバックが減って大きなリスクとなる。（ウォーターフォール型開発）
対して、**小さなバリューを何度もデプロイする考え方がある。** 例えばデイリービルドは毎日デプロイすることで、流れを意識している。
但し、コンパイルやリンクだけでは不十分。**一日一回確実に機能を動かすことで真の価値が生まれるのである。**
### 機会（Oppotunity）
**問題＝変化の機会**である。高みに到達するには、問題を切り抜けるだけでなく、学習やカイゼンの機会に変換しなければならない。
問題で得たフィードバックを機会へと変換し、それをあらゆる場面で実施することで、強みを最大化し、弱みを最小化できる。
XPを実践すると、必ず問題に直面する。エクストリームになるということは、**問題を個人の成長、人間関係の深化、ソフトウェアのカイゼンなどの機会に意識的に変換する**ことでもある。
### 冗長性（Redundancy）
一つの解決策が失敗しても、その他の解決策で惨事を食い止められる。
欠陥は無駄の排除に有効な信頼関係を蝕む。そこで、XPでは数多くのプラクティスで欠陥に対処する。
欠陥は一つのプラクティスでは解決できない。チーム内や顧客との信頼関係が維持できるようになるまで欠陥を減らせればそれで良い。
ただし、冗長性は無駄につながる可能性がある反面、目的の達成に必要な冗長性は残しておかなければならない。
### 失敗（Failure）
**失敗は重要な学びの場である。知識が身につけば無駄ではない。**
何をすべきかわからない時は、**失敗のリスクを受け入れる**ことが成功に近づく最短ルートである。
### 品質（Quality）
品質を犠牲にするのは効果的なコントロール方法ではない。**むしろ品質を高めることでデリバリーが高速化する。**
欠陥数や設計品質、開発経験を使って品質を計測できるようになった。品質が高まると、生産性や有効性などの指標がカイゼンされていった。
品質に求められるのは経済的要因だけではなく、**自分が仕事に誇りを持てるか**どうかも影響する。
品質のコントロールでプロジェクトを管理するには、スコープの追跡や選択を行うことで、優れた制御レバーになる。
また、同品質を高められるかわからなくても、今できることを精一杯やれば良いのである。
**大きな変更を効率的に、安全で小さなステップで行う。**
### ベイビーステップ（Baby Steps）
大きな変更は大きなステップでやりたくなるが、重大な変更を一気に行うのは危険が伴う。変更に不安がある人は、素早く変更をしようとする。
**ベイビーステップは、小さなステップを繰り返していくことである。** 大きな変更が失敗して大きな手戻りになるよりは、小さなステップの方が手戻りは小さい。
テストファーストプログラミングや、継続的インテグレーションなど。
### 責任の引き受け（Accepted Responsibility）
**責任は割り当てられないため、引き受けるしかない。**
例として、サインアップした人がその作業を見積もる方法がある。
**責任には権限が伴わなければならない。**権限がなければ、フィードバックを確かめたり利用したりする立場が存在しなくなってしまう恐れがある。

## 第6章　プラクティス
XPチームが日常的に行うもの。だが、価値によって目的を与えなければ、ただの機械的な作業になってしまう。
プラクティスは状況に依存するため、条件に応じてプラクティスを選ぶ。
但し、状況が変わっても価値を変えてはいけない。分野が変わった場合は新しい原則を採用する場合もある。
XPのプラクティスは絶対的なものとして記述している。今いる所からXP習得までの軌道である。
プラクティスは組み合わせるとより効果が高くなる。7章からは具体的なプラクティスのコレクションを取り上げる。
なお、プラクティスはあくまでカイゼンに至るまでの通過点に過ぎない。相互作用がその効果を増幅させる。

## 第7章　主要プラクティス
プラクティスのうち、他の行動に関係なく取り入れると役立つプラクティスを主要プラクティスという。
どれからでも、今からでも始められる。
### 全員同席（Sit Together）
最も基本的なプラクティスは、**チーム全員が一堂に会する場所を設け、全員が集まって仕事を行う方法である。**
チームがやりとりしなさすぎるのは問題である。なぜなら、システム開発は**あくまで人が開発する**のであり、技術的な処置だけでは限界があるためである。
全員が集まることで適切な量の会話により円滑に事が運び、**あらゆる感覚を使ったコミュニケーション**が可能となる。
いきなり全員を集めることが難しいならば、集まりやすい場の作成や、会議室で集まって仕事をする等段階的に取り組んでいく。（新型コロナ禍ではZoom等のミーティングツールが有効？）
但し、プライベートな空間はチームメンバーに安心感を与えるため、チームの準備ができる前に安心感を奪うのは逆効果である。
### チーム全体（Whole Team）
プロジェクトを成功させるためには、**チーム全体として、適切な目標や必要なスキル、帰属意識等を構築する必要がある。**
こうした成功に必要なスキルや視点をチームで共有し、**クロスファンクショナルチーム**を目指す。
自社への帰属意識、チームとして働く仲間意識、相互に仕事や成長を支援する意識といった、チーム感の醸成が必要である。
チーム人数は、開発チーム単位で12人、プロダクトチーム単位で150人を超えると分けると良い。12人が無理なく統率できる上限値、150人はチームメンバーの顔を覚えられる上限値である。
また、複数社の案件を掛け持ちするよりも、**1チームで作業に当たるとより生産性が高まる。**
### 情報満載のワークスペース（Informative Workspace）
**仕事の内容が一目で分かるようなワークスペースを作る。**
関心のある人が15秒で内容を把握できるような形が望ましい。
カンバンやタスクボード等での**詳細の見える化**と、バーンダウンチャート等の**進捗状況の見える化**を行うと良い。
### いきいきとした仕事（Energized Work）
チームメンバー全体が無理をせず、生産的になれる時間だけ働くことが大切である。
チームの制御を取り戻す最終措置として、残業による長時間労働を行いがちである。
しかし、個人単位で遅く残ろうとすれば、大事な「価値」を気づかずに失ってしまう場合がある。
体調不良だと生産性が上がらずチームに迷惑をかけるので、無理せず療養を行うべきである。
数時間単位でのインクリメンタルなカイゼンも可能なため、まずは日ごろの時間の使い方から見直すべきである。
### ペアプログラミング
2人1組で共にプログラミングを書いていく方法である。
具体的には次のような行動を行う。
#### ペアプログラミングでやること
* お互いにタスクに集中する。
* システムの改良について意見を出し合う。
* アイデアを明確にする。
* パートナーが行き詰まった場合、こちらが主導権を握り、相手の失望感を抑える。
* お互いにチームプラクティスの説明責任を果たす。

共有した事項はチームに持ち帰り、パートナーと素早く修正を行う。
満足感が高まる一方、ペアと組む時間が長く疲労度も高い。休憩を適宜挟むこと。
人間は交流とプライバシーの両方が必要である。そのため、ペアが互いにパーソナルスペースのリスペクトを持つことは重要である。
また、隣り合って作業を行うため、相手が不満を持ちそうな香水の匂いや衛生管理への配慮が求められる。
なお、公私混同を行うのはもっての外である。仕事上の承認と私的な好意の区別がつかないような行動は避ける。あるいはペアを組ませないようにする。
こうした個人間の問題の配慮も行う必要がある。
### ストーリー（Stories）
顧客に見える機能の単位を使って計画する。また、必要な開発工数の見積もりも行う。
また、ストーリーは早めに見積もる。最小限のコストで実現可能性が最も高い方法が得られるためである。
ユーザーストーリーマッピングを用いてストーリーの作成を行い、見積もりは基準ストーリーとの相対見積もりを行うと良い。
また、ストーリーに制約をつけることで見える像がより鮮明になる。
### 週次サイクル（Weekly Cycle）
週初めに、スプリントプランニングをはじめとした週次計画を立てる。顧客が実施するユーザーストーリーを選び、タスクごとに分けバックログを作成する。
これらをもとに、自動テストを書き、このテストのパスを週次デプロイに向けた目標とする。
計画づくりは必然的なムダ（価値を生み出さない）の一つである。できるだけ短くするようにしていく必要がある。
週次サイクルは、チームや個人が実験をするための手軽で頻繁な予測可能なプラットフォームでもある。
新たなワーキングアグリーメントの策定を目指した実験期間に使う事も可能である。
### 四半期サイクル（Quarterly Cycle）
四半期分の計画をまとめて立て、チーム、プロジェクトの進捗、大きなゴールの調整について振り返る。
四半期区切りは一般的に活用されており、外部との調整も立てやすい。
* チームの振り返りを行う。
* ボトルネックを特定する。
* 修正作業に着手する。
* 四半期のテーマを計画する。
* テーマに取り組むための四半期分のストーリーを選択する。
* プロジェクトを組織に適合させる全体像に集中する。
### ゆとり（Slack）
どのような計画にも、遅れてきたときに外せるような重要度の低いタスクを含めておき、余力を持たせることが必要である。
後から重要度の高いミッションが入ってきたときに容易に交換ができる。
また、やるべきことを確実に果たせば、どのようなものであってもムダの排除につながる。習慣化したオーバーコミットや士気の著しい低下、敵対的な人間関係などの改善につながっていく。
### 10分ビルド
システム全体を自動ビルドし、全てのテストを10分以内に終わらせることである。
10分以上かかると使用頻度が減り、フィードバックが得られなくなってしまう。
自動ビルドはストレスを開放するためのツールでもある。
### 10分ビルドの手順
1. 自動化する。
2. 変更した部分だけをビルドする。
3. リスクが高い部分をビルドする。
### 継続的インテグレーション（Continuous Integration）
変更したら自動的に統合してテストを行うことである。
非同期インテグレーション（変更ごとの統合）と同期インテグレーション（一定のメンバーで同時に統合）の2種類がある。
同期インテグレーションのほうが、チームメンバーとの振り返りの時間を取りやすく、チームとしてカイゼンする機会が増える。
### テストファーストプログラミング
TDDの考え方の一つ、最初に失敗する自動テストを書くことである。一度redな状態のテストを作ることで、以下のような問題を解決する。
* スコープクリープ：プログラムがあるべき姿を明確にでき、余計なコードを書かなくなる。
* 結合度と凝集度：テストをしやすい設計は、独立性が高い。（結合度は低く、強度は高い）
* 信頼：動く綺麗なコードを書ける意図を示せる。
* リズム：手順が決まっており、次に何をすべきかが明確になる。
### インクリメンタルな設計（Incrimental Design）
システムの設計を毎日最適化させることである。
これまでの開発方法：欠陥を修正するには、時間がたつほどコストがかかる。→すべての設計を一括で行い、その設計通りに作る。
インクリメンタルな設計方法：変更が増えるとコストがかかる。→ソフトウェアの変更コストを劇的に増やさない条件を作り出す。
小さくて安全なステップを繰り返し、経験を踏まえた後に設計すれば、最も効果的となる。
また、設計の改善箇所は、重複の排除が挙げられる。
繰り返し発生する変更のパターンを体系化した規律が「リファクタリング」である。
## 第8章 始めてみよう
XPパターンの取り入れは、一つ一つ行っていくと良い。新しい習慣の定着は時間がかかるため、適宜プラクティスの目的を思い出し、再検討する。
プラクティスごとに自分の立ち位置を見極め、自分の優先する変化に適したプラクティスを選択する。
不安からチームメンバーが抵抗感を抱き、元に戻そうとすることがある。大切なのは責任感や説明責任を促すことである。
カイゼンには密接な協力と、チーム全体の取り組みが必要となる。
どのような目的を持ち、どのようなプラクティスを行えばよいのかを測る指標として、プラクティスのマッピングが挙げられる。
チームの目標にあったプラクティスは何かを、図を描いて探っていく。

## 第9章　導出プラクティス
基本プラクティスから導出される発展プラクティスで、基本プラクティスの実践が前提となる。
### 本物の顧客参加（Real Customer Involvement）
**本来チーム全体には、顧客も含まれている。** だが、本物の顧客を参加させているチームは少ない。
本物の顧客がいることで、顧客の生の声を聞くことができ、**顧客が必要としないようなシステムを作るリスクを防げる。** →顧客開発
顧客に開発プロセスに参加してもらうことで信頼感が高まり、継続的な改善が促される。
### インクリメンタルなデプロイ（Incrimental Deployment）
古いシステムを新システムに置き換える時に、**一気にではなく徐々に引継ぎを行う**事である。
大きなデプロイは開発チームの疲弊を招き、失敗したときのリスクも大きい。そこで、小さな機能を少しずつデプロイし、マージやユーザー教育を行う。小さく行えば**変化への対応も効きやすい。**
### チームの継続（Team Continuity）
**優秀なチームは解散させず継続させる。**
大きな組織だと、チームの人員はあくまで会社の1資源にすぎず、プロジェクトが終わればチームも終わりである。可能な限り全ての人員を有効活用すべく上層部が立てた人員計画により、チームが解散してしまう事も多い。だが、それだけの問題で**人間関係や信頼の大切さを無視するのは経済的ではない。チームの継続と適度なローテーションを組み合わせる**ことで、安定したチームと知識と経験の継続的な広がりの両方を得られる。
### チームの縮小（Shrinking Teams）
チームとしての能力が高まったら、仕事量を維持しながら**少しずつチーム規模を縮小していく。** チームを離れた人は別のチームに入り、逆に自チームが少なすぎる場合に他チームと統合できる。
全員が忙しいと、チームの利用可能な資源を見落とすこともある。基本的なXPをしっかり実践し、**チームメンバーの誰かの手が空くまで、開発をカイゼンしていけば、規模を縮小しながらチームを継続できる。**
### 根本原因分析（Root-Cause-Analysis）
欠陥が見つかったら、**直ちに欠陥と原因を取り除く。
欠陥の再発防止だけではなく、同じ種類の過ちを二度と起こさないようにするのが目的である。**
欠陥がなぜ発生してしまい、なぜ阻止できなかったのかについて、「5回のなぜ」を用いて解いていくのが良い。この質問を経て、欠陥の中心に人の問題があることが分かる。
### コードの共有（Shared Code）
チームの誰もがシステムのあらゆる部分をいつでもカイゼンできるようにする。
もし基本プラクティスのチームに連帯感が無ければ、チームへの影響を考えずに変更を加えてしまうリスクがある。
最も簡単なコードの共有はペアプログラミングである。また、共同所有の必要条件として、継続的インテグレーションがある。
### コードとテスト（Code and Tests）
**永続的な保守対象は、コードとテストのみにすることである。** ドキュメントは、コードとテストから作り上げる。プロジェクトの重要な履歴の維持については社会的仕組みに任せる。
**コード及びそのテストこそが価値となりえる。** ドキュメントに価値は無い。また、少しずつ取り組みやすいため、インクリメンタルな設計が有効である。四半期サイクルが明確になれば、その分だけ仕様書は薄くなる。
**ソフトウェア開発の重要な意思決定は、「これから何をするのか」「これから何をしないのか」「どのようにやるのか」である。** これらの意思決定をまとめてお互いに補完できるようになれば、価値の流れがスムーズに運ぶ。
### 単一のコードベース（Single Code Base）
**原則としてコードの流れは単一で、ブランチに分かれない。**
ブランチに分かれた複数バージョンの維持は、**全体的な影響を視野に入れていない局所的な最適化**の可能性がある。単一のコードベースを妨げている根本的な設計問題を解決していくことで、複数バージョンは徐々に減らしていく。
### デイリーデプロイ（Daily Deployment）
**新しいソフトウェアを毎日プロダクションに反映する。** プログラマーの手元にあるコードと、プロダクションにあるコードが異なるのは、**プログラマーの意思決定につながる正確なフィードバックを得られない可能性があるためである。**
デイリーデプロイは**必要条件となる基本プラクティスが多く、難易度が高い。** ビルドの自動化、インクリメンタルな展開、そしてチームの信頼関係の醸成が完成して初めて実行できる。
大規模プロジェクトの場合様々なタスクがあるが、システムのユーザーエクスペリエンスが同じであれば、それ以外のあらゆるものはデプロイOKである。
### 交渉によるスコープ契約（Negotiated Scope Contract）
ソフトウェア開発の契約では、**期間、品質、費用を固定し、システムの明確なスコープは可変とし、継続的な交渉を求める。** また、長期的な契約ではなく、**短期的な契約をいくつも結ぶようにする。**
### 利用都度課金（Pay-Per-Use）
**システム利用に対する究極のフィードバックがお金である。
利用の都度お金を請求し、 そこから得られる情報をソフトウェア開発に直結させれば、カイゼンを推進するための性格でタイムリーな情報が得られる。**
電子証券取引システム、航空機座席予約システム等の実例がある。
反対に、ソフトウェアリリースごとに課金するリリース都度課金は、最低限の機能を開発したい供給側と、多くの機能を希望する顧客側とが相反し、両方が損するだけである。
また、定額制である**サブスクリプション**では、**定着率のフィードバック**を得ることができる。

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