既存の翻訳ツールと独自の業務フローを比較する
既存の翻訳ツールと独自の業務フローを比較します。担当者の作業量、レビュー、データの扱い、システム連携、保守を確認してから選びましょう。
既存の翻訳ツールで、許容できる作業量と管理水準を満たせるなら、そのツールを使いましょう。具体的な不足が原因で繰り返し作業、エラー、遅延が生じる場合は、独自の業務フローを検討します。契約などの判断をする前に、同じ業務作業を使って両方を比較してください。
商業上の利害関係について：Vavusはカスタムソフトウェアを販売しています。このガイドでは、個別開発が役立つ場合と、既存のツールで十分な場合を説明します。翻訳サービスの順位付けや性能テストの報告ではありません。
比較する対象を定義する
既製のツールとは、用意された画面と設定で利用できる製品です。ファイル処理、用語の設定、チーム向けの管理機能がすでに含まれている場合もあります。機能がないと決めつけず、現在の製品とプランを確認してください。
独自の業務フローとは、自社の作業手順に合わせて開発または調整したソフトウェアです。元のシステム、翻訳、レビュー、保存先をつなぐことができます。内部で既存の翻訳サービスを使う場合もあります。個別開発は、必ずしも新しい翻訳モデルを作ることではありません。
すでに使っているソフトウェアで、コネクタや自動化を設定するという第三の選択肢もあります。新規開発を依頼する前に、この方法も検討に含めてください。
範囲の限られた作業には既存のツールを選ぶ
一人の担当者が時々テキストを翻訳し、使用前に結果を確認できるなら、まず標準的なツールから始めます。対応するファイル形式とレビュー手順が要件を満たすなら、繰り返し行う文書作業にも適している場合があります。
作業全体を試してください。担当者は原文を見つけ、翻訳し、レビューし、正しいレコードに結果を戻せるでしょうか。出力で必要な構造が保たれるか、担当者が正しい用語を適用できるかを確認します。
既存のサービスにも、単なるコピーと貼り付け以上の管理機能がある場合があります。例えば、Google Cloud Translationは分野固有の用語に対応する用語集機能を説明しています。[1] これはAPIの機能であり、すべての一般利用者向け画面や契約プランに含まれるという保証ではありません。
利用できるツールが要件を満たすなら、明確な理由なく独自のシステムを追加することは避けましょう。
明確な業務上の不足がある場合に個別開発を検討する
担当者がシステム間で何度もテキストを移したり、承認状況の把握に苦労したりする場合は、独自の業務フローを検討する価値があるかもしれません。不足している点は、観察できる具体的な作業として説明します。例えば、承認済みの翻訳を正しいサポート記録にコピーする必要がある、といった作業です。
提案するソフトウェアでは、原文と結果を一緒に保持し、レビュー担当者にテキストを渡し、承認済みの版を保存先に記録する、といった処理が考えられます。これらはプロジェクトの要件になり得る例です。現在のVavusの連携機能を示すものではありません。
まず、元のアプリが対応するインターフェースを確認します。希望する接続は、アクセス権限、利用可能なAPI、そのシステムの契約によって制限される場合があります。こうした制限も見積もりに含めてください。
どちらかのシステムが変わった際に、誰が接続を保守するかを確認します。個別開発には、最初の構築だけでなく、継続的な管理責任も伴います。
翻訳の品質は別に比較する
画面が使いやすくなるとレビューを改善できる場合がありますが、それだけで翻訳が良くなるとは証明できません。候補となる方式を、同じ代表的なコンテンツと言語ペアでテストします。意味、用語、語調は、適切な専門性を持つ担当者に評価してもらってください。
それぞれの方式で、有用な文脈をどう提供するかを確認します。例えば、DeepLのAPIにはコンテキストパラメータと用語集の設定があります。[2] これらは作業に合わせて設定し、テストする必要があります。
レビュー中は原文を参照できる状態にします。どの間違いがあると使用を承認できないか、修正をどう保存するかを定義してください。機械翻訳の出力が届くまでの時間だけでなく、承認済みの結果になるまでの時間を測定します。
管理の仕組みと総費用を確認する
各選択肢について、コンテンツがどこで処理され、誰がアクセスでき、何が保持されるかを確認します。利用する正確なサービスと設定を対象に確認してください。独自のソフトウェアでも、クラウドAPIを呼び出すなら、そのサービスにコンテンツを送信します。
費用は同じ期間で比較します。契約料金やAPI利用料、担当者によるレビュー、重複するデータ入力、設定、サポート、保守を含めます。個別開発の場合は、テストと接続先システムの変更への対応も加えてください。
自動化すれば必ず費用を回収できるとは考えないでください。処理量の少ない作業では開発を正当化できない場合があります。頻繁に行う作業で、処理ミスを測定できるなら、詳しい見積もりを検討する価値があるかもしれません。根拠のない削減率ではなく、自社の測定値を使いましょう。
決定前に小規模な比較を行う
一つの作業、代表的なテストデータ、受け入れ条件を書き出します。実行可能であれば、まず既存の選択肢を試してください。手作業の工程、レビューの負担、不具合、実現できない管理項目を記録します。
重要な不足が残る場合は、その不足を解消するための、範囲を絞った個別開発の提案を依頼します。任意の機能は分けてください。初期リリースで何ができ、それをどう確認するかについて、明確な説明を求めます。
Vavusでは、カスタムプロジェクトのための初期要件整理を文書で提供しています。[3] 見積もりページで、現在の業務手順と不足している点を説明してください。提示された開発範囲を既存ツールの選択肢と比較してから、判断しましょう。