プロのレビュープロセス教えます

前回は、実務翻訳プロセスについて説明した『プロの翻訳プロセス教えます』を書いた。今回は、その続編『プロのレビュープロセス教えます』を用意した。

チェッカーの仕事は翻訳とは少し異なる。「具体的にどのようなプロセスを用いるか」という情報はあまり開示されていない。

ぼくなりのやつを紹介しよう。

ワークフロー

翻訳プロセスと同様に、自分なりのレビューの作業をある程度決めておくと効率がよくなる。

全体的な品質の確認

レビューという仕事を受ける限り、それがレビュー以上の仕事を必要とするものであってはならない。

話にならないような品質のレビューであれば、多くの時間を無駄にすることになる。

まずは、全体にざっと目を通して、「訳文がレビューするに値するか」をチェックする必要がある。これは非常に大事なプロセスと言える。実際にプロジェクトを開始し、途中からこの事実に気がつくと、非常にまずいことになる。

ぼくの場合、全体の30パーセントを上回る修正が必要だと思われる場合は、レビューという形での仕事はリジェクトする。その場合、エディット（編集）の話を持ちかける。

このチェックは、プロジェクトが割り当てられたときにすぐに行い、問題があればすぐにプロマネに連絡することが大切だ。

プロジェクトの確認

全体的な品質に問題がなく、レビューという仕事に値すると判断できた場合は、次のプロセスに移る。これも、翻訳のときと同じように、プロジェクトの詳細を確認する。ここで以下に注意を払う。

どのような内容のプロジェクトか、どのようなレビューが求められているか、作業ファイルや参照ファイルに欠けているものはないか、見積もりは正しく行われているか、ワードカウントは…。基本的な情報を確認する。

ここに疑問や問題がある場合は、早いうちにクライアントやプロマネに連絡して問題を解決しておく。前にも話したが、このようなことを後から対処するとなると、いろいろとトラブルに発展するので、素早く、慎重に行っておきたい。

詳細なレビューの開始

ここで実際のレビュー作業に入るわけだが、ぼくが実際に使用しているチェックポイントを紹介しておこう。

スタイル

クライアントがスタイルガイドを提供している場合は、訳文が要求を満たしているかどうかをチェックする必要がある。よくあるのは、括弧は半角、英語と日本語の間には半角スペースを入れる、参照文書には『』を使い、参照文書のタイトルには「」を使うといったものがある。

クライアントが特にスタイルガイドを用意していない場合は、自分の信じる宗教的なスタイルを押しつけた修正やフィードバックを行うのではなく、一般的なものを適用する。

たとえば、常用漢字を使う、英数字は半角文字を使う、スペースは半角を使うなどが考えられる。

用語

用語についても同じことが言える。クライアント側で用語集が用意されている場合はそれを使い、従っていないものをチェックし、必要に応じて修正を行う。

クライアントが特にスタイルガイドを用意していない場合は、可能な限りバイアスのない、業界標準のものを使うようにする。たとえば、ITコンテンツであればMicrosoftのスタイルガイドを使用することが考えられる。

使う用語に疑問を感じた場合は、プロマネやクライアントに確認を取るとよい。

日本語の流暢さ

これは個人によって判断が異なることもあるだろうが、あくまで翻訳者を尊重した上でチェックを行うようにする。不要な修正は極力行わないようにする。

句読点がない場合や、文法的なミスであれば修正する必要があるが、「個人の好み」ではなく、あくまでリーダビリティを重視して考えることが重要だ。

修正するからには、「なぜ修正するか」を論理的かつ機能的に説明できなければならない。説明できないような「なんとなく」という修正は行わないのが無難だ。

正確さ

誤訳や役抜けなどのミスを修正する作業がこれにあたる。これもあくまで読みやすさを考慮して行う。独創性を優先しすぎて翻訳者の訳を変えてしまわないように注意する必要がある。あくまでレビューの仕事でり、編集ではないことを頭に入れておこう。

これも「流暢さ」と同様に、「なぜ修正するか」を説明できなければならない。

一貫性

アニメや映画などクリエイティブ系を除き、技術、IT、産業では、用語や言い回しの一貫性を確立することが美とされている。つまり、全体的に訳を統一することで、文書が読みやすくなるという考え方だ。

こればかりは、慣れが必要になってくる。まだレビューに慣れていないと、確認に時間がかかるだろう。慣れてくれば、自分の頭の中のコンピューターがエラーをはじき出せるようになる。ここまでなればベテランだ。

QA

これは翻訳プロセスと同様の作業を行う。XbenchやVerifikaにかけて数値や用語のミスをはじき出す。ここでは、タグのチェックも可能なので、タグの不一致や欠如がないかもチェックする。

タグがきちんと配置されていないと、翻訳が完了しても正しくDTP作業が行えなくなったり、遅れが出たりするので、これもレビューアーが責任をもってタグを確認する必要がある。

可能であれば、QA作業が完了したら、エクスポート機能を使用してレポートをファイルに保存し、関係ないエラーをマークしたり、修正しなかった箇所をマークしたりしてコメントを加え、これも一緒に納品できるようにしておくとよい。

