はじめに
世の中の多言語対応してるWebサービスは
- パターン１：ここ最近のインバウンドのニーズを踏まえて最近立ち上げた
- なのでサービスローンチして1,2年程度
- パターン２：最初に日本語版を始めていた。サービス継続してく中で、多言語対応の親和性がありそうで横展開を狙い、結果、対応言語が増えた
という形なのかなと推測してます。
自分が関わっているお店の予約代行をするようなサービスで、上記の自分の分類でいうと、パターン２になります。
どういう形で対応したのか大まかに書くと
- 日本語版を開始
- その後、英語版を追加
- 英語版をベースに外部の機械翻訳のサービス（ググるととすぐに出てくる割と著名なやつ）を使って中国語版対応
- 機械翻訳の文章は違和感あり翻訳データーを環理できる管理機能を作った上で、多言語対応（日本語、英語、中国語の3言語）
という形でちょっとづつ多言語対応してきてます。
自分は、上記の３の頃から開発に関わってますが、当初から多言語対応をするという前提ではないため
- Webアプリケーション含めてサービス全体の設計として当初のターゲットユーザーの言語設定がベースにになってる
- ある意味後付で多言語対応なので、システム含めてトータルで色々考えないといけない
という形で、色々苦労しているので、そこでの学びとして以下の2つについて簡単にまとめようと思います。
- 多言語対応に伴い電話番号の仕様再検討
- 全ての機能について多言語対応を最初から全部行うとは限らない
多言語対応に伴い電話番号の仕様再検討
サービス利用する申請フォームでユーザーさんに電話番号を入力いただくようになってます。
※ 予約代行というようなサービスの特性上、こちらからユーザーさんに連絡を取りたい状況が発生するために、入力いただいてます。
当初は日本人だけだったので、仕様はシンプルだった
日本人を当初ターゲットにしていた時は、そんなに深く考えることなく
- 携帯電話
- 固定電話
のいづれかを入力してもらうだけでOKでした。
多言語対応すると考慮ポイントが増える
ここからが今回のテーマに関連する話題なのですが、多言語対応によって、電話番号についての仕様が途端に難しくなりました。
具体的には
- 日本人以外のユーザーさんの場合、申込時に入力いただく必要があるのは 日本に滞在中に連絡がとれる連絡先 である必要があります。
- 相手の電話番号がわかっても その人がどこの国の人 か判別できないと、こちらから連絡取れないため、国番号を入力いただく
というあたりです。
国番号が必要になる理由
Softbankのサイトから関連する情報をちょっと引用します
日本から海外事業者の携帯電話・一般電話へ電話をかけた場合は、「国際電話」の扱いになります。 Softbankのサポートページより
自国で所有してる携帯電話を滞在先の日本でも利用するケースがほとんどだと思うのですが、そういう人に対して、こちらから連絡を取る時には
国番号＋携帯電話の番号
で発信しないと、電話がつながらないため、画面上では、セレクトボックスで出身国を選択していただき、実際の値は、出身国に紐づく国番号が登録されるようにすることでこの問題を解決しました。
全ての機能について多言語対応を最初から全部行うとは限らない
冒頭のパターン２のケースの場合についていうと、最初から全部を多言語対応するのは現実的に難しいと思います。
理由としては開発に関わるエンジニアのリソースが足りないのもあるのですが、全ての取引先が多言語対応の業務ができる体制になってない or その体制作るのに凄く時間かかるということも考慮しないといけないためそのあたりが大きな要因になります。
最初は限定して、その後に増やすというアプローチになるかと思い実際、自分のケースでも
- Webサービス側の翻訳が全部対応しきれない
- お店の予約代行という特性上、お店側の事情で対応出来ない
というようなことがあり、ちょっとすつ多言語対応していくという形になりました。
ちょっとづつ多言語対応は意外とやっかい
システム開発の観点で
- toC向け
- 管理機能
- 多言語対応のための管理機能はどこまで作り込まれてないといけないのか？
- 英語の情報をベースに中国語に翻訳していく業務フローだったので、中国語版で、部分的に英語の情報が混じっていても許容できる仕様にしてよいか
- 多言語対応のための管理機能はどこまで作り込まれてないといけないのか？
というような点について、どういう仕様なら現実的なのかを考慮しないといけませんでした。
実際の業務を考慮しつつ、プロトタイプとなる機能を作る→試してもらう→問題点ありそうなら改修→再度チェック・・・という繰り返しをしながら対応していきました。
事前には想像出来なかった追加仕様も出た
3言語の対応をできるように開発を進めていたのですが、取引先は3言語全て使うものだと思いこんでいたのですが、取引先によっては
「折角なのでこれを機会に、xx の言語だけにしたい」 「出来れば、xxと○○の2言語だけにしたい」
など地味に細かい要望が出てきました。
今となってはそのあたりの背景は理解できるのですが、作ってる当初は当然ながらそんなことは想像出来ず、当初作っていた処理を見直すことになりました。
その追加仕様に対応できる構造にしていおいたことで、柔軟な運用ができるようになったので、結果的に良かったのかなぁと思います。
どうしても非効率なことが出るのは仕方ない
上記アプローチだと翻訳する人はシステム開発が終わるまで何も出来なくなります。
そのため並行して翻訳対象データーをGoogleスプレッドシートに登録＆翻訳データー作る作業をしていたのですが
- 翻訳データは、実際のDBの構造を反映した形になってなかった
- そのため、機能開発終わったら、１つづつデーターをコピペする形になった
という感じで、今思うともう少し効率的なやり方があったのかなと思います。
最後に
企画段階では他の要望（例：言語ごとにページのレイアウトを変更したい等）があったのですが、社内・社外の各種事情を考慮しながら、実現可能なものから多言語対応着手するのを考えるのは、今振り返っても難しい問題だなと改めて思います。
