CEDEC2015講演 チーム開発をスムーズにするために

Transcript of "CEDEC2015講演 チーム開発をスムーズにするために"

1. 1. チ ーム 開 発 を ス ムーズ に す る た め に C E D E C 2 0 1 5
2. 2. 自 己 紹 介
3. 3. a ikeike443
4. 4. a ikeike443
5. 5. • 現在: Sales Engineer @ GitHub • 過去: DevOps, スクラムマスター, 開発部長など
6. 6. • 『チーム開発実践入門』ほか、いくつか著作あり • Jenkins関連の書籍のレビューを複数（洋書） • PlayFrameworkほか、いくつかOSSに関わっていたこともあり
7. 7. 尚 、 本 日 の お 話 は 現 在 所 属 の 組 織 ・ 団 体 と は 一 切 関 係 あ り ま せ ん
8. 8. A G E N D A • 書籍の紹介 • なぜチーム開発が重要なのか • チーム開発をどう改善してきたか • まとめ
9. 9. と こ ろで 質 問 さ せ てく だ さ い
10. 10. • バージョン管理をしていないという人
11. 11. • チケット管理（課題管理）システムを使ってない人
12. 12. • CI（継続的インテグレーション）をしていない人
13. 13. • CD（継続的デリバリー、デプロイメント）をしていない人
14. 14. あ り が と う ご ざ い ま し た
15. 15. 『 チ ーム 開 発 実 践 入 門 』 紹 介
16. 16. チ ーム 開 発 実 践 入 門 • 技術評論社より2014年4月発売 • チームでソフトウェア開発を行う際によくハマる落とし穴の紹介とそれを 解決するためのノウハウを凝縮した入門書 • 新人PMむけの入門書として、修羅場をくぐったおじさんが涙する書籍とし て大人気！ • おかげさまで現在第4刷！
17. 17. 本 の 内 容 • 第1章 チーム開発とは • 第2章 チーム開発で起きる問題 • 第3章 バージョン管理 • 第4章 チケット管理 • 第5章 CI（継続的インテグレーション） • 第6章 デプロイの自動化（継続的デリバリー） • 第7章 リグレッションテスト
18. 18. 第 一 章 チ ーム 開 発 と は
19. 19. チ ーム 開 発 と は 最適なプラクティスはケースバイケース チーム開発の世界では、どこにでも通用する万能のベストプラクティスがあるというより、 状況に応じたベターなパターンの組み合わせが何通りもある、という考え方が正解に近いで しょう。実際自分が関わるプロジェクトに応じた最適解を見いだせるかどうかが、プロジェ クトを成功に導く といえるでしょう。
20. 20. チ ーム 開 発 と は 自分が関わるプロジェクトに応じた 最適解を見いだせるかが
21. 21. 第 二 章 チ ーム 開 発 で 起 き る 問 題
22. 22. チ ーム 開 発 で 起 き る 問 題 • チーム開発の現場で実際に起きがちな問題をケーススタディとして見せている章で す。 • 実際にわたしが体験したいくつかの現場での事例を組み合わせています • 課題管理ができない • デグレが頻発 • 環境ごとに動きが違う • etc etc
23. 23. 第 三 章 バー ジ ョ ン 管 理
24. 24. バー ジョ ン 管 理 • チーム開発をスムーズにするための基礎の基礎 • さすがに使ってない現場はないとは思うが • データベーススキーマのバージョン管理（データベースマイグレーション ですね）についても触れています
25. 25. 第 四 章 チ ケ ッ ト 管 理
26. 26. チ ケ ッ ト 管 理 • チケット管理に向くフェーズ、向かないフェーズもあります • チケット管理システムは定型的な課題管理に向く • 流動的な課題の管理には非定型ドキュメントを使うべき • 課題の粒度と使うべきツールについても示唆しています
27. 27. 第 五 章 C I （ 継 続 的 イ ン テ グ レ ー シ ョ ン ）
28. 28. C I （ 継 続 的 イ ン テ グ レ ー シ ョ ン ） • 継続的改善に必要不可欠なのがCIです • なぜ不可欠なのか、以下の2点で説明しています • 市場の変化のスピード • コストメリット
29. 29. C I （ 継 続 的 イ ン テ グ レ ー シ ョ ン ） • ビルドが壊れた時のゲームについてなど、CIの運用についても触れていま す。 • CI自体は目新しいものではなく、大昔から実践されてきたプラクティスで あることにも触れました。 • ここまでがチーム開発の基礎となる部分です。
30. 30. 第 六 章 デ プ ロ イ の 自 動 化 （ 継 続 的 デ リ バ リ ー ）
31. 31. デ プ ロ イ の 自 動 化 • デプロイの自動化について、必要性と方法を解説 • Bootstrapping, Configuration, Orchestrationの3フェーズに分けて解説 • Kickstart, Vagrant, Chef, Capistrano, Fabric, Serverspecといったツー ルについて
32. 32. 第 七 章 リ グ レ ッ シ ョ ン テス ト
33. 33. リ グ レ ッ シ ョ ン テス ト • 受入テストとそのリグレッションの自動化 • 意外と具体的な情報がないのがこの分野 • デグレを絶対に起こさず機能追加していくには必須 • 特にB2B向けのサービスでは重要
34. 34. リ グ レ ッ シ ョ ン テス ト • （一般的に言って）プログラミングが不得意な人の多いQA担当者ととも にいかに効率的に受入テスト自動化に取り組むかについても示唆 • 内容としては2年ほど前にJenkinsユーザーカンファレンスにて発表した内 容がベース
35. 35. ぜ ひ 読 んで み てく だ さ い ！ 職 場 の 同 僚 に もす すめ て ね ！
36. 36. な ぜ チ ーム 開 発 が 重 要 な の か
37. 37. プ ロ ジェ ク ト の 課 題
38. 38. • プロジェクトの目標が定まっていない • 誰が要件を決めるのか分からない • 価値を提供できているのか分からない • リスク管理ができていない • チームがパフォーマンスを出していない
39. 39. 言 い 換 える と
40. 40. • ゴールはどこ？ • 決めるのは誰？ • 利益は出るの？ • リスクは見えてるの？ • チーム開発はうまくいってるの？
41. 41. チ ーム 開 発 は 問 題 の 一 部
42. 42. • ゴールはどこ？ • 決めるのは誰？ • 利益は出るの？ • リスクは見えてるの？ • チーム開発はうまくいってるの？
43. 43. チ ーム 開 発 を は じ め る に あ た って 考 える べ き こ と
44. 44. • 方法論はどんなものを使うの？ • コミュニケーションプランはどうする？ • 成果はどう測る？ • チームビルディングはどうする？ • 開発ツールはどう使う？
45. 45. ツ ール の 使 い こ な し は さ ら に そ の 一 部
46. 46. • 方法論はどんなものを使うの？ • コミュニケーションプランはどうする？ • 成果はどう測る？ • チームビルディングはどうする？ • 開発ツールはどう使う？
47. 47. だ が 、 基 礎 で あ る
48. 48. プ ロ ジェ ク ト を 成 功 に 導 く た め の 大 事 な 基 礎
49. 49. • 市場の変化は早い • 計画は容易に変わり得る • 臨機応変に変化に対応しなければ
50. 50. • 遅すぎる開発サイクルはNG • 複数人が素早く並行して開発できないと • でもデグレードは起こしてはいけない
51. 51. で は
52. 52. ツ ール が 解 決 す る 問 題 って ？
53. 53. • 重要メールが多すぎて優先順位が決められない • テスト環境で動かしてみるまで、アプリが壊れていることに気づかない • 自信を持ってリファクタリングできない • バグの発生時期、修正時期がわからない、追跡できない • 開発環境で動くものが本番環境では動かない • リリースが複雑で属人的、時間がかかる、よく失敗する
54. 54. • こういった問題はツールをうまく使うことで解決できる • Webの記事なんかを見てると、色々ツールがあることがわかる
55. 55. • 組み合わせれば解決しそうだね！
56. 56. こ こ 3 ∼ 5 年 W E B を 見 て 実 践 し 続 け て い れ ば ね
57. 57. 新 人 さ ん だ っ た り 、 訳 あ って キ ャ ッ チ ア ッ プ して こ れ な か っ た 人 は ど う な る ん だ ろ う ？
58. 58. 例 え ば ググ って み る と
59. 59. イル開発Gitチケット管理Chefバージョ ビルド自動化JUnitSeleniumテストフ ワークCapsitrano Github Puppetテスト 発FabricデプロイInfrastructure as code pec リグレッションテストImmutable ucture Vagrant VCS アジャイル開発Gitチケット管理Chefバージ ン管理ビルド自動化JUnitSeleniumテストフ レームワークCapsitrano Github Puppetテ 駆動開発FabricデプロイInfrastructure as ケット管理Chefバージョ UnitSeleniumテストフ no Github Puppetテスト イInfrastructure as code アジャイル開発Gitチケット ン管理ビルド自動化JUnitSe レームワークCapsitrano Gi 駆動開発FabricデプロイInfr Serverspec リグレッション Infrastructure Vagrant Trav Infrastructure Vagrant VCS Infrastructure V
60. 60. • 情報が多い。。。 • 整理されてない。。。 • 何から手をつければ。。。
61. 61. そ こ で こ の 本 が や く に た つ ！ ！
62. 62. チ ーム 開 発 を ど う 改 善 して き た か
63. 63. • 素人ながら、チーム開発の改善にいくつか関わってきました • そのうちのいくつかの事例についてお話します ※出てくる事例は過去のあるプロジェクトのその当時の例をデフォルメしたものです。
64. 64. 某 プ ロ ジェ ク ト 1 • 2005年∼2009年ごろ • 200名規模、20チーム以上で開発し、5年以上販売、運用している製品 • 池田はプロジェクト開始直後からジョイン • メンバーは問題解決の意識は高いがエンジニアとしてのスキルにはばらつ きがある
65. 65. 課 題 • 課題管理がされておらず、何が起きているかが担当者以外にはわからなかった • バージョン管理がきちんとされておらず、上書きによる変更の消失などが頻繁に起こる • 単体テストは書かれておらず、そもそもリポジトリの最新コードはコンパイルできるかどうか も保証されていない • 2週間の結合テスト期間に入っても最初の1週間はビルドにかかっていたため、品質も上がら なかった
66. 66. な ぜ こう な っ た か • 課題管理は独自システムがあったが機能しておらず、各チームが独自にExcelなどを駆使して 管理しており、担当者に聞かないと状況がわからなかった • PVCSというロックベースのVCSを使っており、マージができず並行開発が困難だった • テストを書くという文化、発想がそもそもなかった
67. 67. ど う 解 決 を 試 み た か • PVCSではどうにもならず、Subversionへの入れ替えを • 課題管理にTracを導入 • TracとSubversionを連携することで変更の管理と追跡を行えるように
68. 68. と こ ろ が 、 、 、
69. 69. 壁 が ！
70. 70. 改 善 の 壁 • TracやSubversionの導入、検証を行うためのリソースがない • 人のリソース • サーバリソース
71. 71. 改 善 の 壁 • 稟議を通すのは困難 • 導入してみないと効果がわからないのでコストをかける妥当性を説明できない • 今までのやり方で回ってるのになぜ？ に答えられない
72. 72. 「 許 可 を 求 め な 、 謝 罪 せ よ 」 B Y グ レ ース ・ ホ ッ パ ー
73. 73. 壁 を 超 える た め に • サーバリソース • 総務と仲良くなり、余剰PCが出た瞬間に知らせてもらった • 上司の協力も得て0円稟議を書き、PCをゲット • 人のリソース • 検証のための時間は取れないので自分と自分のチームの業務時間をそのまま当てる • 要するに自分のチームを実験台に
74. 74. 既 存 の 業 務 フ ロ ー と の 統 合 • 自分のチームだけ違うVCSを使い、違う課題管理システムを使います、では全体の業務フ ローがおかしくなる • 既存の業務フローと統合させてスムーズに回してみせることが重要 • 既存の課題管理システムとTracの同期スクリプトを書いた • 既存のPVCSリポジトリとSVNを定期的に同期するスクリプトも書いた
75. 75. 可 視 化 に よる 自 分 事 化 • 課題管理をし、バージョン管理をすることで問題が可視化 • 可視化されると、各メンバーが自分事として改善を考えるようになる • そうするとさらに改善は進むと考えた
76. 76. 結 果 を 出 し 既 成 事 実 を • チーム間の課題を共有できるようになり無駄が減る • 誰が何をしているか、課題がどうなっているかわかるように • テストは相変わらずなかったが、代わりにコードのDiffを手軽に見れるようになったので（事後 ではあるが）コードレビューできるようになった • マージが簡単になり、並行開発ができるようになった • CIまでは行かなかったが、VCSを変えて課題管理をしただけでも、結合に係る時間は短縮できた • 結果、目に見えて品質も開発スピードも上がった
77. 77. 結 果 が 出 た ッ ッ ッ ！
78. 78. 結 果 が 出 る と 話 が 早 い • 結果が出たのを見て他のチームから問い合わせが来るように • 全社的にプロセス改善を行っている部署から声がかかり、一緒に全社展開のプロジェクトに とりかかることになった • 各チームの見通しが良くなり、各所で改善活動がされるようになった
79. 79. 仲 間 が 増 え 、 広 が って い っ た
80. 80. ま と め る と • 「許可を求めるより謝罪」まずはやる • 壁にへこたれない、言い訳をしない • 既存の業務フローとの統合までやり切らないと説得力はない • 結果を出して仲間を増やす
81. 81. 某 プ ロ ジェ ク ト 2 • ある新サービスの開発プロジェクト • 開発開始後2ヶ月が経過 • スクラムを採用 • 池田は途中からジョイン • メンバーひとりひとりはスキルが高く大変優秀
82. 82. ジョ イ ン 当 時 • タスク管理があいまい • 業務過多で連日徹夜 • 終わらない、見通せない、リリースが危ぶまれる • 企画サイドとエンジニアサイドの相互不信感MAX • CIがなくよく壊れる • 開発環境を整える工数はない
83. 83. タ ス ク 管 理 が あ い ま い • バックログの管理はされていたが、 • 何が終わり、何が終わっていないのか、誰がボールを持っているか、が あいまい • スプレッドシートで管理されており、よく壊れる
84. 84. タ ス ク 管 理 が あ い ま い • まずチケット管理システムに移行し、システムとしての信頼度を高めた • タスクの完了定義をしっかりと行い、状況を確認しきちんと更新すること で、内容的な信頼度を高めた
85. 85. ジョ イ ン 当 初 の タ ス ク 管 理 スプリント計画 （企画が作成） 上記とは無関係にタスク管理 （開発が作成） タスクボード （開発が作成） 企画がたてたスプリント計画をも とにストーリーをタスクに分解 相互の同期が取れず 次第に状況が不明瞭に タスクボードに載っていない ことをエンジニアが別途管理
86. 86. 課 題 • 見積りが不正確で、毎スプリント計画通り終わらない • エンジニアが計画とは関係ないことをやっている • 企画「エンジニアは全然作業を完遂できない」 • エンジニア「企画は重要な作業が分かってない」 • スプレッドシートはよく壊れ、信頼出来ない状態に
87. 87. な ぜ こう な っ た の か • スプリントの見積り、計画にエンジニアが入っていないため、 • 見積りの根拠があいまい • システム的に重要なタスクが抜ける • 複数人が思い思いにスプレッドシートをいじるため、 • 頻繁に壊れる • 誰がどこをどう変更したかわからず、信頼出来ない状態に
88. 88. ど う し た か • 全てをJIRAに一本化 • JIRAのGreenHopperプラグインを導入 • スプリント計画にエンジニアを入れるように • 計画値と実績値を記録し、定期的に全体共有するように
89. 89. J I R A に 一 本 化 企画とエンジニアがお互いに ストーリーを書き出し、 一緒にスプリント計画 タスクボードに付箋を貼る 合意したスプリント計画をもとにス トーリーをタスクに分解
90. 90. ど う な っ た か • エンジニアが見積りに入ることで • 見積もりがある程度正確に近くなった • ツールを整備したことで、 • スプリント毎の計画値と実績値が可視化できるようになった • 可視化できたことで、 • 各自が見積りと計画を自分事と捉え、改善策を考えるように
91. 91. 可 視 化 に よる 自 分 事 化 • 企画とエンジニアとの間で情報共有を容易にした • 可視化することによって、ここでも自分事化が起きる • 見えてくるとみんなどうやって改善できるだろうかと考え始め、好循環が 生まれる
92. 92. C I が 実 施 さ れて い な い • ユニットテストは書かれていたが、CIは実施されていなかった • 単体テストを実行してからPushすることになっていたが必ずしも。。
93. 93. 起 き て い た こ と • 毎週金曜の朝にスプリントレビューがある • 直前になって開発環境にすべての変更を統合 • きちんと動作せず、レビューに間に合わせるために徹夜
94. 94. な ぜ こう な っ た の か • 機能要件を実装するのに忙しく、CI, CDなど実施するための余裕がない • 開発生産性を高めるための作業が洗い出されておらず、計画もされていない • エンジニアが見積り、計画をしていないことも大きい
95. 95. ど う し た か • 自分がスクラムマスターとしてプロジェクトに入り、CI環境の整備を買って出た • 企画には考慮することができないこういった案件も計画に入れ、見積りをするように働きか けた
96. 96. ど う な っ た か • レビュー前日の徹夜がなくなった • いつでも動く成果物が存在する状態になり、企画とエンジニア間のコミュ ニケーション頻度が上がり活性化 • 品質管理部門もテストをしやすくなった • 開発スピードが上がり、目に見えてチームの状況は良くなった
97. 97. ま と め る と • 課題を一箇所にまとめ可視化 • 課題管理システムを信頼できる状態にし、情報共有を容易に • エンジニアが見積もり、計画をするようにし、タスクの抜け漏れをなくした • 生産性を担保するための必要なインフラ構築の工数を確保するようにした • CIを実施し品質を担保、レビューをスムーズに
98. 98. ま と め ： チ ーム 開 発 を 改 善 す る に は
99. 99. チ ーム 開 発 を 改 善 す る に は • まず可視化 • 現実を直視できる環境を作れば、おのずと改善サイクルは回り出す • そのための必要なことはどんなことでもするのがスクラムマスター（またはプロジェ クトマネージャー）の仕事
100. 100. 小 さ な こ と か ら コ ツ コ ツ と • いきなり「継続的デリバリー！」とか言わない • いきなり「Githubのように一日千回リリース！」とか無理無理 • やれるところから、インパクトの大きいところからはじめるようにしてい ます
101. 101. 一 人 で は で き な い • 当たり前ですが一人ではできません • チーム開発です • 開発もチームでやるなら、開発フローの改善もチームでやりましょう • 「あいつらわかってない」とか「環境が整ってない」とか言わない • 仲間を見つけよう
102. 102. 管 理 し な い • チーム開発を「管理する」発想だと管理者のレベルを超えたものは生まれ ない • シナジーを重視する • シナジーを生むためにはメンバー全員が自律的に考えて動く必要がある
103. 103. 情 報 を 共 有 す る • 全てのメンバーができるかぎりフラットに全情報にアクセスできるように • 持っている情報が多ければ多いほど個別に判断して改善ができるようにな る • シナジーが生まれる
104. 104. • なぜ「管理」ではなく「シナジー」を重視するのか
105. 105. 「やれ」と言われたことをやるよりも、 自ら「やろう」と考えたことをやるほうが パフォーマンスが高い と信じているから
106. 106. • みなが自ら「改善しよう」とかんがえるための土台を作るためには労力を 惜しまない • というのが大事
107. 107. • でもさ、頑張って環境を整えても続かないんだよね、と思うことがありま せんか？
108. 108. • 僕はよくあります
109. 109. チ ーム 開 発 あ る あ る • チケット管理を始めたはいいけど誰も書かなくなる • 始めのうちは単体テストを書いていたけど、仕様変更が重なるうちにメン テしなくなる • CIを始めたはいいけどテストがよくこけるので誰もテスト結果を気にしな くなる
110. 110. よ く あ る 回 答
111. 111. • 「すごく大事なのはわかってるけど、今は忙しいから」 • 「あとで困るのはわかってるけど、困ってからやればいいのでは。。」
112. 112. こ れ って 何 か に 似 て ま せ ん か
113. 113. ダイ エ ッ ト
114. 114. • ググった先でいいことが書いてありました • ダイエットが続かない理由はダイエットを始めるから！ • 太っていない人は「ダイエットし続けている」わけではなく「太りにくい生活習 慣をおくっている」
115. 115. • チーム開発の改善もダイエットと同じなのでは！ • 「課題があるから解決しよう」ではなく、「課題がなくなるような習慣を つくろう」というアプローチが成功の なのでは？
116. 116. ま と め る と • 自ら率先してやってみせることが重要 • みんなが続けやすい環境づくりに労力を割くこともとても重要 • いきなり気張ってやり過ぎず、習慣付けを意識する • できることをできる範囲でコツコツとやる • 無理しない
117. 117. 以 上 、
118. 118. • 開発現場を改善する人たちの地図になれば
119. 119. ご 清 聴 あ り が と う ご ざ い ま し た