「三権分立」で1年に200リリースを達成した楽天トラベル、150人規模のチームで実現できた秘訣とは：DevOps時代のテスト自動化カンファレンス（後編）（1/2 ページ）

2016年12月6日に開催されたセミナー「DevOps時代のテスト自動化カンファレンス〜はやく、いいものを届けよう〜」のレポート第3弾では、楽天トラベルにおけるDevOpsとテスト自動化の取り組みを中心に、最適な開発ライフサイクル実現のヒントを紹介する。

[高橋睦美，＠IT]

　市場ニーズを素早く形にし、「ビジネスの成果を獲得するまでのリードタイムを短縮する」上で重要な手法となる「アジャイル開発」や「DevOps」だが、これらの取り組みにおいて「テスト」というプロセスをどう組み込むかが「いいもの」を作れるかどうかの大きな分かれ目となる。管理すべきコード、テストすべきコードが増加する中で必要十分なテストを実施し、開発サイクルを素早く回す鍵として注目されているのが自動化だ。2016年12月6日に東京で開催されたセミナー「DevOps時代のテスト自動化カンファレンス〜はやく、いいものを届けよう〜」の講演を基に、そのエッセンスを探っていこう。

　前々回は、AbemaTV／サイバーエージェント、日本シノプシス、丸紅情報システムズの講演を紹介。前回は、マネーフォワード、リックソフト、アシストの講演を紹介した。最終回の今回は、楽天トラベル、テクマトリックス、日本ヒューレット・パッカードの講演を紹介する。

「三権分立」で1年に200リリースを達成した楽天トラベルの取り組み

楽天 ライフ＆レジャーテクノロジー統括部 トラベルサービス開発・運用部 トラベルプロダクトデベロップメント課 シニアマネージャー 鬼本康博氏

　国内最大級のオンライン旅行サービスを展開する楽天トラベルでは、世界各地の旅行パンフレットを閲覧できるアプリ「PATW」をはじめ、2016年の1年だけで200件以上の新機能や改修をリリースしている。これだけの新規開発を、前身のマイトリップ・ネット時代からのインフラを引き継ぎながら、プロダクトマネジャーと開発エンジニア、QAエンジニア、インフラならびにDevOps担当など150人規模のチームで実現している秘訣はどこにあるのだろうか。

　楽天 ライフ＆レジャーテクノロジー統括部 トラベルサービス開発・運用部 トラベルプロダクトデベロップメント課 シニアマネージャーの鬼本康博氏と同トラベルプロダクトマネジメント課 Quality Assuranceグループ マネージャーの残田晋氏が、「『ツールありきではなく業務ありき』DevOps実践環境はこう作る」と題して講演を行った。

　鬼本氏によると、楽天トラベルの開発には2つの特徴がある。1つは、開発者とQA、プロダクトマネジャーの三者が、ちょうど三権分立のように互いにチェックし合いながら責任を果たす組織構造になっていることだ。もう1つは、あらゆる案件が、Issue（問題点）とゴール、シナリオを記した「ウィッシュリスト」という形でドキュメント化することから始まること。レビューを経て一度サインオフした案件は、その後はアップデートせず、仕様変更の必要が生じた場合はあらためて新規にウィッシュリストを書き起こすという。

インフラ管理をコードに移行し、本来の仕事に使える時間が大幅増

　楽天トラベルのテクノロジ部門では2016年の年頭に「モニタリング」「見える化」など6つの目標を立てた、その1つに「オートメーション」があった。

　「1996年からサービスを提供してきた関係で、さまざまなバージョンを管理する必要があった。OSのバージョンはもちろん、JavaならJDKのバージョンもTomcatのバージョンもさまざま。一方、アプリケーション開発の生産性が上がってくるにつれ、サーバの構築リードタイムを短くして『できるだけ早くほしい』という要望を受けるようになった」（鬼本氏）。さらに、オペレーションミスの削減や、ステージング環境と本番環境の差分に起因するトラブルも解決したいと考えていた。

　「こうした問題を解決するため、2015年10月ごろに、それまでテキストで管理されていたインフラを、コードでマネジメントする方向に一気に倒した」（鬼本氏）

　従来、Excelなどを用いて手作業で管理していたバージョンや設定内容はBitbucketで管理することにし、ホストグループごとにChefのCookbookやAttributeファイルでOS情報やホスト数などを定義した。設定ファイル（Config）やテンプレートも同様に監視するようにしたという。当初、移行作業は5カ月程度かけて進める予定だったが、2015年内に百数十タイプ以上あったサーバ、ほとんど全てについてコードによる管理へ移行したそうだ。

　この結果、サーバの払い出し依頼があればBitbucketにリモートプッシュし、それがJenkinsに流れ、RubyのコードやChefの内容をRuboCopとFoodCriticでチェック。その後、ChefSpecやRSpecを用いてユニットテストを実行し、結果がHipChatに表示される、という一連の流れが構築できた。オペレーションについても、マニュアルによる確認だけだった段階から、Serverspecと念のためのマニュアルチェックの組み合わせになっているという。

　2016年2月には、インテグレーションテストを追加したり、Dockerコンテナを組み合わせたりするなど、取り組みをさらに拡張している。鬼本氏によると、1日に約500コンテナが起動してはテストし、つぶされるというサイクルを繰り返しているそうだ。また2016年7月にはステージング環境で、9月からは本番環境で、レギュラーチェック（定期的なテスト）を実施し、冪等（べきとう）性の確保に取り組んでいるという。

