エクストリームプログラミングについては、基本情報技術者試験で見かけた程度で、単語としてなんとなく知っているくらいでした。そんな中、先輩から「一度読んでみるといい」と勧められたことをきっかけに、本書を手に取りました。
私のエクストリームプログラミングのイメージは進撃の巨人に出てくる「長距離索敵陣形」です。
細かく軌道修正しながら最終的に目的地に辿り着くために考案されたものです。エクストリームプログラミングでは短いサイクルでデプロイを行い、次に実装するフィーチャー（機能）を決めます。これを繰り返していくことでソフトウェアを作成します。
エクストリームプログラミングでは価値、原則、プラクティスについて書かれています。プラクティスとは手段のことです。
プラクティス
プラクティスは様々紹介されますが、全てを導入しないといけないわけではなく、そのときのチームに最適なプラクティスを選定して導入します。なので、プラクティスを一つ導入するだけでもエクストリームプログラミングと言えるでしょう。
価値
価値とは何を大切にするかです。エクストリームプログラミングでは、コミュニケーション、シンプリシティ、フィードバック、勇気、リスペクトの5つをあげています。
これらは互いに作用し合います。どうすればシンプリシティを保てるか考え議論し、それらをフィードバックして振り返ります。こうしてチームにプラクティスを蓄積していくのです。
変更には億劫になりがちです。ですが、価値を満たしているのであれば勇気を出して実践すべきです。
以上4つを支える価値がリスペクトです。互いにリスペクトがあれば勇気のある指摘もできるでしょう。
原則
原則はプラクティスと価値を結ぶものです。抽象的な考え方（価値）からはどの手段を取ればよいか明確にならないことも多いです。どのプラクティスを使用するかの指針となるのが原則です。
相互作用
自社と他社、会社と個人、チームと個人、開発と保守など様々な関係がありますが、WIN-WINになるようにしたほうがよいという原則です。これを使えば導入したいプラクティスが誰の邪魔にもならずに導入できます。
多様性
チームメンバーが様々な視点から問題にアプローチできます。衝突することもあるかもしれませんが、互いにリスペクトしていれば勇気をもって衝突できます。
振り返り
成功失敗の原因を振り返り知見とします。フィードバックはこの原則に従っています。
流れ
開発における流れを生み出すことです。テストを書く、実装、デプロイをなるべく短い期間でサイクル的に行います。そうすることでフィードバックの機会が増え、軌道修正を行いやすくなります。
機会
問題に直面することは機会です。今まで使ってこなかった原則、プラクティスを実践する機会であるととらえるとチーム、個人の成長につながります。
冗長性
一つの問題に対して複数の解決策を実行しましょう。解決策が間違っていても他のもので問題をとらえることができるかもしれません。どの解決策が的確か判断できるようになってから解決策を減らしていきましょう。
失敗
考えついたことを頭の中で解決するより試して失敗してみましょう。失敗は経験となり、失敗して選択肢をつぶしていくことが確実な道となることが多いです。
品質
品質を上げることとプロジェクトを早く進行させることは同じ意味です。品質が高いソフトウェアは変更に強く進行を妨げることはありません。最高な方法を思いつかない場合は思いついた中で最高の実装をしましょう。そこから少しずつ品質の高いものに移していけばよいのです（ベイビーステップ）。
主要プラクティス
全員同席
全員が同じスペースで開発を行います。もちろん、個人的なスペースも用意しますが、できるだけ多くの時間を共有します。人間は、同じ場所で同じことをしていると、自然とコミュニケーションが取りやすくなるものです。このプラクティスによって、コミュニケーションの価値を得ることができます。
ワークスペース
プロジェクトの進捗状況が15秒で把握できるようなものを用意しましょう。たとえば、ホワイトボードに「課題」「作業中」「終了」の枠を設け、付箋を貼っていく方法があります。こうすることで、全員の意識を自然に共有することができます。意識しなくても目に入る工夫が望ましいです。
ペアプログラミング
2人でプログラミングを行う手法です。常にコミュニケーションを取りながら作業することで、新しい解決策が生まれることがあります。一人では詰まってしまうような問題も、素早く解決できるかもしれません。このプラクティスは、1日中行うものではなく、数十分程度で効果が得られるものであり、長時間の実施には向いていません。
ストーリー
顧客に見える単位で計画を立てましょう。ストーリーで重要なことは、すぐに工数を見積もることです。そうすることで、顧客と開発チームが話し合うことができます。ストーリーの重要性と工数を把握したうえで、双方が納得して優先順位を決めることが可能になります。
週次サイクル
1週間分の計画を立てて行動しましょう。前週の振り返りから始め、今週実装するストーリーを選定し、自動テストを書き、それが1週間以内に動くようにします。これは、「流れ」と「振り返り」の原則を活用していることがわかります。
四半期サイクル
週次サイクルを四半期単位でバージョンアップしたものです。両方を組み合わせて目的地を設定し、週次サイクルで軌道修正を行いながら、四半期の目標を達成するようにしましょう。
ゆとり
「流れ」は繰り返し実行することで生まれるものです。たとえば、週次サイクルで実装するストーリーを毎回無理に終わらせている場合、それは良い流れとは言えません。少しのゆとりを持つことで、自然な流れを作ることが大切です。
10分ビルド
プロジェクトのビルドを、テストの実行を含めて10分以内に完了させるようにしましょう。継続的にデプロイできなければ、柔軟な軌道修正は難しくなります。デプロイに毎回時間がかかるようでは、継続的インテグレーションは実現できません。
継続的インテグレーション
数時間以内に統合とテストを行うようにします。常に動くプログラムを作ることが重要です。
テストファーストプログラミング
コードを書く前に、まず失敗するテストを記述し、それが成功するように実装を進める手法です。このプラクティスは、さまざまな問題を解決できます。開発をテストと実装に分けることで、実装に没頭しすぎることを防げます。また、テストの記述が難しい部分は、設計の見直しが必要かもしれません。
インクリメンタルな設計
設計には毎日手を加えるようにしましょう。プロジェクトの初期段階ですべてを決めるのではなく、進行に応じて最適な実装を目指します。進めていくうちに当初の設計と合わなくなることもあります。そのとき、設計が古いままだと障害になります。実装がその時点で最適であるならば、設計もその時点で最良の状態に更新する必要があります。
まとめ
冒頭でも述べた通り、これらすべてのプラクティスを必ず使用しなければならないわけではありません。また、ここで紹介したプラクティスがすべてというわけでもありません。重要なのは、プラクティスそのものにとらわれることではなく、自分自身や自分たちのチームがプロジェクトにおいてどのような価値を大切にしたいのかを明確にし、その価値を実現するための手段としてプラクティスを選択・工夫・創出していくことです。
私自身、これらの考え方を学んでみて、プロジェクトに対する見方や向き合い方が少しクリアになったと感じています。ただやり方をなぞるのではなく、「なぜその手法を使うのか」「何のためにそれをやるのか」といった視点を持てるようになったことが、大きな収穫でした。
そのようにして導入された考え方や手法が、自分たちにとって意味のあるものであれば、それはすでにエクストリームプログラミングの実践といえるでしょう。
まずは、取り入れやすいものから導入してみましょう。チーム単位でなくても構いません。たとえば、個人で週次サイクルを始めてみることも立派な一歩です。自分やチームの状況に合わせて、小さな改善を積み重ねていくことが、より良い開発と成果につながっていきます。