情報システム部の飯田です、こんにちは！
先月(2022年8月)のもくテクでは業務効率化をテーマにしたLTが行われ、私と同じチームのいっしーさんが課金システムの入金消込業務の自動化について発表してくれました（記事はこちら）。部門を跨いで業務が効率化されて毎日ありがたみを感じています。また、業務効率化のあれこれ Vol.1で渡辺さんが発表してくれたPlaywrightでのブラウザ自動操作も日々の開発業務で役立っています。
課金チームの業務効率化はこれで全部なのでしょうか？いやいや、まだあります！ということで、今回は私がメインとなって行った課金システム専用のテスト環境の構築について書いていきたいと思います！
課金システムの特徴
今回の話の中心となる課金システムはお客さまが弥生のサービスを契約する時に使っていただくもので、お客さまが直接操作する画面と裏でさまざまな処理を行うバッチ、そして他のシステムと連携するためのAPIから構成されています。
特徴としては、数多くのお客さまの契約データを扱っているので性能が重視されることや、契約には期間や請求といった要素があるので時間の観点が重要であること、内部・外部問わず連携しているシステムやサービスが多いことなどが挙げられます。
課金システムをテストする時の課題
システムの総合的なテストを行うには他のシステムとも連携しているテスト環境を用いますが、課金システムのテストでは以下のような課題がありました。
大量のデータが存在するので処理に時間がかかる
テスト環境はもちろん他のチームも使っているので、課金システムにも日々新しい契約データができていきます。性能を確認するには都合が良い一方で、バッチ機能のテストを行う時には大量のデータが仇となって処理に時間がかかり、どうしても待ちが発生してしまいます。
日時に関するテストを行いづらい
上記の通り課金システムには時間の観点があり、例えば以下のような仕様があります。
- 契約期間が終了する時、特定の条件を満たしていれば契約期間を延長する
- キャンペーンの適用期間内であれば、その内容に応じて料金を割引する
- 支払いが何度か行われなかった契約には利用制限を適用する
こういった内容をテストするにはまず条件に沿った契約データを過去にさかのぼって作成する必要がありますし、その上でテストしたい処理が行われるまで時間を進めながらシステムを運用しなければなりません。しかし全てが連動しているテスト環境では課金システムの日時だけを変更するなんてことはできないので、事前に各チームへ確認を取ってから実施する必要があります。場合によってはスケジュールの調整が必要な時もありました。
他チームの契約データを巻き込んでしまう
テストの内容によっては他チームが作成した契約データに影響が出てしまうケースがあります。例えば利用制限に関するテストを行うために請求書の支払いが行われないようにしてシステムを運用していたら他チームの契約データにまで利用制限やさらにその後の自動解約が適用されてしまい、データの復旧や再作成を行わなければなりませんでした。
データメンテナンスで処理の対象外にすることも不可能ではありませんでしたが、実際の運用では行わないことに手間や時間をかけるのは非効率的です。
「専用のテスト環境」という発想
このような課題に対して出てきたのが「課金システム専用のテスト環境を作ってしまえば解決するんじゃないか？」という案でした。本番同様にシステムを連携させたいのに専用とはこれ如何に？と思うかも知れませんが、つまりこういうことです。
課金システムをテスト環境に複製してしまいます！
なんと大胆な！と思うかも知れませんし、一般的なシステムで同じようなことをするのは難しいかと思いますが、事前に課金システムと連携する他システムのチームと相談し、以下の条件であれば問題なさそうという結論に至りました。
- 同じアカウントで同時に2つのテスト環境で契約を作成しない
- 他システムから課金システムの専用環境への連携は行わない
- テストで使い終わった契約は解約する
つまり専用環境の課金システムから他システムへは一方通行ということです。他システムから課金システムを呼び出す機能（製品起動時の契約チェックなどがあります）は従来のテスト環境でテストする必要がありますが、それを除いても課金システムの大部分の機能を専用環境でテストできるようになり、上で挙げた課題も以下の通り解消しました。
テストに必要なデータのみ存在するので処理が速い！
専用環境にしたことによって、こちらに作成した契約データは課金チームが自由に削除できるようになりました！（他システムに連携しているデータは解約扱いにしてもらいます。）これによって必要最小限の契約データのみが存在する状況でテストできるようになり、今まで1時間近くかかっていたバッチ処理が数分で終わるなんてこともありました。性能を検証したい時には従来のテスト環境を用いるか、専用環境でPlaywrightのツールを使って夜間にデータを仕込んでおくという選択も取れるようになりました。
日時も変え放題！
事前の確認によって専用環境の日時を変えても他システムへの影響はないことが分かっていたので、こちらの都合によって自由に日時を変更できるようになりました（他システム目線では過去から将来まで様々な日付のデータが課金システムから連携されることになりますが）。
既存のテスト環境の契約データには影響なし！
専用環境の契約データは従来のテスト環境とは別管理となっているので、専用環境でどんな運用をしても既存のデータには影響ありません。
課金システムの業務効率化はまだまだ続く
専用環境の運用開始から1年以上経過し、一部制約はありつつも上記の利点を活かしてテストの効率化へと大いに役立っています。最近ではバッチの自動実行スクリプトも導入されていてテスト実施の手間も減りました。
とはいえ、課金システムが取り扱うデータの数やサービス・プランの種類は増え続けているのでさらなる改善が必要です。目先の対応にとらわれずこれからも業務効率化に取り組んでいきたいと思います！
あとがき
今回の専用環境の構築で苦労した点としては、本文中で触れている他チームとの認識合わせの他に、課金システムが連携している外部サービスの理解というのもありました。現在どのように連携しているのかを把握するのは比較的容易ですが、現在の状態にするには最初にどういった設定が必要なのか、その設定が何に影響するのかを調べるのは、普段の開発ではほとんど意識していない領域だったので難しかったです。当時のドキュメントは残っていたものの、外部サービスもバージョンアップしていくので変わっていた部分もありましたし。
変わったといえば、運用している途中で外部サービスの仕様が変わってデータの完全削除ができなくなったということもありました。結果としては設定変更でどうにかできるようになったのですが、改めてシステムって生き物だなぁと感じました。そんなこんなで専用環境には結構愛着が湧いています（笑）
一緒に働く仲間を募集しています
弥生では一緒に働く仲間を募集しています！
弥生で働くことに興味がありましたら、求人一覧をぜひご覧ください。
