6月19日、
イベント開会の挨拶 ～DevLOVEとは
DevLOVE主催者である市谷聡啓氏
HangarFlight
飛行機乗りにとって、
「チーム開発をスムーズにするために何ができるか」
「言いたいことは本に全部書いてある」、
今回は本の中身に少し触れつつ、
チーム開発の課題
チーム開発について語る前に、
- プロジェクトの目標が定まっていない
よくある過ちで
「プロジェクト達成の定義」 がされていない状態でプロジェクトが進むことがある。これでは、 いつまでたってもプロジェクトが完了することはない。 - 誰が要件を決めるのか不明
誰がOKと言えば良いか、
決裁者が不明のままプロジェクト進行することがある。また確認する人が居ない状態でプロジェクトが進むと、 最終成果物が思っていたものと違う可能性もある。 - 価値を提供できているのか不明
プロジェクトの目標や要件が決まっていても、
そこに価値がなければ成功とは言えない。プロジェクトを進める意義はあるのか、 利益が度外視されていないかなどの共通認識で持っておく必要がある。 - リスク管理ができていない
いわゆるプランBが無い場合に一つの失敗ですべてが破綻するプロジェクトもある。プロジェクトを進める上で、
リスクヘッジのための代替策は用意しておくべき。 - チームがパフォーマンスを出していない
一人で開発していた時のパフォーマンスが100％の時、
2人になったからといって200％にはならない。
これらを言い換えると、
- ゴールはどこ？
- 決めるのはだれ？
- 利益は出るの？
- リスクは見えているの？
- チーム開発はうまくいってるの？
「見ての通り、
「チーム開発を始めるにあたって考えるべきこと」
- 方法論はどんなものを使うの？
- コミュニケーションプランはどうする？
- 成果はどう測るのか？
- チームビルディングはどうする？
- 開発ツールはどう使うのか？
ツールで解決できる問題
このようにツールはあくまでチーム開発を進める上で考えるべき事象の一部でしかない。そしてチーム開発は、
プロジェクト ＞ チーム開発 ＞ ツール
チーム開発をしていく上では、
- 市場の変化は早い
- 計画は容易に変わり得る
- 臨機応変に変化に対応しなければならない
これらの課題に対応するためには、
- 遅すぎる開発サイクルはNG
- 複数人が素早く並行して開発できること
- でもデグレードは起こしてはいけない
そして、
- 重要メールが多すぎて優先順位が決められない
- テスト環境で動かしてみるまで、
アプリが壊れていることに気づかない - 自信を持ってリファクタリングできない
- バグの発生時期、
修正時期がわからない、 追跡できない - 開発環境で動くものが本番環境では動かない
- リリースが複雑で属人的、
時間がかかる、 よく失敗する
本を執筆するにあたって気にしたこと
ここ3～5年Webを見て実践し続けている人なら新しいツールを活用できるだろうが、
また、
- 予算管理の話
- 工数管理、
見積もりの話 - チームのモチベートの話
- 採用の話
これらはもちろん大事ですが、
逆に
- ツールの紹介
- インストール方法、
コマンド解説 - 事例紹介
- チケット管理、
バージョン管理、 CI、 CD等々をバラバラに解説
池田氏は、
2012～2013年に起きた開発環境の変化
執筆の話を受けた2012年頃の池田氏の開発環境は次のようなものでした。
- SVN/
Backlog/ Bugzilla/ ReviewBoard/ Jenkins - Git/
Githubはまだ試している段階 - Chef/
Vagrantはまだまだ本格的ではなかった
この当時に執筆していたら今回のような本には仕上がらなかったと言います。なぜなら
自身のトラウマが克服するための自叙伝でもある
特に第2章
「
という言葉で締めくくっていました。
各章の紹介
次に、
- 第1章：チーム開発とは
最適なプラクティスはケースバイケース。これをやれば正解というのはなく、
状況に応じてベターなパターンの組み合わせが何通りもある。自分が関わるプロジェクトに最適なプラクティスを選択できるかが鍵。 - 第2章：チーム開発で起きる問題
チーム開発の現場で実際に起きがちな問題をケーススタディで紹介。池田氏の実体験を元に書かれている。ありがちな問題として次の事柄がある。
- 課題管理ができていない
- デグレードが頻発
- 環境ごとに動きが違う
それらの問題の解決策を3章以降で解説していく。
- 第3章：バージョン管理
バージョン管理はチーム開発をスムーズにするための基礎の基礎。この章ではデータベースマイグレーションに関しても解説している。また、
バージョン管理システムの歴史に触れている。バージョン管理システムはこの20年で進化してきた。変化が激しいものなので、 歴史を知ると色々と捗ることがあるはずだ。 20年前新人だった人は今は40代になり決裁権を持つようになっている。しかし、
彼らがその激しい変化をウォッチしているわけではないので、 その人たちには変化をウォッチして良いものを選択できるようにしてほしいと思っている。 - 第4章：チケット管理
チケット管理システムはOSS/商用のものがたくさんあり、
それらについて紹介している。チケット駆動開発についても簡単に解説。次のように、 チケット管理に向くフェーズ、 向かないフェーズもある。 - 定型的な課題監理に向いている
- 流動的な課題の監理には否定形ドキュメントを使うべき
課題の粒度と使うべきツールについても示唆している。
- 第5章：CI
（継続的インテグレーション） ここまでの章を実践すれば普通のチーム開発が回せるようになってくるはず。継続的改善に必要不可欠なのがCI。
（ここで、 CIを現場で導入しているかどうかの質問をしたところ、 会場の人は半分ぐらいの人がCIが現場に入っていると挙手していました。） CI導入がどうして必要不可欠なのかは次の2点が挙げられる。
- 市場の変化のスピード
- コストメリット
（CIを導入することで最終的なコストは削減される）
CIについてはJenkinsをベースに解説。市場の変化のスピードについていくためには、
たくさんの改修やリファクタリングする必要がある。それらをするためにはCIを回さなければ品質が保てない。Pull RequestをCIする方法 （GitHub Pull Request Builder Plugin） の解説やTravisCIにも触れている。 また、
CIの運用について説明をしており、 その一環でビルドが壊れた時のゲームについても写真付きで解説。例としてビルドを壊した人がシルクハットを被って業務に望むという罰ゲームの事例を紹介していた。ビルドを壊した人を言葉で攻め立てるわけではなく、 ゲーム感覚で罰ゲームを設けるぐらいが良さそうとのこと。 - 第6章：デプロイの自動化
（継続的デリバリー） 第6章は株式会社シャノン、
本稿執筆の藤倉が執筆。この章は様々なツールに関して紹介している。執筆中に情報のアップデートがあり、 特に2013年から執筆開始したメリットがあった。Bootstrapping, Configuration, Orchestrationの3フェーズに分けて解説し、 ツールの例としてKickstart, Vagrant, Chef, Capistrano, Fabric, Serverspecを活用したデプロイの自動化や、 クラウド時代のブルーグリーンデプロイメントについて取り上げた。またPaaSも使ったデプロイについても紹介している。 ただし2013年終わりから2014年前半に爆発的にヒットしたDockerを始めとするimmutable infrastructureについては触れるに留まったことが心残り。
- 第7章：リグレッションテスト
第7章は株式会社シャノンの井上氏が執筆し、
受け入れテストとそのリグレッションの自動化について解説。ここでいうテストはユニットテストとは異なる。意外とこの分野に関して情報はあまり公開されていない。デグレードを絶対に起こさず機能追加していくには必須の考え方。特にB2B向けのサービスでは重要。 （井上氏は上海から執筆していました。また当日は上海から帰国していました。） 共著の両名は池田氏の前職の同僚で、
B2B向けSaaSを開発・ 運用していました。ここではデグレードしないというのは非常に重要で、 そこではリグレッションテストの自動化が必須になっていた。この章ではシャノンで実践しているSelenium1を使ったリグレッションテストの自動化について説明している。 （ここでSeleniumを使ったテストを現場で使っている人について質問しましたが、 挙手はパラパラと挙がる程度でほとんどいませんでした。） 時間のかかるSeleniumテストの高速化についても解説。一般的に言ってプログラミングが不得意な人の多いQA担当者とともに、
いかに効率的に受け入れテスト自動化に取り組むかについても示唆している。内容としては2年ほど前にJenkinsユーザカンファレンスにて井上氏が発表した内容がベースになっている。
まとめとして、
本の中身から漏れたもの
なお、
- プロジェクトの見積もり、
計画 - 運用における振り返りと改善企画
- サービス企画、
製品企画と開発を両立するには - コードレビューのやり方、
ツール - コーディング規約
- エディタの使い方、
フォーマットのそろえ方など - 開発環境を良くするための予算のたて方稟議の通し方
- スモールスタートのやり方
- etc, etc, etc...
以上で池田氏の発表は終わりました。
チーム開発の課題について参加者全員でディスカッション
次に、
参考テーマとして次の項目を挙げています。
- ① 新人を率いてチーム開発をする際のポイント
- ② チームとして、
成果を出すためにどうやってチーム力を上げていくか、 優先してすることがあれば教えてほしい - ③ 例えば影響力がない人でもどうやれば、
良いチーム作りができるのか - ④ 例えばRedmineひとつにしても、
会社的に重要と思われている傾向の中、 上の人をどう説得すればいいのか - ⑤ オフショアチームや文化が異なるメンバーとのチームビルディング
- ⑥ チームで同一の方向を向いてやっていくために必要なこと
- ⑦ ツールに関して運用フローやHowToの社内ドキュメントを書く？
書かない？ - ⑧ どうやって導入していくのか。具体的な導入の苦労話を聞いてみたい
- ⑨ 企画・
エンジニア間のコミュニケーションを円滑に進めるためには
最初はパラパラとしか会話が聞こえてこない感じでスタートしましたが、
池田氏に質問
グループディスカッションを踏まえて、
Q：新しいツールをいれる際の教育コストについての質問です。一番詳しい人がやり方を教えるなどの方法があると思うがどういう方法が良いでしょうか。
A：あなたが、
Q：大きいプロジェクトをやっています。いろんな開発ツールが出ているが、
A：プロジェクトが大変な状態では、
Q：チームのメンバーを底上げするために必要なものは何でしょうか。チームメンバーのスキルはまちまちで、
A：地道な作業だがコードレビューをしっかりやる・
Q：本の中にコードレビューのことを書きたかったけど、
A：
個人的にコードレビューする時に気にしているのは、
終わりに
世界中でチームで開発をしていて、