こんにちは、UPSIDERでエンジニアリングマネージャーを務めている小池です。
この記事は、UPSIDER Tech アドベントカレンダー 2025の12月17日公開の記事です。
UPSIDERのアドベントカレンダー2025 では、Tech・Corporate・Bizの3つに分かれて、それぞれのチームメンバーが日替わりでさまざまな内容をお届けします。
Techはこちら：
UPSIDER Tech Advent Calendar 2025 - Adventar
Corpはこちら：
UPSIDER Corp Advent Calendar 2025 - Adventar
Bizはこちら：
UPSIDER Biz Advent Calendar 2025 - Adventar
先日、VPoEの泉が「未来のFintechインフラはどうつくられるのか？──UPSIDERの技術戦略とプラットフォーム構想」という記事を公開しました。UPSIDERが「法人カードイシュアー」から「金融プラットフォーム」へと進化していく構想について書かれたものです。
本記事では、その構想を実現するためのマルチブランドを前提とした新たなシステムコンポーネントを開発する私たちSolarisチームの視点からより踏み込んで取り組みをお伝えします。
特に、不確実性の高い新規プラットフォーム開発において、どのような考え方で技術選定を行っているかという点に焦点を当てます。
プラットフォーム開発の難しさ：変化と曖昧さ
私たちは複数のカードブランドが共存できる新たなカードビジネスインフラを構築しています。マルチブランド対応は実際に開発を進めるとその抽象度の高さに直面します。
将来どのようなサービスが載るのか、それぞれどんな要件を持ってくるのか、現時点では完全には見通せません。協業先との対話を通じて要件が段階的に具体化していく性質があり、「将来何が必要になるかわからない」中で、今日の意思決定をしなければならない。これがプラットフォーム開発の難しさです。また、ブランドごとに個別実装で対応してしまえば、プラットフォームとしてのスケールメリットが失われます。
かといって、「わからないから決めない」では前に進めません。曖昧さを前提として受け入れながら、それでも意思決定していく。チームでは、そのための判断軸を共有しながら開発を進めています。
私たちの技術選定の考え方
技術選定において、私たちが大切にしている方針があります。
「変化に強い設計をしながら、今のコストを過大にしない」
将来の拡張性を考えれば、最初から堅牢で柔軟な構成を作り込みたくなります。しかし、それが今のチームにとって運用・学習・金銭面で過大な負担になるなら、持続可能ではありません。逆に、目先のコストだけを優先して将来の選択肢を狭めてしまうのも避けたい。
このバランスをどう取るか。私たちが意識している判断軸は2つあります。
将来の選択肢を狭めない
「今は使わないが、後で必要になるかもしれない」技術や構成に対して、移行パスを塞がない設計を心がけています。ただし、今から作り込みすぎることはしません。「必要になったときに移行できる状態」を維持することが重要です。やらないことを明確にする
技術選定では「何を選ぶか」と同じくらい「何を選ばないか」が重要です。過度な最適化、過度な抽象化は避ける。今の要件に対して十分かどうかで判断し、「将来必要になるかもしれない」だけでは採用理由にしない。
つまり「Just Use Postgres!」だった
技術選定の考え方を実際の意思決定に落とし込むと、Just Use Postgresに落ちついた例がいくつかありました。
Just Use Postgresについては最近読み応えたっぷりの読書感想文が上がっていたのでこちらもおすすめです。
「Postgres で試した？」と聞き返せるようになるまでもしくはなぜ私は雰囲気で技術を語るのか？ — Just use Postgres 読書感想文
データストアの選定
マルチテナントのプラットフォームとして、複数のテナントのデータを安全に分離して管理する必要があります。将来的なスケールにも対応したいが、初期フェーズのコストは抑えたい。 検討の結果、PostgreSQL（Cloud SQL）+ Row Level Security（RLS） を採用しました。
SpannerやAlloyDBも検討しましたが、現時点ではオーバースペックでした。またRLSによってデータベースレベルでテナント分離を強制できる安心感が決め手です。 ただし、将来的にAlloyDBが必要になる可能性は残しています。水平スケーリングが求められるフェーズが来たら、その時に移行を検討すればよい。今から作り込む必要はないと判断しました。
メタデータ検索機能の設計
任意のメタデータ（key-valueペア）を付与し、それを検索できる機能を追加しようという話になりました。 「検索機能」と聞くと、ElasticsearchやOpenSearchのような専用の検索エンジンを思い浮かべるかもしれません。実際、私たちも検討しました。 しかし、実際にどこまでビジネスニーズがあるのか不透明であり、キーの数などある程度の制約を課せばPostgreSQLのJSONB型 + GINインデックスで十分対応できると判断しました。 専用の検索エンジンを導入すれば、より高度な検索機能や高速なレスポンスが得られます。しかし、別クラスタの運用、データ同期の仕組み、権限制御の同期といった追加の複雑性が生まれます。今の要件に対して、それだけのコストを払う必要があるか。答えはNoでした。 もちろん、将来的にビジネス要件が変わり、複雑な集計やファセット検索が必要になれば、外部検索エンジンの併用を検討します。でも、それは「必要になったとき」の話です。
今のうちから作りこむものは何か
オーバーエンジニアリングを避ける話が続きましたがもちろん今のうちから作り込むものもあります。
例えば、複数のシステムコンポーネントを跨ぐデータ連携の信頼性については、これまで悩まされてきたからこそ丁寧にアーキテクチャ設計を行っています。
処理がロストしないか、安全にリトライできるか、データ不整合が発生しないか、不整合の発生を検知できるかといった観点から、PubSubが多用されていたり、idempotency keyが多くのAPIで提供されていたり、outboxパターンが部分的に採用されていたりします。
信頼性の高いメンテコストの低いシステムがであれば、後から機能を増やすことは難しくないという発想です。
おわりに
Solarisチームの取り組みは、UPSIDERが法人カード事業を「金融プラットフォーム」へと進化していくための第一歩です。まだ立ち上げフェーズであり、決まっていないことも多い。でも、だからこそ面白いフェーズだと思っています。 「将来の拡張性」と「今の現実」の間で意思決定していく経験。曖昧さを前提として受け入れながら、それでも前に進んでいく醍醐味。こうした環境を楽しめるエンジニアにとっては、非常にやりがいのあるチームだと自負しています。
この記事を読んで興味を持っていただけた方は、ぜひカジュアル面談でお話しさせてください。あなたと一緒に、この先の技術的な意思決定を重ねていけることを楽しみにしています。
We Are Hiring !!
株式会社UPSIDERでは現在積極採用をしています。 ぜひお気軽にご応募ください。
UPSIDER Engineering Deckはこちら📣
UPSIDERアドベントカレンダー2025
株式会社UPSIDERのメンバーがお届けする、#UPSIDERアドベントカレンダー2025。Biz・Tech・Corporate の3つに分かれて、それぞれのチームメンバーが日替わりでさまざまな内容をお届けします。内容は仕事に限らず、日々の学びや経験、好きなこと、趣味の話、ふと思ったこと など、自由に…！UPSIDERで働くメンバーの “素顔” が垣間見えるような、そんな企画になっています。気軽に読みながら、メンバーそれぞれの雰囲気を感じていただけたら嬉しいです。
