第10回エクストリーム・プログラミングの原則と基礎プラクティス

この連載は、登場して20年が過ぎ、成熟期を迎えつつある「アジャイル開発」を解説します。アジャイル開発については、世の中にたくさんの書籍や情報があふれていますが、アジャイルコーチとして10年以上の現場経験をもとに、あらためて学び直したい情報を中心にまとめていきます。

第10回目のテーマは、「エクストリーム・プログラミング（XP）」です。前回は価値の解説をしたので、今回は原則やプラクティスを解説します。

この内容はUdemyで公開しているオンラインコース「現役アジャイルコーチが教える！半日で理解できるアジャイル開発とスクラム入門編」の内容を元にしています。

XPの原則
XPの原則：フィードバック
XPの原則：シンプルさを前提とする
XPの原則：変化を包容する
XPのプラクティス
XPの基礎プラクティス：全員同席
XPの基礎プラクティス：チーム全体
XPの基礎プラクティス：情報豊富な作業空間
XPの基礎プラクティス：活気のある仕事
XPの基礎プラクティス：ペアプログラミング
XPの基礎プラクティス：ストーリー
XPの基礎プラクティス： 1週間サイクル
XPの基礎プラクティス：四半期サイクル
XPの基礎プラクティス：ゆとり
XPの基礎プラクティス： 10分ビルド
XPの基礎プラクティス：常時結合
XPの基礎プラクティス：テストファーストプログラミング
XPの基礎プラクティス：インクリメンタル設計

XPの原則

一般的に語られているXPの原則は、第1版第2版で内容が進化したりした影響で、いくつか種類があります。よって、どれが本物かとてもわかりにくいので、今回はWikipedia（Extreme programming – Wikipedia ）にまとまっているものをベースに解説していきます。

XPの原則：フィードバック

まず「フィードバック」です。顧客からのフィードバックだけでなく、テストによるフィードバックも含みます。迅速なフィードバックを得るために、短いサイクルでどんどんリリースを繰り返したり、テストを自動化してくりかえし自動でテスト実行したりします。XPは迅速なフィードバックがもっとも重要だと考えています。

XPの原則：シンプルさを前提とする

次に「シンプルさを前提とする」です。シンプルさはXPの価値にも登場しました。

シンプルなものを複雑にしてはなりません。複雑なものをシンプルに解決していくのが重要です。短い期間で小さく開発するのもシンプルさにつながります。小さくコツコツリリースを繰り返していきます。

XPの原則：変化を包容する

最後に「変化を包容する」です。英語だと「Embracing change」。XPを知る人にとっては有名な言葉です。「embrace」は抱きしめる、包囲する、取り巻く、包容する、受け入れるといった「積極的に取り入れる」意味になります。

これまでのプロセスでは変化をコントロールしようとする方法が取られてきましたが、そうではなく変化を積極的に受け入れるのがアジャイル開発の大きな特徴です。変化を包容することで、より柔軟に開発を進めていけるようになるのがアジャイル開発の目指す方向性です。

XPのプラクティス

最後にXPのプラクティスを見ていきましょう。

プラクティスは状況に応じて実施していきます。また、プラクティス同士、関係し合う部分があるので、うまくつながると大きな効果を満たせます。たとえば、10分でビルドと常時結合を一緒にやることで、プログラム同士の結合がより確実に安全に行われます。

XPのプラクティスはたくさんあるのですが、現在でも使える色褪せない技術プラクティスが多いです。筆者自身も、顧客の支援でXPのプラクティスを中心に導入するケースは多くあります。

現在だと、コミュニケーションやチーム運営が中心のスクラムが主流となり、技術プラクティスがおろそかになってしまう現場も多いです。その結果、アジャイル開発が失敗するケースもあるので、ここでは、ちょっとだけ詳しく解説しておきます。

XPのプラクティスは基礎と応用に分かれています。

XPの基礎プラクティス：全員同席

ひとつめは「全員同席」です。

最近のオフィスだとあまりないかもしれませんが、昔のオフィスだとパーティションに区切られたりしていました。それはそれで個室のように使えるので「集中できる」といった便利な点もありますが、ソフトウェア開発は共同作業なので、パーティションが文字通り壁になってしまう場合もあります。

また、チームメンバーがそれぞれ別の場所で働いている場合、コミュニケーションが取りにくくなります。同じビルでフロアが別でも似たような問題がおきます。

繰り返しますが、開発は人間による共同作業ですので、全員同席というプラクティスはできるかぎり取り組んでいくと良いと思います。難しい場合でも、開発チームの島にひとつだけビジネスの席を作っておく・・・とかして、時間があるときにそこにきてもらって作業できるようにしてあげる・・・などの対応も有効です。

チームの座席配置は、チーム立ち上げ時によく考えてみるとよいでしょう。

XPの基礎プラクティス：チーム全体

2つ目は「チーム全体」です。

いわゆる職能横断型チームをつくるということです。職能横断型チームとは、プロジェクトを成功に導くためのすべてのスキルや知識や経験をもつ人達が集まったチームです。

職能横断型チームを作るのが難しい組織の場合は、アジャイル開発がなかなかうまくいかないケースも多いです。いいすぎかもしれませんが、職能横断的チームを立ち上げ、ふりかえりというプラクティスをくりかえし行えば、たいていの現場はアジャイル開発をうまく機能させられる気がしています。

まずは、職能横断型チームをできるだけ作り、難しい場合は、外部の協力を得て、その摩擦をできるだけなくす・・・といった対策を考えていくと良いでしょう。

XPの基礎プラクティス：情報豊富な作業空間

3つ目は「情報豊富な作業空間」です。

