研究過程と成果の電子的な生残

(作成980510)

超重ソフトウェアへの道程

「これをウつとツカレがとれキモチよくなるよ」と 初回は微量にて渡し,徐々に不純物の比率を挙げながら 増量を重ねて深みへと誘い込み金を巻き上げ続け, ついには引き返し不能点まで追い込んで 身をも破滅せしむ, と書けば誰しもこれは怪しげで不埒なヤク物密売人の手管に ついて述べていると考えるだろう. ところで, こんにちの一部の計算機ソフトウェア会社の方法論もまた これと一定の相似関係にある. 本稿ではその傾向と対策について考えてみよう.

1980年代前半から計算機の利用方法が大きく変わりはじめた. すなわち「ワープロ」だの表計算だのデータベースだの 描画・作画だの統計計算だのといった データ処理を「おまかせ」でやらせてしまう ソフトウェアの勃興とその利用者の急増である. 利用者を「プログラミングのくびき」から解き放つ これらソフトウェアは大いに受け入れられ, ハードウェアの販売を拡大し, ハードウェアの普及はソフトウェア会社に新たなる鉱脈を作り出した. 不特定かつ無数に多い利用者を相手にする 非特化汎用型「アプリケイション」ソフトウェア市場の誕生である.

ところで, これら「アプリケイション」ソフトウェアの 種類はまことに多彩ながら, これを開発販売する側から見れば その果たすべき目的はただ一つであったのではないかと疑っている. すなわち 他社の類似製品を駆逐し, 利用者すべてに自社の製品を使わせる. これを実現する手口はどのメイカーも同じだったのではないだろうか. とにかくどんな些細なことでもいいから 「ウチの製品ではあれもできますこれもできます」と いった方向を目指して製品を開発し, その宣伝に努めた. こういった高機能化はホントは利用者の便宜のためではなく, 単に競争相手を打倒するためのものではないかしらん, と私などは邪推しているのである. ともあれ歳月とともに「便利な高機能」の追求に邁進した 「アプリケイション」ソフトウェアたちは果てしなく肥大化した. これにより「動作が遅くなる」「メモリが多量に必要」など 計算資源を際限無く消費するといった弊害はよく知られている. さらに動作が不安定になったりおかしくなったりすることもある.

たとえばMicro$oft 社は上述の 「太り,占めよ,さもなくば滅びる」哲学の 忠実なる実践者である. 同社のWord なるソフトウェアは ヴァージョン改訂ごとに わけのわからない恐竜的「進化」を成し遂げ, その最新版にいたってはコードの行数は 実に200万行を超えているという噂がある. 十数年前にSDI もしくは弾道弾迎撃計画という 軍事プロジェクトが策定されようとしていたときに, これに反対する研究者たちは 「そのようなシステムを管制するプログラムのコードは 100万行を超えてしまうので 誤動作を導くような致命的なバグの混入を避けられない」 と主張していた. 当代においては不特定多数の一般利用者が用いる ソフトウェアが, 一体全体どこの誰がそれを望んだのか謎であるが, その規模に達しようとしている [1]

「便利な」ソフトウェアの陰にひそむ危険

しかしながら,ここではそのような 汎用情報処理を目指した「高機能な」超重ソフトウェアそのものや あるいはそれを利用することの是非について 直接的に論じるつもりはない. 計算機を学術研究に利用している人々にとって もっと切実な問題は多々ある. そのひとつに, 「アプリケイション」ソフトウェアから 生成された出力ファイルの ほとんどは他のソフトウェアで「読む」ことができない, ということがある. すなわち,学術研究の必用条件である 「研究過程とその成果の記録と保存」 を危うくするものである.

PC やMacintosh などを動作プラットフォームとする 「アプリケイション」ソフトウェアたちのほとんどは その出力としてバイナリーファイルを生成する. バイナリーファイルとは何か. ここでは不正確ながら 「人間には『簡単には読めない』すなわちテキストファイルではない」 ファイルとでも定義しておく. バイナリーファイルの多くはそれを生み出したソフトウェアで なければ「開く」(閲覧・再加工) ことあたわぬ 「閉じた」規格である. したがってそのソフトウェアが無くなったり改変されたりすると ファイル内の情報を取り出せなくなる可能性がある. 「アプリケイション」ソフトウェアを仕事に利用した人は 大なり小なりそのような経験があるだろう.

とくに他意はないけれど, Micro$oft 社をふたたび引き合いに出すなら, 同社はその企業哲学の実現にあたって 「よそのバイナリーファイルをウチの形式に変換できれば, よそのお馴染を籠絡できたも同然」なる 方針に基づいて製品を開発しているようである. しかしながら, 資金・人材が潤沢であるはずの同社の「傑出した」 技術力と甚大なる努力をもってしても, バイナリーファイルの変換は容易ならざるわざらしい. なんとならば, 自社製品どうしのバイナリー変換すら満足になされないのである. 同社のWord5 にて作成した数式入り論文を Word6 に変換すると, 奇怪なことにファイルサイズが倍増する. あるいは,Windows のWord で作成したファイルを Macintosh のそれに変換すると, ところどころ情報が欠落する…… この手の話のたねはつきることがない [2]

