IT翻訳者Blog

日本翻訳連盟（JTF）の個人会員の年会費が2020年4月1日から半額になります。
従来は年2万円でしたが2020年度から年1万円です。

会員になるとさまざまなメリットがありますが、経済面では以下の通りです（執筆時点）。

• 翻訳（関西）セミナー受講料：　非会員6,000円が3,000円（税抜）


• セミナーDVD代金：　非会員6,000円が3,000円（税抜）


• 翻訳祭の参加費：　2019年の場合、非会員10,000円が5,000円（税抜）


• ほんやく検定受験料：　非会員に比べて20%安い


• 翻訳白書（2017年版）：　非会員20,000円が無料（！）

その他、関連団体のセミナーなどへの参加費が割引になることもあります。

さらに、2020年5月31日まで入会金が半額になる入会キャンペーンを実施しています。
こちらの入会案内ページをご覧ください：
https://www.jtf.jp/jp/admission/admission_info.html

現在フリーランスや会社員として翻訳の仕事をしている、あるいはこれからしたいという方は、この機会にぜひご入会ください。

以上です。

プログラミング英語検定のウェブサイトで、Googleによる開発者向け英文スタイルガイドの解説記事を書いています。先月と今月は、情報を見やすく整理する「リストの使い方」でした。

リストの使い方（1）
https://progeigo.org/english-topics/2020/google-styleguide-4-lists-1/

リストの使い方（2）
https://progeigo.org/english-topics/2020/google-styleguide-5-lists-2/

リストは、ちょっとした手順を説明したり、例示をしたりする際に便利です。
英語では特に「following」という言葉とコロン（:）の使い方を覚えておくと、それらしいリストになります。

翻訳は個人で行うことが多く、その場合は橋やビル、あるいは大規模ソフトウェアを構築する際に実施するような「設計」の段階が存在するわけではない。もちろん「これからこの一冊をどう訳そうか」と翻訳者は考えるだろうから、その人の頭の中で計画なり戦略なりは立てているはずだ。ただしここで「設計」とは、翻訳者一人だけというより、翻訳依頼者（クライアント）や翻訳会社などが関係し、翻訳者が何人も参加するような状況における設計を指すことにする。

ソフトウェア開発のプロセスでは、「要件定義」→「外部設計」→「内部設計」→「実装（プログラミング）」といった順に進む。「外部設計」とはユーザーからどう見えるかという設計、「内部設計」とはソフトウェア自体をどう作るかという設計になる。またV字モデルで言うならば、以下の図のように、各フェーズに対して検証を実施することになる。


（引用元：日経XTech https://xtech.nikkei.com/it/article/lecture/20061130/255501/）


翻訳プロセスにこれを当てはめた場合、一番分かりやすいのは翻訳者が「実装」をする点だと思われる。ソフトウェア開発におけるプログラマーと同じ立ち位置である。
では翻訳の「外部設計」で何を決めるのだろうか。外部設計はユーザー（最終読者）から見てどうかという話である。だから、たとえば最終読者がエンジニアである場合、「技術専門用語がきちんと用いられている」、「エンジニア向けの日本語になっている」、「旧版マニュアルの表現を踏襲している」といった点だろうか。
続く「内部設計」は、翻訳成果物内部をどうするかという話である。外部設計を受けるならば、たとえば「あの用語集に従う」、「である調（常体）をスタイルとする」、「前回作成したTMを使う」といった話になるはずだ。

このような翻訳における設計（外部と内部）は、現在のところ翻訳会社内で実施されていると思われる。自分自身も翻訳会社にいるときにしていた。
ただ、翻訳設計は誰もが知るような公の知識になってはおらず、各翻訳会社の「ノウハウ」として蓄積されていると考えられる。ノウハウは利益の源泉になるため、翻訳会社に出してくれとは言いにくい。しかし公の知識になれば、人が同じ失敗を繰り返したり、車輪の再発明をしたりする事態は避けられる。だから大学などの公的機関が研究してまとめて公開することが社会全体からすると本当は望ましい。

実のところ、ISO 11669という国際標準規格では、翻訳の仕様を作る（つまり設計する）ためのパラメーターが提案されている。ISO 11669はお金を払わないと読めないが、その元になったパラメーター自体はMelby氏によってウェブ上に公開されている。
大きく「言語面」（原文と訳文の情報）、「制作面」（タスクなど）、「環境面」（ツールなど）、「社会関係面」（納期や費用など）と分類されている。非常に有用ではあるものの、やはり実務者から見ると少し足りない気がするし、構成がどこまで妥当なのかも分からない。こういったパラメーターも、外部設計や内部設計といった概念で分類してみるとすっきりし、かつ実務で適用しやすくなるのかもしれない。特に検証を内部設計にするのか、外部設計にするのかという分割は、概念上役立つ。

なおソフトウェア・ローカリゼーションにおける設計は自著『ソフトウェア・グローバリゼーション入門』（達人出版会／インプレス）の第2章5節で触れているが、あくまでソフトウェア設計に属する話だったので、純粋に翻訳に注目した調査研究が欲しいところである。