継続的なローカライズ：その意味と仕組み

継続的なローカライズとは、コードのリリース後に別のフェーズとして行うのではなく、開発と歩調を合わせてコンテンツを翻訳およびレビューする手法です。これにより、翻訳がアジャイルおよびCI/CDワークフローに直接組み込まれるため、翻訳チームへの個別の引き渡しなしに、新機能がすべての市場とすべての言語に同時に届けられます。

アジャイル開発は、迅速かつ継続的な反復を中心に構築されています。しかし、ほとんどの翻訳プロセスは依然としてウォーターフォール型の考え方に基づいて構築されています。つまり、開発が完了してから、バッチの文字列がパッケージ化され、翻訳のために送信されるのです。その不一致を解消するのが継続的なローカライズです。

このガイドでは、継続的なローカライズが実際に何を意味するのか、なぜ従来の翻訳ワークフローがアジャイル開発の下で破綻するのか、継続的なローカライズが実際にどのように機能するのか、そしてそれをどのように実装するのかを説明します。

なぜ従来の翻訳はアジャイル開発で機能しないのか？

ウォーターフォールモデルでは、プロジェクトの各ステージは、次の段階が始まる前に完了する必要があります。翻訳は通常、そのステージの1つであり、最後に付け加えられます。

それによって2つの問題が生じます。第一に、翻訳の遅延はリリース全体の遅延につながります。すべての言語の準備が整うまで何もリリースできないからです。第二に、誤訳、UIに収まらない文字列、コンテキストの欠如など、遅れて発見された問題の修正は、「完了」したステージを再度開くことを意味し、設計上、時間がかかり、混乱を招きます。

一部の翻訳ベンダーは、根本的なワークフローを変更することなく、自らをアジャイルと称しています。つまり、文字列は依然としてスプリントの終了時にキットにパッケージ化され、別のチームに送信されています。その結果、名前が変わっただけで、同じ断絶が生じます。ローカリゼーションマネージャーは、製品の異なる部分に異なるタイミングで取り組んでいる開発者と翻訳者の間で調整を行うことになり、リリースのたびに調整のオーバーヘッドが増加します。

アジャイルはローカリゼーションをどのように変えたのか？

アジャイル開発は、1つの長い連続的なビルドではなく、小さく反復的なサイクルで機能します。これをローカリゼーションに適用すると、翻訳は開発の後ではなく、開発と同じサイクルで行われることを意味します。

プロジェクトの最後に一度に大量の翻訳を行うのではなく、開発者がリリースしているのと同じ小さなバッチで、コンテンツが継続的に翻訳者に送られます。ローカリゼーションチームは、ハンドオフを待つのではなく、スプリントに組み込まれて仕事を行います。

この移行により、チームはより迅速な対応が可能になり、問題を早期に発見して修正できるようになります。これは、ローカリゼーションのプロセス自体、ツール、ワークフロー、そしてチームの構造を、定期的なバッチ処理ではなく継続的なフローをサポートするように再構築しなければならないことを意味します。

継続的なローカライズの仕組み

継続的な納品（いつでも製品をリリース可能な状態に保つ手法）は、継続的なローカライズがモデルとしているものです。開発者は、リリース前にQA、ローカリゼーション、テストのために何日も待つことを望んでいません。変更の準備ができ次第、すぐにリリースしたいと考えています。

ローカリゼーションチームにとって、これは大規模な定期的なドロップではなく、継続的なコンテンツの流れを管理することを意味します。実際には、これは通常、自動化されたトリガーを通じて行われます。開発者が原文リポジトリで文字列を追加または変更すると、それが自動的に取得されて翻訳に回されます。この際、翻訳者に時間を与えるための「文字列の凍結」を誰かが要求する必要はありません。

ここでツールが重要になります。コードベースに直接接続する翻訳管理機能と、ウェブフックまたはAPIイベントから自動的に翻訳ワークフローをトリガーできるオーケストレーション機能こそが、「継続的」を単なる「頻繁」ではなく、真に継続的なものにする要因です。Phrase Stringsは、この目的のために特別に構築されています。APIまたはCLIを介して原文リポジトリと同期するため、文字列の変更が発生すると同時に翻訳へと流れ、翻訳された文字列も同じ方法でコードベースに反映されます。統合機能の仕組みについては、APIおよび開発者向けドキュメントを参照してください。

