この連載は、登場して20年が過ぎ、成熟期を迎えつつある「アジャイル開発」を解説します。アジャイル開発については、世の中にたくさんの書籍や情報があふれていますが、アジャイルコーチとして10年以上の現場経験をもとに、あらためて学び直したい情報を中心にまとめていきます。
第11回目のテーマは、「エクストリーム・プログラミング（XP）」です。前回は原則と基礎プラクティスを解説をしたので、今回は応用プラクティスを解説します。
この内容はUdemyで公開しているオンラインコース「現役アジャイルコーチが教える！半日で理解できるアジャイル開発とスクラム 入門編」の内容を元にしています。
XPの応用プラクティス：実顧客の参加
ひとつめは「実顧客の参加」です。第1版では「オンサイトユーザー」でした。
ユーザー VS チームという構図をなくすためには、ユーザーを巻き込んだ開発が必要です。可能であれば、ユーザにもチームの一員として入ってもらうのも手です。
顧客の参加方法もいくつか選択肢があるはずです。たとえば、定期的に開発現場に来ていただくこともできますし、客先にスペースを作ってもらってそこで作業することもできます。
どちらにせよ、顧客と開発を切り離してはなりません。
XPの応用プラクティス： インクリメンタル配置
2つ目が「インクリメンタル配置」です。
配置というのは成果物を環境に配置する「デプロイ」を指しています。当時はデプロイという言葉が一般的ではなかったのだと思います。XPではイテレーションごとに成果物をインクリメンタルにデプロイを繰り返します。
正確に訳すなら継続的デプロイメントですが、今風な言い方にするなら継続的デリバリー（CD： Continuous Delivery）が近い言葉でしょう。つまり、デプロイやリリースの自動化です。
XPの応用プラクティス： チームの継続
3つ目は「チームの継続」です。
XPを続けるチームは、成熟度が高まっていきます。これをリリースごとに解散するのはもったいない話です。可能な限りチームを固定し、継続的に意欲的に開発に取り組んでもらえる体制を作ります。
従来型だとプロジェクトが終わるとチームが解散しますが、アジャイル開発はチームを中心にメンバーが構成され、メンバーをできるだけ固定しながら開発を進めていき、チームの成熟度を高めていきます。
XPの応用プラクティス： チームの縮小
4つ目は「チームの縮小」です。
これはチームをスケールさせる、もともとはトヨタ生産方式のプラクティスだそうです。たとえば、まずアジャイルチームをひとつつくり、生産性や効率性を高めていきます。そして、そのなかの1名をチームからはずし、新しいアジャイルチームの立ち上げで活躍してもらう・・・。このようなやりかたで、チームをスケールさせていきます。
この方法は、今ではアジャイル開発を横展開するときの王道の方法でもあります。
XPの応用プラクティス： 根本原因の分析
5つ目は「根本原因の分析」です。
トヨタがやっていることで有名な「なぜなぜ5回」という方法があります。なぜを5回繰り返すことで、根本原因に辿り着こうとする手法です。なぜなぜ5回と同じように、問題の原因を深堀りしていきます。そうしなければ、上辺だけの解決方法になってしまい、問題がまた再発してしまうからです。
ただ、根本原因にすぐとりかかるのが難しい場合もあります。そういう場合は、まずは短期的な対策を考えて進め、それと同時に長期的な対策をセットで考えるのも手です。
XPの応用プラクティス： コードの共有
6つ目は「コードの共有」です。第1版だと共同所有というプラクティスでした。
現在は、GitHubやGitLabなどのコード管理サービスが広く使われているので、コードの共有はあたりまえのプラクティスと言えます。しかし、XPの書籍がでてきた当時は、共有ファイルサーバにコードを置くなどの運用でカバーしていました（本当に辛かった）。
コードの扱い方については、ブランチ戦略や、プルリクエスト、コミットしたものをわすれずにPushしておく・・・などといったプラクティスへと広がってきています。
XPの応用プラクティス： コードとテスト
7つ目は「コードとテスト」です。当たり前のことですが、コードとテストはもっとも重要な成果物です。
XPでは、これらを使って別に必要なドキュメントを作ることも推奨しています。Javaの世界だと、ビルドツールでJavadocなどさまざまなドキュメントをアーティファクトとして自動生成したりします。
XPの応用プラクティス： 単一のコードベース
8つ目は「単一のコードベース」です。
現在だと、Git flowのように、さまざまなブランチ戦略が使われていますが、XPでは、コードベースを単一にするのを推奨しています。Googleでも単一コードベースのほうが効率がいいとされています。
単一コードベースだと管理がシンプルになり、マージコストも下がります。ただし、単一のコードベースは複数チームでの開発のように、開発者の人数が増えると運用が大変にもなってきます。それぞれの現場にあわせて選択すると良いでしょう。
XPの応用プラクティス： 日次配置
9つ目は「日次配置」です。第1版では短期リリースと呼ばれていたものです。最近だとデプロイ回数を指標として計測するチームも増えています。
日次配置は、いわゆる日次デプロイです。ただ、これを実現するには「コードとテスト」や「インクリメンタル配置」といったプラクティスが必要になります。
このように、XPのプラクティスはそれぞれがゆるく連携しているので、どれか一つを導入してみて、関係するプラクティスの導入を進めていくといいでしょう。
XPの応用プラクティス： 協議によるスコープ契約
10番目は「協議によるスコープ契約」です。
開発を請け負う場合、契約が重要になります。ただ、従来型のように長いプロジェクトとなると、スコープが大きくなり、契約も長くなり、柔軟性が低くなってしまいます。
よって、契約も短く区切り、スコープを調整していきます。スコープには、スケジュール、費用、品質が含まれるので、それぞれを議論してスコープを決定していきます。
XPの応用プラクティス： 利用分払い
11番目は「利用分払い」です。
ユーザは利用した分だけシステム利用料を払う形の課金方法です。従来型だと見積もりをベースに納品後一括支払いが多いでしょう。しかし、XPではお金じたいもフィードバックの一つとして考えているようで、使った分、いただく・・・という形を提唱しています。
この方法は、現在だとSaaS型のサービスに似ています。SaaS型のサービスは、サブスク型の課金が多いので、毎月や毎年の単位で、特定の額を支払います。そう考えると、20年近く前にでてきたXPが、SaaSのサブスク型支払いをプラクティスとしているなんて、XPの先見性にびっくりしてしまいます。
以上が応用プラクティスです。
特にXPのプラクティスは、現在でも利用できる物が多く、あとで説明するスクラムと組み合わせることで、有効性を高められます。たくさんあるので、まずは概要だけでも覚えていただき、アジャイル開発を実践するときに、思い出しながら導入していただければと思います。
連載一覧
第1回：アジャイル開発の過去、現在、未来を知ろう！
第2回：声に出して読みたいアジャイルマニフェスト
第3回：従来型開発とアジャイル開発の違い その１
第4回：従来型開発とアジャイル開発の違い その２
第5回：アジャイル開発のよくある誤解を解いていこう！
第6回：世界中で大人気の秘密に迫る！スクラムを使ったソフトウェア開発
第7回：わかるようでわかりにくいスクラムチームの責任
第8回：スクラムイベントの実践方法
第9回：エクストリーム・プログラミングとその価値
第10回：エクストリーム・プログラミングの原則と基礎プラクティス
第11回：エクストリーム・プログラミングの応用プラクティス
第12回：リーンソフトウェア開発
第13回：ソフトウェア開発における「かんばん」
第14回：さまざまな方法論 − リーンスタートアップ・DevOps
