Asanaのローカライズをしているときに考えていること
概要
対象読者：ローカライズに関わるすべての方々
Disclaimer：この記事の内容は個人の意見であり、会社や組織を代表するものではありません
Asanaのローカライズでは、高品質かつAsana特有のトンマナや遊び心を踏まえた翻訳をすることを心がけています。
最近、ローカライズを体系的に学んだことのない方も含め、今までよりも多様なレベルの方が参加されるようになりました。そこで、チームで内部用に作成したドキュメントを（一部の情報は隠して）公開します。
属人性を排すためにこれまで色々なドキュメントを用意してきましたが、これはその中で最もポエム的なものになります。
基礎的な内容は経験豊富な翻訳者なら知っていることがほとんどだと思いますが、できるだけ網羅的に説明することで、どなたでも少しは新しい学びがあるようにしています。
Asana特有の内容が随所に散りばめられていますが、エッセンスだけ知りたい方は、最後のセクション「最後に、Asanaらしい翻訳とは」をご覧ください。
目的
この記事は翻訳の際に参考にしていただきたいチェックリストです。
一通り翻訳した後、タスクの完了ボタンを押す前の最終確認では、以下のうち自分が意識したい点をチェックするようにしてください。 また、自分が意識してこなかった分野、苦手だと思う分野があれば、体系的に勉強し、仕事の解像度を上げるきっかけになれば幸いです。
よくある落とし穴を多数書いているので、「悪い訳文」を書かないようにするのに参考にしてください。
ただし、何が「良い訳文」「名文」なのかを定義するのは難しく、その書き方を教えることはできません。（分野は違えど、Ruiさんの下のツイートに同意です。）
なぜなら、正解は一つではないからです。目的に合い、求められた結果を出せる日本語テキストであれば、どれも正解です。無数の選択肢から選ぶ作業なので、ひらめきや好みによって大きく影響されます。
「どの程度のtranscreationが必要ですか？」といった質問にも、「感覚的にこれくらい」という答えはありますが、はっきりと回答することはできません。
良いコードというのは良い文章に似ていると思う。知識をひけらかすとか技巧に走るとかではなく、平易な言い回しで、自分のためではなく読者のために書く。
— Rui Ueyama (@rui314) August 5, 2022
良い文章の書き方に絶対的なルールがないみたいに、これさえ守っておけばわかりやすいコードになるみたいなものもない。
※この記事では、以下の言葉をあまり区別せずに使っています。
「ローカライズ」と「翻訳」
「英語」と「原文」
「日本語」と「訳文」
背景
私は翻訳のきちんとしたコースを受講したことはないので、本を読んで学んだこと、翻訳会社での先輩翻訳者からのフィードバック（特にIT翻訳における標準）、実務で経験してきたことなどに基づいてこれを書いています。 翻訳学校で学べる重要なポイントが抜けている可能性があります。
今まで読んだ本の中で、特に勉強になったのは以下の3冊です。正確な引用ではありませんが、手元のメモから内容を紹介している箇所には（1）などと番号を記載します。
日本語の作文技術（本多勝一）
プロが教える技術翻訳のスキル（時國滋夫ら）
越前敏弥の日本人なら必ず誤訳する英文（越前敏弥）
前提
大前提として、ローカライズや翻訳は「英文和訳」とは異なります。クライアントのスタイル（ボイス）で、目的に合った日本語を作成する仕事です。
ローカライズの目的とは、原文が伝えようとしているメッセージを、その言語がわからない人にも届けることです。
防ぎたいエラーは重大度順に以下のようになります。
明らかに見てわかる、誤訳やコンテキストにそぐわない翻訳
スタイルガイドや指示や過去訳と矛盾する一貫性のない翻訳
不自然な翻訳
IT翻訳では言語運用能力と専門知識が必要です（2）。必要な能力・求められる品質は以下のとおりです。
英文の意味を正しく理解する（英文法、英単語）
その意味を日本語で正確に表現する（抜け漏れのない訳）
正しい日本語を書く（日本語の文法、単語）
良い日本語を書く（作文技術）
自然な日本語を書く（語彙力）
目的に合った翻訳をする
手順や指示に従う
上記について自信のない分野があれば、上記の3冊、類書、英日の文法書などで基礎を確認することをおすすめします。
また、上記のすべてに共通して、「調べる」という作業が重要です。 読者が疑問に思うであろう場所を先に疑問を持ち、先に解決しておく必要があります。私はローカリゼーションの作業は一言で言うと「調べ物」であると思っています。
作業の流れ
重要な参照資料
スタイルガイドなどの場所や内容を確認します。 よく使うリンクはタスク「🌏 Frequently used links」を参照してください。 特に大事なのは以下の資料です。
・ミッション
Asanaのミッションがすべてのバックボーンです。
Help humanity thrive by enabling the world’s teams to work together effortlessly.
世界のチームが容易に協力しあえるようにし、人々の豊かな未来に貢献します。
・マーケティングガイド
内容を外部公開できませんが、Asanaの英語でのトンマナ (ブランドボイス、キャラクター) が決まっています。Asanaを使っていて、そしてAsanaの英語を読んでいて感じられる、遊び心、フレンドリーさ、カラフルさなどは、これに基づいています。日本語でもこれを再現する必要があります。
ガイドに記載されているキーワードは最重要なので、常に念頭においてください。チャネル（コンテンツタイプ）ごとの目的や訳し方の違いにも気をつけてください。
・Asana テキスト作成ガイドライン
すべての内容が重要です。
・日本語スタイルガイド
どの仕事でも、スタイルガイドは言うまでもなく重要です。
作業手順
Referencesプロジェクトの「Channel > All」セクションの内容はどのタスクでも共通です。
AsanaやCATなど、ツールの使い方を確認してください。
HTMLやMarkdownなどの構文の基本を学んでください。
テキストエディター、プレビューツール、差分ツールなどの使い方を確認してください。
翻訳開始時
スケジュールを確認し、期日に問題があればPMに連絡します。
プレビュー、ソースファイル、リファレンスを確認します。
CATのエディターを確認します。
作業方法の指示があるかを確認します。
どこでどのように使われるテキストであり、何を目的に翻訳するのか（5W1H）を確認します。
場所の例: 画像中のテキストなら改行位置なども考える必要があります。
目的の例：ウェブサイトならSEOの流入からサインアップを増やす、ガイド記事なら情報をユーザーに正確に伝える、マーケティングメールや新規ユーザーのオンボーディングでは解約率を減らす。
ターゲットオーディエンスを確認します。
対象が一般ユーザーなら専門用語は控えめにするか丸括弧で説明を補う、Asana社員向けならカタカナ語や略語がある程度多くても大丈夫、などと判断できます。
新規ユーザー向けのテキストであれば、Asanaの世界観を体現する自然な訳であることが非常に大切です。
上記について疑問があればPMまたはレビューアーに連絡します。
翻訳中
木と森の両方を見て、正確な訳をする必要があります。
プレビュー、ソースファイル、リファレンスを確認し、全体をざっと読みます。
文章の構造、論理展開、段落と段落・文と文の関係（因果関係、具体から抽象、ミクロからマクロ、順接/逆接など）を確認します。
登場人物・登場事物間の関係を考えます。
なじみのない分野なら基礎知識や周辺情報をリサーチ・学習します（2）。
Developer noteなどの欄を確認します。
特にUI翻訳ではコンテキストの確認が重要です。
各文の意味を確認します。 文法的にどのような構造になっているのかを確認します。
関係代名詞や時制などが要注意です。
各単語の意味を確認します。 辞書を引きます。
辞書はお金で買える実力です（2）。
英和辞典は「訳語集＋用例集」でしかないので、単語の意味は英英辞典で確認します（2）。
辞書は訳語を見つけるためではなく、訳語を思いつくための助けとして引きます（2）。
用例や他動詞・自動詞の区別を確認します。
英和辞典、英英辞典、国語辞典、類語辞典（英語、日本語ともに）などを使用します。
その他専門用語などの辞書も見つけて参照します。
🆕単語の意味の確認やアイデア出しのために、ChatGPTなどのAIも使用できます。
複数の選択肢・アイデアを示してくれることにあると思う
インターネットで検索します。
Googleで単語を検索し、用例を確認し、検索結果の画像タブを見てその単語のイメージをつかみます。
動画の中で単語のニュアンスを知ります。https://www.playphrase.me/#/search （余談: Kevin's English Roomで知りました。）
訳文を考えます。
原文を読んだときと訳文を読んだときに、頭の中に同じ動画が思い浮かぶようにします（2）。
原文を書いた人が日本語を知っていればこのように書いただろうという文を書きます（3）。
訳語は必ず複数候補を考え、その中でベストなものを選びます。
ネガティブ、ポジティブ、どちらのニュアンスを持つ単語なのか。
カタカナ語にするか漢語にするか和語にするか。
訳語の表記について複数の候補がある場合はスタイルガイド、コンコーダンス、用語集、terms listなどで確認します。
少しでも迷ったらリファレンスを確認します。
CATツールに用語集（グロッサリ）がありますが、意図されているコンテキストと異なる場合は別の訳し方が必要です。
翻訳中に気になることや後でチェックしたいことがあれば、手元でメモして忘れないようにします。
過去訳（100%マッチ）の変更が必要な場合もレビューアーに伝える必要があるのでメモをします。
クエリーを挙げます。
原文のタイポについても報告します。
5〜10分調べてわからないことはレビューアーに相談してください。
その際、CATセグメントのURL・原文のコピー・スクリーンショットなどで、何についての質問なのかをわかりやすくしていただけますと助かります。
作業用のブラウザータブとは別に、参照用のブラウザータブを用意します。
該当プロジェクト・ファイル内で全文検索をするとき、作業位置がずれないように、タブを複製して検索用の別タブを用意しておくと便利です。
UI翻訳では、同じ開発者が書いた文字列、同じコンテキストで使われる文字列を検索します。
TM Suggestionタブで過去訳との差分を確認し、挿入して、必要な編集をします。
訳文を直接入力するか、原文をコピーして日本語を編集します。
タグの内容を確認し、必要に応じて編集します。
原文と訳文をそれぞれ読んで、過不足なく翻訳できていることを確認します。
英語のリスニングが得意な方は、読み上げ機能を使って原文を再生し、それを聴きながら日本語訳を確認すると早いです。
翻訳後
「見直し」をして、正しさの確認をし、自然な日本語に仕上げます。
このQAステップにはさまざまな要素が含まれます。
一度に一つの視点でチェックを行い、何周もチェックします。
慣れてくると同時に複数の視点でチェックが行えるようになります。
見直しをする前には時間を空けます。 翻訳するときはどうしても原文と訳文を1対1に対応づけることに集中して、自然な表現が二の次になります。
表示方法を変えます。
メールなどは実際の表示をプレビューをダウンロードしてコンテキストの中で訳を確認します。
CATツールでは翻訳対象外のセグメントも表示し、すべてのストリングの中で訳を確認します。
参照資料の中のどこで訳文が使用されているのかを確認します。
まず、訳文だけを通して読んでみます。
センター試験の国語では、問題文を読まずに選択肢だけ読んでも正解がわかると言われています。 同様に、日本語だけ読んでも誤訳は発見できます。
訳文を読んで違和感がある場合は、多くの場合原文を読み違えているので、文法に従って原文を検討しなおしてください。
訳文を黙読ではなく音読します。すると、不自然な点やうまくつながらない部分が見えてきます。
想定読者の質問に答えます。
自分で説明できない訳文や訳語がないようにします。自分で説明できない場合には、誤訳、原文の読み間違い、正しい訳語を使用していない場合があります。
英語と日本語の見た目の長さが明らかに違う場合は約抜けを疑います。
基本的に英語と日本語訳は見た目の長さが同じくらいになります（英語が10単語約50文字の場合、日本語は約25文字になる）。
スタイルの統一を確認します。
敬体、常体、体言止めなど（急なカジュアル感が出ないように）
句読点の有無など
訳語の統一を確認します。
英語では同じ単語の繰り返しを嫌うのでoneやheやthe Asana cofounderなどと言い換えますが、日本語では同じ表現を使っても構いません。
例：Dustin left Facebook and founded Asana. The youngest billionaire is known to be〜.
2文目をそのまま「その最年少のビリオネアは〜。」と訳すのではなく
「最年少のビリオネアにも認定されたDustinは、〜。」
「Dustinは、Forbesにより最年少のビリオネアにも認定されています。彼は、〜。」
などと訳したほうが自然です。
一方で、文末表現（〜しますの連続、〜ですの連続）などが単調になっていないかを確認します。
バランスを確認します。
カタカナの多さ、読点の密度など
複数の意味で読める表現、誤解を招く表現を修正します。
多くの場合、語順を入れ替えて、係り方を明確にすることで改善できます。
新規情報や重要情報が何かを判断し、それを強調したり、文の先頭に動かします。
Asanaのように、ユーザーの認知負荷を最小にするように心がけてください。
必要に応じて品詞を変えます。
後述しますが、英語は名詞中心の言語、日本語は動詞中心の言語（主語がよく省略されるのもこのため）なので、名詞句を動詞句に変えることが多くなると思います。 必要に応じて文を分割・結合します。
特に原文が「1文目、逆接の2文目、逆接の3文目」の場合、
「1文目、順接の3文目、逆接の2文目」のように訳す方が流れがよくなります。
ユーザーに不快な思いをさせる表現や、炎上の恐れがあるような表現がないかを確認します。
whitelist から allowlist、master (slaveの対義語) から main、看護婦から看護師、などといった用語の変化に注意を払います
NewsPicks の品川駅広告の炎上を踏まえ、「楽しくなければ仕事とは言えません」のようなメッセージは避けます。
ただし、下のツイートのように、いい感じのバズは狙いにいきたい。
【悲報】リモート会議前にアプリに煽られる pic.twitter.com/q4NHbUTX6k
— ウォッカねえさん (@VodkaNeesan) May 25, 2022
レビューの評価基準（後述）をもとにチェックします。
テクニカルな確認をします。
各タグの意味・役割を確認します。
別の文字列が表示されるプレースホルダーなのか、文字列を囲んでスタイルを決めるマークアップなのか。
太字やリンクの位置を確認します。
タグの抜けを確認します。
CATツール内だけでなく、実際に表示されるファイル形式やプレビューの中でを確認します。
URLのローカライズルールを確認します。
altテキストなどを確認します。
if/elseなどの条件分岐を確認します。
全角・半角の間のスペースの有無を確認します。
DTP案件では改行の位置を確認します。
その他スタイルガイドの項目をチェックします。
Check Forbidden/XProof で訳のチェックを行えます。
レビューアーに向けて申し送りがあればコメントします。
タスクを完了します。
レビューフィードバック
レビューアーはレビューをし、翻訳を一定の基準（後述）に従って評価します。私個人としては、自分で理由を説明できない変更はしないように心がけています。
必要に応じてTrans Diffで差分を生成し、フィードバックをお送りします。 変更箇所を確認し、レビューアーによるミスや賛成できない箇所、意図が理解できない箇所などがあればお知らせください。
この記事でチェックポイントを紹介していますが、どうしても翻訳者は英語と日本語を対応させることに集中してしまうので、訳文だけにフォーカスできるレビューアーにしか見えない世界はあります。
フィードバックは「あなた」ではなく「成果物」に対するものです。訳文や作業方法に関して客観的なフィードバックとなるように心がけています。翻訳者への個人的な批判や攻撃をすることはありません。 それより、協力して一緒によい翻訳をつくり、ひいてはユーザーのためによい体験を提供していきたいと思っています。
具体例
訳語の選び方の実例
簡単（基本的）な単語ほど訳し方が難しいと思います。
add→add assigneeなどという場合、「追加」より「設定」が自然です。"the project to add tasks to"を「追加するプロジェクト」と訳すとプロジェクトが追加する主体なのか対象なのかがわからないので、「追加先プロジェクト」などと訳します。
can→「できる」「可能性がある」の両方の可能性があります。
delegate→「割り当てる」と訳すことも、「任せる」「委任する」と訳すこともあります。
do A to do B→「BをするためにAをする」「Aをして、Bをする」のどちらが適しているかをその都度判断します。
make sure→過去に行ったことについては「〜したことを確認する」と訳してよいですが、これから行うことについては「確実に〜する」あるいは単に「〜する」の方が自然です。
more than one→「一つ以上 (one or more)」と誤訳しないように気をつけてください。「複数」「二つ以上」という意味です。
or→「または」という意味のこともあれば、同格の意味のこともあるので注意です。
pay your invoice→日本語で「請求書を支払う」とは言いません。「請求書の金額を支払う」などと訳します。
prioritize→何かを他よりも優先することと、複数のものの中で優先順位を決めることの二つの意味があります。
search→英語では「〜の中を検索する」という意味です。search projectは「プロジェクトを検索して見つける」ではなく「プロジェクトの中を検索する」です。search project for the task「プロジェクトの中でタスクを検索する」を読むとわかりやすいと思います。
track→辞書通りの意味では「追跡する」ですが、日本語で「追跡」は「逃げる者のあとを追いかける」が第一義です。「管理する」「把握する」などの方が自然な場合があります。
virtual→「バーチャル」だけでなく「オンライン」「リモート」と訳すこともあります。
youやweのように、日本語では省略できるものもあります。
at workは「職場で」と訳さなくてもよく、「仕事で〜」と訳したり、省略したりすることもできます。
managerは必ずしも「マネージャー」と訳さなくてもよく、「上司」と訳したり、省略したりできます。
you and your teamも文字通りに訳さなくてよく、省略してもよいです。
説明やSEOの観点から、キーワードの初出部分で括弧書きで言い換え・説明書きを追加することも大事です。
「CSVの列とカスタムフィールドをマッピング（対応づけ）します。」
「バーンアウト (燃え尽き症候群) を防ぐことが重要です。」
正確な日本語訳とは
理論的には原文に含まれる英単語に対応する日本語の単語を並び替えて訳文を作れば抜け漏れのない翻訳をできます。いわゆる逐語訳です。
これをベースに、原文が意味すること（特に強調したいこと）を同等の日本語で表現し、自然な訳を考えていきます。
UI、記事のタイトル、ドキュメントの章タイトルなどを参照する場合は正確なテキストを記載します。
英語のUIの場合は「Update (更新)」のように英日併記にします。
参照先の正確な名前がわからない場合はクエリーを挙げます。
正しい日本語とは
日本語の文法的に正しい訳文を書きます。
「ら」抜き言葉や「い」抜き言葉を使わないようにします。
許容範囲ですが、形容詞＋です（例：「正しいです」）や連続しない「〜たり、」（例：「〜たり、〜できます。」）は正しくないとされています。
「〜は」「〜も」は格助詞ではなく副助詞なので、それを念頭に置いて使用します。
主語と述語などの対応をしっかりさせます。
「この文が問題がある理由は対応がうまく取れていないのだ。」→
「...理由は〜ことだ。」
「...理由は〜からだ。」
「この文は対応がうまく取れていないから問題だ。」
「次のことができます。1. 〜を追加します 2. 〜を設定します」→
「1. 〜を追加できます 2. 〜を設定できます」
「1. 〜を追加する 2. 〜を設定する」
「1. 〜の追加 2. 〜の設定」
修飾語は長い順、重大な順に並べます（1）。
読点は二つ以上の長い修飾語の間と語順が逆順の場合に打ち（1）、それ以外の場合には不要な読点を打たないようにします。
助詞（てにをは）が正しく使われていることを確認します（1）。
自動詞・他動詞を確認します。
「日本語の作文技術」によると日本語の文法は未成熟です（1）。ですが、辞書を引いて、動詞が他動詞的なのか自動詞的なのか、それとも両方の形を取れるのかを確認することはできます。
「〜が向上する」「〜が〜を反映する」はOK、
「〜を向上する」「〜に〜を反映する」は微妙、
「〜を向上させる」「〜に〜を反映させる」はOK。
正しい敬語を使用します。
「ガイドをご参照してください。」→
「ガイドを参照してください。」
「ガイドをご参照ください。」
「ガイドをご覧ください。」
※「ご参照する」の「お/ご〜する」のかたちは謙譲語であり、ユーザーの動作に使用するのは不適切です。
列挙する場合は統一感を持たせます。
「タスクの追加、プロジェクトを設定する、ポートフォリオが表示されていることを確認します」→
「タスクの追加、プロジェクトの設定、ポートフォリオの表示を確認します」
「タスクが追加され、プロジェクトが設定され、ポートフォリオが表示されていることを確認します」
箇条書きでは文末表現を統一します。
ガイド記事の目次（セクションのタイトル）に「<名詞>の<動詞>」と「<名詞>を<動詞>する」という表記揺れがあれば統一する必要があります。
丸括弧を使用する場合、それが対応する場所に合っていることを確認します。
Using tasks (Asana's minium building blocks):
「タスクを活用します (Asanaの最小構成単位)」→
「タスク (Asanaの最小構成単位) を活用します」
送り仮名が正しいかを確認します。
「お話しします」が「お話します」になっているのをよく見ます。
自然な日本語とは
英語は名詞（句）と動詞を中心とした言語、日本語は用言を中心とした言語です（1）。
英語は語順が必ずカッチリと決まっていますが日本語ではある程度自由です。
日本語の「主語」も広義には修飾語です。
I do A for Bは「私はBのためにAをする」とも「Bのために私はAをする」とも言えます。
名詞句は用言に書き換えます。
「Aの設定はBを可能にします」または「Aの設定によりBが可能です」→
「Aを設定することでBできます」
無生物主語は受け身またはユーザーが主語の文に書き換えます。
「この操作をすると、システムは〜を表示します」→
「この操作をすると、〜が表示されます」
「この操作をすると、〜を表示できます」
英語のルールが日本語では適用されない場合があります。
箇条書きで、英語では最後の項目にだけピリオドを打ちますが、日本語ではすべての項目で句点を打つ・打たないを統一する方が自然です。
英単語と日本語単語の意味の違いに注意します。
claimは主に「主張する」という意味です。日本語の「クレーム」とは意味が異なります。（このように言語により意味が変わっている単語をfalse friendsと呼ぶらしい）
emailは英語では「メール」と「メールアドレス」を表します。「メールアドレス」の意味のemailを「メール」と訳すと意味が変わってしまいます。
訳語を例文の中で確認し、コロケーション（共起表現）を調べます。
日常会話やビジネス会話の中で使用される表現を使います。 Google TrendsやGoogle検索による「Google多数決」で、よく使われる表現を選びます。
socialは日本語では「ソーシャルメディア」より「SNS」と言われることが圧倒的に多いです。
コンテキストや場面に合った表現になっていることを確認します。
フォーマルなのかカジュアルなのか、正確性とキャッチーさのスペクトラムの中でどの位置を取るのか。
記事で「〜だと思います」という表現は不確定さや自信のなさを感じさせるので不自然です。
よい日本語とは
誤解のない日本語を書きます。
5W1Hが明確になるようにします。
「私は小林が中村が鈴木が死んだ現場にいたと証言したのかと思った」→
「鈴木が死んだ現場に中村がいたと小林が証言したのかと私は思った」（1）
「チームにサポートを求めるための窓口を提供します」→
「サポートを求めるための窓口をチームに提供します」
「チームにサポートを求めるための窓口を、（誰かに）提供します」
修飾語は被修飾語に近づけて、なるべく直前に置きます。
入り組んだ文では指示語を「それ」などと訳すより具体的にそれが指し示す言葉を使う方が誤解を防げます。
「〜で」は手段や理由、「〜が」は主格や逆接など、複数の意味で読める曖昧な助詞はなるべく使わないようにします。
翻訳の評価基準を確認すること
クライアントやプロジェクトごとに、レビューで点数をつける際に使用される評価基準（正確性、一貫性、技術面、読みやすさ、などなど）が設定されていることが多いので、それに基づいて、各側面から翻訳を自分でチェックすることができます。
最後に、Asanaらしい翻訳とは
復習を兼ねて、今までに変更してきた代表的な「Asanaらしくない」翻訳の例を3つ示します。ご自分ならどう直すかを考えてから、変更例をご確認ください。
注: 上記で非公開にしたスタイルガイド・トーンガイドの内容を含むので、この記事だけお読みの方にはわかりにくいかもしれません。
変更前
Bring your projects and people together with Asana
Asana でプロジェクトと担当者を一元管理しましょう
everyone—from leadership to individual contributors
上司から部下までチーム全員が
All these things close the productivity gap and lead to huge outcomes.
これらすべてが生産性のギャップを埋め、大きな結果をもたらします。
変更後
Bring your projects and people together with Asana
Asana でプロジェクトを一元管理し、全員で仕事を進めましょう
※Asanaのミッションは人々をempowerすることであり、人々が「管理対象」だと感じる表現は避けたい。
everyone—from leadership to individual contributors
リーダーからチームメンバーまでの全員が
※Asanaを使い始めると、お互いにタスクを割り当て合うことは普通のことになり、上司や部下という上下関係から、フラットな関係になる。リーダーは偉いわけではなく、単に他のメンバーが仕事をしやすい環境を整える役割を指す。
All these things close the productivity gap and lead to huge outcomes.
これらすべてにより、チームは本来の生産性を発揮し、大きな結果をもたらすことができます。
※「生産性のギャップ」と直訳しても、読者の頭にはてなマークが浮かぶので、具体的に訳す (理想/本来の生産性と実際の生産性とのギャップのこと)。
※名詞句（無生物主語）から動詞句（人が主語）に書き換える。
この記事が気に入ったらサポートをしてみませんか？