ISO17100について

弊社ではISO17100の認証を2016年7月に取得しています。以来、2回の更新を経て、今年の第1回維持審査も「改善点なし」で認証が更新されました。
ISO17100について、2023年現在の弊社の実状況も踏まえてお伝えいたします。

ISO17100では、「品質の高い翻訳サービスの引渡しに必要なコアプロセス、資源及びその他の側面についての要求事項を規定」しています。言い換えれば、ISO17100で定める適切な翻訳プロセスに則って、それぞれの立場(ロール)に適切な資格と力量のある人がプロセスを遂行する。ということです。

ISO17100取得のメリット
弊社の場合、これまでISO17100を条件に案件を受注したことはありません。むしろ、弊社内のプロセスが業界基準に合っているものなのか、改善点はないか、を確認するために認証を取得いたしました。
実際、毎年の認証審査を受ける中で改善点や追加すべき点をご指摘いただき、指摘いただいた項目は、ISO17100対象プロジェクトだけではなく、全プロジェクトに展開しています。

プロジェクトフローの改善だけではなく、登録翻訳者様や社内スタッフのロール別の力量、資格も毎年見直し、更新して情報をシェアすることで、力量アップへのモティベーション向上にもつながっています。

ISO17100の要求事項
箇条1 適用範囲
規格の適用範囲の説明

箇条2 用語および定義
規格で使用される用語の定義。各担当者のロール名もここで定義されています。たとえば
バイリンガルチェック/バイリンガルチェック担当者
モノリンガルチェック/モノリンガルチェック担当者
一概に「チェック担当者」と言っても英語と日本語を対訳でチェックする工程(バイリンガルチェック)と、そのドメインやプロジェクトに精通した担当者が日本語ベースでチェックする工程(モノリンガルチェック)があり、そこをしっかり分けています。当然必要とされる資格/力量も異なります。

翻訳者の資格は以下のとおりです。
(1)認定された高等教育機関(主に大学や大学院)の翻訳、言語学、言語研究関連学位、または同等の教育機関での翻訳訓練を含む学位を取得
(2)認定された高等教育機関の翻訳以外の学位取得+専業専門家として2年の翻訳経験
(3)専業専門家*として5年の翻訳経験」
*専業専門家の定義としては、当初は12,000ワード/月という目安がありましたが、今は6,000ワード/月 程度となっているようです。
2015年の施行開始から7年を経て、少しずつ変わってきた項目もあります。
たとえば、バイリンガルチェック担当者も同等の資格を必要とするといった基準は、同じプロジェクトを5年程度、校正している場合は十分に要件を満たすということになってきているようです。
弊社ではこの解釈の変更に合わせてISO対象プロジェクトの拡大を行っています。

箇条3 資源
以下の各資源の整備・記録・更新について規定。
人的資源:各プロセスを担当する担当者の資格と力量の定義
技術資源:一連のプロセスに必要な機器、システムなど。

上記、箇条2で書いた通り、認証取得当初の翻訳者とチェック担当者の要件(資格・力量)については、規格開始から時間が経つにつれ、少しずつ実態に合ったものに変更されているようです。

箇条4 制作前プロセスについて
引き合い、見積もり、クライアントとの合意、クライアント情報の取り扱い、プロジェクトの準備、管理活動として、プロジェクトの登録、割り当て、技術資源、スタイルガイドについて遵守すべき項目が提示されています。

弊社の場合は、年間契約になっているクライアント様が多いので、引き合いがそのままハンドオフとなるケースがほとんどです。この全工程が1日で終わる場合もあれば、何か月もかけて進める場合もあります。また、クライアント様の多くが海外のため、時差を考慮して十分な準備を行い、無駄な時間を使うことがないようにしています。
スタイルガイドについては、お取引開始の時点でスタイルガイドなどのガイドラインがないクライアント様については、弊社でガイドの作成をご提案しています。ご提案したスタイルガイドがそのままその会社のローカライズガイドラインとなっているクライアント様もあります。

箇条4 制作プロセスについて
ISO17100で定めるプロセスは、以下のとおりです。

