プロ雑用です！
わたしは一切英語は喋れませんし、英文を読むこともできませんが、今日はそんな話をしつつ、言葉のニュアンス違いによって誤解が生まれるけど、それってなんでなのかなっていう話です。

英語が日本語化されるときに生ずる誤解

ビジネスでは、海外で提唱された理論やモデルやフレームワークを使うことはよくありますよね。そのときには、カタカナ語として定着するパターンの他、和訳されて使われるパターンがあると思います。個人的にはどちらのパターンも日本語に帰化した言葉と呼んでいるのですが、帰化した結果、意味がふんわりして元々の意味が薄れてしまう、なんなら誤解を生んでしまう言葉が多いなと感じています。

ニュアンスが違う言葉たち

たとえばStoreとShopは和訳するとどちらも「店」ですが、店は商店の意味なので、その場合はStore（商品を売る店＝商いをする店）が対応します。Shopは製造や加工も行う店を意味するため、直訳できる言葉がありません。工房がworkshopに対応するので、その意味ではshopは工房が近い意味ではありますが、日本語の工房は必ずしも販売しているわけではないので、直訳とはなりません。

また、調理に関する言葉では、日本には「焼く」「揚げる」「炊く」「煮る」などがあります。焼く＝bake、揚げる＝flyとなりますが、煮るに関しては、低温で煮る＝simmer、弱火でコトコト煮込む＝stew、シチューなどで肉を煮込む＝braiseなど、日本語の煮るだけでは表せない英訳になります。そして、炊くに至っては直接対応する単語がありません。

古い時代の意味に翻訳語の意味が付加された言葉

先程あげた対応する英語がない「炊く」はより広い意味のCookに含まれて訳されることが多いようです。同じように、直接対応する言葉ではないが、一部共通する意味が含まれているため訳語とされる言葉もあります。

たとえば、自然。現在はNatureがその対応ですが、元来の自然の意味は、Natureと完全に対応していたわけではありません。明治時代の翻訳で自然がNatureの訳語となったことで、現在ではNatureが持っていた意味も、自然に取り込まれました。

元々共通したいたのは人為があるか否か。また文法としては、自然は副詞的、Natureは名詞として使われている点です。わかりにくいですので、言葉のイメージを文章にしてみましょう。

自然→「草木が“おのずと”そこにある状態」
Nature→「動物や草木など人間を取り巻くもの」

自然には人間の視点は含まれていないのに対し、Natureは人間とのあきらかな対立構造があります。自然は、草木に人為的に変化を与えてもそれは人為的が加わった自然ですが、Natureは人為的になった時点でNatureではなくなる、ということです。

明治時代にNatureの意味が自然に加わったことで、自然の意味は拡張されましたが、例えば、日本には里山というものがあります。里山は日本人にとっては豊かな自然と感じますが、英語圏の人々は里山をNatureとしては捉えません。一方で原生林は自然でありNatureでもある、というのが一番わかりやすいですかね。

我々が普段日常的に使っている言葉も、翻訳が対応したことで意味に変化が生じることがあります。ですがニュアンスそのものまでが完全に対応したわけではないので、文章を直訳すると意味があいまいになったり、誤解をうんでしまうことになるんですね。

ほぼ誤訳といえる訳語もある

この例で最もわかりやすのはManagementでしょう。
Managementは「管理」と訳されることが多く、ビジネスでも概ねこの意味で使われています。しかし、これは明らかな誤訳だという指摘は少なくありません。

英単語はラテン語に語源を持つものが多く、私はニュアンスを捉えるためによく語源をたどる方法を取ります。それによると、ManagementはManageの名詞形で、Manageの語源はラテン語の「manus：手」です。参考までに、同語を語源とする言葉は、Manual（手動）やManipulate（操作する）などがあり、Manageも元来の意味は「うまく巧みに（手で）扱う」です。

管理という日本語は、古い時代「管轄辦理」を略したとされます。管は門の鍵、轄は車輪のくさび、2つを合わせた管轄は支配を意味、辦理は弁別処理を意味し、合わせて書類や物品の処理し取り仕切る・支配すること、という意味になります。明治時代には管理と書いて「シハイ」「トリアツカフ（ウ）」というふりがなが振られているそうですし、それ以前の江戸時代にはシハイが管理のフリガナとして用いられています。

