Rakuten Tech Blog

皆さんこんにちは。12月15日を担当させていただきますTaichiです。
楽天トラベルサービスを開発している部門の、Front End Developmentグループという部署に所属しています。

…というと、Javascriptなどを使ってバリバリ「フロントエンド」を開発していそうなのですが、フロントに関わる仕事はせいぜい2-3割程度。
肩書に偽り有りです。

実は、私の主務は、フロントエンドエンジニアの皆さんがフロントをバリバリ開発できるよう、「フロントエンドとサーバサイドのビジネスロジックの分離」を進めること。
本日はこれについて紹介させてください。

分割の始まり

楽天トラベルでこのような動きが始まったのは、2010年頃だったと記憶しています。

現在の楽天トラベルは、1996年、「ホテルの窓口」というサービスとして始まりました。
2010年当時、創業当時のプログラムがそのまま稼働している…　ということは流石になかったものの、急成長を遂げながらツギハギで作られてきたシステムは複雑に絡み合い、重複コードも多く、「ちょっとした修正が全然関係なさそうなところに影響を及ぼす」ようなトラブルが頻繁に起こっていたような状況でした。
このような状況を打開するために、「同じ処理はAPIとして一箇所にまとめる」「フロントとロジックは分離して疎結合にする」という、大きなシステム再構築が始まりました。

初めにターゲットになったのはホテルの予約やキャンセル関連の処理。
こちらで実績ができた後、楽天トラベルに参画してくださっているホテルや旅館の方が使う、「施設管理画面」がリファクタリングの対象となり、私自身も当時、メンバーの一人としてこの案件に参加しました。

絵に描いたようなスパゲッティ

この施設管理画面。
使われているプログラミング言語からして古かったり、コピペで作られたようなプログラムが多かったり…　と、当時は「ちょっとした修正が全然関係なさそうなところに…」の代表格のような存在でした。

しかし、機能ごとに再構築された後は、新機能開発にあたっての影響調査が大変楽になったことを覚えています。

また、今年2016年に、長年使われてきたUIが刷新され、とっても見やすく・使いやすくなった「新管理画面」がリリースされました。
こういったことが可能だったのは、まさに、フロントエンドとサーバサイドが適切に分離されていた結果だと思います。

「楽パック」の挑戦

さて、私が現在担当しているのは、楽パックというサービスです。
航空券や宿泊などの商品を自由に組み合わせて予約することができるので、飛行機を利用したご旅行の際は是非！
…という便利なサービスなのですが、反面、システムの面から見ると、多数の外部・内部のAPIの呼び出しや複雑な料金計算ロジックが実装されており、「なかなか手が出せない」「レガシーなモノリス」として、我々エンジニアの前に長年そびえ立ってきました。

このシステムに対し、「より速く」「より安全に」改善のサイクルを回せるようにするため、適切なサイズに解体し、再構築することが現在の私のミッションです。

今は、検索機能のAPI化を進めているのですが、

「そもそも検索って何？」「パッケージ商品の検索って何？」
を再検討するところから始まり、

「検索」といいつつ
「商品を組み合わせる」ロジックや「デフォルトの商品を暗黙的に選ぶ」ロジックが必要であることに気づいたり

はたまた
現在の作りが非常にステートフルで、ユーザビリティもメンテナビリティもよろしくないので
いっそこのタイミングで、ステートレスに作り変えよう！
と挑戦してみたり

…と、次から次へと課題が出てきて、飽きない日々を送っております。


元が複雑なだけにチャレンジが多いのですが、この案件が完了した暁には、これまでの倍どころかそれ以上の開発速度が出ると信じて、日々頑張っております！