翻訳者からエンジニアへのフィードバックは、JIRAなどのチケットシステムを使って、１依頼＝１チケットで管理してください。
機械翻訳の出力を翻訳者に渡して、スタイルエラーなどの改善点をレポートにまとめてもらって、みたいなやり方は非常に効率が悪いです。よろしくありません。
以下の詳細は、英日方向のローカライゼーションで、２社のMT評価・フィードバックを担当した経験からくるものです。
日本企業の多くが必要とする日英方向だと、勝手が異なる部分もあるかもしれませんが、共通する部分もあるかもしれないと思い、箇条書きで書いていきます。
・翻訳者は依頼主が想像する以上に納品物でのスタイルでの統一に神経を使っています。
なので、自社の翻訳案件を担当する翻訳者の生産性を上げたいなら、機械翻訳の出力からスタイルエラーが少なくなるようにチューニングを施すことは有力な手段です。
（もし、「スタイルエラー」がスペース有の「スタイル エラー」と混ざってても、「フィルタ」と「フィルター」が混ざってても気にしないよということであれば、その旨、翻訳会社から末端の翻訳者まで全員に伝わるように周知してあげましょう。逆に、その辺混ざるのが嫌なのに、スタイルガイドなどが未整備なら、最低限のルールだけでも決めてあげましょう。スタイルガイドがないと、一部の良心的な翻訳者が、既訳の山からルールを類推するという不毛な工数が翻訳のたびに発生します。）
・英日ローカライゼーションの現場の話ですが、機械翻訳の出力の改善点として２０個くらいチケット作成しました。
そのうち１０個くらいが実際に改善されて、残りの１０個についても、正規表現などでトライしている姿が見えたので納得感がありました。
翻訳者の仕事って、納品後の最後の姿まで見届けられることは結構レアなので、１つ１つのフィードバックについてエンジニア側での対応を最後まで知れたのはすごくよかったです。
海外ドラマ「クローザ―」でも、事件の「クロージング」まで見届けて初めて人は次に進めるのだ、と言ってました。
チケット型の管理じゃないと、翻訳者からのフィードバックを求めるたびに同じような修正依頼が出て、エンジニアの側でも貴重な時間を無駄にしてしまうと思います。
・別の会社では機械翻訳の出力へのフィードバックをdocにまとめろといわれて、結局１つのアイテムも改善されないというひどい結果が出ました。
最初に、docを読むのがエンジニアなのか、クライアント側のマネージャー層なのかとか、対象読者や目的を確認しなかった自分も悪かったのですが、これはひどかった。
・チケットに依頼をまとめる形なら、エラーが出ているセグメントをすべて列挙する必要もなく、サンプルとして１セグメントだけ挙げればよいので翻訳者の側も楽ちんです。
エラーの出ているセグメントの出力、本来想定される出力、エラー内容の説明、とかをとりあえず翻訳者は記入すればよい。
それに、docで渡されたらエンジニアの側で疑問点や不明点が出てもその後のフォローアップなどやる気も起きないかなと想像しますが、チケットなら、気軽にコメント返せますよね。
「ここどうなってんの？」ってエンジニアが気軽に聞いてくれる前提なら、翻訳者も最初のチケット作成で肩肘張りすぎずに済むので、ここでも省力化が働きます。
また、担当エンジニアチームの中でもリクエストに応じて得手不得手があるようで、正規表現ならこの人、みたいにアサイン替えをしやすいのもチケットのメリットだと思います。
・こういうタスクに向いてる翻訳者の資質ですが、おそらく
ーある程度、正規表現とか、エンジニアの側がこのエラーどうやって解決するのかなとか想像できた方がよい。
ーでも、空気読めすぎる翻訳者だと、自分が「解決できそう」と思う修正しか挙げなくなる可能性があるので、「直るかは分からんが直ったら嬉しいぞ」というエラーも挙げれる人がよい。
ー打率感覚というか、あらゆるエラーをなくすことが目的ではなく、機械翻訳に対する人間の修正（ポストエディット）の所要時間を減らすことが目的だと理解できる人がよい。
ーあと、エンジニアの時間も貴重だと分かってて、再現性の低いエラーよりも、細かいけど頻出のエラーなどを優先できる人だとよい。
ーエンジニアが日本人でない可能性も十分にあるので、その場合は英語で、日本語ノンネイティブの相手に求めている修正内容を簡潔かつ十分に伝達できた方がよい。
・上記の方向性で作業してもらうためにも、翻訳者に、事前に使用する機械翻訳エンジンの性質などを１時間くらいでレクチャーしておくとなおよしです。
JIRAのチケットでフィードバックを管理してくれた方の会社はこの辺も抜かりなく、自分もかなり勉強になりました。
文法解析＋辞書型なのか、統計的アプローチなのか、両者の折衷か、もしくはニューラルなのか、などですね。
タイプによって、どの辺をエンジニアが修正（＝エンフォース）できるかも変わってくるので。
・それと、副次的な効果として、翻訳者は基本的にポストエディットが好きではなかったり、ポストエディットで期待される内容の多さに対する不満を持っている場合が多いと思います。
そういう翻訳者にこうしたMT評価に参加してもらって、１つ１つのリクエストのクロージングまで見届けてもらうと、「これだけしっかり対応してもらって実装できないならしゃーない＝こっちがポストエディットで頑張ってみるか」みたいな、納得感からくるモチベーションアップも期待できるかもしれません。
こちらのニュースが出たこともあり、機械翻訳のチューニングのサイクルを回す上でのポイントをまとめてみました。