近代において、管理の英訳には、Manage、Administer、controlが３つが対応していますが、管理職はマネージャーと訳されます。しかし多くの場合、この管理の意味はManageではなく、control（抑制）で捉えられています。
これは、そもそもManageの単語が日本人に馴染みが薄いこと、くわえて戦後の状況が関係しているそうです。戦後、GHQはcontrolを統制で和訳していましたが、統制という言葉が戦中の後ろ暗いイメージが残っているため避けられることになり、代わりにcontrol＝管理と当てたことで誤訳の始まりのようです。そのため、管理の意味は現在に至るまで混乱して用いられ、それが管理という言葉にも影響し、そしてマネージャーを管理職と訳したため、controlのイメージがマネージメントという言葉にフィードバックされている、と考えられます。「会社のために部下を押さえつける役割」というマネージャーのイメージは、さまざまな事情が絡んでいるんですね。

ドラッカーの著作マネジメントにはMBO：Management by objectivesという考えが言及されていますが、これは「目標管理」と訳されます。本来の意味はニュアンスを意訳すると「目標による組織の運営」となり、やはり目標管理としてしまうのは誤訳とは言わないまでも的を外した訳です。
ドラッカーはマネジメントを組織運営＝経営の意味で使っており、マネージャーとは経営者を指し、経営者とは「組織をうまく運営する人」です。管理とは、組織をうまく運営するための手段の一つでしかないのですが言葉のイメージに引っ張られて、それは組織運営にまで影響を及ぼしてしまっているのですね。

余談：Vモデルの単語ニュアンスを修正してみる

さて、本題はここで終わりなので、ここからは余談です。
次回のnoteでは、Vモデルというプロジェクトマネジメントのフレームワークについては触れますが、これも和訳が微妙に的を外していて分かりづらく、なにより意味がしっくりきていないため、このニュアンスを正しておかないと、解説がいろいろとややこしくなるため、ここでは余談ではありますが、次回のnoteをわかりやすくするために、英語版を参照しながら可能な限り正しいニュアンスの修正を試みたいと思います。

Vモデルとは

Vモデル（あるいはV字モデル、V字プロセス）とは、ドイツ生まれのプロジェクトマネジメント手法で、ソフトウェアエンジニアリングの領域でも、昔はよく見かけたモデルですが、今これをあえて使っているエンジニアは少ないのかな？と思います。特にモダンなWEBサービス開発の現場では聞かないので、若い人には馴染が薄いかもしれません。（情報処理とかの授業ではもしかしたら習うかもしれません）

Vモデルは、いわゆるウォーターフォールの発展系モデルのひとつです。Wikiに載っているこの図では一番上が要求分析となっていますが、これが図によって「要求受入」「要件定義」と分かれている場合や、単に「要件定義」になっている場合もありますが、概ね意味するところは同じです。

右側のファネルは、コーディングで実装したものを検証を行います。同じ高さの右ファネルの項目に対応しており、対応する項目の意図通りに動作するか？を検証します。この、設計の意図通りというのがポイントで、つまり設計がなければ動作は検証しようがないということでもあります。

単語めっちゃわかりにくい

見て分かる通り、ずいぶんと日本語が雑というかざっくりした訳になっていますね。英語の意味するニュアンスを無視する、特にofなどの前置詞を無視して単語だけ直訳するとこういう感じでわかるようなわからないような意味になります。左ファネルの要求分析は置いといても、その後の基本設計、機能設計、詳細設計って、このままで見た人が同じようなニュアンスで捉えることができるかといえば、まぁ無理だと思います。
基本の機能を詳細に設計する、と一文にできる時点でもはや意味がわかりません。単語の意味が広すぎるのです。

右ファネルのほうが、まだわかりやすいです。システム、結合、単体はそれぞれの大きさのイメージが、システム＞結合＞単体と並べられるので、図の並びとまだ整合性が理解しやすいです。（それでもシステムと結合の並びはちょっと微妙ですが）

