エクストリームプログラミング新訳刊行記念:第一世代からの推薦状


ついに新訳が刊行!!

昨年のXP祭りから、私も何度か話題にしていたエクストリームプログラミング(XPE)が、新訳版としてオーム社より出版されることになりました。

元々の邦訳版の出版元であるピアソン桐原(当時)が2013年8月に技術書の取り扱いをやめてしまい(ピアソンショック)、XPEの邦訳版はもう手に入らないと嘆いていました。

ピアソンの技術書は書店在庫限りとの見通し。ピアソン桐原社がピアソングループ離脱で(追記あり)

「プレゼンテーションZen」や「Objective-C プログラミング」など、英国ピアソングループの技術書を国内で出版していたピアソン桐原は、ピアソングループか

www.publickey1.jp

そんな矢先、翻訳者の@kdmsnrさんから、XPEを翻訳しなおすとの情報を耳にしました。その時から「是非レビューさせてほしい」とオファーしていたのですが、いざとなったらなかなか時間がとれず、広く浅くしかレビューできなかったのが心残りで申し訳なかったです。

第一世代から、第二世代へ

私は2000年出版のXP白本(XPE)を真っ先に購入し、第二版の本書は原著で読んで、邦訳版も購入しました。XPJUGの立ち上げにも参加して、2010年に東京を離れるまで、XP祭りを始めとするコミュニティにもずっと関わってきたXP第一世代です。

他の方もブログなどで書かれているように、本書で紹介されているプラクティスは、今では当たり前どころか、現在の方がもっとエクストリームになっている部分も多数あります。

第二版が出版されてからのこの10年で、アジャイルのプロセスやチームワークについては、国内でアジャイルサムライが出版されたり、スクラムが広まってきた状況があり、エンジニアリング環境についてもGithub、Jenkins、DevOps、仮想化技術の進歩など、XPで提唱しているプラクティスが当たり前のようにできる環境が整ってきました。

昨年の講演の中で、私はXPはAgileの細胞として様々な場所に偏在するにいたったと主張しました。プラクティスレベルではこの主張は異論はないところでしょう。

開発プロセス、チームづくり、技術プラクティス、契約など、ソフトウェア開発に関する網羅的な領域において、イノベーションの文脈でよく言われる未来の当たり前を提供したのがXPではないでしょうか。

古典だから読む?

出版社のオーム社のブログにはこんなことが書かれていました。

単なる歴史的な名著を超えて、自分の目の前にいまある問題への糸口になるような本当の意味での古典になっています。

これはそのとおりだと思います。

ただ「古典だから読む価値がある」というだけでは、第二世代が本書を読む動機付けとしてはいささか弱いのではないかと思います。きっと古典を辿るような真面目な開発者しか手に取らないのではなかろうかという気がします。

これまでXPに触れたことがない第二世代の皆さんには、何を持って本書をおすすめすればいいのだろうか、というのを考えてみたいと思います。

XPはプラクティス集ではない

本書はプラクティス集ではありません。第一版はそうであったかもしれませんが、本書のプラクティスはあくまでも実証済みのものを紹介しているのであり、そこに囚われる必要はありません。もちろん、仮説として試してみるのは、どんどんやってみるのが良いでしょう。

ただし、自分で新しいプラクティスを編み出していくこと、プラクティスだけでなく、原則や価値においても自分自身で考え生み出していくことこそがXPの真髄です。

このことは、XP祭り2014の咳さんのキーノートでも改めて言及されています。

XP-matsuri 2014 Keynote

XP祭り2014のキーノート。投げ銭版はこちらです。 https://gumroad.com/l/txWz

speakerdeck.com

XPのこの特性はパーマカルチャー(注釈付き参考文献の「哲学」の欄参照)の影響も受けているのではないかと推測します。

パーマカルチャーも倫理・原理・実践の構成になっており、様々な有名な実践(チキントラクター:ニワトリを地面のカゴの中で飼育しながら除草、糞による施肥、耕起を行う、スパイラルガーデン:螺旋階段状の花壇で水はけや日当たりなどの微気象の違いを作り本来寄せ植えできないようなハーブを寄せ植えする)があります。

しかしそれらを何も考えずに実践するのではなく、倫理や原則をヒントにして、その場を観察し、その場に適したデザイン(=プラクティス)を創意工夫の元実現していくことが重要なのです。

本書には、プラクティスは通過点にすぎないプラクティスは自分たちで作り出すプラクティスは仮説というような記述が繰り返しでてきます。これは初版の「XPはこうあるべき」という教条主義になりがちだった反省があるのでしょう。

