はじめに

コードコンプリートなどで有名な、スティーブ・マコネル氏のMore Effective Agile の和訳版を読んだので、その簡単な書評とメモを書く。

書評

非常に現実目線のアジャイル書籍。アジャイルの書籍は、アジャイルを当然のことながら推している人によって書かれている書籍が多いが、この書籍は完全に傾倒するのではなく、実際にソフトウェア開発に応用してみた経験から書かれている。そのため、読んでいると、「あぁ、たしかにこれあったな」「ここは悩むところだった」という点についてうなずきながら読める。

悩むところの一例をあげると、完了の定義(Definition of Done)ってどうすればいいんだろうってのがある。本書では、次のような具体例を載せているので、「このぐらいの粒度で決めていくのか」と現実に応用する場合に非常に参考になる。

- コードレビューを通過している
- 静的コード解析を通過している
- ユニットテストがエラーなしで完了している
- ユニットテストによるステートメントカバレッジが70％である
- システムテストと結合テストが完了している
- 自動化した非機能テストがエラーなしで完了している
- ビルド時にエラーや警告がでていない
- パブリックAPIがすべて文書化されている

上記でも面白いのは、カバレッジの数字の基準例が記述されている点だ。書籍のP.149でも、

ユニットテストのコードカバレッジが70％であることは、
新しいコードで目標とすべき有益かつ現実的な数字である。
ユニットテストのコードカバレッジが100％であることは滅多になく、
通常は収穫逓減点をはるかに超えている。
(もちろん、安定性を重視するシステムは例外である)

と記載されている。このあたりの数字は、どう決めたらいいのか結構悩むところだと思うし、 プロダクト特性によっては異なるものでもあろうが、指針を決めるときは非常に参考になるだろう。

コミュニティ

本書の良い点として、コミュニティの役割についても言及されている点がある。 私自身、社内でコミュニティを形成・運営する立場でもあり、 コミュニティの有用性について述べられている点は非常に参考になった。

たとえば、

(以下一部の抜粋)
組織内のパフォーマンスが弱い部分を特定する。
人脈を築く。
組織内でのベストプラクティスを洗い出す。
(P.206)

あたりは、「これはたしかに役割だ」とうなずきながら読んでいた。 社内でコミュニティの役割について聞かれる場合の回答材料にもなる。

組織視点

また、本書はアジャイルチームの中の話だけではなくよりマクロに、 どのように効果的な組織にするか、変革していくか、といった内容も含まれている。 現実的だとよくみる、組織に広めた場合の失敗の条件が書いてあり、 アジャイルに限らず、新しいものを組織に展開する場合にとても役立つ内容だろう。

メモ

物理書籍には付箋を貼りまくっているが、その中でも特に好きな一節のメモを書く。

開発者にとって成長の機会は他のどの要因よりも強力なモティベーションになることがわかっている
(P.71)

ダニエル・ピンク氏のモチベーション3.0で言われるように熟達は大きなメリットになる。

CFO: メンバーに投資して、彼らが辞めてしまったらどうするんだ。
CEO: メンバーに投資せずにいて、彼らがいつまでも辞めなかったらどうするんだ。
(P.90)

ちょうど似た議論を見かけていて、CEOの回答がすごいしっくりきた。

有能なプロダクトオーナーは独裁者ではなく、
「決定権者が決める」ときと「グループが決める」ときを心得ている。
（P.172）

POって判断が非常に難しいことが多いが、上を明示的に書いてくれていることで、使い分けが必要なんだって理解できるのは非常に良いと思った。

おわりに

アジャイルであることについて、現実的な目線から書いてくれている良書だった。 もちろん開発者向けの内容は多いが、エンジニアじゃない人が読んでも学ぶところは多そうだ。