英語版を参照してみる

下の図が英語版wikiのV-model (software development)にある図です。

パッと見で、項目の数が日本語より一つ足りないのがわかりますね。まぁ、それは日本語でも英語でも文献によってVモデルの項目数にばらつきがあるので仕方ありませんが、これをヒントに、そして英語版Wikiの内容を参照し、また他のVモデルの図を参考にしながら先に出した日本語版WikiのVモデルに当てはめてみたのが下図になります。

英語からもっかい日本語に訳してみる

で、これを再度、日本語に「意訳」してみたものが下図です。

この図も日本語訳は当然完璧ではないのですが、かなり元々のモデルの意味するニュアンスには近くなったと思います。ただ、一点、検証の意味は日本語の対応限界でした。上図の英訳では検証に当たるのは、validation（システム検証の「検証」）と、verification（機能の統合テストと検証の「検証」）と違いがあります。

Validation（検証）は、製品やシステムがユーザーまたは利害関係者のニーズや要求を満たしているかどうかを確認するプロセスです。つまり、製品やシステムが本当に必要とされる機能や性能を提供しているかどうかを検証すること。主に開発の最終段階で行われ、実際の利用環境で行われることがあります。例えば、製品がユーザーが求める機能を提供しているか、ユーザビリティやパフォーマンスが期待通りであるかを確認することが含まれます。

Verification（検証）は、製品やシステムがその要求事項や仕様に対して正しく設計されているかどうかを確認するプロセスです。つまり、製品やシステムが仕様書どおりに構築されているかどうかを検証することです。主に設計段階で行われることが多いです。例えば、コードが要求された機能を適切に実装しているかどうかを確認することが含まれます。

この2つの違いはとても大きいのですが、それについてはここではさらに横道にずれるので、詳しくは次のnoteで言及したいと思います。

言葉が違う＝文化と歴史が違うと意識する

このnoteでニュアンスという単語をよく使いましたが、ニュアンスは「言葉や表現に含まれる微妙な意味、その奥に感じ取れる意図」という意味になります。ニュアンスを、単に微妙な、と訳してしまうと間違った意味になりますが、日本語では対応する言葉がなく文章でしか意味が説明できないものは、そのままカタカナ単語として定着しやすいですよね。しかし、そうであるがゆえに意味が人によってバラついていて、しかもそれをみんな意識できていないことで後にトラブルになる…なんていうことは多々あります。

また、単語は日本語でも英語でも、文脈によって意味が変わってくるものが多くあることは、ここまで記したことで理解できました。そのために、単語だけ拾って訳してしまうと意味が全く通らなくなる場合も多いです。

「おはよう」「こんにちわ」なども、英語では「good morning」「good afternoon」ですが、直訳してしまうと「良い朝」「良い午後」で意味が全く通じません。ではこれが何故対応しているかというと、文化的な慣習として共通項があるからです。

また日本語の「すみません」「おつかれさま」「ヤバい」「かわいい」などは意味のバリエーションが多すぎて、英訳しきれないというのも一例でしょう。

このような違いは、言葉が文化的背景を持っていること、また文法の違いによる文脈の違いが関係しています。それぞれの単語が生まれた経緯だけではなく、言葉の成り立ちがそもそも異なるため、同じ意味のようでいても、詳細の意味合いは異なってくるのです。また、同じ単語でも時代によって意味はどんどん変化していきます。

考えてみればこれは至極当たり前の話ですが、普段の生活においては、なかなか意識することはありませんが、グローバル社会と言われるようになり、様々なビジネスモデルや文化が入ってくるとき、単語そのものよりもその意味とニュアンスを捉えていくことが重要なことだと思います。

今回は英語と日本語というわかり易い例で解説しましたが、同じ日本語であっても同様のことはよくあります。特にビジネスにおいては職種、業種、地域が違うと同じ単語の意味するところが全く違うことは多くありますよね。自分以外の人がどういう意味でその言葉を使っているのかは、深く注意し、きちんと言葉が意味するところが共通しているのか、認識合わせすることはビジネスをするうえでは重要なことです。

ということで、今日はこれまで。
それじゃ、また👋