チーム開発実践入門を読んでみた。既に実践している人でも役立つ本。

この本を読みました。

2014年5月初版と出てから少し時間が経っている書籍ですが、まさに今、自分が求めている内容が書いてあり、とても役立ったので、この記事書いていきます。

チーム開発実践入門 ~共同作業を円滑に行うツール・メソッド (WEB+DB PRESS plus)

読書の目的

この本では、チーム開発を効率化するために必要なものバージョン管理、チケット管理、CI/CD等が網羅的、体系的に説明されています。

私自身、これらの経験自体はありますし、有用性も体験としては理解しているつもりです。ただ、それらは自分が現場に入った時には既に整備されていたもので、深く考えずに使っていたり、いくつかは勉強したのですが、場当たり的で虫食い状態の知識があるだけでした。

今、開発しているサービスでは、このあたり0から整備が必要になるので、このタイミングで体系的に学んでみようと思い本を探していて、この本を見つけました。

読みました

目次

技術評論社のこのシリーズの書籍は、構成がとてもわかりやすく整理されているのが一つの特徴と思っています。

目次を見るだけでも話の流れや、内容がわかりやすくなっています。以下には、「章」のレベルで目次を並べていますが、技術評論社のサイトでは、もう2段階深いところまで目次が公開されています。きっと、それを読むだけでも得るもがあるのではないかと思っています。

第1章 チーム開発とは
第2章 チーム開発で起きる問題
第3章 バージョン管理
第4章 チケット管理
第5章 CI(継続的インテグレーション)
第6章 デプロイの自動化(継続的デリバリー)
第7章 リグレッションテスト

1章が導入、2章でケーススタディを使って開発現場の課題の洗い出し、3章以降でそれらの課題に立ち向かうためのプラクティス毎の説明が続きます。

2章のケーススタディ 読んでると辛くなる

1章の導入の後、2章にケーススタディが続きます。話の流れ上、最悪の現場を想定したケーススタディになっています。さすがに100%当てはまる酷い開発現場は無いと思う(そう信じたい)のですが、100%当てはまらない素晴らしい現場も少ないのでは無いかと思います。そういう意味では誰でも読んでて共感できるポイントや、自分の現場に感謝するポイントがあって面白いと思います。

こういう網羅的な失敗プラクティスは読んだ事無いので、自分のいる開発現場を網羅的に振り返るという意味でも役立ちました。

3章以降の説明の粒度が理解しやすい

3章以降の説明も、そのプラクティスが必要な理由、関連用語の説明、プラクティスのメリット、歴史背景などが体系的に説明されています。

単純に便利だと思って使っていたツールも、そのツールが解決している課題を理解することで、より良く使えると思います。体系的にまとめられているため、実は当たり前に使っていたツールが気付かないうちに裏で解決していた課題など、気付きがありました。

ツールについては、代表的なものの紹介程度に留められており、それぞれは深くありません。ツール毎の深い話は別のツール毎の書籍を読んだ方が良いと思います。

むしろ個別のツールに寄った説明では無く、どのツールを使っても共通して流れている考え方だったりする内容に充填が置かれた説明が多いです。このあたりが初版から4年以上経っているのに今でも役立つ内容になっている理由だと思います。

オススメする読者

チーム開発のプラクティスについて経験はあるけど体系的に復習したい人

既に経験も知識もある方、現場にもある程度導入済みの方の場合でも、何か課題が出た時に手元にあれば、辞書的に使うことで課題整理のツールになると思います。

この書籍に書かれているプラクティスを取り入れている現場に入ったばかりの人

自分の場合、ここに書かれているようなプラクティスに現場で初めて触れた時、場当たり的にWEBでググって、書籍を買い漁り勉強しながら何とか理解を深めてきました。もし、その時にこの本が手元にあればポイントを絞って効率の良く理解できたのでは無いかと思っています。もっと早く知りたかった。

これからチームの開発環境を整備する人

今の自分です。最初から全てを完全にするのは無理だと思います。優先度つけて取り組むにしても、ゼロベースで始めるのと、網羅的・体系的な知識があった上で進めるのとでは大きな違いが出ると思います。

運用やインフラエンジニアのように開発には直接参加しないが、開発チームと連携している人

当然ながらインフラの業務でも使える内容が多いです。開発からしてみてもインフラの人がこの辺りを理解していると助かるはず。開発とインフラが一緒に進めていった方が良い部分もあると思います。

最近技術から離れてしまっているエンジニア管理職の人

エンジニアが製品やサービスの開発ではなく、その開発環境の整備に時間かけてる理由がわかると思います。ツールが必要な理由が最低限の技術的用語でまとまっています。流石にエンジニアの経験が0では難しいのかもしれませんが、一度でも開発の経験があれば理解できる内容なのではないかと思います。