チーム開発をスムーズにするために何ができるか

『チーム開発実践入門』紹介

自己紹介

• 池田尚史（いけだたかふみ）

• 株式会社ディー・エヌ・エー所属

• 『チーム開発実践入門』を執筆しました

• オライリー『Jenkins』にも付録を書きました

• Playframework1のコミッター（幽霊部員）

@ikeike443

• コンサルティングファームで数年間に渡り超大規模プロジェクトに復数参画

• 技術力が明暗を分けると痛感しプログラマーに転身

!

• VCS: 無いこと多い

• ITS: Excel

• CI: なにそれ？

2001~2004

• 国産ERPパッケージベンダーで製品企画と開発マネージャー、プログラマーを経験

• この時期瞬間最大で同一製品の6バージョンのメンテナンスを行っていた。。

• SVN+Tracの導入推進をした

• VCS: PVCS, 後にSVN

• ITS: 独自システム, 後にTrac

• CI: なし, 後にHudson

2005~2010

• B2B向けWebサービス（SaaS）ベンダーでプロダクトマネージャー兼プログラマー

• この時期にPlayframeworkのコミッターになるなどした

!

• VCS: Git

• ITS: Backlog, PivotalTracker

• CI: Jenkins

2010~2013

大体こんなこと話します• チーム開発の課題って

• プロジェクトの課題って

• ツールの情報は散逸してる

• 執筆にあたって気にしたところ

• 各章紹介

チーム開発における課題

の話の前に

ソフトウェア開発 プロジェクトによくある課題

• プロジェクトの目標が定まっていない

• 何を達成すれば成功なんだっけ？

• 要件が定かでない

•誰が要件を決めるのか不明

•おもてたんとちゃう

• 価値を提供できているのか不明

•やる意義はあるんだっけ？

•利益は出るのか？

• リスク管理ができてない

• プランBがない

• チームがパフォーマンスを出していない

• チームビルディングができていない

• 開発効率が悪い

再掲

• プロジェクトの目標が定まっていない

• 誰が要件を決めるのか分からない

• 価値を提供できているのか分からない

• リスク管理ができていない

• チームがパフォーマンスを出していない

言い換えると

• ゴールはどこ？

• 決めるのは誰？

• 利益は出るの？

• リスクは見えてるの？

• チーム開発はうまくいってるの？

チーム開発は問題の一部

• ゴールはどこ？

• 決めるのは誰？

• 利益は出るの？

• リスクは見えてるの？

• チーム開発はうまくいってるの？

チーム開発をはじめるに あたって考えるべきこと

• 方法論はどんなものを使うの？

• コミュニケーションプランはどうする？

• 成果はどう測る？

• チームビルディングはどうする？

• 開発ツールはどう使う？

ツールの使いこなしは さらにその一部

• 方法論はどんなものを使うの？

• コミュニケーションプランはどうする？

• 成果はどう測る？

• チームビルディングはどうする？

• 開発ツールはどう使う？

だが、基礎である

プロジェクトを成功に導くための大事な基礎

• 市場の変化は早い

• 計画は容易に変わり得る

• 臨機応変に変化に対応しなければ

なぜなら

• 遅すぎる開発サイクルはNG

• 複数人が素早く並行して開発できないと

• でもデグレードは起こしてはいけない

ゆえに

では

ツールが解決する問題って？

• 重要メールが多すぎて優先順位が決められない

• テスト環境で動かしてみるまで、アプリが壊れていることに気づかない

• 自信を持ってリファクタリングできない

• バグの発生時期、修正時期がわからない、追跡できない

• 開発環境で動くものが本番環境では動かない

• リリースが複雑で属人的、時間がかかる、よく失敗する

• こういった問題はツールをうまく使うことで解決できる

• Webの記事なんかを見てると、色々ツールがあることがわかる

• 組み合わせれば解決しそうだね！

ここ3～5年Webを見て 実践し続けていればね

新人さんだったり、 訳あってキャッチアップ してこれなかった人は どうなるんだろう？

例えばググってみると

アジャイル開発Gitチケット管理Chefバージョン管理ビルド自動化JUnitSeleniumテストフレームワークCapsitrano Github Puppetテスト駆動開発FabricデプロイInfrastructure as code Serverspec リグレッションテストImmutable Infrastructure Vagrant VCS

アジャイル開発Gitチケット管理Chefバージョン管理ビルド自動化JUnitSeleniumテストフレームワークCapsitrano Github Puppetテスト駆動開発FabricデプロイInfrastructure as code Serverspec リグレッションテスト

アジャイル開発Gitチケット管理Chefバージョン管理ビルド自動化JUnitSeleniumテストフレームワークCapsitrano Github Puppetテスト駆動開発FabricデプロイInfrastructure as code Serverspec リグレッションテスト

アジャイル開発Gitチケット管理Chefバージョン管理ビルド自動化JUnitSeleniumテストフレームワークCapsitrano Github Puppetテスト駆動開発FabricデプロイInfrastructure as code Serverspec リグレッションテストImmutable Infrastructure Vagrant Trav

as code Serverspec リグレッションテストImmutable Infrastructure Vagrant VCS

as code Serverspec リグレッションテストImmutable Infrastructure Vagrant VCS

• 情報が多い。。。

• 整理されてない。。。

• 何から手をつければ。。。