XP自体も常にフィードバックサイクルを回しながら、その場に適したものへの変容を仮説検証しながら実現していくというメッセージなのです。

私も2012年度のIPAのアジャイルプラクティスの調査に携わり現場のさまざまな工夫を目にしました。そこでは本の通りではない、自分たちの現場にあったプラクティスが生み出されていました。

様々な方法論やフレームワークがありますが、「なんかうちの文脈には合わないな」「本の通りにやってもうまくいかない」そんな経験のある方や、ついつい教条主義「こうあるべき」になってしまいがちな方は、本書を読んで「自分たちでプラクティスを作り出す」とはどういうことをかを考えてみてはいかがでしょうか。

人生におけるTDD

昨年(2014年)の9月から11月にかけて、本書の旧約版を元に、注釈付き参考文献で紹介されている本についての講演をしました。

人生で大事なことはXP白本と参考文献に教わった IN 神山

2014/11/07 神山.rb 第一回にて XP祭り2014の再演の資料。ESM版からの資料の修正加筆あり。 http://kamiyamarb.doorkeeper.jp/events/16452

www.slideshare.net

その講演のために、本書の旧約版や参考文献を読みなおして改めて気づいたのは、この本はXPの解説だけでなく、著者のKent Beck氏の価値と現実を一致させる旅の軌跡であったということでした。

本書を呼んでいて気づいたのは、価値、原則、プラクティスという構造は、これ自体がTDDと同じ構造になっているのではないかと仮説です。

価値、つまり「自分やチームが大事にすること」というのは、その人やチームが常に満足するべき条件であり、原則は満足条件が達成できているかを確認するためのテストであり、プラクティスつまり実際の現実世界の行動はプロダクトコードである。

価値が明確でないということは、よい仕事・人生を送る上での満足条件が明確でないということになります。

もしも、価値と行動がずれている場合は、満足条件を満たしていないということになります。その場合、いくら行動を積み重ねても、自分が満足する結果にはなりません。

価値と現実を一致させるということは、自分自身の満足条件を明確にして、そこを満足させるテストを書き、そのテストをパスするプロダクトコードを書き、常にフィードバックサイクルを回しながら、満足条件がみたされるように振る舞いし続けるということ同義ではないでしょうか。

Kent Beckは、XPという本を書き、自分のやり方を世間に向けて公開するにあたって、必然的に価値を明示することになりました。そして、自分の明示した価値(=満足条件)、原則(=テスト)を満たすようなプラクティス(=プロダクトコード)を書き続ける、人生のテスト駆動開発、価値駆動人生(Value Driven Life: 造語です)の実践に苦心した初版からの5年の旅だったのではないかと、本書を読んで感じたのです。

Kentは本を書くことで自分の価値や原則をまとめたのですが、そうやって自分の価値を明示する機会がない人はどうすればいいのでしょう?

Kentは本書の結論でこう述べています。

今すぐに始めよう。自分の価値について考えてみよう。その価値と調和した生き方を意識的に選択しよう。

準備なんて必要ないのです。今日から、そして今からできるのです。

ソフトウェア・ITに関わる仕事に携わり、それらを含めた自分の人生を考え、よりよく生きたい人は、本書を読んでみて、自分から変わり、身近なところが変化していくために何が必要かを探してみてはいかがでしょうか。

「何度も読む」は伊達じゃない

最後に、オーム社のブログにはこう書かれていました。

プログラマーをはじめとしたソフトウェア開発に直接携わる方々はもちろん、コンピュータを使って生産的な仕事をしているすべての人に、何度でも読んでいただきたい一冊です。

これはただの売り文句ではありません。

実際に、私が(初版を含めて)この15年間、自分の仕事のステージが変わる度に何度も本書を読み返し、注釈つき参考文献をひも解くことで、自分のステージにあった新しい発見がありました。

私の場合、本の読み込みが甘いのでしょうが、常に新しい発見・読み流していた部分が新しく刺さることがありました。他の人にそのまま当てはまるかは別ですが、ソフトウェア開発に関わるすべての人々:プログラマー、チームリーダー、マネージャー、経営者に至るまで、それぞれの視点、ステージに合った発見ができると信じています。

まとめ

本書は時を超えて読み継がれる古典です。私は以下のような方々にオススメします。

  • ソフトウェア開発の現場をよりよく改善したい人
  • よりよい仕事・よりよい人生を送りたい人
  • ソフトウェアエンジニアであったが仕事のステージが変わって悩んでいる人

[関連する記事]