品質と、管理と、改善と。「翻訳会社における品質管理を学ぶ」
当社は翻訳品質管理活動の一環として、外部講師による社内研修を実施しています。
講師に吉澤正孝先生（クオリティ・ディープ・スマーツ有限責任事業組合代表/一般社団法人品質工学会副会長）をお招きし、品質管理の基本を勉強する講義を継続的に実施しています。後ほど、この社内研修の一コマを皆さんに共有したいと思います。
品質と個人の価値観
今年度初回となった勉強会では、「改善のためのデータ分析」と題して、収集したデータの分析および活用の方法について学習しました。今回対象となったのは、比較的社歴の浅い社員です。制作部門がメインの内容になりますが、営業も一緒に参加して自社の取り組みについて勉強しました。
「品質」と一言でいっても、いろいろな議論があります。ISO9000:2005 では「本来備わっている特性の集まりが要求事項を満たす程度」とあり、JIS8108：1981では「品物またはサービスが、使用目的を満たしているかどうかを決定するための評価の対象となる固有の性質・性能の全体」と定義されています。
例えばお昼の弁当で考えてみると、本来「味」、「安全」、「栄養価」、「見た目」などが本来備わっているべき特性になると思いますが、人によってコンビニの弁当でも問題ないが、コンビニでは絶対に買わないという人もいるかもしれません。
量を重視する人もいれば、保存料や着色料が無添加であることを重視する人もいるかもしれません。最近では店の雰囲気や、購入時のポイント付与、電子マネーの利用可否などが付加的な評価基準になりつつあると思います。
品質は評価者の価値観が大きく影響します。翻訳の品質も同様です。
話が少し横道にそれますが、当社は本来備わっているべき特性を評価するためのツールとして、EAST（Effective Assessment and Standardization of Translation）という品質評価ツールを自社開発しています。創業以来30年以上の経験を蓄積し、翻訳に本来求められる特性を定量的に評価できるようになっています。
一方で、先に述べたように、翻訳の品質も個人の価値観によって大きく影響を受けます。そういった個人ごとに変わる用途や分野、好みなどの要求事項は当社では品種と定義しています。
品種の把握は、営業やプロジェクトマネージャの重要な役割です。それに応じた資料や用語集、スタイルガイドの適用や、Q&Aのプラットフォームを用意することは非常に重要です。翻訳の実務の現場では、きめ細やかなコミュニケーションが付加価値として評価されることが良くあります。
また、どんなに本来の特性や要求事項が明確になっても、工程設計やリスクテークに誤りがあると満足いただけるサービスは提供できません。こうしたプロジェクトマネジメントの品質も当社は重要視しており、品質、品種、プロジェクトマネジメント品質を三本柱としてTAFTシステムと呼んで、管理・改善活動を実施しています。
管理と改善
次に、管理とは、改善とは何でしょうか。勉強会でもこの疑問は取り上げられたことがあります。その時には、「品質をよりよい状態で維持する活動＝品質管理」とし、「品質レベルをよりよい状態にする活動＝品質改善」であると言及がありました。当たり前のように見えて、取るべきアプローチは異なります。
- 期待に対してギャップが無い場合→維持管理をするため、PDCAを回す
- 期待に対してギャップがある場合→悪い状態を良い状態に変えるためCAP-Doのサイクルを回す
これも改善活動に従事している人であれば当たり前のことですが、上記に共通している事は、「期待値」が必要だということです。期待値は、可視化ができ、定量化できる必要があります。計測できない問題は、改善できません。当社は、EASTを用いて可視化・定量化しています。
一例として、今回の勉強会で取り上げられた、EASTの結果を活用したパレート分析を以下に記載します（画質が悪く申し訳ありません）。横軸はあるプロジェクトに一定期間関わった翻訳者を列挙し、縦軸にはその期間内のエラーの数が記載されています。
グラフを見ると、原点に近い翻訳者に大量のエラーが発生している事が一目瞭然です。当然これらの翻訳者が翻訳したものは、当社の「期待値」をクリアできていません。
では、クリアできなかった理由は何でしょうか。それは、翻訳者のスキルの問題もあるかも知れませんが、当社のプロジェクト設計に問題があったかもしれませんし、資料や用語集などの仕様の聞き取りに不備があったからかも知れません。そうした原因を分析データから生のエラーデータへ掘り下げ、分析をしてゆくのです。
人のせいにすると改善活動は止まってしまう
今回の勉強会で一番のポイントは、「人のせいにするのは簡単。でもそれで終わったら改善活動は止まってしまう」ということでした。
問題が発生した原因を分析し（CAP）、改善策のアクション（Do）をする。今回のケースでは、翻訳者さんにエラーのフィードバックをして自己分析をしてもらったり、当社側にもフィードバックをしてもらったりすることで相互に再教育をし、工程を見直すことでAからBへのシフトを誘導することが重要であるという締めくくりで勉強会を終えました。
これ以外にも、ピボットテーブルから相関分析、回帰分析をするためのシミュレーションを行いました。積極的なシフトを引き起こすためには、問題を自覚する事が何よりも大切です。意思を持たなければ問題は自覚できませんし、自覚できない問題は解決できません。こういうこともいろいろと学習することができました。
今回の勉強会を経て、若い現場にも新しい変化が起こることを期待しています。
関連記事