たとえば、アジャイルチームは、壁にふせんを貼り付けて議論したり、ホワイトボードに新しいアーキテクチャのドラフト図を書いたりして、情報豊富な作業空間を作っていきます。

さらにいうと、フロアにコーヒーメーカーをおいてもらって雑談空間を作ったり、そこにおやつをおいて集まりやすくしたりする工夫もしたりします。

私自身も、開発チームの座席の近くに、おやつ置き場をおいたりします。これはおやつ神社などと呼ばれるプラクティスで、メンバーはすきな額のお金をお賽銭箱に入れて、お菓子をたべます。賽銭箱のお金を使ってお菓子を補充するのが僕の役目でした。

XPの基礎プラクティス：活気のある仕事

4つ目は「活気のある仕事」です。第1版だと「週40時間労働」という名前のプラクティスでした。

アジャイルマニフェストにもありますが、持続可能な開発が重要です。よって、XPでは週40時間勤務をベースとして、しっかり休息を取るようにしていました。

あたりまえのことのように思うかもしれませんが、昔は残業でカバーが横行していたので、明示的に「ノー残業デー」を作るのも手です。

ただ、残業がだめというわけではありません。場合によっては、必要なときもあるはずなので、するとしても無理のない方法をとる。メンバーも納得の上で働ける環境を作るのが重要だと思います。

XPの基礎プラクティス：ペアプログラミング

5つ目は「ペアプログラミング」です。通称ペアプロは、有名なプラクティスであり、賛否が分かれるプラクティスでもあります。

ペアでプログラミングをするので、開発量は2分の1になります。ただ、随時議論を行いながらコーディングするので、レビューのコストが減るため、結局こちらのほうが効率が良かったりします。また、ペアで作業することで、知識や経験は倍のスピードで得られるようになります。

ペアプロの生産性については、過去多くの議論が行われていますが、少なくとも、ずっとペアプロができなくても、新しいメンバーがはいってきたときや、難しい実装をするときなどにしぼって、ペアプロを部分的に活用できます。

XPの基礎プラクティス：ストーリー

6つ目は「ストーリー」です。ユーザーストーリーと呼ばれたりします。

ストーリーの特徴のひとつは、見積もりをすばやくシンプルに行えることです。よって、必然的にストーリーは、できるだけ小さく作らなければならなくなります。1000ページの要件定義書よりも、1枚のカードに書ききれる量のストーリーをXPはあつかいます。

XPの基礎プラクティス： 1週間サイクル

7つ目は「1週間サイクル」です。第1版では計画ゲームというプラクティスでした。

アジャイル開発ではイテレーション（スクラムだとスプリント）と呼ばれる短いサイクルで開発を行います。書籍は当初2〜3週間を推奨されていましたが、第2版では1週間になっているのが興味深い点です。より短い期間でリリースを繰り返していくことをすすめているのかもしれません。

XPの基礎プラクティス：四半期サイクル

8つ目は「四半期サイクル」です。

短いサイクルで開発を行いますが、中長期的な計画も大切です。四半期、つまり三ヶ月ぐらいの期間で大きな目標の調整を行っていきます。

長期的な計画については、現場に合わせて長さを調整すると良いと思います。ただし、長く見積もっても、1年から2年ぐらいが限界だと思います。意味のある範囲で計画を立てていきましょう。

XPの基礎プラクティス：ゆとり

9つ目は「ゆとり」です。ゆとりで有名なものとしてはGoogleの20％ルールがあります。

やることを詰め込んでも、大抵はうまく終わりません。どうせうまくいかないことを、毎回のイテレーションで行うとどんどん辛くなってきます。よって、ある程度のゆとりを設け、この問題を解決していきます。

XPの基礎プラクティス： 10分ビルド

10番目は「10分ビルド」です。

システムの規模によって変わってくるかもしれませんが、ここでは10分という目安を設定しています。10分以内という制限があることで、実行回数を維持しやすくなりますし、時間が長くなってしまったときに気がつけます。

ビルド時間は短いに越したことがありません。時間については、自分たちが待てる時間を設定してもいいと思います。

XPの基礎プラクティス：常時結合

11番目は「常時結合」です。

これは継続的インテグレーション（CI）です。書籍では2〜3時間ごとに結合とテストを行うとありますが、最近だとソースがコミットされたら自動でCIが動く方法をとっている所も多いと思います。

大抵の場合、問題は結合部分におきます。よって、常時結合していけば、その問題にすぐきがつけるようになります。これがCIを利用するメリットです。

XPの基礎プラクティス：テストファーストプログラミング

12番目は「テストファーストプログラミング」です。テストファーストとテスト駆動開発は、賛否両論が起きやすいプラクティスです。

失敗するテストをまず書き、テストが失敗しないようにコードを修正していくプラクティスです。はじめからテストファーストで行うのが難しいなら、コードとテストを同時コミットするルールから始めてもいいと思います。なんにせよ、自動テストはアジャイル開発に必須の技術プラクティスです。

XPの基礎プラクティス：インクリメンタル設計

13番目は「インクリメンタル設計」です。第1版ではシンプルな設計というプラクティスでした。

これは説明が難しいプラクティスですが、ざっくりいうと、ちょっとずつ設計しましょうです。その理由は、全部をまとめて設計するのはコストがかかるからです。ちょっとずつ設計すれば、いま決めなくても良いことを、ぎりぎりまで先延ばしして、それまでに得た情報を使ってあとで決められます。先延ばしをうまく使う方法です。これはあとで解説を予定しているリーンソフトウェア開発にも「最終責任時点」という似たような言葉がでてきます。

ここまで基礎プラクティスを解説してきました。次回は応用プラクティスの解説を行います。