2025/10/07

グローバル展開にむけたアプリと基盤の再構築

Author:: deeeet

, 2025/10/07

Cross Border (XB) Engineeringの @deeeeeeeeeet です．

先日の事業戦略発表会において共有しましたが，今後更にメルカリの海外展開を加速させるためにグローバル版のメルカリアプリを先日リリースしました．

このアプリは現在提供してる日本版・アメリカ版のメルカリとは異なる新しいアプリであり，またアプリだけではなくその裏側のバックエンド基盤も新たに再構築しています．本記事では，エンジニアリングの観点からメルカリグローバルアプリ（以下、グローバルアプリ）とその基盤の戦略やアーキテクチャーをこれまでのメルカリの挑戦から得られた学びを振り返りつつ紹介します．

メルカリにおける越境取引

「メルカリ」に出品したことがあるみなさんの中には，自分の商品が一般のお客さまではなく事業者によって「代理購入」された経験がある方もいらっしゃるかもしれません．これは，海外のお客さまが日本の「メルカリ」に出品されている商品を購入できる越境 (Cross-Border, XB) 取引という仕組みによるものです．

メルカリにおける越境取引は代理購入パートナーとの連携によって実現されています．海外のお客さまは，まず提携パートナーのWebサイト上で「メルカリ」の商品を注文します．すると，パートナーが購入代行者として「メルカリ」上で商品を購入し，支払い手続きを行います．国内の出品者は，この代理購入者であるパートナーの指定する日本の倉庫へ，通常の国内取引と同じように商品を発送します．商品が倉庫に到着後，パートナーが検品や海外向けの梱包を行い，海外のお客さまの元へ国際発送するという流れで実現されています．

この仕組みは，海外と国内のお客さまの双方にメリットがあります．海外のお客さまにとっては，言語の壁や通貨の違いを気にすることなく，日本のユニークな商品を手軽に購入できます．一方で，国内のお客さまにとっては，海外のお客さまとの直接的なコミュニケーションや国際発送といった複雑な手続きは一切不要で，国内取引と同じように販売の機会を世界中に広げることができます．

越境取引事業は2019年に始まり，近年さらに成長しており, GMVとしては過去3年で15倍に成長しています．特に，アニメ，コミック，ゲーム，エンタメ関連グッズのカテゴリーが取引全体の多くを占めており海外のお客さまからの強い需要があります．

このような強い需要と成長を顧みて，代理購入パートナーのサイトを通じた仕組みに加え，日本のメルカリのWebサービスを通じて代理購入を可能にする取り組みも開始しました．この仕組みにより，海外のお客さまは直接「メルカリ」上でアカウントを作成し，「メルカリ」が提供する体験を通じて商品の検索と購入を行うことが可能になりました (引き続きパートナー企業を間に挟む形式は継続しています)．この取り組みは2024年にリリースし, 現在台湾と香港から利用可能で利用者数を伸ばしています．

こうして越境取引事業は順調に成長してきましたが，同時にいくつかの重要な課題も見えてきました．以下で説明するように既存の日本のシステムは日本市場に特化して作られており，単一通貨・単一言語を前提とした設計になっています．越境取引機能はこの上に追加的に実装したため，複数国への展開や各国固有の商習慣への対応を実現していくには限界がありました．特にアジア市場ではEC利用の多くがモバイル経由という状況において，Web版のみの提供では競争力に欠けるという問題もありました．

このような課題を抱えながらも，海外市場からの需要は確実に存在しており，特にアニメ・ゲーム関連商品への関心は非常に高いことがわかっています．現在は台湾と香港の2か所のみですが，東南アジアや欧米にも同様の潜在的な需要があることは明らかでした．この機会を最大限に活かすためにはより早く展開国を拡大していく新たなアプローチが必要でした．

そこで私たちは，単に既存システムを拡張するのではなく，グローバル展開を前提とした新たなアプリケーションとその基盤を構築するという決断に至りました．これは越境取引から始めて，将来的には各国でのローカルマーケットプレイスの立ち上げ，そして最終的には国境を越えたグローバルなマーケットプレイスの実現を見据えた戦略的な判断でした．

海外展開のアプローチ

グローバルなマーケットプレイスの実現は，メルカリ創業当時からのビジョンであり，海外展開への挑戦は今回が初めてではありません．これまでにもアメリカでの事業展開に挑戦し，現在もその成長に注力しています．過去にはイギリスへの展開を試みた経験もあります．

