home‎ > ‎

IT翻訳入門01:IT翻訳とはどういう仕事か

発表機会:『通訳・翻訳ジャーナル』(イカロス出版)1999年11月号掲載(雑誌記事)

1999年から一年あまり『通訳翻訳ジャーナル』(イカロス出版)という業界誌に「IT翻訳入門」というタイトルで連載記事を書かせていただく機会がありました。現在同誌は年四回発行ですが当時は月刊誌でした。このホームページの内容は、雑誌向けの原稿に加筆修正し、連載と並行して当時のホームページに公開したものです。『通訳・翻訳ジャーナル』の概要は下記のリンクから参照できます。


利用上の注意:このホームページは執筆当時(1999-2000年)の状況について述べており、すでにかなりの記述が「時代遅れ」となっていますが、原則として当時のままの内容を修正せずに公開しています。ご注意ください。

IT翻訳とは何か

IT 翻訳とは、産業翻訳でも需要が多いと思われる IT = 情報技術に関連する分野の翻訳を指す言葉です。具体的にはソフトウェアのマニュアルを翻訳する場合が多くなります。ソフトウェアのマニュアルには、紙のマニュアルとオンラインヘルプの2種類があり、どちらも翻訳対象となります。数年前までは紙のマニュアルのほうが主体でしたが、Windows 95 の登場と前後してオンラインヘルプが十分高速に使えるほどマシンの処理能力が向上してからは、オンラインヘルプのほうに主体が移っています。

紙のマニュアルとオンラインヘルプでは内容的に重複する部分も多いことから、ソフトウェアベンダー各社は内容を効率良く作成する方法をいろいろと工夫してきました。たとえば両者の原稿を可能な限り共通 化して流用をはかったりしています。ちなみに紙のマニュアルの原稿は Adobe FrameMaker で作成されることが多いようです。Microsoft Word も一部で使われています。

オンラインヘルプは現在、Windows 95 で使われていた WinHelp と、Windows 98 以後の新方式である HTML Help の 2 通りの方式が混在しています。従来の WinHelp では winhelp.exe というヘルプエンジンを使って拡張子 .hlp のファイルを表示していましたが、今後はウェブと同じ HTML ファイルを元に作成できる拡張子 .chm の HTML Help 方式に移行していく予定です。

ソフトウェアは皆さんご存じの通りアメリカが圧倒的に強く、欧州でもアジアでも、アメリカで開発されたソフトを自国語版に改造して利用することが多くなります。このように、ソフトウェアを各国語にあわせて改造する作業をローカライズ、またはローカリゼーションと呼びます。IT 翻訳はローカリゼーションの中で大きな比重を占める作業ですが、翻訳だけがローカライズではありません。

たとえばアメリカと日本では時刻の表示方法も違いますし、重さの単位や長さの単位、休日も違います。このような箇所はローカライズ先の文化にあわせてソフトウェアの内容を変更することになりますし、日本語独自の処理機能のように、アメリカのソフトウェアにない機能を日本語版で追加する場合もあります。このような作業も、ローカリゼーションの重要な仕事のひとつです。

このようにみてくると、IT 翻訳業界は、ソフトウェア業界と翻訳業界の中間に位置する業界ということができるでしょう。

IT翻訳の特徴

実務翻訳には、技術文書の翻訳、特許翻訳、医薬系翻訳、ビジネス文書翻訳、映像翻訳(これは場合によっては文芸翻訳か?)などいろいろな分野がありますが、その中にあってIT 翻訳には次のような特徴があります。

英文が平易である

ソフトウェアのマニュアルの原文を書いているのはアメリカのライターの人たちなわけですが、多くのライターの人たちは技術的な内容をできるだけ平易な英文で表現するという原則をまずまず守ってくれるので、マニュアルの原文は英語としては平易な場合が多いと思います。

例外として、製品の市場投入を特急で行いたい場合に、ソフトウェアもバグだらけのベータ版、マニュアルも途中の原稿という状態で翻訳を開始しなければならなくなり、英文側の完成度の低さに苦しめられるケースもたまにあります(それほどでなくても、翻訳直後に改訂版が送られてくるのは日常茶飯事です)。

