会社でアジャイル開発を初めてかれこれ５年ぐらいになります。
初期の頃に外部からスクラムコーチを招いてスタートしたのですが、私自身はチームにあまり参加しておらず、どちらからというとチーム外でインフラを担当するコンポーネントチームを担当しておりました。
それが会社の経営危機もあって社員がどんどん辞めていき、会社が立ち直った後もそれは続き、２年前ぐらいにはついには初期の開発メンバーは私だけという状況になってしまいました。
仕方なく、私がチームリーダーとして開発チーム全体を仕切ることになったのですが、もともとスクラムはあまり好きではなかったこともあり、すぐにヤメてしまいました。
ただ、アジャイル開発は続けていたので、スクラム以外のアジャイル手法についてもっと勉強してみようと、色々と本を読み漁っています。
振り返ってみると、ざっと２０冊以上にもなるので、今回はその読んだ本の書評をまとめてみました。
※おすすめ度を星の数で表現していますが、あくまで個人的な感想であって、決して書籍の優劣をつけているわけではありません。
＝＞あと、頑張ったのですが、まだ半分ぐらいしか書けていません。続きはまた今度書きます。。
Contents
初心者向け
スクラム実践入門 成果を生み出すアジャイルな開発プロセス（⭐️3）
スクラム初心者向けとしてよくまとまった本です。かなり読みやすい本で、基本的なスクラムのイベントやプラクティス、役割をさらっと説明したあと、初心者がよくぶつかる問題点と解決事例を多く載せていることがポイントです。
この本の価値は第6章からの事例紹介で、GMOペパボ、mixi、DeNAなど日本国内大手での事例が紹介されており、先人たちの苦労話が聞けるのは初心者にはとても参考になります。
ただ、中級者以上にとってはありふれた事例も多かったためか、私個人にはあんまり響かなかったですが、スクラムの初心に戻るという意味においてもおすすめの本かと。
良くも悪くも、スクラム初心者向けの本なので、スクラムやったことがないけど、少し興味があるって人におすすめです。
アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣（🌟４）
アジャイル開発を理解するための基本の一冊で、この本もとても読みやすいものです。アジャイルソフトウェア開発宣言に書かれている以下４つの価値を重視するための基本プラクティス（実践方法）が書かれています。
- プロセスやツールよりも個人と対話を
- 包括的なドキュメントよりも動くソフトウェアを
- 契約交渉よりも顧客との協調を
- 計画に従うことよりも変化への対応を
私の場合、ある程度アジャイル開発をやってからこの本を読んだので、一通りのプラクティスは知っており、さらっと読み流していたところが多くありました。
ただ、さらにいろんな本を読んだあとで今読み直すと、説得力をもって読めることが多く、よい本だと再認識できました。
アジャイルを実践するためのプラクティス本としてはよくまとまっている本です。
「悪魔のささやき」と「天使の声」という、現場で実際に起こりそうな心の葛藤を対比形式で記載しているのは、面白い書き方です。
といっても、ひとつひとつのプラクティスをより深く実践するには、この本だけでは役不足です。この本をきっかけに、CI・CD、TDD、DDD、チームビルディング、コーチングなどの各専門書を読むことでより深く納得でき、習熟していけると思います。
アジャイルサムライ（⭐️５）
弟子と師匠の会話形式でのQ&Aなど、読み物としてもとても読みやすい本です。本のボリュームはそれほどないのですが、アジャイル開発の心構えからチーム運用、見積もり、プログラミングなど、具体的な実践方法まで一通りのことが書かれています。
アジャイルアジャイル初心者・中級者におすすめの本です。
特に、「第Ⅱ部 アジャイルな方向づけ」で書かれているインセプションデッキによるチームビルディング手法についてはこの本でしかみたことがなく、すごく参考にさせてもらいました。
「インセプションデッキ」とは、PMBOKでいうところの「プロジェクト憲章」的なもので、「プロジェクト憲章」がトップダウン方式の宣言であるのにくらべ、「インセプションデッキ」はボトムアップ方式で、チームメンバー全員の認識合わせや目的を共有することができます。
これまでも、チームとして「ご近所さん」を探せや、「何を諦めるのかはっきりさせる」など、振り返りのテーマとしてやったことはありました。ただ、根本的な問いかけである「我々はなぜここにいるのか？」は開発の基本に立ち返るもので、チームが成長する上で一番重要なものであると思えます。
この「我々はなぜここにいるのか？」は後で読んだ、「チーム・ジャーニー」でも頻繁に登場しておりました。
「スクラム実践入門」とこの「アジャイルサムライ」を読んでおけば、とりあえずアジャイル開発の第一歩が踏み出せます。
これだけ！KPT（⭐️５）
アジャイル開発での振り返りの定番である、「KPT」の解説本です。
初心者スクラムマスターであれば、誰もが経験することだと思いますが、フレームワークとして単に「KPT」を取り入れてみても、チームとしてのカイゼンがなかなかうまく回らないものです。
せっかく振り返りの時間を設け、「KPT」を見よう見まねでやってみても、Problemが全く上がってこなかったり、表面上だけのTryをしてみたり、チームにイマイチやる気が感じられなかったりしませんか。
それは、チームが悪いのではなく、リーダーであるあなたに責任があるのです。
「KPT」が万能だからといって、なんとなくProblemをあげてみて、なんとなくTryしてみたところで、カイゼンできるはずがありません。
本書では、単なるフレームワークとしての「KPT」ではなく、理想のチームを「KPT」で育てるをテーマにいろんなコツを教えてくれてます。
とても読みやすい本でさらっと読めるので、特にスクラムマスター・チームリーダーの方にはおすすめの本です。
アジャイル・ユーザビリティ（⭐️2）
ユーザーテストの入門書。本のボリュームはかなり薄いので、サクッと読めます。
専門家にユーザーテストを頼むと「高い、遅い、重い」ので、とても敷居が高いです。特にアジャイル開発のような短期間でのイテレーションをやっているような現場では、UXテストを開発に組み込むことが難しいものです。
そんな課題に対して、この本では簡単なユーザーテスト（DIY）をやり方を解説してくれ、短納期かつ低予算で実施できるようになります。
要は、身近な人たちに開発中のソフトを試してもらい、フィードバックを繰り返しもらうことでUXをカイゼンしていくというものです。
ユーザーテストの経験がない開発者であっても自分で主導できるようになり、限られた予算内でユーザービリティを向上させ、顧客満足度を高めることができます。
カイゼン・ジャーニー（⭐️4）
たった1人のエンジニアが始めたカイゼン活動がチーム活動となり、やがてスクラム開発への発展し、プロダクトを成功させるストーリー仕立てになっています。
お決まりのゴタゴタを乗り越え、成功するストーリーはとても読みやすく面白かったです。
ただ、やや強引なストーリー展開も気になる点が多く、小説としては２流以下かと。
また、シーンごとに解説があるのですが、その解説が少し多岐に渡りすぎる感じで、ページの都合上さらっと流されるので、スクラムのプラクティクスを詳しく知らない初心者にはちょっと難しめの内容となっています。
個人的には、あまり知らないプラクティスが突然出てくるので、面白かったですが。。
スクラムの導入書として、物語風というのは面白い芸風なので、ポイントが高いのですが、ターゲットユーザーが初心者なのか、中級者なのか、若干、ブレているような気がするのでマイナス１ポイントで星４つとしました。
中・上級者向け
リーン開発の現場 カンバンによる大規模プロジェクトの運営（⭐️4）
著者が経験したリーンソフトウェア開発の実際の現場を詳しく、具体的に解説した本です。大規模という内容的にも中・上級者向けとなります。
アジャイルプラクティスも色々活用しているのですが、一番はカンバンの活用が中心となっています。特に複数チームによる大規模開発でのカイゼンのポイントが詳しく書かれています。
ページボリュームもそれほどないので、物語としてサクッと読める本です。
デイリーカクテルパーティーや同期ミーティングなど、大規模開発で役立つプラクティスが紹介されています。
うちの開発チームの人数はそれほど多くないのですが、チームを５つに分けているため、チーム間の連携が手薄になっています。
そのため、この本で紹介されている手法を参考にし、カイゼンしている最中です。
レガシーコードからの脱却 ソフトウェアの寿命を伸ばし価値を高める９つのプラクティス（⭐️3）
XP由来の以下の９つのプラクティスを使って、いかにレガシーコードを生み出さないかを詳しく解説してくれています。
- やり方より先に目的、理由、誰のためかを伝える
- 小さなバッチで作る
- 継続的に統合する
- 協力しあう
- 「CLEAN」コードを作る
- まずテストを書く
- テストでふるまいを明示する
- 設計は最後に行う
- レガシーコードをリファクタリングする
上のタイトルをみてお分かりのように、どちらというとコードを書く上でのプラクティスに多くを割いており、CI、「CLEAN」なコード、ユニットテスト、TDD、リファクタリングなどの解説がされています。ただし、コードを書くためのテクニック本というよりは、開発に対するマインドや取り組み方を解説した本です。
そのため、開発メンバーだけでなく、リーダー、プロジェクトオーナーやもっと上の決裁権限を持っている人にも読んでもらいたい本です。
私のチームでは、TDDまでまだ実践できておらず課題となっているので、「テストでふるまいを明示する」はとても興味深かったです。
ただ、私的には文体が若干読みにくく、読み込むのに時間がかかりました。1回読むだけでは消化しきれず、２回読むと理解度も深まります。
アジャイルな見積もりと計画づくり（⭐️４）
見積もりと計画づくりだけで一冊の本になっている点が驚きです。
この本は、中級者以上のPOとスクラムマスターにはぜひ読んで欲しい書です。特にリリース計画を立てる上で、経営層から無茶振りされている人には論理武装するための最適書です。
そもそもアジャイル開発とは、「計画に従うよりも変化への対応を」が基本理念です。この基本理念に従うため、変化への対応ができる計画づくりが求められるのです。
本書では、そのためのアプローチを事細かに説明してくれています。
この本を読むことで、自信をもって上層部への説明ができるようになること間違いなしです。
チーム・ジャーニー（⭐️3）
カイゼン・ジャーニーの続編的な位置付けの本ですが、チームとは何かに焦点をあてた本です。
前作と同じように物語り風なのですが、こっちの方が圧倒的に読みにくいです。自身の練度も足りないのだと思いますが、ご都合主義的な展開にはついていくのがやっとでした。
どっちかというと、前作よりこちらの方が自分の立場的にはぴったりな本で、結構期待していたのですが、個人的にチームビルディングというものはもっと泥臭い感じがしており、この本にはしっくりきませんでした。
そんなにうまいこと進むのか？という疑問符がいっぱいです。
ただ、参照されている大規模プラクティスについては気づかされる点も多く、別途、勉強しようかという気にさせてくれました。
実際、チーム間連携については結構悩むことも多いのですが、コーチングやファシリーテーション、自己啓発本などがとても参考になっています。
XPエクストリーム・プログラミング入門―変化を受け入れる
カンバン仕事術 チームではじめる見える化と改善
正しいものを正しくつくる
アジャイルコーチング
アジャイルレトロスペクティブ
ユーザーストーリーマッピング
チームの生成と開発
コーディング本
リーダブルコード
現場で役立つシステム設計の原則
テスト駆動開発入門
リファクタリング
ビジネス本
小さなチーム、大きな仕事 働き方の新しいスタンダード（⭐️2）
タイトルどおり、小さなチームで大きな仕事をするための格言集で、ビジネスで使えるTip集です。
ひとつひとつが短編になっていて挿絵も多いので、とても読みやすいです。
個人的には、最後の「ひらめきには賞味期限がある」という一節がとても好きです。何かしたいことがあれば、今しなければいけない、というのはとても共感できました。
前に読んだ「仕事は楽しいかね？」に書いてあった、「試してみることに失敗はない」とよく似た感じで、どちらも好きな言葉です。
ただ、この本の格言が多すぎて覚えられないです。
ざっと読んで、好きなものだけ覚えておきましょう。。
あなたのチームは、機能してますか？
まとめ
今回は、私が今まで読んだアジャイル関連本をリストアップしてみました。さらっと1日で読めるものから、読みにくいものだと２、３週間も掛かったものまであります。
＝＞あまりに読みにくいものは、最後は読み飛ばしたりしてました。
本によってレベルも色々で、初心者向けのものから中級・上級者向け、スクラムマスター向け、プロダクトオーナー向けなど様々なものがあります。
書いている視点や観点が違うことから、その本が重きを置いている内容によってバランスが変わってくる感じです。
ただ、結局、書いてあることの根本はみな同じで、アジャイルソフトウェア開発宣言に沿った内容となっています。
最初は、初心者向けの概要レベルのものからはじめ、中級者向けもの、そして個別プラクティス特化のものへと進んでください。
私もざっと読んだものが多く、細かな内容については忘れているものが多いのですが、違う本で同じようなことをなんども読んでいるうちに身についてきた感があります。
最後に、アジャイル開発といっても結局は最後は人です。人を成長させ、チームを成長させることが一番大事になってきます。それはウォーターフォールであっても同じであり、人とのコミュニケーション（対話）を大事にしなければ、勘違いやミスが起こりやすくなります。
そういう意味では、昔、Kindle Unlimitedで読み漁ったコーチングの本や、「人を動かす」など古典的な本がとても役立っています。
アジャイル本に飽きたら、次に読んでみてはどうでしょうか。
