dev love kansai

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

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

自己紹介

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

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

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

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

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

@ikeike443

大体こんなこと話します• 書籍の紹介

• チーム開発の課題って

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

• チーム開発をどう改善してきたか

• まとめ的な

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

第一章 チーム開発とは

チーム開発とは

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

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

チーム開発とは

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

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

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

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

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

• 課題管理ができない

• デグレが頻発

• 環境ごとに動きが違う

• etc etc

第三章 バージョン管理

バージョン管理

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

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

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

第四章 チケット管理

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

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

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

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

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

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

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

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

• 市場の変化のスピード

• コストメリット

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

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

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

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

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

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

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

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

デプロイの自動化

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

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

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

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

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

リグレッションテスト

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

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

リグレッションテスト

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

以上、本の紹介でした

大体こんなこと話します• 書籍の紹介

• チーム開発の課題って

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

• チーム開発をどう改善してきたか

• まとめ的な

チーム開発における課題

の話の前に

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

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

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

• 要件が定かでない

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

•おもてたんとちゃう

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

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

•利益は出るのか？

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

• プラン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

…という動機で書いたのが本書です。

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

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

開発現場の地図になれば

大体こんなこと話します• 書籍の紹介

• チーム開発の課題って

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

• チーム開発をどう改善してきたか

• まとめ的な

チーム開発をどう改善してきたか

• 素人ながら、チーム開発の改善にいくつか関わってきました

• そのうちのいくつかの事例についてお話します

※出てくる事例は過去のあるプロジェクトのその当時の例をデフォルメしたものです。

• 2005年～2009年ごろ

• 200名規模、20チーム以上で開発し、5年以上販売、運用している製品

• 池田はプロジェクト開始直後からジョイン

• メンバーは問題解決の意識は高いがエンジニアとしてのスキルにはばらつきがある

某プロジェクト1

• 課題管理がされておらず、何が起きているかが担当者以外にはわからなかった

• バージョン管理がきちんとされておらず、上書きによる変更の消失などが頻繁に起こる

• 単体テストは書かれておらず、そもそもリポジトリの最新コードはコンパイルできるかどうかも保証されていない

• 2週間の結合テスト期間に入っても最初の1週間はビルドにかかっていたため、品質も上がらなかった

課題

• 課題管理は独自システムがあったが機能しておらず、各チームが独自にExcelなどを駆使して管理しており、担当者に聞かないと状況がわからなかった

• PVCSというロックベースのVCSを使っており、マージができず並行開発が困難だった

• テストを書くという文化、発想がそもそもなかった

なぜこうなったか

• PVCSではどうにもならず、Subversionへの入れ替えを

• 課題管理にTracを導入

• TracとSubversionを連携することで変更の管理と追跡を行えるように

どう解決を試みたか

ところが、、、

壁が！

• TracやSubversionの導入、検証を行うためのリソースがない

• 人のリソース

• サーバリソース

改善の壁

• 稟議を通すのは困難

• 導入してみないと効果がわからないのでコストをかける妥当性を説明できない

• 今までのやり方で回ってるのになぜ？　に答えられない

改善の壁

「許可を求めな、謝罪せよ」 by グレース・ホッパー

• サーバリソース

• 総務と仲良くなり、余剰PCが出た瞬間に知らせてもらった

• 上司の協力も得て0円稟議を書き、PCをゲット

• 人のリソース

• 検証のための時間は取れないので自分と自分のチームの業務時間をそのまま当てる

• 要するに自分のチームを実験台に

壁を超えるために

• 自分のチームだけ違うVCSを使い、違う課題管理システムを使います、では全体の業務フローがおかしくなる

• 既存の業務フローと統合させてスムーズに回してみせることが重要

• 既存の課題管理システムとTracの同期スクリプトを書いた

• 既存のPVCSリポジトリとSVNを定期的に同期するスクリプトも書いた

既存の業務フローとの統合

可視化による自分事化

• 課題管理をし、バージョン管理をすることで問題が可視化

• 可視化されると、各メンバーが自分事として改善を考えるようになる

• そうするとさらに改善は進むと考えた

