c5n's i18n

Webサービスの多言語化について書いています。

フリーランスエンジニアになってからの2か月を振り返る

会社を辞めてフリーランスになってから約2か月が経ちました。

キリの良いタイミングというわけではないのですが、なんとなく今の生活にも慣れてきたような気がしますので一度ここまでを振り返ってみたいと思います。

これからフリーランスをやってみたいけどなんとなくイメージがつかないなー、という方(つまり3か月前の僕)へ、何かのお役にたてれば。

フリーランスになるまで

はじめに、僕がフリーランスになろうと思ってから実際になるまでを振り返ってみようと思います。

がんばっていろいろアウトプットしてみた

僕がフリーランスになろうと考え始めたのは去年の夏くらいでした。言い方を変えると、フリーランスになると決めてから1年近くを準備期間として使っていた、ということになります。

その1年間は、とにかく外に向けて「これをやったよ!」が言えるようにアウトプットすることを意識していました。具体的には、Qiitaに記事を書いてみたり、Twitterしてみたり、自分で書いたちょっとしたソースコードGithubに上げてみたり、といった具合です。

それをすればフリーランスでもやっていける、というよりは、それができてやっとフリーランスのスタート地点に立てる、という感覚でした。

フリーランスになると、多くの場合仕事を得るために自分のことを全く知らない人に対して自分に価値を見出してもらう必要が出てきます。 つまり、自分が前の会社でどれだけ頑張ったとか、どんな製品を作ったとか、どんな人脈があったとか、そんなことは全く関係のない人に対し、「自分のスキルにはこれだけの価値があります」と言えなければなりません。そんな時に最低限の説明材料として必要になるのが、所属する会社に関係なく価値のある情報を、インターネットを通して誰でも見ることができる場所に公開されていることだと考えました。

いろいろやってみた結果、たとえばQiitaでは37記事を投稿して1294コントリビューションを得ることができ、フォロワーも49人まで増やすことができました。(2017/7/25現在) 周りを見渡すと決して多い数字ではありませんが、1年前に全くのゼロからスタートしたことを振り返ると、自分としては珍しくコツコツと積み重ねられたものだなと思います。(もともと飽きっぽい性格です)

詳しくは後述しますが、結果としてこれをすることで得ることができた知識や実績、自信などが役に立ち(かどうかはわかりませんが)、フリーランスになった後もすんなりと当面の仕事を確保することができました。

フリーランスについて調べてみた

また同時に、この期間にフリーランスの情報をネットで調べてみたりしました。 が、こちらは今振り返ってみるとあまり役に立たなかった印象です。

そもそもフリーランスエンジニアといってもスキルの低い人から高い人、仲介サイト経由で仕事を請ける人から自分で仕事を探したり創ったりする人などとても多様なワケですし、それぞれにメリットデメリット、楽しいことやつらいことがあるワケで、「フリーランスはこうだ!」と言える人はどこにもいないのです。

結局、自分はどう働きたいのか、そのために何を準備して、どんなスキルを身に着けて、誰にどうアピールしていけばよいのか、といったことを自分で考えて実行するのが大切で、同時にその自由さがフリーランスの一番楽しいところの1つなのだと今は考えています。

フリーランスになってから

フリーランスになって最初の仕事は、とある研修ベンダーの外部講師として新人研修のサポートをする、というものでした。

これは完全に前職のツテで決まった仕事で、その研修ベンダーの方々も僕のことをそれなりに知ってくださっていたため、とてもすんなりと話が決まった印象です。コネって大事だなー、と思った瞬間でした。

あまり詳しくは書けないのですが、この研修では技術以外にも企画の立て方を同じくらい叩き込まれる内容で、後ろで聞いている僕の方が勉強になるくらいでした。新人たちもとても前のめりでいろんなことにチャレンジしていて、とても楽しい仕事だったことを覚えています。

これともう一か所の研修の講師補佐を合わせて1か月ほどしていました。これが6月です。

7月から、つまり現在はとあるメーカー会社でAndroidアプリの開発をしています。 この仕事はとある仲介会社を経由して見つけることができた仕事で、今までのWebサービス開発とはまた違った経験のできる仕事です。

