Agile japan2010 rakuten様プレゼン資料

3,245 views

Published on

Published in: Business
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
3,245
On SlideShare
0
From Embeds
0
Number of Embeds
84
Actions
Shares
0
Downloads
81
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide

Agile japan2010 rakuten様プレゼン資料

  1. 1. Rakuten Development Department 楽天株式会社 開発生産性強化グループ 田澤久 2010年4月吉日 -1-
  2. 2. 自己紹介: 田澤 久(たざわ ひさし) 楽天入社: 2007年09月 (業界歴:18年目) 楽天株式会社>開発部>開発環境整備課> 開発生産性強化グループ 開発環境プロデュースグループ IPA: ITアーキテクト委員会 非ウォーターフォール型開発研究会 twitter: (へさし) -2-
  3. 3. はじめに・・・ 現在の、楽天株式会社:開発部の実態、課題、想い、 将来に向けて始めた取り組みの紹介などを、本日 のトークにぶつけてみたいと思っています。 ゆえに、皆さんにとって有益な情報になるのか・・・ 分かりませんが、ご了承ください。 -3-
  4. 4. Introduction -4-
  5. 5. 楽天のご紹介 -5-
  6. 6. 開発部の規模感 約30事業のサービス開発・運用 内製による開発・運用 社員数:約900名 派遣数:約500名 約200の開発プロジェクトが同時進行中 -6-
  7. 7. 毎日がお祭り騒ぎ (^_^; -7-
  8. 8. ビジネス要求 設計・開発 調整 プロジェクト化 プロデューサ SYS-ENG 事業部・営業・企画 デザイナー APP-ENG やり残し リリース 軽微バグの改修 リファクトリング 改善など 活動のメインは こっち 機能改善、増強要請、提案など プロデューサ APP-ENG SYS-ENG システム要求 24時間365日運用 -8-
  9. 9. ※マインドに関わる大事な補注 出来上がったサービス(システム)は、誰のもの? 【通常(?)】 発注した(費用を出した)事業側・お客様のもの。 【当社の場合】 開発した開発部のものでもある。 イメージとしては半々。(特に決まりは無い) -9-
  10. 10. Issues - 10 -
  11. 11. 工数・期間 分布 7 6 期 5 間 期間=√(工数) 期間(月) 4 ( 月 3 の標準線 ) 2 1 0 0 5 10 15 20 25 30 35 40 45 50 工数(人月) 工数(人月) - 11 -
  12. 12. 工数・期間 分布 7 6 期 5 間 期間(月) 4 ( 月 3 ) 2 1 規模の割にリリースが 0 0 5 10 15 遅いものが、約半数 20 25 30 35 40 45 50 工数(人月) - 12 -
  13. 13. What happened ? スピード開発を重視してきたつもり だったのに、そう言えない現状に なってきている。 - 13 -
  14. 14. 組織も多くなり、手続きが増えてきている 仕様を考えるのは、開発主導なのに 途中で生まれたアイデアが反映出来ない - 14 -
  15. 15. ~現場の意見~ ●仕様がPRJ初期に決まれば世話ない ●一気に設計、一気にテスト・・・どわ~っ とやるから、管理が面倒くさい ●テストが後なので、デグレが心配 ●スケジュールが間に合わなくて、機能が おちる。あとは運用でカバー - 15 -
  16. 16. 要するに・・・ そんな開発 がしたい!! Step by step で開発が出来て 開発リズムが安定していて いつでもテストが出来て 小さな追加開発が速やかに出来て 運用の実態が、すぐに反映出来る - 16 -
  17. 17. 苦しんでいる時に重なるもので・・・ 社長がつぶやく・・・ - 17 -
  18. 18. Challenges Speed!! Speed!! Speed!! - 18 -
  19. 19. アジャイル開発 やってみようか !? - 19 -
  20. 20. アジャイル開発といっても、やり方は色々。 以下をやってみよう、という事で進める。 安心・安全な開発 = テスト駆動開発+CI ※TDD 効率的な開発 = CI 目で見る管理 = Redmine テスト に注目する開発方法を指向する。 - 20 -
  21. 21. その前に・・ まずは「テスト」をちょっと整理 - 21 -
  22. 22. できれば自動化 ビジネス面 手動 結合テスト ユーザビリティテスト プ 開 ABテスト ロ 発 ストーリーテスト ダ 支 ク ここに注目 ト 援 ユニットテスト QAテスト 評 価 自動化 ツール テクノロジー面 * 実践アジャイルテストより - 22 -
  23. 23. テストをプログラム化したい なぜ、テストに注目するのか。 なぜ、テストをプログラム化したいのか。 理由 = 私たちは作ってお終いでは無い 運用は、ほぼ永遠に続く 毎回テストで苦労するのは嫌 - 23 -
  24. 24. ユニットテストの仕組み = SVN + Hudson レポートも自動で 作成される CIサーバ ログ出力 自 問題発生 動 問題なし 問題なし ゾ ー 自動テストOK 自動テストOK 自動テストNG 機能 機能 ン 追加 修正 間違った 修正 アラートメール送信 手動 コミット !問題検知! 自動 ソースコード管理サーバ - 24 -
  25. 25.  テストコードにより  常に動作するアプリケーションが保 障される  CIサーバにより  機械的に繰り返し品質確認できる  ソース管理システムにより  これらがバージョニングされる - 25 -
  26. 26. 実際にやってみると・・・ 開発コスト TDD後の運用を見てみると・・・ 開発コスト 半年の開発で 開発6:テスト4 40% の割合になった 毎回の再テスト コストが削減で きる 60% ■・・・開発コスト ■・・・テストコスト 開発 リリース / 運用 時間 動作確認レベルの 単体テストの作成と テスト実施 実施 ■・・・開発コスト ■・・・テストコスト - 26 -
  27. 27. 結果 = Feeling good !! 品質面 コスト リスク面 ケース アプリの 運用後の 引継ぎのし デグレード バグによるト 事業へのリ 初期開発時 易さ(人の入 防止 ラブル防止 スク防止 品質 のコスト 開発コスト れ換え) 従来型開 発 × even high ×××× テスト駆 動型開発 ○ even low ○○○○ - 27 -
  28. 28. 結合テストの仕組み= VirtualBox + Selenium 詳細は、時間の都合で割愛。。。 なぜに、VirtualBox? システム日付、DBデータの操作性 なぜに、Selenium FireFoxのプラグインで画面操作を 記録すると自働で再現してくれる 繰り返し作業を自働実行するため!! - 28 -
  29. 29. 開発メンバーの実感 大変だった。でも、やって良かった。 いつでも全ての動作確認が出来るの は安心、しかも数分で。 良いものを、良い方法で作っている実 感がある。 初期工数を多く使ったので、繰り返し 使って借金を返すぞ! - 29 -
  30. 30. なぜ早く取り組まなかったのか・・・ やり方を替える事への不安。 最初に仕様をきっちり決めれば、良い 開発が出来ると思っていた。 何よりサービスリリースを優先して来た。 色々理由はあるけど、これから変わっていき ます。安心して楽しく開発したい! - 30 -
  31. 31. まだ始めたばかり。 大きな課題がある。どう立ち向かうか? 巨大な楽天市場 1,000人を超える開発人員 加速する国際化 - 31 -
  32. 32. to be continued.. - 32 -

×