溜池随想録 #13 「XP（エクストリーム・プログラミング）その２」　（2010年6月）

XPのプラクティス（続き）

　今回は、前回に引き続きXPのプラクティスを紹介する。
 

(7) 小さなリリース（Small Releases）
　システムが一部でも動く段階になれば、すぐに発注者に引渡しを行う。XPではこうしたリリースを小規模に何度も繰り返す。ウォータフォールモデルでは最終段階にならないとシステムの引渡しを行わないために、終盤になって要求仕様の誤りが発見されてプロジェクトが火を噴くことがある。しかし、XPの場合には、この小さなリリースを頻繁に繰り返すことによって、情報システム開発プロジェクトがもつリスクを着実に低下させることができる。
　リリースされたシステムは、できるだけエンドユーザーによって利用され、チェックされることが望ましい。少しでも早く実際のユーザのニーズに応えることにもなるし、実際に使ってもらうことによって改善点を明らかにすることができる。
 
(8) コーディング標準（Coding Standard）
　コーディング標準とは、プログラムを書くときのルールである。最初から厳密かつ広範なルールを作ろうとすると時間を浪費してしまうことになるので、最初は単純なルールから始め、徐々に発展させることが望ましい。重要なことは、コードがチームの誰もが見慣れた書き方になっていることである。コーディングのルールが決まっていると、ペア・プログラミングが円滑に進むし、リファクタリング、コードの共同所有が容易になる。
 
(9) コードの共同所有（Collective Code Ownership）
　前回、ペア・プログラミングで述べたように、誰とペアを組むかはローテーションによって変わり、かつ担当する部分も変わる。したがって、開発中のコードに特定の所有者はない。つまり、チームの全員がすべてのコードを共同で所有しており、チームの誰もが自由にコードを修正・変更できる。もちろん、コードに手を加えてプログラムを壊すことは許されない。壊したら必ず直さなければいけない。
　コードの共同所有によって、コードはたくさんの目でチェックされることになり、欠陥が減り、品質も上がる。また無駄のないシンプルなコードになって保守性も向上する。
 
(10) シンプルな設計（Simple Design）
　XPでは、コーディングと同時に設計を行っていく。このため、XPでは設計を軽視していると見られがちである。しかし、実際にはコーディングを進めながらプログラムの設計を行った方がより合理的である。なぜなら、プログラムの設計は機能を具体的にどうプログラムに置き換えるかを考えないとできない作業であり、コーディングの工程と重複する部分が大きいからである。XPではシンプルなコードが推奨されている。それは、すべてのテストをパスし、重複する部分がなく、何をしたいのかが明確に表現されており、必要最小限のクラスとメソッドしか含まないコードである。
 
(11) システム・メタファー（System Metaphor）
　XPでは、開発すべきシステムの構造や機能を理解するために、分かりやすい比喩を用いる。イメージできるモノに喩えることによって、チーム全員がシステムのイメージや機能を把握することができる。
 
(12)　持続可能なペース（Sustainable Pace）
　これは当初「週に40時間（40-Hour Week）」と呼ばれていたプラクティスである。もちろん、週に40時間以上労働してはいけないという意味ではないが、ソフトウェアの開発作業は極めて高度な頭脳労働であるので、XPでは適切なペースで作業を進めることが求められている。つまり、過剰な残業や休日出勤で疲れていたのでは、ミスが多くなり、よいプログラムが書けない。その結果として生産性もソフトウェアの質も低下するだろう。必要な時には残業をすることもあるだろうが、それが常態化してはいけない。高い生産性を保つために、いつまでも持続できるペースで仕事をしようというプラクティスである。
 
　前回と今回でXPのプラクティスについて説明したが、読めば分かるように、それぞれのプラクティスは相互に関連しているものが多い。したがって、すべてのプラクティスを採用することが理想的である。
ただ、現実には一度のすべてを採用するのは難しい場合もあるだろうし、中にはペア・プログラミングのように単独で採用しても、それなりの効果を発揮するものもある。
XPの採用については、経験者がいることが望ましい。もし、チーム内に経験者がいない場合には、専門家の指導を受けることをお勧めする。
 
　次回はスクラム（Scrum）の紹介をしよう。