　15カ月前に比べると楽天トラベルのサーバ台数は1.8倍に増加したが、その運用に当たる人数は3〜5人程度のままでカバーできている。「2015年10月当時は、自分の時間の30％をアプリケーションチームからの依頼に割き、30％を自グループの案件に費やすという具合だった。現状では、アプリケーションチームからの構築依頼に使う時間は半分以下の10〜15％で、ツールや環境の改善といった自グループの案件に50％くらいの時間を使える状況だ」（鬼本氏）

　こうした成果を踏まえ、JIRAを用いたリクエストフローのオートメーションにも取り掛かっているそうだ。「アプリケーションエンジニアがチケットを作成すると、その後、自動でJSONファイルまで生成される。レビューと承認はオペレーションチームがやるが、その後は自動化の流れに乗ってオペレーションなして本番環境に載るところまで実施できるようになっている」（鬼本氏）

　同様に、複数のプロジェクトが同時並行で進む中で、リソースの衝突を引き起こすことなく円滑に開発とテストが実行できるよう、マルチサーバ環境を構築した。そのリソースにプロジェクト単位で適切にアクセスできるプロキシサーバを構築しただけではなく、自ら設定できる環境を用意。手戻りなく開発を進められるようにし、生産性を高めたという。

プロジェクトの初期からQAエンジニアも関わり、こと細かくドキュメントを作成

楽天 ライフ＆レジャーテクノロジー統括部 トラベルサービス開発・運用部 トラベルプロダクトデベロップメント課 Quality Assuranceグループ マネージャー 残田晋氏

　続けて残田氏が、QAのプロセス改善に向けた取り組みを紹介した。リリースが年に200件となると、毎月15〜20件ほどのQAをこなす計算になるが、楽天トラベルでは20人体制のQAチームでその作業を回している。うち15人はマニュアルのテストを行い、残り5人が自動化に取り組んでいるそうだ。

　先に鬼本氏が紹介した「三権分立」の仕組みの中で、QAチームには、バグの重症度に応じてトリアージを行う権限が与えられている。バグの内容によっては、今すぐ修正しなければ以降のテストは行わなかったり、直ちにではないものの修正しない限りリリースは認めなかったりといった重要な判断を下す権限が与えられているわけだ。

　残田氏は「おそらく他の企業と同様だと思うが」と述べた上で、起案、要件定義とその確認、テスト計画、設計、実施、本番リリースとその確認というプロセスを回す中で、さまざまな改善に取り組んできたと述べた。

　「2016年は200、2017年、2018年は300、400というリリースを、今の人手を極力増やさず回すためには、いろんな課題が出てきている。主な課題は、システムが新しくなっていく中でテストケースが増え続けていること。テストケースが増えれば、ケース漏れも発生する。また、開発のスピードが上がっている中、われわれQAの速度が追いついていないという問題も発生してきた」（残田氏）

　その解決に向けて実施した施策の1つが、「テスト設計」のプロセスを、「テストスペック」「ケースデザイン」の2つに分けたことだ。「どんなテストをしたいのか、どういうシナリオで、どういうスコープでやりたいのかという概要を定義するフェーズと、実際にケースやシナリオに落としていくフェーズに分けることによって、開発段階で何らかの問題が起きても柔軟に対応でき、手戻りコストを抑えられる体制を整えている」（残田氏）

　現時点でもテストドリブンを志向し、開発と同時にテスト設計とケース作成を行っているが、スコープの確認も前倒しで行うようにしていく。「ケースの作成は実際の開発が始まった段階で行い、過去のテストケースや重要なテストケースの結合もこのフェーズで終わらせる。1つ前の段階で行うことで、さらに手戻りコストを減らしつつ、複数の案件を動かしていく」（残田氏）

　プロセス改善の一環として、QAエンジニアが要件定義の段階から関わり、テスタビリティの観点から要件に漏れがないかレビューするようにもした。プロジェクトの最初の段階からQAエンジニアが関わり、ドキュメントの漏れをなくすことが大切だと分かってきたという。「一番重要なのは、やはりドキュメント。要件定義の段階で、全ての後に続くプロセスに影響がないよう、できるだけ漏れなく、こと細かく定義することに一番時間を使っている」と残田氏は述べた。

　2017年に向けてQAチームでは、手動テストと自動テストの並行実行などに取り組んでいく計画だ。また、活動の成果として出来上がったテスト自動化ツールは、QAチーム内はもちろん、開発側に渡してクオリティゲートとして活用してもらうことも考えている。最終的には本番環境の監視、モニタリングに使えるツールを目指しているそうだ。

　さらに「自動化用のフォーマットと手動のフォーマットの統一に取り組もうと考えている。今までテスト設計では、マニュアルテストのためだけの設計をしていたが、同時に自動テスト用にも落とし込む必要があるとなれば、プログラミングできるよう、事細かく期待値を記述する必要がある。従来は、それぞれが手でExcelなどに書いていたパターン表やケースを基にテストをしていたが、これからはオートメーション用にテストケースを書き、それを見て人間がテストをするようになるかもしれない」（残田氏）。当然、最初はその分の手間とコストが掛かるが、実際のテスト実施フェーズでは、従来の半分程度のコストで運用できることが見えてきたそうだ。

　このようにインフラの自動化についても、またQAについても、生産性向上というゴールに向けて段階的に、地道に継続を重ねてきた楽天トラベル。今後も、プロダクトマネジャーとQAと開発、3者がバランスを取りながら責任を果たすことで、クオリティを保ちながらリリースを続けていくという。