さまざまな言語に対応する Slack の取り組み

Slack は現在 11 の言語に対応しています。ここ 1 年では、4 つの言語をリリースしました。韓国語とイタリア語、そして一番新しいのが簡体字と繁体字の 2 種類の中国語です。

Slack では、使いやすさの観点からローカライゼーションをとても重視しています。コロナ禍では世界中の企業がリモートワークに急転換し、多くの人が優先事項を見直さなければいけませんでした。私たちにとっては、皆さんのチームが離れていても仕事を進められるようにすることが新たな緊急事項となりました。そんななか、世界中の多くの企業ではかつてない成長を遂げています。そこで Slack が重要な局面でしっかり役に立てるよう、私たちは新しい言語のローカライゼーションに力を入れることにしたのです。

これは大きな決断でした。というのは、ローカライゼーションにはものすごく大きな労力がかかるからです。実際、エンジニアからカスタマーサポート、製品管理、デザイン、営業、マーケティングまで社内の多くのチームとの連携や調整が発生します。しかしローカライゼーションはユーザーにとって転機となります。うまくローカライズするということは、ユーザーが普段使う言葉でサービスを提供するということです。そうすれば、ユーザーは直感的かつ自然に仕事を進められるようになります。私たちのローカライゼーションに対する取り組みは、世界中で Slack をバーチャルな職場として活用する皆さんへの責任の表れなのです。

Slack のローカライゼーションチームは、すべてのサポート対象言語において全社の翻訳ハブとして機能しています。チームの仕事は、現在の対象言語でサービスを提供し続けることと、そしてユーザーのために新しい言語をリリースすることです。新しい言語のリリースは大変ですが、同時にやりがいもあります。世界中で Slack を活用してビジネスを進める皆さんに対して、よりよいサポートを提供できるようになるからです。私たちは新しい言語に対応することで、ユーザーの仕事を少しでもシンプルに、快適に、有意義にすることを目指しています。

新しい市場に参入する際は、できる限り質の高いローカライゼーションでユーザーに満足してもらえるよう、プロジェクトチームやプロセスを作ります。南アフリカの指導者である故ネルソン・マンデラ氏はかつてこう言いました。「相手が理解できる言語で話せば、その言葉は頭に届きます。相手の国の言葉で話せば、その言葉は心に届きます」。これは私たちが常に頭に置いている原則です。Slack では常にユーザーを第一に考えています。だからこそ、ローカライゼーションプロセスでは言語品質の高さを優先するのです。

そのため特定の市場でのローカライゼーションを始める際は、現地のユーザーとそのニーズをより理解するための調査から始めます。この調査は複数の形式で行います。例えば現地のユーザーと直接話すことで、Slack が現在どう使われているか、今後どう改善できるかなどの意見を集めます。また定性調査では、テクノロジーのトレンドから関連する政策や環境要因など、その地域の働き方を形作っている重要な要素を把握します。場合によっては、その地域内で正式なユーザー調査を行い、働き方について直接会って学ぶこともあります。また分析会社とともに定量調査も行い、その地域における現在と過去の Slack の利用状況を把握します。これは製品体験において、現地のユーザーが使いづらいと感じたり問題になったりしそうな箇所を特定するのに役立ちます。

新しい言語のリリースをスムーズに進めるうえで、私たちは 3 つの要素を重視しています。それはプロジェクト管理、品質保証、ツールの最適化です。これらの戦略的要素をしっかり押さえるために、ローカライゼーションチームはプロジェクト、品質、システムという 3 本柱から成り立っています。

• プロジェクトの柱では、チームに寄せられるリクエストをすべて管理します。この柱では、新しい言語のリリースが決まると、仕事を引き受けたり、難しい問い合わせに回答したり、全社規模でのエンドツーエンドのタイムラインを追跡したりする担当者を割り当てます。
• 品質の柱は、大きな規模での品質の維持を担当します。言語品質の合格スコアは 97% です。つまり翻訳コンテンツが Slack の品質基準を満たすには、コンテンツの品質評価のスコアがすべて 97% 以上でなければいけません。新しい言語のリリースにおいて、この柱では言語品質保証（LQA）プロセスを実行し、社内のネイティブスピーカーや社外のベータパートナーからバグ報告やフィードバックを受け、重大な問題がすべてリリースまでに修正されるよう徹底します。
• システムの柱は、新しい言語のリリースを効率よく行うだけでなく、提供中の言語をサポートするためのツール作りや自動化に取り組んでいます。この柱では、ファイルのアップロードをサポートしたり、ツールの問題のデバッグに対応したり、国際化に関する問い合わせに対応したりしています。

