もはある日記

岡山県の西端で、英日翻訳をしています。ここに「も」ステキなもの「は」いっぱい「ある」よ!

「翻訳マニュアル」について思うこと

『「マニュアル」をなめるな! ~職場のミスの本当の原因~』を読みました。

筆者は職場のミスの研究者。事務ミスの原因はマニュアルの欠陥にある場合が多い、と指摘します。

欠陥というのは、必要な事項が抜けているなどではなく、マニュアルの書き方の問題です。マニュアルが長すぎたり、複雑すぎたりして、内容を覚えきれないし、そもそも読まない人もいることから、ミスが引き起こされます。

翻訳業でも、とても覚えのある話です。わずか数百ワードの文書を訳すときにも、指示書、スタイルガイド、ツールの操作説明書…と各種マニュアルを読まないと作業に取り掛かれないことが多々あります。読むのに時間がかかるのでゲンナリです。きちんと読みますが、あんまりこまごました指示がたくさんあると、本当にすべてに従うことができるのかな?といつも心配になります…。

 

本書では、ミスの原因になるポイントとその改善策を解説しています。

マニュアルが効果的に作ってあると、翻訳者は短時間で読むことができて、指示にきちんと従うことができて、浮いた時間をよりクオリティの高い翻訳物を作るために費やすことができますよね~~~。

 

 

マニュアルとは

本書では、取り扱い説明書、パッケージの注意書き、標準作業手順書、対処マニュアル、問答集、申込書、標識・ラベルなど、作業・行動の指針となる文書や図画を幅広く「マニュアル」として扱っています。

翻訳業務で言えば、以下のようなものが当てはまりそうです(IT 系の翻訳を前提としています)。

  • 作業打診メール
  • 発注メール
  • 作業指示書
  • スタイルガイド
  • 用語集
  • ツールの説明書
  • QA/納品物チェックリスト

マニュアルの文章作法

ここからは、本書で推奨しているテクニックをいくつか見ていきつつ、翻訳業にありがちなマニュアルの欠陥を見ていきましょう…私もスタイルガイドや翻訳指示書など、各種マニュアルの編集を依頼されることがあるので、そのための備忘・反省も込めて。

全てを 1 ページ以内に収める

 複数ページのマニュアルは、読み手が内容を覚えきれなくなるのに加え、作業中にページをめくらせることになり、読み手の気が散ってミスが増えるのだそうです。

現実的には、1 ページに収まらないマニュアルもあるでしょう。本書では、大型飛行機のマニュアルを例に挙げ、全体図を 1 枚に収めて、全体がいくつの部分で構成されているかを解説し、各部分用に紙を 1 枚ずつ用意して描けばよい、としています。

翻訳業では、作業打診メールや作業指示書でこの原則が守られていると嬉しいかな、と思います。メールや作業指示書 (html ファイルで提供されることもある) はモニター上で確認するので、物理的なページの概念とは相いれないこともありますが、1 画面に映る範囲に情報がまとまっているとスクロールしなくて良いので少し楽になります。分量が長くなる場合は、「作業開始前の指示」「翻訳中の指示」「納品物準備の指示」などが 1 画面に収まっていると、参照しやすそうです。

現場の「虎の巻」を採取する

長大なマニュアルが存在する職場には、その要点をまとめた一枚紙が既に存在するらしいのです。

翻訳ツールや翻訳会社のポータルの操作説明書なんかは、翻訳会社社内にそんな「虎の巻」が案外存在しているものです。

使い慣れないツールが指定されて、操作方法は公式ページを参照と指示されても、PM さんやコーデさんに問い合わせると、社内で作った簡単な操作説明書を提供してくださることが結構ありますよ…。

一発退場方式で読者を早期解放する

大多数の読者には用無しの部分がマニュアルには多いので、その部分を無駄に読ませないようにします。

作業指示書には、翻訳者向けの指示、チェッカー向けの指示、レビュアー向けの指示など、複数の作業者向けの指示が同居していることがあります。スタイルガイドの場合は、一般的なドキュメント向けのスタイル、マーケティング資料向けのスタイル、字幕向けのスタイル…と、翻訳対象に応じて参照すべきスタイルを探す必要があります。

作業者が自分に関係する内容だけをすばやく、抜け漏れなく把握できるようにする必要があります。

フローチャートは使わない

フローチャートは一見便利に思えるが、線をたくさん引っ張ると見づらくなり、効率が落ちてしまいます。早見表を使った方が便利だと、筆者は主張しています。

翻訳に関連するマニュアルでフローチャート? と思う方もいらっしゃるかもしれませんが、ときどきお目にかかります。

翻訳上の問題について、クエリするか、申し送りにするか、翻訳者のベストジャッジで済ませるかの判断や、リンク タイトルの処理方法 (英語ママにするか、日本語にするかなど) の判断など、ちょっと判断が複雑そうな場面でフローチャートが好まれるようです。

例えば、UI の訳をどのように処理するかどうかをフローチャートと早見表にしてくらべてみましょう。

f:id:I_tanja:20210105172805p:plain

フローチャート、見づらいですね(フローチャート作成スキルがないともいう)。時間をかけないと見やすいものができません。

これを早見表にすると、以下のような感じになります。作る側としては短時間で作れますし、使う側としては見やすく、検索性も高いものになっています。

製品名 日本語製品名 UI ローカライズ状況 用語集にない UI の処理方法
ProductA 製品あ 問い合わせ
ProductB 製品い 問い合わせ
ProductC 製品う 一部済 英語で残す
ProductD 製品え 英語で残す

検索しやすくする

表記を統一して、検索しやすくします。

本書では、「メール」「メイル」「mail」などを例に挙げていました。表記が揺れていると、関連する情報を検索しようとしても、検索漏れが発生するおそれがあります。

翻訳の指示で揺れがちなのは、「URL」「リンク」「参照先」などでしょうか。

更新履歴を明記する

マニュアルには最終更新日が記載されていても、以前のバージョンからどこが変更されたのか?が分からないパターンがよくあります。

それが慣れ親しんだ長大なマニュアルに対する変更だと、微妙な間違い探し(?)に時間を浪費することに…。

どのセクションを更新したのかが明記されていると確認時間を短縮できて助かります。

作業は一本道にする

マニュアルで規定する作業手順に関する話でできた原則なので、本書の意図とは異なるのですが…

翻訳マニュアルを読み込む作業に関して言えば、同じ工程に関する指示を複数のマニュアルに分散させない方がベターです。

例えば、ソースクライアントが作った指示書に加えて、翻訳会社による補足指示を記した指示書が提供される場合があります。翻訳会社の補足資料には、ソースクライアントの指示書とは矛盾する処理が指示されていることもあり…。大抵はまず一方の指示書を読み込んでからもう一方を読みますから、覚えたばかりの指示をすぐに上書きしなければならなくなって、混乱します。できれば、ソースクライアントの指示書に直接コメントを書き込んで補足した方がよいでしょうね。