当たり前といえば当たり前だけど、社会人になってからはチームで開発することが増えている。プログラミングはひとりだとしても、運用するサービスをひとりで回すことはない。

僕が考える「チーム開発」は、開発部内におけるプロデューサー×エンジニアの掛け合いを指すのではなく、そのサービスやシステム、機能に関わるすべてのステークホルダーを巻き込んだもの。医龍で言うところのチームドラゴン。

共同作業を円滑に行う為に

昨今は開発に関わること以外でも、とりあえずわからないことはGoogle検索すればある程度の正確性を持った回答は得られるし、自分ひとりでの勉強ならほとんどがそれで事足りると言っても過言ではない。

しかし、チームという複数人単位で作業を進める際には、共同作業におけるメリットやデメリットがある。メリットは言うまでもなく、スピード感だったり、規模感だったり、とにかくひとりでは得られない（であろう）恩恵を手にできる。

一方でデメリットとしては、そのスピードや規模ゆえに作業の行き違いが発生したり、知らない作業が行われていたり、といった積み重なっていくことで悪循環を生み、やがてはデスマーチの温床となり得る事象が挙げられる。

円滑に行う為のツール・メソッド

様々な共同作業における便利ツールやメソッドが登場している中で、どういった場面でどれをどのように使えば正解なのか。バグの無いシステムは存在しないけど、バグが極力存在しないシステムを目指すにはどうするのか。

• バージョン管理
• チケット管理
• CI（継続的インテグレーション）
• CD（継続的デリバリー）
• リグレッションテスト

本書では、まずツールを用いない（又は場面において適切でないツールを用いた）開発フローでのケーススタディを紹介した上で、世の中に存在する様々なツールを用いた解決策、組み合わせ例を紹介している。

バージョン管理

CVSやSubversionといった歴戦の強者が数多く存在するバージョン管理。これを用いていない開発はおそらくほとんど存在しないはず、だが、一方でどこまでそれを有効的に用いることができているか。

移り変わりの末、現代でベストプラクティスとされている分散型のGitを用いたスムーズな並行開発のフローを紹介している。ソースコードだけでなく、データベーススキーマやデータさえ、Gitで管理すべきなのである、と。

チケット管理

紙面やメール、Excelによるタスク管理も不可能ではない。が、そこには様々な問題点が存在する。チケット管理でバグの報告や新機能開発を進めていくメリットは大きい。

数あるチケット管理システムの紹介と、前章のバージョン管理システムとの連携についても解説している。これにより、現場においてよく発生しがちな「あのバグいつ直ったの？」「なぜこんな変更が入ったの？」の解決にも多大な功績を果たす。

CI（継続的インテグレーション）

この辺りからはいよいよ本格的な開発フローがメインとなっていく。アジャイル開発を進めていく上で、CIは非常に重要な考え方である。しかし、手動での作業はコスト的に限界がある。

そこで、Jenkinsというツールを使ったCIのプラクティスを紹介している。Jenkinsとバージョン管理システム（Git）との連携を行うことで、スピードと品質の両方を担保した開発フローを実現する。

CD（継続的デリバリー）

本書の章題は「デプロイの自動化」である。システムの規模やサーバの台数などが増大するにつれ、デプロイにかかる時間は比例して増えていく。また、人的ミスの発生率も自ずと増す。

ここでは、デプロイメントパイプラインにおけるツールチェーンを以下の3つのレイヤーに分け、解説している。

• ブートストラッピング（Bootstrapping）
• コンフィグレーション（Configuration）
• オーケストレーション（Orchestration）

各レイヤーで用いるツールとして、VagrantやChef、serverspec、Capistranoなどについてそのインストール方法から実行方法までコマンドベースで解説している。

リグレッションテスト

開発者視点によるユニットテストではなく、ユーザ視点で行われる結合テスト・ユーザ受け入れテストについての章。

かなりの時間と人的労力を必要とするリグレッションテストをどこまで自動化させることができるか。その為に用いるSeleniumについて、また、Jenkinsとの連携による分散ビルド＆テストの並列実行についても言及している。

ベストプラクティスはどれか

本書でも度々書かれていることだが、時代とともにツールやその使われ方は変化していくものであるし、開発現場の環境や掛けられるコストによってもベストプラクティスは異なる。

一概に、どのツールを組み合わせるのがベストプラクティスである、とは断言できない。つまり、個々の環境に応じてツールの選定は慎重に行うべきであるし、必要があればその見直しも行うべきである。

使えるものを使わず、非効率的かつリスクの高い手法をとり続けるのではなく、何がベストプラクティスなのかを常に考え、改善し続けていく姿勢こそ、共同作業を円滑に行うメソッドなのではないかと考える。

[amazonjs asin="4774164283" locale="JP" title="チーム開発実践入門 ~共同作業を円滑に行うツール・メソッド (WEB+DB PRESS plus)"]