それにしても、Business Week の記事みたいに見慣れない単語が頻繁に出てくる(見慣れないのは私が無知だからでしょうが...) こともないし、複合文のややこしい構造などの解釈に困るということはあまりありません。逆に言えば、ソフトウェア マニュアルの英文程度で解釈に苦しんでいるようでは、英文解釈の基礎から勉強し直す必要があるでしょう。

専門知識の比重が大きい

英文が平易だからといって、そこに書いてある内容も平易かというと、全然そうではありません。これは、自分の専門外の学術文献が日本語で書いてあっても簡単に理解できないのと同じ理屈で、書いてある内容を理解するには、背景となる専門知識が必要になることがよくあります。

同じマニュアルでも初心者を対象として書かれているものは、ほとんど予備知識なしに訳せる場合もあります。一方で、たとえばデータベースやオブジェクト指向などの個別 分野についてある程度深い知識を持っていないと訳せない仕事が来る場合もあります。

たとえば出版における IT 翻訳の場合、Word 入門や Windows 入門というような初心者対象のチュートリアル(手引き書のこと)について、日本はアメリカよりも進歩していると言っていいくらい、日本の出版社はいい仕事をしていると思います(「すぐわかるシリーズ」とか「よくわかるシリーズ」とかいう本の図解式説明のわかりやすさは、日本のまんが文化の基盤があってこそ開花したのだと思います)。

そういう意味で、チュートリアル本は英文和訳で制作するより日本人のライターが書き起こして制作するケースが多くなるために、IT 翻訳の仕事として回ってくるのは、より難易度の高い本の側に重心があるとみていいでしょう。

このような状況のなかで、易しい内容しか翻訳できない翻訳者に対して翻訳会社が依頼できる仕事は、かなり限定されてしまうため、野村監督による阪神タイガースの投手起用のように、発注側の翻訳会社は翻訳者の起用法に頭を悩ますことになります。逆に言えば、どんな IT 分野でもそれなりに翻訳できる守備範囲の広い翻訳者のほうが翻訳会社からみて使いやすいので、仕事を出す対象は優秀な翻訳者のほうに偏っていくことになります。

独特のファイル形式に対応する必要がある

翻訳者というと英文の原書と辞書を左右に拡げて原稿用紙やワープロに向かっているような印象がありますが、IT 翻訳では、翻訳者の向かう相手は必ずパソコンで、原文も辞書もパソコン上に存在することになります。

他の分野の実務翻訳だと、翻訳対象の英文が支給される形態として、紙の原稿、そのコピー、あるいはそれを翻訳会社からファックスしてきたもの、あるいはそのファックスの元原稿がクライアントからのファックスだったりしてファックスのファックス、ファックスのファックスのファックス...という輪廻転生はともかく、紙原稿の場合が少なくありませんが、IT 翻訳においては多くの場合、英語の原文は英文ファイルで支給されます。

問題はそのファイル形式です。翻訳者は、英語の原文を著作したライターなりエディターが使用したソフトウェアの保存形式の英文ファイルを受領することになります。 たとえばそれは、Microsoft Word だったり、Adobe FrameMaker だったり、Word の RTF フォーマットだったり、HTML だったりします(ただしこの状況は、翻訳支援ツールである TRADOS の登場で変化しつつあります)。

IT 翻訳でも書籍の場合は英文ファイルがなく、紙原稿 (英文の原書など) を元に翻訳する場合が多いようです。これは、出版翻訳においては米国での原本の出版社と日本での翻訳本の出版社が違う会社であり、相互に原稿ファイルをやりとりする習慣がまだあまり根付いていないことが原因と思われます。

ソフトウェアのマニュアルやウェブサイトの翻訳の場合は、今日では翻訳会社から翻訳者に対して英文ファイルが支給されるケースがほぼ 100% と言ってよいでしょう。

WinHelp のオンラインヘルプは原則的には Word で RTF ファイルとして原稿作成する以外に作成手段がないため、原稿は必然的に RTF フォーマット、操作するワープロは Word ということになります。ただし、すでに書いたとおり WinHelp は消えゆくヘルプ形式であり、今後は HTML Help が主流になるので、ヘルプに関しては Word に縛られることはなくなるでしょう。業界動向を考えると、いまさら WinHelp を極めるよりも HTML、XML などに貴重な学習時間を投資したほうが賢いと思います。

