翻訳横丁の裏路地

We can do anything we want to do if we stick to it long enough.


昨年の意外な人気記事

昨年(2015年)一年間のアクセス解析をしてみたら、意外な記事のアクセス数が第2位になっていた。(第1位は「翻訳者の時給っていくら? [アンケート結果]」)

それは、なんと!

チェックシートは品質保証にあらず

だった。

この記事は2014年5月に公開したもので、すでに1年半が経過しているが、昨年の中旬頃からジワジワとアクセス数が増加してきた。ひょっとするとISO17100が関係しているのかも?しれない(笑)

チェックシートには大きな誤解があると感じている。特に企業内では、品質保証の一種の安心材料として取り扱われたり、品質の高さをアピールするための宣伝文句に利用されたりしているが、その運用と位置付けが正しく行われているかは、少々疑問がある。

翻訳者に対して、チェックシートに沿ったチェックの実施と、そのエビデンスとしてチェック印を付けたチェックシートの提出を依頼しているケースを昨今耳にするが、チェック項目ごとにチェックマークをつけるスタイルだとすると、チェックシートの位置付けを間違っている可能性がある。理由は、上記記事を読むと分かっていただけると思う。


JTFセミナーの感想に感謝!

「歴史と本と翻訳と」のブログ主さんであるおさやさんが、昨年末に私が行ったJTFセミナーのDVDをご覧になって、感想を記事にされています。

翻訳=製造

かなり刺激的なタイトルにされているので、私も最初にタイトルを見てドキリとしましたが、記事の中身は私が意図とした事をかなり正確に汲み取っていただけていて、感激いたしました。

実は、セミナーの後、一体、どれくらい真意が伝わったのだろうと心配していたのです。ポジティブな反応をパラパラいただいていたものの、いまひとつ自信が持てませんでした。でも、おさやさんの記事のお陰で、分かっていただける人には分かって貰えるのだと分かり、安心いたしました。ちなみに、私のJTFセミナーの報告は、JTF日本翻訳ジャーナルの次号に掲載される予定ですので、概略を知る上でご覧いただければと思います。また、セミナーの一部の内容は、明後日のサンフレアアカデミーのオープンスクールの私のクラスの中でも、お話をする予定です。


1月の名古屋翻訳者勉強会へ参加します

来年(2015年)1月18日(日)に開催される「名古屋翻訳者勉強会」にて、
翻訳の品質管理とWildLight」というタイトルでお話をさせて頂きます。

なかなか名古屋へ出向く機会がないのですが、この度、久しぶりに名古屋へ参ります。私に頂いている時間は1時間ですので、翻訳準備や翻訳チェックにおける WildLight の使用実例をデモを交えてご紹介する程度になると思いますが、WildLightの動作は理解できると思います。名古屋近郊にお住まいの翻訳者さんで、WildLightに興味ある方やテリーに興味がある方(笑)は、是非、参加をご検討頂ければと思います。ランチ会にも参加する予定です。

詳細、およびお問い合わせ・申込みは、以下のリンクよりお願い致します。

リンク:名古屋翻訳者勉強会

 


チェックシートは品質保証にあらず

5月某日某社にて WildLight 社内セミナーをさせていただきました。その時に「おまけ」として話した「チェックシートは品質保証にあらず」をここでも紹介します。

チェックシートは品質保証にならず品質問題が発生すると「チェック(マーク)をつけよう」とか「チェックシートにしてチェックさせよう」という発言をする人を良く見かけます。あたかもそれが品質対策の一般常識のような勢いで、まことしやかに登場する「チェックシート」ですが、私は品質対策として期待通りには機能しない代物と考えています。

人間には、規則的連続動作を繰り返すことで、無意識でも同じ作業を繰り返し行うことができる「手続き記憶」の能力があり、製造業のポカミス対策では、その能力を利用した方法を行っています。例えば、複数箇所のビス(Screw)締め作業の場合、「ビス締め忘れ」(ポカミス)を防止する手段として、ビス締め順番を決め、その順番に沿って作業をするという指示を作業手順に盛り込みます。これは、作業実施者がその決められた順番で繰り返し作業する事で、その作業手順が手続き記憶として記憶され、積極的に意識をしなくても(無意識でも)決められた作業手順通りに作業が行えるようになります。ここで重要なのは、もし、作業している中で1本のビスを忘れてしまった場合、手続き記憶との不整合が発生し、作業実施者にはその部品忘れ、作業忘れが「違和感」として認識できるという点です。つまり、かなりの確率で自分のミスを自己検出できることになります。

