[言葉] エンジニアたるもの、用語の意味を間違えることなかれ [定義]

Pocket

Tweet

エンジニアに限らないんだけれども、単語・用語、そして言葉の意味をまちがえる、というコトは、相手との意志・疎通を阻害する要因にしかなりません。
IT用語など、特にあいまいに語られやすい用語がたくさん使われている業界においては、「用語集」を作って、相手と齟齬がないように会話・対話を進めることが肝心です。

わたしは、ずっと ITアーキテクト、と言う職務についていますが、「用語の定義」については、最初からきつく学ばされています。そもそも「アーキテクト」「アーキテクチャ」とはなんぞや、と明快に答えられることが望まれています。用語や単語といったものは、自分の思いで勝手に定義してはいけないです。勝手に定義した言葉を使うことで、相手と認識に祖語が発生し、意思の疎通ができなくなるからです。

難しい漢字を並べてみましたが、言ってみれば通じない言葉を使わないことが大事だと言うことです。

そんな中、欺瞞に満ちた文章で、用語どころか日本語自体をまちがえた blogを見つけて、とても悲しい思いをしました。
その内容自体は悪くはなかったですし、訴えたいことはよく分かるので、あえて日本語の言葉尻をとって「ありゃぁダメだ」と言う気はさらさらありませんでした。しかし、完全にちがう意味合いになってしまい、その所為でじっくり読む気も失せてしまった人は、私一人ではないと感じています。

あえて、それを祭り上げる気もありませんが、まちがいやすい点についてご紹介します。普段、自分の接しない部分では、用語の使い方をまちがえてしまうことは往々にしてありますから。
正しいだろうと思いながら使っている言葉が、よくよく調べてみたら、まったくちがう意味で恥ずかしかった、と言う経験はないでしょうか。例えば、「ぞっとする」「ぞっとしない」のように反意語でない使い方や、「確信犯」の様にまったくちがう意味で使われていたり、「なおざり」「おざなり」のちがいが不明確だったり、あえて自分が慣れない言葉を使うときに、このような失敗をする傾向にあります。

では、エンジニアとしてまちがえてしまってはならないものとはなんでしょうか。
外来のものを使っている手前、次の2つに気をつけるべきではないかと考えています。

カタカナ用語

主にカタカナ用語でしょう。

日本語として最適な単語がない場合、その発音をベースにしたカタカナ単語・用語が浸透し、そのまま日本語として利用されていることがあります。コンピュータ、テレビ、ラジオなど、普段から目にするものでまちがえようのないものが多いです。

ただ、エンジニアリング、アルゴリズムなどになってくると、明快に答えられる人は少ないのではないでしょうか。
特に、エンジニアリング、については接頭辞や場所によって、意味合いが若干変わるケースもあり、使い方が難しい用語です。Wikipedia で見ていただいても、いくつかの意味合いをもつ、使い勝手のわるい用語です”エンジニアリング – Wikipedia” 。
このような用語は、実のところ、あまり使うべきではありません。

その代わり、「エンジニア」 => “技術者 – Wikipedia” という用語は多用されていて、まちがいも少ない用語となっています。面白いですね。

とは言え、ITの技術者、と言う意味での「エンジニア」は幅が広すぎて使い勝手が平易ではありません。特に「IT技術者」自体が「Information Technology Engineer」と英語で言うとそれっぽいのですが、日本語だと「情報技術技術者」という重複表現にも見えます。怪しいですよね。

無理矢理日本語化されたもの

PMBOKやBABOK見ると分かりますが、半ば強引にも近い、日本語化されたものがあります。
これらは、英語の文意をちゃんと理解していないと、似たような日本語を使ってしまって、まったく異なる文章になってしまうケースです。

今日の本題です。あるところでみたblogが、これの所為で完全にまちがった文意になってしまい、せっかく内容が良かったのに「やむ落ち ^[I]知りたかったら TRICK 見てください 」してしまった話です。

IT業界では、上流から下流へフェーズを伴って、成果物を開発し、テストしていきます。上流・下流という言い方が好きではないアーキテクトも多いのですが、あえて、業界の人にぴんときやすい方をつかいました。
この上流工程において、「Requirements Definition」を実施します。日本語で言うと「要求定義」「要件定義」などと訳されます。「要件定義」局面(工程)では、相手の「要求」をまとめて「要件」と「制約」にまとめ、どのように ITで解決するか、ソリューションまでを定義する局面になります。ゴールについては、会社などによって変わりますので、厳密にはこれが正しいとは言いませんが、「要件」と「制約」事項に分類されて、整理されることが一番重要なポイントです。

この度、私が見ていたとあるblogでは、これらが「要望」と「仕様」と書かれていました。似ているようですが、まったく違います。

ご説明します。出典は「大辞林」です。

要件

必要な条件・欠くことのできない条件

要望

物事の実現を強く望むこと

制約

制限や条件を付けて、自由に活動させないこと。
物事の成立に必要な条件や既定。

仕様

やりかた。方法・手段。

「要件」とは、欠いてはいけない要求です。実現しないといけない「条件」であることです。したがって、お客様から提示された「要件」は、基本、全て実現しなければならないことです。
それに対して「要望」とは、「実現してほしいなー」です。無くてもいいことです。実現がめんどくさいなーと思ったら、落としたって、文句の言われないレベルです。

次に、「制約」です。活動の範囲を制限することです。例えば「予算はここまで」「サービスインはココ」と、変更不可能な条件を指し示しています。
「要件」よりも条件が厳しいものです。「制限」されていますから。

それに対して「仕様」とは、そもそも意味合いがちがいます。上流工程では「要求仕様」といったように「要件のまとめ方」「要件を実施するための手段のまとめ」のように使われています。そもそも、お客様が「仕様」を明示してくるようなことはまれと考えられます。
少し、緩和された意味合いをもつ「仕様」”仕様 – Wikipedia” でも「Specification」であり、「制約(Restriction)」ではありません。

今回、私はこのような誇大解釈をしながら、そのblog を読了したわけですが、エンジニアとしては残念に思わざるをえません。
用語の意味をちょっとまちがえました(;^^)ヘ..、ではなく「日本語まちがえました」なので、フォローのしようがありません。

用語を間違えることなかれ

こういった用語をまちがえることによるマイナスは、全部自分に返ってきます。特に、年を取ってからでは、誰も注意もしてくれず、自分で注意をして正していかなければ、まちがったまま使い続けることになります。
なんとなく、blog でちょっと誤用している程度では、あまり何も起きませんが、仕事で誤用したまま使っているコトは、自分を辱めるとともに、会社の品位にまで影響する場合があります。

「敬語」云々以前に、正しく日本語を使えているかどうか、自問自答をしながら振り返ることが大事なのではないかと、日々、考えてます。私の日本語が完璧だとは言いませんが、ずっと正しく日本語が使えているかどうか、大辞林を片手に生活をしています。

我が家では、三女から「◯◯の意味はなに?」の問いかけが多く、答えられないで恥ずかしい思いをするわけにもいきません。これからも、日々、勉強して学び、正しい日本語を心がけたいなーなんて考えた次第です。

かしこ。