再読、実体験が増えていくと納得感が増す。キーセンテンス並べるだけで、自問自答するのに役立つ。バランス大事。

光栄なことに翻訳の査読をやらせていただいたので、本書に関しては発売前に一通り読むことができた。しかし、献本していただいたものを改めて通読してみた。一言で言えば、グッジョブすぐる。

そして、本書を読み始めてすぐ、「コレハ！」と思ったところに付箋を付けていく、という方法は早々に破綻しそう（付箋がいっぱいですごいことになりそう！）なことに気づき、アンダーラインを引いていくことに切り替えた。

最初のプラクティス「成果をあげるのが仕事」に従えば、監訳者の角谷さんと木下さんは、これを十分にクリアした。この本はただの翻訳書ではない。見事なローカライズがなされている。原著をあたる方がいい翻訳書はたくさんあるけれど、この本に限っては違う。

成果（アウトプット）について触れたけれど、この本ができていく過程に一部関わらせてもらった感想として、そのプロセスもまた素晴らしかったことを付しておく。この過程も含めて本書の評価に反映せざるを得ない。

本書は「プラクティス」という名前を関している。このプラクティスが指しているのは「心構え」であったり「習慣」であったりするのだけど、本書にはその具体的なインプリメンテーションは書かれていない。それでいてなお、実践的だ。

アジャイルプラクティスを実装するのはあなたのチームであり、本書はそのためのテストコードになると思う。本書を読み終えた段階はテストコードが揃った状態であり、最終ページに書いてあるように、「これからが本番」と言える。

監訳者紹介文に倣って、私もプラクティスベスト3を挙げておく（3つに絞るのはとても大変だった）。

5.「変化に付いていく」
34.「警告をエラーとみなす」
41.「メンターになる」

咀嚼して、飲み込んで、そしてまた反芻していきたい、そんな本に出合えた僥倖を素直に喜びたい。

本書を通じて、自分の中にメタファーを持つことの意義にあらためて気づいたけれど、それはまた別の機会に。

いくつかアジャイル本を読んでいるので内容は既知で、重なる部分が多かった。それでも、いくつかは意識してないプラクティスがありメモしました。

メモしたいプラクティス
・設計は指針であって、指図ではない。
　設計は実装を始められるだけ詳細であればいい
・受け入れテストを自動化する
　受け入れ評価する担当がSeleniumかければよいのかなぁ
・アーキテクトもコードを書くべき
　PowerPointでコードはかけない
・答えを見つけられるように力を貸す
　メンターになってチームを育てる。
　いじめっ子(Tormentor)にならないように。