企業で翻訳に携われる方々にとって「用語集」は非常に関心の高いテーマです。
こうしたニーズに応えるべく「用語集の利活用」をテーマにして連載記事をお届けしています。今回はその第四弾です。

第一弾、第二弾、第三弾は次からお読みいただけます。
・第一弾：翻訳における用語集の利活用①
・第二弾：翻訳における用語集の利活用②バイリンガル用語集を自動的に作成する方法？
・第三弾：用語集データ管理ツールの選択ポイント

目次

1. あらためて、用語集管理をうまく回す大方針について
2. 用語集に含まれる情報項目
3. 用語集に含まれる対象エントリの範囲
4. まとめ

「用語集がうまく活用できない理由はいくつかあります。」ということを前回の記事では説明しました。せっかく用語集を作成しても、必要な情報が付与されていないと正しく利用できなかったり、部門ごとに作成された用語集の優先順位や参考資料として提供している情報との競合があった場合の処理方法を決めていなかったり、事前に決めておけばよかったという事項がいくつかあります。また、用語集のライフサイクルについても、しっかりと管理方針を策定しないと、いつ・誰が・何のために作成/変更した用語なのかがわからなくなります。

＜決めておきたい3つの大方針＞

1. 用語集構築時の基本方針
   1. 用語集データ管理ツールの選択
   2. 用語集に含まれる情報項目
   3. 用語集に含まれる対象エントリの範囲
2. 用語集の運用方針
3. 用語ライフサイクルの管理方針

こうした3つの大方針を事前に決めておくと、用語集管理の基盤がとても強固なものになります。

今回は、第四弾としてこのうち「用語集構築時の基本方針」に関連する「②用語集に含まれる情報項目」と「③用語集に含まれる対象エントリの範囲」について掘り下げます。

前回は、入れ物としての用語集管理ツールの選択ポイントを紹介しました。今回は、用語集の「中身」としての情報項目に関連したノウハウを紹介します。
用語集に含まれる情報項目の中には、「最低限必要なもの」と、「あれば助かるもの」があります。
最低限必要なものは、以下のものです。

• 用語ライフサイクルに関連する日付および担当
  • 登録日、承認日、変更日、廃止日およびそれぞれの実施者名
• 用語のエントリ
  • 原文および訳文
• 用語のステータス
  • 提案中/承認済み/廃止など

これらの属性はどうして必要なのでしょうか。たとえば、用語集に含まれている内容に矛盾が出た時を想像してみると分かりやすくなります。

例えば、用語集には以下のようなエントリがあったとします。”cost sheet”の訳はかなり前から「原価シート」なのですが「コストシート」という言葉も登録されてしまっています。登録日を見ると「コストシート」の登録日の方が新しいため、こちらを採用したほうがいいと作業者さんは思うかもしれません。ところが、ステータスの欄を見ると「提案中」となっています。この情報があることで、T.Tanakaさんが「原価シート」から「コストシート」に用語を変更したいが、まだ承認待ちというステータスであることがわかります。この場合は、一旦承認済みの「原価シート」を作成すべきだと判断できます。登録者や変更者の名前がある場合は、その方に経緯を聞くことができる場合もあります。

次に、「あれば助かるもの」です。

• 用語の定義
• 用語の用例
• その他の事業属性（サービス名/製品名/事業部名/プロジェクト名を示すもの）
• 備考

用例や定義、その他の事業属性については、用語集に含まれていることでどういったデメリットがあるのでしょうか。こうした情報が含まれることで、判断の助けになる材料が増えることになります。例えば以下のような用語集を想定してみましょう。

“order number”は三種類の訳語が存在しています。ステータスもすべて承認済みなので、登録者や変更者に確認する以外に、判断の材料はなさそうです。こうした場合にその他の情報があると判断がしやすくなります。

事業部の属性が追加されました。自分が翻訳している文書がどの事業部に属する/関する文書かを理解することで間違えるリスクは大幅に回避できそうです。また、下記の例のよう定義や用例も付与されていると、訳語選択ミスが大幅に減少します。

次に対象エントリの範囲について説明します。まず、用語集は辞書とは異なることは明らかです。ところが用語集として提供されるものの中に、辞書的な意味の基本的な単語が含まれているケースが稀にあります。一般的、辞書的な単語まで用語集に登録されていると、翻訳者の作業効率は大幅に減少します。

用語集は、お客様から提示していただく「仕様」の一つです。翻訳サービスを提供するプロバイダー側は、その「仕様」に沿っていない場合は、「品質が悪い」という理解しています。ところが、一般的な単語は、文脈に応じて適宜訳し分ける必要があり、辞書的な意味ではない言葉で置き換えるケースも十分ありえます。その際に、「用語集と異なる用語定義を使用しました」と報告することは、かえって双方にとって手間が増えるだけです。

例えば動詞の“Do”に対する複数の定義をわざわざ用語集に登録されてしまうと、作業時に混乱の元になるのはお分かりいただけると思います。

とあった場合、翻訳者は”he”がした行為を読み解き、別の言葉に置き換えるはずだからです。これはかなり極端な例となりますが、翻訳サービスの要求事項を定義したISO17100でも、そもそも翻訳者に求められる力量として、分野に沿った適切なスタイルで専門用語を使用することが要求されています。IT領域であればその分野の用語を、医療領域であればその分野の用語を使用する技量はもともと要求されてしかるべきです。用語集が整備されていない場合には、作業者自身の判断で専門用語を選択することがほとんどです。

一方で、専門用語の中にも、業界内で統一が図られていない用語や、自社内だけで使用する用語、製品に関連する機能名称などは、その処理方針について事前に合意しておくことが望ましいと言えます。本連載の第一回でも触れましたが、用語集は階層的構造を構成することを事前に意識するとコミュニケーションがしやすくなります。また、以下のピラミッドの中で説明されている、社内用語＋専門用語を用語集の対象にすると漏れが少なくなります。

いかがでしょうか。今回の内容をまとめてみます。

•    用語集に含まれる情報項目の中には、「最低限必要なもの」と、「あれば助かるもの」が存在する。

• 「最低限必要なもの」には、用語ライフサイクルに関連する日付および担当登録日、承認日、変更日、廃止日およびそれぞれの実施者名、およびステータスなどが含まれる。

• 「あれば助かるもの」には、定義、用例、その他の事業属性（サービス名/製品名/事業部名/プロジェクト名を示すもの）、および備考欄が含まれる。

• 用語集のエントリに。一般的、辞書的な単語まで用語集に登録されていると、翻訳者の作業効率は減少する。

• 専門用語の中にも、業界内で統一が図られていない用語や、自社内だけで使用する用語、製品に関連する機能名称などは、その処理方針について事前に合意しておくことが望ましい。 

次回は、用語集を運用に関するノウハウを共有します。

関連記事

• 第一弾：翻訳における用語集の利活用①
• 第二弾：翻訳における用語集の利活用②バイリンガル用語集を自動的に作成する方法？
• 第三弾：用語集データ管理ツールの選択ポイント