これまでの海外展開では，それぞれの国において，日本と同様のローカルなC2Cマーケットプレイスをゼロから立ち上げるというアプローチを取ってきました．しかし，今回のグローバル展開は越境取引の成功と課題から学んだ新たなアプローチを取っています．日本から海外へ商品を届ける「越境取引」を事業の軸に据え，そこで構築した顧客基盤を活かしながら段階的にサービスを拡大していく戦略です．また展開エリアも3年以内に50カ国と地域を目指しており，スピード感も従来とは大きく異なります．これは日本のお客さまや事業者に出品していただいたユニークで豊富な商品を世界中に届けることを起点とし，そこから更なる可能性を模索していく戦略への転換を意味しています．

この事業戦略の転換によりエンジニアリング戦略も大きく変えました．

これまでの日本とアメリカ，そしてイギリスへの展開はそれぞれ独立した異なるシステムにより実現してきました．もちろん当初は共通のコードベースを各国にデプロイする方式 (ただしデータは分離) を取っていました．しかし，日本向けに作られたシステムを各国の事情に対応させていくことによるコードベースの複雑化 (e.g., 国のスイッチのためのif文が多くの場所で書かれることになった) や，国間での方針のアラインが必要であるために各国の意思決定のスピードの低下といった課題にぶつかりました. 最終的にはフォークを決定し，それぞれ独立したシステムとなり，開発運用の体制も分離していくことになりました．アメリカはその後アプリ自体も現地のUI/UXに合わせて刷新を行い，独自の機能をその上に実装していくことになり，日本とアメリカのシステムは今日でも分離されています．

この方法は，迅速に事業を立ち上げ，各国の市場に深く最適化できる点では有効なアプローチでした．各国の事業をそれぞれで伸ばしていくために独立した組織作りとシステムを開発していくのも重要だったと思います．一方でより長期的な視点に立ったときに以下のような課題があり，次の展開へと繋げることが困難になっていました．

展開のコストとスピード: 展開国を増やすという観点での共通の基盤の整備はできておらず，次の国を考えたときに新たなアプリケーションとバックエンド基盤を構築し直すこと，もしくは既存のシステムの大規模な改修を考える必要がある．
開発リソースの非効率性: 同じような機能がそれぞれの国で個別に実装され，各基盤に専任のチームが必要となるため，開発リソースの重複や運用の非効率性が発生する．

現状の「越境取引」自体は既存の日本のシステム上に構築できています．しかし，以下でより詳しく述べるように既存のシステムは複雑化しており，今後のより高速に展開国を増やしていく，グローバルに向けたより良いUI/UXの提供を行っていくのは限界がきていました．そして「越境取引」の次，例えば新たな国でローカルのマーケットプレイスを展開するといったことに繋げることは非常に困難です．

このような課題を根本的に解決し，そして「越境取引」を中心とした新たな海外展開を効率的に加速させるためには新たな戦略が必要でした．そこで「国や地域ごとに個別のシステムを構築するのではなく，単一のグローバルな基盤で全ての国や地域をサポートする」という新たなビジョンを打ち立てその基盤の開発を始めました．

グローバル基盤の開発戦略

この単一のグローバル基盤の開発の戦略にはいくつかのアプローチが考えられますが「拡張と再構築のハイブリッドなアプローチ」を選択しています．このアプローチに至った背景をこれまでのメルカリのバックエンドシステムの変遷から説明します．

メルカリのバックエンドシステムの変遷

メルカリのバックエンドシステムはMonolithアーキテクチャ (単一コードベースに全ての機能を実装する方式) として始まっています．アメリカ事業やイギリス事業を開始するときにフォークという選択肢をとることができたのはこのためです (それぞれの国のスケールを支えるために裏側のインフラやツールとして多くの仕組みがありそれらを複製するのは容易ではなかったはずですが)．

2017年あたりから特に日本の組織の規模は急激に拡大を始めます．組織の拡大により単一の巨大なコードベースに多くの人が同時に開発を行うことが困難になり，また一部の機能のバグでサービス全体に障害が波及する事も多く発生しました．加えてほとんどのシステムがオンプレ上に構築されており，その運用や拡張がボトルネックになっていました．このような問題を解決するためにMicroservicesアーキテクチャ移行とクラウド移行 (それに伴うDevOps化への移行) を開始します．私自身が入社したのはこの直前で，移行プロジェクトの推進とMicroservices開発の基盤やツールを整えるPlatform Engineeringチームの立ち上げと拡大を担ってきました．

