あるソフトウェア開発の現場でのお話である。
定義に拘る人がいる。
会議の途中で「ちょっと待った。この用語の定義はどういう意味なん だ？」と質問する。早く本題に入ってさっさと案件を片づけたいのに、 「まず××の定義から始めることが必要だ」と言い出す。もうさんざん 議論してそろそろ何かしらの結論を出したい時に、「でも○○の定義が できていない。これではだめだ」などと言い出してみんなをうんざりさ せる。
われわれはさんざん議論したつもりだったのに、その人にとってはぜ んぜん議論になっていなかったらしい。
その人がその場に初めて現れた人ならば、まぁ、仕方ないから許そう （プロジェクトがけっこう進行してから「初めて顔を出す」のは止めて 欲しいものだが）。驚くのは、すでにそのプロジェクト関係の打ち合わ せには何度か顔を出しており、討議されている問題についても知ってい る筈の人がそういうことを言い出す。それもたいがい、話がもつれかかっ たり雲行きが怪しくなったりした時に。それこそ、今までこのヒトは用 語の定義というものをどう考えていたのだろう？
定義を疎かにセヨ、などというつもりはない。定義は大切だ。プロジェ
クトの最初期においては何よりも大事だ。定義をろくに定めずになんと
なく判ったつもりになって走り出して、後になって全員が違った概念を
心に抱いていることが明るみに出て火を噴いたプロジェクトのなんと多
いことか。
しかし重要なのは適切な時期に適切な種類と適切な量・質の定義を適
切に定めることなのであって、このいずれかを踏み外した途端、定義
（すること）は逆に重荷になる。
それに走り出してから定義に拘るというのはどう見ても順序を間違え ているか思い違いをしている。もちろん、走り出した後になって重要な ことが未定義のままだったということはあり得る。そのときに定義を与 えるために速度を落としたり停まったりすることが必要なこともある。 しかし多くの場合、そんなときに大切なのはいまさら定義に拘ることで はなく、速度を落とさずに走り続けること、速度を落とさないようにほ どほどの定義をすることだ。そしてことばの定義が問題になるような場 合の殆どは、ここで停まったらプロジェクトが死ぬ、という場合なのだ。
といったことは理屈ではなくて経験則なのだが、それでもこーゆーこ とを知らないか、軽視している（としか思えない）人のなんと多いこと か。プロジェクトがごうごうと、がうがうと火を吐き燃え盛っていると ころで、またそうでなくとも小さな火種が机や椅子やコンピューターや 要求仕様書の下で出番を窺っている明らかな兆候を前にして、「いやこ の用語の定義が」などとやらかす。それをしている間に潜んでいた炎は ぼっと噴き出し、真っ赤な炎の舌をちろちろ動かし、これまで構築した かに見えたものはみな火が回って燃え落ち、メンバー全員焼け焦げて死 ぬ。
困ったことにプロジェクトの当事者（である筈の、であるべき）人間 にこの手の性癖の持ち主がいる。
意味に拘る人もいる。
「この語はしかじかの意味であるから、かくかくに使うのはおかしい」 「この語はうにうにという意味だから、ふにふにという文脈では使えな い」とやらかす。これは〈意味硬直病〉といって、転義とかあやとかを 一切認めない病である。
ある文書のあるレビューでレビュアーの一人が「『下記のとおり』と あるが、これはおかしい。『下記』とは後に出て来る『記』で始まる部 分と照応させるものなのに、その『記』がない」と言い出した。ぼくは 驚いて飛んで帰り、日本語辞典を調べてみた。ほっとした。さすがに日 本語辞典にはそんな莫迦なことは書いてない。その辞書を本人に突きつ けてやりたかったが止めた。お客さんだったのだ（哀）。
気持は判らないでもない。いや、判るかな？ 判らないな。
「この語の意味はしかじかである」というとき、その根拠となってい るのは、「だって辞書にそう書いてあるもん」だろう。この論法（「辞 書に書いてあるからこういう意味なんだ」）は強力に見えるけれど、大 事な点を見逃している。辞書というのはさまざまな語法用法から抽出さ れ同定された意味を載せているだけだ。いわばことばの〈死んだ意味〉 を載せているのであって、生きていることばというのは、日日使われ、 使われるたびに微妙な意味の揺らぎを生じている（それはそうだろう、 使われる対象も違えば使われる状況も違うし、使う人間も違うのだから）。 言ってみれば使うたびに転義が生じている。それらを集めて最大公約数 を抽出したのが辞書なのに、「辞書に乗っている意味と違う」といって 現場での〈意味〉を否定するのは本末転倒だ。
使うたびに転義が生ずるからといって辞書（に載っているような誰も が認めるような意味）を無視した使い方をしたり、ぶっ飛んだ比喩に使っ てみせたりするのは論外だけれど（文芸作品を書いているんじゃないか らね）、辞書にがちがちに従うのも考えものだ。というか、周囲の人間 が迷惑する。
こういう人には普通の意味での想像力が欠如しているのではないかと 思ったりもする。
これらと似通っている、というか重なるのが、〈厳密病〉。「『デー タベースをロールバックする』という言い方はおかしい。ロールバック するのはトランザクションだ」とおっしゃる。
データベースということばを聞いたことのない人はいないと思うが、 現在のフツウの意味は、「データを安全に保管し、必要に応じて容易に 取り出すことができる貯蔵庫」といったものだ。
データベース自体は「貯蔵庫」を指すだけで、それを取り扱う仕組みを 包含したソフトウェアシステムは「データベース管理システム（DBMS）」 といいます。が、普通は区別されません。少なくとも日本語では。厳密 な使い分けをしていないのですね（苦笑）。アプリケーションとは独立 なシステムとなっていて、データを調べたり登録するのにSQLという独 特の言語を用いるのが一般的です。
ところでこれ、原義としては単に「データを整理して保管しておく場所」 程度の意味とぼくは解しています（もちろん実際の用例をもとにそう解 釈しています）。「整理」にはこの場合「データの形式が定められてい る」とか、従って「個個の項目へのアクセスが容易」といったことも含 みますが、ともかくSQL文で問い合わせるものだけがデータベースでは ありませんし、DBMSがなければデータベースじゃないというものでもあ りません。
変な操作をしてデータが壊れることのないよう、ひと続きの作業（こ れをトランザクションといいます）が一段落すると〈コミット〉、途中 でちゃらにするときには〈ロールバック〉ということをする。コミット されるまでデータベース本体には影響しないようになっているのだ。
というわけで、上の言い分は正しい。正しいのだが、「データベース をロールバックする」という言い方が間違っているかというと、そうと も言い切れないだろう。トランザクションが影響を及ぼす先はデータベー スなので、データベースをコミットすると言ったっていいとぼくは思う し、誤解の生じない限りトランザクションとデータベースを同 一視してもいいではないか、と言ったっていい。あるいはここでの〈デー タベース〉は換喩的に使われている、と見ることもできる。ぼくの考え では、「何についてどんなことを言っているのか、関係者の間で紛れが ない限り、そういうアバウトな語法は許される」だ。その程度の正確さ で充分な時にはその程度の正確さでよいのだ。
「データベースをロールバックするのはおかしい。ロールバックする のはトランザクションだ」という言い分を見ると、「『部屋の電気を消 せ』というのはおかしい。正しくは『部屋の電灯の電気を消せ』だ」な どと言い出す人を思い浮かべてしまう。落語の登場人物という感じ。
プログラムデザインにおける厳密さと要件定義における厳密さは粒度 が異なる。要件定義では概念として対象を正確に捉えることが重要なの で、ロールバックでいうならたとえば「いつ、どうなったらロールバッ クするか」といったことで、対象を「データベース（誤答）」といおう が「トランザクション（正解）」といおうが大きな問題にはならない筈 だ。望ましいのは「適切なときに適切な厳密さ」なのです。
ほんとうに厳密に言いたいなら『電灯の電気を』も間違いで、正しく は『電灯に通じている電流を断つ』などとしなければおかしい。厳密さ にこだわるのもけっこうだけれど、そういう人の求める〈厳密さ〉はし ばしば自分に都合がよかったり自分が納得する程度のものでしかない。 だいたい、「日常生活的な厳密さ」と「科学的な厳密さ」は自ずと分解 能が異なる。「厳密であればあるほどいいんだ〜」と叫んで日常生活水 準の厳密さから逸脱してばかりいると、病院に連れて行かれることだっ てあるだろう。少なくとも自分の趣味を人に向かって振り回すのは止め てもらいたいものだ。いやいや、ビョーキなんだから、こんな言い方を しては気の毒ですね。
定義病、意味硬直、厳密病は同じ人に同時に発症することが多い。特 にデザインレビューの場で発症することが多いようである。デザインレ ビューといういささか特殊な場が誘発するのか、普段からそうなのだけ どそういう場だから目立つということなのかは不明だ。
こういう振舞いは、プロジェクトの最初、あるいはプロジェクトが始 まる前の企画とか要件定義とかの場でなら有意義だし、必要だ。ぼくも その時期なら気の済むまで煮詰める。
ソフトウェアは言ってみれば概念構造物だ。それもかなり複雑な構造 物だ。これは残念ながらハードウェアのように目に見えるわけではない し、模型を作って感じをつかむわけにも行かない（適切なモデルを持つ ことは大切だけれど、そのモデル自身が概念だから、やはり目には見え ない）。対象システムにはどんな概念が潜んでいるのか、それらをどの ような方針で扱いシステム化するのか、どのような方針で実装するのか、 予めきちんとできる限り見通しておかなければ、デザインや実装で必ず 行き詰まる。
この〈概念〉という輩は今のところコトバでつかまえるしかない。そ
れで、用語の定義とか概念の定式化という作業を行なう。この作業を通
してオバケをつかまて檻の中に入れておくのである。いつかは逃げ出し
てしまう危険もないとはいわないけれど、ひとまず一度でも檻に入れた
という安心感は何ものにも替え難い。それに、関係者の間に用語に対す
る共通理解が形成されるし、うまくすれば共通の概念を共有することも
できる。（いや、うまくしなければイカンのですが）
だから用語の定義はとても大切なのだ。プロジェクトが動き出す前
（あるいは初期）に、用語の定義が曖昧だったりまったく未定義だった
りすることに気づかないとしたら、のちのち火を噴いても文句は言えな
い。中級以上のプログラマーのみなさんは、そんな状態に気づいたらす
ぐ大きな声で注意を促すべきだ。初級プログラマーのみなさんも、自分
の作業で「何かヘンだな？」と思ったら鵜呑みにしないで、先輩にしつ
こく訊きましょう(^^)
しかし、それはプロジェクトを明確にするために行なうのであって、 用語の定義自体が目的ではないことは忘れてはなるまい。今日中にこの 文書を片づけなければ全体のスケジュールが大きく狂う、といったよう な状況で、「いや定義が」「このことばの意味はこうなので」「厳密に は違う」なんてことで貴重な時間を潰す人は、何か別のものを捕まえて しまっているか、あるいは逆にとらわれてしまっているのかなと思う。
ある本によると「こだわり（こだわる）」というのは昔は「どうでも
いい（または因われてはならない）ことを気にする」といったよくない
意味で使われていたそうだ。手持ちの辞書にも(^^)最近
の用法を「ごく新しい」と書いてある。
ここで触れたような「病気」たちは、ことばの本来の意味での「こだ わり」といっていいだろう。お偉い人の中にこういう人が混じっている と、ホント困ります。
（おわり ―― 2001.02.12）