そこで『チーム開 (ry

世にあるプロジェクトマネジメント本

• 予算管理の話

• 工数管理、見積もりの話

• チームのモチベートの話

• 採用の話

• 上記はもちろん大事なんだけど、「作らない人」の話ばかり

世にある開発ツール本

• ツールの紹介

• インストール方法、コマンド解説

• 事例紹介

• チケット管理、バージョン管理、CI、CD等々バラバラに解説

• 一つ一つの担当者には大変有益だが、全体を俯瞰できない

断絶

そこで『チーム開 (ry

話を受けた当初• 2012年

• 当時自分の開発環境は

• SVN

• Backlog, Bugzilla

• ReviewBoard

• Jenkins

• Git, Githubはまだ試している段階（OSSでGithubは使ってた）

• ChefやVagrantなんかもまだまだ本格的に触っていなかった

ぼんやりしてたら 一年経過

2013年

CIは当たり前に なってきた

GitHubを使う 会社も増えた

ツールもそろってきて 継続的デリバリも かたちが見えてきた

執筆開始

• 私自身のトラウマを克服したい

• 困っている現場を少しでも無くしたい

開発現場の地図になれば

各章紹介

第一章 チーム開発とは

チーム開発とは

最適なプラクティスはケースバイケース

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

チーム開発とは

自分が関わるプロジェクトに応じた

最適解を見いだせるかが鍵

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

チーム開発で起きる問題• チーム開発の現場で実際に起きがちな問題をケーススタディとして見せている章です。

• 実際にわたしが体験したいくつかの現場での事例を組み合わせています

• 課題管理ができない

• デグレが頻発

• 環境ごとに動きが違う

• etc etc

チーム開発で起きる問題• 重要メールが多すぎて優先順位が決められない

• テスト環境で動かしてみるまで、アプリが壊れていることに気づかない

• 自信を持ってリファクタリングできない

• バグの発生時期、修正時期がわからない、追跡できない

• 開発環境で動くものが本番環境では動かない

• リリースが複雑で属人的、時間がかかる、よく失敗する

チーム開発で起きる問題

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

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

第三章 バージョン管理

バージョン管理

• チーム開発をスムーズにするための基礎の基礎

• さすがに使ってない現場はないとは思うが

• データベーススキーマのバージョン管理（データベースマイグレーションですね）についても触れています

バージョン管理

• バージョン管理システムの歴史についても触れています

• ほんの20年ほどで劇的に変わっているのがバージョン管理です。いかに変化の激しい分野なのかを知ると色々はかどります

バージョン管理

• 20年前新人だった人がまだ40代

• 決裁権を持っている彼らの技術センスも重要なポイント

バージョン管理• ちなみに

• バージョン管理の歴史図

• git-flowの図

• 両方とも作者に許可をとって翻訳しました

• 献本もしたよ！

第四章 チケット管理

チケット管理

• チケット管理システムはOSSのものも商用のものもたくさんあります

• 色々紹介しています。

チケット管理

• バージョン管理システムとの連携方法も説明しています。

• チケット駆動開発についても簡単に解説しています。

チケット管理• チケット管理に向くフェーズ、向かないフェーズもあります

• チケット管理システムは定型的な課題管理に向く

• 流動的な課題の管理には非定型ドキュメントを使うべき

• 課題の粒度と使うべきツールについても示唆しています

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

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

• 継続的改善に必要不可欠なのがCIです

• なぜ不可欠なのか、以下の2点で説明しています

• 市場の変化のスピード

• コストメリット

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

• CIについて、主にJenkinsをベースに解説しています。

• ビルド、テストの自動化の方法、Jenkinsの使い方について解説しています。

• Pull RequestをCIする方法（GitHub Pull Request Builder Plugin）も解説しています。

• もちろんTravisCIにも触れています。

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

• ビルドが壊れた時のゲームについてなど、CIの運用についても触れています。

• CI自体は目新しいものではなく、大昔から実践されてきたプラクティスであることにも触れました。

• ここまでがチーム開発の基礎となる部分です。

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

第六章 デプロイの自動化 （継続的デリバリー）

• デプロイの自動化について、必要性と方法を解説

• Bootstrapping, Configuration, Orchestrationの3フェーズに分けて解説

• Kickstart, Vagrant, Chef, Capistrano, Fabric, Serverspecといったツールについて

デプロイの自動化

• クラウド時代のブルーグリーンデプロイメントについても解説

• また、PaaSを使ったデプロイについても

デプロイの自動化

• 執筆していた2013年という年はこの分野に劇的な進歩が見られた年

• どんどん変わっていく技術を追いかけながら実践して書籍に落としこんでいくのはかなりの苦労

• 残念ながら時期が上手く合わず、Dockerを始めとするImmutable Infrastructureについては、ほんの少し言及するにとどまりまった

• 総じてエキサイティングな章になっているはず

デプロイの自動化

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

• 受入テストとそのリグレッションの自動化

• 意外と具体的な情報がないのがこの分野

• デグレを絶対に起こさず機能追加していくには必須

• 特にB2B向けのサービスでは重要

リグレッションテスト

• Selenium1をつかったリグレッションテストの自動化について主に書かれている

• 時間のかかるSeleniumテストをいかに高速化すればいいのかについてJenkinsの分散ビルドをどう使っていけばいいか解説

リグレッションテスト

• （一般的に言って）プログラミングが不得意な人の多いQA担当者とともにいかに効率的に受入テスト自動化に取り組むかについても示唆

• 内容としては2年ほど前にJenkinsユーザーカンファレンスにて発表した内容がベース

リグレッションテスト

ぜひ読んでみてください！ 職場の同僚にもすすめてね！

以上、本の紹介でした

おまけ

• プロジェクトの見積もり、計画

• 運用における振り返りと改善企画

• サービス企画、製品企画と開発を両立するには

• コードレビューのやり方、ツール

• コーディング規約等々

• エディタの使い方、フォーマットのそろえ方など

• 開発環境を良くするための予算のたて方稟議の通し方

• スモールスタートのやり方

• etc, etc, etc..

漏れたもの

以上、

開発現場の改善に 取り組む皆様の よき地図となれば

幸いです

ご清聴ありがとうございました