More Effective Agileの前半部分を読んだ #デッドライン読書会

読むのが骨な（積みがちな）技術書やビジネス書を取り上げて２週間の読書期限を課して読んでアウトプットする仮想読書会「デッドライン読書会」の第16回。今回はSteve McConnell氏の「More Effective Agile」前半部分（12章まで）がノルマである。予測にたがわず、有用な本であることに疑いはない。

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

作者:Steve McConnell
発売日: 2020/06/11
メディア: Kindle版

ソフトウェア開発を「うまくやる」ための本

のっけから、有用な匂いがビシバシ伝わってくる。俺たちのMcConnell氏が帰ってきた！

アジャイル開発に関するほとんどの書籍はエバンジェリストによって書かれている。エバンジェリストは特定のアジャイルプラクティスを提唱しているか、アジャイル全体を奨励している。筆者はアジャイルのエバンジェリストではない。筆者は「うまくいくもの」の提唱者であり、「なんの根拠もなく大袈裟な約束をするもの」への反対者である。本書では、意識高い活動としてアジャイルを扱うのではなく、管理的なプラクティスと技術的なプラクティスの集まりとして扱う。ここで扱うプラクティスは、その効果や相互作用をビジネス用語や技術用語で理解できるものである。
More Effective Agile “ソフトウェアリーダー”になるための28の道標「第1章はじめに」

ちなみにこの後、「第3章複雑さと不確実さという課題に対処する」にて、なぜアジャイルなのかについても明快に説明される。流行っているからでも、VUCAの時代だからでもなく、明確にアジャイルプラクティスに組織が投資したほうが良いという説明がされているのだ。というわけで、それ以降本書は批判的な立場を崩すことなく、アジャイルプラクティスの良い使い方についてアドバイスするという体裁となっている。

35年かそれ以上にわたってソフトウェア業界に携わってきた中で、一番の難題は、「コード＆フィックス開発」を避けることだった。コード＆フィックス開発とは、事前の見直しや計画を立てずにコードを書き、そのコードが動くまでデバッグする手法のことである（中略）。アジャイル開発には、見るからに短期集中型でコード中心であるために、チームがアジャイル開発のプラクティスを実践しているのか、それともコード＆フィックスを行っているのかますます見分けがつかなくなる、という課題がある（中略）。より効果的なアジャイルのミッションの1つは、アジャイル劇場を防ぐことである。アジャイル劇場とは、チームがアジャイルという化粧でコード＆フィックスを覆い隠すことを指す。
More Effective Agile “ソフトウェアリーダー”になるための28の道標「第4章より効果的なアジャイルの始まり：スクラム」

あと、10章で既存の大規模アジャイル開発のフレームワークをバッサリ批判しているあたり、非常に痛快。

まだ完読していないけれども、おすすめの読み方は次の通り

まず監訳者あとがきを読んで、本書の業界的な位置付けや、ねらいについて俯瞰する
1章と2章を読む
巻末の「28の基本原則のまとめ」を読む
残りを読む

マコネルと言えば……

有名なのは次の2冊だと思う。ソフトウェア開発における見積もりという行為には様々な批判があると思うけれども「ソフトウェア見積り」はいまだに有用度は高いと思うので、未読であれば強くおすすめする。「Code Complete」は好きな本だけれども、かなり古さを感じるので今から読むのであればよく注意したほうが良い（古書を買うか、Kindleでセールになっている時に買い、古いと感じたところは飛ばし読みするのが良いだろう）。