アジャイルプラクティス の商品レビュー

VenkatSubramaniam,AndyHunt【著】,角谷信太郎,木下史彦【監訳】

2024/02/03

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

2019/01/20

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

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

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

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

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

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

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

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

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

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

2019/08/20

[備考]
https://www.amazon.co.jp/%E3%82%A2%E3%82%B8%E3%83%A3%E3%82%A4%E3%83%AB%E3%83%97%E3%83%A9%E3%82%AF%E3%83%86%E3%82%A3%E3%82%B9-%E9%81%94%E4%BA%BA%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9E%E3%81%AB%E5%AD%A6%E3%81%B6%E7%8F%BE%E5%A0%B4%E9%96%8B%E7%99%BA%E8%80%85%E3%81%AE%E7%BF%92%E6%85%A3-Venkat-Subramaniam/dp/4274066940/ref=pd_sim_14_4?_encoding=UTF8&pd_rd_i=4274066940&pd_rd_r=285a40d9-e24e-11e8-a9bf-17b1a941fca2&pd_rd_w=IF6PG&pd_rd_wg=suwCM&pf_rd_i=desktop-dp-sims&pf_rd_m=AN1VRQENFRJN5&pf_rd_p=68cfebef-f8b4-4691-9d72-a10f0956615a&pf_rd_r=EN6MCF3N3A8SMTDE6R54&pf_rd_s=desktop-dp-sims&pf_rd_t=40701&psc=1&refRID=EN6MCF3N3A8SMTDE6R54

2018/10/28

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

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

2018/10/23

ソフト開発プロセスは、ヘビー級なもとのライト級なものに二分される。大抵のまともなプログラマーはヘビー級を嫌う。なぜなら、ヘビー級は、「ユーザに提供されるもの意外を沢山つくることを強制する」、「硬直的で、官僚的」、「チームの社会的側面を軽視する」、「聞いたこともないようないろいろな職種を定義する」などの非効率的アプローチであるからだ。本書は、この対極であるライト級プロセスの一般名称アジャイルプロセスのベストプラクティス集である。昨今、ヘビー級の失敗のおかげでアジャイルが注目されているため、「アジャイルＸＸＸ」なる本は偽物が多く出回っており、名前だけでプラクティスを選ぶとだまされることになる。だまされないためには、著者や監修者、コメンテータの欄に"Kent Beck"、"Andy Hunt"、"Dave Hunt"ら著名且つ有能なプログラマーの名前を探すことである。という意味で、本書は読む前から良書であることが約束された書籍である。従って、プログラマーなら内容を問わず取り合えず読むことをお勧めする。とは言え、折角私のコメントを読んでくれている人のために、少しだけ本書の内容に触れよう。　本書は４５の厳選されたプラクティスから成る。各プラクティスは、それぞれについて　・最初に、そのプラクティスを皮肉るような「悪魔の囁き」が来る。　・その後、そのプラクティスの詳細な説明があり、　・続いて、「悪魔の囁き」に対する「天使の助言」が来る　・そして、このプラクティスが引き起こすであろう感情を「こんな気分」で説明し、　・とは言え、「バランスが肝心」で、やりすぎは良くないと戒めるというような構成になっている。　本書が第一に紹介しているプラクティス「成果をあげるのが仕事」を、著者自体が忠実に守っているため、アジャイル・プロセスの解説書としての出来はすばらしい。また、リファレンスして便利に使えるような工夫も随所に見られるため、上級者の再学習用としても秀逸。ということで、繰り返しになるが、あなたがプログラマーなら取り合えず読むことをお勧めする。

2018/10/13

