翻訳は個人で行うことが多く、その場合は橋やビル、あるいは大規模ソフトウェアを構築する際に実施するような「設計」の段階が存在するわけではない。もちろん「これからこの一冊をどう訳そうか」と翻訳者は考えるだろうから、その人の頭の中で計画なり戦略なりは立てているはずだ。ただしここで「設計」とは、翻訳者一人だけというより、翻訳依頼者(クライアント)や翻訳会社などが関係し、翻訳者が何人も参加するような状況における設計を指すことにする。

ソフトウェア開発のプロセスでは、「要件定義」→「外部設計」→「内部設計」→「実装(プログラミング)」といった順に進む。「外部設計」とはユーザーからどう見えるかという設計、「内部設計」とはソフトウェア自体をどう作るかという設計になる。またV字モデルで言うならば、以下の図のように、各フェーズに対して検証を実施することになる。


(引用元:日経XTech https://xtech.nikkei.com/it/article/lecture/20061130/255501/


翻訳プロセスにこれを当てはめた場合、一番分かりやすいのは翻訳者が「実装」をする点だと思われる。ソフトウェア開発におけるプログラマーと同じ立ち位置である。
では翻訳の「外部設計」で何を決めるのだろうか。外部設計はユーザー(最終読者)から見てどうかという話である。だから、たとえば最終読者がエンジニアである場合、「技術専門用語がきちんと用いられている」、「エンジニア向けの日本語になっている」、「旧版マニュアルの表現を踏襲している」といった点だろうか。
続く「内部設計」は、翻訳成果物内部をどうするかという話である。外部設計を受けるならば、たとえば「あの用語集に従う」、「である調(常体)をスタイルとする」、「前回作成したTMを使う」といった話になるはずだ。

このような翻訳における設計(外部と内部)は、現在のところ翻訳会社内で実施されていると思われる。自分自身も翻訳会社にいるときにしていた。
ただ、翻訳設計は誰もが知るような公の知識になってはおらず、各翻訳会社の「ノウハウ」として蓄積されていると考えられる。ノウハウは利益の源泉になるため、翻訳会社に出してくれとは言いにくい。しかし公の知識になれば、人が同じ失敗を繰り返したり、車輪の再発明をしたりする事態は避けられる。だから大学などの公的機関が研究してまとめて公開することが社会全体からすると本当は望ましい。

実のところ、ISO 11669という国際標準規格では、翻訳の仕様を作る(つまり設計する)ためのパラメーターが提案されている。ISO 11669はお金を払わないと読めないが、その元になったパラメーター自体はMelby氏によってウェブ上に公開されている。
大きく「言語面」(原文と訳文の情報)、「制作面」(タスクなど)、「環境面」(ツールなど)、「社会関係面」(納期や費用など)と分類されている。非常に有用ではあるものの、やはり実務者から見ると少し足りない気がするし、構成がどこまで妥当なのかも分からない。こういったパラメーターも、外部設計や内部設計といった概念で分類してみるとすっきりし、かつ実務で適用しやすくなるのかもしれない。特に検証を内部設計にするのか、外部設計にするのかという分割は、概念上役立つ。

なおソフトウェア・ローカリゼーションにおける設計は自著『ソフトウェア・グローバリゼーション入門』(達人出版会インプレス)の第2章5節で触れているが、あくまでソフトウェア設計に属する話だったので、純粋に翻訳に注目した調査研究が欲しいところである。