アジャイルサムライ読んだ

アジャイルサムライ−達人開発者への道−

アジャイルサムライ−達人開発者への道−

1年くらい前から読もうと思いつつ読めていなかったのだけど、年末年始の電車移動中に殆ど読んで、昨日の夜に読み終わった。 本によって同じような文量でもすぐに読み終えるものともの凄く時間がかかるものがあるけれど、この本は前者だったように思う。読むのに時間は要らなかった。

アジャイル開発、というキーワードはずっと前から目にしていて気になっていたのだけど、殆どバズワードのような使われ方しか目にしていなかったのでこれまできちんと勉強しようという気持ちになれなかった。

それで気が向いてこの本を読んで、アジャイル開発アジャイル開発っていうけどアジャイルって何なのよ、という疑問を解消することができたように思う。アジャイルというのは、価値観や姿勢の話であって、手法の話では無かった。乱暴に云ってしまえば、悪い意味ではなく、アジャイル開発という宗教の話だった。

しかしながら、アジャイル開発を実現するためのベストプラクティスみたいなものはそれなりに蓄積されていて、それらの手法についてもいくつか言及をしていた(全部の手法に網羅的に言及しているわけではない)。

歴史に学ぶように、価値観や姿勢といったものは単一のものを全体が共有できるものではないし、するべきではないと思う。 だから、とにかくアジャイル開発を適用すれば現場が良くなるのかというと、絶対にそんなことは無いということも理解した。 その一方で、その現場に合った価値観や姿勢というものをチームが共有すれば、より大きな仕事ができるようになるとも考える。

そうした中で、ウェブ業界のような変化の早い水物の業界では、基本的にアジャイル開発の思想はマッチするのではないかと思う。 個人的には、例え自分がマネージャーでなくてもマネージメントに気を使うべきだと考えているので、これから仕事をしていく上で意識していけたら、と考えている。

自分は仕事のコードを書くときに「このコードはどれくらいの価値を生み出しそうで、その価値のためにどれくらいの労力を割いて良いのか?」ということを考えているのだけど、そもそもウェブサービスみたいなわけのわからんものにそういう考え方を上手に適用して運用するのは難しいと思い直した。どちらかというと、言い訳のように使われることが多かったのではないかと予想する。

というわけで、過剰品質にならない範囲内で先ずは短い間隔でリファクタリングするところから始めようかなあ、などとぼんやり思っている。

去年の3月末にAgile Do It!行ってきたのでメモ書き - 下林明正の日記なんてエントリーを書いているわけだけど、あれからまたいくつか現実を見て転職をしてようやくアジャイルサムライ読んだ今このエントリーを読みなおしてみると、なかなか面白い。

Agile Do It!の懇談会で著者や訳者といった方たちの人柄を伺えたのも今思えば良い経験だった。