社内の翻訳用語を自社製ツールで管理、サイボウズ社のローカライズ戦略

ソフトウェアグローバリゼーション入門 国際化I18Nと地域化L10Nによる多言語対応

Globalization(G11N)の基本から具体的な手法やツールまで基礎的な知識を集約！

この記事は、書籍『ソフトウェアグローバリゼーション入門 国際化I18Nと地域化L10Nによる多言語対応』の内容を、Think IT向けに特別にオンラインで公開しています。詳しくは記事末尾の書籍紹介欄をご覧ください。

取材協力：サイボウズ株式会社　佐藤 鉄平氏、河村 理加氏

チーム内の情報共有・コミュニケーションを目的とした「グループウェア」は、企業などのビジネス用途で古くから活用されているソフトウェアの1つです。組織がグローバルになってくると、チームメンバー間の時差や言語などの制約を受けるケースも少なくありません。国産グループウェア製品の雄であり、グローバル展開にも積極的なサイボウズ社の佐藤氏と河村氏に、B2Bソフトウェアならではのローカライズの苦労などを聞きました。

佐藤：サイボウズ株式会社では「世界中のチームワークを良くする」をミッションに、スケジュール、メッセージ、ファイル共有などの機能をもったグループウェア製品を取り扱っています。1997年の創業からグループウェアを手がけて今年で20周年（インタビュー当時）になりますが、2011年にはWebアプリケーション開発のプラットフォーム「kintone」をリリースしました。こちらはユーザーが自分で簡単にアプリを作って社内で使えるようにするサービスです。製品カテゴリとしては大きくその2つになります。

撤退からの再チャレンジ、いまでは海外拠点は３つに

佐藤：グループウェアというプロダクトの性質上、より多くの皆さんに使ってもらう必要があります。メンバーの中で日本語が苦手な人がいた場合でもチームワークを発揮できるようにするためには、UIがその人に適したものであることが望ましいです。サイボウズは日本の会社で国内のお客様も多いですが、グローバル化は会社のミッションとしても重要な観点でした。

過去2001年には、アメリカに進出してすぐに撤退した経緯もあります。その後は日本専業の時代が長く続きましたが、ベトナムや上海に開発拠点を展開し、2008年ごろから製品のグローバル化の取り組みを再スタートさせました。大規模向けグループウェアのGaroonでは、それまでは日本語とJST（日本標準時）のみ対応だったものから、言語は日英中から、タイムゾーンは自由に選択できるようにしていきました。現在では上海とサンフランシスコに販売拠点*6を持ち、この2拠点をベースにして国外のマーケットにGaroonやkintoneを売り出しています。ロケールも販売ターゲットに合わせて日・英・中を選定しています。

ちなみに、上海の開発拠点には中国人のエンジニアが多く、日本語だけのコミュニケーションでは一緒に仕事をするのが大変な時期がありました。（自社サービスのグループウェアが）中国語に対応したことで開発チームの国際化に寄与し、海外拠点が広げやすくなるというメリットもありました。

サイボウズの佐藤氏

言語の違いよりも文化や商習慣の違いがボトルネックに

佐藤：グループウェアは非常に業務寄りの製品です。仕様・機能設計にあたっては、仕事の進め方や文化的なコンテクストをどこまで製品に盛り込むのかが1つのポイントになります。例えば最も日本に寄せると、「予定に登録された参加者を役職順に並べる」といった機能の要望が出てきます、が欧米では恐らく必要ありませんね。最もグローバル寄りのkintoneでは、プラットフォームというプロダクトの性質もあり、そうした地域色の強い機能は極力排除するよう明確にデザインしています。

地域固有な要望とグローバルな要望の線引きは非常に重要で、それぞれのプロダクトマネージャーが製品のターゲットに合わせて判断して機能を取捨選択していくことになります。

いま課題になっているのは、導入や運用管理する人（例えば情報システム部門など）と、実際のサービスの利用者（事業部の担当者など）が異なるケースです。また、日本本社で購入したものを中国支社で利用する、といったようにリージョンが異なるパターンも少なくありません。kintoneでは購入者のリージョンに紐付いた特定地域向けの設定がいくつかあり、管理者向けに顧客管理や交通費精算、稟議書などのテンプレートが用意されているのですが、購入したリージョンが日本で日本企業向けの設定になっていても実際に利用されるのが中国ではほとんど意味がなくなってしまいます。

