自己紹介
- 残田晋
- 富士山の頂上でトラブルシューティングした経験あり
楽天トラベルについて
- 国内外の旅行を扱っている
開発体制・案件について
- トラベル事業は楽天の中でもトップの方を位置する規模
- セールス、マーケティング、開発が同じフロアで行っている。
- 開発はさらに3つに分かれている
- PDM
- 未来を考える人
- 30人程度
- 開発
- 100人程度
- QA
- 30人程度
- PDM
基本的には全て内製
2016年の新規の開発案件が209件。
- BugFixなどのPDM以外の案件はQAが関与していない
案件の内容比率
- 2016年の各サービスごとの改善割合。
- 国内宿泊サービスのBugFixが8割強
- 改修のプライオリティを5段階に分けている。毎回のプロジェクトで行っている。
QAのプロセス改善について
以前のフロー
- ウォーターフローに近いかたち
- PDMの人はアイデア、議論、起票、レビュー、要件定義
- 開発の人は要件定義レビュー、開発設計、テスト設計、開発・テスト、リリース
以前の問題
- 旧システムvs新システム
- 開発スピードについていけない
- ケースが漏れる
- プロセスの改善を行った。
現在のフロー
- 現在は、要件定義、開発設計、テスト設計(シナリオの概要を書かせる)、ケース設計、手動テスト、本番確認
今後の展望
- 今後は開発と同じ速度でテスト設計を始められるようにする。
- 要件定義の段階からQAが入るようにする。テスタビリティの観点からレビューに参加する。
開発の設計が始まった段階でテスト設計も行うようにする。
- 開発の設計では漏れている観点をデベロッパーにフィードバックできるようになった。
- 開発とQAの意思疎通がうまくいくようになった。
今後は、テストケースをもっとプラグラマチックなケースで書かせて、すぐに自動化できるように行う。
QAの責任範囲は広がっていった。
まとめ
- QAはリリース後の全てのバグに権限を持っている
- QAの実施可否
- 作ったツールのパス率、ITの結果、UTの結果から判断する。
本番リリース可否
- 全ての案件において、リリースできるかどうかの決定ができる。
- 営業がリリースの要望を持っていても、拒否することが出来る。
- バグが残っている状態で出荷することもある
- 全ての案件において、リリースできるかどうかの決定ができる。
PDM、開発、QAの三権分立を行っており、パワーバランスを保っている。