単語数だけでなく、ローカライゼーションのリードタイムを測る

単語数は測定しやすく、翻訳量を見積もるのに役立ちます。

しかし、それだけではローカライズされたキャンペーンが期限どおりに開始できるかは分かりません。

500語のページでも、キューで6日待ち、翻訳自体は数分で終わり、その後さらに2日間レビュー待ちになることがあります。リリースで高くつくのは、単語数ではないことが多いのです。判断と判断の間で失われる時間です。

リクエストのライフサイクル全体を測る

ローカライゼーションのリードタイムは、コンテンツが翻訳可能な状態になった時点で始まり、対象ロケールが意図した到達先に達した時点で終わります。

その到達先は、承認済みドラフト、CMS への正常なプッシュ、または公開済みページかもしれません。終点を明確に定義し、各フェーズを分けて報告しましょう。

1. 翻訳待ち
2. ドラフト生成
3. レビュー待ち
4. アクティブレビュー
5. プッシュ待ち
6. 公開待ち

フェーズごとの内訳を見ることで、実際にどこで作業が滞っているのかが分かります。

キュー時間はプロダクトのシグナル

リクエストの大半の時間が待機に費やされているなら、より高速なモデルでも配信速度は大きく改善しません。

キュー時間が長いのは、バッチが大きすぎる、責任の所在が不明確、通知が適切なレビュアーに届いていない、または優先度の低い作業がリリース直結のページを塞いでいる、といったことを意味する可能性があります。こうしたのはワークフローの問題であり、単語数では明らかにできません。

中央値と高パーセンタイルの待機時間を追跡しましょう。平均値では、繰り返し公開開始に間に合わない少数のリクエストが見えなくなることがあります。

機械の時間と人の時間を分ける

生成時間はインタラクティブな作業では重要ですが、カレンダー上の時間を最も消費するのはレビューであることが少なくありません。

アクティブレビューの時間は、レビュアー待ちの時間とは独立して測定しましょう。アクティブレビューが遅いなら、チームにはより良いソース文脈、用語、プレビューリンク、またはより小さなフィールド単位の変更が必要かもしれません。待機が長いなら、原因はルーティング、処理能力、または優先順位である可能性が高いです。

同じ合計リードタイムでも、必要な改善は大きく異なることがあります。

手戻りループを測る

最初のドラフトが速くできても、レビューに3回差し戻されるなら成功とは言えません。

リクエストがどれだけ頻繁に再生成されるか、承認後に再オープンされるか、CMS へのプッシュ後に変更されるかを追跡しましょう。それらのイベントには、ソース変更、用語の問題、書式の問題、市場からのフィードバックといった理由を対応づけます。

手戻り率は、速度に品質の文脈を加えます。これにより、単に負荷を下流へ移すだけの初回通過指標を最適化してしまうことを防げます。

同じ条件同士を比較する

リードタイムは、コンテンツのリスクやワークフローポリシーによって変動します。

2段階の承認が必要な法務ページを、自動公開される短い製品ラベルとベンチマーク比較すべきではありません。レポートは、コンテンツ種別、対象ロケール、優先度、意図した到達先ごとに分けましょう。

また、初回ローカライゼーションと更新も区別してください。新しいページの翻訳と、変更された1段落の改訂では、最終的な単語数が同じでも作業範囲は異なります。

この指標を運用習慣にする

有用な週次ビューは、次のような小さな構成でも十分です。

• 翻訳可能状態から翻訳完了までの中央値
• レビュー待ち時間の中央値
• 承認から公開までの中央値
• 要求された期限までに完了した割合
• 再オープンまたは再生成されたリクエスト
• 優先度別の最古のアクティブリクエスト

トレンドラインだけでなく、例外も確認しましょう。あるロケールで繰り返しブロックが発生していれば、四半期レポートに現れるよりずっと前に、担当者不在や権限不足が見えてくることがあります。

要点

単語数はコンテンツ量を測ります。リードタイムは、チームがどれだけ出荷できるかを測ります。

ライフサイクル全体を追跡し、待機時間とアクティブな作業を分け、手戻りを含め、同程度のリスクを持つリクエスト同士を比較しましょう。目標は、すべての翻訳を瞬時にすることではありません。多言語リリースがソースコンテンツと同じロードマップに沿って進められるだけの予測可能性を備えたワークフローを構築することです。