HTML ファイルの翻訳では、市場に出回っているウェブ オーサリングツールを使うのは一般 的には危険です。特に Word 95/97 で HTML ファイルを開いて上書き翻訳するのは絶対にやめましょう。オーサリング ツールはあくまでもオーサリングのためのツールであるため、原文の HTML ファイルのタグを維持するという考え方があまりなく、英文ファイルを開いて編集後に保存すると、タグまで書き換えてられてしまう場合がよくあります。翻訳者の場合、勝手にタグの内容を書き換えることは許されませんから、これがトラブルの原因となります。むしろ、シンプルな高機能テキスト エディタで HTML ファイルを開いて文書部分を上書き翻訳するか、TRADOS で前処理してから翻訳するほうが安全です。

ちなみに FrameMaker の現行バージョン (5.5) では、ライター@米国が英語版FrameMaker で作成したファイルを翻訳者@日本が日本語版FrameMakerで開いて上書き翻訳する場合、フォントにからむ書式設定が原因でいろいろなトラブルに見舞われます (まあ、ワープロソフトをローカライズするときに、翻訳者のユーザビリティまで考慮してもらうのはなかなか難しいだろうとは思います...)。

あと、これはワープロではありませんが、TRADOS で前処理されたファイルは、英文が隠し文字に加工された独自形式の Word ファイルになりますから、これをもらったときにも壊さないように取り扱えなければなりません。

また、あまり多くはありませんがリソース類 (コマンド名やメッセージなど) を集めたリソース ファイルの翻訳の仕事も、ときどきまわってきます。たいていはテキスト ファイルですが、どの部分がリソースなのか、ある程度プログラミングの素養があったほうが編集ミスを減らせます。 

以上に述べたようないくつかのファイルといくつかのワープロ/エディタ ソフトをある程度使えないと仕事ができないというのが IT 翻訳の特徴と言えるでしょう。"Word なんてすぐ使えるから大丈夫" とみんな思うでしょうが、ふっふ、Word ってそれほど簡単でもなくて、脚注だの隠し文字だのスタイルだの各種オプション設定だのを駆使した英文ファイルを受領したときにそれらの設定を破壊したり脚注を消したりせずに、ちゃんと翻訳すべき箇所だけを翻訳して訳し抜けはしない、というのは意外と難しいんです。半角スペースを挿入する端から勝手に削除してくれる困ったオプションもあるし...。ですから、「ある程度使える」という「ある程度」を最初は注意したほうがいいと思います。

進歩が早いために継続学習が必要

私は現在の仕事に就く前は航空宇宙業界でご飯を食べていたのですが、人工衛星の開発では、プロジェクトの進行も技術の導入も10年単位 のスパンでものを考えます。これは、国家プロジェクトとして予算を立案して研究開発するという性格から来るものでもありますが、航空宇宙の分野が産業としてはすでに壮年期にさしかかっていて成熟度が高いことが主な原因と思われます。

一方、コンピュータの分野は皆さんご存じのように今がのびざかりの秒進分歩、特にインターネットがブームになってからは dog year とか web year とか言われて業界の三ヶ月が世間の1年分、三年前は江戸時代、やーあの頃はチョンマゲしてましたねーという状況です。

当然ながら翻訳者に仕事として回ってくるのは最新版のソフトのマニュアルに決まっており、最新版のソフトは従来にない機能を実現しているからこそ最新版なので、IT 翻訳者としては次々に登場する新しい言語、デバイス、機能をそれなりに消化しないと満足に翻訳ができません。

こう進歩が早くなってくると、どのように優れた翻訳者であっても長期間にわたってすべての IT 技術に精通し続けるというのはほとんど不可能になってきますし、かといってスーパーな翻訳者だけ集めて仕事をこなそうとしてもとても業界の需要を消化できませんから、おそらく今後はちょうどお医者さんが外科や消化器科や皮膚科といった専門分科に分かれることで事態に対処しているように、IT 翻訳者もデータベース系、プログラミング言語系、インターネット系などと分野を細分化することによって最新動向へのキャッチアップ負担を分散化する必要がでてくるでしょう。

