10年を経たシステムへのレクイエム

この記事は 「COUNTERWORKS Advent Calendar」 の22日目の記事です。

株式会社COUNTERWORKS CTOの徳永です。
今年9月、当社の主力プロダクトSHOPCOUNTERの大規模リニューアルを完了しました。本記事では、その背景と取り組みについてお伝えします。

プロジェクトの背景

当社は2つのプロダクトを展開しています。

SHOPCOUNTER
ポップアップストア出店支援プラットフォーム（創業時からのプロダクト）

SHOPCOUNTER Enterprise
商業不動産向けVertical SaaS（3年前にリリースしたプロダクト）

創業から10年が経過したSHOPCOUNTERは、ビジネスの変遷に伴う様々な施策の痕跡を抱え、特にマーケットプレイスの核となる取引システムが、事業成長のボトルネックとなっていました。そこで、約1年をかけてシステムの全面刷新を行いました。

プロジェクトの目的と成果

2つの主要な目標を掲げました：

1. 既存システムでは実現困難だった機能の実装
2. 将来の拡張性を確保するためのシステム基盤の再構築

システム面での主な変更点：

1. バックエンドの刷新

   • 言語をRubyからGoへ移行
   • 複雑化したモノリスを、疎結合なモジュラーモノリスへ再構築

2. データベースの再設計

   • ステートレスで可能な限りイミュータブルな設計を採用
   • 売り手・買い手・運営の3つの視点でドメインを分離
   • イベント駆動型アーキテクチャの導入
   • 詳細な設計ドキュメントを整備し、チーム内での解釈の統一を図る

CTOとしての役割と課題

マネジメント職にあるエンジニアがどれぐらい開発プロジェクトに深く関わるか。

コードを書くことを辞めたというCTOが数多いらっしゃる中で、今回のプロジェクトでは、私自身も一定のコードを書きました。とはいえ、スクラムチームに入ってスプリント毎にPBIを担当していけるほどレギュラーな業務時間のコントロールは当然なく、関わったのは設計の検討やレビュー、データ移行の調査とスクリプト作成といった周辺業務になりました。

10年を経て、何があったか。

データ移行の調査が非常に難航しました。データを深ぼっていくと、数々の過去の痕跡が・・・、10年分のデータに内在する様々な課題に直面しました。

• 過去の一時的な施策による特殊データ
• 機能追加時の暫定対応が積み重なったステータス
• データ修正による整合性の乱れ
• トランザクション処理の不備による重複・欠損

もはや、システム移行あるあるの全コンプですね。

結局、丁寧にデータ間をクロスチェックしながら検証し、地道に起こっていたことを推測しながら過去のコードも含めて解釈し、お客様に許容いただけるイレギュラーなケースを対象外とさせていただく、その判断をしました。正直、無限に時間が溶けていくような作業だったため、どうやって見切りをつけるか、何を捨てるか、判断力が全てという仕事でした。振り返りの際に、

• スクラム外で対応していた
• 事業を鑑みた上での取捨選択の判断を迅速に行える

データ移行を担当したのは私で適任だったのではないかなという意見をチームメンバーからもらいました。

レクイエム

「技術負債」とどう向き合うか。

システムに残る過去の痕跡は、事業成長の証です。こうしておけばよかった、何故こうなっているのかわからない、という後世からのリスペクトのない誹謗中傷に晒されがちですが、そのときに必要だったことを必死にやってきた、スタートアップのプロダクトとはそういうものだと思っています。

SHOPCOUNTERに10年前の原型はまだ存在しています (だいぶ減りましたが)。それは素晴らしいこと。創業当時に考えたことが今でも変わらずに事業に生きていて、それを今作るとすれば別の技術や方法を用いるかも知れないとしても、まだ使えていることはリスペクトに値すると思います。過去の遺産に対して罵詈雑言を浴びせるのではなく、真正面から向き合って必要な時期に適切な方法で刷新していけばよいと考えています。

コツコツな負債返済というよりは全く新しいアーキテクチャで作り直す、そんなチャレンジに参画してみたいと思われた方、ご連絡をお待ちしております！私はCTOとして、メンドウで誰かやって欲しいなということを拾いまくったり、ちょっと口を挟んだり (笑、よい壁打ちになれるように努めます)、その他のサポート等をしますので、開発の本丸でグイグイやっていただける方を募集しております。