ローカライゼーションとアジャイルの共存

Infobipにおけるローカライゼーションへの取り組みについて少しお話ししましょう。企業や開発者向けのグローバル通信プラットフォームとして、私たちは常にローカライゼーションプロセスの改善を模索しています。特にアジャイルフレームワーク内で機能させる点においてです。

そのため、私たちは最近、新たな調査と実験に着手することを決定しました。その結果、興味深く、驚くべき結果が得られました。

ローカライゼーションとソフトウェア開発：基本事項

まず最初に、ローカライゼーションとは何か、そしてソフトウェア開発とどう関係するのかを説明します。ローカライゼーションとは、製品やコンテンツを特定の地域（国や地域単位）に合わせて調整し、その文化的・言語的環境で確実に機能するようにすることです。

Infobipでは、継続的ローカライゼーションに注力しています。これは最新のローカライゼーション手法であり、ソフトウェア企業が開発サイクルにローカライゼーションを組み込む際に直面するボトルネック問題を解決するために設計されています。複数のエンジニアリングチームを抱える企業にとって非常に有益です。

従来のローカライゼーションの問題点

昨今、ソフトウェアはアジャイルと同義です。これは短いリリースサイクル、つまり開発者がソフトウェア製品に小規模な追加や変更を頻繁に行うことを意味します。こうした小規模で反復的なリリースもローカライズが必要となるため、ローカライズプロセスに関わるすべての関係者——LSP（言語サービスプロバイダー）、翻訳会社、社内チームを問わず——もアジャイルであるべきです。

残念ながら、ローカライゼーション業界は依然として伝統的な考え方、つまり遅くて直線的なウォーターフォール方式に固執しています。これは、有限のステップを一つずつ完了させてから次のステップに進む方法です。この旧式の手法は一部の業界では（かろうじて）まだ通用するかもしれませんが、ソフトウェア企業に適用するとボトルネックの問題は避けられません。なぜなら、すべてがはるかに迅速に行われる必要があるからです。

インフォビップの課題

例として、自社ケースを見てみましょう。当社の製品（UI）には約95,000語があります。120語程度の小さなテキストを、48時間以内に11言語へ翻訳する必要が生じることもあります。

当社が連絡を取ったLSPはすべて、以下の対応が必要でした：

要件を明確化し、プロジェクトを受諾する
最大11社のベンダーに連絡する
対応可能か確認し、短期間での対応が不可能なベンダーや応答がないベンダーの代替先を探す
プロジェクトの進捗を監督する
質問に回答し、問題を解決する
完了を確認し、翻訳を納品する
プロジェクトの進捗を監督する
質問に答え、問題を解決する
完了を確認し、翻訳を納品する
クライアントに請求書を発行し、ベンダーに支払う

要件のため、私たちは通常3つの問題に直面していました：LSPとそのベンダーからの最低料金、厳しい納期、そして品質の低下です。ここで重要なのは、LSPが明らかに多くの仕事を抱えているため、私たちの継続的な小規模プロジェクトの流れに対応し続けることが困難であるという点です。

継続的なローカライゼーションは常にInfobipの目標でしたが、上記の制約により、せいぜい「半継続的」な状態に留まっていました。そこで私たちは最近、ローカライゼーションプロセスを真に継続的なものにできるか検証するため、低リスク・高リターンな実験に着手しました。つまり、ローカライゼーションプロセスをアジャイルフレームワークにシームレスに組み込めるかどうかを確かめたかったのです。

Smartcatでウェブサイトやアプリを翻訳しましょう

Sing up for free

インフォビップの理念：アジャイル宣言の12原則

真の継続的ローカライゼーションがなぜこれほど困難なのかを考えたとき、私たちはローカライゼーションプロジェクトにおけるウォーターフォール型の順次アプローチから完全に脱却する必要があると気づきました。そんなことが可能だったのだろうか？

実は、2001年にソフトウェア開発者グループが同じ課題に直面していたことが判明した。彼らはウォーターフォール手法に対抗し、ソフトウェア開発の新たな手法としてアジャイル宣言を提唱した。この宣言は20年前にソフトウェア開発に革命をもたらし、今日なおかつてないほど有効である。

^{アジャイル手法 VS ウォーターフォール手法}

