Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

アジャイル時代の翻訳プロセス

967 views

Published on

翻訳祭2019でのセッション資料です。
公開ポリシーの都合上、当日の投影資料にあったコミュニケーションツール類のスクリーンショットは抜いています。

  • Be the first to comment

アジャイル時代の翻訳プロセス

  1. 1. 第29回 JTF翻訳祭2019 アジャイル開発時代の翻訳プロセス サイボウズ株式会社
  2. 2. チームで働くことが、楽しくなるサービスを
  3. 3. 中小企業グループウェア 業務アプリ作成プラットフォーム 大企業向けグループウェア メール共有システム 60,000社以上 10,000社以上 5,000社以上 7,500社以上 グループウェアの開発・販売、 チームワーク研修など
  4. 4. https://topics.cybozu.co.jp/news/2019/08/22-8483.html
  5. 5. 自己紹介 仲田 尚央(なかた なおひろ) UXライター / テクニカルライター UIの言葉のデザイン、ヘルプなどのドキュメント制作が仕事。 中島 晃一(なかじま こういち) ローカライゼーション スペシャリスト 機械翻訳の調査も含め、翻訳関連全般を担当。
  6. 6. Cybozu Technical Communication Team ▌UIの言葉のデザイン ▌ヘルプなどのドキュメント制作 ▌翻訳&ローカライズ ⚫日本語 → 英語/中国語
  7. 7. 今回お話するトピック ▌プロダクトの開発手法の変化 ⚫ウォーターフォール開発からアジャイル開発へ ▌アジャイル開発に対応するために ⚫ライティング/ローカライズの体制 ⚫基盤システム ▌開発チーム・翻訳者・翻訳会社のコミュニケーション ▌UIのローカライズプロセス
  8. 8. プロダクトの開発プロセスの変化 ウォーターフォールからアジャイルへ
  9. 9. 実装設計計画 テスト リリース ウォーターフォール開発 アジャイル開発 テスト リリース 計画 設計 実装 イテレーション 1 テスト リリース 計画 設計 実装 テスト リリース 計画 設計 実装 イテレーション 2 イテレーション 3
  10. 10. 実装設計計画 テスト リリース ウォーターフォール開発 アジャイル開発 テスト リリース 計画 設計 実装 イテレーション 1 テスト リリース 計画 設計 実装 テスト リリース 計画 設計 実装 イテレーション 2 イテレーション 3 小さなリリースサイクルを繰り返す フィードバックを得ながら、仕様や開発計画を見直していく
  11. 11. 特徴 ▌ウォーターフォール開発 最初に開発計画と仕様をしっかり固める。計画どおりにプロジェクトを 進めることを重視。 ▌アジャイル開発 事業の状況や関係者からのフィードバックに応じて、柔軟に計画や仕様 を変えることを重視。 変化の速い時代には アジャイル開発が適していそう
  12. 12. メリットとデメリット ▌ウォーターフォール開発 😃 仕様や開発計画が明確なため、全体像を把握しやすくコミュニケーション コストが低い 😱 開発途中での計画や仕様の変更が困難 ▌アジャイル開発 😃 仕様や開発計画を柔軟に変更できる 😱 コミュニケーションコストが高く、納期や開発コストが当初の計画とズレやすい
  13. 13. アジャイル開発手法の1つ。 柔軟な変化を可能にするため、コ ミュニケーションを重視。 開発チームがスクラムのように一 体となって動く。 スクラム開発 Wikipedia
  14. 14. アジャイル開発に適した翻訳を ▌翻訳者と開発チームの密なコミュニケーション ▌翻訳プロセスの効率化 ▌フィードバックを得ながら翻訳結果も改善していく ⚫ 翻訳者にもユーザビリティーテストに参加してもらったり
  15. 15. アジャイル開発に対応していくために
  16. 16. 縦割り組織体制によるコミュニケーションコスト 開発本部 開発 (PG) 品質保証 (テスター) PM & デザイン ライティング & 翻訳 翻訳会社
  17. 17. 開発チームがより一体となれる体制にする プロダクトA 開発チーム プロダクトB 開発チーム プロダクトB 開発チーム プロダクトB 開発チーム 翻訳チーム ライター ⚫縦割り組織を廃止、プロダクトごとの開発チームを形成 ⚫ライターは各開発チームに直属し、素早く翻訳原文を決定 ⚫UIなど短納期の翻訳は社内で。多量長納期のドキュメントを翻訳会社へ 翻訳会社
  18. 18. ドキュメント(ヘルプ)を多言語で展開するための差分管理 CMS 記事ごとに PDF出力 変更箇所を ハイライト 翻訳前回の翻訳からの差分を 確認して反映 リリースサイクルの短期化、頻繁な仕様変更で負担増 差分管理やCMSへの反映を人力でやるのは現実的でなくなる 改善前の翻訳プロセス
  19. 19. ヘルプ制作プロセスの改善 ▌差分管理はシステムに任せる ⚫ バージョン管理システム ⚫ CATツール ▌システムで差分管理しやすいよう、テキスト形式で原稿を作る ▌可読性の高いMarkdown記法に切り替え ×Word / HTML / XMLは、表現力は高いが差分管理しづらい
  20. 20. Markdownとは マークアップ言語のひとつ シンプルな記法で構造化された 文書を制作できる # Markdownとは? Markdownは、マークアップ言語のひとつです。シンプルな記法で 構造化された文書を手軽に制作できます。 ## Markdownで文書を作るメリット * シンプルな記法で「覚えやすい」 「書きやすい」 「読みやすい」 * ツールを選びません。テキストエディタがあれば書けます * HTMLやPDFなど各種フォーマットに変換できます ## Markdownで文書を作るには? 1. お手持ちのテキストエディタを開き、Markdown記法で内容 を書きます。 2. 「.md」の拡張子と付けてファイルを保存します。たったこれだけ
  21. 21. Markdownでコンテンツを作るメリット ⚫シンプルな記法で「覚えやすい」 「書きやすい」 「読みやすい」 ⚫ツールを選ばない。テキストエディタがあれば書ける ⚫記法を覚えなくてもブログライクに書けるツールもある ⚫HTMLやPDFなど各種フォーマットに変換できる ⚫読みやすいため、Markdown形式のままでもレビューが容易 ⚫TradosやMemsourceなどCATツールが対応 ⚫テキストファイルなのでGitなどでのバージョン管理が容易 ⚫文字の一括置換が容易
  22. 22. MarkdownからHTMLへの変換 Hugoを利用 ⚫ HTML変換が高速 数千ページのサイトも運用可能 ⚫ Markdownの拡張が可能 「注意」「ヒント」など多彩なスタイルを表現できる https://www.staticgen.com/
  23. 23. バージョン管理システム ①最新のデータを 取り込み ③変更を反映 ②編集 ④変更を 取り込み ▌ ファイルの変更履歴を記録 ⚫いつ、誰が、どのような目的で、どのように作成/ 変更/削除したかを記録 ⚫複数のファイルにまたがる編集をまとめて記録 ⚫履歴からファイルを過去の時点に戻すことも可 ▌ 複数人が同じファイルを同時に編集してし まった場合の競合を解決する仕組みも
  24. 24. バージョン管理システム 変更 変更 変更 変更 ▌ 履歴を分岐して管理できる ⚫分岐した各枝を「ブランチ」と呼ぶ ▌ 分岐したブランチは他のブランチの 影響を受けない ⚫複数の変更を並行して進められる ⚫他の人による変更を気にせずに変更できる ▌ ブランチ同士を合流(マージ)させ、 変更を他のブランチに反映することもできる 公開版の 履歴 要件Aを反映 する履歴 ページ構成変更 の履歴 マージ
  25. 25. ドキュメント(ヘルプ)のブランチ管理 公開用ブランチ 要件Aリリース 要件Aを反映するブランチ 要件Bを反映するブランチ 要件Cを反映するブランチ リリースされない機能の ブランチは破棄 翻訳用ブランチ 要件Bリリース 要件リリースに 合わせてマージ 要件と紐付かないヘルプの更新 をまとめて翻訳 各言語版リリース
  26. 26. CMSの刷新 GitHub 記事ファイル Memsource 翻訳メモリー 機械翻訳エンジン Circle CI Netlify ビルド ホスティング Markdown記法チェック ホスティング文章チェック HTML化 md ①記事をPush ②チェック ②自動チェック ④翻訳元記事 を入力 学習 ⑤翻訳 ⑤翻訳 ⑥翻訳済み記事 を出力 ⑦記事内の参照リンク を言語ごとに置換 ③&⑧ デプロイ md mdmd
  27. 27. マニュアル&ヘルプ 制作の流れ 日本語原稿作成 レビューを受ける 公開! • GitHubのプルリクエスト機能 でレビュー • GitHubが差分を表示 • GitHubでFix原稿をマージ • 自動的にHTMLに変換 →日本語版公開 マークダウンで、記事を作成
  28. 28. マニュアル&ヘルプ 制作の流れ 翻訳 Memsourceに日本語マークダウン を読み込み、更新部分を翻訳 公開! • GitHubに翻訳結果をマージ • 翻訳結果が自動的にHTMLに変換 →各言語版が公開される
  29. 29. ドキュメント翻訳のプロセス
  30. 30. Computer Assisted Translation (コンピュータ翻訳支援)ツール ▌Memsource ▌選択理由 ⚫価格 ⚫翻訳者は、パッケージ版やライセンスの購入が不要 (以下は他社製品も実現できるかもしれません) ⚫クラウドで全操作 ⚫翻訳者はオフライン操作も可能 ⚫ワークフローも可能 • アサインのメール通知、等
  31. 31. ドキュメント翻訳の流れ
  32. 32. プロジェクト作成 → アサイン 1. GitHub Desktop で Fetch 2. 翻訳対象のフォルダーを zip に圧縮 3. そのまま Memsource プロジェクトに取り込む フォルダー構造が維持される 4. 翻訳メモリ等、必要な設定を行う 5. アサイン先(翻訳者)を決める 誰にアサインするかはゲストスペースで(後述) 以上はすべて、サイボウズでの操作
  33. 33. 翻訳中 → 翻訳完了 6. 翻訳中の質問等は、適宜 kintone ゲストスペースで(後述) 各セグメントの質問・申し送りは、Memsource のコメント機能 7. 翻訳が完了したら、通常はサイボウズ社内でレビュー テクニカル コミュニケーション(TC)チームでレビュー TC が翻訳した場合には、社内担当部署にレビューをお願いするケースもあり 8. 一次納品後のフィードバック Memsource 上、もしくはゲストスペースで伝達 9. プロジェクトが完了したら、訳文完成ファイル(zip)をダウンロード 10.Zip ファイルを、各製品の担当者に渡す → GitHub への取り込み
  34. 34. 翻訳会社とのコミュニケーション
  35. 35. 翻訳会社とのコミュニケーションの効率化 ▌kintone ゲストスペースを活用 https://kintone.cybozu.co.jp/price/guestprice.html
  36. 36. kintone ゲストスペース ▌コメントのやり取りだけではなく ⚫ファイル管理(ファイルサーバーのような使い方) ⚫タスク管理(開始日、終了日といったスケジュール管理) ⚫案件ごとの注文書、請求書等の管理 ▌すべてゲストスペースで行っています 基本、メールのやり取りはゼロ
  37. 37. 機械翻訳
  38. 38. 機械翻訳の取り組み ▌Garoon 5 で初の取り組み ▌Garoon とは? ⚫中堅・大規模組織向けグループウェア https://garoon.cybozu.co.jp/
  39. 39. いままでの Garoon ヘルプ
  40. 40. 日英中で違い ▌日本語ヘルプ https://jp.cybozu.help/ja/g/admin/system/basic/ ▌英語ヘルプ https://jp.cybozu.help/en/g/guide/ ⚫英語版の方が「簡略化」され、中身が異なる ▌問題 ⚫機能変更、追加があった際に、加筆修正する個所が日英で全く異なる ⚫翻訳そのものより、編集個所の特定等の工数が増大 ⚫中国語にも同じ問題
  41. 41. Garoon 5 ▌Garoon 5 へのバージョンアップ(2019年10月) ▌日本語ヘルプの大幅な加筆修正 ⚫これを機に、日本語と、英語・中国語を揃えることに ▌人力翻訳では間に合わない ⚫日本語ヘルプの完成が8月末~9月上旬 ⚫英語・中国語ヘルプも同時にリリースする必要 ▌機械翻訳(MT)+ポストエディット(PE)の導入 ⚫自社のエンジンではなく、有料の機械翻訳サービス
  42. 42. カスタマイズ ▌ 英語は、カスタマイズを行った ⚫日本語↔中国語はカスタマイズできないので、標準の翻訳 ▌ 日本語↔英語は既訳(翻訳メモリ)を加えてトレーニング ⚫製品名や UI 用語など、翻訳精度が向上 ⚫例:「CSVファイルに書き出す」の訳 トレーニング前: Write to a CSV file トレーニング後: Export to CSV file ⚫ただし、100% 正確ではない ⚫よく言われる「ニューラル翻訳問題」 • 用語統一ができない、似たような文章なのに違う訳を出してくる、等々 ▌ 用語を含めてのトレーニングはあきらめた ⚫人名、製品名等いろいろ試したが、100%言うことを聞くわけではない
  43. 43. MT+PEの流れ 1. Memsourceでプロジェクト作成 2. 機械翻訳エンジンを指定 3. まず翻訳メモリをあてた ⚫100%のみあてて、確定・ロック 4. 残りの空欄セグメントをMTで埋めた 5. MTされた文章をPE ▌まず 1 回目のプロジェクトが終わった段階なので、これから振り返り・次回への 課題等を洗い出し
  44. 44. UI 文言のローカライズプロセス
  45. 45. UI 文言の翻訳 ▌外注せず、社内で翻訳 ▌理由1 ⚫仕様書、画面設計、スクリーンショットなど社外秘 ⚫開発チームとの密なコミュニケーションが必要 ▌理由2 ⚫動作確認が必要な場合が多い • テスト環境を作成し、実際の画面・動作を確認 • そのうえで最適な訳語を決める ⚫特にモバイル環境 • 文字切れしないかチェック、等
  46. 46. UI 翻訳に必要な情報 ▌ 訳語を決めるために必要な情報 ⚫UI 用語は短いので補足情報が必要 ⚫例:extension → 拡張子?内線? 1. キャプチャ • 画面コピー、もしくは画面設計 2. 表示される場所 • メニュー、詳細画面、等 3. 条件 • 詳細画面で保存ボタンを押したときの確認メッセージ ▌ 仕様書(バックログ)を参照することもあり ⚫ユーザーストーリー ⚫デザイン担当者や開発者のやり取りなど
  47. 47. kintone アプリで画面 UI 文言を管理 ▌ 画面 UI の文言を管理 ⚫「用語」管理はまだこれから ▌ kintone アプリ上でワークフローを実現 ▌ 例 1. 開発チームが日本語を検討 2. 日本語確定 3. 自動で英語・中国語担当者に翻訳依頼の通知 4. 何か質疑があればアプリのレコードのコメント機能で 5. 翻訳が終了したらステータスを「英語確定」 6. 開発チームに通知が飛ぶ 7. さらに、チームによっては自動で英語文言を取り込んで最新ビルドに反映させている
  48. 48. 質疑応答

×