どのようなローカライゼーション技術スタックが必要ですか?

どのような種類のローカライゼーション技術スタックが必要ですか?

この質問に答える前に、この質問の中に存在するパラダイムの分断プロセスファーストとソフトウェアファーストのパラダイムについて考えてみましょう。 異なるパラダイムごとに、異なる答えとその答えに対する理論的根拠が生じます。まず、これらのパラダイムを定義することから始めましょう。

プロセスファーストのパラダイム

プロセスファーストのパラダイムは、プロセスを比較的不変の所与として確立します。 プロセスに最も適した技術スタックを探しています。 通常、このプロセスは小さなコンポーネントに分割され、各コンポーネントは一種のソフトウェアにマッピングされます。

プロセスファーストのアプローチでは、ローカライゼーションの人々は通常、プロセスを要件としてリストすることから始めます。 しかし、このプロセス優先のアプローチには大きな隔たりもあります。それは、ゼロから技術スタックを構築し始めている人々と、いくつかのプロセスに対してすでにシステムを持っている人々です。

少なくともCAT（コンピュータ支援翻訳）ツールを利用できると仮定して、ゼロから構築している人々を調べることから始めましょう。 たとえば、例としてこのプロセスから始めましょう。

1. 利害関係者は電子メールで要求します
2. プロジェクトマネージャーはステークホルダーと要件について会います
3. プロジェクトマネージャーはお見積もりのためにアセットを準備します
4. プロジェクトマネージャーはアセットをCATツールにロードします
5. プロジェクトマネージャーはログファイルをダウンロードし、ログファイルに基づいて見積もりを作成します
6. ステークホルダーは見積もりを承認する
7. プロジェクトマネージャーはアセットを準備し、ファイル、翻訳メモリ、および用語集キットを翻訳者
に送ります。
8. 翻訳者は自分のCATツールでタスクを完了します
9. 翻訳者はファイルをプロジェクトマネージャーに送り返します
10. プロジェクトマネージャー QA アセット
11. プロジェクトマネージャーはアセットをステークホルダーに返却します

人々がプロセスをカテゴリに分けることは一般的です: ビジネスマネジメント、翻訳管理、会計、コミュニケーション、品質管理、コネクター。 この文脈では、CATツールはどの技術スタックにおいても基本的なソフトウェアコンポーネントです。 それがなければ、翻訳メモリや用語集の形で知識を活用することはできません。

ソフトウェアファーストのパラダイム

ソフトウェアファーストのパラダイムは、まず市場で入手可能なさまざまなソフトウェアに注目し、次に各ソフトウェアの機能を活用する効果的なプロセスを構築しようとします。他の技術スタックのコンポーネントは通常、CATツールに重ねられます。 例えば、大きなアップグレードとして、各プロジェクトの異なる売掛金や買掛金、プロジェクトのステータス、所有権、ベンダーなどを追跡するために、PlunetやXTRFのようなビジネスマネジメントシステムをレイヤーすることが考えられます。その後、Content-quoのような品質管理を追加することを考えることができます。ミドルウェアソフトウェアを使用してコネクターを統合し、XeroやQuickbooksのような会計ソフトウェアを追加し、タダーン！あなたは終わりました。文字通り終わりました。 これで技術スタックができましたが、翻訳を予測どおりに管理するための最も簡単で効果的な方法は何か、という疑問が残ります。これらすべての異なるソフトウェアを見ているときに:

• 高額なライセンス料、
• これらの異なるプラットフォームをすべて動作させ続けるための多くのエンジニアリングオーバーヘッドがあり、
• さまざまなサポートチームとの多くのやり取りと
• 根本的に接続するように作られていないシステムを接続しようとする、非常に苛立たしいプロセス。

教訓#1