Microservicesアーキテクチャ移行のアプローチとしてはStranglerパターンを採用しました．これは既存のシステムの前段にGatewayを置き，そのGatewayを軸にトラフィックを徐々に新しいシステムに移行していくという方針です．より具体的には，(1) 既存システムに実装されている機能群をMicroservicesとして切り出し (2) Gatewayからその機能の利用トラフィックを徐々にMicroservices側に流す，を繰り返すことで段階的に新システムに移行していくアプローチです．移行開始から数年が経過しましたが，多くの機能をMonolithから切り出し，またその上で新しい機能を開発してきました．またほぼ全てのサービスのクラウド移行も完了しています (サービス数でいうと100を超えています)．

Microservices化以降では日本ではメインとなるC2Cマーケットプレイス事業に加えて複数の新規事業の立ち上げが始まることになります．フィンテック事業のメルペイ，暗号資産のメルコイン，B2C事業のメルカリShops，そしてスキマバイトサービス事業のメルカリハロです．メルペイはメルカリの決済システムを切り出しており，MicroservicesアーキテクチャとしてC2Cと同じインフラ基盤上に構築しています．メルコインはセキュリティのためにインフラは大きく分離していますが，基本的には同様のアーキテクチャパターンで開発しています．ShopsはMicroservicesアーキテクチャですがC2Cとは切り離した独立したシステムになっています (モバイルアプリとしては一つですが，裏側のバックエンドは分離しています)．

この数年に渡るMicroservices移行と複数事業の立ち上げに合わせて推進してきたのは共通基盤の整備です．自分がリードしてきたPlatform Engineeringのレイヤーとしての開発基盤やツールだけではなく，ID基盤や決済基盤，マーケティング基盤のような複数事業にまたがって利用できる基盤も開発してきました．これらが創業以来メルカリのバックエンドシステムの変遷です．

既存システムの課題

2025年の現在，既存のシステムを俯瞰したときにいくつかの構造的な課題を抱えています．

最も大きな問題は，C2Cマーケットプレイスとして重要な機能がMonolith基盤に残っているという点です．Stranglerパターンとしていくつかの機能をMicroserviceとして抜き出すことはできてはいますが，この方式はProxy的に上物の機能を抜き出すに止まりデータ移行まで進まなかった部分も多くあります．特に「トランザクション管理」「配送」といった機能をMonolithとそのDBから抜き出すことができていません．これらはロジックとして密結合が強くうまく分離を進められなかったというのも大きな理由です．そのためMonolithへの強い依存が未だに残っています．この部分は今でも多くの開発と変更が必要な一方で複雑なコードベース上に残ってるために，日本事業の継続的な改善においても早急な対処が必要です．Microservices移行の初期から関わってきた人間としては，この重要部に初期から挑まなかったのは大きな反省です．

グローバル展開を見据えてもこれは大きな課題になります．Monolithに残るトランザクション管理と配送システムは日本市場に特化した設計になっています．トランザクション管理は日本円のみを前提としており，複数通貨での取引，為替処理，各国異なる税制への対応を追加することは非常にコストは高いです．配送システムも日本国内の配送業者のシステムと密結合しており，各国のローカル配送業者，異なる配送オプションへの対応は根本的な作り直しなしには実現は難しくなっていました．

また，C2CマーケットプレイスとB2C Shopsのシステム乖離問題があります．現状は別々のトランザクション，配送システムをそれぞれが持っているだけでなく，プロダクトの管理も分かれており，結果として日本のお客さまに対しても統一的な体験を提供できていません．これは，もともとのビジョンとして独立したサービスが考慮されていたこと，方向性が変わり統合しようと思っても上のMonolith問題により実行が難しかったことが原因として挙げられます．

Microservicesアーキテクチャ自体にも課題があります．各サービスのオーナーシップと自由度を重視し，サービス間で十分な抽象化を行えていなかったこと，適切なドメイン分離を行えておらず分割の単位も非常に小さくしてしまったことが原因で，多くの小さな，作り方が微妙に異なるMicroservicesが数多く構築されてしまいました．このためMicroservicesの運用のコストが非常に高くなってしまっています．メルカリはスピード感を持って物事を進めるため組織変更も頻繁に行いますが，そのたびにMicroservicesのオーナーシップの移管が必要になり，実装の差異によりオンボードのコストも高くなっています．

