※この記事は、Speee Advent Calendar 18日目の記事です。昨日の記事はこちら tech.speee.jp

はじめに

はじめまして、 Speee のDX事業部所属エンジニアの渡邊です。
Speee には昨年の12月に入社をして、気づけばもう1年がたっていました。今回が初めての DEVELOPER BLOG への投稿になります。

今回はJavaで実装されていたイエウールの請求周りのシステムをRubyでリニューアルした話についてご紹介します。

背景

2014年リリース当初のイエウールはPHPとJavaで実装されておりRubyに全面リニューアルされた現在でも社内向け管理ツールの特定の機能等、一部のシステムでは当時の実装が残っているものがあります。
今回ご紹介するシステムもそのうちの一つです。遡ってみると約7年ほど前の2014年3月に一番最初のコードがcommitされており、言語はJavaで実装されていました。

とはいえコードが古いことやJavaで実装されていること自体が問題になっていたのではなく、

実装当時の仕様やコンテキストを知るメンバーがいなくなってしまっている
当時のエンジニアと現在のエンジニア採用では重視するスキルが異なるため、普段の業務であまり利用しない言語で実装されたシステムの改修や機能追加を気軽に行えない

などなど、ソフトウェアとしてのコントローラビリティを失ってしまっていたことが課題となっていました。

自分をはじめ、当時のことを知らないエンジニアにとって、あまり慣れていない言語で実装された仕様が分からないシステムは「蓋を開けたくないもの」として敬遠しがちな状態になっていました。

移行方針

今のエンジニアメンバーが慣れ親しんでいる言語(Ruby)で実装する
今までの継ぎ足し継ぎ足しの運用と実装で生まれた技術的な負債を解消する
事業部の各プロダクトに存在する請求周りの共通処理をgem化する

今回の大きな目的の1つがシステムのコントローラビリティを取り戻すことなので、言語はRubyを使い、ただ移行するだけでなく長年の運用と実装で生まれた技術的な負債等の改修・改善も同時に行うことにしました。

どう移行したのか

実装

上述のように今回は単純にJavaのコードをRubyに置き換えただけではなく、事業部共通の処理部分のgem化をしたり、これまでのシステムでは対応できなかったイレギュラーな請求にもシステムで対応可能にしたり、イエウールのオプションサービスの課金に対応するよう新しく実装したり、細かい改修・改善も多々行いました。
そのため、下記のように段階を分けて各フェーズごとにスケジュールをきり、可能な限りビッグバンリリースにならないように進めていきました。

1.新しい機能をRubyで実装

このフェーズではJavaのシステムには手を加えておらず、データの整合性が保たれるように新しい機能をRubyで実装しています。
ここで実装した新しい機能群はJavaのシステムで作成/更新されるデータが存在することを前提にしているため、今まで通りJavaのシステムで処理が実行されたあとに、今回実装したシステムを実行するような運用フローになりました。

2.一部機能を段階的に移行

このフェーズから段階的にJavaで実装されていた機能をRubyに移していきました。
システムの要となる金額の計算や複雑な請求のステータス更新処理の役割はこれまで通りJavaのシステムで担当してもらいつつ、社内の売上管理ツールへの連携や請求書発行処理等の分離できそうな部分からRubyに移行しました。
共通部分のgemもこのフェーズから本格的に運用がスタートしています。

3.メイン機能の移行

最後にメインとなる機能を移行して実装自体は完了です。可能な限りJavaのテストコードをRSpecに移していくようなこともこのフェーズで実施しました。

検証方法

今回の移行に関して一番大変だったのは新しいシステムにバグがないかを検証することでした。
データ構造的に毎月の請求締め処理を実行する時点でのデータでないと算出される金額に差分がでて正しく検証ができないため、特定時点のdumpデータを2つの検証環境にインポートして新旧システムでそれぞれ処理を実行し、2つのシステムで算出された金額や更新されたデータに差分がないかをチェックするという方法で検証していきました。
このdumpデータが非常に重く、検証用のDBにインポートするだけでも割と待ち時間が発生し、さらに請求システムの実行にもそれなりに時間がかかるため、毎回検証するための環境を用意するだけで一苦労でした。
金額やデータの差分チェックもある程度自動化はしていましたが、データ量が多いため非常に大変でした。

うまくいかなかったこと

ここまでざっと実施したことを短くまとめて書きましたが、実際の移行には長い期間がかかっており、特に請求周りのシステムには高い堅牢性が求められるため神経を使うことが多かったです。
途中でプロジェクトの一時停止やメンバーの入れ替わり等もありましたが、Javaの機能を移行し始めてからでも5,6ヶ月ほどはかかっていたと思います。
また、当然不具合なしで進んだということもなく、考慮漏れや細かいバグの修正と検証を何度も何度も繰り返してきました。
特に本番に向けた作業においては、何か不具合が起きたときにどう対処/リカバリーするのかを漏れなく想定して動くのが非常に大切だと身にしみてわかりました。
また、今までの継ぎ足し継ぎ足しの運用で生まれた技術的な負債の全てを解消するには時間がかかりすぎるため、計画していたスケジュールに収まるように、泣く泣くスコープを縮小する判断も何度かしています。

最後に、学びとか

最後に、年末らしくこのプロジェクトを漢字1文字で表すと...「難」でした。

というのも、最初は仕様が分からないといっても動いているコードは存在しているわけなので、旧システムのコードを注意深くリーディングしていけば移行できるだろうと軽く考えていました。
蓋を開けてみると想像以上に属人化している部分や、なぜそうなっているのか、今も使われている機能なのか、判断するのが難しい部分が少なくありませんでした。

実際に運用していくフェーズはまだまだこれからですが、いつかこの大変だった移行プロジェクトの恩恵を受けられると信じています！
また、当たり前のことかもしれませんが、このプロジェクトを通して、エンジニアの技術的なスキルアップが「新しいモダンな技術をガンガン使い倒してドヤれるようになる」ことだけではないと改めて再認識できたので非常によい学びの機会となりました。

Speeeでは一緒にサービス開発を推進してくれる仲間を大募集しています！もしSpeeeに興味を持っていただいた方は以下で社内メンバーのカジュアル面談を公開しているので、お気軽にご連絡ください！ tech.speee.jp

Speeeでは様々なポジションで募集中なので、「どんなポジションがあるの？」と気になってくれてた方は、こちらをチェックしてみてください！もちろんオープンポジション的に上記に限らず積極採用中です！！！