読むのがホネな技術書やビジネス書を取り上げて2週間の読書期限を課して読んでアウトプットする仮想読書会「デッドライン読書会」の第69回。同僚と読書期限を約束することによって積読が確実に減るという仕組み。過去記事はこちら。
さて、今回読む本は「ソフトウェア開発現場の「失敗」集めてみた。 42の失敗事例で学ぶチーム開発のうまい進めかた」である。わりと好物な切り口！ しかし現代的というか、タイトルが長い～
『42の失敗事例で学ぶチーム開発のうまい進めかた』の概略
表題のとおり、ソフトウェア開発のよくある失敗事例を通じてどうすべきだったかを学んだり考える本である。著者がメーカー系の出身ということで、コンテキストをまとめるとこんな感じ。
- 組み込み系、デバイス制御系の製品に関するソフトウェア開発
- 自社開発（受託開発ではない）
- 委託開発もしているが部分的で、基本的には内製開発
- 大規模（複数チーム並列）ではないサイズの開発
- 組織文化はブラックではないが、ほどほど理不尽
このコンテキストと読者の距離が近ければ共感度は高いだろう。
「はじめに」で著者はこう書いている。
- 失敗の経験が危険を検知する
- （しかし）失敗自体はマイナスでしかない
リーダーとしてよい判断を下すには、自分の中に豊富な失敗のケースを持っておくことが必要です。一方、失敗を豊富にやらかしていると失敗を生かす前に会社をクビになってしまうというジレンマがあります。
そこで新しくソフトウェアプロジェクトのリーダーになった皆様、もしくはリーダーを目指す皆様に、著者の豊富な失敗経験から作った「失敗事例集」を提供できればと考えました。この「失敗事例集」を皆様がよい判断を下すためのガイドとして活用いただきたいと思います。当然、本書と全く同じ失敗はあり得ないと思いますが、それぞれの失敗をパターンとして覚えておけば、きっと役に立つはずです。
ソフトウェア開発現場の「失敗」集めてみた。 42の失敗事例で学ぶチーム開発のうまい進めかた、はじめに より
この考え方は大賛成だ。
ほどよく抽象的なレベルの42のパターン
さて、本書の目次は出版社のサイトなどでも閲覧できるので、興味があれば参照してみるとよい。上級者であればタイトルを見ればだいたいなにがテーマかわかるだろう
全体としては、抽象度がほどよく、誰にでも考えさせることができる記載になっているという印象だ。
- アーキテクチャやコードそのものまで深掘りされているわけではない（プログラマでなくても読める）
- 特定の開発プロセス（ウォーターフォールとかアジャイルとか）にも依存しないし、どんなプロジェクトでも直面しそうなフェーズが揃っている
というわけで新人エンジニアでも若手でも十分楽しめるのではないだろうか。
むしろ、若手を含むチームで読書会などをして、チームの教養として本書を取り込むとよいだろう。
事例の表題がパターン名のようになっているので「あー、これは42事例本の『初期企画至上主義』になってませんか」「そうかもー！」といった会話がチーム内でできると良さそうだ。
一方でベテランでも改めて通読することで、忘れていたことを思い出して「ウッ！」と感じることもできる（とりあえず、わたしはそうだった）。
なかなか興味深い本である。
他人の失敗から学ぶのはスキルアップの早道
著者の言うとおり、自分のプロジェクトでみずからやらかして経験値を得るのはリスクも高いし非効率だ。だから、他人の失敗を疑似体験するのが良い。
本書で（失敗事例が）もの足りない人もいるだろうと考えて、思いつく限りの類書を挙げておこう。
闘うプログラマー ビル・ゲイツの野望を担った男達
デスマーチの元祖といえるMicrosoftのWindowsNT 3.1の開発に関するドキュメンタリーである。さすがに古いが、現代の開発でも活用されているプラクティスがけっこう使われていて興味深い。とりあえずWikipediaを見ていくと匂いは感じ取れるだろう。
The Unicorn Project
DevOpsの本なはずなのだけど、前半がホラーなプロジェクトのドキュメンタリーになっている。以前に本ブログで取り上げているので興味があればどうぞ
IT業界の病理学
こちらは翻訳書ではなく、日本のIT業界の問題あるあるを病理学風に整理するというエッセイ集。以前に本ブログで取り上げているので興味があればどうぞ
というわけでこの読書は終わり。
さて、次は何を読みましょうかね……
積んである本だと、このあたりを消化したい感はある
あと未購入だけど話題の本だとこのあのあたりも読みたい
読むべき本は尽きないのであった
