先日 jus（日本 UNIX ユーザ会）のシンポジウムで懇親会の後、 好きな連中が集まって BOF（バード・オブ・フェザー すなわち「同じ穴のムジナ」）と称する会を行なった。 jus も設立当初は T シャツにジーンズというラフなスタイルが多かったのだが、 最近は背広上下という仕事着姿？が過半数を占めるようになった。 しかし BOF ではラフなスタイルがやや多かったような気がしたし、 途中でお茶のかわりにビールが出るところは何とも言えない。
テーマは「ワークステーションとは何ぞや」ということだったが、 ここではワークステーションを大学や企業の研究室で使っている ハッカー達（この言葉にも定義が色々あるが、本来の良い意味でのハッカー） が常日頃の満足、不満足を交えてワークステーションを定義してみよう という趣向で、チェアマンを中心に（もちろんチェアマンもビールのグラスを 傾けながら、、、）色々な意見が交わされた。
あくまでもスピードを追求する人、メモリーの大きさを重要と考える人、 マンマシーンインタフェースを第一と考える人など、ニーズが異なるので 定義は様々のようであった。
まず意見の一致を見たのは、 ワークステーションとは個人の作業環境ということであったが、 それではスタンドアローンのパーソナルコンピュータや ラップトップをワークステーションと呼ぶかとなると、 それでよしとする意見はほとんどなかった。
ただし、これらが回線で他のコンピュータに接続され 端末として動いているなら、 これもワークステーションではないかという意見があり、 TSS もワークステーションかという点について議論が戦わされた。
CPUのスピードを追求する人から、 多数の人間の色々なタスクが走ることにより、 CPUパワーを大きく喰われることを嫌う意見もあったが、 これを解決するにはTSSではなく、 個々のワークステーションが CPUを独占するとともに、 必要な資源についてはネットワークを介して共有する必要がでてくる。
総合してみると、 他人に邪魔されずに仕事ができる「書斎」説、 いや多少は他人の仕事をしている気配を感じることができ、 ちょっとした打ち合わせ程度は気軽にできる「パーティション」説 などがでてきた。
面白いのは誰からも邪魔されたくない一方で、 他人とコミュニケーションがとれなければワークステーションではないということである。 この矛盾をクリアするには、 あるウインドーは他人からのメッセージを受け付けるが、 仕事中のウインドーには邪魔が入らないというような工夫が必要だろう。
私が提言したのは、ワークステーションは 「お利口な秘書つきの書斎」であって欲しいということだった （私は別に美人の、、、とは言わなかったのだが、 何処からか「俺は秘書だけ欲しい」という声が聞こえた）。
書斎で仕事をしている時、電話が入ったり何処かへ連絡しなければならない時 インテリジェントに処理してくれる機能、 必要な書類をそろえてくれたり、 大まかに作った資料からレポートを作成してくれる機能など、 仕事の内容によって色々あろう。
私の本来の仕事、 医療の世界で出てくるのがAIによる自動診断機能、 最近ではエキスパートシステム、コンサルテーションシステムなどである。 いくつかの医科大学で研究が進められているが、 内容を聞いてみると 患者さんから沢山の質問に答えてもらい診断しようとしても、 実際にやってみるとうまくいかない。
理由を尋ねてみると、 患者ごとにインテリジェンスの違いなどがあって、 同じ設問の回答でも異なった解釈が入ってしまう、 あるいはミスタイプなどが紛れ込んで正しい結果が得られないなど、 そのネックとなる部分はAI以前のものであることが多い。
似たようなことはどの分野にも見られることで、 高度なAIを駆使する前に単純なミスをチェックしたり、 労力を省くような点にもっと木目細かく注意を払い 「人間工学的なソフト作り」を行なうことこそ、 これから最も必要なことではないかと思う。
もっとも UNIXの世界ではこのような考えは当たり前のことで、 高級な言語を使用せずシェルを使った単純なものでも、 非常にお利口にできていて舌を巻くことも少なくない。
ここでUNIXのPDS(Public Domain Software)の環境について ちょっとご紹介しよう。
当然のことながらソフトはC言語で書いてある場合が多く、 大きいものが多いので、ソースは無数のCプログラムに分かれていて、 これを一つずつネットワークを介して送るのはかなり面倒であるし、 途中でファイルが一部失われてしまって 使いものにならなかったりする可能性もある。
そこでこれをシェルアーカイブにして送る。 シェルアーカイブとは複数のファイルを繋げて一つにしたもので、 文書を次々と糊付けして長い巻物にしたと考えて頂ければよい。 これをそのまま送ってもよいし、 大きなものは圧縮してカサを小さくして送り、 受け取った方でこれを再び圧縮用のプログラムにかけると、 インスタントラーメンにお湯をかけたように元の姿に戻る。
長い巻物のままではコンパイルできないので、 エディターで一つ一つのファイルに千切ることもできるが、 そんな面倒なことをする必要はない。 シェルアーカイブをシェルで直接走らせると、 巻物の中にシェルコマンドが埋め込まれていて 自動的に一つ一つのファイルを取り出してくれる。
実際にはたった一行のコマンドで梱包をほどけるし、 梱包するのも make などのコマンドを使えば バカチョンでやってくれる。
UNIXネットワークでニュースを読むにはいくつかのツールがあるが、 rn (read news) をインストールするのは初めての人間にとって かなり感激的である。
confituration を命ずると、 画面に「ふむふむ、これは 4.2BSDだな」とか 「結構まともなUNIX使ってるじゃない、、、」とか、 システム内を勝手に走査して独り言をいいながら、 そのシステムにあった状態で rn をコンパイルし、 必要なファイル類を所定のディレクトリへ配置してくれる。
DECのセールスマンから小説家に転じた J.P.ホーガンの作品に 「造物主の掟」というのがある。 資源のある惑星をみつけ着陸した無人探査機が惑星の資源を使って ロボット工場を作り、 それらを使って次々と色々な工場を建設し、 資源を加工しては母星へ転送するというものである。
rn はまさにこれで、 宇宙船ならぬ電話回線を介して到着したパッケージを 一匹システム内に放してやると、 自分で勝手に荷造りを解いて良いように根付いてしまう。
現場で必要なものはAIの前にこのような考え方だと思うが、 rn をインストールするための主な部品はシェルで書いてあるに過ぎない。 「道具」の前に必要なのは「考え方」であろう。