楽天トラベルの開発プロセスに関して #JaSST '17 Tokyo

自己紹介

楽天トラベルについて

  • 国内外の旅行を扱っている

開発体制・案件について

  • トラベル事業は楽天の中でもトップの方を位置する規模
  • セールス、マーケティング、開発が同じフロアで行っている。
  • 開発はさらに3つに分かれている
    • PDM
      • 未来を考える人
      • 30人程度
    • 開発
      • 100人程度
    • QA
      • 30人程度
  • 基本的には全て内製

  • 2016年の新規の開発案件が209件。

  • BugFixなどのPDM以外の案件はQAが関与していない

案件の内容比率

  • 2016年の各サービスごとの改善割合。
  • 国内宿泊サービスのBugFixが8割強
  • 改修のプライオリティを5段階に分けている。毎回のプロジェクトで行っている。

QAのプロセス改善について

以前のフロー

  • ウォーターフローに近いかたち
  • PDMの人はアイデア、議論、起票、レビュー、要件定義
  • 開発の人は要件定義レビュー、開発設計、テスト設計、開発・テスト、リリース

以前の問題

  • 旧システムvs新システム
    • 開発スピードについていけない
    • ケースが漏れる
  • プロセスの改善を行った。

現在のフロー

  • 現在は、要件定義、開発設計、テスト設計(シナリオの概要を書かせる)、ケース設計、手動テスト、本番確認

今後の展望

  • 今後は開発と同じ速度でテスト設計を始められるようにする。
  • 要件定義の段階からQAが入るようにする。テスタビリティの観点からレビューに参加する。
  • 開発の設計が始まった段階でテスト設計も行うようにする。

    • 開発の設計では漏れている観点をデベロッパーにフィードバックできるようになった。
    • 開発とQAの意思疎通がうまくいくようになった。
  • 今後は、テストケースをもっとプラグラマチックなケースで書かせて、すぐに自動化できるように行う。

    • 設計にはコストがかかるが、実施コストは下がるので、トータルコストも下がる。
    • 次回以降はデベロッパーに配ることで、デグレードを抑えることができる
  • QAの責任範囲は広がっていった。

まとめ

  • QAはリリース後の全てのバグに権限を持っている
  • QAの実施可否
    • 作ったツールのパス率、ITの結果、UTの結果から判断する。
  • 本番リリース可否

    • 全ての案件において、リリースできるかどうかの決定ができる。
      • 営業がリリースの要望を持っていても、拒否することが出来る。
      • バグが残っている状態で出荷することもある
  • PDM、開発、QAの三権分立を行っており、パワーバランスを保っている。