僕の会社では40種類近いソフトウェア製品を開発しており、そのうち半分くらいを日本市場向けとして日本法人で取り扱っています。残りの半分は、日本市場に向いていないという判断だとか、日本語化するためのリソースを割くに値しないとか、様々な理由で取り扱っていません。また、日本で取り扱っているソフトウェアもすべて日本語化されているわけではなく、英語版のまま販売・サポートを行っている製品もあります。英語版のままでも需要のあるソフトウェアは、開発者向けのツールを中心に存在します。もちろん、日本語化するに越したことはないのですが、日本語化には時間と労力がかかりますし、それはコストに直結するのです。
現在、来年入社予定の方が２名、インターンとして週に数日会社に来ています。２名とも技術者志望なので、まずは簡単なWebアプリケーションを開発してもらおうと、PHPとMySQLを使ったプログラムの開発を課題に出しています。二人ともなかなか優秀です。
日本法人の技術者の仕事はもちろん開発だけではありません。開発は数ある仕事のごく一部でしかなく、顧客企業の一流の開発者に対するコンサルティングやプレ／ポストサポート、マーケティングや営業と連携した販売戦略の技術的側面のサポート、社内システム全般の構築から運用まで、インドの開発チームとの折衝、開発プロジェクトのマネジメントやブリッジエンジニアリング、イベントの準備やイベント会場での技術的サポート、そして製品の国際化や日本語化、日本独自のサービス開発などがあります。これは、ほとんどの外資系IT企業における標準的な業務内容だと思います。ただ、うちの会社は人数が十分でないため、マルチプレイヤーであることが求められます。実際僕自身も技術の部署に身を置きながら、マーケティングを兼務しています。マーケティングは僕たち全員にとって、昨年までかなり未知の分野でした。マーケティングのプロが居なかったのです。現在はマーケティング専門の社員も抱え、定期的に大学でマーケティングの教鞭をとっている教授を招いて勉強会も行っていますので、１年前とはかなり状況も変わってきました。これらの活動は、僕自身にとっても視野が広がるし、新たな領域に挑戦できる、刺激的なものです。
マーケティングについては、また別途書くことにしようと思います。
インターンの学生さんたちにとって、国際化と日本語化の違いというものが曖昧だったようです。
この違いというのは明白で、国際化というのは、そのソフトウェアが多国語に翻訳できる状態であることをいいます。英語ではinternationalization、略して"i18n"なんて言ったりもします（iとnの間に18文字あるからです）。国際化されたソフトウェアは、環境もしくは設定に応じて表示する言語を切り替えたりできるようになるわけです。
そして日本語化、日本語にローカライズするという作業は、国際化されたソフトウェアの日本語の部分を作ること、つまり日本語のリソースを用意することです。英語ではlocalizationといいますが、"l10n"とは言いません（笑）。
国際化やローカライズの作業は、対象別にいくつか分かれます。まずはソフトウェアのUIをローカライズするということ。たとえばメニューなどです。それから、ヘルプやマニュアルなど、ソフトウェアとは分離したドキュメントを翻訳する作業。あとは、入出力です。つまり例えば、ソフトウェアが文字列を含むデータを扱うのであれば、そこに日本語が含まれていても大丈夫かということです。この最後の項目は、ローカライズというよりも国際化の作業になります。
大昔は（と言っても何十年も昔ではないですが）国際化という部分は存在しないことがほとんどでした。ソフトウェアはある単一の言語向けに作成され、UIに表示する内容などはプログラム本体にハードコード（埋め込み）されていました。文字コードもその国特有のものが使われている場合が多く、ただ言語を翻訳しただけでは文字化けしてしまうとか、色んな問題がありました。
僕たちが扱うソフトウェアは、一部を除いてほとんどがJavaで書かれています。Javaの場合、各言語に対応した文字列が入っているリソースファイルは、propertiesファイルに記述します。これは、通常のJavaで使用するpropertiesと同じです。そして、Javaで使う標準の文字コードは、Unicodeです。Unicodeを使っている限り、日本語化において問題が発生することは殆どありません。
ただ、最近ではAjaxを取り入れたWeb UIが増えてきて、これが少々厄介だったりします。Ajaxでは文字列をJavaScript等で扱い、Webサーバと勝手に通信して文字列のやり取りなんかをしたりするのですが、その際に使われる文字コードがUnicodeではなかったり、2バイトコードを意識していない作りになっていたりする場合があるからです。この話も、別途書いてみようと思います。
ローカライズの作業ですが、まず次期バージョンや新製品の英語版propertiesファイルが開発チームから送付されてきます。この内容を翻訳していくわけですが、propertiesファイルはJavaを使える方ならご存知の通り、以下のような書式になっています。
file="File";
edit="Edit";
これを以下のように翻訳していくわけです。
file="ファイル";
edit="編集";
昔はこの作業を、毎回毎回手作業で、テキストエディタを使ってやっていましたが、最近「翻訳メモリ」なるものを導入しました。TRADOSという、その手では有名なものらしいです。プロの翻訳家もよく使うそうです。とくにIT関連では必須のツールらしいのですが、まだ使いこなせていません。
翻訳メモリは翻訳エンジンとは異なり、自動翻訳はしてくれません。ただ、一度翻訳したものを記録してくれて、次回同じ表現が出たときにデータベースからそれを取り出してくれるのです。こうした機能により、翻訳の個人差や製品ごとの品質のばらつきを最小限にすることができます。専門用語のGlossaryなんかも自動生成できたりするのですが、やっぱり使いこなせていません。
このpropertiesの翻訳ですが、たまに困ったことが起きます。たとえば、
from="From";
to="To";
という項目があった場合、どのように翻訳しますか？
このソフトウェアはメールを取り扱う機能があり、メールのFromとToの部分で使われているリソースです。この場合、
from="送信者";
to="宛先";
こんな感じに翻訳しますね。さて、ではこれでテストしてみます。
送信者： xxx@abc.com 宛先: yyy@xyz.com
ちゃんと表示されました。一件落着、と思いきや別の画面でまずいことになりました。
このソフトウェアにはメールをフィルタする機能があるのですが、表示するメールを期間指定する画面で、
期間の指定： 送信者 [2006/01/01] 宛先 [2006/10/31]
こんな表示になってしまいました。
そう、英語では"From"と"To"という同じ単語が使われる場面なのです。なので同じリソースを参照しているんですね。
この場合、意味が異なる二つの単語で、ひとつのリソースを参照しないようにプログラムを変更する必要があります。
このように、デバッグとローカライズは切っても切れない関係にあります。
そして、デバッグは海の向こうにいる開発チームにしかできない作業なので、開発チームと密に連絡をとりながら進めていく必要があるのでした。
そして大抵の場合、日本よりも大きな市場である欧米の都合に合わせてソフトウェアがリリースされる計画が立っているので、ローカライズに割くことができる時間は限られます。タイムリミットをオーバーしてしまうと、日本企業的感覚では「リリース延期」の判断になる場合もあるのですが、国際企業の場合そうはいきません。リリースされてしまいます。日本語機能がないままに。そして、日本語対応は後日パッチとして配布されたり、次期マイナーバージョンアップに盛り込まれたりするという、あまり美しくない方法でリリースされることになるのでした。
日本市場が重要視されていない製品の場合とくに、開発スケジュールにローカライズの線が引かれていないことがままあります。このような事態も、放置しておくとそのまま進んでいってしまうので、待ったをかけなければなりません。
ローカライズと一言で括っても、いろいろと作業があることがお分かりになったでしょうか。それでも、初めて製品のUIに自分が翻訳した文字が表示されたときには、開発の一部に関わったようでとても嬉しい思いをした記憶があります。あの初心を忘れたくないですね。
それから、よく海外から翻訳されたソフトウェアやそのマニュアルは、訳文独特の言い回しでとても読みにくいと思っている方が多いです。マニュアルなんかはとくに、直訳してはダメです。直訳は理科系出身者に多いとよく聞きます。語句をひとつも逃さず正確に訳しようとするからかもしれません。読み手の気持ちになって、わかりやすい表現で意訳する。ときには原文に無い表現を付け足したり、バッサリと削ったりすることも大切だと思います。このようなことをしていると、「翻訳メモリ」で使えない文章になってしまうのですが。
以上、簡単に国際化と日本語化について書いてみました。
コメント