Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Rakuten
Development Department

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

                        -1-
自己紹介: 田澤 久(たざわ ひさし)

 楽天入社: 2007年09月 (業界歴:18年目)
 楽天株式会社>開発部>開発環境整備課>
    開発生産性強化グループ
    開発環境プロデュースグループ
    IPA: ITアーキテクト委...
はじめに・・・

 現在の、楽天株式会社:開発部の実態、課題、想い、
 将来に向けて始めた取り組みの紹介などを、本日
 のトークにぶつけてみたいと思っています。

 ゆえに、皆さんにとって有益な情報になるのか・・・
 分かりませんが、ご了承くだ...
Introduction


               -4-
楽天のご紹介




         -5-
開発部の規模感

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


               -6-
毎日がお祭り騒ぎ (^_^;
        -7-
ビジネス要求                                      設計・開発

            調整               プロジェクト化


                    プロデューサ      ...
※マインドに関わる大事な補注
出来上がったサービス(システム)は、誰のもの?

【通常(?)】
 発注した(費用を出した)事業側・お客様のもの。
【当社の場合】
 開発した開発部のものでもある。
 イメージとしては半々。(特に決まりは無い)

...
Issues


         - 10 -
工数・期間 分布

        7


        6



期       5


間                                                 期間=√(工数)
期間(月)




      ...
工数・期間 分布

        7


        6



期       5


間
期間(月)




        4


(
月       3



)       2


        1               ...
What happened ?

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




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

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

     ...
要するに・・・       そんな開発
               がしたい!!
  Step by step で開発が出来て
  開発リズムが安定していて
  いつでもテストが出来て
  小さな追加開発が速やかに出来て
  運用の実態が、す...
苦しんでいる時に重なるもので・・・
社長がつぶやく・・・




               - 17 -
Challenges


             Speed!! Speed!! Speed!!


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


        - 19 -
アジャイル開発といっても、やり方は色々。
以下をやってみよう、という事で進める。
安心・安全な開発 = テスト駆動開発+CI
                        ※TDD

効率的な開発   = CI
目で見る管理   = Redm...
その前に・・




   まずは「テスト」をちょっと整理
              - 21 -
できれば自動化
              ビジネス面               手動



          結合テスト
                  ユーザビリティテスト
                             ...
テストをプログラム化したい
 なぜ、テストに注目するのか。
 なぜ、テストをプログラム化したいのか。

理由 = 私たちは作ってお終いでは無い
     運用は、ほぼ永遠に続く
     毎回テストで苦労するのは嫌

             ...
ユニットテストの仕組み = SVN + Hudson
                 レポートも自動で
                  作成される          CIサーバ
                              ...
 テストコードにより
   常に動作するアプリケーションが保
    障される

 CIサーバにより
   機械的に繰り返し品質確認できる

 ソース管理システムにより
   これらがバージョニングされる
             ...
実際にやってみると・・・
開発コスト                               TDD後の運用を見てみると・・・
                                    開発コスト

             ...
結果 = Feeling good !!
        品質面             コスト                      リスク面

  ケース   アプリの           運用後の    引継ぎのし    デグレード ...
結合テストの仕組み= VirtualBox + Selenium

  詳細は、時間の都合で割愛。。。
  なぜに、VirtualBox?
    システム日付、DBデータの操作性
  なぜに、Selenium
    FireFoxのプラグイ...
開発メンバーの実感

 大変だった。でも、やって良かった。
 いつでも全ての動作確認が出来るの
 は安心、しかも数分で。
 良いものを、良い方法で作っている実
 感がある。
 初期工数を多く使ったので、繰り返し
 使って借金を返すぞ!
    ...
なぜ早く取り組まなかったのか・・・

 やり方を替える事への不安。
 最初に仕様をきっちり決めれば、良い
 開発が出来ると思っていた。
 何よりサービスリリースを優先して来た。

色々理由はあるけど、これから変わっていき
ます。安心して楽しく開...
まだ始めたばかり。
大きな課題がある。どう立ち向かうか?


 巨大な楽天市場
 1,000人を超える開発人員
 加速する国際化
              - 31 -
to be continued..

              - 32 -
Upcoming SlideShare
Loading in …5
×

Agile japan2010 rakuten様プレゼン資料

3,405 views

Published on

Published in: Business
  • Be the first to comment

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 -

×