Slack のローカライゼーションチームでは、2017 年に言語のリリースを開始しました。それ以来異なる言語のリリースを 6 回行い、プロセスを繰り返してきました。ここからは、そうしたローカライゼーションを通して私たちが学んだ教訓をお伝えしたいと思います。ここで紹介する内容は、私たちが新しい言語に対応する際に必ず頭に置いていることです。

言語とプロセスについて社内のパートナーを啓蒙する

プロジェクトの柱は、その言語にかかわるさまざまなチームのメンバーに向けて、新たな地域について知っておくべきことをまとめます。起こりそうな課題（日付と時刻の書式設定、言語の複数形や所有格など）を押さえておくだけでなく、対象言語に関する予備知識を提供することで、その言語に少し馴染んだ状態でスムーズに仕事を始めてもらえるからです。

また複数の部門のメンバーから成るチームに対してバグの対応手順について共有し、目指すべきサービス品質について認識を揃えます。ローカライゼーション関連のバグには、言語、機能、対象外という 3 つのカテゴリーがあります。言語のバグは、ローカライゼーションの領域です。ほとんどの場合、誤字脱字、文法の誤り、コンテンツの配置ミスであるため、修正が可能です。2 つ目の機能上の問題には、変数内のエラー、文の中断、単語や文が英語で表示されてしまうことなどがあります。こうしたバグを修正するにはエンジニアチームやデザインチームの力が必要です。これらのカテゴリーについては、関係者に事前に共有しておくことが大切です。そうすれば、テキストが英語で表示されるバグが発生した時に、エンジニアは翻訳漏れ以外の可能性もあるとわかっているため、すぐにエスカレーションできるようになります。

特に複雑な分野においては、コードについてしっかり学びました。翻訳を始める際は、製品のなかでもローカライゼーションが難しい領域から取りかかるようにしています。また翻訳された文字列が、正確な翻訳が欠かせないとわかっている名前空間に返される場合には細心の注意を払います。こうした注意が必要なものには、スラッシュコマンドの名前空間のほかに絵文字のローカライゼーションがあります。それらの翻訳はプラットフォーム全体で統一させなければいけません。こうした翻訳から取り掛かるということは、きちんと翻訳されていることを確認する時間をしっかり確保するということです。

言語品質保証（LQA）を品質エンジニアリング（QE）より先に行う

言語とエンジニアリングの QA チームは分かれているため、QA 工程を連携して行うようになりました。QE テストサイクルの前にコンテキスト内レビューを行うようにすることで、言語のバグをすばやく見つけて修正し、問題の重複を避けることができます。また翻訳されていない箇所がある場合、文字列が翻訳に正しく対応できていない可能性があるなどの重要なフラグを立てることも可能です。こうした連携によってエンジニアのタスクが明確になり、スムーズに次の段階へと移ることができ、何度もやり取りしなくて済むようになりました。

製品をうまくローカライズするには、できるだけ多くのネイティブスピーカーからフィードバックを得ることも欠かせません。これまで作ったプロセスはすべてユーザーを念頭に置いたものですが、それらを検証するには社内の関係者や社外のベータパートナーからのフィードバックを活用するのがベストです。そうしたフィードバックプロセスを何度か経ることで、最終的なリリースの成功につながります。

さらに、用語集やスタイルガイドに関しては早い段階から社内のさまざまなチームとやり取りして固めると、質の高いローカライゼーションを実現できることもわかりました。Slack 上にはこうしたつながりによって、進めている最中にすぐにフィードバックを得られる仕組みがあるため、新言語がベータパートナーにリリースされる前に数か月間の改善するチャンスが得られるのです。

