(ある科学者の立場からの、雑談的)コンピュータ利用技術論

【1997年5月27日に、当時所属していた大学の大学院・卒論生のゼミで配ったメモです。まじめな教材を作ろうとしたのですが、もう自分はコンピュータ利用技術を教える能力を失ったのではないかという悩みがまじってこんなものになってしまいました。今(非常勤講師をしていた慶応のサイトで再公開した2003年)となっては固有名詞などが古いところもありますが、状況はあまり変わっていないと思います。わたしの仕事スタイルもGKSをあきらめてGMTを主にした以外はあまり変わっていません。また、うちわ向けの表現があちこちにありますが、公開向けに書きなおす時間がとれそうもないのでごかんべんください。】

1. コンピュータを使うことが目的じゃないよねえ

ゆううつな本屋めぐり

コンピュータ関係の棚面積はふえた。本の数もふえているだろう。
しかし、新しく出る本の大部分は、特定のソフトウェア(エクセル、一太郎、 Netscape...)の使い方解説だ。
「何か仕事をしたいときに、どうコンピュータを使うか」という本が少ない。

なんでマニュアル本ばかりなのだろう

海賊版利用者のマニュアル代わりという理由は昔のことだろう。
正式版でも、マニュアルは簡単なことしか書いてなかったり、辞書みたいなものだったりする。別の観点で機能を整理したものがあると確かに便利だ。 (実際わたしも使うことがある。)
この種の本では、出版業とソフトウェア産業がもちつもたれつの関係になっておたがいに安心できるのだろう。「ある種のソフトウェアは全部役にたたない」なんていう本を書いてしまうと業界から追い出されるのかな。
いろいろなソフトウェアを使い比べるのに必要な投資ができる人は限られているのかもしれない。
限られた製品だけでも、自分はこう活用したという実践記録を書いてほしいんだがなあ。ただ、違った利用目的を持った人にはそのままでは役にたたないだろう。じゅうぶん応用性のある実践記録か、「手に汗握る」文学的センスのある本なら買って損をしたとは思わせないですむと思うのだけど。

考えてる人もいるようだね

雑誌記事にはいい実践記録がときどきある。ただし短すぎてものたりない。
Unix Magazineにはその名も「目的指向の....」という連載があった(山口、坂下、1994)。 Plauger (1993-94)の評論集の原題Programming on Purposeもそんな意味らしい。どちらもコンピュータのプロの文章なのが、ある意味で残念。

ところで、わたしの目的は

世界で起こっていることを、なるべく多様性を失わないで、なるべく簡単に要約・整理すること。
ときどき、それの間の因果関係を知ろうとすること。
ここで世界というのはほんとに世界、つまり地球全部の大気圏・水圏・陸面。時間範囲は地球形成以後全部だけれど、人類出現以後に重点がある。
多様性と簡単さの妥協点は、自分の頭またはコンピュータの中に地球全体の情報が入れられるレベルに置く。
このために必要な道具を総称して macroscope -- 大きなものを小さくして見る道具。

2. わたし、このごろのコンピュータが苦手です

確かに昔(10年前)は得意になってました

東大大型計算機センター相談室に増田あり[き](増田, 1991a)。
データフォーマットの解読、変換は毎度のこと。
NCAR Graphics (パブリックドメイン版) の移植も(先輩から引き継いで)やりました。
大気大循環モデルの1万行のプログラムもいじりました(わたしの手では完成しなかったけれど)
一太郎 ver. 3で時速2千字で文書を作りました(レイアウトまで含めて)。
PC98でアニメーションもやりました(N先生のに比べればめちゃくちゃ遅いですが)

でも時代に負けました

コンピュータのプロがおおぜいかかって情報を生産するから、エキスパートであり続けようとすると、コンピュータ利用技術の自己研修だけでフルタイムになってしまう。地理学の知識の習得も気象学の知識の改訂も進まない。
今は地球科学を優先したいので、コンピュータに関しては「年寄り」を決めこんでいます。

ハードウェアの性能の進歩はすなおに認めよう

CPUの時間あたり演算回数
メモリーの面積あたり収容ビット数
電力消費量あたりの演算能力
日本人の所得の中央値で規格化したコストあたりの演算能力

どんどん複雑になるソフトウェア

