企業のローカライゼーションへの取り組みについて：Slackの場合

スラックとローカライゼーション

ローカライゼーションプロセス

企業ではローカライゼーション戦略をどう採りいれているのでしょうか。コミュニケーションアプリのSlack、日本企業でも使用しているところもあると思います。Slackは日本語のユーザーインターフェースも使えますね。メールのやりとりが負担ななか、楽しくコミュニケーションがとれるため採用している企業もどんどん増えているようです。Slackが書いたこのブログでは、企業のローカライゼーションや翻訳プロセスがどんなに全社的なものであるかを語っています。ブログの内容を簡単に日本語に要約してみました。Slackではどのようにローカライゼーションと翻訳に取り組んでいるのでしょうか。

現在、Slackではアプリを11言語にローカライズしています。コロナウイルス感染症のパンデミックによる影響でアプリを使用する国が大きく増えたために新たにローカライゼーション言語を増やしたとのことで、簡体、繁体中国語もこの中に加わったようです。このようにローンチ時には数言語だったインターフェースに、さらに言語を加えていくことも決して珍しいことではありません。

ローカライゼーションとは

ローカライゼーションは単にひとつの言語を別の言語に翻訳するというだけのものではなく、企業全体で取り組まなくてはならない一大プロジェクトです。

単に翻訳をするというだけでなく、ローカライゼーションをする際にはアプリのエンジニアリング、カスタマーサポート、製品管理、デザイン、営業、マーケティングその他さまざまな部署が一丸となって取り組まなくてはなりません。翻訳するだけじゃないんですね。UIデザインはユーザーの体験と密接に関わっていますし、マーケティングではユーザーのフィードバックを収集することがあります。

スラックとローカライゼーション

ローカライゼーションの成功例

ローカライゼーションを行なう前に、Slackではまず対象言語のリサーチを行なっているそうです。定量的調査を行なうことで、どのような地域でもっとも使われているのかを導きだし、定性調査（質的調査）で一定地域のテクノロジートレンドや環境に関する要素まで考慮にいれ、どのような機能が要求されているのかを調べる手法をとっています。この調査は、例えばスペイン語を採用するときに、製品がどの地域の人たちにもっとも愛用されているかを知ることで、スペイン語を南米のスペイン語にするのか、欧州のスペイン語にするのかなどを決める手かがりに出来ます。

新しい言語をローンチする際には、プロジェクト管理、品質管理、ツール最適化の3つに注力するそうですが、それぞれはどんな意味を持つのでしょうか。

  • プロジェクト管理の一元化：社内外の窓口的役目を果たすプロジェクト管理者を社内に置くことで、交通整理をしてもらうことができます。
  • 品質管理の徹底：ローカライゼーションプロセスの中に翻訳後のテキストを数量化して評価するLQAというプロセスを採りいれ、アプリへの展開前にチェックを徹底することでローカライゼーションの正確性が高まるので、カスタマーの満足度に直結します。
  • ツールの最適化：翻訳されたファイルの効率的な処理のために、ファイルアップロードする手順を一部自動化するなどの最適化を行なっています。さらにデバグまでのワークフローの自動化や、翻訳者からの質問に迅速に答えられるような最適化ツールも必要といいます。

Slackの最適化でもっとも効果的と思えるのは、SlackとJiraを組み合わせて言語関連のバグに関するフィードバックを得てそれをバグ修正として実際のアプリに反映させるまでの手順がスムーズに自動化されている点です。

LQA

ローカライゼーションのワークフロー LQA：Linguistic QA

翻訳者が作業にあたるとき、ソーステキストで気づいた点やソースの間違いなどを報告する場合があります。この手順がクライアントと直で出来る場合は双方にとって大きなストレスと時間の節約となります。またテキストのバグ（誤訳とは違いUIに収まりきらない場合や対象国にふさわしくない翻訳）を管理者を介さずに直接エンジニアに流すことができるシステムづくりも、Time to Market（市場投入までの時間）削減に貢献するでしょう。

通常Linguistic Bugと呼ばれる翻訳バグをローンチ前のアプリ上でとらえて製品としての完成度を高める、肝心のLQA（Linguistic Quality Assurance）は通常社内で行ないますが、11言語を理解する人を探すことはなかなかできませんので、これも通常は翻訳会社またはチェック会社に依頼することになります。ときにはこのLQAステージはセキュリティの面から社内で行なう大企業も少なくありません。SlackではこのステージをEQA前に置いていると書いています。その理由は、それぞれの言語で発生するバグは言語特有のバグを内包することが多く、単に翻訳を修正することにとどまらない場合があるからです。アプリの新機能を追加するときにもやはりこのLQAは必須です。私は長くソフトウェアの翻訳がうまく反映されているかどうかの、ソフトウェアQAのうちでもLinguistic QAと呼ばれる言語のバグチェックを長くやってきました。それをやっていて思ったのは、工程が後にいけばいくほど、間違いを修正する負担は高くなるということです。ですので、言語面でのバグもやはり翻訳段階でキャッチして修正しておく必要があります。そのためには翻訳段階での翻訳者への指示出しをどれだけうまく出せるか、翻訳者から出るクエリをどれだけ効率的に処理できるかにもかかっています。後工程にいけばいくほど、修正するのに時間も、コストもかかるようになるのです。

このように最先端を走るアプリやテック企業では作業やワークフローを効率化するさまざまな工夫が凝らされています。翻訳の技術だけでなく、Jiraをはじめとするバグ報告に関する知識、さまざまなアプリやツールにアクセスできる基本的なコンピュータリテラシーはアプリを翻訳する翻訳者にとって必須とも言えます。アプリ翻訳をどれだけ効率的にできるかで市場への投入時間も短縮できるようになるというわけです。

また、翻訳チェックをする際にもLQAという用語は使われます。このSlackの記事でもつぶさに翻訳の内容を精査し間違いや修正のレベルによって点数で数量化、スコア化するLQAについても言及しています。SlackではLQA評価のパス基準を97点に据えているそうですが、97点を獲得するのは実は結構難しいです…。翻訳の分量が多くなればなるほどタイプミスや誤訳も増えますし、実質この誤訳などをどうキャッチして修正していくかは各翻訳会社の課題ともいえるものです。単なる文字の入力ミスはもちろん細かな誤訳をどのように見つけるか、二重三重のチェック体制を敷く企業もあります。エンドクライアントが気をつけなくてはならないのは、翻訳段階でできる限り細かいコンテキストを翻訳者に届けられているか、それも最適化・自動化されているか、翻訳者から出るクエリの処理もちゃんとワークフローに組み込まれているかです。翻訳の品質があがらないのは翻訳ツールが使いにくい、コンテキストが提示されていない、質問を出しているのにちゃんと返信がもらえない、なども原因として考えられるのです。それらすべてがうまく機能して始めて効率的なローカライゼーションプロセスができあがるといえます。

Word Connection が主催するHuman Powered勉強会では、毎回外部からのスピーカーを迎えて翻訳関連のさまざまな講座を開講しています。翻訳の技法から実務に関することまで、トピックは豊富に用意しています。隔月の不定期開催になります。詳しくはトップページをご覧ください。