ほかのチームとの連携にはワークフロービルダーも活用しています。社内の有志メンバーは、各言語のフィードバック専用チャンネルを使ってフィードバックを共有します。例えば、イタリア語の場合は #proj-italian-feedback（#proj-イタリア語のフィードバック）です。そうした社内のネイティブスピーカーたちが翻訳の問題を報告するフローでは、手順を案内するプロンプトを設定しています。フィードバックを送る人は、このフローを通して氏名や提案、修正が必要だと思われる単語やフレーズ、さらに翻訳の表示位置がわかるコンテキストやスクリーンショットを共有します。

ワークフロービルダーを通じてフィードバックを取り入れると、Jira インテグレーションフィードバックをバグとして処理するため、優先的に対応できるようになります。こうしたプロセスによって状況がわかりやすくなりました。以前は、問題の概要を書いてスクリーンショットを送ってもらうだけでしたが、その方法では問題を再現したり、バグを見つけて修正したりすることが常にできるわけではありませんでした。

今ではベータ段階でもユーザー向けに同じようなワークフローを用意し、ユーザーが Slack コネクトチャンネルを通じてフィードバックを簡単に共有できるようにしています。このように社内でフィードバックを集める方法を社外で再現することは、とても効率的だとわかりました。こうしたプロセスによって、ユーザーからの意見をリアルタイムで集めてやり取りすることができるからです。

新しいプロセスを試して品質向上につなげる

新しい言語をリリースする際は、過去のプロセスを繰り返すことでさらに効率的に進めることができます。ワークフロービルダーで社内のフィードバックを集めることは、主なプロセスを効率化し、品質の柱における調査作業を大きく減らすための試みでした。最近システムの柱では、新しい言語のファイル送信プロセスについてのアイデアが生まれました。毎回ほぼ同じ単語を翻訳することから、社内の繰り返し作業を自動化することが目標です。こうしてチームでは、新しい言語の翻訳において画像など難しい部分の効率的な管理や、フィードバックやバグへの対応にもっと専念できるようになりました。

私たちは常に効率と品質のバランスを図ろうとしていますが、行き過ぎた効率は品質低下につながります。そのため、ベンダーの研修や用語集の作成という土台の部分だけでなく、フィードバックの受け取りなど業務の成果をはかる部分の時間を特にしっかり確保するようにしています。

社外パートナーをチームの一員として扱う

私たちは、ベンダーをチームの仲間だと見なしています。私たちが大事にしていることをベンダーに理解してもらえるよう、できる限り必要な情報を共有するようにしています。新しい言語のリリースでは、ベンダーにスケジュールやテストの計画、全体的な目標について説明するところから始めます。言語のリリースに必要なコンテンツのほとんどは、言語サービスプロバイダー（LSP）のおかげでうまく翻訳することができています。また彼らとの仕事を繰り返すうちに、バグの修正もお願いできるようになり、それによって社内のリソース配分をすばやく行えるようになりました。

ローカライゼーションは翻訳以上だと理解する

新しい言語のリリースは、わくわくすると同時に大変です。チームでは、各担当者が異なるタイミングで繁忙期を迎えます。プロジェクトマネージャーはタイムライン策定時に多忙になる一方で、品質戦略担当者はリリースが近づくにつれてどんどん増えるフィードバックに対応しなければいけません。またシステム開発者はその過程で常に連携する必要があります。全員がうまく連携できるように、さまざまなタイミングでこまめに進捗を共有し、ほかの業務に及ぼす影響を確認することは非常に重要です。

ローカライゼーションは、言語の翻訳にとどまりません。しっかりローカライズされた製品を提供するためには、社内のあらゆるチームとの強いパートナーシップが必要です。製品チームが新しい機能を評価する際は、各地域ならではの影響や営業機会を考慮しなければいけません。エンジニアチームは、ローカライゼーションのバグやパフォーマンスの問題に対応し、グローバルに拡張できるシステムを構築します。さらにカスタマーエクスペリエンスチームは、世界中のユーザーと直接連携して問題を解決し、社内の関連チームにフィードバックを共有しています。ここで取り上げたのは、ローカライゼーションに関係する人々の一例に過ぎません。まとめると、さまざまなチームの協力を得て進めているローカライゼーションの取り組みはすべて、Slack を世界中のユーザーにとってよりシンプルで、快適で、有意義な場にするという目標に向けたものなのです。