開発チームの目標は、摩擦を最小限に抑えることです。開発者がリリースを続ける一方で、ローカライズはバックグラウンドでそのペースに合わせ、開発者の注意が必要なフィードバックのみを提示します。

継続的なローカライズのメリット

ローカライズを開発サイクルの後ではなくサイクル内に組み込むことで、翻訳者と開発者の仕事の仕方が変わります。翻訳者は、ローカライズキットを受け取るだけの受動的な立場から、製品を構築する人々と共に仕事をするようになります。

より短いリリースサイクル

ローカライズはもはや独立した段階としてクリティカルパス上に存在しないため、市場投入までの全体的な時間が短縮されます。Pegaは、翻訳の所要時間を最大75%短縮しました。以前は英語のリリースから最大4週間遅れていたマーケティングコンテンツを、人員を増やすことなく最短1週間でリリースできるようになりました。あるグローバルSaaS企業はさらに先へ進みました。ウェブコンテンツの翻訳を自動化したことで、リリースサイクルは数週間から複数言語での即日リリースへと短縮され、外部ベンダーのコストはゼロになりました。

より高い品質

切り離された文字列一覧ではなく、実際の製品コンテンツを扱って仕事をする翻訳者は、エラーやその後の問い合わせを減らすことができます。問題は、関連する開発者がまだコードベースにいる間に表面化し、数週間後になることはありません。

同時グローバルローンチ

開発とローカライズの間の遅延を解消することは、機能が数週間または数ヶ月にわたる段階的な展開ではなく、すべての市場で一度にリリースできることを意味します。

継続的なローカライズの進め方は？

継続的なローカライズへの移行は、単なるツールの変更ではなく、プロセスの変更です。移行をスムーズにするためのいくつかの実践方法：

1.異なる仕事の進め方に備えてチームを準備する

チームが変化を避けるのではなく、前向きに受け入れられるようにすることが重要です。変化を拒めば拒むほど、それが現実となったときにより大きな困難に直面する可能性があります。

2. 現在のワークフローを変更する前に、その全体像を把握する。

ローカリゼーションをコンテンツの流れとして捉え、現状で滞っている箇所を特定しましょう。プロセス全体に一度に取り組むのが難しいと感じる場合は、最も摩擦の少ない単一のステップから始めて、そこから拡大してください。

3. ハンドオフを自動化する

実務上、文字列を手作業でバッチ処理し、ファイルをメールで送信し、翻訳済みのコンテンツをコードベースに再統合するプロセスは、継続的なローカライズの効率を著しく損なう原因となります。TMSを問題トラッカーに直接接続する（例えば、APIを介してJiraなどのツールと連携する）ことで、手作業による介入なく、コンテンツと問い合わせが円滑に処理されます。

4. 安定した専任の翻訳チームを維持する。

同じ製品に長く携わる翻訳者は、一時的な人員集団では得られない、製品知識と一貫性を築き上げます。開発者は、単なるチケット上の名前ではなく、製品に精通している翻訳者からのフィードバックを信頼するようになります。

5. 文字列だけでなく、コンテキストも翻訳者に提供する。

スクリーンショット、短いクリップ、またはリンクされたチケットは、曖昧な文字列を迅速かつ正確な翻訳に変えます。コンテキストの欠如は、翻訳エラーや手戻りの最も一般的な原因の1つです。

6. 一度限りの移行ではなく、継続的なものとして扱う

初回のリリース後、ワークフローの改善を継続的に重ねていくことを見込んでください。継続的なローカライズを実現するためには、まず開発工程自体がアジャイルであり、反復的であることが前提となります。そうでなければ、翻訳プロセスを反復的に運用するメリットは限定されるでしょう。

継続的なローカライズは、すべてのチームにとって価値があるのでしょうか？

製品をアジャイルなペースでグローバル市場に提供している場合、その価値は十分に発揮されます。一方、ウォーターフォール型の前提で運用される翻訳ワークフローは、リリースのたびに効率を削減する可能性があります。継続的なローカライズにより、翻訳が開発プロセスに組み込まれ、もはや独立したプロジェクトではなく、製品リリースの一環として機能します。

継続的なローカライズに関するよくある質問