海外SaaSの日本ローンチで最初に壊れるのは、ユーザーテーブルだ
海外で動いているSaaSを日本に持ち込む。 プロダクトは完成しているのだから、あとは翻訳とローカライズだけ、と考えられがちだ。
実際にはそうならない。 止まるのはだいたい技術側で、しかも設計の深いところに当たる。
日本ローンチの前に潰しておくべき論点を並べる。
■ 名前と住所で、データモデルが壊れる
一番早く当たるのがここだ。
日本語の氏名は、文字列ひとつでは収まらない。
まず、フリガナが要る。 決済、配送、金融系の本人確認、そして多くの業務システムが、カナでの照合を前提にしている。 後から追加すると、既存ユーザー全員分をどうするかという問題になる。
次に、文字の範囲が広い。 全角の英数字。 半角カナ。 そして異体字だ。髙島の「髙」、山﨑の「﨑」。
これらは正規化するのか、そのまま保存するのか。 決めずに実装すると、検索が一致しない、帳票で文字化けする、といった形で後から出てくる。
データベースの文字コードも確認がいる。
MySQLで絵文字や一部の漢字を保存するには utf8mb4 が必要で、utf8 のままだと保存時に落ちる。
住所も同じだ。 都道府県、市区町村、番地、建物名。 海外の住所フォーマットにそのまま流し込むと、番地が入らない。
番地は数値ではなく文字列だ。 「1-2-3」もあれば「一丁目二番三号」もある。
■ 電話番号とメールは、届かないところから始まる
電話番号を E.164 形式で保存している場合、先頭の 0 の扱いを決める必要がある。
日本の番号は 0 で始まる。 国際形式にすると 0 が落ちる。 表示のときに戻し忘れると、ユーザーには自分の番号に見えない。
市外局番の桁数も一定ではない。 固定長を前提にしたバリデーションは通らない。
メールはもっと厄介だ。
キャリアメール（docomo、au、softbank）には、ドメイン指定受信が設定されていることがある。 送っても届かないが、送信側にはエラーが返らない。
SPF、DKIM、DMARC は最低限として、 届かなかったときにユーザーが自力で解決できる導線を用意しておく必要がある。
■ クレジットカードだけでは、決済が成立しない
日本の個人向けサービスでカードだけを用意すると、取りこぼす。
コンビニ払い。 銀行振込。 キャリア決済。 コード決済。
どこまで対応するかはターゲット次第だが、カード一本という前提は成り立たない。
法人向けはさらに違う。
日本のBtoBは請求書払いが基本だ。 月末締めの翌月末払い、といった支払サイトが前提になる。
つまり、与信をして、掛けで売って、請求書を出して、入金を消し込む。 この一連の流れがプロダクト側に必要になる。
サブスクリプションの課金基盤をカード決済前提で作っていると、ここが丸ごと足りない。
■ 請求書には登録番号が要る
2023年から日本ではインボイス制度が始まっている。
適格請求書には、発行事業者の登録番号、適用税率、税率ごとに区分した消費税額を記載する必要がある。
消費税は10%だが、飲食料品などには8%の軽減税率がある。 税率が2つある前提で設計されているかを確認する。
請求書のPDFを生成している場合、そのテンプレートが日本の要件を満たしていないことが多い。
■ 帳票は和暦と年度で来ることがある
企業や官公庁向けの場合、出力する帳票に和暦を求められることがある。 令和7年、といった表記だ。
改元があると変わるので、変換テーブルを外に出しておく。
そして年度だ。 日本の会計年度は4月から翌年3月。 集計や締めの単位がカレンダーイヤーになっていると、そのままでは使えない。
■ データの置き場所を、契約で聞かれる
技術要件というより、契約審査で出てくる論点だ。
まずレイテンシ。 東京リージョンに寄せるかどうかは、単に速度の話だけではない。
日本の企業、特に大手や官公庁向けでは、データがどこに保管されるかをセキュリティチェックシートで問われる。 海外リージョンのみという構成は、それだけで審査に時間がかかる。
個人情報保護法も見ておく。 個人データを海外に移転する場合、原則として本人の同意か、相当する措置が必要になる。 プライバシーポリシーと同意フローの設計に関わる。
電子帳簿保存法にも触れる可能性がある。 請求書や領収書を電子で扱うなら、保存要件を満たしているかを確認する。
法令の判断そのものは専門家の領域だが、 どの論点が技術設計に跳ね返るかは、事前に把握しておく必要がある。
■ 自分ならこう進める
順番がある。
最初にやるのは、データモデルの調査だ。 氏名、住所、電話番号、日付。 この4つが日本の要件を吸収できるかを、コードを見て確認する。
ここが駄目なら、他を進めても手戻りになる。 逆にここさえ通れば、残りは追加開発で対応できることが多い。
次に決済と請求。 ターゲットが法人なら、請求書払いに対応できるかが事実上の参入条件になる。
最後にデータ所在地と法令。 これは契約審査で止まる論点なので、営業が動き出す前に結論を出しておく。
翻訳とUIのローカライズは、最後でいい。 目に見える部分なので先にやりたくなるが、止まるのはいつも見えない部分だ。