読者です 読者をやめる 読者になる 読者になる

$shibayu36->blog;

株式会社はてなでエンジニアをしています。プログラミングや読書のことなどについて書いています。

「チーム開発実践入門」を読んだ

tech book

チーム開発実践入門という本が最近出ていたので、読んだ。

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

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

この本は良くない開発フローの例をケーススタディとして2章で紹介し、その後の章でそれに対応する形でバージョン管理やチケット管理、テスト、構成管理などの紹介をしている。

なんとなくエンジニアリングの開発フローがうまく行っていないけど、どこから始めていいか分からないという人には非常に面白いと思う。2章のケーススタディの例を読んでみて、その中で確かに自分のチームでもあるあると思えたところを中心につまみ読みしてみると良いと思う。

個人的にはほとんど知っている内容ばかりだったので、どちらかというと事例を含めてもう少し内容があると良かったように思う。



この本を読んでいる中で一番良かったのは7ページに書いてあった話で

最適なプラクティスはケースバイケース
チーム開発の世界では、どこにでも通用する万能のベストプラクティスがあるというより、状況に応じたベターなパターンの組み合わせが何通りもある、という考え方が正解に近いでしょう。実際自分が関わるプロジェクトに応じた最適解を見いだせるかどうかが、プロジェクトを成功に導く鍵といえるでしょう。

というのがすごく良い。こういう開発フローの本を読んでいる時はその中に書いてあるものが良いものとして認識されがちで、そのまま試してチームのワークフローが大変なことになるみたいなことはよくあるように思う。ただこの本はケースバイケースなので、今回紹介するツールなどを使わなければならないわけではないと言い切っているところが良い。

この話、最近TDDとかテストの話でもすごくひっかかっていて、なんか軽くそういう系のブログとか読んでると「自動テスト」はみたいな話になって、なんでそんな全部をひっくるめてダメだみたいな否定に入るんだろうみたいな感じになった。「どの領域」に対する「どういうやり方」が良くないかという風に言わないといけないと思う。もちろんケースバイケースだからといって議論をしないというふうにすると最悪だけど、特にテストの話はこういうケースのことについて話しているんだろうなというのを思いながら読むほうが良いと思った。



今回の本はチームのエンジニアリングよりの開発の本だったけど、もうちょっとチーム文化とかの話を知りたかったら、Team Geekとかアジャイルサムライとかを読むと良いと思う。


Team Geek ―Googleのギークたちはいかにしてチームを作るのか

Team Geek ―Googleのギークたちはいかにしてチームを作るのか

アジャイルサムライ−達人開発者への道−

アジャイルサムライ−達人開発者への道−