海外にも支社があるおかげでそこから来ている外国人も多く、雑談などを通してWebサービスの多言語化のヒントが多く得られる職場です。

3か月ごとの自動更新で、週5で会社に常駐のためあまり生活スタイルとしては会社勤めと変わらない働き方ではあるのですが、とりあえず安定した収入源は確保できた形です。

今の仕事が決まった経緯

前提として、僕は自分で仕事を探したり創ったりしたい派です。ただ、フリーランスになっていきなりそれで生活に十分なお金を稼げるほど簡単なことだとも思っていません。僕は家のローンもあれば子供2人の育児中でもあるので、まずは「食いっぱぐれない」ことがフリーランスとしての最初の目標でした。

そのため、ひとまず食いっぱぐれないために、前職のツテで知ることができた仲介会社へ相談して仕事を探してもらうことにしました。

驚いたのは、「7月以降の仕事のご提案をお願いします」とメールしたその直後から次々と仕事の提案が来たことでした。合計10件くらい提案をいただき、概要から判断して面談の日程調整を5件くらいお願いし、結局最初に調整のついた2件の面談をする、という流れだったのを覚えています。

1件は前職と同じような環境のWebサービスの提供会社で、もう1件は今のメーカー企業でした。

面談の結果はどちらもその場で「7月から開発に参加してください」で、当然両方の現場に参加することはできないため、今後の多言語化の仕事のプラスになりそう(海外に支社があって、同じチームに外国人がいることは面談の際に伝えられていた)という理由と、なんとなく前職と違う環境で違う経験も積んでみたいという漠然とした理由で今のメーカーの方を請けることにしてみました。

面談ではやはり先述したQiitaなどのアウトプットの部分から話が広がったり興味関心を理解していただけた場面が多く、そのあたりもすんなりと話が決まった一因になったのかな、と思っています。

仕事が決まる過程を振り返ってみると、仲介会社にあれこれ相談すればフリーランスでも食いっぱぐれることはないのだな、という感想です。 また、案件の紹介される勢いから見ても、エンジニアという職業はどこも人が足りていない様子がうかがえ、そこに対して適切にアピールできれば「仕事がない期間」ができてしまうなんて想像できない、というのが正直なところです。(当然、「適切に」アピールするためには日ごろのスキルアップとアウトプットが必要ですが) 報酬も、経費分を差し引いても前職の稼ぎより少し余裕が出るかな、という額なのでこちらも問題ナシでした。

面談をしていて印象的だったのは、今の案件の面談の中で、部長の方に「開発スピードに自信はありますか?」と聞かれ、とっさに「あります!」と答えると、「自信があるのはとても大事」とおっしゃっていたことでした。 その理由については特に何も伝えられませんでしたが、結局スキルなんて実際に一緒に仕事してみないとわからないものだから、自信の有無が今までどれだけ頑張ってきて、どれだけ役に立ちそうかの良い判断材料になる、ということなのかなと勝手に想像しています。

結果的に、1年間アウトプットを続けて得られた自信はここでも役に立てることができました。

これから

とりあえずフリーランスとして仕事をスタートできた段階ではありますが、今後はもっと自由な働き方で、もっと高い報酬で働けるようになることが当面の目標です。

といのも、フリーランスになった目的のひとつは、家事、育児や自分の趣味などの時間をもっと柔軟にとれるようになりたい、というものでした。特に育児については、子供がいつ病気にかかって仕事している場合でなくなるかもしれませんし、世間一般と休みをずらすことでより外出を楽しむことができたりします。これが、今まで通りの平日週5で会社に通うスタイルでは状況は変わりません。

さらに、子育て&週5の通勤だとスキルアップの時間が圧倒的に不足します。平日の日中はオフィスで仕事をしなければならず、休日は1日子供の相手をしなければならず、結局集中できるのは通勤電車の中と夜子供を寝かしつけたあとの合計1日3時間程度だけだったりします。

