2001 年 12 月 15 日
バッテリーとエネルギー貯蔵において、最も一般的な文書の失敗は誤訳ではありません。製品ラインが先に進むにつれて、言語バージョンがバラバラになっていきます。
バッテリーおよびストレージ製品は反復が速く、製品ラインは急速に拡大します。最も一般的な障害モードは、誤訳ではなく、言語バージョンがバラバラになることです。中国の仕様は 3 回改訂されていますが、ドイツ語はまだ最初の改訂版です。顧客が間違ったファイルを使用することは軽微ですが、それによるインストール エラーはインシデントです。
この修正は、製品ラインごとに 1 つの正式な仕様を保持し、そこからすべての言語バージョンを派生することです。変更は最初にソースで行われ、その後プッシュされます。これは自明のことのように聞こえますが、ほとんどのチームのファイルは数十の文書や電子メールに分散されており、どれが信頼できるものであるかを判断する方法はありません。
単一ソースは一貫性を解決するだけでなく、ローカライゼーションの価格を見積もることができます。ソースが安定していれば、翻訳の作業負荷は予測可能です。出典が毎日変わる場合、引用は架空のものになります。
文書の最初の行には、対応するハードウェアとファームウェアのバージョンを記載する必要があります。新エネルギー製品は頻繁に改訂され、同じモデルであってもバッチ間でパラメータが異なる場合があります。新しいユニットを古いマニュアルで取り付ける顧客は、よくある紛争の原因です。
バインディングとは、ドキュメント番号に製品バージョン番号が付けられ、変更が段階的にバージョンを上げ、製品バージョンが変更されたときにドキュメントを再レビューおよび再翻訳する必要があるというルールがあることを意味します。このルールはプロジェクトの開始時に設定する必要があり、インシデントが発生するたびに再交渉する必要はありません。
通常、実装の難しさは組織的なものです。製品を変更するチームとドキュメントを管理するチームは同じ人物ではないことがよくあります。製品の変更によってドキュメントのレビューが自動的に開始されるようにするには、何らかのメカニズムが必要です。手動で監視することはできません。
バッテリー製品には、熱暴走、過充電、輸送要件、設置規則など、ほとんどの消費者製品よりも高い安全上のリスクが伴います。それらのいずれかが間違って書かれていると、人身傷害事故を引き起こす可能性があります。したがって、安全に関する章、警告の翻訳、およびコンプライアンスに関する声明を他のコンテンツと同じ立場で扱うべきではありません。これらは第一級の成果物であり、個別にスケジュール、レビュー、アーカイブされます。
実際のプロジェクトでは、安全に関する章は短く、単純に見えるため、このセクションは日常的に圧縮されています。実際、彼らのレビュー要件は最も高く、翻訳は正確であるだけでなく、対象市場の規制上の文言と一致する必要があります。警告文はいくつかの管轄区域で指定されており、文言のわずかな変更により法的意味が変わります。
安全文書用に別個のチェックリストを作成します。すべての言語、すべての規制要件、すべてのバージョンに 1 つずつチェックを入れます。インシデントが発生した場合、そのチェックリストが最も強力な証拠となります。
新エネルギーの発売には通常、かなりの数の言語が含まれるため、通常の製品よりも審査のプレッシャーが高くなります。ドメインとターゲット言語を理解しているレビュー担当者は、通常の翻訳者や自動チェックが見逃す問題を発見します。たとえば、地域の標準で指定された表現を持つ用語、地域の慣例と一致しない単位形式、直訳すると意味が逆になる文などです。
レビュー能力が不足している場合は、安全性に関する文書と主要市場の言語を優先し、残りはリスクベースの階層化で処理します。レビューを完全に削除するという選択肢はありません。人間によるチェックを行わない機械翻訳は、規制されたコンテンツでは最終的に失敗します。
FangService には、新エネルギー技術文書に対応する言語でのドメイン レビュー リソースがあり、安全性とコンプライアンス ファイルは、第一級の成果物プロセスを通じて実行されます。製品タイプと対象市場を提示し、1 つの文書の分類計画から始めます。
ストレージ プロジェクトには、所有者、EPC 請負業者、送電網会社、運用チーム、火災検査担当者など、非常に多くの関係者が関与します。彼らはまったく異なる優先順位で同じシステムを見ています。電力会社は電力網接続パラメータと保護設定を読み取ります。操作では障害コードと交換手順を読み取ります。所有者は運用コストと保証の境界を読みます。この文書は 1 つの包括的な技術マニュアルとして書かれていますが、そのどれにも役立ちません。運用のみを目的として書かれたものでは、電力会社はそれを受け入れません。その方法は階層化です。パラメータ テーブルがマスター ドキュメントを形成し、各役割が独自のクイック ガイドを取得し、番号付けが一貫しており、改訂時にチェーン全体が一緒に更新されます。
リビジョンの同期は 2 番目の罠です。障害コードを追加および削除する BMS ファームウェアのアップグレードは、マスター マニュアル内でのみ変更されている場合、役割固有のガイドが古いバージョンのままになり、現場では古いコード テーブルに対して新しいファームウェアを検索することになります。 FangService は、用語集とバージョン番号をこれらのプロジェクトにバインドし、リビジョンの範囲内のすべての派生ドキュメントをカバーし、主要なリビジョンの変更概要ページを発行して、クライアントの運用チームがそこからトレーニング資料を直接更新できるようにします。
エネルギー貯蔵ドキュメントには決定的な特徴があります。それは、開発、提供、運用に及ぶ長いライフサイクルであり、多くの関係者と多くのバージョンが存在することです。ドキュメントを 1 回限りの成果物として扱うプロジェクトは、最終的に 3 年目にドキュメントを何度も書き直すことになります。運用側は新しい形式を必要とし、クライアントは新しいテンプレートを必要とし、新しい市場は新しい言語を必要とし、そのたびにコンテンツが古いファイルから発掘されます。
資産化とは、一貫した構造、独立したモジュール、安定した番号付け、管理された用語、追跡可能なバージョンなど、最初のドラフトから再利用できるように設計することを意味します。これらが整ったら、言語の追加は書き換えではなく掛け算であり、役割の追加は組み合わせです。前処理に費やした時間は、その後の再利用のたびに返されます。
FangService は、用語ベース、翻訳メモリ、バージョン管理ルールを、納品して立ち去るのではなく、プロジェクトの一部として納品します。クライアントが受け取るのは翻訳だけではなく、継続的に機能する資産であり、小規模なチームにとっては単価の割引以上の価値があることがよくあります。