このように、単純なインターフェースの国際化だけではなく、ビジネス文化や商習慣、販売チャネルの違い、決済手法、各地域のサポートパートナーとの契約など難しい問題が多々出てきました。だんだんとエコシステム全体でグローバルに対応していくときの悩みへシフトしているのを感じます。

ライブラリーはなければ作る！ 現在はClosure Libraryを活用

佐藤：少し技術的な側面についても触れたいと思います。海外展開をし始めた頃のPHPはバージョン4だったので、言語標準では国際化には対応していませんでした。そのため自前でPHPのライブラリを書きました、そういった時代です。ただ、現在はグローバリゼーションのためのフレームワークとして、とりわけバックエンドで導入しているものはないと思います。言語標準の仕組みが整ってきたからです。ただし問題はフロントエンドで、JavaScriptの国際化は機能に乏しくタイムゾーンの変換さえできません*7。よくある例としては、航空機のフライトで出発地と到着地のタイムゾーンが異なるときに、カレンダー上ではどう表示させるのかといった問題があります。最近はECMA-402*9としてI18Nの標準化も進んではいますが、残念ながらInternet Explorer 11の対応は不十分で、任意のタイムゾーンを指定した日時の変換ができません。企業向けソフトウェアとしてはまだまだIE 11のシェアは無視できないのでフレームワークに頼る必要があります。

サイボウズでは、Googleが公開しているClosure Library*8を活用して、タイムゾーン周りの表示や計算をしています。日付や数値のフォーマットも同じようにClosure Libraryを使っています。企業向けサービスになるとサポートが長期化するため、継続的にメンテナンスされているかどうかは慎重にみて判断しています、Closure LibraryはGmailなどでも使われているため実績は十分ですね。

あとは、サイボウズ製品と組み合わせてよく使われる他社のソフトウェアがどのように国際化されているのかを調べる必要もありました。具体的にはマイクロソフトOfficeになりますが、例えばCSVで数値を扱うときに小数点の区切りがロケールで異なるため、Excelでimport/exportするとどう変換されるのか注意する必要があります。また、文字コード（Shift_JIS）の扱いも同じような問題です。これを一般のユーザーに理解してもらうのはなかなか難しいです。

次にkintoneの場合ですが、kintone上で動作するアプリをユーザーが国際化するための仕組みを、プラットフォームとしてどこまでサポートするのかという別次元の問題が出てきます。ラベル、数値、日付、タイムゾーンの問題に対応するような機能を実装する必要がありました。ローカルのマシンでExcelの日付関数を扱おうとしたときには通常、ローカルのタイムゾーンを使用します。ところがグループウェアはWeb型の共有モデルなので、どこのタイムゾーンをベースに日付計算をすればよいか基準が必要になってきます。やってみるとこうした泥臭い問題がいくつも出てきました。ひたすら調査をして1つ1つ問題を潰しながら仕様を決定していく必要があります。

社内の翻訳用語をkintone製ツールで管理

河村：続いて翻訳のフローに関してご紹介します。L10Nですが、中国語（簡体字）は上海の拠点に翻訳を依頼していますが、英語に関しては特に翻訳という意識をしていません。エンジニアにから機能の説明を聞いたり仕様書を読み込んだり、実際にテスト環境を操作したりしながら、日本語と英語の文言を決めています。英語をイメージしてそこから日本語が決まることもあります。"英語としての自然な表現"を常に心がけています。

サイボウズの河村氏

UIの文言は100％内製で、米国でユーザビリティテストを実施して文言の確認をしています。例えば、画面を作るボタンを「Build Up」にするか「Create」するか、実際に被験者に確認してもらってしっくりする単語を決めていきました。サイボウズ社内では、日本語と英語を担当し、中国語は現地スタッフ、タイ語は現地パートナーにそれぞれお任せしている状態です。最近では台湾市場から繁体字についても要望が届いている状況です。

