『ヘルプサイトの作り方』（仲田尚央、山本絵理・著、技術評論社）を読んだ。
タイトルにあるように、ソフトウェアといったプロダクトのヘルプを作成する方法を解説している。事例としてサイボウズ社のヘルプサイトも登場する。
目次は上記リンク先から確認できる。

◆

たとえば第6章「記事を作る」では、執筆時に使える手法が具体的に解説されている。文の書き方（例：一画面一手順）や図解の方法（例：ユーザーの視点から描く）などである。
こういった内容はもちろん参考になるが、ライティングの教本などほかの書籍でも取り上げられていることもある。
やはり本書で独特なのは、ヘルプの書き方というより、ヘルプサイトを全体としてどううまく作るかを扱っている点だと思う。
第1章の冒頭にもあるように「文章力」より「設計力」に注目しているのである。

◆

個人的には、翻訳支援ツールと連携したサイボウズのヘルプ管理システムの話が面白かった。
以前、自著に関連してサイボウズを取材させてもらったことがある（記事）。サイボウズでは対訳用語集を自社製品で管理しているという話だったが、ヘルプ管理システム全体としてどう動いているかまでは知らなかった。
本書ではその全体像が（ページは少ないものの）説明されている。以下、173ページから図を引用する。



フローとしては、まずヘルプの記事を制作して「GitHub」に取り込んでいることがわかる（図上半分）。
その後、記事を「翻訳支援システム」に渡している（図下半分）。実際の翻訳は、その右側にある翻訳者と「機械翻訳」が行う。その際に左側から「用語」を取得しているのだ。ここで対訳用語集が利用されているということだ。
記事の翻訳が完成するとGitHubに戻し、その後ヘルプとして公開される。

やはりITはアメリカ企業が強く、ヘルプを多言語化している国内IT企業はそれほど多くないように思われる。そのため多言語化のフローはとても参考になるし、事例を提供してくれるサイボウズは貴重な存在である。

◆

なお、第5章「スタイルガイドや用語集を準備する」で、日本語スタイルガイドとして「JTF日本語標準スタイルガイド」を紹介していただいている。
制作に関わっている者として感謝申し上げたい。

Thierry Poibeau著『Machine Translation』（MIT Press、2017年）（英語版のみ）



2017年に出版された機械翻訳の解説書。新しいのでニューラル機械翻訳（NMT）まで扱っている。
技術面というより、歴史的な流れに主眼をおいて説明している。そのため技術者でなくてもあまりストレスを感じず読み進められる（ただし統計翻訳で若干の数式が登場）。
日本で既刊の機械翻訳本は技術者向けのものが多いので、その点では貴重だ。

◆

同書第3章を参考に、簡単に機械翻訳の歴史をまとめるとこうなる。

・〜1940年代：
　研究者は自動翻訳について考えてはいたが、実現方法がなかった。

・1940〜1960年代半ば：
　コンピューターが登場し、動く機械翻訳システムが作られた。期待は大きかった。

・1965-66年：
　機械翻訳の実現に否定的な「ALPACレポート」がアメリカで出され、研究費が出なくなった。

・1966〜1980年代末：
　英米圏で研究は下火だった。ただし計算言語学で進歩があり、構文解析などが進んだ。
　一方、欧州や日本では研究は継続されていた。1980年代に日本の長尾真氏による「用例ベース」（Example-based）の機械翻訳が登場し、第8章はまるまるこの解説に当てられている。

・1990年代〜：
　統計とバイリンガル・コーパスを使ったアプローチが登場した。基礎になっているのは1980年代後半〜90年代初頭に行われたIBMでの研究（同書内でも詳しく解説している）。

・2010年代半ば〜：
　ディープラーニングに基づく新アプローチが登場（ニューラル機械翻訳のこと）。

◆

同書でやや残念なのは、2017年に出版されたため、その直後に一気に普及したニューラル機械翻訳の解説が少ないという点だ。そのため、最新の機械翻訳だけを集中して知りたいという人にとっては物足りないかもしれない。
ただし歴史全体を知るには良い書籍であり、Kindle本で1,400円弱、洋書でも1,700円弱（2018年6月時点）なので、比較的買いやすい。

光藤京子・著（秀和システム）2016/12/24

◆　◆　◆

訳文の誤りを「エラーカテゴリー」で分類することで、翻訳能力向上を図る方法を示した書籍である。

各エラーカテゴリーにおける具体例が豊富で、翻訳を学ぶ学生にとって役立つだろうと感じた。エラーカテゴリーを利用する翻訳評価手法は一般的に「エラー評価」と呼ばれるが、それを具体例とともに解説した日本語の一般書はないため、その点でも有用だろう。

同書のエラーカテゴリーは合計15個あり、大きく3種類に分けられている（p. 25-26）。

1. 「正確に訳されているだろうか？」：「歪曲」や「情報の欠如・付加」など8個のカテゴリー


