略語に対する違和感から考えるマネジメント・ハザード

ひとつは「ワイヤー」、そして「ジャバスク」。もうひとつ「マシン」。

これらの言葉が（私がかかわった状況で）何を指していたかというと、

ワイヤー＝基本設計
ジャバスク＝JavaScript
マシン＝コンピュータのハードウェア

ということになるわけですが、いつもいつも何か違和感を感じていました。違和感についてちょっと詳しく書いてみます。

「ワイヤー」は「ワイヤフレーム（透視図）」を略したものだと思います。ソフトウェア自体の設計に透視図もなにもあったものではないというのはさておき、枠組みだけでも表現したもの、というような意味合いでこの言葉を使ったのであろうとは推測できます。ただ、「ワイヤー」では何のことやらさっぱり分からない。ジャーゴンでもスラングでもなく、ただの符牒といったところでしょうかね。

「ジャバスク」は個人的には何かとても嫌な感じがします。ナントカスクリプトをナントカスクと略すやり方を他に知らないというのもありますし、対象を代表する名前をさらに省略されては意味が欠けてしまうような印象があるためです。たぶんこの略記は「スクリプト」を発音しにくいと感じた人が言い出したことなんではないかと思ってみたりしますが。ジャバスクリプトという言葉には破裂音が二つもありますし。これはやっぱりジャバスクリプト、と発声してほしいところです。

「マシン」については、まさにリアルな「動く機械（からくり）」がそれであると私が感じていたため、違和感を抱いたものです。また「麻疹」という比較的身近な同音異義語もあります。コンピュータの場合はマシンというにふさわしい稼動部分はファンであったりモータであるわけですが、そこはそもそもコンピュータの要ではないということが、違和感の正体だと思います。コンピュータを「マシン」と呼ぶには概念の拡張が必要で、情報処理を行う部分も機械とみなし、マシンと呼ぶ、としないと違和感が消えませんでした。

そういえば「ＤＯＳ」はどう呼ぶのかというのを思い出しました。見たときからドスと呼んでいたわけですが、「ドスは短刀を想像するから変だ。ディーオーエスだろう？」と友人から突込みが入ったのは20年以上前。でも普通にドスで通じますよね？いまだとディスクオペレーティングシステムとサービス拒否攻撃の二つの意味がかぶりますがそこは文脈依存で聞き取るとして。あえてドスを避けるなら「ディスクオーエス」かな。

このようなことを書いているのは、どれが正しい呼び方か、ということを示したいわけではありません。しかしどれが正しい呼び方かなんてのはどうでもいいというわけでもありません（そういう場合は言外に「話をしたくない」と言っていることが多い。すべてがそうではないけれど）。

何を示したいのかというと、「今現在の自分が保持している意味解釈を行う仕組みが作り出す感覚」が形成する場の中でのみの判断として「わかった」とか「わからない」とか「心地よい」とか「心地よくない」などと言える、ということです。つまり意見を言うということは自分の意味の場を全てではないにせよ、さらけ出しているのと同じということ。もうひとつ、「意味解釈システム」に変化を加えれば出てくる感覚そのものが変化する可能性があるということ。

それが何を意味するかというとまさしく「人の言葉はあてにならない」。かといって話半分で聞いていていい、というわけでもないのですが、「言質を取った」といってその先の行動を縛るという日常的によく使われる行動が大変奇妙なものだということです。他人の意味解釈システムが固定であることを要求するというのは養老孟司さんの言葉を借りれば「情報として扱おうとしている」ということです。そのようにしたら「人が何を考えているか分からない」といって悩むようなことになるのは当然のことで、一方「人が何を考えているか分からない」のはとりあえず当たり前だと認識してそれを前提とし、それを元にさてこちらはどう行動するかね、と決めるのは似たようであってもまったく違うものになってきます。

さて前置きが長くなりましたが、ここでホームグラウンドのソフトウェア開発の話に戻ります。

オブジェクト指向で物を作るとき、オブジェクトの中身はどうあれインタフェースが一定の応答を保証するならそれでよしとする考え方があります。これは言い換えると、「そのオブジェクトを実際に使わずともその他の状況から判断してそのオブジェクトの振る舞いを確実に予言できる」ことを意味します。もっと言えば、そのようにコードを書けば、書けるように努力すれば、それだけでソフトウェアの品質は上がります。（ここで言う「品質」は「予想もしない動作をしない」という意味です。）しかし、多くのプロジェクトではこれを人の振る舞いを「統制」することで制御しようとしています。決まったパターン、慣れたパターンのなかで思考することで補助的に振る舞いを予言できるようにしているように見えますが、これでは個人が持つ意味の場がそのパターンの中だけで成長することになり、融通がきかない育ち方をすることになりかねません。

まあ人を情報として扱おうとして取替え可能としようとしているところからすると勝手に成長されては困るということもあるかもしれませんが、人はどうあれ勝手に意味解釈のシステムを更新していくものです。それを無視してこのようなやり方を行うというのは、いずれどこかでそのやり方そのものが役に立たなくなりかねない。これは「マネジメント・ハザード」とでも呼んでも良いんじゃないでしょうか。

プロジェクトで作るのは製品ではなくて人、製品はその副産物、そういう考え方をしたほうが良いと思います。この考え方をしてしまうと、あるプロセスを適用すれば物ができる、というわけじゃないことになってしまうため困る人は困るのですが。