ikeike443のブログ

Playコミッターが書くソフトウェアビジネスに関心がある系のブログ

『チーム開発実践入門』という本を書きました

2年くらい前に技術評論社さんから「チーム開発に役立つツールや方法論をまとめた本を書かないか」とお声がけいただきました。

それから構想1年(ぼんやりしてた)、執筆に1年かけて(週末がなくなった)、ようやく4月16日に発売できそうなところまで来ました。

今印刷所でゴインゴイン刷っていると思います。


技術評論社さんのページを見てもらうと、表紙画像もアップされてますね。
http://gihyo.jp/book/2014/978-4-7741-6428-1

Amazonさんにもページができていますが、まだ表画像はアップされてません。

チーム開発実践入門 ~コラボレートを円滑に行うツール・方法論 (WEB+DB PRESS plus)

チーム開発実践入門 ~コラボレートを円滑に行うツール・方法論 (WEB+DB PRESS plus)

目次もまだ公開されていませんが、数日中に公開されると思います。また注意深い人は気づいたと思いますが、技術評論社さんのページとAmazonさんセブンネットさんのページとでサブタイトルが違っています。技術評論社さんのページに書いてあるサブタイトルのほうが正しいです。これも数日中に改まると思います。

執筆にあたって意識していたこと

チーム開発に役立つツールと方法論を一冊にまとめるのってかなり辛くて、詳細に書くと全12巻組みくらいの大長編になっちゃいます。

そこをグググッと凝縮して、300ページちょっとに収めました。なのでツールの使い方にフォーカスを当てて解説しています。ホントはチーム開発を上手く行かせるのに必要なのってツールの使い方だけじゃなくて、チームビルディングの方法だったり、タフネゴシエーションの技術だったり、いろいろあるのですが、そこをあえてツールに絞って書いています。大長編になっちゃうからね。。

ツールに絞ったとしても全6巻くらいにはなるはずのところを1冊にしているので、ツールのインストールの方法や細かな設定方法についてはそれなりに端折って書いています。チーム開発の現在形をざっと概観するための本だと捉えてくれれば幸いです。

総じていうとアジャイル開発の本なのですが、書籍中ではアジャイル開発という言葉はほとんど使っていません。最近、アジャイル開発という言葉にはなんだかスピリチュアルなニュアンスがついちゃったような印象が個人的にあり、出来るだけ避けたかったというのがあります。現実の問題に対処するためにツールを使ってどう問題解決を実践するのか、という話にフォーカスを当てたつもりです。

目次

詳細な目次は公開されるのを待っていただくとして、ここでは大項目レベルでお知らせします。

第1章 チーム開発とは

導入ですね。チーム開発ってどういうもので、どんな問題が起きるのか、どう立ち向かえばいいのか、について触れています。

第2章 チーム開発で起きる問題

チーム開発の現場で実際に起きがちな問題をケーススタディとして見せている章です。
起きる問題の例としては、例えば下記のようなものです。

  • 重要メールが多すぎて優先順位が決められない
  • テスト環境で動かしてみるまで、アプリが壊れていることに気づかない
  • 自信を持ってリファクタリングできない
  • バグの発生時期、修正時期がわからない、追跡できない
  • 開発環境で動くものが本番環境では動かない
  • リリースが複雑で属人的、時間がかかる、よく失敗する

本文ではこの他にも色々、ありがちな問題をあげ、起きていることの解説をしています。そしてこれら問題の解決策となるのが次に続く3章から始まる各章、というかたちです。

ちなみに3章以降は、チーム開発改善の際に手をつけるべき順番に並んでいます。

第3章 バージョン管理

バージョン管理の章です。基本的にGitの話を書いているのですが、バージョン管理システムの歴史についても触れています。ほんの20年ほどで劇的に変わっているのがバージョン管理です。チーム開発の基本となるこのバージョン管理が、いかに変化の激しい分野なのかを知ると色々はかどります。

また、データベーススキーマのバージョン管理(データベースマイグレーションですね)についても触れています。

第4章 チケット管理

チケット管理システムはOSSのものも商用のものもたくさんありますので色々紹介しています。バージョン管理システムとの連携方法も説明しています。チケット駆動開発についても簡単に解説しています。