• チーム間の課題を共有できるようになり無駄が減る

• 誰が何をしているか、課題がどうなっているかわかるように

• テストは相変わらずなかったが、代わりにコードのDiffを手軽に見れるようになったので（事後ではあるが）コードレビューできるようになった

• マージが簡単になり、並行開発ができるようになった

• CIまでは行かなかったが、VCSを変えて課題管理をしただけでも、結合に係る時間は短縮できた

• 結果、目に見えて品質も開発スピードも上がった

結果を出し既成事実を

結果が出たッッッ！

• 結果が出たのを見て他のチームから問い合わせが来るように

• 全社的にプロセス改善を行っている部署から声がかかり、一緒に全社展開のプロジェクトにとりかかることになった

• 各チームの見通しが良くなり、各所で改善活動がされるようになった

結果が出ると話が早い

仲間が増え、広がっていった

• 「許可を求めるより謝罪」まずはやる

• 壁にへこたれない、言い訳をしない

• 既存の業務フローとの統合までやり切らないと説得力はない

• 結果を出して仲間を増やす

まとめると

• ある新サービスの開発プロジェクト

• 開発開始後2ヶ月が経過

• スクラムを採用

• 池田は途中からジョイン

• メンバーひとりひとりはスキルが高く大変優秀

某プロジェクト2

• タスク管理があいまい

• 業務過多で連日徹夜

• 終わらない、見通せない、リリースが危ぶまれる

• 企画サイドとエンジニアサイドの相互不信感MAX

• CIがなくよく壊れる

• 開発環境を整える工数はない

ジョイン当時

タスク管理があいまい

• バックログの管理はされていたが、

• 何が終わり、何が終わっていないのか、誰がボールを持っているか、があいまい

• スプレッドシートで管理されており、よく壊れる

タスク管理があいまい

• まずチケット管理システムに移行し、システムとしての信頼度を高めた

• タスクの完了定義をしっかりと行い、状況を確認しきちんと更新することで、内容的な信頼度を高めた

ジョイン当初のタスク管理スプリント計画 （企画が作成）

上記とは無関係にタスク管理 （開発が作成）

タスクボード （開発が作成）

企画がたてたスプリント計画をもとにストーリーをタスクに分解

相互の同期が取れず 次第に状況が不明瞭に !タスクボードに載っていない ことをエンジニアが別途管理

課題• 見積りが不正確で、毎スプリント計画通り終わらない

• エンジニアが計画とは関係ないことをやっている

• 企画「エンジニアは全然作業を完遂できない」

• エンジニア「企画は重要な作業が分かってない」

• スプレッドシートはよく壊れ、信頼出来ない状態に

なぜこうなったのか• スプリントの見積り、計画にエンジニアが入っていないため、

• 見積りの根拠があいまい

• システム的に重要なタスクが抜ける

• 複数人が思い思いにスプレッドシートをいじるため、

• 頻繁に壊れる

• 誰がどこをどう変更したかわからず、信頼出来ない状態に

• 全てをJIRAに一本化

• JIRAのGreenHopperプラグインを導入

• スプリント計画にエンジニアを入れるように

• 計画値と実績値を記録し、定期的に全体共有するように

どうしたか

JIRAに一本化企画とエンジニアがお互いに ストーリーを書き出し、 一緒にスプリント計画

タスクボードに付箋を貼る

合意したスプリント計画をもとにストーリーをタスクに分解

どうなったか• エンジニアが見積りに入ることで

• 見積もりがある程度正確に近くなった

• ツールを整備したことで、

• スプリント毎の計画値と実績値が可視化できるようになった

• 可視化できたことで、

• 各自が見積りと計画を自分事と捉え、改善策を考えるように

可視化による自分事化

• 企画とエンジニアとの間で情報共有を容易にした

• 可視化することによって、ここでも自分事化が起きる

• 見えてくるとみんなどうやって改善できるだろうかと考え始め、好循環が生まれる

CIが実施されていない

• ユニットテストは書かれていたが、CIは実施されていなかった

• 単体テストを実行してからPushすることになっていたが必ずしも。。

起きていたこと

• 毎週金曜の朝にスプリントレビューがある