機能がふえて覚えきれない、使いきれない、バグがあっても気がつかない
ジャストシステムが典型、今売ってるパソコンで動くものを売ってるけど、古いパソコンを大事にしてる人はカヤの外。
フリーのGNU emacs/muleも例外じゃない。使ってるけどまねしたくない。
適応の目的を失った定向進化--マンモスのキバ? (マンモスに失礼か)
「複雑化のサイクル」(Plauger, 1993-94, 第2巻21章): 単純さで売りだしたはずのUnixが今では....
ソフトウェアではハードウェアと違って、「機能がほしい」という不満にこたえても、かさばらないから生産者側のコスト増加が少ないわけだ。 (ユーザー側には、ディスクスペースを占有しすぎるとか、移しかえるときトラブルが起きやすいという不満はくすぶっているけれど...たとえばPlaugerの2巻14章)
「複雑すぎてわかりにくい」という不満はフィードバックされないらしい。
せめて自分が作るものくらい、単純な構造・機能にしておきたい。

GUI (graphical user interface)は迷惑だ--少なくともわたしにとっては。

グラフィックスは必要だ。でも必要なときだけ出てきてほしい。
画面上の場所を指させばいいのなら確かに直観的だよ、でもなんで机の上でマウスなんだ?
バッチ処理(6節)のできない計算機は計算機じゃない--少なくともわたしにとっては。
たまに使う人にとっては、コマンドを覚えるより便利でしょう。たぶん。

商品サイクルが早すぎる。現代資本主義の症状じゃないだろうか

たった10年前のエキスパートが無力になってしまう世の中なんて、やっぱりおかしくないかなあ。
フリーソフトウェアの場合は説明できないけれど、現代資本主義社会の構造的問題がからんでいるような気がする。　
浪費を作り出す人々(Packard, 1961)の戦略だ。 A社のを買え、B社のを買えという宣伝は再生産されるけれど、手持ちのパソコンを長持ちさせましょうという宣伝をしてももとがとれない。
需要と供給の平衡でうまくいくっていう話は、平衡に達する時間がじゅうぶん短いことが前提なんだ。でも、現代の企業経営は、平衡に達する前のゆらぎを利用して利益をあげよう(そうしないとつぶれるぞ)っていう感じじゃないかな。
よく似た商品どうしで、需要の比に比例して供給量が決まるようなしくみはない。ちょっと有利なほうが大量に供給されてしまうはずだ(証明はまだしていないけれど)
資源と環境の有限性が経済活動に反映されるような政治が必要だ。

3. 石頭計算機を知ってるかい

石頭計算機(安野, 1973)は電子計算機のパロディーです。
フォンノイマン型の計算機の形容として「石頭」はみごとだと思う。材料がシリコンだからじゃないよ。
石頭は、すべてのものごとを(たくさんだが整数個の)0か1かでとらえる。
石頭は、プログラム(これも0と1で書かれている)の命令を(原則として)順に実行する。
つまり、機械語のプログラムは計算機に対する仕事の結果だけではなくて、手順を指定したものだ。
FortranやPascalやCのプログラムも手順立てだ。
LispやPrologやSQLとなるとちょっと違って、結果を指定してあとは計算機に考えさせる。ただし計算機自体は石頭だから、実際に「考えさせる」ためには考える手順を指定した石頭語のプログラム(Lispインタプリタなど)を用意しておくわけだ。

4. 人間はすごいパタン認識機械なんだ

自動画像認識の最先端は、人間の能力から見ればたいしたことない。 (もちろん自動化できれば人間の労働を省けることはいろいろあるが。)
人間のパタン認識能力を最大限に生かすように、計算機に何度でもビット処理をさせるという人間機械結合システムを組むのが今の技術水準のもとでは最適戦略だろう。
だからわたしはデータの可視化(Cleveland 1985)にこだわる。統計処理も数値への要約よりもグラフのほうがだいじだと思う。

5. 期待される人間像たち

1種類の人ばかりじゃつまらない

大きな仕事なら、適材適所で分業
独立研究者の集まりでも、得意な面で助け合い

どんな役まわりがあるか

企画家
データマネジャー (何を集めるか、何を集めないかを決める人: 増田, 1995a)
ビット職人、グラフィックス職人
システム管理者、ネットワーク管理者
事務職員(業務情報管理者)、人間管理者

6. ビット職人が寝てる間に計算機は働く

見ている間では終わらない

数値実験は欲を出せばきりがない
データ加工も同類のデータがたくさんあれば定型作業になる
他人のぶんまで計算を引き受ける立場なら効率化しなければ立ち行かない

