第4章：ソフトウェア国際化エンジニアの仕事

ソフトウェア国際化の問題は、「文字化け」にとどまりません。第四回目はソフトウェア国際化エンジニアの役割を、もう少し見ていこうと思います。

ソフトウェア国際化エンジニアは、ソフトウェアやシステムの設計段階から国際化について考える必要があります。設計段階で国際化を見落とした場合、問題が発覚した時点でそのソフトウェアは大幅な設計変更を求められ、ほとんどのアプリケーションコードを書き直す必要が出て来ます。例えば、国際化されていないという問題が、翻訳をする段階で表に出ることがあります。ソフトウェアを日本へ販売しようとした段階で、ユーザインターフェースやメッセージデータなどが翻訳できるような形になっておらず（いわゆるハードコードされている状態など）、慌てて日本語専用のコードを作り直し、再コンパイルすることもあるようです。

また、ソフトウェア国際化エンジニアは、標準プロトコル、標準規約、開発フレームワーク、開発言語やプラットフォームなど、常に社内外の新しい情報にアンテナを張り巡らせておく必要があります。そして、自社のアプリケーション開発時に、開発者からソフトウェアの国際化についてアドバイスを求められたときに、すぐに答えられるようにしておきます。

例えば、URIには指定することができる文字列は、ASCII文字と「?」や「/」など決められた文字列のみで、日本語などのマルチバイトはオクテット単位にエスケープ（ページコードでエンコーディング。例えば、「あ」をUTF-8でエンコーディングすると「%E3%81%82」となります。）する必要があります。これは、RFCと呼ばれるインターネット技術の仕様書（簡単に言うと・・・）で決められており、ほとんどのブラウザがこの仕様に決められた通りに動作します。ただ、サーバ側で動的にURIリンクを作成し表示する場合などに、翻訳された文字列がそのまま入り、エスケープされていない文字がURIに含まれる可能性が出てきます。この場合、リンクをクリックするとエスケープされていない文字がそのままWebサーバ側に伝えられ、アプリケーションが正しく動作しないケースが出てきます。こうしたケースをあらかじめ想定し、ソフトウェア国際化エンジニアは、パラメータをURに渡す別の方法（例えば、文字列ではなく、それに対応したＩＤなどを使用することなど）を開発者にアドバイスする必要があります。

プラットフォームや開発言語上では、例えば（有名な話ではありますが）、JavaServletではgetParameter()で文字列を取得すると、常にISO-8859-1としでデコードされ処理されるため、一度getBytes(“ISO-8859-1”)でバイトコードに変換してから、処理を続ける必要があります。英語だと何の問題もなく処理が続けられますが、日本語などを使うと文字化けなどの問題を引き起こします。これを毎回のコードレビューでチェックするのはキリがありません。どこのソフトウェア会社でも、あらかじめ決められた開発フレームワークを使ってソフトウェアを開発しています。この開発フレームワーク上に、開発者が出来るだけなにも考えないでソフトウェアの国際化を実現できる仕組みをあらかじめ組み込んでおくのも、ソフトウェア国際化エンジニアの重要な仕事となります。

ソフトウェア国際化エンジニアは、文字コードの扱いにも注意する必要があります。文字コードに関しては、Unicodeなどが標準化され、また UnicodeとJavaやXMLとの相性が良いため、国際化の問題は以前ほど起きなくなってきたと言えます。例えば、データの交換を全てUTF-8や UTF-16などで統一することで、文字コード変換は発生することなく、以前よりスムーズに異なるシステムでデータのやりとりなどが出きるようになりました。しかしながら、例えば、政府に提出する電子書類などは、全てUTF-8に統一されている訳ではありません（例えば、日本だとシフトＪＩＳ、ヨーロッパだとISO-8859-15）。また、電子メールをＵＴＦ-８で受け取ることを嫌がる人はまだ多くいます。日本語だとISO-2022-JPが、色々な歴史的背景などから多く使用されているようですが、このように、ソフトウェア国際化エンジニアは、各国で求められている要件や慣習となっている要件などについても、情報を収集し、出来るだけ国際化において汎用性の高いアプリケーション開発のアドバイスを行う必要があります。

その他に、ＲＦＣに提案書を投稿したり、Mozillaなどのオープンソースプロジェクトに参加したりするなど、ソフトウェア国際化エンジニアの活躍の範囲はかなり拡がっています。しかも、常に新しい技術を広く深く身につけられるという点は、かなり面白い仕事だと思っています。元々は、日本語がわかるという理由で、ＱＡエンジニアとして期待されるところがあるのですが、それで留まっていては仕事そのものに面白みがなくなります。この様に、ソフトウェアの国際化エンジニアといっても単なる文字化けを退治するエンジニアではなく、アプリケーションの設計から、実際のコーディング方法の提案、開発フレームワークのインプリ、コンサルテーション、さらには業界標準仕様の提案など、様々な仕事をしているのです。

次回は、米国で働く日本人と日本法人との微妙な関係についてお話したいと思います。