• 直前になって開発環境にすべての変更を統合

• きちんと動作せず、レビューに間に合わせるために徹夜

なぜこうなったのか

• 機能要件を実装するのに忙しく、CI, CDなど実施するための余裕がない

• 開発生産性を高めるための作業が洗い出されておらず、計画もされていない

• エンジニアが見積り、計画をしていないことも大きい

• 自分がスクラムマスターとしてプロジェクトに入り、CI環境の整備を買って出た

• 企画には考慮することができないこういった案件も計画に入れ、見積りをするように働きかけた

どうしたか

どうなったか• レビュー前日の徹夜がなくなった

• いつでも動く成果物が存在する状態になり、企画とエンジニア間のコミュニケーション頻度が上がり活性化

• 品質管理部門もテストをしやすくなった

• 開発スピードが上がり、目に見えてチームの状況は良くなった

• 課題を一箇所にまとめ可視化

• 課題管理システムを信頼できる状態にし、情報共有を容易に

• エンジニアが見積もり、計画をするようにし、タスクの抜け漏れをなくした

• 生産性を担保するための必要なインフラ構築の工数を確保するようにした

• CIを実施し品質を担保、レビューをスムーズに

まとめると

大体こんなこと話します• 書籍の紹介

• チーム開発の課題って

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

• チーム開発をどう改善してきたか

• まとめ的な

チーム開発を改善するには

• まず可視化

• 現実を直視できる環境を作れば、おのずと改善サイクルは回り出す

• そのための必要なことはどんなことでもするのがスクラムマスター（またはプロジェクトマネージャー）の仕事

チーム開発を改善するには

小さなことからコツコツと

• いきなり「継続的デリバリー！」とか言わない

• いきなり「Githubのように一日千回リリース！」とか無理無理

• やれるところから、インパクトの大きいところからはじめるようにしています

一人ではできない• 当たり前ですが一人ではできません

• チーム開発です

• 開発もチームでやるなら、開発フローの改善もチームでやりましょう

• 「あいつらわかってない」とか「環境が整ってない」とか言わない

• 仲間を見つけよう

管理しない

• チーム開発を「管理する」発想だと管理者のレベルを超えたものは生まれない

• シナジーを重視する

• シナジーを生むためにはメンバー全員が自律的に考えて動く必要がある

情報を共有する

• 全てのメンバーができるかぎりフラットに全情報にアクセスできるように

• 持っている情報が多ければ多いほど個別に判断して改善ができるようになる

• シナジーが生まれる

• なぜ「管理」ではなく「シナジー」を重視するのか

「やれ」と言われたことをやるよりも、

自ら「やろう」と考えたことをやるほうが

パフォーマンスが高い

と信じているから

• みなが自ら「改善しよう」とかんがえるための土台を作るためには労力を惜しまない

• というのが大事

• でもさ、頑張って環境を整えても続かないんだよね、と思うことがありませんか？

• 僕はよくあります

チーム開発あるある

• チケット管理を始めたはいいけど誰も書かなくなる

• 始めのうちは単体テストを書いていたけど、仕様変更が重なるうちにメンテしなくなる

• CIを始めたはいいけどテストがよくこけるので誰もテスト結果を気にしなくなる

よくある回答

• 「すごく大事なのはわかってるけど、今は忙しいから」

• 「あとで困るのはわかってるけど、困ってからやればいいのでは。。」

これって何かに似てませんか

ダイエット

• ググった先でいいことが書いてありました

• ダイエットが続かない理由はダイエットを始めるから！

• 太っていない人は「ダイエットし続けている」わけではなく「太りにくい生活習慣をおくっている」

• チーム開発の改善もダイエットと同じなのでは！

• 「課題があるから解決しよう」ではなく、「課題がなくなるような習慣をつくろう」というアプローチが成功の鍵なのでは？

まとめると• 自ら率先してやってみせることが重要

• みんなが続けやすい環境づくりに労力を割くこともとても重要

• いきなり気張ってやり過ぎず、習慣付けを意識する

• できることをできる範囲でコツコツとやる

• 無理しない

以上、

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

幸いです

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