道具立て

仕事の手順をプログラムする: マクロコマンド、Unixならシェルスクリプト (砂原ほか, 1996)
バックグラウンドにまわす (端末画面をあける)
バッチジョブ: 列にならんだバックグラウンドジョブ。ロードレベラー(IBM)やNQS(フリー)はジョブの管理をするソフトウェア。　
手順が定まるまでは対話型、完成したらバックグラウンドへ。使うプログラムは標準入出力を端末からファイルに変更できるように作っておく。シェルスクリプトの定石はsh系なのだが(Peekほか, 1993)、わたしはあえてcsh系で組む。　
ファイル名一覧をawkで加工して、使い捨てシェルスクリプトを作る手もある。

7. うるさい言語と気楽な言語

手順立て型言語の構造化とモジュール化

手順の構造化(制御構造): 手順立て言語のプログラムは次の3つの構文で書ける。
- 順次処理
- 条件判断 (if ... then)
- 繰り返し (do while ...)
構造をもった変数を定義できること
手続きの部品化(サブルーチン化)
部品内の変数などを外部から見えなくすること(カプセル化)
変数などとそれを共有する手続きをまとめること(パッケージ化)

(Fortranユーザーのわたしが実践しているのは1と3)

昔のBasicで大きいプログラムをデバッグする悪夢

(実例はN88 Basic、「大きい」は1000行程度)
サブルーチンは書けるが変数が全部グローバル
変数は宣言しなくてよいので、書きまちがえてもなかなか気がつかない
制御構造の構文がうまくできてないので「go to」文を避けられない

大きいプログラムを書くにはうるさい言語を

Wirth先生の言語(Pascal, Modula 2, Oberon)は正しいプログラムを書くまで許してくれないのでこの点ではいい。ただしあまり大きいプログラム (何万行もあるもの)は書けないと思う。
FortranならIMPLICIT NONEで変数の宣言を必須にする
Cなら必ずプロトタイプ宣言

急いでプログラムを書くには気楽な言語を

けっして大きいプログラムにしないこと (100行程度までが適当。大きくなりそうなら中間結果を書き出すことにして複数のプログラムに分けるのがよい。)
テキストファイルのフィルター型処理ならawk
もう少し一般的処理ならPerlかな?
Basicもいいでしょう。ただしわたしはこのごろのBasicを知りません。

8. 無念、長いものに巻かれろでUnix

業界標準が必要だ

なるべくなら、論理的な筋が通っていて、しかも人間工学的に使いやすいのがいい
でも、使っている人が少ないのでは使い方の知識が蓄積されないから便利にならない。
標準を決めるまではなるべくいい標準になるように努力し、決めたら妥協するのが現実的態度だろう。

でも、どっかの会社と心中したくない

Windowsを作っているのはマイクロソフトだけ(IBMのOS/2があるが)。 MacOSはもちろんAppleだけ。
VMSはがんじょうでいいのだけれど、作っているのはDECだけ
DOSは複数のところで作っているようだけれど、さすがにシングルタスクでは能力不足
いわゆる汎用機OSは明らかに落ち目
Unix系のものなら、LinuxやFreeBSDなどソースプログラム公開のものもあるから、どの会社がつぶれてもそれだけで消滅することはない。

いわゆる汎用機OSユーザーから見た、Unixの困ったところ

1文字1文字が貴重。1文字まちがえるととんでもない動作。 (情報伝達では、冗長度というのは安全度でもあるんです)
消したファイルは帰ってこない。
マルチユーザーなのに、読み書き権限を細かく指定できない。 (あけっぴろげ文化の産物だから)
管理者権限の一部を譲ることがむずかしい。だから管理者に雑用が集中する。高いモラルも要求される。
設定ファイルの書き方がソフトウェアによってそれぞれくせがあり、直感的でない。
コマンド名が短くて連想がききにくい。

Unixのいいところ

ファイル形式がすっきりしている (レコード長などを意識しなくていい)。
標準入出力の扱い(<, >, |)が一貫している。これに支えられたパイプライン処理の文化がある。
たいていのソフトウェアの設定ファイルがテキストファイルになっている。わたしにとっては、特定のプログラムからしか読めないもの(Windows95のレジストリ) よりいい。(悪いという立場--カプセル化の論理--もわかるけれど)

複雑さへの不満

