言語産業は過去20年間で劇的に変化しました。 2000年代初頭、一般的なプロジェクトでは個々の文書を1～2～3言語（多くてもそれ以上）に翻訳するのが普通でした。今日では、文書一式全体の翻訳が求められ、対象言語の数は2桁に達し、さらに増加を続けています。世界そのものが加速しており、顧客は翻訳コンテンツを何日も待つことを望みません。すべての言語で同時に公開されることを期待しているのです。
これにより翻訳プロジェクトマネージャー（TPM）の負担が明らかに増大します。もはや自身と顧客、翻訳者間で数通のメールをやり取りするだけの話ではありません。1日に数十回、1週間に数百回、1ヶ月に数千回もの連絡が必要になります。しかも連絡だけでなく、進捗状況やプロセスといった情報を常に把握しておく必要があるのです。
Smartcatでは、自動化こそがTPM（プロジェクト責任者）にかかるストレスを軽減する鍵だと考えています。 航空機のパイロットが多数のレバー操作から高度に技術化されたコックピット制御へと進化したように、プロジェクトマネージャーもテクノロジーを活用して心の平安を得て、真に重要な業務に集中すべきです。
本ホワイトペーパーの目的は、翻訳プロジェクトマネージャーの業務を分析し、その各要素を自動化できる可能性について検討することです。すべての項目に答えがあるわけではなく、答えがある場合でも絶対的なものではありません。ここでの主な目標は、業界全体の成功にかかわるこのテーマについて議論を始めることにあります。
言語産業におけるプロジェクト管理の詳細な分析に入る前に、翻訳管理プロセスの主なステップを簡単に振り返りましょう（下図参照）：
ステップ1: お客様のご要望に対応する
ステップ2:プロジェクトの準備
ステップ3：翻訳者の選定
ステップ4：翻訳の実行
ステップ5：品質保証
ステップ6：納品
ステップ7：支払い
当然ながら、これらのタスクは数人で分担することも可能です。すべてはLSPの構造次第です。逆もまた真なり：1人のPMが複数のワークフローを同時に管理することは可能であり、通常はそのように行われます。この非線形なパターンは、問題が発生する可能性のある要素の数を増加させます。
では、このプロセスを分解してみましょう。
翻訳プロジェクト管理の自動化
ステップ1: お客様のご要望への対応
このステップの目的は、顧客が翻訳の必要性を感じている状態から、LSP（言語サービスプロバイダー）による具体的な見積もりと納期確約を得られる状態へ、迅速に移行することです。
典型的なサブステップは以下の通りです：
リクエストを受信する
単語数を計算する
見積もりを作成する
以下のような追加要件があるか確認する
PDFのスキャン
ウェブサイトのコンテンツをダウンロードする
翻訳前に機密データを削除する
自動化がない場合、顧客とベンダーの双方にプロジェクトの発注と受諾の標準的な方法がなく、代わりにメールやインスタントメッセンジャーを使用します。これにより人的ミスが発生します：
プロジェクト関連の依頼を他のメールとまとめて保管する必要があり、紛失するリスクがあります。
既存のプロジェクトに追加のリクエストがあった場合、それがどのプロジェクトのものか覚えておき、それをチェックする必要があります。
必要な情報やファイルをすべて、プロジェクト管理システム（もしあれば）に再添付するか、あるいはメールボックスで追跡し続けなければなりません。
顧客は、単純な翻訳依頼であっても、ベンダーからの見積もり回答を待たなければなりません。そして、複数のベンダーに依頼した場合、最初に返信したベンダーがその仕事を得る可能性があります。
簡単に言えば、ベンダーも顧客も、すべての要求やプロジェクトを完全に把握し、コントロールできているとは感じていないのです。
1. 顧客リクエストの迅速な処理
顧客は文書を送信（またはポータル経由でアップロード）するだけで、即座におおよその見積もりを取得できます。プロジェクトマネージャーはメール対応やファイルのダウンロード/アップロード作業から解放されます。TPMが単純な注文を多数扱う場合、手作業が大幅な時間ロス要因となるため、この機能は特に有用です。
2. 継続的なローカライゼーションを有効にする
あるいは、WordPress、Drupal、GitHubなどの主要なコンテンツ管理システムやリポジトリ向けのAPIコネクタを利用することも可能です。自動化されたコンテンツ交換により、更新に伴うオーバーヘッドが排除されます。これは、今日のアジャイル志向の顧客では頻繁に発生する可能性があります。翻訳に必要なコンテンツは常に管理者の手元にあるため、すぐに作業を開始できます。
3. 人為的ミスを回避
ファイルは自動的に、処理および翻訳が行われる同一システムに表示されます。これにより、コストのかかる手動作業を回避すると同時に、人為的ミスを最小限に抑えます。すべての関係者は、貢献者が顧客から提出されたものと全く同一の文書およびバージョンで作業していることを確信できます。
その結果、TPMは常に新しい注文に対応できる「コンベア」を準備しており、顧客はそれが確実に処理されることを確信できます。
ステップ2: プロジェクトの準備
注文が確認された後、TPMの目標は、プロジェクトをできるだけ早く翻訳可能な状態にすることです。
典型的なサブステップは以下の通りです：
ファイルの前処理と分析、
付随情報の分析、
内部統計の算出、
内部締切の計画。
自動化なしでは、これは管理が最も困難な部分の一つとなり得ます：
ファイルが大きすぎて1人の翻訳者が対応できない場合、複数のチャンクに分割して別々の担当者に割り当てる必要があります（これはステップ3と重複します）。
過去に類似プロジェクトがあったかどうかを記憶しておく必要があります。それらは同じテキストの一部を含み、同じ用語を使用している場合もあれば、そうでない場合もあります。
翻訳者が同じ作業を二度行わないよう、新規プロジェクト内で完全または部分的な重複をチェックする必要があります。
ソースコードのスニペットなど、翻訳不要なテキストは手動で除外する必要があります。
1. よりシンプルなプロセスを採用する
解決策は、文書を分割せずにTPMが異なる部分を異なる担当者に割り当てられるようにする必要があります（ステップ3も参照）。これにより人的ミスが減り、プロセスが迅速化されます。例えば、翻訳者が応答しなくなった場合、文書を再分割する手間をかけずに、その担当部分を別の翻訳者に再割り当てできます。
2. 過去の翻訳と用語の再利用
クライアント固有の翻訳メモリ（TM）と用語集は、プロジェクト全体を通じて顧客の声を一貫させるのに役立ちます。 顧客はコストと同様にスタイルを重視します。翻訳メモリによりベンダーは重複コンテンツの翻訳時に割引を提供でき、用語集はプロジェクト全体で同一の用語が使用されることを保証します。
3. 内部統計の算出
翻訳メモリ（TM）の一致数や反復回数などの内部統計は、クライアントに提供される数値と異なる場合があります。例えば、ベンダーは顧客に対して単語数全体で課金したい一方で、翻訳者への支払いはTM一致分を減額する可能性があります。
4. 文脈に応じたコメントを提供する
原文テキストの特定部分に対するスクリーンショットや説明は、翻訳の適切性を大幅に向上させます。なぜなら、翻訳者はテキストがどこに表示されるのか、何を意味するのかを常に正確に把握できるからです。すべての文字列が自明であるとは限らないためです。
5. 納期管理の改善
システムは、過去の生産性データに基づいて各ワークフロー段階の納期を自動提案するか、納期が事前定義されている場合は必要な翻訳者数を自動提案すべきです。言語ペアや専門分野によって平均翻訳生産性は異なります。データに基づいた提案を行うシステムを導入することで、TPM（翻訳プロジェクトマネージャー）はより適切な判断を下せるようになります。
その結果、バラバラで関連性のないツールやリソースの寄せ集めではなく、ベンダー探しという次のステップに進む前に最適な判断を下せる単一のダッシュボードが手に入ります。
ステップ3：翻訳者の探し方
典型的なサブステップは以下の通りです：
社内に専門家がいる場合は確認する
予算やその他の要件に基づき、既知のフリーランサーを確認する
これらの要件に基づき、新しいフリーランサーを探す
オプション：顧客が発表した将来の仕事に向けて専門家を予約する
自動化がない場合、典型的なワークフローは、インスタントメッセンジャーやメーリングリストを通じて直接関係者の空き状況を問い合わせることです。これは時間がかかりすぎ、プロセスを管理不能にします：
従業員が休暇を取ったり、病気になったりする可能性があります。
他の顧客からのタスクが多すぎる場合や、同僚からのタスクが多すぎる場合もあります。
誰が対応可能かを把握するため、スプレッドシートなどの管理手段を維持する必要があります。
もしそのいずれも利用できない場合、求人サイトや翻訳フォーラムで新規人材を採用する必要があります。ここではさらに多くの課題に直面し、時間を費やすことになります：
導入メッセージの作成、
返信者の経歴調査、
選定者へのワークフロー導入。
1. ワークフローを一元化する
ワークフロー全体を単一のプラットフォームに移行すれば、TPMはアプリやウェブサイトを切り替える手間を省けます。ベンダー調達プロセスを一貫したUXで管理することで、労力を削減できるだけでなく、一貫性と信頼性も強化されます。社内リソースを優先するプロセスであれ、フリーランスを基盤とするプロセスであれ、操作の流れは類似しており、慣れ親しんだものとなるでしょう。
2. 選定プロセスをデータ駆動型にする
TPMは翻訳者のスキル、経験、プロフィールへのフィードバックについて詳細かつ検証可能な情報を保持しており、システムは翻訳履歴と対象ソース資料に基づいて専門家を自動的に提案します。
3. 可用性と生産性の追跡を有効にする
TPMは、現在の作業負荷と過去の生産性に基づいて各翻訳者の可用性を追跡できます。すべての作業が一箇所で実施されるため、これら両方の計算は容易です。 翻訳者の作業速度は人それぞれであり、特に多言語プロジェクトでは全員が同じタイムゾーンにいるとは限りません。そのため翻訳者間での作業配分は極めて非線形の作業となります。こうした計算を機械に任せることは非常に有益です。
その結果、TPMは数分、場合によっては数秒でフリーランサーを見つけ、割り当てることができ、他のプロジェクトに移行できます。
ステップ4：翻訳プロセス
最後に、作業の本質に迫ります。ここでの目標は、プロジェクトを期限内に高い水準で完了させることです（ステップ5も参照）。
典型的なサブステップは以下の通りです：
進捗状況を監視する
翻訳者からの質問に対応する
納期遅れを回避する
自動化なしでは、このプロセス全体がTPMにとってブラックボックスとなる：
TPMが翻訳者に直接尋ねる以外に、プロジェクトの進捗状況を確認する方法がない。
翻訳者との連絡手段は、メールやインスタントメッセージのやり取り以外に存在しない。
翻訳者が実際に約束した作業を行っているかどうかを確実に確認する方法がない。
これにより、プロジェクトマネージャーはプロジェクト全体を通じてストレスを抱え続けることになる——何か問題が起きた場合、責任を負うのは彼らだからだ。
1. 進捗状況の追跡
TPMは、プロジェクト内の各文書およびサブタスクの進捗状況に関するリアルタイム情報を把握する必要があります。状況を常に把握することで、マネージャーは問題を早期に発見し、納期厳守を確保できます。翻訳者が応答しなくなったり、長期間進捗がない場合、TPMはタスクを他の担当者に再割り当てできます。
2. コンテキストに沿ったコミュニケーション
TPMは、翻訳者からの具体的な質問をその文脈の中で読み取り、回答できる必要があります。文脈に沿った議論は、各質問の背景を説明するための時間を節約し、すべてのコメントを一箇所で管理できる環境を提供します。さらに、多言語プロジェクトの場合、コメントは全翻訳者に表示されるため、同じ質問に繰り返し対応する必要がなくなります。
3. 警戒を怠らない
システムは問題の可能性を検知した際に通知を送信すべきです。一例として、既に述べた進捗の遅れが挙げられます。その他には、締切が迫っている場合、翻訳の速度が遅すぎる（あるいは速すぎる）場合、ポストエディターによる機械翻訳の編集不足などが含まれます。
その結果、TPMはプロセス全体を把握し、あらゆる警報状況に対して迅速かつ十分な情報に基づいた判断で対応できるようになります。
ステップ5：品質の保証
品質保証の目的は、単にミスを修正するだけでなく、ミスを未然に防ぐことです。この点において、これを「ステップ」と呼ぶのは一般的に誤りです。これは翻訳プロジェクトの前、最中、そして後にも継続的に行われるプロセスです。しかし簡潔さを考慮し、ここではこのように説明します。
典型的なサブタスクは以下の通りです：
プロセス前の過去のデータを再利用する
プロセス中の品質を管理する
プロセス後に教訓を学ぶ
顧客の苦情に対応する
自動化がなければ、品質保証は主に事後対応的で直感的なものとなります。TPMは編集者を割り当てて完成した翻訳をレビューさせ、フィードバックを収集し、それに基づいて同じ翻訳者との今後の協業を継続するか否かを判断します。このアプローチは最適とは程遠いものです：
翻訳が完了するまで、その翻訳が優れているかどうかはわからない。
「優れた」翻訳者と「劣った」翻訳者に関するデータをどこかに保管しておく必要がある。
翻訳者によっては、ある点では「良い」が別の点では「悪い」場合もあり、これも覚えておく必要がある。
その結果、多くのTPM担当者は品質関連の判断を下す際に、直感だけに頼らざるを得ない状況にある。
1. データ駆動型
品質に関するすべての履歴データは、信頼性が高く構造化された方法で保存されます。品質関連のデータを一箇所に集約することで、他のプロジェクトマネージャーが再利用できるようになります。同様に、TPMとして他のTPMが報告したデータを再利用することも可能です。
2. 積極的
プラットフォームは、翻訳者の経験と専門知識に基づいて自動的に翻訳者を提案します。ステップ3で既に述べたように、特定の案件に最適な翻訳者を割り当てることで、生産性と品質の両方が向上します。
3. 協働的
編集者は翻訳者の作業を事後ではなく、進行中にレビューできます。翻訳が10%完了した段階でTPMが編集者を割り当てられれば、スタイルや用語の重大な問題、あるいは翻訳者のスキル不足を早期に特定し、修正コストが高騰する前に修正することが可能です。
その結果、品質保証は翻訳プロセスにおいて遍在し、あらゆる段階と成果に影響を及ぼす。
ステップ6：配送
このステップの目的は、翻訳された文書を顧客に引き渡すことです。
典型的なサブステップは以下の通りです：
完成したファイルを準備する
結果を納品する
自動化がなければ、多くの手作業が必要になる可能性があります：
異なる翻訳者によって翻訳された部分を「つなぎ合わせる」こと、
書式が崩れないようにすること、
大容量ファイルの場合、ファイル共有ネットワークへのアップロード。
技術的な作業だけを含むステップなのに、時間がかかりすぎている。
1. 手動での「貼り付け」や書式設定は不要
これらは自動的に行われ、各テキスト要素が適切な翻訳に置き換えられます。機械がほとんどの作業を行うため、TPMはファイルをダウンロードした後、すべてが正しく配置されていることを確認するための簡単なチェックを一度行うだけで済みます。
2. シングルユーザー体験
すべてのファイルは同一の場所に保存され、TPMまたはポータルソリューションの場合は顧客がダウンロード可能です。これにより、完了通知のメール送信や顧客への連絡にかかる時間を節約でき、誤ったファイル送信などの人的ミスを削減します。
3. 外部システムとの連携
あるいは、ファイルは顧客のCMSやリポジトリに自動的にインポートされるため、手動操作は一切不要です。これによりローカライゼーションプロセスが完了し、TPM担当者が経験のないサードパーティシステムを扱う必要がなくなります。
その結果、TPMは翻訳の配信に実質的に時間を費やしません。
ステップ7：支払い
このステップは、技術的にはプロジェクト管理の一部ではありませんが、その目的は、すべての作業に対する報酬を顧客からフリーランサーに支払わせることです。通常、これを担当するのはTPMです。
ここでのサブステップは以下の通りです：
出来高払い額の計算
オプション：時間単価払い額の計算
顧客からの入金受領
フリーランサーへの支払い
自動化なしでは、これはすぐに悪夢と化す可能性があります：
各フリーランサーの希望する支払い方法を確認する必要があります。
翻訳メモリ割引などを考慮し、支払額をすべて手作業で計算する必要があります。
各フリーランサーへの支払いを手作業で送金する必要があります。
支払先となる各国で、書類作成や税法への準拠が必要です。
その結果、TPMは実際の業務よりもこの作業に多くの時間を費やすことになり、間接的なコストは言うまでもない。
したがって、自動化の目的は以下を確実にすることである：
1. 自動支払額計算
すべての支払額は、作業内容、単価、翻訳メモリ（TM）の一致度などに基づいて自動的に計算されます。作業と支払いの連携により、外部での計算は不要になりました。システムが計算を行うために必要なデータはすべて利用可能です。
2. 個別支払いの不要性
支払いは一括で一度のみ行われ、その後の金額はフリーランサー間で自動的に分配されます。TPMが各企業からフリーランサーへの支払いを個別に処理する必要がないため、これが最大の時間節約となります。これにより、毎週何時間もの作業時間が削減されます。
3. 税務・法令遵守
すべての税務および書類関連業務は、支払い技術を提供するプラットフォームが担当し、TPM（第三者支払い管理業者）は関与しません。地域ごとの複雑な支払い処理に対応するのは煩雑な作業です。そのため、第三者に委託することでストレスを軽減できるだけでなく、潜在的な罰金リスクも回避できます。
その結果、TPMは業務の中で最も退屈な部分の一つを解消でき、フリーランサーは自国通貨で、かつ希望する方法で支払いを受け取ることができる。
結論：未来への展望
多くの翻訳プロジェクトマネージャーやLSP（言語サービスプロバイダー）は、自動化によって自分の仕事が奪われることを恐れています。なぜなら、数回のクリックで全プロセスを自社で実行できるなら、企業が翻訳会社を必要とする理由がなくなるからです。
いいえ。企業がグローバル展開する際には、常に支援が必要となります。そしてグローバル化が重要になればなるほど、その必要性は高まるでしょう。確かに、自社でローカライゼーションチームを擁する企業は常に存在しますが、これは決して新しいことではありません。
変化が見込まれるのは、企業がLSP（言語サービスプロバイダー）やTPM（翻訳プロジェクトマネージャー）に求める内容である。この点において、焦点は個別の案件の遂行や管理から、新規市場への参入に向けたプログラム全体の構築へと移行するだろう。
あなたはどちらの側に立つのか？
