大規模かつアジャイルなソフトウェアのローカライズ:カスペルスキー事例研究

Updated April 1, 2020
Rokarizeishon biggu ajairu sofuto kasuparusuki keesu sutadi - Smartcat blog
Smartcat covers all your language needs with AI translation, AI content generation and AI human workflows.

大手ソフトウェア企業のローカライゼーション業務を統括すること自体が困難です。この企業がアジャイル手法に切り替えた場合、どうなるでしょうか? そう、課題はさらに深刻化し、抜本的な変更を迅速に実施しなければならなくなります。 このケーススタディでは、Ekaterina GalitskayaDarya Egorushkinaカスペルスキーのドキュメンテーションおよびローカライズチーム)が、Smartcatを活用してプロセスの能力と効率を向上させた取り組みについて語ります。

エカテリーナ&ダーリヤによる追加テキスト

当社チームは、モバイルセキュリティアプリのUIテキストとヘルプセンター記事の執筆・ローカライズを担当しています。以下では、モバイルセキュリティアプリのローカライズをより信頼性が高く、俊敏で自動化された手法で開始した経緯をご紹介します。 まず、現状変更の必要性に迫られた課題から始め、直面した困難と導き出した解決策を順を追って説明します。本記事が、開発だけでなく関連するあらゆる側面でアジャイル導入に挑む中規模から大規模ソフトウェア企業にとって有益であることを願っています。

パン

他の多くの企業と同様、カスペルスキーもある時点でアジャイル開発手法に切り替えていました。これによりリリースサイクルは大幅に短縮されました。以前は数か月ごとに新バージョンをリリースしていましたが、今では2週間ごとにリリースするようになりました。確かに各リリースに含まれる文字列は減りましたが、それでも大きな助けにはなりませんでした。より厳しい納期に直面しながら、これらのわずかな文字列を、従来のローカライゼーションと言語テストプロセス全体にかけなければならなかったからです。

モバイルアプリにはテキストが少量しか含まれないという誤解もよく見られます。そうだったらいいのですが!例えば当社のケースでは、UIテキストだけでアプリ1本あたり平均約25,000語、これを約10本のアプリに掛け、さらに各アプリごとに約20のターゲット言語に掛け合わせる必要がありました。しかも毎週新しいUIテキストやドキュメントテキストが追加される状況でした。
その結果、ローカライゼーションはリリース展開プロセス全体のボトルネックとなった。かつてプロダクトマネージャーがローカライゼーションチームのメンバーの名前すら知らなかったのは(翻訳が「魔法のように勝手に」現れるのだから当然だろう)、今や彼らは望んだ以上に深く、関連するあらゆる問題に気づかされるようになったのである。

カスペルスキーにおけるローカライゼーションプロセスは、一般的に翻訳言語テストの2段階で構成されています。

翻訳段階における一般的な問題は、使用されたプロセスとCATツールの制限の両方により、手作業が多すぎたことです。具体的には:

  • マルチブランチパイプラインがサポートされていなかったため、翻訳用の差分を手動で作成し、後でそれらをブランチにプッシュし直す必要がありました。

  • アプリと言語全体での一貫性を保証することが不可能でした。

  • 追加の翻訳依頼を並行して処理できなかった。例えば、ソーステキストがプロセス中に変更された場合などである。代わりに、基本翻訳パッケージの準備が整うまで待機し、その後で追加翻訳に進む必要があった。

  • 「翻訳不可要素」のエラー、エスケープされていないアポストロフィ、その他の人為的ミスによるビルド失敗が、次第に深刻な問題となりつつあった。

言語テストの段階については、実際の翻訳に要した3~5日に対し、最大2週間かかる可能性があります。「言語テストとは一体何なのか?」と疑問に思われる方もいらっしゃるでしょう。

言語テストの主な目的は、文脈全体を考慮した翻訳の検証にあります。当社には専門用語に精通した確固たる翻訳者チームが在籍しています。しかし、周囲の文脈を確認せずに翻訳したり、ボタンか見出しかの区別すらつかない状態で作業すると、事態は急速に悪化します。