Multicsに対抗して単純さで売りだしたはずなのに、 Bell研流にもバークレー流にも使えるように機能追加してしまったので、けっこう複雑。 (利用者はどっちかを知っていればいいのだが、管理者になると両方のトラブルに対応する必要が出てくることがある。)
特に、個人で使う場合、マルチユーザー機能は必要ない。だれかシングルユーザー向けのマルチタスクがしっかりしたOS (OS/2 ひく Windows たす X Windowみたいなもの)を作ってくれないかなあ。

9. グラフィックス職人の道具箱

性能よりも移植性

学生は卒業する。大学教員はいつ転勤してもふしぎではない。
グラフィックス装置の寿命は長くない。
地球環境データは人類の共有物だ。それを見るプログラムも共有にしたほうがいい。
装置ごとにプログラムを書くだけの人間時間の余裕はない。

部品型、フィルター型、会話型

[部品型]部品の道具箱(Fortran流に言えばサブルーチンライブラリ)を用意する。メインプログラムは自分で書く。--わたしはこれがふつうです。
[フィルター型]データを入れると図形が出てくるプログラムを用意する。
--見ばえはともかく急いでデータを見てみたいとき使うことがあります。
[会話型]プログラムと会話しながら図形を作っていく。 --「お絵かき」では必要ですね。わたしはこれが苦手です。

GMT(Wessel and Smith, 1991)は作りとしてはフィルター型なのですが、使い方から見ると部品型に近いと思います。
gnuplotはUnixのフィルターではないけれど、わたしはフィルター型に含めて考えています。

はやらないけれどGKS

特定機種依存でない部品の規格。
UnixでもDOSでも使えるもの。
FortranでもCでも使えるもの。
2次元図形表示に限っておく。3次元は見送る(覚えきれない)。
ベクター図形中心(ラスターでない)。ただし線だけでなく塗りわけは必要。
図の大きさの縮小拡大が簡単にできること。
業界標準というほどではなくても、複数のソフトウェアメーカーが使っている。
しっかりした規格書がある。教科書(鈴木, 1991)も出ている。
(これから選ぶとしたら、DOSでは使えないと思うけれど3次元のOpenGLかな?)

もっと高度な道具を整備したいんだけど...

地図をかく、地図の上に数値を表示する、等値線をかく...
- GKS上に教材として整備しているが(増田, 1995b)、自分の研究の実用にも追いつかない。
- 「地球流体電脳倶楽部」(林, 1995)に参加したほうがよかったか?
ベクターとラスターを共存させる、相互変換する (増田, 1988)
散布図方陣とその上でのデータ群の選択表示(Cleveland, 1985)を空間座標も含めた多変数でやりたい。
データのデバッグのための効率のよい可視化

10. データの流れが仕事の流れ

古典的フローチャートは不要なチャート

制御の構造化、サブルーチン化をしていれば、プログラムの制御の流れはプログラム自体を見ればわかるはず。
書くべきなのは、データの流れの図。
制御の流れを組む上でも、データの流れを先に考えるのがいい方法 (Plauger, 1巻11章ほか)

外部データで仕事をつなごう

プログラムを他人と合作するのは楽ではない。
UnixやDOS上のファイルとしてデータを引き渡すことにして、データの形式についてていねいに取り決めておけば、それぞれ自由にプログラムを書くことができる。標準入出力を使ってもいい。
部品(サブルーチン)ごとに分担する場合は、引き渡す変数についてしっかり取り決める。引き渡さない変数は相手側のプログラムでは操作できないようにしておく。

11. 大学はいつも試作工房

プロのプログラムとアマチュアのプログラム

プログラムだけでは売り物にならない。マニュアルもサンプルデータも必要。
プログラム、プログラム製品、プログラムシステム製品で必要な労力は1:3:9 (Brooks, 1995)。
プログラマとして就職する人は、学生の場合とは品質基準が違うことに注意。

試作工房の品質基準はこんなところかな

とりあえず自分だけが使うプログラムは、自分が使う範囲の入力に対して正しく動けばいい。
繰り返し使うプログラムは、データフローを考え、見通しよく書きなおす。入力の範囲も広げてテストする。
とても多く繰り返し使うプログラムに限って実行効率も考慮する。

12. つるを切って木を見せる -- 文章を書くのもプログラミングと同じ