そのあたりを改善するためにも、1か月あたりの稼ぎをもっと多くして、仕事をしない期間があっても大丈夫な状況を作り出し、自分の都合に合わせて仕事とそれ以外の時間を調節できるようになりたいところです。

そして何より、Webサービスの多言語化という内容で自分で仕事を見つけ、自分で稼げるようになることを引き続き目指したいと考えています。今はとにかく仕事の内容を選ばずに稼いでいますが、やはり名刺にも書いた通り「Webサービスの多言語化」を自分の一番の価値として売り出せる仕事が僕の実現したいところです。

というわけで、Webサービスの多言語化はぜひ chooyan.engineer@gmail.com までご連絡ください!

その他

各種事務手続きについて

フリーランスになるための開業手続等ですが、思ったより簡単でした。 だいたいの場合、ネット上で軽く前提知識を得た上で窓口へ相談すれば効率よく必要な手続きについて教えてくれますし、その場で実際の書類を一緒に書いて提出までしてしまえば手戻りもなく手続きを済ませることができます。ついでに必要な手続きが他にあればその場で教えてくれたりもします。

小難しい手続きはネットで済まそうとするのではなく、最後は専門家を直接頼るスタンスで進めれば特に苦労することはないのだと知りました。

金銭感覚について

金銭感覚もだいぶ変わりました。 フリーランスは、正社員以上に収入が増減しやすいです。つまり、投資した分のリターンも見込みやすい、と考えることができます。

最近は、たとえば通勤の際の30分間の電車移動に片道400円の特急を使うようになったり、空き時間の作業場所をカフェではなくコワーキングスペースにしてみたり、といったことを意識してやってみています。多少お金がかかっても集中して何かをできる環境を確保することで、そこでの成果によって今後もっと良い条件の仕事を見つけられたり、副収入を確保できるのではないかと思っています。

また、同じような理由で自分や家族の健康やストレス解消に必要だと思ったものは、値段は見て見ぬふりをして買ってみるようにしています。フリーランスにとって病気(家族も含め)で仕事する時間が減ることはそのまま収入減につながりますので、多少の節約よりも健康への配慮を優先するようになりました。

業務内容について

正社員でなくなったことで、自分の仕事は「開発」のみになり、上司との面談や研修などの「組織のためのタスク」がなくなったことも大きな変化でした。

オフィスの椅子に座っている間は打ち合わせもなく、横から入るタスクもなく、ひたすら今自分に求められているアプリの完成に集中できるため、1日に使える時間が前職の5倍くらいに増えた感覚です。それだけ、横槍が全く入らないという状態は開発がはかどるものだと知ることができました。

もともと僕は会社から面倒を見られることにそれほど必要性を感じないタイプで、さらにはちょっとしたことで集中力が切れやすい人間だったため、この変化はとてもプラスでした。

まとめ

総じて、フリーランスに転向したことはとても自分にとってプラスになったと感じています。毎月のように新しい人たちと新しい場所で新しい仕事をすることができ、とはいえ収入が不安定になることもなく、今のところ仕事を楽しむことができています。 よくネット上で「フリーランスはやめた方が良い」という内容を目にすることは多いのですが、今のところそんな実感はなく、むしろこの働き方をもっといろんな人に体験してほしいと思ったりしているくらいです。(あまり無責任に勧めたりはできませんが)

とは言え僕もフリーランスになってまだまだ2か月そこらの駆け出しですので、1年くらい経った時にどうなっているのかは全く予想できていません。そのあたりはまた来年このブログにかければと思います。

最後に、フリーランスをやっていると「10年後どうするの?」とよく聞かれたりしますが、最近そんな先のことはあまりこと細かに考えなくなってきています。

前職では同じ会社に7年間勤めていましたが、1年前に予想していたことが次の年にあっさり覆っている、という経験を何度も体験しました。同じ会社に所属していても数年先はわからないのだから、先が見えないという点では正社員もフリーランスも変わらないような気がしています。

それよりも1年先にどうなっていたいかを考え、それを実現するためにどう行動すればよいかを考え、ちょっとずつ目標に近づいていく、というのを毎年重ねていけば、そのうちなるようになるんじゃないかな、というのが最近よく考えることです。 10年後については、「最低限子供たちの学費は無理なく払えるくらい稼ぎたいなー」ぐらいなものです。

