既存の業務アプリに翻訳を組み込む際の要件のまとめ方
業務アプリへの翻訳機能の導入を計画しましょう。見積もりを依頼する前に、対象コンテンツ、言語、レビュー、データのルール、障害対応、受け入れテストを定義します。
まず、チームが別の言語で行う必要のある作業を、最初から最後まで一つ選びます。次に、その作業のどこで翻訳を使うかを決めます。単に翻訳ボタンの追加を依頼するよりも、ソフトウェアの提供会社が見積もりを作成しやすくなります。
プロジェクトの範囲には、テキスト、担当者、データ、成果物を含めます。翻訳に失敗した場合の対応も必要です。技術的な方式を選ぶ前に、以下の手順で範囲を整理してください。
初期リリースで扱う業務フローを一つ選ぶ
原文がどこから来て、承認済みの翻訳をどこに保存する必要があるかを書き出します。例えば、サポート担当者が受信したメッセージを読み、顧客の言語で返信を準備する作業が考えられます。これは要件の例であり、Vavusの導入実績を示すものではありません。
メッセージを開く、翻訳を依頼する、原文と翻訳を並べて読む、返信を編集する、送信を承認する、という各手順を列挙します。翻訳を自動で開始するか、従業員が選択したときだけ開始するかも決めます。
初期リリースの範囲は小さくします。一つの画面と明確な業務作業を対象にする方が、アプリ内のすべてのテキスト欄を対象にするよりテストしやすくなります。
対象コンテンツと必要な言語を確認する
翻訳が必要な項目を一覧にします。短いラベル、自由入力のテキスト、文書、音声を分けてください。それぞれ異なる処理やテストが必要になる場合があります。注文番号や商品コードなど、変更してはいけない項目も一覧にします。
翻訳元と翻訳先の言語を指定します。必要な地域別の言語バリエーションも含めます。通常のテキストの長さと、想定する1日あたりの処理量を記録します。提案されたサービスが、どの言語の組み合わせと入力形式に対応するかを確認してください。
短いテキストでは文脈が重要になることがあります。例えば、DeepLのテキスト翻訳APIには、文脈自体は翻訳せず、翻訳結果に影響を与えられるコンテキストパラメータがあります。また、同じリクエスト内でも、別々のテキスト項目は文脈を共有しないと説明されています。[1] 役立つ文脈情報をどこから取得するかも、要件に含めてください。
用語と人によるレビューを定義する
業務でよく使う用語を集めます。推奨する訳語、商品名、変更せずに残す単語を含めてください。この一覧を管理する担当者を一人決めます。
用語集に対応する翻訳サービスもあります。Google Cloud Translationでは、用語集を、分野固有の用語を一貫して翻訳するためのカスタム辞書と説明しています。[2] 選択するサービスと実際に使う言語ペアで、この機能を確認してください。用語集があっても、メッセージ全体が正しいことの証明にはなりません。
どの出力に、適切な専門性を持つ言語レビュー担当者の確認が必要かを決めます。レビュー担当者が原文を参照できるようにしてください。顧客向けのテキストを送信または公開する前に、明確な承認手順を設けます。
データとアクセスのルールを決める
業務フローで扱う情報を説明します。初期テストには架空の例を使ってください。ボタンが動くかを試すためだけに、実際の顧客データを試用環境にコピーすることは避けます。
テキストがどこで処理されるか、アプリが何を保存するか、誰が閲覧できるか、いつ削除されるかを確認します。ログとバックアップも確認の対象に含めてください。提供会社の最新の利用条件と、選択したプランで使える管理機能を確認します。
独自の画面を作るだけでは、外部の翻訳サービスを非公開の環境にしたり、オフラインで動かしたりできるわけではありません。ローカルでの処理が必要なプロジェクトでは、最初にその要件を示し、データの流れ全体が要件を満たすかをテストします。
遅延とエラーへの対応を計画する
期待する応答時間と、サービスが利用できない場合に担当者が行う対応を書き出します。アプリには、待機中、レビュー可能、失敗など、明確な状態を表示する必要があります。原文は保持してください。
一時的な障害と、修正が必要なエラーを区別するよう開発者に依頼します。例えば、DeepLはリクエスト頻度の制限によるエラーでは待ち時間を設けて再試行する方法を説明しています。一方、利用枠を使い切った場合には別の対応が必要です。[3] リクエストの再試行によって、同じ返信を2回送信するなど、業務上の操作が重複しないようにします。
利用量の警告とサポートの担当者を決めます。プロジェクトの費用を比較する際は、サービス料金、保守、将来の変更も含めてください。
開発前に受け入れテストを定義する
必要な言語ペアごとに、代表的な例を選びます。長いメッセージ、特殊な文字、未入力の項目、承認済みの用語一覧にある語句を含めてください。元のレコードから、保存または送信された結果まで、作業全体をテストします。
人が確認できる合格基準を定めます。例えば、商品コードが変わらない、未承認の翻訳は送信できない、失敗したリクエストが表示される、レビュー担当者が原文に戻れる、といった基準です。意味と語調は、適切な専門性を持つ担当者に評価してもらいます。不具合を記録し、変更後に同じテストを繰り返してください。
明確な見積もり依頼を準備する
業務フロー、項目の例、言語ペア、想定処理量、データのルール、受け入れテストを送ります。各項目が初期リリースに必須なのか、後のリリースで対応できるのかを示してください。前提条件と対象外の作業は書面で確認します。
Vavusでは、カスタムプロジェクトの範囲を文書で整理するサービスを提供しています。[4] 見積もりページで、既存のアプリと改善したい作業を説明してください。提案される連携、導入、テストの内容は、プロジェクトの範囲として確認する必要があります。