2. 「分かりやすく訳されているだろうか？」：「違和感のある語彙選択」など4個のカテゴリー


3. 「細かいところに気が配られているだろうか？」：「表記ミス」（スタイルガイド違反）など3個のカテゴリー

これは業界で用いられているエラー評価分類と似ている部分もある。例えばDQF-MQMでは「正確さ」（上記の1）、「流暢さ」（上記の2）、「スタイル」（上記3の一部）という大カテゴリーを設けている。同書にこういった既存エラーカテゴリー（DQF-MQM以外にもいくつか存在する）との比較研究があれば、実務家にとってより有益だったかもしれない。

さらに、同書内では業界の基本的な実務知識（翻訳プロジェクトの流れなど）にも簡単に触れられている。全体として翻訳者を目指す人向けの書籍と言えるだろう。
（ちなみに、スタイルガイドの例として『JTF日本語標準スタイルガイド』が挙げられていた。作成に関わっている者としてお礼を申し上げたい）

◆　◆　◆

ここでは同書に関連するものの、書かれていなかった点について考えてみたい。特にエラーカテゴリーを評価に使う際の課題である。

A. エラー評価に対する批判

実はエラーカテゴリーを用いたエラー評価は、以前から実務翻訳で使われている。
一般的にエラー評価では、原文と訳文を1文ごとに対照させ、訳文中にあるエラーを発見する。そしてエラーの重大度に応じて点数（「深刻」なら10点、「重度」なら5点、「軽度」なら1点など）を付け、合計がしきい値を超えたら「不合格」にするといった運用をする。

このやり方については主に2つの批判がある。
1つめは「木を見て森を見ず」という批判だ。1文ごとに見比べるため、文（＝木）というミクロレベルではエラーを見つけやすい。例えば、誤訳、用語集違反、スタイルガイド違反などだ。
ところが、文章全体（＝森）として見比べているわけではないため、マクロレベルのエラーは評価できていないという批判である。例えば、学術論文には独特の構成があり、それに合うよう文章が訳されていることが望ましい。

2つめは「さまざまな専門分野に対応できない」という批判である。例えば特許文書とマーケティング資料では、訳文で重視する点が異なる。特許では「正確さ」（例：誤訳のなさ）が重要だし、マーケティング資料では「流暢さ」（例：購買欲を刺激する表現）が重要かもしれない。
もし単一のエラーカテゴリーしかないのであれば、いくつもある専門分野に柔軟に対応できないという批判である。

（この「A. エラー評価に対する批判」については、JTFジャーナル #285（PDFファイル）の私の記事（p. 26-）でも紹介している。）


B. エラーで翻訳を評価してよいか

こちらはAと比べると、より根源的である。エラーの有無のみで翻訳を評価してよいかという問いである。

翻訳成果物はエラー以外に、さまざまな側面から評価できる。
例えば、訳文には最終読者がいる。最終読者の反応を考慮せず、提供側のエラーカテゴリーのみで良し悪しを決めてしまって良いのだろうか？
また、プロとして翻訳ビジネスをするなら、納期や予算の制約がある。スケジュールも料金も悪い条件で仕事を依頼をされたのに、通常と同じ基準で評価されてしまったら、翻訳者としては納得できるだろうか？

評価すべき翻訳の「品質」が何であるかと議論が従来からあり、最近翻訳業界では「Garvinの5分類」が提唱されている。要するに「品質」が意味するところは主に5つあるということだ。
エラー評価は5分類のうちの「プロダクトベース」に該当する。ほかには上記の最終読者の視点で評価する「ユーザーベース」や、予算との兼ね合いで評価する「価値ベース」などがある。
（Garvinの5分類について詳しくはJTFジャーナル #283（PDFファイル）の私の記事（p. 20-）をご覧いただきたい。）

つまり、エラー評価は、いくつもある方法のうちの1つに過ぎないのである。

業界（や教育）においてエラー評価がよく用いられるのは、その簡便さが理由だと思われる。翻訳提供側でエラーカテゴリーを用意して使えばよいだけだからだ。もし訳文について毎回最終読者にアンケート調査して評価していたら、コストがかかり過ぎてビジネスとして成立しない。

エラー評価は便利ではあるが、それは翻訳品質の1面のみを評価しているに過ぎないという意識を常に持っておく必要がある。

私の好きな話に「街灯の下で鍵を探す」がある。ある公園を夜歩いていると、男が街灯の下で鍵を探している。その男に「確かにここで鍵を落としたのか？」と聞くと、「どこで落としたのか分からないが、ここが明るいのでここを探している」と答えたという話だ。
エラー評価は簡便であるため、翻訳評価でつい使いたくなる。しかしそれが本当に評価すべきものかどうかは分からない。「評価しやすいから評価する」（＝探しやすいから探す）のではなく、本当に評価すべきものは何であるかをしっかり見極めなければならない。