長々と書いてしまいましたが、とりあえず僕は今楽しくフリーランスの仕事をしています、ということが今回書きたかったことです。 世間では祝日がないと騒がれる6月も、僕は合計6日ほど平日にオフがありました。

またなにか変化があればこのブログに書きたいと思います。

再掲:Webサービスの多言語化はぜひ chooyan.engineer@gmail.com までご連絡ください!

新卒から7年間働いた会社を退職してフリーランスエンジニアになりました

先週、新卒で入社して7年間働いた会社を退職し、フリーランスエンジニアとしての生活をスタートしました。

大学の専攻ががっつり文系だった僕でもエンジニアとして採用してくれ、3ヶ月の研修とさらに3ヶ月ものOJT期間を提供してくれて、徐々にエンジニアとしてのスキルを伸ばしながらWebサービスの開発の仕事をさせてくれる、とても良い環境の会社だったと思います。

この記事では、そんな会社を辞めてフリーランスに転向した経緯を振り返りつつ、今後フリーランスとしてどう仕事していこうとしているのかをまとめてみます。

どんなことをやっていたのか

前職では、主に自社開発のWebサービスをB to Cで提供する会社で、AndroidアプリやServletによるWebアプリケーションの開発をしていました。 言語はJavaが一番多く、次いでJavaScriptPython、という感じでした。

僕は落ち着かない性格で、1年前後のスパンでプロジェクトを転々とし、時には人事としても働いてみたりしながら、データのクローリングや整形、ServletJSP, JavaScriptによるWebアプリケーション開発、Androidアプリ開発、さらには新卒採用や教育研修まで幅広く経験しました。

そんな7年を経て、現在ではLinuxの文字だけの世界がとても居心地よく思えるようになったり、Qiitaに記事を投稿するようになったり、といったことは当時からすると考えられない変化ではないかと思います。

プライベートでもNode.jsやRailsを書いてみたり、EC2でマインクラフトサーバー立ててみたり、Raspberry Piで電子工作してみたり、だいぶエンジニアを満喫している現在です。

フリーランスへの転向の理由

そんな至れり尽せりの環境ではあったのですが、いつからだったか、「自分の技術に世間一般ではいくらの値段がつくのか」というのに興味が出てきました。 また、入社以来社内のエンジニアとばかり仕事をしていたので、勉強会やWeb上で見かけるような、外のエンジニアと仕事をしてみたいと思うようにもなりました。

自分の意思決定で、自分の責任において自分の好きな環境・条件で好きな開発ができ、好きにお金を稼げる、という状況にとても憧れがあり、最終的にフリーランスでやっていこうと決断して今に至っています。

今後

今後は「多言語対応フリーランスエンジニア」という肩書きで、Webサービスの多言語化を専門とするエンジニアとして仕事しようと思っています。 多言語対応はシステムの根本的な設計に関わるために一度進めてしまうと後戻りしづらく、とはいえ自社にノウハウを持っている会社もそれほど多くないと踏んで、この分野のプロフェッショナルになれば一定の需要があるのではないか、と予測しています。

多言語対応のライブラリは “i18n” とつくライブラリがどの言語にもありますが、それらのライブラリの使い方だけでなく、技術以前の言語や文化、宗教、政治などの文系的な知識も提供できるエンジニアとして、文系のメリットを最大限に活かしながら仕事ができればと考えています。実際調べていると多言語対応はシステム的にもテキストを翻訳すれば良いだけではないことがわかるのですが、そのあたりはこのブログに一つずつまとめられればと思っています。

多言語対応と言ったら @chooyan_i18n!と言われるよう、セルフブランディンク的なことをしていく所存です。(このあたりも文系的な知識が役に立つ、はず、、、!)

というわけで、多言語対応は @chooyan_i18n へ!

Webサービス多言語対応 技術的なチェックリスト

Webサービスの多言語対応について絶賛勉強中です。

