強くてニューゲーム!大規模リプレースで次のレベルを目指す

介護・障害福祉事業者向け経営支援サービス「カイポケ」の開発をしているエンジニアの神谷です。中途入社してから5年たった今、これまでの活動を振り返ってみようと思います。

入社以来、顧客への価値提供を素早くできるようにするため、開発環境のモダン化や技術的負債の解消にトライし続けてきました。

最初は小さなサブシステムのリプレースにチャレンジし、リプレースの大まかな流れやカイポケで抱えていた技術的負債の解消パターンなどを獲得していきました。

tech.bm-sms.co.jp

直近ではカイポケ障害児支援領域の大規模リプレースに関わってきました。今回この大規模リプレースでチャレンジしたことについて、技術的な面にフォーカスして振り返ってみます。

カイポケ障害児支援領域の大規模リプレースに関してはこちらもご覧ください。

tech.bm-sms.co.jp

tech.bm-sms.co.jp

カイポケ障害児支援領域リプレースで意識したこと

今回の大規模リプレースを通して、業務知識のキャッチアップが最初の課題となりました。幸い、私がチームにJoinしたタイミングで、チームではドメインモデリングが進んでおり、ソースコードにまで落とされたドメインモデルを通して、業務知識の全体像を把握していくことができました。

また、実際に障害児通所支援事業所を訪問させていただき、カイポケを利用されている現場での課題を伺ったり、法改正に向けて現場の声を聞いたりすることで、理解度を高めていくこともトライしていました。

その他に、特に意識していたのは、以前のリプレースを通して得た知識をもとに

  • テスト、運用フェーズを意識した設計をする
  • レイヤーを跨いで、自動テスト可能な状態を維持し続ける
  • ミドルウェアのアップデートを継続的に実施可能な体制を作る

ことでした。次に具体的な例を挙げます。

テスト・運用フェーズを意識した設計

法制度が関係するカイポケのシステムテストを行う際には、法が施行される4月1日からは新しい法制度に対応しているが、3月31日以前は法改正前の振る舞いであること、といったシナリオのテストをすることがあります。

以前の法改正ではシステムや言語処理系の現在時刻を調整することで対応していましたが、これらは予期しない副作用を引き起こしたり、そもそもコンテナランタイムの上では使えない方法などもあり、避けるべきだという議論がチームでされていました。

そこで、リプレースにおいては現在時刻を扱う箇所は、現在時刻を外部からインジェクション可能な設計としています。

また、コンテナの環境変数から現在時刻を変更可能とし、テストチームから「法改正後の環境をテストしたい。法改正後の請求を行う5月の状態をテストしたい。」と要望があった場合でも、再デプロイのみですぐにテスト環境が用意できるようになっています。これは令和6年4月および6月の法改正対応で絶大な威力を発揮しました。

レイヤーを跨いで、自動テスト可能な状態を維持し続ける

ソフトウェアのレイヤーを跨いでの結合テストを充実させるため、自動テストでは動かしにくいコードをリファクタリングしていきました。

実際のデータベースやクラウドストレージにアクセスするレイヤーもコンテナを活用することで「テストダブルで理想的にセットアップされている環境では動くが、リアルな環境では動かない」といった手戻りが極力起こらないようにしています。

具体的には TestContainers を活用することでデータアクセスレイヤを含む自動テストを拡充していきました。

テスト前にコンテナをたて、テストケースごとにコンテナを破棄することで毎回クリーンな状況からテストを開始し、不安定なテストとなることを避けています。

もっとも全てのテストを実際のストレージに接続して実施していてはテスト実行に時間がかかりすぎてしまうため、代表的なケース以外はテストダブルを使用するなどバランスを考慮しています。

ミドルウェアのアップデートを継続的に実施できるようにしておく

カイポケの共通機能は社内でメンテナンスされているSpring Bootをベースとした薄いフレームワークに寄せられています。

リプレースにおいてもこのフレームワークを利用しているのですが、フレームワークをメンテナンスできる人が少なくなってきてしまっていたため、ソースコードのリーディング会や社内LT会でフレームワークの紹介、ドキュメントの整備などを行い、メンテナンスがされている状態へのリカバリーを行いました。

また、一度実験的に実装をしたものの、後に不要となった機能を断捨離することで、認知的負荷を減らし、メンテナンスが継続的に行えることを優先しました。

さらに、フレームワークの自動テストカバレッジを維持し、ミドルウェアのアップデート時に自信を持ってアップデートできるようにしています。

フレームワークはSpring Boot 2時代に社内で初回リリースされたものですが、大きな破壊的変更が入ったSpring Boot 3への対応を終え、現在3.X系の最新バージョンまで対応できています。

取り組みの結果と今後の展望

最初に取り組んだリプレースと比べ、今回は規模やステークホルダーも多く難易度は相対的に高かったものの、学習したことを生かし、もう1段階大きなリプレースを乗り越えることができました。

一方、今後トライしていきたいこともまだたくさんあります。

今回のリプレースのファーストリリースでは、フロントエンドからバックエンドまでを通したE2Eの自動テストや、フロントエンドの複数コンポーネントを跨いだ自動テストなどはスコープ調整や技術的背景から見送りました。

今後これらの自動テストを充実させ、開発速度と品質の両立を目指して探求していきたいと思っています。