- 1 -

Rakuten

Development Department

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

- 2 -

自己紹介： 田澤 久（たざわ ひさし）

楽天入社： 2007年09月 （業界歴：18年目）

楽天株式会社＞開発部＞開発環境整備課＞

開発生産性強化グループ

開発環境プロデュースグループ

IPA: ITアーキテクト委員会

非ウォーターフォール型開発研究会

twitter: （へさし）

- 3 -

はじめに・・・

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

ゆえに、皆さんにとって有益な情報になるのか・・・

分かりませんが、ご了承ください。

- 4 -

Introduction

- 5 -

楽天のご紹介

- 6 -

開発部の規模感

約30事業のサービス開発・運用

内製による開発・運用

社員数：約900名

派遣数：約500名

約200の開発プロジェクトが同時進行中

- 7 -

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

- 8 -

ビジネス要求

事業部・営業・企画

活動のメインは

こっち

APP-ENG SYS-ENG

24時間365日運用

システム要求

機能改善、増強要請、提案など

プロデューサ

プロデューサ

調整

デザイナー

設計・開発

APP-ENG SYS-ENG

プロジェクト化

リリースやり残し

軽微バグの改修

リファクトリング

改善など

- 9 -

※マインドに関わる大事な補注

出来上がったサービス（システム）は、誰のもの？

【通常(?)】

発注した（費用を出した）事業側・お客様のもの。

【当社の場合】

開発した開発部のものでもある。

イメージとしては半々。（特に決まりは無い）

- 10 -

Issues

- 11 -

工数・期間　分布

0

1

2

3

4

5

6

7

0 5 10 15 20 25 30 35 40 45 50

工数（人月）

期間（月）

工数（人月）

期間（月）

期間=√（工数）

の標準線

- 12 -

工数・期間　分布

0

1

2

3

4

5

6

7

0 5 10 15 20 25 30 35 40 45 50

工数（人月）

期間（月）

期間（月）

規模の割にリリースが遅いものが、約半数

- 13 -

What happened ?

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

- 14 -

組織も多くなり、手続きが増えてきている

仕様を考えるのは、開発主導なのに

途中で生まれたアイデアが反映出来ない

- 15 -

～現場の意見～

●仕様がPRJ初期に決まれば世話ない

●一気に設計、一気にテスト・・・どわ～っとやるから、管理が面倒くさい

●テストが後なので、デグレが心配

●スケジュールが間に合わなくて、機能が

おちる。あとは運用でカバー

- 16 -

要するに・・・

Step by step で開発が出来て

開発リズムが安定していて

いつでもテストが出来て

小さな追加開発が速やかに出来て

運用の実態が、すぐに反映出来る

そんな開発がしたい!!

- 17 -

苦しんでいる時に重なるもので・・・

社長がつぶやく・・・

- 18 -

Challenges

Speed!! Speed!! Speed!!

- 19 -

アジャイル開発

やってみようか !?

- 20 -

アジャイル開発といっても、やり方は色々。

以下をやってみよう、という事で進める。

安心・安全な開発 ＝ テスト駆動開発＋CI

効率的な開発 ＝ CI

目で見る管理 ＝ Redmine

テスト に注目する開発方法を指向する。

※TDD

- 21 -

まずは「テスト」をちょっと整理

その前に・・

- 22 -

* 実践アジャイルテストより

できれば自動化

自動化 ツール

手動

開発支援

プロダクト評価

ビジネス面

テクノロジー面

ユニットテスト

ユーザビリティテスト

ABテスト

QAテスト

結合テスト

ストーリーテスト

ここに注目

- 23 -

テストをプログラム化したい

なぜ、テストに注目するのか。

なぜ、テストをプログラム化したいのか。

理由 ＝ 私たちは作ってお終いでは無い

運用は、ほぼ永遠に続く

毎回テストで苦労するのは嫌

- 24 -

CIサーバ

機能

追加

自動テストOK

機能

修正

自動テストOK 自動テストNG

間違った修正

問題なし 問題なし問題発生

ログ出力

アラートメール送信

ソースコード管理サーバ

！問題検知！手動

自動

コミット

自動ゾーン

レポートも自動で

作成される

ユニットテストの仕組み = SVN + Hudson

- 25 -

CIサーバにより

機械的に繰り返し品質確認できる

テストコードにより

常に動作するアプリケーションが保障される

ソース管理システムにより

これらがバージョニングされる

- 26 -

開発コスト

動作確認レベルのテスト実施

単体テストの作成と実施

６０％

４０％

■・・・開発コスト

■・・・テストコスト

開発コスト

時間リリース / 運用

■・・・開発コスト

■・・・テストコスト

TDD後の運用を見てみると・・・

開発

半年の開発で開発６：テスト４の割合になった

毎回の再テストコストが削減できる

実際にやってみると・・・

- 27 -

ケース

品質面 コスト リスク面

アプリの

品質

初期開発時のコスト

運用後の

開発コスト

引継ぎのし易さ（人の入れ換え）

デグレード防止

バグによるトラブル防止

事業へのリスク防止

従来型開発 × even high ××××テスト駆動型開発○ even low ○○○○

結果 = Feeling good !!

- 28 -

結合テストの仕組み＝ VirtualBox + Selenium

詳細は、時間の都合で割愛。。。

なぜに、VirtualBox？

システム日付、DBデータの操作性

なぜに、Selenium

FireFoxのプラグインで画面操作を記録すると自働で再現してくれる

繰り返し作業を自働実行するため!!

- 29 -

開発メンバーの実感

大変だった。でも、やって良かった。

いつでも全ての動作確認が出来るのは安心、しかも数分で。

良いものを、良い方法で作っている実感がある。

初期工数を多く使ったので、繰り返し使って借金を返すぞ！

- 30 -

なぜ早く取り組まなかったのか・・・

やり方を替える事への不安。

最初に仕様をきっちり決めれば、良い開発が出来ると思っていた。

何よりサービスリリースを優先して来た。

色々理由はあるけど、これから変わっていきます。安心して楽しく開発したい！

- 31 -

まだ始めたばかり。

大きな課題がある。どう立ち向かうか？

巨大な楽天市場

1,000人を超える開発人員

加速する国際化

- 32 -

to be continued..