2011年09月06日
Jonathan Rasmusson『アジャイルサムライ――達人開発者への道』（オーム社） 
原書刊行時に書名を面白がったのが縁となり、監訳者の角谷信太郎さん経由で献本いただいた。
実を言うと、本書を読んで楽しめるか、もっというとちゃんと理解できるか不安があった。ワタシ自身ソフトウェア技術者であるが、扱うソフトウェアの分野が本書が対象とする SI ベンダであったりウェブ開発者とは住む世界が違う。
ワタシが属する世界は今なおウォーターフォールな開発に支配されている。それに不満がないわけではなく、「アジャイル」という言葉にはずっと関心を持ってきたが、それを基本から真剣に学ぼうとしてなかった。
本書を読んでまず感じたのは、自分の「アジャイル」という言葉に対する期待の仮託、つまり現状のソフトウェア開発にまつわる不満、具体的にはドキュメント作成の手間などへの不満などに対する反抗心として勝手に期待していたところを自覚させられた。それでは駄目である。
アジャイル開発で大事なのは何より動くソフトウェアを定期的に届けることであり、それを実現するのは、「これまで経験したことのないほど強烈なスポットライトを浴びてるみたいな感覚」に耐える必要があること、そしてチームとしてそれに突き進むために必要な自己組織化には、成果責任と権限委譲がセットで必要なんだね。
以前から思っていたことだが、アジャイル界隈には情熱とユーモアが共存した活気ある文章の書き手が多い。『BEST SOFTWARE WRITING』におけるロン・ジェフリーズについての紹介文で、Joel Spolsky はそれだから「アジャイル」に注目が集まるんだという穿った文章を書いていたが、本書もその系譜に属するもので、翻訳もそのユーモア（何せアジャイルサムライでマスターセンセイですから）を損なわない活気ある本に仕上がっている。そして何より、上に書いたアジャイル開発の本質について一冊で網羅的に語っている中身のある本だ。
個人的にはユニットテスト、リファクタリング、テスト駆動開発、そして継続的インテグレーションについて順を追って解説する第V部「アジャイルなプログラミング」が特にありがたかった。上にも書いたように、ワタシの属する世界が違うため、この通りに実行できるわけではない。しかし、はじめからできないものと決め付けるのでなく、自分の仕事に本書の内容がどのように役立てられるのかずっと考えながら本書を読んだ。プロジェクトの核心を抽出した共通理解を開発プロジェクト関係者全員に伝えるツールであるインセプションデッキの概念は特に参考になるように思ったが、これから折に触れ本書の内容に立ち戻り、再読することになるだろう。
さて、このようにワタシにとってとても有意義な本だったが、最後に本書に関連して思うところを書いておく。以下は蛇足である。
これは本書に限らずこの界隈の書籍に共通する不満だが、やたらとキーワードをカタカナ表記で済ますのはよくない傾向ではないか。もちろん定訳になってるものも多い。ワタシ自身訳者としてできるだけ定訳に乗っかる主義だが、本書を読んでいて例えば「ベロシティ」といった単語までカタカナ表記になってるのを見て不思議に思った。どうして単純に「（開発）速度」ではいけないんだろう？ ソフトウェア開発経験の浅い人が「リグレッションテスト」と聞いてどれだけピンとくるか。訳注を見ると「回帰テストとも呼ばれる」とある。じゃあ、そう呼べよ。リグレッションテストより回帰テストのほうが日本人にはずっと情報量が多いだろうに（実際 Google の検索ヒット数も後者のほうが圧倒的に多い）。
こうしたアジャイル界隈に詳しくない人間の不満は、その筋の方々から見ればさぞかし愚鈍に見えるだろう。訳者たちの開発の現場における用法に則っただけであることは当方も想像できるが、より多くの人たちを引き込むには、煙に巻かれるように感じるカタカナ語は得策ではないのではないか。第一、アジャイルで重要なのは（ソフトウェア開発が本業でない）顧客を巻き込むことなんだろう？
例えば本書では「スートごとにカードが13枚あること」という文章があって（243ページ）、「スート」にわざわざ訳注がつけられている。別にこの「スート」という単語が本書の他所で独特な意味で使われているわけではない。単に「トランプの（4種類の）マークごとにカードが13枚あること」と書けば済む話ではないか。これも前述の悪習に引きずられた例にワタシには思えた。