これらの制約により，既存システムの延長線上でグローバル展開を進めることは，技術的にもビジネス的にも限界があることが明確になりました．

グローバル基盤の方向性

このような変遷と現状の課題をベースにグローバル基盤の開発方針としていくつかのアプローチを考慮しました．まず，過去のアメリカ展開のようにフォークという選択肢を取ることは非常に難しくなっています．Microservices化された多くのシステムを複製していくのは現実的ではありません．全てをゼロから再構築することも考えましたが，これもコストと効率の観点から選択肢から外しました．結論として「既存のシステムの拡張と再構築のハイブリッドなアプローチ」を選択しています．

このアプローチでは，どこまでを拡張とし，どこまでを再構築するか? のラインを決めるのが重要でした．既存のシステムの多くは日本の市場に特化したものになっており，また多くのサービスがMicroservices化されています．それら全てを拡張していくのは現実的ではありませんし，日本事業は引き続き重要であるため，グローバル展開はそこから独立して進められることも重要でした．また未だ残るMonolithにグローバルから依存することも避けたいという強い気持ちもありました．

「拡張」としては複数事業の立ち上げとともに発展した共通基盤を主に活用することにしました．特に強い専門性が求められる，そして拡張性を考慮して設計されてるサービスを選定しています．以下で詳しく述べますがMicroservicesからの脱却も同時に考えており，小さな細かなサービスには依存するのではなく，十分な大きさかつ独立した「ドメイン」(SaaSとして置き換えられるレベル) に依存することも決めました．この基準により，例えば，ID基盤はグローバルで共通に，また決済基盤はメルペイ基盤を通じてStripeに接続しグローバルの通貨やローカルの決済手段に対応していく，といったことを進めています．他にも検索基盤，マーケティング基盤なども既存のシステムを拡張することで活用しています．

それ以外の部分は「再構築」の選択肢をとっています．特に上述したC2Cサービスとしての「トランザクション管理」「配送」「アイテム・プロダクト管理」は作り直すしかありませんでした．日本と同じ問題を避けるために，(1) それぞれを疎に長期的な拡張性を容易にする (2) CとBの商品を同等に扱い，統一したUI/UXを提供することができることを考慮し，また複数カ国展開や別の国において新たなローカルマーケットプレイスを実現できるようにするために (3) 各国の通貨，言語，税制・関税，法規制に柔軟に対応できる (複数であることを前提にする．以下のTenetsを参照) (4) 日本以外の国の商品や配送手段を扱うことになっても対応できるようにする，を前提として構築しています．

また単に作り直すだけではまた新たな別基盤が誕生するだけです．初期はグローバルでの成功をメインとしつつも，最終的には日本のC2CとB2Cの基盤も置き換えていく，という想定で動き始めています (実際にリリースまで達成したのでこの基盤を日本でも活用していくためのプロジェクトを始動しています)．

モバイルアプリとWebに関してもグローバルでは異なるUI/UXは必須なので作り直しの選択になっています．加えてバックエンドを刷新することでAPI自体も切り替えることもでき，実装自体もより良くできます．

MicroservicesからModular Monolithへ

上述したMicroservicesアーキテクチャの抱える課題に取り組むため「再構築」したバックエンド基盤はModular monolithアーキテクチャとして開発しています．

Microservicesの課題

メルカリにおいてMicroservicesアーキテクチャの運用コストが高くなってしまった大きな理由は，各サービスの開発の自由度を高めてしまったところにあります．サーバー実装はGoで，データベースとしてSpanner/CloudSQL (MySQL)，インフラとしてKubernetesを利用する，という最低限の技術スタックの統一は進めてきました．一方で，レポジトリ戦略はPolyrepo (1サービス = 1 GitHub レポジトリ)として，基準となるテンプレートや最低限の共通ライブラリはあれど，レポジトリの構成や実装方針は各チームに委ねる形になっていました．そのため，マクロで見ると同じGoのMicroservicesですが，ミクロでみるとかなり異なるサービスが量産されました．一つ一つのサービスの運用のコストは小さくても，異なるサービスを複数面倒見る必要があるとその差異により共通化ができず，コストが高くなるということが起こっています．

これに加えてメルカリはとにかくスピード感を持って物事を進め方向性を転換していくため組織変更も頻繁に行います．そのためMicroservicesのオーナーシップの移管も頻繁に行う必要があります．移管のたびにオンボードが必要ですが実装の差異によりそのコストも高くなります．また共通化を進めるのも難しいです．

