More Effective Agile “ソフトウェアリーダー”になるための28の道標 読了

通称「もえアジャ」を読んでみました。

More Effective Agile “ソフトウェアリーダー”になるための28の道標

実は結構前に読み終わってブログも書いていたのですが下書きが消えてしまって、同時にやる気も消えてしまっていました。。。 頑張って書きました（2回目）

この本は英語版のときから上司が絶賛していたのですが、その訳が分かりました！ 先日社内のQA向けに本の内容を紹介したのですが、その上司は「今のエンジニアでアジャイル開発の影響を受けていない人はいないはず。エンジニアは全員読む価値がある。」と言っていました。結構ハッとしました。

自分がこの本が素晴らしいと思うところは以下の3つです。

1. 組織文化、対話、品質・テストを含め開発に必要なものが広く網羅されている

新しくアジャイル開発を取り入れる組織にとっては役立つと思います。シーケンシャル開発と対比されているところもかなり参考になります。

2. 具体的なアクションが書かれている

各章の最後に「推奨リーダーシップアクション」として具体的なアクションが書かれています。そのため導入時や迷ったときにアクションにつなげやすいと思います。 しかもそのアクションが検査と適応になっていてスクラム知っている人ならわかりやすいです。

3. 冷静な目で書かれている

主観ではなく、論文などを引用しながら効果が述べられています。 例えば、モブプロについては「これらのプラクティスを実践して成功を収めているチームもいくつかあるが、その有効性にはまだ疑問の余地がある。」と書かれています。

グッと来たところ

スプリント疲れに対処する方法の 1つは、スプリントの長さをたまに変えてみることである。

これは興味深いですね。リズムを作ることが良いことかと思ってましたが、それにより疲弊することもあるということでスプリントの長さを変えてみるという話でした。本文では2週間6, 1週間1という感じになっていましたが、1週間スプリントをリリース終わったタイミングで2週間とかにするのもいいかなと思いました。

アジャイル開発は従来の「テスト」の重点に 4つの変化をもたらした。 1つ目は、開発者によるテストをさらに重視するようになったことである。 2つ目は、フロントローディングテスト──つまり、機能を作成したらすぐにテストすることを重視するようになったことである。 3つ目は、テストの自動化をさらに重視するようになったことである。そして 4つ目は、要求と設計を改善する手段としてテストを重視するようになったことだ。

これは上司を説得するときなどに使えそうですねｗ

スクラムにおいて最もよくある失敗モードの 1つは、無能なプロダクトオーナー（ PO）である。

以前社内で研修をしたときに、「もしかしてうちの会社の問題はPOが不在ってことなのでは？」という人がいたのを思い出しました。とにかくプロダクトに関する責任や決定権がボンヤリしていると進むものも進まないイメージです。

大規模な組織によく見られるパターンは、変革サイクルをいくつも開始した挙句、そのほとんどが実を結ばない、というものである。このようなサイクルを何回か経験すると、メンバーは身を潜め、自分の身に火の粉が降りかかる前に立ち消えになることを願うようになる。

これも胸が締め付けられるような思い出が蘇ります。自由にできる雰囲気、失敗を責めない雰囲気を作らないで名前だけ先行するとグダグダになることが多い気がします。 改革、イノベーションなどが付けたプロジェクトからはイノベーションが起きないと思っている派です。

上司の受け売りになりますが、現場で困っている人もアジャイル開発懐疑派の人も色々な人に読んでほしい本だと思いました！ あと翻訳者の長澤さんがJSTQBの用語の合わせてくれたということで、テストクラスタの人も読みやすいと思います。