Visual Studioの開発現場から（第6回）

　マイクロソフトのディベロッパー製品開発部門には，ローカライズ・チームと呼ばれるチームがあります。

イラスト：岡本 敏

　マイクロソフトの製品は，英語版・日本語版のみならず，韓国語版や中国語版，フランス語版やスペイン語版など，多数の国の言語に翻訳された製品が出荷されています。それらの多国語版製品を開発・出荷するための，一連の実作業および管理をしているのがローカライズ・チームです。

　ローカライズ・チームの中は，さらにいくつかのチームに細分化されています。(1)ソフトウエアの中に複雑に組み込まれたUI（UIはユーザー・インターフェースの略。メニューやダイアログ・ボックスなど）を翻訳可能な状態にする「エンジニアリング・チーム」，ドキュメントの翻訳を運用する「UEチーム」（UE＝ユーザー・エデュケーションの略。ユーザーが利用するヘルプやドキュメントを総称してUEと呼ぶ），多国語版製品の出荷スケジュールや修正すべきバグの優先度などの管理を多角的に行う「ローカライズ・プロジェクト管理チーム」，そして翻訳者の集団である「翻訳チーム」——などから成り立っています（図1）。

図1●開発チームの中にローカリゼーション・チームという多国語化専門部署がある

　なお，私はエンジニアリング・チームに所属しています。従って今回は，エンジニアリング・チームで行っている作業を中心にお話します。具体的には，いかにしてわれわれの製品「Visual Studio」を多国語版の製品として開発していくか，また，翻訳者の翻訳作業に入る前にいかにして翻訳しやすい環境を提供するか（翻訳以外の技術的なことを意識させないで作業に入れるような）について説明していきたいと思います。

一筋縄にはいかない多国語版ソフトウエアの開発
　ローカライズ・チームと聞くと，一見淡々と翻訳作業をしているチームのように思われるかもしれませんが，そうではありません。現実には翻訳作業の前段階の作業および後段階の作業が，全体の作業量の大きな比重を占めています。

　Visual Studioのような大規模な製品では，インストール後のファイル数は数万にも及びます。われわれは，その数万のファイル群の中から多国語化が必要なファイルを特定し，それらのファイルの中から翻訳が必要なUIを抽出，それを元に表を作成し，中でも翻訳者の間違いが，直接その製品の動作の妨げになりそうな部分に仕掛けを施します。例えば，フォント名や言語コードのような部分には，あらかじめ特殊なルールを設定して，翻訳者が間違った文字や数値を入力できないようにするといったことです（図2）。

図2●翻訳用テーブル 翻訳用テーブルの中身は，（1）翻訳に必要なユーザー・インターフェースを抽出した原文（ソース），（2）訳語，（3）翻訳者が間違った値を入れないようにする規則（ルール）——からなる。

　そもそも，多国語化が必要になるファイルの種類は様々です。UIを含んだDLLファイル，インストール時に表示されるUIやエラー・メッセージなどを含んだMSI/MSMファイル，HTML/XML/CSSファイル，そして各種ソース・ファイル（VB/CPP/C#/J#）などがあります。さらに同じDLLでも，従来のWin32で作成された「アンマネージドDLL」と呼ばれるDLLと，.NET Frameworkに対応した「マネージドDLL」と呼ばれるDLLがあります。他にもHTMLが埋め込まれているような特殊な作りの施されたDLLなど，実に様々です。

　しかしながら，どんなに特殊なファイルが翻訳対象であったとしても，翻訳者の手にそれらが渡るときには，そういった複雑な事情は一切意識することなく，翻訳作業ができるようにする必要があります。翻訳者の作業対象は，すべての翻訳対象文字列がExcelシートのような表の上にずらりと並べられたものになります。

△　図をクリックすると拡大されます 図3●翻訳用テーブルを作成するための背後にあるシステム

　従って，われわれエンジニアリング・チームは，もととなるファイルがどんなに複雑で特殊な構造を取っていたとしても，その内容を落ち度なく抽出して表化し，さらに特別なルール（図2）を，その表に対して施します。翻訳時の間違いによって，製品の動作に影響が出ることを防ぎ，あとは翻訳の専門家である翻訳チームにゆだねるところまでを行っています（図3）。

　もちろん，翻訳作業の後は，再びエンジニアリング・チームの出番となります。

　翻訳された膨大な量の表と，翻訳前のDLLやHTMLなどのファイルを組み合わせて，製品に組み込まれるファイルを生成します。

　そして，それらの翻訳されたファイルと，翻訳の不要なEXEなどのファイルをすべて組み合わせて，いよいよ製品のビルドを行います。

△　図をクリックすると拡大されます 図4●多国語版が生成され，テストでバグ・レポートがフィードバックされる概要

　ビルドによって作成された各国語版（例えば日本語版）のVisual Studioは，その後テスト・チームによってテストされ，バグが発見されれば修正してまたビルド，という作業を繰り返して，最終的に製品として出荷されます（図4）。ビルドの詳細は後述します。

　今年の7月に，われわれの次期主力製品となる「Visual Studio 2005」のベータ1が出荷されましたが，裏方で作業をしていたわれわれエンジニアリング・チームは，人知れず大きな問題やトラブルに見舞われて，いくつかの夜を徹することもありました。

　私の記憶に最も鮮烈に残っているのは，Visual Studio 2005の開発の一部に使用する社内ツールの仕様が大幅に変更になったときのことです。

　マイクロソフトの開発チームでは，その開発ツールとしてVisual Studioを中心に，合わせていくつかの社内ツールを使用しています。そのツールを使う社員が非常に多いため，ツールの大幅な変更は時として多くの社員に影響を与えます（なお，それらの社内ツール自身の開発にもVisual Studioを使用しています）。

　われわれローカライズ・チームでは，その社内ツールを自分たちのチームでの使用目的に合うように拡張して使用していました。大幅な仕様変更と，われわれの作った拡張部分との整合性が取れなくなり，それまでできていた作業ができなくなる，という状況に陥ってしまいました。

　しかし，社内ツールは常に最新版を使うことを義務付けられています。より高いセキュリティへの対応なども施されているからです。従って，われわれはその拡張部分について急遽作り直すしかありませんでした。

　作り直しは困難を極めました。長い間その部分を変更する必要がなかったため，最初にその拡張部分を作成した者は，既に他チームへと異動していたり，そのソース・コードがあまり分かりやすく書かれていなかったため解析に時間がかかったりと，必要以上に時間のかかる作業となってしまいました。