はじめに

こんにちは。弥生で販売課金システムのエンジニアをしています、Kです。
このブログは弥生 AdventCalendar 2024 の13日目の記事です。
本記事では、弊社の販売課金システムの移行プロジェクトについて記載します。

ざっくりと販売課金システムについて説明

弊社の販売課金システムは、新システムと旧システムの並行稼働で運用していました。
「デスクトップソフト」および「あんしん保守サポート」の契約管理は旧システムで行っていましたが、ゆくゆくは新システムに移行する計画でした。
私が5年前に入社した時も、社内研修などで全社的な大きな課題として話されていたのを覚えています。
当時は正直「へー、大変そうだな（遠い目）」と思っていましたが、まさかそのプロジェクトに自分が深く関わることになるとは思いませんでした。
今回は移行プロジェクトで成し遂げたことや大変だったこと、学びなどをまとめてみたいと思います。

システム移行の概要

旧システムには、新システムと同様に画面の契約導線が存在し、バックエンドも新システムとは別に持っています。
以下のような順に移行の準備、実施を行います。

  
新システム側に、必要な画面の追加やバックエンド機能の追加
（旧システムでできていたことで必要なもの精査し、新システムにも機能を作る）
↓
新システム側だけで、デスクトップ製品の契約操作や管理ができる状態にする
　⇒ここまでで、移行先の箱はできた状態
↓
旧システムのデータ構造から、新システムのデータ構造に置き換える「データの移行」を行う

また、移行のタイミングについては移行期間を設けて、その間はお客様の好きなタイミングでデータの移行を行うことができます。
ただし、ある程度早めに移行を進めたいため、契約期間に応じて月初にまとめて自動移行する仕組みも導入しました。
毎月月初に、母数の約1/12のデータが移行されるというものです。

システム移行リリースまで

私はデータ移行の実装をメインで担当していましたが、着手前から大きな壁にぶち当たっていました。それは…
”そもそも旧システムのデータ構造が全く分からない！！”

旧システムの画面を見たことは何度かありましたが、詳細な契約導線やバックエンドの構造などは全くもって知りませんでした。
DBのテーブル名も一つもわからないという状況でした！
そんな状況でしたが、以下のような順に進めていきました。

  
とっかかりとして、旧システムを知っている有識者に相談
↓
細かいところはさておき、最低限軸となるデータ構造（今回の場合、契約内容や契約期間など）
が分かったところで、最もシンプルなケースの移行を、詳細なデータ構造込みで描いてみる
↓
上記を有識者レビューしてもらい、指摘やアドバイスをいただく
↓
開発環境で、上記のプロトタイプを実装してみる（実現可能性のチェック）
↓
上記を軸に、他に必要な情報が何かを洗い出す
↓
必要な情報の洗い出し後、それらに対してパターンの網羅を行い、移行前後のデータ構造を確定する
↓
上記を実現するためのプログラムを、プロトタイプをもとに設計する

一番重要だと感じたのが、まずシンプルなケースをプロトタイプ作成まで実装することです。
基本的なデータ構造の理解や実現可能性まである程度検証できるため、このステップは複雑なシステム移行には必須の手順だと思います。
ここまでできてしまえば、これを軸にパターン分けをしていく作業になります。
パターン分けの際、どうしても実現が難しいケースがあった場合は、移行とは別の機能で補完するか、もしくは移行対象外とするような対策を取ります。
実際はプロトタイプ作成から最終的な仕様確定・リリースまでには色々課題が見つかりましたが、移行ロジックや周辺機能による補完で、何とかテストをクリアできました。

システム移行リリース後

システム移行機能のリリースは無事成功しました。（実はリリース当日も色々あったのですが…）
リリース当初はいくつか不具合があり、移行時にエラーになってしまうお客様もいらっしゃいました。
加えて、エラーになった方だけでなく、希望通りの移行がされなかった方から問い合わせがカスタマーセンターに殺到しました。
リリース後に一番大変だったのは、上記のようなお客様への対応でした。
システム移行は弊社の都合で行うものであって、決してお客様が悪いわけではないので、お客様の希望通りに契約管理ができるように、お客様対応や場合によってはシステムメンテナンスで対応する必要がありました。

これは後から聞いた話ですが、リリース当時のカスタマーセンターは大混乱で、応答率の低下もさることながら、どう対応したらいいかもわからないケースが多い状況でした。
（問い合わせの原因が、システム障害なのか、お客様の操作ミスもしくは元のデータが悪かったのかが切り分けられなかった。）
カスタマーセンターの方と直接会って話を聞く中で、改善が必要だと感じた点は以下です。

  
・お客様影響が大きいリリースの直後は、開発本部への問い合わせ窓口を多く持っておく
・同時に、すぐに相談できる開発担当の有識者を現場に派遣し、迅速なエスカレーションができるようにする

正直、大規模なリリース直後は不具合対応などで開発本部も余裕がないため（実際余裕はなかった）、実現できるかはわかりません。
しかし、当時は上記のような発想自体無く、現にカスタマーセンターは大混乱で、開発担当もなかなかエスカレーションに対応できていなかったです。
次回こういった"お客様影響の大きい"リリースがある場合は、事前にエスカレーション担当を確保するなどの対策をとろうと考えています。

実はリリース直後ではないですが、上記のように開発担当者が現場にいてほしいという意見があったので、移行の最繁忙期に私が1週間ほどカスタマーセンターに出張し、現場でエスカレーション業務をしていました。
その時は既に対応方針がある程度確立されているものが多かったので、頻繁にエスカレーションが来ることはなかったですが、「やはりすぐに開発担当に質問できるとその場で解決できるし効率が上がる、あるいは安心する」という声が多くありました。
そういった声からも、上記のような対策は必要だと考えます。

まとめ

システム移行のとっかかりとしては、まず移行元のシステムの有識者にヒヤリングし、シンプルなケースで移行方針を決定＆プロトタイプ作成まで実施すると良いです。
また、お客様影響の大きいリリースになる場合は、開発担当者の一部をカスタマーセンターからの問い合わせ担当にするなどの工夫をする必要があります。
弊社の基幹システム移行に関する実話なので、あまりシステムの詳細に踏み込んだ具体的な話は書けませんでしたが、今後大規模なシステム移行を担当する方には是非参考にしていただきたいと思っています。