図解の本質はここにあった
ITエンジニアにも必要な国語力

第1回　名前にとことんこだわるべし

開米瑞浩（アイデアクラフト）
2005/8/10

コミュニケーションスキルの土台となる図解言語。だが筆者によると、実はその裏に隠れた読解力、国語力こそがITエンジニアにとって重要なのだという。ITエンジニアに必須の国語力とはどのようなものだろうか。それを身に付けるにはどうしたらいいのか。毎回、ITエンジニアに身近な例を挙げて解説する。

　「Can you speak English?」と聞かれてあたふたしてしまう日本人も、「あなたは日本語が話せますか？」と聞かれたら「いいえ」と答えることはないだろう。しかし、「日本語が話せる」といっても、日常会話レベルの日本語力とエンジニアリングに必要な日本語力とでは次元が違う。ITエンジニアに必要な国語力をあらためて見直そう。

■ITエンジニアにこそ国語の力が必要

　一見ITエンジニアとは関係なさそうな話から始めるが、現在の文部科学大臣、中山成彬氏が今年の1月18日に次のような発言をして、教育界で大きな話題になったことがある。

　「教育では、国語、数学などの基本的な教科をいかに確保するかが大事だ。私は国語と数学にもっと力を注ぐべきで、特に国語の力がすべてだと思っている」

　この発言、もちろん中山文科相は小中学生を念頭に置いていったものだ。しかし私はITエンジニア諸氏にこそ聞いてほしいと思い、新連載をここから書き始めることにした。「国語の力がすべて」という発言は、ITエンジニアにこそ当てはまるといっても過言ではないのである。

　思えば2年前から私は、図解力を磨くための教育研修事業を行ってきた。その経験から分かったのは、図解がうまくできないというのも、実は読解力の問題、国語力の問題だったということである。

図1　図解には読解力が必要

　人が何かものを書くときには、図1の（a）のように、まず初めに考えがあって、それを文章として書くという順序を踏む。「考え」の段階では人の脳内のものだから目に見えないが、（a）を経て文章になると、それが目に見えるようになる。

　それに対して図解という作業では、まず文章からその背後にある考えを読み取る＝（1）読解。次にその考えを（2）整理する。そうしてより整理され進歩した考えを（3）図解する、という順序になる。

　この（1）から（3）の工程の中で、（1）の読解の段階からすでにうまくいかないというケースが非常に多かった。「図解ができない」のはなぜだろうと原因を探ってみたら、それは国語力の問題だったのである。

　国語力といっても、漢字をたくさん書けるとか、敬語を正しく使えるとかいう種類の国語力ではない。まして、古文漢文を読み下す能力が必要なわけではない。ここでいう国語力とは、情報伝達文としての日本語を駆使する能力のことであり、その種の能力は実は学校では教えられてこなかった。そのため、自分で意識的に鍛える必要に迫られているのである。

■安易に名前を付けてはいけない

　そこで、国語力を鍛えるための手段として、まずは「名前」にとことんこだわることをお勧めする。もちろん子どもやペットの名前のことではない。開発するシステムの機能やクラス、データ項目、要件などの名前である。

　ITエンジニアの仕事では、その種の概念を細かく整理し、名前を付ける機会が非常に多い。しかし私の見るところ、この名付けがいまいちいいかげんに行われているように思える。適当に思いついた名前を使うのではなく、どんな場合でも候補を10個ぐらい考えて、その中から執念深く「この名前でなければならない」という理由を考えて選ぶようにするといい。

■2つの「正常動作通知機能」

　例えば以下のような場合、あなたは何と名前を付けるだろうか。

AサーバはBサーバに対して、デフォルトの設定では60秒に1回信号を送る。この信号はAサーバが正常に稼働していることをBサーバに知らせるものである。Bサーバはこの信号が途絶えたときには、何らかの異常がAサーバに発生したと見なして警報を出す。このとき Aサーバ側の機能（60秒に1回信号を送る）を「（ネームA）機能」 Bサーバ側の機能（Aサーバからの信号が途絶えたときに警報を出す）を「（ネームB）機能」 と呼ぶことにする。

　まずネームAから考えるとしよう。ネームAについて、次のような名前は適切だろうか。

　正常動作通知機能

　これは私がITエンジニア向けの研修でこの問題を出したときに、実際によく出た解答だった。間違いとはいえないが、満足するには少々問題がある。というのは、この名前だと「60秒に1回、正常稼働信号を送り続ける」という継続性を表現できていないためだ。

　例えば、

・Aサーバは電源投入後に1度自己診断を行い、正常であれば正常稼働を示す信号をBサーバに1度送る

という機能があったとしたらどうだろう（図2の右）。この機能に「正常動作通知機能」という名前を付けてもまったく問題ない。つまりこの名前の意味する機能の範囲は、図2の左と右どちらのケースにも使えるほど広く、その分あいまいなのである。

図2　Aサーバからの正常稼働信号

　シャープなネーミングをするためには、それではいけない。できる限り意味の範囲を狭く限定しなければならない。そこで「60秒に1回送り続ける」という継続性を表現する手段を何か考えよう。