知識の体系は(おそらく)網のようなもの、HTMLで書けばリンクだらけ
人間の言語は、話すにしても書くにしても、基本的に時間1次元。 (2次元の図表は補助的役割という約束になっている)。
論述の文章は、ふつう木構造(階層構造)で書く。 LaTeXはそのための道具 (plain TeXは印刷紙面を直接支配するための道具で、性格がぜんぜん違う)。
ジャングルのつるを切って木を残すような頭の訓練が必要。プログラムの構造化と同じ頭の使い方だと思う。
その上で、可能ならば補助的構造としてリンクを明示する (HTMLのリンクやLaTeXの参照項目)と便利。
ただし今のHTMLリンクはgo toみたいなものなので文書群の構造化ができない。

13. 非レーニン共産主義への希望

GNU (Free Software Foundation) の精神 (Stallman, 1985)

プログラムは再配布自由であるべきだ。プログラムの価値は利用者をふやすことによってふえるのであって、制限することによってふえるのではない。
プログラムを書いたり配布したりする労働に対して対価を払うのは当然である。しかし払った人にプログラムに関する独占的権利が生じるわけではない。
わたしは、地球環境データに対しても同じ態度でのぞみたい。

インターネットの未来への希望

インターネット全体を統制する権力はできてほしくない。自由がいい。
しかし、現在のWWWのように無秩序・非定常に情報源が分布しているだけでは不満。インターネットのあちこちに知識や情報の体系化を志す人の集団 (仮称: 知識館)が出てきてほしい。

参考文献

安野光雅, 1973/1987: わが友石頭計算機。文春文庫, 155 pp.
Brooks, F.P.Jr., 1995; 滝沢徹, 牧野祐子, 富沢昇訳, 1996: 人月の神話 (原著発行20周年記念増訂版), アジソン・ウェスレイ, 321 pp.
Cleveland, W.S., 1985: The Elements of Graphing Data. Wadsworth, 323 pp. 渡部宏邦訳, 1987: 科学・技術者のためのグラフ処理技法。日刊工業新聞社, 286 pp. (1994年に原書改訂版(Revised Edition)がHobart Pressから出ているが、内容がかなり変わった。) [読書ノート]
林祥介, 1995: 地球流体電脳倶楽部(GFD-DENNOU club)-- 大学現場でのインターネット・情報計算環境の発展史と問題点を交えて。天気, 42, 545 -- 558.
増田耕一, 1988: 図形処理系についての一つの構想。 東京大学大型計算機センターニュース, 20, No. 3, 19 -- 20.
増田耕一, 1991a: 計算機利用者支援ソフトウェアに望むこと--ハイパーマニュアル構想。 1991年情報学シンポジウム講演論文集, 157 -- 160.
増田耕一, 1991b: 情報教育の悩み。東京大学教育用計算機センター報告, No. 17, 11 -- 22.
増田耕一, 1995a: 地球環境データと地理情報科学。 GIS-理論と応用, 3, No. 2, 11 -- 18.
増田耕一, 1995b: GKSを使ったプログラム例(2)--等値線(コンター)による数値の場の表現。 東京大学大型計算機センターニュース, 27, No. 5, 38 -- 46.
Packard, V., 1960; 南博, 石川弘義訳, 1961: 浪費をつくり出す人々。ダイヤモンド社.
Peek, J., O'Reilly, T. and Loukides, M., 1993: UNIX Power Tools. O'Reilly, 1119 pp.
Plauger, P.J., 1993-94; 安藤進訳, 1995-96: プログラミングの壷。共立出版、3冊, 254+234+254 pp.
Stallman, R.M., 1985; 野崎昭弘訳, 1988: GNU宣言。 Computer Today, No. 23 (1988.1), 9 -- 16.
砂原秀樹, 石井秀治, 植原啓介, 林周志, 1996: プロフェッショナルシェルプログラミング。アスキー, 254 pp.
鈴木陽一, 1991: はじめて学ぶGKS。共立出版, 177 pp.
Wessel, P. and Smith, W.H.F., 1991: Free software helps map and display data. EOS Trans. Amer. Geophys. Union, 72, 441.
山口英、坂下秀、1994: 昔は昔、今は今--目的指向の環境構築に向けて。 UNIX MAGAZINE, 1994.6, 27 -- 43. (この号から1995年3月号まで連載)

1997-05-27, 2003-05-08, 2005-05-03, 2013-12-13
増田耕一 (MASUDA Kooiti)

[増田の雑文一覧へ]