言語テストでは、通常スクリーンショットを通じて、生成されたアプリ画面をすべて手動で確認します。これにより、以下のような問題の特定に役立ちます。

  • テキストが画面要素のサイズに対して長すぎる場合。省略されたテキストに免責事項や財務情報が含まれる場合、法的影響が生じる可能性があります。

  • 翻訳者が誤訳したか、文字列として外部化されず、ハードコードされていた場合など。

  • 文脈を誤って翻訳されたテキスト。例:ボタンのテキスト(例:「ダウンロード」)が文法的に不定詞ではなく命令形になっている場合。

スクリーンショット作成作業だけでも膨大な時間を要した。例えば、新機能に40のUI画面が含まれ、20のターゲット言語がある場合、最大70時間もの手作業による機械的な労力が必要となる。

結局のところ、3か月ごとに新バージョンをリリースしていた頃は、この問題も我慢できる範囲だった。しかし隔週リリースになると、ローカライズチームに負担がかかり始めた。早急に修正する必要があったのだ。

私たちには二つの選択肢がありました:

1. 経験の浅い労働者を雇用し、ローカライゼーション作業量を削減する — どちらも当然ながら品質の低下を招く、もしくは
2. 自動化する。

私たちは後者を選択した。

なぜSmartcatなのか

CAT/TMSソリューション選定における最優先事項は以下の通りでした:

  1. 社内承認プロセスの簡素化 — 予算承認、シリアルキー発行など一連の手続きを削減するため、

  2. 基本機能の即時利用可能化 — 追加機能の開発待ちなく即時利用開始が可能であること、

  3. 軽量なサーバー要件 — ここでも承認プロセスを長期化させないため、

  4. 手頃な価格、できれば無料でのサービス導入。

  5. 十分なサポート — 社内開発者を雇う必要がないよう、サービス側で提供されるサポート。

  6. セキュリティ要件 — 当社がサービスに接続する方式(逆接続ではない)。

  7. マルチブランチ対応 — 複数の機能を並行して翻訳するため、

  8. 追加翻訳が元のバッチと並行して可能であること。

候補を絞り込んだ結果、最終的に残ったのは2つの名前だけでした:Smartcatと、Evernoteの開発者による継続的ローカライゼーションサーバー「Zing」です。

Zingはカスタマイズ性、無料のインストールパック、プライベートアクセスが気に入りました。自社内でホスティングできる点も魅力でした。ただし、インストールプロセスは決して簡単ではなく、翻訳者やスタッフ全員の導入には多大な時間を要するため、サービス運用にかかる時間コストが高くなりすぎるという欠点がありました。

そこでSmartcatを採用しました。社内VCSにCATツールを直接接続できないため、Smartcat–Sergeバンドルを利用することにしました。 (Sergeはバージョン管理システムと翻訳管理システム間で文字列を同期するオープンソースソフトウェアです。様々な形式のファイルから文字列を識別し、業界標準のPO形式に変換してSmartcatに供給します。自社サーバーに直接インストールできるため、機密情報が外部に流出することはありません。)

このソリューションで特に気に入った点は以下の通りです:

  • すべての要件をサポートしている点:マルチブランチパイプライン、追加翻訳、セキュリティなど。

  • 更新がリアルタイムで適用されるため、ダウンロードやインストールが不要です。

  • Smartcat–Sergeバンドルにより、文字列用の独自の解析スキーマを作成できます。

  • プラットフォームを離れることなく、文書を翻訳中の翻訳者と直接コミュニケーションが取れます。

  • p>

  • 必要に応じてプラットフォームのマーケットプレイスでフリーランサーを直接見つけることができます

  • 全言語・全プロジェクトの支払いを単一の請求書で済ませられます

  • サポート体制が非常に優れています — Smartcatのチームはワークフローの立ち上げを支援し、当社にとって重要な機能の優先順位付けも行ってくれました。

  • 実質無料で利用可能 — プロジェクト全体のテキスト検索機能のため、最終的にサブスクリプションを選択しましたが、これは任意の選択でした。