そこで、元のマニフェストを少し調整するだけで、ローカライゼーションもアジャイルにするための原則をいくつか考案しました。

継続的なローカライゼーションのための 12 のガイドラインをご紹介します。

翻訳は早期に公開し、後で改善する – 完璧にレビューされた翻訳を待つ必要はありません。
絶え間ないコンテンツ更新に備える – 開発凍結を要求して市場投入までの時間を遅らせるな。
翻訳は可能な限り頻繁にリリースする – 大量バッチを待ってサイクルを遅らせるな（これは旧来のウォーターフォール方式の特徴である）。
会社全体での連携を確立する - ローカリゼーションチームを孤立させてはいけません。
人材、信頼、チームワークを重視する - ローカリゼーション部門やプログラムで指揮統制型の手法を採用してはいけません。
翻訳者やその他の関係者との直接的なコミュニケーション方法を優先する - LSP を通じた間接的なコミュニケーションに頼ってはいけません。
エンドユーザーからのフィードバックを収集する - ユーザーは、本当に重要なことを示し、品質の真の評価基準となる。
継続的かつ拡張可能なプロセスを確立する - ローカリゼーションチームが不在の場合でも、プロセスが遅延してはならない。
ローカリゼーションツールとシステムを継続的に改善する - 汎用的なサードパーティ製ソフトウェアがすべてのニーズを満たすとは期待せず、内部開発も依然として必要である。
手作業を自動化または最小化する - 自動化が可能な場合は、人的なプロジェクト管理や人的関与に依存しない。
ローカライズチームが作業方法を選択できるようにする – 厳密に定義された手順を強要しない。
プロセスと計画を定期的に見直す – 必要な調整を行わずに年月を過ごさない。

実験――低リスク、高リターン

これらの原則を検証するため、ローカライゼーションプロセスの全工程を分析し、一部を削除した上で、残った工程の効率化を検討しました。アジャイルの原則は例外なく、見事に適合しました。

実験における重要な変更点の一つは、LSP（言語サービスプロバイダー）の役割の再定義でした。従来はクライアントと翻訳者の仲介役と位置付けられていましたが、我々は翻訳者とクライアント（当社）に並ぶ第三の主体として再構築しました。

適切なLSP（Beluga Linguistics）と提携した後、テスト言語としてスウェーデン語を選択し、再定義した三角関係（クライアント、LSP、フリーランス翻訳者2名）を構築しました。技術を活用し、三角関係内で相互にコミュニケーションを取ることで、ウォーターフォール型の実践を完全に排除しました。

体制とコミュニケーションの変更に加え、フリーランスへの契約と支払いを自社で管理（サードパーティ技術で数クリックで処理）し、LSPには主にフリーランスチーム管理と品質プロセスのノウハウ提供を依頼しました。これにより当社とLSPの利益衝突の可能性を排除し、全員が最終目標である「より迅速で高品質なローカライゼーション」に向けて完全に一致団結できたのです。

真の継続的ローカライゼーションの利点

この新しい三角形の配置により、ついに真の継続的な位置特定が可能となり、関係者全員に利益をもたらすことが判明しました。

ソフトウェア企業にとっての利点：

製品リリースを遅らせる必要がなかった – コードとマーケティングの両面で準備が整い次第、即座に翻訳に回されリリースされた。
言語に関する問題は即座に修正可能だった – ソース言語の問題であれ翻訳の問題であれ。

翻訳者にとっての利点：

報酬は適切に、迅速に、全額支払われました。銀行や関連手数料による控除はありませんでした。
クライアントとの直接コミュニケーション – LSP経由での回答や説明を待つ必要がありません。

LSPおよび翻訳会社にとってのメリット：

締切や事務作業の心配が不要です。
リテーナー契約のように、安定した月次収入が保証されます。

特筆すべきは、Infobip製品が生命に関わる性質を持たないため、時折不完全な翻訳が生じても許容できた点です。これにより市場投入までの時間を短縮できただけでなく、現地のInfobipスタッフがTMSの抽象的な環境ではなく、実際の国内環境でUIレビューを実施することが可能になりました。これを実現するため、まず技術的観点からローカライゼーションプロセスを分解しました。これにより翻訳エラーを修正し、変更を本番環境に公開するまでの時間をわずか10分に短縮。1日に何度でも必要な修正を適用できる体制を整えたのです。