Agile japan2010 rakuten様プレゼン資料

Rakuten Development Department 楽天株式会社開発生産性強化グループ田澤久 2010年4月吉日 -1-

自己紹介：田澤久（たざわひさし）楽天入社： 2007年09月（業界歴：18年目）楽天株式会社＞開発部＞開発環境整備課＞開発生産性強化グループ開発環境プロデュースグループ IPA: ITアーキテクト委員会非ウォーターフォール型開発研究会 twitter: （へさし） -2-

はじめに・・・現在の、楽天株式会社：開発部の実態、課題、想い、将来に向けて始めた取り組みの紹介などを、本日のトークにぶつけてみたいと思っています。ゆえに、皆さんにとって有益な情報になるのか・・・分かりませんが、ご了承ください。 -3-

Introduction -4-

楽天のご紹介 -5-

開発部の規模感約30事業のサービス開発・運用内製による開発・運用社員数：約900名派遣数：約500名約200の開発プロジェクトが同時進行中 -6-

毎日がお祭り騒ぎ (^_^; -7-

ビジネス要求設計・開発調整プロジェクト化プロデューサ SYS-ENG 事業部・営業・企画デザイナー APP-ENG やり残しリリース軽微バグの改修リファクトリング改善など活動のメインはこっち機能改善、増強要請、提案などプロデューサ APP-ENG SYS-ENG システム要求 24時間365日運用 -8-

※マインドに関わる大事な補注出来上がったサービス（システム）は、誰のもの？【通常(?)】発注した（費用を出した）事業側・お客様のもの。【当社の場合】開発した開発部のものでもある。イメージとしては半々。（特に決まりは無い） -9-

Issues - 10 -

工数・期間　分布 7 6 期 5 間期間=√（工数）期間（月） 4 （月 3 の標準線） 2 1 0 0 5 10 15 20 25 30 35 40 45 50 工数（人月）工数（人月） - 11 -

工数・期間　分布 7 6 期 5 間期間（月） 4 （月 3 ） 2 1 規模の割にリリースが 0 0 5 10 15 遅いものが、約半数 20 25 30 35 40 45 50 工数（人月） - 12 -

What happened ? スピード開発を重視してきたつもりだったのに、そう言えない現状になってきている。 - 13 -

組織も多くなり、手続きが増えてきている仕様を考えるのは、開発主導なのに途中で生まれたアイデアが反映出来ない - 14 -

～現場の意見～ ●仕様がPRJ初期に決まれば世話ない ●一気に設計、一気にテスト・・・どわ～っとやるから、管理が面倒くさい ●テストが後なので、デグレが心配 ●スケジュールが間に合わなくて、機能がおちる。あとは運用でカバー - 15 -

要するに・・・そんな開発がしたい!! Step by step で開発が出来て開発リズムが安定していていつでもテストが出来て小さな追加開発が速やかに出来て運用の実態が、すぐに反映出来る - 16 -

苦しんでいる時に重なるもので・・・社長がつぶやく・・・ - 17 -

Challenges Speed!! Speed!! Speed!! - 18 -

アジャイル開発やってみようか !? - 19 -

アジャイル開発といっても、やり方は色々。以下をやってみよう、という事で進める。安心・安全な開発＝テスト駆動開発＋CI ※TDD 効率的な開発＝ CI 目で見る管理＝ Redmine テストに注目する開発方法を指向する。 - 20 -

その前に・・まずは「テスト」をちょっと整理 - 21 -

できれば自動化ビジネス面手動結合テストユーザビリティテストプ開 ABテストロ発ストーリーテストダ支クここに注目ト援ユニットテスト QAテスト評価自動化ツールテクノロジー面 * 実践アジャイルテストより - 22 -

テストをプログラム化したいなぜ、テストに注目するのか。なぜ、テストをプログラム化したいのか。理由＝私たちは作ってお終いでは無い運用は、ほぼ永遠に続く毎回テストで苦労するのは嫌 - 23 -

ユニットテストの仕組み = SVN + Hudson レポートも自動で作成される CIサーバログ出力自問題発生動問題なし問題なしゾー自動テストOK 自動テストOK 自動テストNG 機能機能ン追加修正間違った修正アラートメール送信手動コミット！問題検知！自動ソースコード管理サーバ - 24 -

 テストコードにより  常に動作するアプリケーションが保障される  CIサーバにより  機械的に繰り返し品質確認できる  ソース管理システムにより  これらがバージョニングされる - 25 -

実際にやってみると・・・開発コスト TDD後の運用を見てみると・・・開発コスト半年の開発で開発６：テスト４４０％の割合になった毎回の再テストコストが削減できる６０％ ■・・・開発コスト ■・・・テストコスト開発リリース / 運用時間動作確認レベルの単体テストの作成とテスト実施実施 ■・・・開発コスト ■・・・テストコスト - 26 -

結果 = Feeling good !! 品質面コストリスク面ケースアプリの運用後の引継ぎのしデグレードバグによるト事業へのリ初期開発時易さ（人の入防止ラブル防止スク防止品質のコスト開発コストれ換え）従来型開発 × even high ×××× テスト駆動型開発 ○ even low ○○○○ - 27 -

結合テストの仕組み＝ VirtualBox + Selenium 詳細は、時間の都合で割愛。。。なぜに、VirtualBox？システム日付、DBデータの操作性なぜに、Selenium FireFoxのプラグインで画面操作を記録すると自働で再現してくれる繰り返し作業を自働実行するため!! - 28 -

開発メンバーの実感大変だった。でも、やって良かった。いつでも全ての動作確認が出来るのは安心、しかも数分で。良いものを、良い方法で作っている実感がある。初期工数を多く使ったので、繰り返し使って借金を返すぞ！ - 29 -

なぜ早く取り組まなかったのか・・・やり方を替える事への不安。最初に仕様をきっちり決めれば、良い開発が出来ると思っていた。何よりサービスリリースを優先して来た。色々理由はあるけど、これから変わっていきます。安心して楽しく開発したい！ - 30 -

まだ始めたばかり。大きな課題がある。どう立ち向かうか？巨大な楽天市場 1,000人を超える開発人員加速する国際化 - 31 -

to be continued.. - 32 -

http://www.slideshare.net	51
http://paper.li	10

Agile japan2010 rakuten様プレゼン資料

by Agile Japan on Apr 15, 2010

Accessibility

Categories

Tags

Upload Details

Usage Rights

2 Embeds 61

Statistics

Agile japan2010 rakuten様プレゼン資料 — Presentation Transcript