まず以上の話に恐慌をきたした心配性の読者のために もっとも原始的かつ確実な解決方法をしめす. それは作成したすべての ファイルに含まれる情報を細大漏らさず 紙に印刷出力して後生大事に保存しておくのである. で,別のソフトウェアにデータを移すときには, その印刷出力を見ながらキイボードから 逐一再入力すればよろしい. 時間のある人は自分でやればよいし, 金があれば人を雇って入力させればよい…… それでは次に, いま少し電算機らしい解決策を考えてみよう. もちろんこの連作の主題である PC-Unix を用いた「安価で高性能な」やり方である.

電算機世界の「共通語」:テキストファイル

Unix の世界では(機種を問わず) 情報交換の基礎となるのはテキストファイルである. テキストファイルとはテキストエディターやペイジャーを使って 「読める」ファイル形式のことである. このテキストファイルに データもその加工処理をほどこすためのスクリプトも プログラムのソースコードも出力結果も書いてしまう. まさに共通語とでも呼べる形式である. PC やMacintosh でもテキストファイルを作成することはできる. これら非Unix プラットフォームで作成したテキストファイルを Unix 上で利用するためには変換操作が必要である. しかし,上述したバイナリーファイルのそれとはことなり, ほぼ確実に変換可能である [3]

テキストファイルの利用のされ方について 具体的に例を挙げてみよう. 例えば,文章の整形印刷を担う組版プログラムであるTeX では 入力ファイルはテキストファイルである. テキストファイルで複雑な数式もペイジレイアウトも記述している. 印刷出力するときにはいったん 印刷機器非依存のdvi 形式と呼ばれるバイナリーファイルに 変換する. これをレイザープリンターから出力するためには dvi ファイルをpostscript ファイルに変換することが多い. このpostscript は多くの印刷機で利用可能なペイジ記述言語であり, これもテキストファイルとして記述されている.

TeX のように文書の修飾をテキストで明示的に記述する形式を マークアップ言語と呼ぶ. 読者の皆さんが現在読んでおられる文書もHTML と呼ばれる マークアップ言語によって記述されたものであり, もともとのファイルは単なるテキストファイルである.

Unix の世界においては, Tpng やIdraw といったドローソフトウェアの出力も一種のテキスト ファイルとなっており, テキストファイル加工のスクリプトを用いることで, 誰でもそのファイルを変換できる (原理的には……実際にはなかなかしんどいので, 世界のどこかで誰かがすでに作った変換スクリプトを インターネット上で探しまわることになる). 商用ソフトウェアであるMathematica や いくつかのリレイショナルデータベースにおいても 入出力ファイルの基本はやはりテキストファイルである.

データをテキストファイル形式で保存することの利点は 閲覧・再加工・変換の確実性を高めるだけではない. 正規表現を用いた検索によって (そのためのプログラムはUnix では標準で装備されている) いろいろなディレクトリに保存されている 無数のファイルから求めている情報を見つけ出すことができる. またデータを加工するための スクリプトやプログラムのソースコードもまたテキストファイルに 記述されていることはすでにのべたとおりである [4]. これによってプログラムはプラットフォーム間の相違を越えて, どこでもほぼ同じように動作する. こういった正規表現による検索や スクリプト言語やプログラム言語については また機会を改めて解説したい.

目先の便利さか長期的な生残か

本稿で述べたかった「研究過程と成果の電子的な生残」法とは, データもその加工処理方法もすべてテキストファイルで書くのがよい のではないだろうか,ということである. そのためには様々な知識や技術を自らのものとしなければならない. いっぽう「便利さ」を売り物にしている 「アプリケイション」ソフトウェアにおいては そういったわずらわしさ [5] とは無縁である.

どちらを選ぶかは各人の仕事の内容によるのだろう. しかしながら, 誰もが「忙しい」という魔法の呪文を詠唱すれば 何をやってもあるいは何もやらなくても 許されると考えられている当代にあって 超重ソフトウェアが猖獗をきわめるのも けだし自然のことなのかもしれない. かくいう私自身も実は その呪縛からまだ完全には脱けきっていないのである.


脚注

[1] Linux (OS) は30万行ぐらいで収まっているらしい. ただしこちらはすべてのソースコードを全世界に公開しているので, 非常に原始的なレベルで多くの人にチェックされている,と言える. 社内でも秘密主義のはびこっているM$ 社とは品質に大きな違いが あるのではないだろうか.

[2] 最近ではLinux で動くアプリケイションが増えてきた. Applixware の`Office' ではWord の文書なども読めるらしい. 果たしてこれら商用ソフトウェアが良い方向に進むのか, それともわけのわからん恐竜的……

[3] バイナリーファイルであっても 「誰でも読める」公開された規格はある. たとえばビットマップ画像のファイル形式である GIF, JPEG, TIFF などは有名である.

[4] さらにテキストファイルで記述されたスクリプト言語を また別のスクリプト言語に変換するプログラムも存在する. Fortran で書かれたソースコードをC に変換する プログラムすら存在する.

[5] 枕詞的に「わずらわしい」と書いたけれど, スクリプト言語やプログラム言語を習得することは, 実は「楽しい」ことなのである.



戻る