この連載は、登場して20年が過ぎ、成熟期を迎えつつある「アジャイル開発」を解説します。アジャイル開発については、世の中にたくさんの書籍や情報があふれていますが、アジャイルコーチとして10年以上の現場経験をもとに、あらためて学び直したい情報を中心にまとめていきます。
第9回目のテーマは、「エクストリーム・プログラミング（XP）」です。
この内容はUdemyで公開しているオンラインコース「現役アジャイルコーチが教える！半日で理解できるアジャイル開発とスクラム 入門編」の内容を元にしています。
価値・原則・プラクティス
XPの話をする前に、価値・原則・プラクティスを解説します。スクラムやXPのように、世の中にはさまざまな開発手法がありますが、それぞれの手法には価値・原則・プラクティスが定義されてるケースが多いです。これらがどういった意味を持つのかを見ていきましょう。
まず、価値とは、「何を考え、何を行うのかを判断するのに使用する基準」です。開発手法が持つ価値観なので、開発手法が大切にしていることが価値としてまとめられています。この価値があることで、開発手法を利用する人は、「自分たちは、この開発手法の価値を満たしているだろうか？」と判断ができます。
価値はふんわりした言葉になるので、じゃ、どうやったらその価値を実現できるのか？がわかりにくいと思います。たとえば、アジャイルマニフェストの一例をあげると、「個人と対話を」という価値がありますが、これをどう実現すればいいか？ これだけではそこまでわかりません。
また、価値だけだと間違った判断になってしまう可能性があります。たとえば、アジャイルマニフェストだとコミュニケーションに価値を置いてますが、「コミュニケーションを重視したいから1000ページのドキュメントを書こう！」となると、ドキュメント作成に時間がかかりすぎて、アジャイルな開発とは言えません。そこで登場するのが原則です。
原則は、価値とプラクティスを支える橋のような存在です。原則は、「具体的な指針」なので、具体的に何をすればいいかわかりやすいものになっています。
アジャイルマニフェストの原則を見てみると「顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します」というのもあります。この原則を守って、価値を実現していこうというものです。
先程の例にでてきた「1000ページのドキュメントを書こう！」の場合、「フェイス・トゥ・フェイスで話をする」や「シンプルさ（ムダなく作れる量を最大限にすること）が本質です」という原則にマッチしません。マッチしないので、価値を満たさない可能性のあるアクションだと気がつけます。
プラクティスは、価値へと向かう原則をより具体的にしたものです。アジャイルプラクティスとも呼ばれます。プラクティスには「実行」、「練習」、「習慣」という意味があり、アジャイル開発だと「アジャイルになるための習慣」という表現がふさわしいかもしれません。アジャイルプラクティスをやればアジャイル開発になる！とはかぎりませんが、少なくとも価値へと続く橋のような存在になります
エクストリーム・プログラミング
XPの考案者のケント・ベックさんは、Javaエンジニアであれば誰もが知っているであろうテストフレームワーク「JUnit」を開発したひとりです。
XPは、価値・原則・プラクティスに分かれて解説されています。XPは、コミュニケーションやチーム運営だけでなく、具体的なエンジニアリングプラクティスが揃っているので、開発者の方であれば共感しやすい内容にもなっています。ただ、エクストリームとあるだけあり、極端なプラクティスも多く、ペアプログラミングなど、賛否両論を呼ぶプラクティスも多数あります。
XPを解説した書籍は、第1版が出た5年後に第2版が登場しました。第2版は内容も修正・追記されています。副題も変わっており、第1版では「ソフトウェア開発の究極の手法」だったのが「変化を受け入れる」になっています。ここでは、手元にあるエクストリーム・プログラミング第2版『XPエクストリーム・プログラミング入門―変化を受け入れる』を使って説明しています。
まずは、XPの価値を順に見ていきましょう。XPの価値は5つあります。
XPの価値： コミュニケーション
ひとつ目の価値は「コミュニケーション」です。書籍では「もっとも重要」とされています。
XPの生みの親であるケント・ベックさんが、実際の仕事において、顧客とのやりとりがうまくいかず失敗するプロジェクトを多く見てきたため、コミュニケーションをもっとも重要視するようになったという逸話もあります。
XPに限らず、アジャイル開発全般において、チームの意識を高め、効率的な協力関係を生み出すためには、コミュニケーションは必須の価値とも言えます。
XPの価値：シンプルさ
2つ目は「シンプルさ」です。
シンプルさは、開発するシステムであったり、問題や課題の解決策であったり、さまざまなものに適用できる価値観です。私自身も、若手エンジニアを育成するときは、「140文字以内で報告をしてみよう」とか「これがもっともシンプルな方法だろうか？」といった話を意識してしています。
もちろん、複雑なシステムも必要でしょうが、開発活動も開発するシステムも、コミュニケーション方法も、できるだけシンプルな方が、よいシステムに近づけるように思います。
XPの価値： フィードバック
3つ目は「フィードバック」です。
完璧なシステムを開発するのはとても難しいことです。たとえ、完璧になったとしても、時間の流れや世の中の変化によって、それもすぐ不完全になってしまいます。
ただ、完璧を目指していく姿勢はとても大切です。自分の力だけで完璧になれればよいですが、フィードバックがあればよりはやく完璧に近づけるでしょう。十分な改善を行うためには、さまざまなところからやってくるフィードバックが重要になります。
また、アジャイル開発に取り組むのであれば、フィードバックに慣れておくのも必要だと思います。たとえば、コミュニケーションを重視するアジャイル開発では、フィードバックをもらうだけでなく、あなたからもフィードバックを与えるケースが多くなるはずです。よいフィードバックをする習慣を身に着けておくと良いでしょう。
そして、フィードバックにはポジティブなものもあれば、ネガティブなものもあります。ネガティブな場合でも、どうすればよくなるのか？ ポジティブに相手とコミュニケーションを取っていく必要があります。
ネガティブなフィードバックは、誰もがすぐに受け入れられるものではないでしょう。相手を気遣って本当のフィードバックを避けてしまう気持ちもわかります。
しかし、将来の宝になるかもしれないフィードバックが与えられない、受け取れない環境は健康的な環境とは言えません。ネガティブな内容であっても、チームで話せる、話し合える、そういうチームを目指してみてはどうかと思います。
XPの価値： 勇気
4つ目は「勇気」です。
フィードバックでも書きましたが、真実を伝える勇気、新しい解決策を探す勇気など、開発のなかで様々な勇気が求められます。ふりかえりでも勇気を持ったチャレンジを考えていきます。
アジャイル開発では、どんどん変化を受け入れていくため、勇気を持った対応がとても重要です。そうでなければ、新しいチャレンジができなかったり、できることだけやってしまったりして、その結果、改善が進まなくなり、「なんだかうまくいかない」となってしまうでしょう。
個人的には、やりなおせるものであればどんどんチャレンジしてほしいと思いますが、どれだけ心配であっても、作業全体の20％ぐらいはチャレンジを入れていかないと、現場が良くなっていく体感が得られにくいのではないかと思います。
XPの価値： 尊重
最後は「尊重」です。
書籍には、「これまでの4つの価値の背後にあるのが尊重」とあります。続けると「ソフトウェア開発で人間性と生産性を同時に改善するには、チームにおける個人の貢献が尊重されるべき」と書かれています。
アジャイル開発では、コミュニケーションを重視します。コミュニケーションはひとりではできないものです。相手に対する尊重であったり、敬意であったり、よいコミュニケーションに必要な価値は、アジャイル開発でなくとも持っておきたいものだと思います。
連載一覧
第1回：アジャイル開発の過去、現在、未来を知ろう！
第2回：声に出して読みたいアジャイルマニフェスト
第3回：従来型開発とアジャイル開発の違い その１
第4回：従来型開発とアジャイル開発の違い その２
第5回：アジャイル開発のよくある誤解を解いていこう！
第6回：世界中で大人気の秘密に迫る！スクラムを使ったソフトウェア開発
第7回：わかるようでわかりにくいスクラムチームの責任
第8回：スクラムイベントの実践方法
第9回：エクストリーム・プログラミングとその価値
第10回：エクストリーム・プログラミングの原則と基礎プラクティス
第11回：エクストリーム・プログラミングの応用プラクティス
第12回：リーンソフトウェア開発
第13回：ソフトウェア開発における「かんばん」
第14回：さまざまな方法論 − リーンスタートアップ・DevOps
