去年の年末 Amazon で手に入らずにキャンセルしてリアルショップを探して手に入れた割にまったく落ち着いて読む時間が取れずにいたものをようやく読み終えた。

いい。

付箋だらけで逆に付箋貼った意味がない。

いくつか拾うと、

• 応急処置による泥沼化
• deploy の自動化
• プロジェクト用語集
• コードで伝える
• Tell, Don't Ask
• ソリューションログ（なんでもチケット化？）
• 警告をエラーとみなす
• アーキテクトもコードを書くべき
• コードをレビューする

辺りが心に残ったり引っかかったりしているところ。

例えば deploy の自動化は今まさに自分がいちばん問題意識として強く持っていることの一つで、PHP の設定って PHP で書いた方がよくない？ なんかは実はこの辺に繋がっている。設定を php.ini の外に出すことでいくつものサイトのコードを同時に扱えるだけでなく、さらにその設定を開発環境、検証環境、本番環境に確実にセットできるようにすることを目指している。さすがに全自動にするのは難しいが、自前の Ruby スクリプトに必要なパラメータをコマンドラインオプションで与えるだけで include_path のセットや symlink の作成などを自動的に行い、できるだけ早くその後の行程に入れるようにということを考え、実践している。

以前 CruiseControl.rb の名前も出したかと思うが、この辺も基本的には同じ。deploy ではなく全体の（ユニットテストではなく）実際の動作チェックを自動化しておくことは非常に大きな安心感、そして自信に繋がる。現在のところこれも自前のスクリプトでゴリゴリチェックを掛けているが、このツールがなければ複数のサイトを一気に PHP 4 から PHP 5 に移行させるには間違いなくもっと多くの時間が必要だったと思う¹。

もう一つはコードで伝えるという辺り。最近、様々なレベルでインターフェイスということをよく意識している。ユーザーがアプリケーションに触れるインターフェイス、コードと開発者のインターフェイス、コードとコードのインターフェイス、アプリとアプリのインターフェイス。で、言ってみれば「コードで伝える」ということはコードと開発者のインターフェイスという辺りの話かなと。

逆にもやもやしているのはコードレビューの辺り。それもコードレビューの方法とかではなく、コミットされる前のコードをどうやってレビューするの？という初歩的な話。だってコミットされていないコードは基本的に開発者のローカルの環境にあるわけでしょ？ ペアプロでもやってない限りコミット前のコードって現実的にレビューできなくないですか？

というわけで今のところ 1 〜 2日で終わらない作業は基本的にブランチ切って、ブランチ内は動いてないコードでもとにかくコミットさせ、そこでレビューすることにしている。なんかこの辺、もうちょっと何か工夫がないのかなぁという気はしている。

自分の話は置いといて本そのものの話をちょっと書いておく。

自分の場合、多くの内容はどこかのサイトや他の本や雑誌などでなんとなく見たことのある内容だったので、時間とやる気がある程度以上確保できた今日はとても軽快に読み進めることができた。まぁ言うなれば復習なので。ただ「書籍としては」アジャイルの本はたぶん初めて読んだと思う。

そのためどの内容もウンウンとうなずくばかりで、その結果が冒頭に書いた付箋だらけで付箋の意味を成していないような状態である。まぁそれだけ内容が「詰まっている」と言える。

ただ「詰まっている」というのは項目の数として内容が多いという意味でもあるが、書籍全体の分量はとてもお手軽な量に収まっているため、一つ一つの内容がそれほど深くないという意味でもある。例えば実際のコードはあまり登場してこないし、個々のツールの説明もかなり少ない。ユニットテストの自動化やデプロイの自動化など魅力的な言葉は並んでいるが、それらを始めるためにどれくらいのコストが掛かるかも、まったくアジャイルの経験も知識もない人には予測がつかないだろう。

そういう意味では実践に移すためにはこの本だけでは不十分で、より多くの情報を集め、自分だけで試せることはとりあえずやってみるなど、それなりに手間ヒマを掛けないとダメな気がする。

とは言えこの「ギュッと詰まった感」はまったく初めての人でも圧倒される心配がなく、入り口として実にいい塩梅に仕上がっていると思う。別なタイトルを考えるとすると、（会社違うけど）

アジャイルHACKS²

みたいなもんだと言えば通りはいいかもしんない。

オススメっす。