プルーフリーディング

すっかり毎回おなじみになってしまったが、プルーフリーディングを行うに当たり他のデバイスにファイルをコピーしたり、ファイルを物理的に印刷したりして形態を変えてリーディングを行う。

いつも同じことを言うのではつまらないので、もう1つプルーフリーディング方法を紹介しておこう。

多くのCATツールでは、Microsoftオフィスドキュメントファイル（docやdocx）へのバイリンガル形式でのエクスポートが可能だ。オフィスファイルにエクスポートしてからファイルを開くと、オフィスならではなの日本語スペルチェックを利用できる。オフィスのチェックには文法チェックや一貫性チェックもある。これが結構役に立つ。

フィードバック

ぼくは、クライアントに「フィードバックを書いてくれ」と言われなくても、レビューアーはフィードバックを書くことが重要だと考えている。これは、翻訳者にとっても、クライアントにとっても有益なものでなければならない。

そこで、ぼくはクライアント用と翻訳者用の2つのフィードバックを用意するようにしている。その内容を以下にまとめる。

原文について

プロジェクトによっては、原文が非常にわかりづらく、翻訳が困難なテキストもある。この場合、翻訳者だけでなく、レビューアーの仕事にも影響が及ぶ。これを正直にフィードバックすることで、この会社の今後の作業効率を向上できる可能性がある。会社側も管理者の多くのは翻訳者出ないことが多いので、現場のリンギストからの意見は重宝される。

翻訳者について

これを直接聞いてくるクライアントは少ないが、「翻訳者についてどう思うか」というのは気になる点であることは確かだ。「適切な翻訳者を割り当てられただろうか」。「翻訳者の技量は十分であったか」。「今後、仕事を依頼し続けて問題ないだろうか」。このように、さまざまな疑問を抱えていることだろう。

これは別に陰口をたたくものではない。

このフィードバックは、可能な限りバイアスがかからないように行うべきだ。率直かつ正直に、どこがよかったのか、どこが不足していたか、どうすれば改善できるのか、今後もこの翻訳者のレビューを引き受けても問題ないかを説明しよう。このようなプラスアルファを提供できてこそ、プロのレビューアーというものだ。

プロジェクトについて

これは単純にプロジェクトについて思ったことをフィードバックすればいい。個人的な意見でも問題ない。楽しかった場合はその理由を、つまらなかった場合はその理由を。プロマネの段取りはよかったか、安心してプロジェクトに取り組めたかなどをフィードバックしてもいい。

これも、会社側が時折アンケート形式で質問を行うくらいなので、ささっと手短にフィードバックを書いておくと今後のワークフローが改善されることもある。

よかったところ

これを書くレビューアーはあまりいない。しかし、よかったところを認めて、それを「フィードバックするために書く」ということは自分にも学びがあるため有益だ。「動詞の訳し方がよかった」、「ややこしい副詞の連続にも、訳が工夫されていて勉強になった」。できるだけ詳細に、そして手短にフィードバックを行う。

修正したところ

クライアントが直接翻訳者にレビュー後のテキストを返さない限り、翻訳者はどこが修正されたかを知らないでプロジェクトを終えることになる。それは、非常にもったいないことだと言える。せっかくプロジェクトに関わり、それを完了するところまで行けたのだから、何かお土産を持って帰ってもらったほうがいいに決まっている。

「どこが悪かった」という言い方ではなく、「どこを修正させていただきました」というスタンスでフィードバックするといい。「句読点が少なかったので、読み手の混乱を避けるために追加しました」、「副詞の位置が誤解を招く可能性があったので、配置を換えました」。これも詳細かつ手短に、そして文句言うスタイルではなく、こういう修正を行ったというレポート形式で行うといいだろう。

納品

さぁ、レビュー、QA、フィードバックも終わった。いよいよ納品となる。レビューは翻訳よりも納品項目が多いのであらかじめチェックリストを用意しておき、納品する前に自分でチェックするとミスを減らすことができる。

これはあくまで一例だが、自分なりのチェックリストを用意して、納品前にそれを確認しておく。

アフターケア

翻訳と同様、「納品してしまえばもうオシマイ」という態度はよろしくない。今後も良い関係を続けたいのなら、納品後のフォローアップにも責任を持とう。

レビューアーであれば、DTP作成後の簡単なプルーフリーディングに付き合ったり、クエリの回答による変更などを行う必要がある。

こういったアフターケアをパッケージに入れて作業を行うだけでも、信頼できるレビューアーとしてのポジションを確立することができるので、ぜひ考慮されたい。

さいごに

翻訳プロセスと似た部分がもあるが、レビュー固有のワーフローも多い。「チェッカーの仕事も経験すべきか」と疑問に思う駆け出しのリギストも多いようだが、得られるものも多いのでぜひとも経験されることをおすすめする。

丁寧かつ詳細なレビューを行い、それを報告できることは1つのスキルだ。これは自分が翻訳するときにも役立つ。こういった「目」を鍛えることは今後、翻訳者としての財産となることは間違いないだろう。