プロジェクトの引き合い > 見積り > 開始連絡 > 翻訳者の選定 > 校正者の選定 > プロジェクトの記録 > 翻訳者へのハンドオフ > 翻訳(クエリのやり取り) > 翻訳者の納品前チェック > 翻訳者からのハンドバック > バイリンガルチェック担当者へのハンドオフ > バイリンガルチェック担当者によるチェック > (コンパイル/DTPなどのプロダクション:必要な場合) > プロジェクトマネージャーの納品前検品 > 納品 > クライアントからの修正依頼 > 最終納品 > TMの更新

各工程において、弊社では自社開発ツール(クエリの管理を行うQT、翻訳品質向上に役立つQAツールEDT:Error Detection Toolなど)を多用しています。自社開発なので、プロジェクトに応じて素早いカスタマイズが可能です。これらのツールは弊社で扱う全プロジェクトで使用しています。

またこの項目では各フローで担当する担当者についても、明記されています。
弊社の場合、プロジェクトによってはいくつかのロールを1人のスタッフがこなすことがあります。たとえば、あるプロジェクトでは、プロジェクトマネージャーがバイリンガルチェッカーの役割も同時に果たしたり、バイリンガルチェッカーがLinguistic QAを担当したり、コンパイルなどのプロダクションを担当することもあります。その場合でもそれぞれのロールにおける資格や力量がISO基準を満たしていることを確認しています。

「1人1人がプロフェッショナル」という意識を常に持ち、プロジェクトの性質やスパン、スタッフのスキルによって柔軟な対応で多様なお客様のニーズに応えるようにしています。

余談になりますが、
今年の審査員の方が弊社の業務内容を審査された際に
「デプロさんはとんがった業務を多くされていますね」
というコメントをいただきました。
これまで上手く自分たちの会社の特徴を言い表す表現がみつからなかったのですが、とてもいい表現を頂きました。ありがとうございます。

弊社ではどの言語でも、どんなプロジェクトでも対応します!とは言いません。
自分たちが本当に自信の持てる分野で、お客様の要求にしっかり応えていく、そんな「とんがった」ローカリゼーションサービスプロバイダーでありたいと願っています。

ローカライズがらみでお困りの方、まずはご相談ください。

日本語の翻訳単位の最後にある半角スペースの保持

Tradosのエディターで日本語の翻訳単位の最後に半角スペースがある場合、訳文生成やExportによってこのスペースがなくなってしまうことはあまり知られていないようです。

たとえば原文ファイル (word) に以下のようにコロンの後に半角スペースが入っている場合:

Tradosにファイルを入れると、以下のように半角スペースは見えなくなります。

これは、表示を

にしていた場合です。これをすべてのコンテンツを表示

にすると

それぞれの翻訳単位の後にスペースが非表示で存在することが分かります。

日本語でコロンを半角にして、その後に半角スペースを入れるスタイルの場合(Microsoftもこのスタイル)、日本語で訳すときにどう処理すればいいか。
単純に考えれば、スペースは非表示で残っているんだから、何もしなくてもいいのでは?と思いますよね。つまりAll Contents表示で

と処理する。ところが、これで訳文を生成(またはExport)すると、以下のように半角コロンの後のスペース(非表示部にあるスペース)は消えてしまうんです。

これについては、Trados2007の時代から翻訳単位の最後に入れた半角スペースは消える、と公式にSDLさん自身が認めていらっしゃいます。

SDL Trados Studio 2015 SR2で

*****************
Enhancements to processing white spaces when using Japanese as a target language. As a general rule and as before, a space at the end of the segment is removed. However, a space is added or kept after the following characters: single-byte colon, semi-colon, question mark or exclamation mark. Studio makes sure that the space between the segments is kept after these characters.
セグメントの末尾のスペースはこれまで通り削除されるが、半角コロン、セミコロン、疑問符、感嘆符が末尾にある場合は、1つスペースが追加/保持される。
*****************
ということなのですが、実際、プロジェクトを運用していく上では、以前と変わらず特別な処理が必要です。

そこで弊社では長年、このような場合は翻訳者様にお願いして末尾にスペースを入れて「●●」を追加するという処理をしてきました。つまり、
英語:

日本語:

でもこうすると非表示の半角スペースがあるのだから、●●のあとにスペースが残って生成後に●●を取った後はスペースが2つ重なりそうですよね。でも生成してみると以下のとおり、●●の後にはスペースは入っていません。

生成後のファイルで「●●」だけを削除すればOKです。
ではスペースを1つ入れて●●を入れなければどうなるか。つまり、
英語:

日本語:

です。生成してみると以下のとおり、スペースが1つちゃんと入っています。

これでよくない?って思われるかもしれませんが、実はこのスペース、TMでは保持されないんです。この翻訳単位を登録したTMをTMX形式でExportすると、スペースが登録されていません。

●●を付けたほうはスペースも登録されています。

ということで、やはり正解は
英語:

日本語:

です。

ちなみに、同じファイルに更新があった場合、Perfect Matchをかけると、末尾のスペースは以下のように保持されます。

でもTMには登録されていませんので、別の場所で100%マッチとなったところは、
TMから取得するとスペースが取れてしまいます。

TMに記号が入っているのを嫌がられるお客様もいらっしゃるのですが、このような事情によるものですので、ご理解いただければ幸いです。

DTPを発注される際にご指示いただきたいこと

日本語でのDTP(Desk Top Publishing)をご依頼いただく際、前もってお客様に決めていただきたいいくつかの必須項目がありますので、以下に例とともにまとめます。

Source File (ソースファイルの有無)Yes / No
Application (アプリケーション)InDesign / Framemaker / Office(Word/PPTX)
Version・(バージョン) 
OSWindows / Mac
Original paper size (原本の用紙サイズ)Letter / A4 / A3 / others
Deliverable paper size (翻訳後の用紙サイズ)Letter / A4 / A3 / others
Font to be used (使用するフォント)Alphabets/numners:Calibri
Japanese:メイリオ
PDF generate (PDF作成)Yes
PDF type (PDFの用途)Web / Print
Joboption specified (ジョブオプションの有無)Yes / No
Italic (イタリックの使用)Italic / BOLD / Normal
  • ① ソースファイルの有無。

PDFしかないのだけれど、というご相談をよく頂きます。PDFからでも同じ体裁のものを作成することは可能ですが、そのPDFの元となるソースファイルがあれば、コストを低く抑え、品質も良いものが作成できます。また翻訳ツールを使用して、翻訳を行うことで、バージョンアップ時のコスト削減にもつながります。

  • ② ソースファイルがある場合は、アプリケーションとそのバージョン。

  • ③ 用紙サイズ:原本はLetterサイズであるが、日本語版はA4にしてほしい。またはLetterのままでいい、など。
  • ④ フォント:アルファベットと数字のフォントおよび日本語のフォント。
    複合フォントを使用する場合、フォントサイズの違いが出ることがあります。
    たとえば、アルファベットと数字に「Calibri」を、日本語に「メイリオ」を選択された場合、以下のようになります。

フォントサイズは同じ18ポイントですが、英語は小さく見えてしまい、バランスが悪くなります。
そのため、日本語のフォントサイズを下げるか、英語のフォントサイズを上げるか、で調整します。

バランスはよくなりますが、アプリケーションによってはこのフォントの調整は手作業になってしまいます。ソースファイルがWordやPPTXの場合です。前もって複合フォントを使用できる場合はドキュメントを通してそのフォントを使用します。

  • ⑤ ジョブオプション:昨今、PDFの多くは印刷目的よりもWebからダウンロードするものが多いため、ファイルサイズは小さいほうが好まれます。ただ、中にある画像の解像度は上げたい。そのようなPDFの作成仕様をお客様の方でお持ちの場合、ご提供いただければ、一定の品質でPDFが作成できます。固有のものがない場合でも印刷するものなのか、Webに載せておくものなのか、など用途をお知らせいただければ既成の仕様で作成いたします。
  • ⑥ イタリックの使用:日本語では通常イタリック(斜体)は使用しませんが、原文がイタリックになっている場合、日本語ではどうするか。翻訳中にタグを削除してしまえばいいのですが、CATツールを使用した場合、翻訳後のQAでタグ数の不一致となってしまうため、そのまま残しておいて欲しいというお客様が多いです。その場合DTPやコンパイル時にイタリックスタイルを削除したり、ボールドにしたりすることがあります。