　例えばこんな案がある。

　KeepAlive通知機能

　KeepAliveというのはIT業界でこの種の働きを表すためによく使われる名前で、こちらの方が良い。理由は「Keep」という語感にある。「Keep」という単語は、「ある状態が時間軸に沿って持続する」という印象を与えるため、1回限りの場合にも使える「正常動作通知」という名前よりも適切なのである。

■どんな「警報発令機能」なのか

　次にネームBの方はどうだろう。ネームBについて

　警報発令機能

といった名前は適切だろうか。これも間違いとはいえないがやはり不満なネーミングといえる。

　この名前の問題は、「どんな条件で警報が出るのか」を表現していないことである。単なる「警報発令」では、何か人に注意を促してくれるんだなということは分かるが、何についての注意なのかはまったく分からない。Aサーバの異常を知らせる警報だということが表現されていないのである。

　そこでその意味を書き足して

　Aサーバ異常警報発令機能

としたとしよう。これなら少しましになるが、やはりまだ問題がある。「Aサーバ異常」といえば、例えば「Aサーバがディスク容量不足でもう書けません」といったものも含まれるような気がする。しかし実際には「Aサーバからの正常稼働信号が途絶したとき」に警報を出すのである。それ以外の条件については何も書かれていない。そのことを厳密に表すなら

　Aサーバ通信途絶警報発令機能

という手がある。これで意味がかなり明確になってきた。

　さらにもう少し簡潔に書くならこんな方法もあるだろう。

　KeepAlive監視機能

　これはAサーバの「KeepAlive通知機能」とペアになるネーミングである。「通知」と「監視」でこの両者がペアになっていることは自然に分かる。これならAサーバのKeepAliveをBサーバが監視していることを表現できる。「監視」は通常、何か変化が起きたときには適切な対応を取る、という行動を伴うものなので、異常が起きたときに警報を出す、というニュアンスまでこのひと言で伝えることができるのだ。

■「起動停止」は起動の停止？

　もう2つ例を挙げておこう。

　あるシステムの運用作業項目一覧表の一部に次のような記載があったとする。このネーミングは適切だろうか。

作業項目	作業内容
ハードウェア導入	必要なハードウェアの搬入および設置
サーバ起動停止	決められた条件に従ってサーバの起動や停止をする

　「ハードウェア導入」と「サーバ起動停止」というこの2つの名前はどちらも間違いとはいえない。だが、「導入」や「起動停止」という文字だけを見たときに受ける印象と、実際に行われる作業内容との間には若干のずれがある。この「若干のずれ」こそ多くの誤解の原因になるものなので、こうした細かなネーミングに気を使ってほしいのだ。

　まず「ハードウェア導入」の方だが、単に「導入」と聞くと、必要なハードウェアの選定・発注、あるいはその計画立案といった前準備まで含むような印象を与える。しかし実際に行うのは「搬入および設置」といういわば肉体労働である。であれば、例えば「ハードウェア搬入・設置」というベタなネーミングのほうが誤解は少ない。

　そして一見その「ベタなネーミング」をしているように思えるのが次の項目だ。「サーバ起動停止」という項目名だが、これには何か問題はないだろうか。

　実は問題は「停止」という単語の意味にある。

　例えばこれが「搬入設置」だったら問題はない。搬入して設置する、という意味以外に受け取りようがないので大丈夫だ。しかし「起動停止」は、「起動を停止する」という意味にも読めるのである。何かの条件の下で起動を停止する場合をいっているのかな、とも思えるわけだが、実際には「起動や停止をする」で、起動と停止はまったく別の作業なのだ。要するに起動と停止の2語をつなげてしまうと問題が起こるのである。

　だから、つなげなければいい。例えば「サーバ起動・停止」のように中黒を1つ入れるだけで「起動停止」の印象はなくなる。たかが中黒、されど中黒である。点1つといえどもばかにしないで注意深く駆使するようにしたいものだ。

■「名前」にとことんこだわろう

　以上、一見正しい名前のようでも誤解を招く例を通じて、適切な名前を付けることの重要さをご理解いただけただろうか。もしこの話が重箱の隅をつついているように思えたとしたら、あなたの書く仕様書にはこの種の「微妙に不満のある名前」が頻出している可能性があるので気を付けてほしい。多くのITエンジニアの名前に対する執念はまだまだ甘い。一見何の問題もないような名前でも、厳密に意味を考えると不満が見つかるケースは非常に多い。

　名前にとことんこだわること、それがITエンジニアの国語力向上の第一歩なのである。

＜参考＞ 8月末に出版される私の2冊目の本『90分で学べるSEの思考術』（日経BP社刊）でも、「ネーミング」という一節をもうけて今回の「名前にとことんこだわるべし」に関連する話題を取り上げています。ぜひ参考にしてください。

編集部からのお知らせ

来る9月30日（土）、オフラインイベント「＠IT自分戦略研究所 MIX」を開催します。本連載の筆者である開米瑞浩さんも出演。皆さまのご参加をお待ちしています！