この記事では、Webサービスの多言語化を実現するために、システム面でできることや考慮しなければならないことをチェックリスト形式でをまとめてみようと思います。


文字コードUTF-8になっていますか?

とにかく文字が表示できなくては多言語化は始まりません。 世界各国の文字を収録しているUNICODEは必須と言えるでしょう。

文字コードはシステムの全ての箇所で統一されている必要があります。 HTMLやアプリ等のフロントエンドだけでなく、サーバー、Webアプリケーション、DBなど、システム全体がUTF-8で統一されていることを確認します。

なお、UTF-8は日本語などの全角文字を3バイトで表現するのに対し、UTF-16は日本語も英語も全ての文字を2バイトで表現する、という性質上、アジア言語をメインにサポートする場合はUTF-16という選択肢も考えられるようです。 (とはいえ広く使われる文字コードはやはりUTF-8ですので、そこまでデータ量にこまかなチューニングが必要になるわけでなければUTF-8を使うのが安全なのではないかと思います)

テキストのハードコーディングはないですか?

システムにおける多言語化対応の大部分はテキストの翻訳作業です。

一般的に多言語化の仕組みとして、プログラム上ではテキストに対して「タグ」を割り当て、そのタグが具体的にどのような文字列を指すのかを言語ごとの翻訳テキストファイルから探し出す、という手法が広く用いられます。 プログラム内でテキストをハードコーディングしていると、そのような言語設定によるテキストの出し分けができなくなってしまいます。

多言語化を視野に入れた段階で、テキストをプログラム内にハードコードするのはやめ、タグと言語ごとの設定ファイルによってテキストを動的に変えられる仕組みを徹底するようにする必要があります。

スタイルはロケールによって切り替え可能ですか?

同じ内容の文章でも、文章の長さや読みやすいスタイルは言語によって様々です。

例えば、漢字という表意文字を使う日本語は、同じ情報量を英語よりもかなり少ない文字量で表現することが可能です。逆に、ドイツ語やフィンランド語は、英語よりも40%ほど文字数が多くなると言われています。

文字の長さだけでなく、右から左に文字が進むアラビア語、縦書きで左から右に文章が進むモンゴル語など、我々に馴染みの無いルールでテキストを表示する言語も存在します。

そのため、国際化対応ではテキストの変換だけでなく、そのテキストできれいにレイアウトを作るためにスタイルそのものを変えることが必要になってきます。そのため、言語設定ごとに適用するCSSやレイアウトファイルが切り替えられる仕組みを検討します。

画像はロケールによって切り替え可能ですか?

国際化において考えなければならないのはテキストだけではありません。画像も、対応する国や地域によっては大きな問題となる場合があります。

例えば、イスラム教では偶像崇拝を禁止しているため神様やそれに類する画像を見せるのは避けるべきです。また、女性の肌、髪の毛の露出なども、地域によっては避けたほうが良い場合があります。Webサービスではありませんが、スターバックスのロゴ問題などが有名です。

スターバックスのロゴ問題 中東編 : きよおと-KiYOTO

また、タイでは曜日ごとに色が振られており、国王や首相が生まれた曜日の色はその人を象徴する色となることがあります。そのため、社会情勢によっては色の使い方で「この人を支持する」という意思表示と解釈されてしまう可能性があったりします。

タイ人にとっての色のお話|INJカルチャーセンターのブログ

テキストだけでなく、画像も対象とする国や地域、社会情勢によってすぐに切り替えられるようにしておくと、不測の事態にすぐに対応できるでしょう。

入力フォームは各国の事情に対応できますか?

名前や住所は、国や地域ごとの文化や宗教などに大きく影響を受けます。 日本のように姓・名の入力ボックスだけではミドルネームを始めとする3つ以上の名前の構成要素に対応できないですし、逆に「よみ」はひとつの漢字に対して複数の読み方が存在する日本語固有の項目です。

ロケールによって入力フォームの構成が変えられること、また、テーブル構成がその入力内容を受け付けられることなどが求められます。

人名 - Wikipedia

サーバーの配置場所は大丈夫ですか?

