こんにちは。開発部テクニカルコミュニケーションチームの澤井です。
サイボウズでは昨年、ヘルプサイトの記事更新の高速化や翻訳の効率化を目的として、ヘルプ基盤を変更しました。詳しい内容は以下のページで紹介しています。
これらの変更により、特にサイトの多言語化業務においてさまざまな改善効果を実感しているので、今回はその紹介をしたいと思います。
多言語サイト運用で課題となっていたこと
サイボウズのヘルプサイトのページ数は1万を超え、日英中3言語で展開しています。また、開発サイクルが短くなっていることから、日本語の記事更新はほぼ毎日行われています。各言語でなるべく早く最新のコンテンツを公開するにあたり、以下のような課題がありました。
- 差分管理が大変
- 翻訳結果の取り込みに時間がかかる
それぞれ、どういうことか説明します。
差分管理が大変
翻訳者に翻訳依頼を出す際、翻訳対象テキストを伝える必要があります。
ヘルプ基盤変更前は、更新した日本語のページをPDFに保存し、変更箇所をハイライトしたり、注釈をつけたりすることで翻訳者に変更点を伝えていました。また、販売地域ごとの書き分けもこのPDFファイルの中で翻訳者に伝えていました。
書き分けとは、例えば「メールワイズ」は日本国内でのみ販売している製品なので、日本リージョンの中国語サイトには記述が必要ですが、中国リージョンの中国語サイトでは非表示にしなければならない、といった制御のことです。
このやり方だと、変更するページの数だけPDFファイルを作成しなければならず、変更ページ数が多いと作業が膨大になってしまう問題がありました。翻訳者も、全てのPDFファイルを開いて変更箇所を探した上で翻訳しなければならず、実質の翻訳業務以外の管理業務にかなり時間を奪われる状態でした。
さらに、翻訳依頼者が翻訳者にPDFファイルを渡す際に最新でないファイルを渡してしまう、翻訳者が変更箇所を見落として訳漏れが発生する、などのミスもたびたび発生していました。これらのミスを防ぐため、翻訳依頼者、翻訳者の両方が確認作業に多くの時間を割いている状態でした。
翻訳結果の取り込みに時間がかかる
翻訳者は、PDFファイルで翻訳箇所を確認した後、翻訳作業をプレーンテキスト形式で行っていました。翻訳結果をヘルプサイトのコンテンツとして公開するためには、翻訳結果をCMSに反映し、HTML形式に変換する作業が必要です。ヘルプの基盤を変える前は、翻訳者がCMSに翻訳結果を手作業で入力することでこの変換を行っていました。
また、たとえば同じ中国語の翻訳ファイルであっても、販売地域によってCMS上で記述を書き分ける作業が合わせて必要でした。
この、CMSに手作業で翻訳結果を入力する作業と販売地域ごとの書き分けの作業のために、翻訳結果の取り込みに多くの時間がかかっていました。
いかに課題を解決したか
この2つの問題をどのように解決したか説明します。
CAT(翻訳支援)ツールの導入
CAT(翻訳支援)ツールとは、翻訳作業を行うエディタ機能、過去訳を参照できる翻訳メモリ、ツール内での機械翻訳の使用などを一元的に行えるツールです。SDL Trados、memoQ、Memsourceなどが人気のようです。
サイボウズではヘルプ基盤の変更に伴い、Memsource(メムソース)を導入しました。Memsourceはチェコの企業発のクラウド型CATツールです。
これにより、悩みの種だった差分管理がとても楽にできるようになりました。
翻訳対象のファイルをMemsourceに取り込むと、画像のように翻訳用エディターに翻訳対象テキストが表示されます。このとき、過去に既に翻訳された文章は翻訳メモリとして活用され、Memsourceが自動的に翻訳します。つまり翻訳者はシステムの表示に従って原文の変更箇所のみ翻訳すれば良いのです。
この機能のおかげで、これまで翻訳依頼者が行っていた「ここを変更したので翻訳してください」という連絡が不要になり、翻訳者は翻訳個所をいちいち探すことなく集中して翻訳に取り組むことができるようになりました。このおかげで、翻訳にかかる期間が短縮されました。
さらに、用語の過去訳が常に参照できるおかげで表記の統一がしやすくなり、文書品質が向上したことも導入の大きなメリットでした。
マークダウン移行による翻訳取り込みの効率化
翻訳結果取り込みを楽にしてくれたのが、ヘルプのマークダウン移行です。
翻訳の取り込みでボトルネックになっていたのは「CMSに手作業で1ページずつ、翻訳結果や販売地域ごとの書き分けを入力しないといけない」点でした。「HTMLファイルのまま翻訳してHTML/CSSファイルの中で地域ごとの書き分けを指定し、そのまま公開することはできないの?」と思うかもしれませんが、このやり方は、意図しない内容が検索結果に表示されてしまう、「隠しテキスト」としてGoogleからの評価が下がってしまうなどの弊害があるため、好ましくありませんでした。
根本の1つの翻訳ファイルの中で地域ごとの書き分けを指定でき、システムがそれを変換して各地域ごとのHTMLファイルを生成してくれると一番楽に運用できますが、これを実現してくれたのが静的サイトジェネレーターHUGOのマークダウン拡張機能です。翻訳ファイルの中で {{% disabled US %}} のようなショートコードを使って販売地域の書き分けができるようにしました。
Memsourceは、翻訳対象ファイルをマークダウンで読み込むと、翻訳結果ファイルもマークダウンで出力できるので、この出力ファイルをGitHubに保存するだけで、各地域ごとのHTMLファイルが自動的に生成、公開されるようになりました。(参照リンクを言語ごとに変える処理など、テキストの翻訳だけで対応しきれない部分は独自の変換ツールを使用しています。)
上記の対応によって、定型業務がどれくらい削減されたか示したのが下図です。原稿作成から公開までにかかる時間はほぼ半分に減りました。
変更後の翻訳フロー
ヘルプ基盤変更後の翻訳フローは、以下のような感じです。
日本語ヘルプ担当者が翻訳依頼用のブランチを作成し、翻訳者に翻訳開始を依頼します。
翻訳者は、GitHubからマークダウンファイルをダウンロードし、Memsourceに読み込みます。
翻訳者はMemsourceの翻訳エディター上で翻訳作業を行います。
翻訳が終了したら、Memsourceから翻訳結果のマークダウンファイルを出力し、GitHubに反映します。
自動的に販売地域ごとのHTMLファイルが生成され、公開されます。
具体的なやりとりの内容で説明すると、日本語ヘルプ担当者が「日本語が確定しましたので、このブランチの翻訳をお願いします!」と依頼したら、翻訳者が翻訳終了後に「翻訳を反映しましたので、プルリクエストの承認お願いします!」という返事をする、というシンプルなフローに落ち着きました。
これまで当たり前だった煩雑な確認や連絡が一切不要になったので、最初にこのフローを実施したときには「本当にこれで大丈夫なの?」と心配になったほどでしたが、翻訳結果はもちろん、問題なく公開されました!
改善効果
ヘルプ基盤変更の前と後で、原稿作成から翻訳結果の公開までにかかる時間はほとんど半分になりました。これまで、翻訳にかかる稼働を考えて記事の改善に心理的なハードルを感じる場面がありましたが、今はまったく気にすることなく小さな改善も大きな改善も実施できています。
また、定型業務に忙殺される状態を脱して時間が有効に使えるようになったことで、コンテンツ内のスクリーンショットを増やしてより直感的に理解しやすい内容にしたり、Google Analyticsなどの分析ツールを活用してよりユーザーにとって価値のあるコンテンツを検討したりするなど、ヘルプの品質を高める取り組みにより重きを置けるようになりました。
現在テクニカルコミュニケーションチームでは、文書校正のルールを検討して自動化するなどの取り組みを進めています。機械翻訳の活用も進めているので、これらの取り組みについても別の記事でご紹介できればと思います。
最後に
テクニカルコミュニケーションチームのメンバーや翻訳者は大多数が非エンジニアで、マークダウンやGitHubを本格的に使ったことがないメンバーもいました。そのため、新しいツールを使いこなすための勉強会やハンズオンなどにはそれなりのコストがかかりました。今回の改善の学習コストが高いことは否定できませんが、今は全員が問題なくこれらのツールを使いこなし、スピーディーなヘルプ更新や翻訳が行えています。コストよりも、得られるリターンがとても大きいことを実感しています。
この記事が、多言語サイトを管理するチームの方々の何かの参考になればとても嬉しいです。