また、この特徴からすぐに導かれる別の教訓は、勉強を怠った翻訳者はベテランでもすぐに墜ちていくということです。パソコンが登場して IT 翻訳の需要が立ち上がってきたときに、パソコン以前のコンピュータ産業で仕事していた人がかなりおおぜい翻訳者として仕事しようとしていましたが、それらのロートルな人たちの多くはパソコンに対応できずにどこかに行ってしまいました。なまじかつてコンピュータに詳しかった、という人のほうが「自分はコンピュータが分かっている」という自負心が強い分だけ新しい技術を謙虚に学ぶ心がけが弱まる傾向があり、自分をロートル化してしまいがちです。

IT翻訳と他の翻訳の比較

今週から3回の予定で、IT 翻訳と他の翻訳の比較を通じてIT 翻訳の特徴を外側から考えてみたいと思います。比較対象として、他分野の実務翻訳、出版翻訳、学校翻訳をとりあげます。初回の今週は IT 翻訳と他分野の実務翻訳のかかわりです。

IT 翻訳と他分野の実務翻訳の違い

実務翻訳には IT 関係以外に、産業翻訳、医薬翻訳、特許翻訳、経済翻訳、映像翻訳などいろいろの分野があります。実務翻訳を扱う会社が登場してきたのは戦後と言われていますが、大東亜戦争敗戦から今日までの日本が置かれている経済状況に変化にともない、分野毎にはやりすたりを繰り返してきました。

高度成長期にプラント輸出が盛んになったときには産業翻訳の仕事がたくさんあったそうですし、バブル景気のころには経済翻訳の仕事がずいぶんもうかったようです。バブル崩壊後、パソコン販売の成長にあわせて現在人気があるのは、ご存じのように IT 翻訳ですが、多チャンネル時代の到来にともない、最近では映像翻訳の需要ものびているようです。

翻訳者や翻訳会社には、雑に言えば、分野にこだわりがある場合と翻訳という営みにこだわりがある場合の二通 りがあります。IT 翻訳という分野に興味とこだわりがある人が翻訳者や翻訳会社の経営者である場合は、IT 翻訳の仕事がなくなってきたら IT 関係の他の仕事に就こうとしますが、翻訳という営みにこだわりがある場合は IT 翻訳の仕事がなくなってきたら他分野の実務翻訳の仕事に就こうとするでしょう。

翻訳会社の場合は「なんでも翻訳できます、やります」という看板を掲げているところも多いので、経済翻訳の仕事が下火になってきた90年代には、新たなる仕事を求めて、求人圧力の高まってきた IT 翻訳の市場に、多くの翻訳者と翻訳会社が新規参入しました。

そうやって他分野から IT 分野に翻訳の舞台をうつした実務翻訳者の一部は、優秀にもコンバートに成功したと思いますが、たいていの場合そう簡単に専門を代われるものではないと思います。ローカリゼーション翻訳にはそれなりの設備と知識が必要なので、最初の数回は仕事を受けられても、本格的なローカライザーが台頭してきた昨今では、素人くさい翻訳者や翻訳会社は通 用しなくなりつつあるのではないかと私個人は思っています。

結局いくら成長率が高い市場でも、参入者がそれにも増して集まってしまえば競争は激しくなるわけで、魚も多いが釣り人も多い大きな池で釣るか、魚は少ないけどライバルも少ない小さな池で釣るか、という判断はそれなりに大切なわけです。

いくら IT 翻訳は仕事がありそうだからといって、興味もないのにソフトウェア マニュアルの翻訳ができるほど顧客は甘くないわけですから、やはり自分の能力の範囲内で、しかも興味をできるだけ持てそうな仕事 (翻訳に限らず) を選ぶのが大事なんじゃないでしょうか。と、説教くさくなってしまいましたが、ほんとに多いんですよ、「翻訳の仕事がしたくて、コンピュータ関係の仕事が多いと聞いたので、全然わからないんですけど初歩から教えてください」みたいな人..

実務翻訳と出版翻訳の違い

IT 翻訳と他分野の比較、二週目は実務翻訳と出版翻訳を比べてみたいと思います。

翻訳者になりたいという方の中には、「訳者として自分の名前を冠した訳書を出版したい」という希望を持つ方もおられます。翻訳者の名前が出るような単行本翻訳の仕事は、一般 に出版翻訳と呼ばれます。いわゆる文芸翻訳はほとんどすべてが出版翻訳だと思いますが、出版翻訳には、文芸以外にもノンフィクションや学術書が含まれますから、文芸以外の出版翻訳の仕事のほうがずっと多いと言えるでしょう。

