Infobipにおけるローカライゼーションへの取り組みについて少しお話ししましょう。企業や開発者向けのグローバル通信プラットフォームとして、私たちは常にローカライゼーションプロセスの改善を模索しています。特にアジャイルフレームワーク内で機能させる点においてです。
そのため、私たちは最近、新たな調査と実験に着手することを決定しました。その結果、興味深く、驚くべき結果が得られました。
ローカライゼーションとソフトウェア開発：基本事項
まず最初に、ローカライゼーションとは何か、そしてソフトウェア開発とどう関係するのかを説明します。ローカライゼーションとは、製品やコンテンツを特定の地域（国や地域単位）に合わせて調整し、その文化的・言語的環境で確実に機能するようにすることです。
Infobipでは、継続的ローカライゼーションに注力しています。これは最新のローカライゼーション手法であり、ソフトウェア企業が開発サイクルにローカライゼーションを組み込む際に直面するボトルネック問題を解決するために設計されています。複数のエンジニアリングチームを抱える企業にとって非常に有益です。
従来のローカライゼーションの問題点
昨今、ソフトウェアはアジャイルと同義です。これは短いリリースサイクル、つまり開発者がソフトウェア製品に小規模な追加や変更を頻繁に行うことを意味します。こうした小規模で反復的なリリースもローカライズが必要となるため、ローカライズプロセスに関わるすべての関係者——LSP（言語サービスプロバイダー）、翻訳会社、社内チームを問わず——もアジャイルであるべきです。
インフォビップの課題
例として、自社ケースを見てみましょう。当社の製品（UI）には約95,000語があります。120語程度の小さなテキストを、48時間以内に11言語へ翻訳する必要が生じることもあります。
当社が連絡を取ったLSPはすべて、以下の対応が必要でした：
要件を明確化し、プロジェクトを受諾する
最大11社のベンダーに連絡する
対応可能か確認し、短期間での対応が不可能なベンダーや応答がないベンダーの代替先を探す
プロジェクトの進捗を監督する
質問に回答し、問題を解決する
完了を確認し、翻訳を納品する
p>プロジェクトの進捗を監督する
質問に答え、問題を解決する
完了を確認し、翻訳を納品する
クライアントに請求書を発行し、ベンダーに支払う
継続的なローカライゼーションは常にInfobipの目標でしたが、上記の制約により、せいぜい「半継続的」な状態に留まっていました。そこで私たちは最近、ローカライゼーションプロセスを真に継続的なものにできるか検証するため、低リスク・高リターンな実験に着手しました。つまり、ローカライゼーションプロセスをアジャイルフレームワークにシームレスに組み込めるかどうかを確かめたかったのです。
インフォビップの理念：アジャイル宣言の12原則
真の継続的ローカライゼーションがなぜこれほど困難なのかを考えたとき、私たちはローカライゼーションプロジェクトにおけるウォーターフォール型の順次アプローチから完全に脱却する必要があると気づきました。 そんなことが可能だったのだろうか？
実は、2001年にソフトウェア開発者グループが同じ課題に直面していたことが判明した。彼らはウォーターフォール手法に対抗し、ソフトウェア開発の新たな手法としてアジャイル宣言を提唱した。この宣言は20年前にソフトウェア開発に革命をもたらし、今日なおかつてないほど有効である。
アジャイル手法 VS ウォーターフォール手法
そこで、元のマニフェストを少し調整するだけで、ローカライゼーションもアジャイルにするための原則をいくつか考案しました。
継続的なローカライゼーションのための 12 のガイドラインをご紹介します。
翻訳は早期に公開し、後で改善する – 完璧にレビューされた翻訳を待つ必要はありません。
絶え間ないコンテンツ更新に備える – 開発凍結を要求して市場投入までの時間を遅らせるな。
翻訳は可能な限り頻繁にリリースする – 大量バッチを待ってサイクルを遅らせるな（これは旧来のウォーターフォール方式の特徴である）。
会社全体での連携を確立する - ローカリゼーションチームを孤立させてはいけません。
人材、信頼、チームワークを重視する - ローカリゼーション部門やプログラムで指揮統制型の手法を採用してはいけません。
翻訳者やその他の関係者との直接的なコミュニケーション方法を優先する - LSP を通じた間接的なコミュニケーションに頼ってはいけません。
エンドユーザーからのフィードバックを収集する - ユーザーは、本当に重要なことを示し、品質の真の評価基準となる。
継続的かつ拡張可能なプロセスを確立する - ローカリゼーションチームが不在の場合でも、プロセスが遅延してはならない。
ローカリゼーションツールとシステムを継続的に改善する - 汎用的なサードパーティ製ソフトウェアがすべてのニーズを満たすとは期待せず、内部開発も依然として必要である。
手作業を自動化または最小化する - 自動化が可能な場合は、人的なプロジェクト管理や人的関与に依存しない。
ローカライズチームが作業方法を選択できるようにする – 厳密に定義された手順を強要しない。
プロセスと計画を定期的に見直す – 必要な調整を行わずに年月を過ごさない。
実験――低リスク、高リターン
これらの原則を検証するため、ローカライゼーションプロセスの全工程を分析し、一部を削除した上で、残った工程の効率化を検討しました。アジャイルの原則は例外なく、見事に適合しました。
実験における重要な変更点の一つは、LSP（言語サービスプロバイダー）の役割の再定義でした。従来はクライアントと翻訳者の仲介役と位置付けられていましたが、我々は翻訳者とクライアント（当社）に並ぶ第三の主体として再構築しました。
適切なLSP（Beluga Linguistics）と提携した後、テスト言語としてスウェーデン語を選択し、再定義した三角関係（クライアント、LSP、フリーランス翻訳者2名）を構築しました。技術を活用し、三角関係内で相互にコミュニケーションを取ることで、ウォーターフォール型の実践を完全に排除しました。
体制とコミュニケーションの変更に加え、フリーランスへの契約と支払いを自社で管理（サードパーティ技術で数クリックで処理）し、LSPには主にフリーランスチーム管理と品質プロセスのノウハウ提供を依頼しました。これにより当社とLSPの利益衝突の可能性を排除し、全員が最終目標である「より迅速で高品質なローカライゼーション」に向けて完全に一致団結できたのです。
真の継続的ローカライゼーションの利点
この新しい三角形の配置により、ついに真の継続的な位置特定が可能となり、関係者全員に利益をもたらすことが判明しました。
ソフトウェア企業にとっての利点：
製品リリースを遅らせる必要がなかった – コードとマーケティングの両面で準備が整い次第、即座に翻訳に回されリリースされた。
言語に関する問題は即座に修正可能だった – ソース言語の問題であれ翻訳の問題であれ。
翻訳者にとっての利点：
報酬は適切に、迅速に、全額支払われました。銀行や関連手数料による控除はありませんでした。
クライアントとの直接コミュニケーション – LSP経由での回答や説明を待つ必要がありません。
LSPおよび翻訳会社にとってのメリット：
締切や事務作業の心配が不要です。
リテーナー契約のように、安定した月次収入が保証されます。
特筆すべきは、Infobip製品が生命に関わる性質を持たないため、時折不完全な翻訳が生じても許容できた点です。これにより市場投入までの時間を短縮できただけでなく、現地のInfobipスタッフがTMSの抽象的な環境ではなく、実際の国内環境でUIレビューを実施することが可能になりました。 これを実現するため、まず技術的観点からローカライゼーションプロセスを分解しました。これにより翻訳エラーを修正し、変更を本番環境に公開するまでの時間をわずか10分に短縮。1日に何度でも必要な修正を適用できる体制を整えたのです。
ソフトウェア企業向け推奨事項
総じて、我々の実験は成功を収め、適切な方法で実施された場合、継続的な位置特定がいかに効果的であるかを実証した。
ローカライゼーション・トライアングル解決済み
自社でのローカライゼーションの実践方法を学ぶには、何と言っても直接体験に勝るものはありません。しかし、実験から得た知見に基づく以下のヒントが、その過程でお役に立てるはずです：
ソフトウェア企業は、ローカライゼーションプロセスの主導権を自社で保持することを真剣に検討すべきです。外部の人間が自社以上に優れた成果を出せることはありません。
翻訳は非人間的な流れ作業ではなく、人間同士の協働であることを忘れないでください。関わる全員を大切にし、効率的な協力の恩恵を享受しましょう。
期待値を早期に設定し、担当者が専門性を発揮できると信頼してください。
翻訳者が御社のビジネスを理解するための時間的・金銭的インセンティブを提供しましょう。
全員が成長できるよう、小規模な検証や実験を頻繁に実施してください。
この最後のポイントは最も重要でありながら、おそらく最も見過ごされがちな点です。アジャイルの本質は反復、テスト、微調整にあります。この実験的アプローチをローカライゼーションプロセスにも臆せず適用すれば、ソフトウェア企業において継続的ローカライゼーションの恩恵をすぐに享受できるようになるでしょう。