この手続き記憶が、チェックシートにはマイナスに働きます。チェックシートの目的は、何かを「確認」し、その証拠を「記録」することですが、そのフローを大まかに書いてみると以下のようになるでしょう。

  1. チェックシート確認項目を読み、理解する
  2. 確認する(チェックする)
  3. 結果をチェックシートに記録する(レ点を付ける)

このフローの中で、手続き記憶が関わるのは3のみです。1と2は精神的プロセスなので肉体的動作を伴わず、手続き記憶として記憶に定着しません。また、精神的プロセスを必要とする作業項目は人間の意識に高く依存していて、人間が意識的に思い出し、また意識的にそれを脳内で実施しない限り簡単に欠落してしまいます。つまり、無意識に動作完結する物理的作業と、継続的意識を必要とする精神的プロセス作業が混在していることが、チェックシートの品質保証上の意味をぐらつかせていると考えるのです。

トラブル発生直後のチェックシート(チェックマーク付け)追加は、問題が新鮮であるが故に意識面で緊張を与えるため、その緊張が緩和されるまでの間、精神的プロセス作業は正しく再現され品質保証の効果を示します。しかし、その緊張が途切れた時、手続き記憶された物理的動作は継続されるものの、精神的プロセス作業は行われなくなるのです。現象として何が起こるか? それは、確認行為がされていないのに、チェックシートにレ点がついているものが出てくるということです。つまり、作業実施者の頭の中では「チェックシートへレ点をつける作業」に置き換わってしまったということです。

このような背景から、品質保証のために「チェックシートを実施する(チェックマークを付ける)」という発想はとても安易ですし、余計な作業工数が増える割に効果が無いことになります。

ただし「チェックシートにする」目的が、検査・確認する項目が標準化されておらず、それらをリスト化し明文化するのであれば、話は違います。「チェック内容とその基準が明確に指示されていない」という問題への対策となりますから、 品質保証上、重要となります。(ただ、チェックシートじゃなく、作業手順書で良いわけです)

さて、ここまで書いてしまうと、「チェックシートなんてやったって、品質が良くなる訳じゃないんだから、やらないよ!」という話をされてしまいそうですが、チェックシートには「記録」の意味があります。品質管理上の「エビデンス」という位置付けが大きいです。ISOや社内規程の要求事項として「品質記録」に位置付けられている場合は、品質管理上、必要です。

要は「チェックシート」もツールですので、その目的が何か?を正しく理解し、その目的に合った正しい使い方をすることが大切です。少なくとも「品質を良くするためにチェックシートにチェックマーク付けさせて…」という、ツールの特性と目的がアンマッチな発想だけは、避けたいものです。


翻訳のヒューマンエラー対策

「ポカミス」「凡ミス」と言う言葉は、製造業に関わる方には馴染みのある言葉だと思います。いわゆる人間が起こしてしまうヒューマンエラーを「作業ミス」と「ポカミス」(凡ミス)に分類して管理しています。それぞれのミスにはその発生要因から特徴があり、それにあった対策を取って行く。そう言った品質活動が、製造の現場では行われています。

さて、これを翻訳に置き換えて考えてみました。まず、翻訳に関わるヒューマンエラーには、どのようなものがあるでしょうか?
以下に気がつくままに列記してみます。

訳抜け
誤訳
数字・記号の転記ミス
スペルミス
文法ミス
覚書、メモの削除忘れ
スタイルガイドの適用ミス
フォントの設定ミス
全角・半角の適用ミス
用語・定形訳の適用忘れ

私が製造現場で仕事に従事していた頃(二十数年前)の「ポカミス」(凡ミス)とは、以下のように定義されていました。

ポカミス(凡ミス):作業忘れ、逆付け、種類違い

