チェック・トラブル対処Read this article in English

スコアを発明せずにローカライズ品質の推移を追う

ローカライズ品質を一つの数値にまとめて、ダッシュボードに載せて上がっていくのを眺めたい、という誘惑はよくあります。しかしそれは避けるべきです。翻訳、フォーマット、UIへの収まりのように性質の異なるものを一つのスコアにまとめると、平均の裏に多くが隠れるか、未訳文字列とぎこちない言い回しをどう重み付けするかが恣意的になるかのどちらかです。実際に意味のある情報を教えてくれるのは、もっと地味な、件数とカテゴリと時系列の推移です。

これは可視化を諦めるという意味ではありません。誠実に数えられるものから可視化を組み立て、単発の数値ではなく推移を読むということです。

ビルドごとにカテゴリと深刻度で数える

あるビルドのレビューで見つかった不具合には、カテゴリ(未訳、プレースホルダー不一致、用語の不整合、はみ出し、語調や自然さ、その他)と深刻度(ビルドを壊すものか、ネイティブの読者なら言い回しを直したいと感じる程度のものか)があります。ビルドごとにカテゴリ別の件数を記録すること — 合計ではなく内訳 — が、誠実さを保てる最小の記録単位です。

合計件数だけを見ても、ほとんど意味を持ちません。一万語の新規テキストが追加されたビルドの40件と、二百語しか追加されていないビルドの40件では、まったく異なるシグナルです。新規・変更されたコンテンツの量に対してざっくりでも正規化しておけば、単にたくさん作業したビルドの数字が悪く見えてしまうことを防げます。

  • カテゴリ: 未訳 / プレースホルダー / 用語 / はみ出し / 語調 / その他
  • 深刻度: リリースをブロックする / 直すべき / 見た目や好みの範囲
  • そのビルドでの新規コンテンツ量(おおよその語数やエントリ数で十分)
  • どのチェックで見つかったか: 自動フォーマットチェック、スプレッドシートレビュー、文脈内レビュー、プレイヤー報告

新規・解消・再発を分ける

ビルドごとの生の件数は、ある一時点の状態しか教えてくれません。推移を教えてくれるのは、各ビルドの不具合を前回のビルドと比べて三つに分けることです。新規に発生した「新規」、前回あって今回は直っている「解消」、前回フラグが立って直ったはずなのに再び現れた「再発」です。

この三つの中で最も注意を払うべきなのは再発です。新規は新しい作業のコストです。解消は仕組みが意図どおりに機能している証拠です。再発は、修正が実際にはファイルへ反映されなかったか、後の変更でひっそり元に戻されたことを意味します。これは翻訳の質そのものではなく、レビューの仕組みが「ループを閉じる」ステップで機能していないことを指し示しています。

// ビルドごとの不具合の増減(直前のビルドとの比較)
build 42: 新規=14  解消=9   再発=2
build 43: 新規=6   解消=14  再発=0
build 44: 新規=21  解消=8   再発=5  ← 再発が急増、要調査

どのカテゴリが繰り返し出てくるかを見る

複数のビルドにわたって、他のカテゴリが減っているのに一つのカテゴリだけ横ばい、あるいは増えているなら、それは文字どおりに受け止める価値のあるシグナルです。何か構造的な原因がそのカテゴリの不具合を生み出しており、同じ場所でレビューの努力を増やすだけでは自然には直りません。用語の不整合が絶えず出続けるなら、翻訳者が不注意なのではなく、用語集が存在しないか使われていないことを示しています。はみ出しが絶えず出続けるなら、翻訳者が長い文を書きすぎているのではなく、UIが最初から文字数の変動を想定して設計されていないことを示しています。

ここで有効なのは、直近その文字列を触った人に責任を割り振るのではなく、持続するカテゴリをプロセス上の問いとして扱うことです。「なぜこのカテゴリだけ繰り返し出てくるのか」を問うと、たいていは個人の力量ではなく、上流にある欠けた仕組み — 存在するのに誰も参照していない用語集、文字数の上限が定義されていないUIコンポーネント、翻訳者が必要としていた文脈をひっそり落としてしまう書き出し処理 — にたどり着きます。

ベースラインがあって初めてこれらは意味を持つ

ここまでの件数はすべて、一貫した比較の基準がなければ意味を持ちません。あるレポートではビルド44をビルド40と比べ、次のレポートではビルド43と比べていたら、その数字は推移として読めず、たまたま同じグラフに載っただけの無関係な二つのスナップショットになってしまいます。ベースラインを持つとは、比較のルールを一つ決めて守り続けることです。常に直前のビルドと比べる、あるいは常に前回のリリースビルドと比べる、そのどちらかを、推移が見えるようになるまで続けます。

また、ビルドをまたいで「同じ不具合」とみなす基準を揃えることも必要です。同じ文字列の同じ根本的な問題は、見つかるたびに新規としてカウントするのではなく、一つの再発として認識されるべきです。そうでなければ先ほどの再発というくくり自体が意味を失います。この一貫性が保たれて初めて、推移のグラフは単一の品質スコアには決してできない仕事をしてくれます。ローカライズのプロセスが実際に良くなっているのか、横ばいなのか、静かに悪化しているのかを、行動に移せるだけの誠実さで示してくれるのです。

関連記事