実務翻訳と出版翻訳の大きな違いは、翻訳報酬の支払い方の違いでしょう。実務翻訳は英文原稿のワード数や翻訳上がりの原稿用紙枚数などの従量 制で報酬報酬を支払いますが、出版翻訳では印税方式が主流です。印税はご存じのとおり売価に対して一定の比率で翻訳報酬が支払われる方式で、翻訳者の場合は 5~7 % 程度が印税として支払われることが多いようです。報酬の総額で計算すると、印税方式のほうがかなり少なくなります。もちろん、訳書が大当たりして印税で儲けるという話もごくまれにはありますが、ボーナス的に考えておく方がいいようですし、税金対策が面 倒になりがちです。

実務翻訳と出版翻訳のもう一つの違いは、実務翻訳では翻訳者の名前が出ることがないが、出版翻訳では名前がでる、という点でしょうか。この違いは、両者の本質的違いに根ざしています。

同じ翻訳でも実務翻訳の場合、翻訳者は翻訳>レビュー>技術編集>などの複数の工程の一部を担当しているのであり、翻訳者の出力は、作品ではなく素材です。ソフトウェア マニュアルの翻訳に参加した翻訳者が、実際に自分が参加した製品の日本語版を購入してみると、自分の翻訳にかなり手が加えられていることに気付くことがよくありますが、それは必ずしも翻訳がまずくて手直しされているということではなくて (もちろんそういうこともあるToTけど)、日本語版独自の仕様を反映していたり表現統一のために編集が加えられているためです。

ソフトウェア マニュアルでは1製品を1名の翻訳者だけで翻訳することはまずなく、数名で分担する場合がほとんです。そうなると翻訳者の個性が訳文に反映してしまうのは望ましくなく、仕様書などの約束事をかなり細かく決めて、訳者の個性による表現のばらつきをできるだけ抑える方向で翻訳することになります。原文と訳文の表現の距離という点でも、あまりに意訳の度合いが大きい "超訳" はきらわれ、訳文と英文の対応がつきやすい程度の翻訳のほうが一般 に好まれます。

一方、出版翻訳は、ジャンルや訳者のスタンスにより程度の違いはありますが翻訳者の出力は素材ではなく作品(というか最終製品)そのものです。ソフトウェアにおける主製品はソフト自体でありマニュアルは "おまけ" と見なされますが、出版物の場合ドキュメントが主製品ですから、翻訳はいわば主役の衣装と見なされます。

出版翻訳者の場合、特にノンフィクションや文芸では翻訳者の出力はかなり尊重されるようです。翻訳者によっては、編集者がなんらかの手を加えるのであれば自分の名前を訳者名として掲載することを許さない、という人もいます。出版翻訳者の評価がその訳書で下されることを考えると、自分が納得のいかない編集者校正を加えられた文章を自分の翻訳とみなされることは、プロの翻訳者にとって我慢できないであろうことは容易に想像がつきます。

コンピュータ関係の書籍はたくさん翻訳されていますから、IT 翻訳の場合でも出版翻訳の仕事はあります。IT 関係書籍や専門書の場合、小さい本では訳者しかつきませんが、ある程度まともなタイトルや大きな本では、監訳者がつくのが普通 です。もちろん訳者自身が専門家の場合は監訳者は不要ですが、まともな専門家は多忙で翻訳の時間は取れないので、翻訳者と分業するために監訳という枠組みを使うことが多いのです。

就職機会としては出版翻訳者になるのは実務翻訳者になるよりも10倍くらい難しいと思いますが、収入は実務翻訳者のほうが稼ぎやすいと思います。もちろん、どちらのほうがエライということはありません。どちらも社会から必要とされる職業ですから。

余談ですがときどき有名人が翻訳者として名前を載せている本があります。ああいう本ではゴースト トランスレーターがいることも少なくないようです。一度でもまともに翻訳をやった人なら、有名人が片手間にできるほど翻訳の仕事は短時間では済まないとすぐわかりますから、常識的に考えて無理だと私は思うんですけどね。

実務翻訳と学校翻訳の違い

IT 翻訳と他分野の比較の最後は、実務翻訳と学校翻訳との比較です。