例えば、ロシアやイランでは、サービス提供者はその国民の個人情報を国外に持ち出すことを禁止しています。

外国企業の半数がサーバ移転中――ロシア人ユーザの個人情報を国内に保管 / SYNODOSが選ぶ「ロシアNOW」 | SYNODOS -シノドス-

また、地理系のサービス提供者が中国でビジネスをする場合、地図データを中国国外に持ち出すことができないなど、様々な制約を課せられます。

http://www.tcci-wbiz.jp/hotnews/2140.html

このように、ターゲットとする国によっては電子データの扱いなどに法律による制限をかけている場合がありますので、それぞれの国の事情に合わせてシステム構成全体を考え直さなければならない場合があることを考慮しておく必要があります。

ネットワークは大丈夫ですか?

法律的な制限がなくとも、地球の裏側の国へサービスを届ける場合、どうしても物理的な距離によってリクエストとレスポンスの速度が数百ミリ秒という単位で遅くなってしまう場合があります。

また、物理的な遅延以外にも、ターゲットとする国や地域のネットワークの整備上記によって、現実的な通信量は変わってきます。

もしサービスが日本の通信網で、日本国内で使うことを前提に設計されているのであれば、データの通信量自体の削減を検討する必要がある場合があります。

URL体系は整っていますか?

例えば、以下のように日本語と英語のページで、URLのロケール部分だけが違うような設計になっている場合、ユーザーはURL自体を修正することで自分の求める言語のコンテンツを表示することができます。

・日本語
https://www.example.com/ja/some/contents/0001

・英語
https://www.example.com/en/some/contents/0001

ユーザーはどのリンクを踏んで、どの言語のどのページから自社のサービスに流入するか予測できないため、言語部分を修正するだけで同じコンテンツの言語違いのページを表示することができれば、ユーザービリティは大きく向上できるでしょう。

他にも、もしロケールによって準備ができていないページがあったとしても、該当のページが存在しないことをユーザーに提示した上で、一つ上の階層に戻るか、別の言語で表示し直すかを選ばせることができるような構造になっていれば、混乱を最小限に留めることが可能です。

サービスで利用する文言は全て任意のタイミングで表示できるようになっていますか?

翻訳者は、単語や文章だけ渡されてもそれを正確に翻訳することはできません。 想定ユーザーやサービスのコンセプト、どのような場合にどのようにそのテキストを見せるのかなど、情報量が多いほど翻訳はより正確になります。

そうなると、実際に翻訳者にサービスを触ってもらい、実際のユーザーとしての視点から翻訳作業が行えるのが理想です。

好きに触っても本番環境に影響がなく、翻訳をすぐに当てはめて検証することができ、レアなケースで表示されるテキストも任意のタイミングで表示できるような仕組みを作ることができれば、翻訳はより効率的に、正確に進められると思います。


以上、多言語化をするにあたっての技術的な確認観点をまとめてみました。 実際には、これに加えて各々のWebサービス特有の設計や事情から、他にも検討事項が出てくるのではないかと思います。

追加で記載できる内容があれば、この記事も随時更新できればと思います。

Webサービスを多言語化するリスクを考えてみた

IKEAサウジアラビアで製作したパンフレットが物議を醸しているという記事がありました。

IKEA's Women-free Catalogue in Saudi Arabia

内容は記事を読んでいただければと思うのですが、これを読んで、自社のWebサービスを「国際化」するつもりが「多言語化」だけで満足してしまうことのリスクについて考えたので、まとめてみます。

多言語化することのリスク

最初に紹介した記事はいわゆる「多言語化」とは違った取り組みですが、今までの顧客とは違った文化を持つ層にアプローチするという意味では多言語化するのと同じだと考えています。

その上で、多言語化することのリスクについて、以下の2つがあると思いました。

新しいターゲットに意図しないメッセージが届いてしまうリスク

例えば今私たちが日本語で日本人向けのサービスを展開していることを考えた場合、作る側が使う側の立場になって自分のサービスを見ることができるため、作る側が提示しているテキストや画像がどのように受け取られるのかをある程度予想することができます。

