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