英語は中学高校の6年間ほとんどすべての日本人が学校で習うので、翻訳についても学校で習っていると認識している人が多いと思います。私自身も翻訳の仕事をはじめたばかりの頃は、学校で習った翻訳と違うことをやる必然性も方法も理解できませんでした。

ですが、トライアルで苦労したり仕事で得意先の評価を受けたりする経験を繰り返すと、学校で習った翻訳と、仕事としての実務翻訳では評価のものさしが違うことを実感するようになりました。

学校翻訳のオーディエンス(対象読者層)は学校の先生です。英語の先生が英文和訳の試験問題で評価するのは、英文解釈がちゃんとできているか、課題文中の単語やイディオムを理解できているかという点でしょう。これらの採点ポイントがちゃんとできていれば、テストでは合格点をとれます。

一方、実務翻訳のオーディエンスは顧客です。顧客というのは IT 翻訳の場合、直接には納品先のベンダーやソフトウェア メーカーの品質保証担当者さんであり、最終的にはソフトウェアを購入したユーザーさんです。マニュアル類はいわゆるテクニカル ライティングの対象分野であり、読者にいかに分かりやすい文章を書くかというテーマは、テクニカル ライターの間ではいろいろと工夫もされ、議論もされ、守るべきルールもある程度は明らかにされています。マニュアルを訳す翻訳者は、翻訳者であると同時にテクニカル ライターと同じ土俵に立つことが求められているわけです。

すなわち、実務翻訳では、学校翻訳で問題にされなかったライティングの質が問われることになります。学校翻訳で評価の対象となった単語、熟語の理解や英文解釈の正確さというのは、実務翻訳では正しくできて当たり前、そのレベルで間違っているようでは翻訳者失格です。おおざっぱに言えば、

実務翻訳=学校翻訳+ライティング

という認識で、日本語のライティング品質をどれだけ磨けるかが評価の分かれ目になります。

このことが引き起こす問題は代表的には2つあると思います。

ひとつは産業翻訳の初心者がライティングの重要性を認識せずに学校翻訳でいいのだという誤解をする問題、もうひとつはライティングの重要性は認識できてもどうすれば品質の高い文章が書けるのかライティングの方法論が分からない問題、のふたつです。

後者の問題はこの「IT 翻訳入門」の連載でも大きなウェイトをしめる部分でこれからたくさん語ることになると思うのでここでは述べません。ここでは、前者の問題だけ解決できればよしとしたいと思います。解決方法は簡単で、認識を改めてもらえばいいわけですが、具体例がないとよく分からないですよねえ?うーん、具体例を書こうと努力すると筆者が挫折してこの連載が終わってしまうのが見えているので^^;(過去の経験) 具体例は勘弁してもらってヒントみたいなことを書きますね。

たとえば実務翻訳では、英文のライターの意図を汲んで文章の構造を意図的に訳者が作り替えることを許される場合があります。代行著述的なアプローチというか、超訳というか...もちろん、書き換えばっかりやってちゃだめですし怒られますが、直訳調ではかえって英文ライターの意図が伝わらないなと感じたときに、ここぞとばかりに超訳をまぜるんですね。超訳は学校翻訳では減点ですが、実務翻訳ではライティング上成功していれば「うまい翻訳者だ」という評価につながります。

ライティングは英語力というよりは国語力です。実務翻訳者の場合、英語が必要条件で国語が十分条件というか、英語はできて当然で差が付くのは国語力というか、ことばというメディアをいかに繊細にあやつれるかという能力を問われているのだと思います。

ソフトウェア マニュアルの種類

この連載では、これまで 7 週を費やして "IT 翻訳とは何か、その特徴は何で、他の翻訳とどう違うのか?" という話を書いてきました。これまでの 7 週は、連載のはじめに IT 翻訳のイメージをつかんでいただくための「概要説明」だったわけですが、今週は「概要説明」の最後として、IT 翻訳の主力業務であるソフトウェア マニュアルの種類を軽く紹介したいと思います。

ソフトウェア マニュアルの種類は、当たり前の話ですがソフトウェアの種類に応じて異なります。私は、ソフトウェアをマニュアル形態の視点から、(1) 開発系ソフト、(2) オフィス系ソフト、(3) ホーム系ソフト、(4) (ソフトじゃないけど) 装置系マニュアル、の 4 つに分けて考えています。

