先日、とあるお仕事でのことですが、「Route」のことを「ルート」と表記した資料を元にいろいろと話を進めていました。
わかりにくいのでアルファベットにしましょうか、という提案をしたところ、本来「Route」となるべき所が、「Root」(スペルを勘違いされていた）となってしまったことがありました。
「Route」と「Root」はどちらもITインフラ周りではよく出てくる用語ですので、一見すると意味が通ってしまったりして大変ややこしい思いをして苦労しました。
私は自分で資料を作る際には、ほとんどの場合において、類似のカタカナ語が存在する場合はアルファベット表記を使うことにしています。
この例であげたRouteとRootや、PacketとBucketなんかもそうですし、PathとPassなんかもわかりにくいです。WeightとWaitなんか、両方ともお尻に値がついて「ウェイト値」という言葉で使われることが多いので、大変わかりにくいです。
これらをカタカナにして表記しておくと、一見しただけではどちらの意味かつかめず、暴走してトラブルにつながることがあり得ます。直接的に大きなトラブルにつながることはないかもしれません。しかし、例えば、Linuxに対して「Routeの設定を変更」というような曖昧な指示が出た場合「Rootの設定を変更」と勘違いして暴走してしまったら大変です。
「そういえばRootのパスワードを変えるかも？みたいな話が出ていたなあ」といった偶然が重なってしまったら、ある日突然root権限のパスワードが変更されていて、パニックが起きるかもしれません。
ネットワーク機器の話をしているときは、スタンバイという言葉の雑な使い方も、個人的には気になっています。
HSRPにおいてはstandbyという文法で設定を行いますが、HSRPというプロトコルは同様にスタンバイルータを構築するためのものです。
会話の中で、「スタンバイの設定」という言葉が出てきた場合、「HSRPの設定を行う」のか、「スタンバイ側機器の設定を行う」のかが、わかりにくくなってしまいます。
ハインリッヒの法則によると、大きなトラブルは軽微なトラブルの積み重ねによって起こるとされています。曖昧なまま確認しなかったことで、自分がトラブルを起こしてしまうことはできれば避けていくほうがいいでしょう。
ですので、私は「カタカナ表記＝依頼者の中で定義が曖昧＝注意」と自分の中でリンクして考えることにしています。カタカナ満載の資料が届いた時には、必ずカタカナ語の意味を確認することにしています。
その際、最も重要なのは、「依頼者側は専門家ではないため、しっかりと用語定義ができている必要はない」ということだと思います。用語の履き違え、意味の取り違えがあった場合、悪いのは確認しなかった専門家側にあるということだと思うのです。