また特にMonolithから移行を進めたC2C側はドメインの適切な分離ができていないところも多く，サービスの凝集度が低いところが多くあります．これにより機能追加のために複数のサービス，チームに跨った変更が必要になり，コミュニケーションコストの増大にも繋がっています．サービスごとのオーナーシップを強化するという方向性は逆に外からの変更を受け入れにくくするということにも繋がっています．

このような課題に対して上手くMicroservicesアーキテクチャによる実装を進めたのがメルカリShopsによるMonorepoを使ったアプローチです．この方式ではShopsに関わる全てのMicroservicesを1つのRepoにまとめ，サービス間の実装を抽象化・統一化するということを実現しており，複数サービスによる運用のコストを削減しています．開発体験としてはMonolith的に，裏ではサービスが分離されてデプロイされる(これにより耐障害性のメリットを得られる)，という両方の良い部分を取り入れることができています．

一方でこのアプローチであっても課題はあります．こうしたMonorepoのためのインフラや自動化の仕組みを管理維持していくのは非常にコストが高いです (既存のPlatformと大きく分けて構築されたため共通基盤チームとの連携が難しくなっていたことも原因として挙げられます)．そもそもMicroservicesのテスト，デプロイ，開発環境の構築は複雑にならざるを得ません．例えばテスト環境は全部のサービスをPRごとに複製するという富豪的なアプローチをとっています．またサービスごとにDBを分けるなどを厳密に行なっており，インフラのコストも高くなってしまっています．

Modular Monolith

このような背景もあり，新しい基盤の構築にはModular monolithアーキテクチャーを選択しています．単なるModular monolithではなく特定のModuleを必要とあらば独立してデプロイ可能な形にしています (Service Weaverのコンセプトに近い)．

初期のメルカリのMonolithでは適切なドメイン分離・モジュール分離ができなかったためにコードの密結合とそれによる複雑化が発生したと思っています．サービスの境界，依存関係をモジュールごとに明確に整理することで同様の問題に当たらないようにしています．Microservicesのように細かく分離しすぎることで複雑になるのを避け，十分に機能が凝縮されたモジュールを作るようにしています．また必要なときに独立したデプロイを可能にすることでMicroservices的な耐障害性の利点も可能にしています．

初期の開発フェーズでは人数も多くないので基本は特定のモジュールにオーナーシップを限定することはしていません (もちろん特定の領域に強い人はいる)．皆がコードベース全体にオーナーシップを持ってもらうようにしています．これにより，プロダクト開発の優先度によってモジュールのアサインが動的に決まり，Microservicesで発生した無駄なコミュニケーション調整コストをなくしています．一方で，今後組織が拡大したとしても，モジュール単位でのアサインは可能であり，かつてのMonolithでハマった問題も解決できる余地もあります．

Monolithであることで，ワンバイナリによるローカル開発環境の構築は容易になり，またテストやデプロイもシンプルになり，Microservicesによって生じていた開発負荷もなくすことでより良い開発体験を作れています．インフラやCI/CD基盤もPlatform Engineeringチームが提供するものをそのまま使うことができ，ShopsのMonorepoアプローチで陥った基盤運用コストを抑えることができています (より詳細は次のポストで @yanolabより紹介します)．

一方でこの方針は組織全体の中では新しく，既存のMicroservicesアプローチとどう共存していくかという課題があります．現実的に一度分離したMicroservicesを全てMonolithへと戻していくことは簡単ではありません．そのためMicroservices自体は今後も残ることになると思います．Microservices開発と運用のコストを減らしていくために，サービスの分割単位をより適切なレベルに合わせていくことや，さらに言えばShopsで実現したようなMonorepoアプローチによる統一化を高めていくことが重要だと思っています．そして将来的な新規事業でこれからMicroservicesアーキテクチャーを初手で選択することは，特別な理由がない限りは，しない方がいいと思っています．このグローバル基盤のModular monolith構築パターンを横に展開し，実装パターンを共通化していくことも考えています．

技術スタック

以下はこの基盤の構築に利用している技術スタックの一覧になります．基本的にはメルカリがこれまで培ってきたスタックを前提に大きく変えないでそれらをうまく活用するようにしています．

