日本では「あのピッチャーはコントロールがよい」と大まかな物言いをすることが多いですが、メジャーリーグなどでは「コマンド」と「コントロール」を次のように区別することが多いようです。
コマンド=狙ったところに投げる能力
コントロール=ストライクを投げる能力
コマンドとコントロール |
コマンドは狙ったところにピンポイントで投げる能力、コントロールの方は「ストライクゾーン」と呼ばれる一定の「枠」の中に収める能力（＝その枠の中では散らばっていてもよい）と言い換えられますね。
翻訳者も、「コマンド」に当たるピンポイント力と、「コントロール」に当たる大枠力と、区別した方が解像度が上がるよなあというのが常日頃考えていることです。
例えば、納品物について、納品を受ける側が基本的に求めているのは「大枠力」の方なんですよね。
翻訳者は自分も含めて「ピンポイント」であることに気持ち良さを感じる人も多いかとは思いますが、それはそれとして、仕事は仕事なので、ビジネス的には「大枠」に投げ込んだ上で時間当たりのアウトプット（＝生産性）を上げる方向で頑張っていくのが、いわゆる１つの right direction かなあという気がします。
とはいえ、「大枠」に投げ込めばいいやっていう翻訳の仕方ばかりしてると、進歩がないどころか下手になるとは思いますけどね。
別の場面では、翻訳をレビューした人（特にベンダー所属のレビュアー）からのフィードバックで「妙にピンポイントだなあ」と感じることがあったら、それはおそらく妙にピンポイントなだけだと思います。
たまにあるんですよね、クライアントとひと悶着あった表現・単語とか、「ここだけはきっちりせなあかんで」みたいな。
そういう「歴史あり」、「要マーク」の用語だけは、不自然なくらいに修正する、というのが、クライアントに直接納品する立場のベンダーでは発生しがちかもしれません。
そして、クライアントとのひと悶着みたいな情報までうまく情報共有できるプロジェクトはあまり多くないというのが現実かもしれません。
（そんな情報までフリーランスの方に流していては情報量過多になってしまって申し訳ない、というような気持からの場合も含めて）
本当は、
「なんかこれ妙に細かいですけど、なんかありました？」、
「いえ、実はかくかくしかじか」
「OK、わかったー。今度から気を付けてみるね（ローラ風）」くらいに風通しがよい方が、いろいろみんなハッピーだとは思うんですけどね。
以下、余談
あと、ちょっと気になる話は、フリーランスの翻訳者は、作業ファイルの不備や、指示書に記載のない不明事項などが発生したときに、依頼者への報告義務があるのかという点です。
準委任契約は、色々な責任がない分、「報告」が求められます。 なので、客から求められたら進捗を報告する義務があります。
（中略）
請負は報告義務はありません。
仕事の完成を提供して対価を得る契約なので、ぶっちゃけ「その間のこと」はどうでもいいんです。
自由です。
ちゃんと納期に開発を終わらせれば、現場に来る必要もなければ、進捗を報告する必要もありません。
よく請負契約なのに「お前会社員かよ」っていうくらい、毎日出社して朝会で進捗報告している奴がいますが、僕から言わせれば「アホ」です。（マネジメント側とかなら別ですが。）
そういうフリーランスは事業として絶対に発展（売り上げ拡大）できません。
「お前らのフリーランスになるメリットは間違っている」というお話 - Qiita
発注者としては報告して頂けた方が絶対にメリットだし、そのためには「報告した者が損をする」ことだけは絶対に避ける仕組み作りが必要ですよね。
その上で、そういう報告に関する仕組みをできるだけクリアに契約書に反映させられたらよいのになあ、と思うのですが。
JTFの契約書のテンプレートを見ても、納期遅延の話だけなんだよなあ。
＜納期遅延＞
第11条
乙の責めに帰すべき事由により、仕様書に明記する納期内に、当該翻訳業務が完了しない危険が生じた場合には、乙は速やかにその旨を甲に通知し、とるべき措置(業務の遂行方法など)については、甲、乙協議するものとする。
なお、当該協議により合意が得られない場合、乙に生じ得べき本契約上の責任が免除されるものではない。
翻訳基本契約の雛形｜JTF 日本翻訳連盟
発注者側が速やかに査収するとか、フリーランスの方による再外注の禁止とかはばっちり盛り込まれているのに。
フリーランスの方からの納期遅延って、あんまり現場では見ないけど、それよりベンダーがハンドオフしたタスクが、タスクと呼べるほど整理されてなくて問題発生みたいなケースの方が頻出だという気が。。
CATツール使ってたり、間にファイルの変換や翻訳メモリの適用が挟まれてると、いろいろ起きますよね。