つまり、「忘れ」や「間違い」が凡ミスになります。これをベースに上記の翻訳におけるミスを「翻訳ミス」と「凡ミス」に分類し、それぞれについて考えられる対策を対策強度順に並べてみると、以下のようになります。(あくまでも私の主観によります)

翻訳のヒューマンエラー

この表は、今年初めに行った WildLight セミナーでも簡単に紹介し、説明したものです。黄色セルが対策として効果ありという意味です。

「誤訳」や「文法ミス」は、翻訳者の能力・知識不足により発生する場合もあるため、あまり有効な対策が思い付きません。翻訳経験者によるダブルチェックが有効だと思います。こればかりは、翻訳者個人が地道な努力と学習をしていく事しかないでしょう。

それ以外のミスは、うっかりミスに類するものと思います。翻訳の分からない顧客でも、こういう明白なミスは指摘できるので、流出させてしまうと「翻訳の質が悪い」というレッテルを貼られてしまう可能性が高くなります。従って、徹底的に撲滅したいものです。考えられる対策を上表の(1)~(6)のように考えてみました。これらを以下に説明します。

  1. 気を付ける
    これは対策ではありません。必ず再発します。対策を求められて「気を付けます」は、何もしませんというのと同じ事です。製造業においては「気を付けます」は対策として認めず、以下の対策の何かを必ず実施する事を求めるようなやり方をしているようです。
  2. コピペ・上書き
    最初からミスを出さないというアプローチの対策です。訳抜け、転記ミスを防止する上で有効です。上書き翻訳はこの対策の1つです。
  3. セルフWチェック
    これは、同じフィルターを掛けているだけですので、見過ごしによるミスの数は減るものの、ミスは流失します。製造業の世界では、チェックという関所をどれだけ設けても、ミスは流出するというのが一般的な考え方です。
  4. 他者Wチェック
    目の違うフィルターを掛けるという意味では、検出されるミスの数と種類が変わり、効果があります。
  5. Easy to notice
    チェックのポイントを絞り、目立たせて検出し易くします。また、検査力を集中します。個人翻訳者が自分の翻訳物をチェックする場合、他人にチェックをお願いするというルーチンを組める人は稀ではないかと思います。従って、Easy to notice の方法は、自分完結で実施できるチェック方法で、ミスの流出をかなり防止できます。
  6. 機械化
    実現できるならば、ミス流出防止には完璧な方法。全て機械に検出させ、間違いを指摘させる方法です。実用レベルにあるものがどんどん登場しているようですが、まだ完璧と言う域には達していないと思います。

拙作のワードマクロ「WildLight」は、この表の「Easy to notice」対策を行う為に開発したものです。例えば、数の転記ミスチェック、スペルの正しいスペルミス、日本語スタイルガイドチェック、簡易英文法チェック、技術翻訳における英文チェック、全角半角混入チェック、用語集適用チェックなどに使用しています。

先にも述べましたが、「凡ミス」は翻訳を知らない人にも認識できるミスで、誰でもそれがミスだと明確にわかるものです。それ故に、その指摘内容から翻訳全体の質が悪いと捉えられ、翻訳者としての評価にも大きく影響してしまいます。どんなに素晴らしい訳文が書かれていても、そういう印象を顧客に残してしまいます。したがって、このような凡ミスは徹底的に潰す努力が必要だと考えています。少々ざっくりとした対策案を述べましたが、自分が実行可能で効果の高い対策を編みだして実行される事を強くお勧めします。その方法が私にとっては WildLight の開発と使用だったという事です。

最後に、私個人的な考えですが「機械化」、つまり自動的に問題を検出するようなシステムは、チェックする側の能力に依存し、チェックする者によってチェックレベルがばらつくような環境にある翻訳会社では必要だと考えています。しかし、翻訳者には向かないのではないかと考えています。それは翻訳者という視点で考えた場合、システムが検出するからという依存を産み、勘を鈍らせると思うからです。経験や知識がない人間でも、ある一定レベルでチェックし検出を可能にするシステムは、発展途上にある翻訳者の能力伸長を阻害すると考えるからです。以前から継続して言っているように、道具は良くその特性を理解し、自分のコントロール下に置いて使用したいものです。