ホスティング事業部の業務信頼性向上チームでエンジニアをしているはらちゃんです。 ホスティング事業部で使用していた売上集計システムのマイグレーションを行いました。 既存のシステムをいちから作り直したことについて、どのように進めていき、何が大変だったか、やって良かったこと、こうしておけば良かったことなどをまとめておこうと思います。
- まず業務信頼性向上チームとは？
- 売上集計システムのマイグレーションを行った理由
- どのようにマイグレーションを進めたのか？
- 何が大変だったか？
- 何がやって良かったか？
- こうしておけば良かったと思う点
- まとめ
- 小話
まず業務信頼性向上チームとは？
最初に、自分の所属している業務信頼性向上チームの紹介です。 ホスティング事業部内では、Internal System Reliability（業務信頼性向上）の頭文字をとってISRチームと呼ばれています（以下ISRチーム）。 ISRチームは社内で使用する顧客管理システムや業務ツールなどの信頼性を高めるチームです。 加えて、内部統制を含む業務プロセス改善を行うことやDX推進を支援することで、事業部全体の生産性向上をミッションとしています。 ざっくり言うと、一緒に働く仲間が働きやすい環境を整えるチームです。 現在4名（2023/03/16時点）のメンバーで、さまざまな業務改善やホスティング事業部で使用している社内システムの運用を行っています。
売上集計システムのマイグレーションを行った理由
ホスティング事業部にはサービスごとに売上集計システムがあります。 今回、新収益認識基準にのっとってこのシステムの改修を行う必要がありました。 ただ対応するだけならば、既存の売上集計システムに変更を加えれば要件を満たせます。 しかし、下記理由から売上集計システムのマイグレーションという選択をしました。
- ホスティング事業部のサービスで売上集計システムが統一されていないため下記課題があった
- それぞれの売上集計システムの構成や機能が異なることで
- メンテナンスコストが上がっていた
- このサービスではできるがあのサービスではできないという不便さがあった
- それぞれの売上集計システムの構成や機能が異なることで
- 既存のシステムが古くなってきておりメンテナンスコストが大きかった
- 使用ライブラリのバージョンが古く更新できていない
- 使用している言語のバージョンが古い
- 運用上必要とされる機能が新たに存在した
これらの理由から、既存の売上集計システムが今後の運用に耐えることは現実的でないと判断しマイグレーションに踏み切りました。
どのようにマイグレーションを進めたのか？
マイグレーションは大まかに下記の手順で進めました。
- 要件定義
- 既存システムを利用している関係者へのヒアリング
- 出力内容と形式を決定
- 新収益認識基準に合った集計ロジックの決定
- 稼働させるサーバーの決定
- 使用する言語の決定
- 実装
- 既存システムの出力を再現するようにシステムを構築
- テストの追加
- 変更があるロジックの改修
- 検証
- リリース
要件定義
要件定義では、既存の売上集計システムであるwebページの機能一覧を下記のように書き出し、どの機能をどのように使っているかヒアリングをしました。
この表で、誰がどのwebページから何を得ているということが明らかになりました。
関係者が得たい情報がわかったので、次にどういった形式で出力されるのがいいのかも確認しました。
既存の運用では、webページのスクリーンショットを証憑として使用していたが、CSVなどのTEXTで問題ないのかなどの確認です。
これで、既存のシステムから必要と思われる要件をあらかた定義することができました。
続いて、新収益認識基準に対応するための要件を経理部門と話し合い、この項目はどういった計上方法に変更するかなどの細部の詰めを行いました。
細かい内容は伏せますが、やったことは現行の会計処理を書き、それに対しどういった背景で新しい会計処理に変更するかをポジションペーパーにまとめました。
稼働させるサーバーの決定
要件定義の結果、出力がwebページである必要はないことが判明しました。 このようなことから専用のホストを用意せず、GitHub Enterprise Server（以下GHES）上でGitHub Actionsを使用することにしました。 GitHub Actionsを採用した理由は、売上集計システムをActionsで稼働させることで、下記メリットがあると思ったためです。
- ホストの運用保守のコストをゼロにできること
- webページなどのviewにかかるコストが削減できること
- 権限管理はGHESに委任できること
完成後の稼働の様子は下記の通りです。
このように、サービスと対象年月日を入力し売上集計を行います。 集計が終了次第PRを作成し、出力結果をGitでバージョン管理できるようになっています。
使用する言語の決定
実装に使用する言語は、下記理由でGoを採用しました。
- Goは後方互換性のある言語である（今のところ）
- ホスティング事業部では、バックエンド実装のための言語としてGoが推奨されているため事業部としての学習コストは総合的に低くなる
- GitHub Actionsでサービス提供するにあたり、必要なものがワンバイナリで可搬性があること
実装
実装では、3サービス（ロリポップ！、ムームードメイン、ヘテムル）の売上集計機能に加えて、ムームードメインの仕入れコスト集計機能の計4つの実装が必要でした。 構成としては、下記のような形で実装しました。
売上集計システムとしてsobaと命名されたパッケージ（命名の由来は小話へ）を用意しました。 sobaパッケージでは、cobraというGoのCLIアプリケーションを作成するためのライブラリの処理を記述しています。 その配下の子パッケージとして各サービスとコストのパッケージを配置しました。 子パッケージでは、実際に各サービスDBへの接続や集計ロジックの実装、集計ログファイルの出力などを担当しています。
このようにサービスごとにパッケージを分けたことにより、並行して実装をしやすくなりました。 1パッケージに対して1名の担当エンジニアが付き、実装や進める上で新たに出てきた問題を各ステークホルダーと確認しつつ進めました。
各担当に分かれてまずやったことは、既存システムの出力を新システムで再現することでした。 これにより、ビジネスロジックや集計ロジックへの理解を深めると同時に、Goの扱いになれることができました。
既存の出力を再現できたあとは、新基準により集計ロジックが変わる部分を実装していきました。 この実装では、まず期待する集計結果をテストに落とし込み、その後集計ロジックの変更を行いました。
検証
リリース前の検証として、運用開始予定日の1年前からこのシステムを動かしていた想定で、シミュレーションを行いました。 つまり、運用開始日は2022年1月1日だったので、2021年1月1日に新システムへ切り替えを行ったこととして、1年分の売上集計を実施しました。 これで、正常に運用できているかを検証しました。
何が大変だったか？
以下、大変だったことをチームメンバーごとに記載します。
ロリポップ（担当：はらちゃん）
要件定義から実装・検証までを初めて担当したのでまずそれが大変でした。 ステークホルダーと認識の相違をなるべく生じさせないようにコミュニケーションを進めたり、本当に必要とされているものを言語化するのが難しかったです。 それに加えて、3000行ほどのSQL文を読み解くのが大変でした。 この経験を経て、どんなに長いSQL文を見ても動じない心を手に入れたのでいい経験でした。
ムームードメイン（担当：orzup）
ムームードメインのサービス開始から現在に至るまでの契約についてそれぞれの契約状態を洗い、sobaではどういった売上計上がされるべきなのか判断を行なったことです。 数十年積まれてきた契約の中には、なぜこの状態になっているのかという背景がすでに失われてしまっているものも多く、契約のデータやサービスのコード、ドキュメントといった今ある情報から推測することしかできません。 できる限りの調査を行うことで事実に近い推測をしたはずですが、それが100点満点なのかどうかは誰にもわからないので大変でした。 もともと私は、コードには語られていないシステムの設計意図や方針について情報を残すことを重要視していたのですが、sobaの開発を経てより情報を残していくぞと改めて認識できたので良い経験でした。
ヘテムル（担当：とみー）
新収益認識基準に対応するにあたって、どの項目について計上の変更が必要で、どの項目については変更が不必要かといったことを、経理の方と話し合いながら確定させるのが大変でした。 ソフトウェアを開発する上でのコミュニケーションの重要性を改めて思い知りました。
ムームードメインの仕入れコスト（担当：genkiroid）
イニシャルデータとして必要となる請求明細の数が、大量かつフォーマットが統一されていないといった状態であったため、それらを整形したりアレしたりするスクリプトをたくさん書くことになりました。大変でしたが楽しかったですね。
何がやって良かったか？
以下、やって良かったことをチームメンバーごとに記載します。
ロリポップ（担当：はらちゃん）
ステークホルダーとの認識確認を頻繁に行ったことが良かったなと思っています。 頻繁にコミュニケーション取ることによってお互いの距離も縮まり些細なことでも声をかけ、確認できる関係が構築できました。 また、文字や言葉だけだとやはり相違が生まれてしまうので図や表を用意して確認したことも良かったなと思います。 これらのおかげで、大きな手戻りも発生せず終えることができました。
ムームードメイン（担当：orzup）
エンジニアが仕様を把握するドキュメントとして確認できるように、様々なパターンのテストを用意したことです。 今回の新収益認識基準に対応するにあたって、特にムームードメインは大部分の契約データに関する売上集計方法が変わりました。 売上集計システムへの入力である契約データの状態とその出力である売上集計結果がどう遷移するのか、あえて多くの種類のテストを用意することを選択しました。 これにより、エンジニアであればテストから売上集計の概要を把握することがでます。 先日、久しぶりにロジックの調査をする必要があったのですが、私はすっかり仕様を忘れてしまっていて困り果てたのも束の間、テストで仕様を確認できて便利！となっています。テスト最高！
ヘテムル（担当：とみー）
Goを実務で書くことができたのは大変良かったです。今ではすっかりお気に入りの言語になりました。 ただ、今コードを見返すと、書き直したいところばかりなのはご愛嬌ではあります。それだけ過去の自分より成長できたということとポジティブに捉えることにします。
ムームードメインの仕入れコスト（担当：genkiroid）
わりと綿密に設計（運用設計を含む）したので、運用開始後に大きなトラブルなく走っています。運用設計を反映した形の運用ドキュメントも整備したので、属人化を防ぐ一助になっています。
こうしておけば良かったと思う点
以下、こうしておけば良かったことをチームメンバーごとに記載します。
ロリポップ（担当：はらちゃん）
自分は、しっかりとGoを触ったのが今回はじめてでした。 関数とメソッドの違いもわからないまま進めてしまっていたので、メソッドをあまり使っておらず低凝集な作りになってしまったのが心残りです。 構造体に紐づく処理はしっかりとメソッドを使っておけば良かったなと思っています。
ムームードメイン（担当：orzup）
sobaの運用開始日が決まっていたこともあり、マイグレーションに伴って用意したい機能のうち諦めた機能がいくつかあるのですが、それをやっていけるといいなと思います。 特に、エンジニア向けのドキュメントとして様々なパターンのテストを用意したのですが、これを経理やディレクターといったエンジニア以外のパートナーにも簡単に共有できるようにドキュメントが自動生成されるといった整備をやりたいですね。
ヘテムル（担当：とみー）
厳格なスケジュールが決まっている中、開発を進める中で改めて定義すべき要件に気づいたりと、オンスケジュールで進行させることの難しさを感じました。 開発手法については、何かしらのプラクティスを取り入れるなどして、改善できていたかもしれません。
ムームードメインの仕入れコスト（担当：genkiroid）
こうしておけば良かったというよりは、今後の伸び代として、完全自動化の実現というのがありますので、そちらをやっていければと考えています。
まとめ
今回売上集計システムのマイグレーションを振り返りました。 こういったシステムのマイグレーションや、一連の開発の具体例などなかなか情報として公開されていないので自分達も参考にするものがなく手探りで進めました。 この記事を公開したことで、少しでも誰かの役に立つことを祈っています。 この記事を読んで面白かった、興味が持てた、という方は下にある採用情報をご覧ください！ISRチームは新しい仲間を探しています！カジュアル面談も出来ます〜。
小話
システムの親パッケージの名前がsobaなのは、対応するプロジェクト名が「信州そば」だったためです。
プロジェクト名が「信州そば」の理由は下記のようになっていました。