第5章 CI(継続的インテグレーション

CIについて、主にJenkinsをベースに解説しています。ビルド、テストの自動化の方法、Jenkinsの使い方、Pull RequestをCIする方法(GitHub Pull Request Builder Plugin)も解説しています。もちろんTravisCIにも触れています。
ここまでがチーム開発の基礎となる部分の解説です。ちなみにここまでは私が書いています。

第6章 デプロイの自動化(継続的デリバリー)

デプロイの自動化について、必要性と方法を解説しています。
Bootstrapping, Configuration, Orchestrationの3フェーズに分けて解説しています。
Kickstart, Vagrant, Chef, Capistrano, Fabric, Serverspecといったツールについて解説しています。

クラウド時代のブルーグリーンデプロイメントについても解説しています。また、PaaSを使ったデプロイについても触れています。

この章はシャノンの藤倉さんが書いているのですが、この章が一番大変でした。執筆していた2013年という年はこの分野に劇的な進歩が見られた年で、どんどん変わっていく技術を追いかけながら実践して書籍に落としこんでいくのはかなりの苦労だったと言えます。

残念ながら時期が上手く合わず、Dockerを始めとするImmutable Infrastructureについては、ほんの少し言及するにとどまりましたが、総じてエキサイティングな章になっていると思います。

第7章 リグレッションテスト

最後の章はSelenium1をつかったリグレッションテストの自動化についての章です。時間のかかるSeleniumテストをいかに高速化すればいいのかについて、シャノンの井上さんが書いています。内容としては2年ほど前にJenkinsユーザーカンファレンスにて井上さんが発表した内容がベースになっています。

類似書籍との違い

同じ技術評論社さんから先ごろ出版された『GitHub実践入門』と似ているんじゃないかと思う方もいらっしゃるかもしれません。
確かに一部かぶっているところもあるのですが、こちらの書籍のほうがより広い範囲を扱っている本になります。逆に言うとGitHubについては、『GitHub実践入門』のほうが詳しくわかりやすいと思います。
同じ事は『Jenkins実践入門』や『JUnit実践入門』などについても言えます。

むしろのこの『チーム開発実践入門』という本は、『GitHub実践入門』、『Jenkins実践入門』、『JUnit実践入門』といった書籍の間をつなぐミッシングリンクのような本です。

この本で概要をつかみ、さらに個別の書籍を買って理解を深めることで、バラバラの知識が一つにつながることと思います。

興味の湧いた方はぜひお買い求めを!

発売日は4月16日予定です。

デベロッパーサミット2014 OSSコミッタ大集合に登壇してきました

遅くなったけど簡単に。


先週の13日、Developers Summit 2014:【13-E-1】OSSコミッタ大集合に登壇してきました。

資料は下記です。いろんなOSSのコミッタさんがいらっしゃいます。
https://docs.google.com/presentation/d/1eh7fMYMEUA1CriyUxay4wkYaWtnxLkg0l4jtd9CXLv4/htmlpresent

当日の様子はこちらから:
2014/02/13 デブサミ2014【13-E-1】OSSコミッタ大集合 #devsumiE - Togetterまとめ


元々のこの企画の趣旨はHerokuの相澤さんが下記のように定義してました。

ソーシャルコーディングの台頭によって、オープンソース・ソフトウェアへの貢献は「ふつうの」エンジニアにも解放されました。新機能の開発やバグの修正だけでなく、不具合の報告やドキュメントの修正も、オープンソース・ソフトウェアに対する素晴らしい貢献活動です。誰もが知っている有名なプログラマーだけでなく、デブサミに集まるエンジニアの中にも数多くのオープンソース・ソフトウェアのコミッター/コントリビューターがいます。オープンソース・ソフトウェアへの貢献はわたしたちソフトウェア開発者にとって、もはや特別な活動ではありません。わたしたちがオープンソース・ソフトウェアに対して何か貢献をしたいとおもったとき、今できることがあります。
この企画では、なるべく多くの『人』を紹介することで、もしかしたら「敷居が高い」と感じていたかもしれないオープンソース・ソフトウェアへの貢献を、より身近に感じてもらえたらと思っています。


僕もそのとおりだと思っていて、僕みたいなヘボいプログラマーでもOSSに貢献できる余地はあるんだよということが伝わればいいと思い登壇いたしました。結果、聴衆の方にどう伝わったかはちょっとわかりませんが。。

当日は思ったことをうまくしゃべることができなかったですが、言いたいことは簡単で、

  • OSSにバグを見つけたら報告しよう
  • そのバグを直せるならその場で直してパッチを送ってあげよう
  • ドキュメントに不備があれば直したり整理したりしてあげよう
  • その他なんでも気づいたら手を貸してあげよう

くらいしかないです。

OSSは基本ボランティアベースで(企業が担いでいるものももちろんたくさんありますが)、みんなリソース的にもカツカツの中やっていることがほとんどです。

普段OSSのお世話になっていないソフトウェアエンジニアはいないと思います。普段OSSから受けている恩恵を、なんらかのかたちで少しでも還元していただければ、世界中のみんなが少しずつハッピーになります。

というわけで、OSSに貢献しよ−!

maven-archetype-quickstartが未だにJUnit3.8.1使ってる件

どうにかならないんでしたっけ。。

mvn archetype:generateすると、下記のように344(maven-archetype-quickstart)を勧められて、

$ mvn archetype:generate
略
913: remote -> tk.skuro:clojure-maven-archetype (A simple Maven archetype for Clojure)
914: remote -> uk.ac.rdg.resc:edal-ncwms-based-webapp (-)
Choose a number or apply filter (format: [groupId:]artifactId, case sensitive contains): 344:

言われるがままにプロジェクトを作って、出来上がったpomを見ると、JUnit3.8.1。。

<dependencies>
    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>3.8.1</version>
      <scope>test</scope>
    </dependency>
</dependencies>

この問題は既に下記チケットで報告され、既に修正されているっぽく*1、次回リリースの1.2に含まれそうだが。。
http://jira.codehaus.org/browse/MARCHETYPES-41

セントラルリポジトリを見てみるとまだ1.2はリリースされてない。。
http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22org.apache.maven.archetypes%22%20AND%20a%3A%22maven-archetype-quickstart%22

ちょ、困るんですけど。。maven-archetype-quickstartのMLどこなん。。とりあえずチケットAssigneeのOlivierってのにメールしてみたけど。。。

*1:Diffくらい貼れよと思った

Scalaのカバレッジツールの定番scctがMaven Central Repoに

アップロードされてました。(com.github.scctの方。com.github.seratch.reaktorの方は id:seratch さんでしょう)
http://search.maven.org/#search%7Cga%7C1%7Cscct

誰がやったんだろ。

このスレ見る限り、まだ本人からのコメントはないけど。
https://github.com/mtkopone/scct/issues/43