(1) の開発系ソフトには、ソフトウェアを開発するための開発言語/開発環境や、業務アプリを動作させるためのバックオフィス系諸製品が含まれます。Visual Studio とか Delphi とか、Back Office とか Oracle Developer とか JDK1.2 とかいった仕事がこの分類に入ります。

これらのソフトのマニュアルには、「プログラマーズ ガイド」と「リファレンス マニュアル」の 2 種類があります。プログラマーズ ガイドは開発者のためのガイドブックあるいはチュートリアルであり、リファレンスには関数やクラスなどを列挙しています。

うーん。我ながら説明が下手で寝そうですね。言い換えてみましょう。ドラクエやファイナル ファンタジーをやったことがある人なら、公式ガイドを立ち読みしたり買ったりしてますよね?あの公式ガイドで、アイテムやモンスターや呪文のような、各グループの説明を延々としてある箇所があるでしょ?あれがリファレンス マニュアルですね。ユーザーズ ガイドというのはこれとは違って、そのソフトを使うにあたって必要となるまとまった概念の解説をしているところですね。

チュートリアルというのは、ユーザーが実際に操作する流れに沿って手取り足取り解説する入門書のことで、言ってみれば料理のレシピですね。作業の流れに沿っているので分かりやすいのですが、ただ言われたとおり漫然とやってもボタン押しサルになってしまうので、チュートリアルからスタートしても、一度通 れば後はあまり読むことがないでしょう。

(2) のオフィス系ソフトは、オフィスで使う文房具のようなソフトのことです。有名なのは Microsoft Word/Excel/PowerPoint ですね。これらのソフトは基本的に文房具ですから、いかにしてすべての人がつまづかずに使えるかという点を最大の関心事としてマニュアルを設計しています (いるはずです...)。

オフィス系ソフトのマニュアルには、インストール ガイド、ユーザーズ ガイドが含まれます。中にはマクロ関数のリファレンス マニュアルが存在する場合もありますが、それは紙ではなく最近はオンラインのみで添付するのが普通 です。同じユーザーズ ガイドといっても (1) の開発系よりもかなり易しく、[ファイル] メニューの [開く] コマンドを選択して...、みたいな誰でも訳せそうな文章が続いている箇所もあったりします。

開発系ソフトのマニュアルがプログラマやシステム管理者を対象読者に想定したマニュアルであるのと違い、オフィス系ソフトのマニュアルの読者は普通 の人を想定していますから、翻訳するのも楽ですが、誰でもできる分だけ競争も激しいし単価も安くなります。

(3) のホーム系は、PC ゲームやマルチメディア タイトルのことです。でも、この分野になるともう IT 翻訳とは言えないでしょう。ゲームにはマニュアルはほとんどありません。ゲームの場合、訳すといえばリソース (UI) と readme.txt などが多い。一方、マルチメディア タイトルはその対象分野の知識がないと訳せませんよね。たとえば「恐竜辞典」のような CD-ROM は苦労して辞書を引きまくって、専門家の監修を受けてやっと終わるわけですが、こういう仕事までもソフトの翻訳と言っている場合もあるので注意が必要です。マルチメディア タイトルの翻訳は、ソフトの翻訳よりも出版系または映像系の翻訳によほど近いと思います。

ホーム系のタイトルには、マルチメディアの他にも辞書事典やエンターテイメントがあります。

(4) の装置系マニュアルですが、最近の産業機械はソフトを搭載しているのが当たり前なので、そのマニュアルの翻訳仕事が来たりします。日本の場合機械工業が強いので、CAD や CAE の分野のソフトや、検査用のソフトなどの仕事が多いようです。これらはソフトのマニュアルではあるのですが、その装置が対象としている分野の知識がないと上手な翻訳は困難です。例えば半導体の製造の一部の工程で使われる装置のマニュアルならば、半導体製造プロセスの一通 りの知識がないと翻訳は大変でしょう。

ちょっと IT 翻訳とは呼びがたい分野もありますが、ソフトのマニュアル翻訳の仕事といえば、たいていは上で述べた (1) ~ (4) のいずれかに分類できると思ってもいいでしょう。

(1999/9/14執筆)

利用上の注意:このホームページは執筆当時(1999-2000年)の状況について述べており、すでにかなりの記述が「時代遅れ」となっていますが、原則として当時のままの内容を修正せずに公開しています。ご注意ください。