新たにアジャイル関連の書籍を入手したので読んでみました。

この書籍は経営層や管理職の方、またはアジャイル開発の導入を会社へ提案したい人が読むとよいのではという印象です。 特に第２部ではいくつか国内の事例を紹介しており、これからアジャイル開発を検討する方には参考になる部分が多そうです。 スクラムがどのようなものかについても触れていますが、具体的にスクラムでの開発のやり方を知りたい方は以前の書評で紹介した「SCRUM BOOT CAMP THE BOOK」がおすすめです。

印象に残った箇所にP.54のコラムで触れているウォータフォールの問題点があります。

このアプローチでは途中で計画外のよりよいやり方がみつかっても採用できない。すべてのよいアイディアは、プロジェクトの最初で計画する必要がある。

これは全ての要件を最初に固めてしまうのが前提のウォーターフォールでは、後からの仕様変更に柔軟に対応しにくく、開発者側からすると仕様変更は悪みたいなことになりがちです。

しかし、ウォーターフォールが極めて論理的であるため、「もっと上手にやっていたら、うまくいったはずだ。もっと文書化し、変更を最小限に抑えれば、すべてもっとスムーズにいくはずだ」と思い込んでしまう。残念ながら、多くのチームでは逆の結果になる。しっかり管理すればするほど、さらに悪い結果になるのだ。

これは正にその通りだと思います。しっかりやろうとすればするほど悪循環になりやすく、変更を最小限に抑えようとして本当に必要なものが作れなくなるなど、本末転倒な結果にもなったりします。 ウォータフォールはよくないとまでは思いませんが、最初に全てを決めようとするプロセスは特に技術革新の激しいソフトウェア開発においては適応するのが難しくなってきていると言えます。

P.129のリクルートの事例の部分も的確に問題点を捉えています。

SWATでは、「持ち帰りは禁句」という原則を打ち出した。従来のように会議の席上で100%の確約を要求するのをやめ、「可能性80%ならOKと答えてもよい。その代わり、持ち帰って検討は禁句」と関係者全員に理解をもとめたのだ。

全てを最初に決めようとするとあとから技術的に難しいものや、見積もりが思った以上にかかることが後から発覚しても「あの時そういったじゃないか！」と揉める原因になることも多いです。 そのため100%の確認をするために一旦持ち帰らせてもらうことは私もよくありました。ですがその場で決定できないため、スピード感が落ちることはどうしても止む終えない状態になりました。 それを解決するたのルールとしてはとてもよいと思いますが、この80%と調整の部分はさじ加減が難しいとも思います。

そして一番印象に残ったのはP.241のこの部分です。

このことで、筆者はアジャイルを目的ではなく手段だと考えるようになったし、また、「アジャイル対ウォーターフォール」とか、「プログラマ対管理者」といった敵・味方の味方ではなく「現場をよくしたい」という気持ちで活動することが大切だと実感した。

アジャイルを意識するばかりアジャイルでやることが目的になってしまうというのは本末転倒です。 常に手段が目的になってしまわないよう気をつけないといけません。 また開発が人ありきで進む以上、敵・味方とか関係なく常によくして行こうという気持ちをメンバー全員が持てるようにすることが一番重要だと改めて認識しました。

最後にアジャイルとウォーターフォールとの比較でアジャイルのメリットを知りたい方にもおすすめです。