中から大規模のソフトウェア開発の実例から、ソフト開発がうまくいかないことによる損失が見過ごせないほど大きいことをデータで示しつつ、旧来のウォーターフォール的なやり方からアジャイル的なやり方へ転換すれば改善できると説いた本。
アプローチとしては、いわゆる「アジャイル宣言」にほぼ沿っている。つまり、エクストリームプログラミング・スクラム・アジャイル・ペアプログラミング・CI,CD・Devops・テスト駆動・リファクタリング、といった内容になる。なぜこれらが良いのかについての根拠が若干弱い気がするが、いずれにせよ、旧来からの開発のやり方から脱却するためのプラクティスとして説いている。
ただ、これらプラクティスのエッセンスという意味では、この本を読むよりも、それぞれの内容そのものにフォーカスした別の本を読んだほうがいいんじゃないかと私は思ってしまった。この本ならではの点が何かを考えてみるに、開発方法の転換を図りたくてもなかなかできないような現場にて上を説得するための材料や根拠をコンサル視点っぽく提供してくれること、なのかな。
とはいえ、最後の章が典型的だけど、やろうと思ってもなかなかできないのが現実で、ひたむきに真摯に取り組み続けることの難しさみたいな精神的な面を語っていたりもする。本著のタイトル「レガシーからの脱却」はそういうところなのかとも思う。
というわけで、アプローチのエッセンスについてはそれぞれの個別の本を参照したほうが良いと思う。アジャイル的な話の中身をわかっちゃいるけど実践できないような停滞感のある現場を知っている人がそれでもやっぱり転換したいと思ったときに手に取るのがよいではないかと思う。
ページ28 2.3.2蔓延「バグ修正に多くの時間を費やす人は少ない」え？逆じゃないの？バグ解析や修正に時間がかかることが多いんじゃないの？ものすごく違和感を感じる記載だった。
ページ63 5章プラクティス1「開発の半分もの時間が要求収集に費やされていた」 ソフトウェア開発者がソフトウェア開発をやっていないというのはもはやこの業界のあるある。仕様を取りまとめたりチェックシートを整備したり進捗確認したりバグチケットの取締をしたり、そういう中間管理の仕事をする人が＊割を占める。＊には好きな数字を入れてくださいな。