機能とユースケースの互換性から、すべてのユースケースのニーズをカバーするソフトウェアスタックを持つことは、効果的なソフトウェアインフラストラクチャを確実に整えることを保証しません。 シンプルで無駄がなく、管理しやすい状態を維持することは、全体的な管理に大きな影響を与えます。 このパラダイムからの進化として、多くの企業はMemsource、MemoQ、Tradosなどの翻訳管理システムを選択しています。 そして、Translation Managementシステムは素晴らしく、翻訳者、translation memories、プロジェクトマネージャー、顧客とのよりシームレスな統合を提供しますが、依然として廃止されない残りの技術スタックに縛られています。そしてここに来ます：

レッスン#2

自動化を意図したソフトウェアと適応を意図したソフトウェアの間には深淵があります。 私が出会うほとんどの人は、ユースケースに対応するソフトウェアを探しています。 その結果、彼らは通常、ユースケースのさまざまな次元に対応するために異なるソフトウェアの組み合わせを必要とし、最も重要なことは、多くのカスタマイズ可能なフィールドとデータ入力の柔軟性を備えたソフトウェアを好むでしょう。 例えば：

• 翻訳者のTシャツサイズのためのフィールドが欲しい
• クライアントの誕生日のフィールドが欲しいです
• 週末と夜で異なる料金を入力できるようにしたいです
• 私は単語ごと、文ごと、段落ごとに課金できるようにしたいです

ご理解いただけると思います。 ソフトウェアに何を対応させたいかについて夢中になることができ、多くの点でそうすることは正しいです。 しかし、その一方で、これらすべての要件の関連性を再考し、達成しようとしている最も基本的で抽象的な概念に焦点を当てることもできます。

• 市場投入までの時間を最小化する
• 人間の介入を最小限に抑える
• 顧客エンゲージメントを最大化します
• 品質ガバナンスツールを最大化する

大局的に見ると、それらの厳しい具体的な要件は、もはや厳しい要求ではない、より柔らかく曖昧なアイデアに変わっていきます。 その後、状況が変わり、Bureau Worksのようなソフトウェアが非常に魅力的になります。

新しいものを生み出す

Bureau Worksは、エンドツーエンドのローカリゼーションワークフローに取り組むために構築されました。

• お見積もり/スコーピング,
• 翻訳メモリ,
• コンテンツ管理,
• 翻訳者やその他の関連する関係者への自動案件配信、
• 買掛金および売掛金
• 品質管理.

5つの異なるソフトウェアコンポーネントをBureau Worksで置き換えることができます。さようなら、翻訳管理システム、さようならビジネスマネジメントシステム、さようなら品質管理システム、こんにちはBureau Works！:) 明らかに、Bureau Worksはさまざまなユーザーのニーズに統合されているものの、すべての問題の究極の万能薬ではありません。 究極の効率性を求めており、ルールとして次々と例外を伴って作業することを求めていない場合に最適です。 自動化優先のソフトウェアとして、Bureau Worksはフィールドと手動データ入力を最小限に抑えるように設計されています。 したがって、翻訳者のお気に入りのペットのフィールドが欲しい場合や、必要に応じて手動でフィールドを追加する場合には、あまり優れたソフトウェアではありません。 翻訳者が好きなCATツールで作業を続けたい場合（可能ではありますが）、またチームの人員数を最大化し手作業の必要性を求めている場合には、あまり適していません。

しかし、それが本当に重要なことです: なぜか?

現状を維持するためのソフトウェアをお探しですか、それとも根本的な働き方を再設計できるソフトウェアをお探しですか? この質問はすべてを変えます。 威圧的でリスクが高いように見えますが、再設計のアプローチは、執拗に追求すれば無限の可能性を開きます。 そのままにしておいて、そのユースケースをカバーするためにシステムの寄せ集めを組み立てるのも問題ありません。それは、過去の要件を考慮して家を建てることと、将来の可能性を考えて建てることに似ています。 断定的に正しいアプローチがあるとは思いませんが、知らず知らずのうちに真ん中に落ちてしまうことを避けるために、自分がどこに立っているのかを明確にすることが重要です。