しかし、多言語化して自分とは全く異なる文化、言語で生活している人たちにサービスを提供するとなると、先ほどの「作る側が使う側の立場で自分のサービスを見る」ということができなくなるため、そのテキストや画像がどのように受け取られるか、予測することはほぼ不可能になってしまいます。

さらに、多言語化という意識で「言語」だけを見てしまうと、言語は同じだけれど国も文化も宗教も全く違う人たちの存在を見落とします。 例えば、スペイン語はスペインだけでなく、はるか海を渡った中南米でも公用語として使われていますし、中国語(特にMandarinと呼ばれる共通語)は中国本土の各地域や台湾、香港、さらにはシンガポールといった様々な国や地域で、13億人以上が読むことができてしまいます。

私たちが日本語で日本人に発しているテキストを単純に翻訳すれば、新しいユーザーにもそのまま同じように届くとは限らないのです。

想定外の人にメッセージが届いてしまう

今回のIKEAの件は、イスラム教を厳格に守っている人たちに向けてサービスをチューニングした結果、それが全く意図しない「女性の人権を考える人たち」に拾われてしまったことが発端のようです。

つまり、良かれと思って特定の言語に対応した結果、それ自体を快く思わない人たちが出てくるリスクがある、ということになります。

例えば、同じハングルでも韓国と北朝鮮では書き方・読み方に方言のような差異があるそうなのですが、韓国人向けにハングルでサービスを提供した結果それを目にした北朝鮮の人が「ハングルと言ったら北朝鮮だろう、なんで南訛りの表記をしているんだ!」とクレームの声を上げることも考えられないことではありません。

上の例はさすがにそう起こることではないかと思いますが、とはいえ宗教上の対立、紛争地域、歴史的な経緯などが影響して、「こっちのユーザーを想定してこの言語で出したら、それを読めちゃうあっちのユーザーが不快に思う」という事態は十分起こり得るのではないかと思います。


システム的な多言語対応というと、言語設定ごとのテキストの変換や、画像などのリソースファイルの選択をサポートしてくれるものがほとんどで、それを使って満足してしまうこともあるのではと思いますが、それだけでは不十分どころか、サービスの内容や翻訳方法によってはブランドイメージを損なう可能性もあるのではないかとIKEAの記事を読んで考えました。

本当にターゲットの国のユーザーに使ってほしいのであれば、テキストの翻訳だけで満足するのではなく、いわゆるグロースハックのような、継続的な検証と修正が国・地域ごとに必要なのではないかと思います。

技術的には、翻訳文を変換する仕組みの実装だけでなく、国・地域ごとに継続的に細かなチューニングができる柔軟な環境づくり、場合によってはある国向けのサービスだけ全く別のシステムとして構築し直すことになった場合にシステム全体を再設計する力、などが必要になるのではないかと思います。

やればいいというものではない、ということかなと思います。

i18n対応で参考になりそうなサイト

Webサービスの国際化対応について勉強するにあたり、参考になりそうなサイトをまとめます。随時更新です。

コーディングのガイドラインなど

文字コードとは、みたいな基本的なところからまとまっているので入門として使えそう。

Androidアプリを国際化する際に知っておきたい基本的な仕組み。

実際の例

実際に世界中にサービスを展開している企業のウェブサイトは参考になることが多い。

stackoverflowの議論

それぞれ言語は違うけれど、サービスを国際化する際に考えなければならないこと、という意味では特にどの言語で書くかは関係ない。

その他参考になりそうな記事

SwiftでiOSアプリを国際化する際に知っておきたいTips、ノウハウなど。iOS以外でも同様に使える知識が書かれている。

“10 Best Practice Tips On How To Write Global-Ready Content For Localization” というタイトルの記事。国際化対応は大変だけど、これだけ抑えておけばある程度対応が楽になる、という話。

さらにその他

Webサービスが開発できる言語であれば、だいたいサービスの国際化をサポートするライブラリなりツールなりが開発されているので、それらができることをじっくり見ていけば、どんなところに気をつける必要があるのかある程度分かってくる気がします。