インフラ: 引き続きメインのクラウドにはGoogle Cloudを採用しています．メインのリージョンは東京を使っていますが，将来的には(特にパフォーマンスの観点から) 別のリージョンを利用する可能性も考慮しています．アプリケーションの実行基盤にはPlatform Engineeringチームが管理するKubernetes (GKE) を利用しています．
データベース: データベースにはAlloyDBを選択しました．これまではメルペイを中心にSpannerを選定してきましたが， (1) 長期的な展開を考慮した時にGoogle Cloud 全てで担えない可能性も考慮し，なるべくロックインを避けること (2) PostgreSQLによるより良い開発体験エコシステムを利用すること，を考慮してAlloyDBを選定しました．他にもCockroachDBも考えており，今後の展開によっては乗り換えも考慮する可能性があります
言語・フレームワーク: サーバーはGo，iOSはSwift，AndroidはKotlin，WebはNext.js (TypeScript)としています．ここは大きく変えていません
Monorepo: より詳細は別のブログがこのあと書かれますが，iOS, Android，Webはそれぞれ日本のサービスのレポジトリをMonorepoとして拡張することで開発されています．日本とグローバルで共有可能なモジュールを切り出し，CI/CDを共通化することで，開発と運用の効率化をしています．

Tenets

この新たな基盤とアプリの開発には日本のみではなくインド拠点のメンバーを含めて多くが参加しています．さまざまな背景のメンバーが参加しても，これまで上で紹介してきたような方向性を実現するには，皆が同等の指針にしたがって意思決定を行えることが重要です．

これを実現するために「Global Engineering Tenets」を策定しました．TenetsはAmazonのTenets: supercharging decision-makingを参考にしています．

主なTenetsをいくつか紹介します:

Design for two: ソフトウェア開発においてある機能のサポートを1から2に増やすよりも，2から3に増やす方が容易であることは実感としてわかると思います．例えば，アプリケーションが既に2つの言語をサポートしている場合，3つ目の言語を追加するのは簡単です．一方、アプリケーションが1つの言語しかサポートしていない場合、2つ目の言語を追加するにはi18nの仕組みなど多くの準備が必要になります．これはグローバル展開においても同様のことが言えます．既に複数国・地域に対応している基盤に新規の地域や国を追加するのは、単一地域/国向けのアプリケーションを拡張するよりもはるかに容易です．機能やシステム設計においては常に2カ国・地域以上を想定するようにしています．
Global by default but enable localization: グローバル利用に向けたシステム開発を進める一方で，単に複数国へ事業を拡大するだけでなく，主要市場ではローカライゼーション施策を実施します．そのため，システムは複数の国々へ迅速かつ容易に拡張できつつ，かつ特定の国の要件をサポートする柔軟性も考慮する必要があります．長期的にはローカライゼーションのため現地にエンジニアリングチームを設置する可能性もあり，彼らが独立してローカライズ機能を開発できるようにする必要があります．
Learn and unlearn from the past experience: 今回新規で「再構築」する部分が多くあります．ただし，これは完全に新規であるべきではなく，上で紹介したような過去の学びを重要な資産として活用するべきです．自分は概要を説明しましたが，それぞれの領域，モバイル開発，Web開発，プロダクト開発などさまざまな領域で見直すべき課題があります．新しく採用したメンバーに関してもこれらの活用は強くお願いしました．
Keep each country’s business isolated: 既存の基盤やプラットフォームを活用する場合でも、相互に影響を与えないようにすべきです．例えば，グローバルで発生したバグやインシデントが日本の事業に影響を与えたり，その逆が生じることを避ける必要があります．

これらはデザインドキュメントを書く時など多くの場面で指針として利用されています (特にDesign for Twoは各所で言われた)．もちろん，多くの人が参加してる，長期的なプロジェクト、である以上は細かな部分ではズレは発生していますが，大きな方向性としては皆が同じ方向を向けたのではないかと思っています．

今後の展望

今回のリリースでは基本となる機能の実装が完了した状態です．今後はこの上に越境取引にとって重要になる機能，例えば事業者商品の予約販売機能や鑑定機能，などを実装しつつ，展開国をどんどん増やしていくことを目標としています．横展開だけではなく，特定の国へのローカライズとグロースを行っていく必要もあり，さらに基盤を活用していくフェーズになります．また上で紹介したように基盤自体は日本でも使えることを想定しており，その置き換えのプロジェクトも始めています．これによりこれまで抱えていた技術的な負債も同時に返済していくことを考えています．