私たちが直面した課題の一部は以下の通りです:

  • 当初、プロジェクト内の全文書からテキストを検索できませんでした — 現在はSmartcatがこの機能を実装したため問題ありません、

  • フリーランサーがプロジェクト文書の更新通知を見逃したり無視したりすることがあるため、組み込みチャット経由で手動でリマインダーを送る必要がありました、

  • プロジェクトマネージャーが翻訳者への招待を手動で開始する必要がある点——ただし、この手順は近く自動化されると聞いています。

これまでのSmartcatでの経験を踏まえ、これらの課題の解決に向けて既にチームが取り組んでいると期待しています。

ビフォア&アフター

状況を整理するために、プロセスと数値の両面から、以前の状態と現在の状態を比較してみましょう。

プロセス

以前

変更前は、翻訳および言語テストの段階において、30に迫る工程を踏まなければなりませんでした:

翻訳手順:

  1. リポジトリ内の異なるブランチからテキストを手動で取得する、

  2. 翻訳用の差分ファイルを手動で作成する、

  3. 翻訳用パッケージを構築する、

  4. FTPサーバーにアップロード、

  5. 代理店、フリーランス、現地事務所に大量のメールを送信、

  6. 翻訳が完了したらFTPサーバーから翻訳データを取得、

  7. CATツールに読み込み、問題がないか確認、

  8. 翻訳済み文字列をリポジトリにアップロード(ブランチを混同しないよう手動で)、

  9. ビルドを実行、エラー修正、ビルド完了、

  10. 追加翻訳を依頼 — 基本的に同じプロセスを繰り返す。

言語テスト:

  1. ビルドを開始し、完了するまで待機する、

  2. ローカライゼーションエラーで失敗した場合、ビルドを再起動する、

  3. デバッグメニューがない場合、特別なテスト環境を設定する、

  4. 20以上の言語に対応する関連スクリーンショットを全て撮影する、

  5. QAチームと協力し、不足しているスクリーンショットの入手方法を検討する、

  6. スクリーンショットパッケージを作成し命名する、

  7. それらをFTPサーバーにアップロードする、

  8. 翻訳文の確認を翻訳会社に依頼する、

  9. 翻訳会社からの質問に回答する、

  10. タスクを受け入れ変更を加える、

  11. ビルドを実行する — 時間がかかる場合もある、

  12. エラーがあった場合はビルドを再実行する、

  13. 回帰テスト用のスクリーンショットを撮影する、

  14. 再度、スクリーンショットをアップロードし翻訳会社にタスクを割り当てる、

  15. 再度、翻訳会社と全てを協議する、

  16. 再度、翻訳変更があった場合は回帰テストを再度実施する。

その後

全工程を通じて、以下の9つのステップのみとなりました:

  1. コピーライターがGitに新規文字列をコミットします。Sergeが自動的に文字列をSmartcatに連携します。

  2. ローカライゼーションプロジェクトマネージャーが翻訳者を割り当て、

  3. 翻訳者はスクリーンショットやコメントをすぐに参照できる環境で文脈に沿って翻訳します。

  4. ローカライゼーションプロジェクトマネージャーが翻訳を確認・承認すると、翻訳内容は自動的にGitに戻ります。

  5. ローカライゼーションチームがローカライズされたテキスト用の機能スクリーンショットボットを実行し、

  6. ローカライズチームは翻訳済みスクリーンショットをFTPサーバーに配置し、言語専門家へ送信します。

  7. 言語専門家は翻訳済みスクリーンショットを確認しながら翻訳内容をチェックし、必要に応じて修正します。

  8. 変更内容は自動的にGitに反映されます。

  9. ローカライズチームがプルリクエストをクローズします。

以上です。この3段階の複雑さの削減により、従来の方法との違いを実感しています!

数字

すべての数値は、1回のリリース(2週間ごと)および1つのアプリごとに算出されています。

ステップ

時間前

時間後

合計時間

合計時間

開始前時間

開始後時間

全ブランチから文字列を収集

1

-

新規または更新された文字列のみを含む差分を作成し、20以上の言語向けにCATツールへアップロード

4

0.25

20以上の言語に対応した翻訳パッケージを作成

0.5

-

20以上の言語の翻訳パッケージをFTPサーバーにアップロード

0.5

-

20以上の言語について、翻訳会社/翻訳者と連絡を取り、仕事を引き受けられることを確認する

2~3