その一方で、マニュアル類は翻訳会社に依頼することも多いです。また、これから機械翻訳にもチャレンジしようかと考えています。ただ、実際には思い通りの翻訳があがってくることは少なく、テスト環境を提供してもなかなか操作してもらえなかったりと、難しい部分はあります。昔は膨大なドキュメントをただひたすら日本語にするという時代があり、その頃から開発と翻訳の現場は分断されていました。アウトソースすると文脈がわからずに翻訳が難しくなるという弊害はありますね。

注意点としては、必ず操作環境と翻訳メモリーを提供すること。マニュアル用に以前はOmegaTを使っていましたが今はTradosを使っています。また、訳文については必ずチェックして改善ポイント（単数・複数の違いや能動態と受動態の違いなど）を伝えています。

kintoneで構築された社内の用語管理ツール

ローカライゼーションで使用しているツールとしては、自社サービスであるkintoneで文言管理のアプリを作って日英中の3言語を管理しています。アプリの操作画面から、コメント機能で直接開発担当者にメンションを送ったり、翻訳の進捗状況をステータス管理できたりします。アプリ上で文言を変更すると、それを自動的にプロダクトに読み込めるため、kintone上で翻訳から開発・実装までのワークフローが完結できるようになります。TMS（translation management system）、GMS（globalization management system）としての機能はこのkintoneアプリですべて賄える優れものです。

UXライターという職種―1ワードいくらの世界じゃない！

河村：私はもともとマニュアル翻訳が専門だったのですが、いまは「UXライター」という肩書で主にGUIの翻訳を担当しています。翻訳もUXの重要な要素の1つで、単純な文言の翻訳ではなく、操作性や文脈を勘案したうえでの単語選定を意識してます。ユーザビリティテストもよく実施していて、ユーザーに響く、また誤解のない表現を常に心がけています。

よく翻訳の世界では「1ワードいくら」という料金換算をします。マニュアルに関してはまだそれでも良かったのですが、UIの世界でそれはありえない。たったひとつの機能に関する単語を何時間も考えたり、ネイティブの人に相談したりしてものすごく時間がかかっています。UIの翻訳は1ワードいくらでは測れません。

また、単語を調べるときはGoogle Trends*10を使って"流行り"を確認するようにしています。ユーザーが実際に使うキーワードを調べられるツールとして有用で、例えばひと昔前はメールを「e-mail」と表記していましたが、最近は「email」が主流でハイフンは省略されています。

校正にはスペルチェックツールとしてGrammarlyを、スタイルガイドは自社製でwikiで管理しています。用語管理は先ほどのkintoneアプリに一本化しています。CSV出力にも対応しているので、kintoneからCSVファイルに出力したものをTMX（Translation Memory eXchange）形式に変換して翻訳会社と共有しています。

重要なのは技術的な実装コストとビジネスとのバランス感覚

佐藤：国際化は突き詰めれば際限なく理想が広がっていくテーマですね、議論は尽きないです。現実的には、現在取り組むべき課題とそれを実現するためのコストなどを鑑みて、ユーザーが喜んでくれるところから取り組みを進めるのが良いのではないでしょうか。昔に比べると情報もたくさん出てきていますし、言語やフレームワークなどの標準的な仕組みはだいぶ整ってきています。そのうえで、プロダクトごとに特性を出すため自分たちで開発していく部分は必要かもしれません、それが差別化の要点として強みになっていく場合もあるからです。

この記事のもとになった書籍
西野 竜太郎 著 価格：2,400円＋税 発売日：2017年10月16日発売 ISBN：978-4-295-00255-0 発行：インプレス	ソフトウェアグローバリゼーション入門 国際化I18Nと地域化L10Nによる多言語対応 Webアプリケーションやスマートフォンが広く使われる現在、世界中で使われるソフトウェアを開発・配布するための障壁は薄まりつつあります。しかし、多くの人たちに使ってもらうには、さまざまな言語や文化に対応した、グローバルなソフトウェアを開発しなければなりません。本書はソフトウェア開発におけるグローバリゼーション(Globalization, G11N)をテーマにしています。その概要と開発プロセスについて触れた後、二つの大きな分類である国際化(I18N)と地域化(L10N)について、それぞれ詳しく解説しています。