2007-12-22

最近もらった本 : アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣

いただきました. ありがとうございます > 訳者のかたとオーム社の中のかた. 薄くまとまっているのは良いと思いました. あとはなにより訳が良いというのはアジャイル本では重要なのだと再認識しました.

これは本を貰ったお世辞が二割くらいで八割本当. 私がこれまでに読んだアジャイルの本はなんというか lost in translation があり, アジャイル固有の良く言えば情熱的な, 悪くいえば宗教がかった迸りが失われていた. この本でも強調されているとおり, アジャイルの文脈では態度や感情の持ち方がそれなりの比率を占めている. それを伝える上で文体の果たす役割は大きい. 訳文はそうしたアジャイルのノリをうまくあらわしていると思う．　

具体的な内容は, 私にとってはおおよそどこかで聞いた話だった. アジャイル関係の本はちょこちょこと読んでいるから当たり前かもしれない. 入門書として見た時の話題の選び方は妥当なかんじ.

...

もう少し素直に言うと, この本に従って上手くいく人は半分以下じゃなかろうか. 薄さとのトレードオフで細部が犠牲になっている. 最初はここで自分の体験からどのように上手くいかないかを延々と列挙するつもりだったけれど, 考えているうちに記憶が蘇えり比喩でなく涙が出そうになったのでやめておいた. それに, 書いたところでうさ晴らし以上の役には立たないだろう. "幸福は驚くほど一様だが, 不幸は様々である" ってやつ. (元ねたはトルストイだと最近知った.) 文脈に依存した細部は一般化しづらい. Joel も Michael Feather も文脈の重要性を強調している. そう考えるとこの薄さは妥当なトレードオフだと言える.

アジャイルの入門書がもつ役割は, ある <一様な幸福> のプロトタイプをもたらすことだと思う. アジャイルの方法論が誰にとってもハッピーとは限らない. だから気に入らなかった人は無理に従うこともない. 一方で, そもそも楽しく働くのがどういう状態かを 想像できていないプログラマも世の中にはけっこういる. そういう人は独占的外資IT企業や実体のわからないベンチャーの人事広報が広める 独占的コーラ飲み放題や実体のわからない自由研究制度の宣伝に振り回されながら, ただやさぐれていくことしかできない.

アジャイルの方法論も無茶な理想に走りすぎる部分はある. (ex: XP1ed. のオンサイト顧客) けれど少しは現実的でもある. たとえば製品開発でなく受託開発に使える. 湯水のような余剰資金とスーパーハッカーのかわりに 頭のとんがっていない上司とそこそこ仲の良い同僚がいればいい, ことになっている. 彼らを説得するのは富士山を動かすよりもいくらか楽だろう. (一人ではじめてもいいけれど, 辛い道程になる.)

私は割と早い時期, XP が出始めた頃からアジャイルの話を読んでいる. そのせいか, 大半のプログラマはアジャイルいいなあと思っているものだと勝手に信じていた. けれど仕事をする中で, 開発プロセスに興味のないプログラマが多いことを知った. "技術が好き" という立場をとるプログラマはプロセスを好まない. そうでなくても, 仕事術やリーダーシップ, 果てはプロジェクト管理の本を読みながら アジャイルをはじめとする開発プロセスの話を読んでないケースがある. そうした人々はアジャイルとフラジャイル(=グダグダ)の区別がついていない. 先の lost in translation 問題も事態を助長している.

アジャイルに限らず, 開発プロセスの本はソフトウェア開発に特化したビジネス書だ. だからプログラマなら一般的な自己啓発本やライフハックをかじる前に XP なり Scrum なりを調べてみる方が実入りはいい気がする. なにしろソフトウェア開発に話題を絞り, 断片的なハックでなくまとまった仕事術が 開発プロセスの手法なわけだから. この本が開発方法論以外のもう少し軽薄(?)な文脈で話題になり, これまで敷居の高さからリーチしなかったプログラマにまで届けば良いと思う.

そうしてアジャイルいいなと試してみて失敗して, 結局はハックが必要になる. けれど, そんなときプログラマとしてアジャイルに楽しく働ける状態が想像できれば 工夫の仕方も変わってくるだろう. 私はしばらくそうした職場ハックの意欲を失っていた. でもまだ試していないことはあるなと気を取り直した. どうぞよろしくおねがいします. > 同僚のひとたち