とても良い本でした。
ソフトウェア開発にたずさわる読者に、「アジャイルであること」とは何なのかを理解させ、アジャイルプラクティスの試行を大いに助けてくれる本です。
アジャイル(Agile)とは、直訳すると「機敏である」ということ。
ソフトウェア開発において、最終的な製品の仕様が開発段階であらかじめ完璧に決まっているなんてことはあり得ないんだから、当然完璧な要求仕様やスケジュールなんか最初から組めるわけない。エクセルで開発スケジュールを作り、スケジュールが変化するたびに(スケジュールは当然変化する)エクセルのスケジュールをちまちま編集する、そんな馬鹿げたことに無駄な時間と労力を費やすよりも、とにかく作ろうとするソフトウェアをモジュール単位に分割して、何かしら設計してみて、コーディングして、コンパイルして、テストして・・・のサイクルを機敏に繰り返して素敵な製品を作って進化させていこうよ、という設計姿勢が「アジャイルであること」らしいです。
開発段階では仕様が確定していないので、素敵な製品の定義というのもこの時点では曖昧です。アジャイル開発は、その曖昧さを解消するために、ソフトウェア開発者にユーザーと常に接することを求めます。作った(あるいはテスト中の)ソフトウェアをユーザーに見せ、ユーザーからのフィードバックを反映し、より良いアイデアを能動的にユーザーに提案し、再テストする。この繰り返しが、ユーザーにとっての素敵な製品とは何かを定義づけていくプロセスであり、この繰り返しのプロセスを設計者がアジャイルに(機敏に)できる環境を構築することが、アジャイル開発の肝であるようです。それは例えば、分割したモジュールのコンパイルが容易であるとか、自宅からでもモジュールのチェックイン/アウトができてどこにいてもソフトウェアが作れる環境にあるとか、競合(同モジュールをチームの複数人が同時に編集しようとする)が発生しにくい仕組みやチームワークを構築する、といったことです。
チームワークの重要さもよく述べられていました。現代のアプリケーションの規模を見たときに、そのソフトウェア開発をひとりで行うケースというのは現実的でなく、ソフトウェア開発は常にチームで進められるものであるから、そのチームワークは大切であるとのことです。その有効な方法として例えば、短いスタンドアップミーティングをチーム内で毎日実施して開発者同士の進捗を確認するとともに交流を深めたり、ひとりひとりがチームにとってのメンターになる意識を持って自分の知識をチームと共有する機会を設けたり、といったことです。自分の知識は思わぬところで他人の役に立つことがあるから、とにかくメモ書きでもブログでもなんでもいいから残して共有しておくと良く、またそれを継続するためには自分自身が常に勉強する意欲と他人から教えを請う姿勢が常に求められるので、結果として自分もチームメンバーも互いに向上し合える、というのが「メンターになる」ことのメリットだそうです。(実際、「アジャイル開発」という言葉を全く知らなかった僕がこの本を読むことになったのも、チームの先輩から教えてもらったことがきっかけでした。)

最後に、ソフトウェア開発における「設計」について述べられた文章が印象的でしたので、ご紹介します。

『設計とは、直面している問題それぞれに固有の解決策である。現場でそのまま使えるほど詳細に事前設計することは難しい。最初の段階では、まだ問題の背景も十分わかっていないし、フィードバックもほとんどない。設計は時とともに進化するのだ。アプリケーションの実態(そして実装)を無視して、新しい機能や機能の強化を設計することはできない。(著書より抜粋)』

2018/10/07

ソフトウェア開発をアジャイルに行うための習慣が45書かれている。 今まさにアジャイルにプロジェクトを進めている自分にとって、実に納得の内容だったり、頭ではわかっていても全然できていないことがあったりで、もやもやしていたところがある程度スッキリできてとてもよかった。 各プラクティスの冒頭には「悪魔の囁き」があり、よくありがちなアンチパターンがあり、終わりにはアンチパターンに対応する「天使の助言」がある。これらもよくまとまっててとても参考になった。 アジャイルな開発は個々の相乗効果を高めることを常に意識しておかないとダメだな、ということを再認識できた。変なプライド(がもしあれば)は捨てて謙虚にいかないとね。 タイトルは「アジャイルプラクティス」となっているけど、アジャイルでないプロジェクトでも実践すべきプラクティスがいくつか書かれているので、ソフトウェアエンジニアは必読の一冊だと思う。

2016/12/14

読みやすくてためになった
プログラミングの会社に勤めている人なら部分的に取り入れるだけでもいいと思う

2015/08/03

まだアジャイルの概要以外何にも知らない状態から読んだ。
易しい言葉で書かれているので読みやすいし、すんなり理解できて良かった。
実際の現場と比較しながら読めたのも面白かった。

2015/03/09

2015/03/09 08:00

アジャイルを実践しようという感じの本だということで、読んでみた。

そんなに新しい本ではないからか、あまり目新しさはなかった。

アジャイルってなんか原理主義の宗教くさい感じがしていて、避けていたんだけど、この本ではそういう印象は全くなかった。

開発手法に関わらず取り入れることができそうなことが多かったので、今後役に立てたい。