プラットフォーム上で直接翻訳会社/翻訳者に仕事を割り当てる

-

0.25

翻訳者からの質問に回答

2–4

0.5

翻訳のレビューと確認

1

0.25

ビルドの実行

最大8

0.25

追加翻訳

8

0.25

スクリーンショットを取得

自動スクリーンショットツールで16~32枚

スクリーンショットを取得

自動スクリーンショットツールで16~32枚

スクリーンショットを取得

自動スクリーンショットツールで16~32枚

自動スクリーンショットツールで8枚

スクリーンショットをFTPサーバーにアップロード

8

1

代理店/翻訳者と連絡を取り、確定した翻訳を取得する

8

1

リソースファイルを更新する

8

2

変更を Git に書き込む

8

0.25

アプリごとのリリースあたりの合計時間

84時間

14時間
6分の1の時間を実現!

ボーナス

追加の利点 — その一部は予想外のものですが — には以下が含まれます:

  • より信頼性の高いビルド: プレースホルダーのおかげで、翻訳不可テキストが誤訳されることやアポストロフィのエスケープ漏れなどの懸念がなくなりました。

  • Smartcat は、その 重大なエラー 設定のおかげで、いくつかの古いバグを特定しました。

  • 他の人の時間とリソースを無駄にしない:QA チームからテスト用デバイスを借りたり、開発チームの時間をスクリーンショットの撮影に費やす必要がありません。

  • 翻訳者がスクリーンショットを利用可能、翻訳者はエディタから直接、簡単に スクリーンショットを開いて確認できるため、翻訳の品質が大幅に向上しました。

今後も改善を続け、時間の経過とともにローカライゼーションプロセスの効率と品質を向上させる新たな方法を見出せるでしょう。最も重要なのは、ローカライゼーションがリリースサイクルのボトルネックではなくなったことです。このような短期間で成果を上げたことは、当社チームとSmartcatプラットフォームの双方にとって大きな成果であったと考えています。


付録。ヒントとアイデア

以下は、当社がSmartcatを導入した際に実施した具体的な手順です。当社の取り組みを参考にしたい他企業やチーム向けの「手引き」としてここに掲載します。全てが容易なわけではありませんが、大半の手順はローカライズプロセスをより円滑にし、エラー発生を減らすのに役立つでしょう。

統合:

  • Git–Serge–Smartcatの連携をテストし、すべての文字列がSmartcatプロジェクトに正しく送られ、戻ってくることを確認してください。本番環境で予期せぬ問題が発生するのを避けたいでしょう。

  • ソフトウェアエンジニアとブランチ命名規則を合意する。これにより、ローカライズが必要な特定のブランチを検索するボットを設定でき、開発者と双方のコミュニケーション時間を大幅に削減できます。

  • 必要に応じてSergeのデフォルトパーサーをカスタマイズする。例えば、翻訳者が参照できるスクリーンショットへのリンクや、文字列ID、コメントを表示するように設定しました。

  • 上記で合意した名前マスクに基づいてローカライゼーションブランチを見つけるcronジョブを作成する

  • UI テストと機能スクリーンショットの撮影を検討するKaspresso フレームワークを使用します。例えば、当社の開発者は使用する各文字列にスクリーンショットへのリンクを配置しています。 ファイルが Smartcat に送信されると、スクリーンショットのリンクが自動的に [コメント] タブに追加されます。Kaspresso の詳細と、その使用メリットについては、こちらで詳しくご覧いただけます。

ローカライゼーションおよび言語テスト:

  • 用語集が用意されている場合は、Smartcatにアップロードして、ローカライゼーション全体で一貫性を確保してください。

  • 社内翻訳者を追加して、実際の仕事を受ける前にプラットフォームを探索し、操作方法を学べるようにします。

  • フリーランサーを見つけ、選択し、自社のプロセスに組み込み、スクリーンショット、コメント、用語集などの使用方法を確実に理解させます。

  • 必要に応じて、追加のローカライズやテストのニーズに対応できる翻訳会社を見つけます。

お役に立てれば幸いです。ご自身で何かお持ちでしたら、ぜひお知らせください!

💌

ニュースレターを購読する

メールアドレス *