
LIGが新サービス「door」をリリース! インフルエンサーへの拡散依頼が簡単に!
こんにちは、バックエンドエンジニアのグッチです。
2019年にもなったことだし、今日はWebサービスを作った思い出を振り返りながら、多言語・多通貨・複数国対応のバッドプラクティスについて書いてみようと思います。
Webサービス・アプリなどを仕事や趣味で作って(作ろうとして)いる方の参考になれば嬉しいです。実際に自分のサービスが全世界で使われるサービスになるかはさておき、いつか来るかもしれないその日に向けて、考えてみる機会にしていただけたら……。
▼最近のご飯
目次
日ごろWebサイト/サービス/アプリを使っていて、こーゆーの見たことありますよね?
何気なく使っているかもしれませんが、裏側では国際化(i18n: Internationalization)と呼ばれる仕組みを使って、エンジニアやデザイナーが頑張って書いているんです。
私は主にdoorというSNSマーケティングプラットフォームの開発を行なっています。SNS上でフォロワーを多く抱えるインフルエンサーと、宣伝して欲しい自社製品やイベントがある企業とをマッチングさせるサービスです。
スポンサー視点だと、
など、いろいろな種類の依頼が可能です。
またインフルエンサー視点だと、
といったメリットがあります。そのほか詳細は下記の記事をご覧ください。
LIGが新サービス「door」をリリース! インフルエンサーへの拡散依頼が簡単に!
構成はざっくりとこんな感じ。
スケジュールもけっこうキツキツだったので、優先度の低いところはリリース後の機能拡張で対応するということにして「とりあえず早く」をモットーに開発。
徐々にユーザー数も増えるのを横目でみつつ、UI/UX改善とほんとは欲しかった機能を並行して実装。このころはサービスの性質上、海外展開はしばらくないだろうと思っていました。
ところが、ある日偉い人から突然こう言われました。
「T国でこのサービス展開したい。英語にして」
そこで以下のような実装を行い、なんとかリリースしました。
が、国際情勢的なタイミングの問題でプレスリリースやCMを打ったりすることが難しく、口コミなどで少しユーザーは増えたものの、結局はほとんど動きませんでした(かなしいね)。
そして、またある日、
「V国でもやりたい。V語追加して」
「運営もV国側でやってくれるって!」
「V国側のパートナー企業のエンジニアも一緒に開発してくれるって!」
なんやかんやあって実装も終わり、リリースはできたものの……いろいろと大変でした。
リリース後に寄せられたけど重すぎて断念した意見もいろいろありました。
ここには書けないけど、その国の文化に根ざした意見の食い違いもありました。
各フェーズでの要件定義は満たせてはいるものの、将来的な要望までは手が回らず、大改修して作り直したい気持ちでいっぱいです。
世界中の人が自分のWebサービスにアクセスすることを想定する場合、表示上の注意点はなんでしょうか?
言語・時間などはパッと思いつきますね。
多くのフレームワークでよく見る多言語化(i18n)は「表示する言語を変える」という目的は満たせますが、実際にはもう少し考える必要がありました。
使用するフレームワークによって時間の取り扱いもi18nに含まれたり、含まれなかったりすることがあるので注意しなければなりません。また場合によってはi18nとl10n(localization:地域化)を併用する必要なども出てくるので気をつけましょう。
これは、「Webサービスがユーザーになにを提供したいか」によっても変わってきます。
表示する言語が違うだけというパターンの場合、同じコンテンツを出せばいいので素直に多言語化するだけですが、実際にはそうはいかない方が多いでしょう。
まず考えるとすればこれくらい。
コンテンツを出し分ける場合には、追加でいろいろ考える必要があります。
doorでは、
という形に落ち着きました。
多言語化(i18n)の際は言語を変えますが、Webサービスの多地域展開を考える上では言語ではなく国で整理した方がわかりやすくなります。
おそらくもっとたくさんあるんだとは思いますがdoorでハマったポイントを並べてみます。
言語によって決まるものって案外少なくて、実は国によって決まるものの方が多いんじゃないかなと思ってます。言語によらないデータまで言語に紐づけてしまうと、後から大変になるので注意しましょう。
最適化していい場所かどうか判断がつく前にシンプルに実装したことで後から泣きたくなる問題。
海外展開しないだろうと思ってHTMLに日本語書いたりするあれですね。
doorでは失敗したなぁと思うこともたくさんありますが、多言語化まわりで思うのは「国・言語・通貨を1:1:1という関係性にしてしまった」ことかもしれません。
これは当時の開発メンバーも社内の誰もが気づかずに進んだため、「英語圏の人が日本版で英語を使う」といったことができなくなりました。今からそこを変えるのは重いので、ずっと保留になっています。
ほかにも気になるところはあるので綺麗にしたいなぁ。
将来のためを考えてそのための拡張性を保って実装したせいで、日々の実装が大変になったりメンテナンス性が悪くなることがある問題。
当初、「同一アカウントでスポンサー側にもインフルエンサー側にもなれ、スポンサーには複数のユーザーが所属し、ひとりのユーザーが複数のスポンサーに所属できる」ような構造にするという設計でした。
しかし、ビジネスロジック側の理由から大きな機能変更が入り、その辺をだいぶ簡略化して実装することになりました。
「でも将来的には当初の構造にしたいよね」という声も多く、データ構造的には当初の実装が可能な形を維持しつつ、簡略化された方法で実装しました。ユーザー周りのアソシエーションが複雑になったり、deviseでのユーザーの管理が複雑になり普段の実装がほんの少しめんどくさくなりましたが、「将来のために」と思ってそのまま頑張りました。
時間がたち、当初の仕様へアップグレードするという夢は今さら手をつけるには負荷が大きすぎる状態になり、実現するにはかなりめんどくさ……難しいタスクと言わざるを得ない状況です。
拡張性を高くしようと思ったことで、かえって不幸になることもあります。何事も適度なバランスが大切ですね。
結局のところ、どんなに綿密に練った要件で実装してもビジネス上の理由やその他なんやかんやの理由で「え、今それ言うの?? あのときこうしておけば。。。」となることは避けられないことかもしれません。日々それなりに頑張っていくしかないですね。
早すぎる最適化と早すぎる拡張性の確保の間で、バランスをとりながら生きていきましょう。グッチでした。