次の形で出版されたものです。 参考文献として使う場合は、次の出版物のほうをあげてください。
原稿提出が遅れ、編集担当のかたがたに申しわけなく思う。いただいた題名は「理学部地球惑星物理学科における情報処理教育について」だったが、地球惑星物理学科(以下「地物」と略す)としての計算機教育に関する方針は定まっていない。筆者の個人的な考えを述べることで代えさせていただくほかない。筆者個人にしても、最近は、計算機まわりの教育をどう進めてよいか、見通しがつかず、悩むばかりである。これは今の時代状況の反映でもあり、他の教職員のかたがたと議論を重ねていくことによって、解決の道をさぐっていかなければならないと思うので、とりあえずの議論の種を提供するしだいである。
前にも述べたように(増田、1987)、地物では多くの(全部ではない)教官や大学院生が毎日のように計算機を使っているが、そのための入門教育が系統的に用意されているわけではない。わたしはたまたま東大地物の卒業生だが、学部4年生のころ(1979年)をふりかえってみると、「気象学・海洋物理学演習1」で数値計算(差分法による数値積分)のアルゴリズムの説明のあと、教育用計算機センターで計算してみなさいという問題が出された。Fortranでやることが期待されていたようだが、Fortranの授業はなく、工学部の「算法通論」を聴講していた同級生から習った。(こういう助けあいもいいことだと思う。ただし教官側として、学生全員がなかよくやっていると期待するのは危険だろう。)
地物では今のところ物理学科で開講されている「物理学実験1」を3年生の必修科目としているので、物理学科での計算機教育の整備の恩恵を受けている。この科目の中の計算機実習は、1987年度は教育用計算機センターのMSP、1988年度は同UTSで行なわれた(釜江、1988はこの年の状況の紹介である) 。1989年度以後は物理学科および中間子科学研究センタ一保有のVax(OSはVMS)を使って行なわれている。主としてFortranによる数値計算であり、図形出力にはStanford加速器センター(SLAC)で作られたTop-Drawer(TD)というパッケージが使われている。地物の学生にも4年生までVaxのユーザIDが与えられているが、地物の演習科目にこのVaxを使うのは遠慮してほしいと言われている。したがって3年後期の「地球物理学基礎演習」や4年生の演習では、原則として教育用計算機センターを使うことになるわけだが、学生にはせっかく慣れたVaxやTDから切り離されることに不満もあるようだ。一方、大学院に進学する場合には大型計算機センターのHITAC VOS3をはじめとして、研究グループごとに違う計算機を使うことになるので、上級生から下級生にノウハウが引き継がれるという継続性も乏しい。また、教官自身がふだん使っていない計算機システムで実習の指導をするのはめんどうであり、教材整備になかなか力がはいらない。現状では、地物の教官は、自分が使いやすい計算機を使うよう指定するか、学生自身の努力に任せて放任する傾向が強い。少数の人だけがスジを通して教育用計算機センターを活用しようと努力しているが、それが総合的にみて得策であるかどうかはよくわからない。学生から見ると、教官の気まぐれでいろいろな計算機を使わされているという感じだろう。
今年度から、これまでの地球物理学科と地球物理研究施設が合併して、「地球惑星物理学科」となった。この改組に関連して、学部の実験指導を物理学科に頼らないようにするという方針が示されている。計算機教育に関しては、コマギレ状況は解消されるわけだが、いよいよ学科としてのポリシーをもって望まなくてはなるまい。計算機に関する具体的なカリキュラムの議論はまだ始まっていない。ただ、教育用計算機環境の整備としては、Unixワークステーションを中心にし、教育用計算機センターと協力して進めようという、一部の教官の提案が認められたもようである。
計算機に関する教育の中で、いろいろなOSを体験すること自体は悪くないと思う。あまりに特定のOSに依存してしまうと、それがない環境に行くのが不安になってしまう。あるOSでこうやることを別のOSではこうやる、といった経験から、なんとなく計算機とはこんなものだという認識ができてくるのがよいと思う。しかし、本格的に数値計算やデータ処理の練習をする計算機が、同じ学科のカリキュラムの中でも担当教官によってばらばらでは、多くの学生には覚えきれないし、教官側の教材整備の努力も分散してしまって困る。わたしが特に教材整備が必要だと思うのは、図形表示と、他の計算機で作られたデータを読む方法である。1つのOSを学科としての重点とし、他のOSは体験用としたほうがよいと思う。物理学科が、計算機を自前で持つというコストを払っても、研究用に使っているのと同じOS(VMS)で実習をすることにしたのもうなずける。
さて、今、1991年の時点で新たに重点OSを決めるとすれば、Unix系のものをとるのが比較的適当と思われる。Unixには欠点もある。まだウィンドウ系はよくわからないので裸のUnix(というよりもc-shell)について思うことを述べると、主要なコマンドが短く、また各種の記号(|、<、>など)を活用しているため、コマンドラインで1文字まちがえると、エラーを指摘されることよりも、意図したのと違う動作をしてしまうことが多いことである。キ一入力を気楽にやっているわたしなどには、恐ろしいものである。また、もともとMulticsに対抗して単純さで売り出したにもかかわらず、最近のUnixシステムはBell研とバークレイの両方の機能を取りこんだために複雑化しており、特にシステム管理者には(メインフレーム機ほどではないとしても)負担が重いと思う。一方、FACOM MSPやHITAC VOS3のようなIBM MVS系のメインフレームOSでは、ユーザーがコマンドで指定すべきことがたくさんある。入力まちがいがエラーとして検出されやすいのはよいのだが、ファイル形式に関するパラメタを毎回いろいろ指定しなければならないのはめんどうなので、個人ごとあるいは計算機センターごとにマクロコマンドを作ることがほとんど必須である。VMSはUnixよりがんじょうでありMVSよりもコマンドの呼び出しかたが簡単らしいのだが、DEC社の計算機に依存するので標準というわけにはいかない。これからコマンド体系の標準を作るとしたら、もっと人間工学的配慮をしてほしいと思う。しかし、標準化は多くの場合妥協である。多少不合理でも、極度に不合理でなければ、普及しているものあるいはどこかでオーソライズされたものに乗ることによって、お互いの労力を省くことができることに意味があるのだ。
一部の教官と、それを助けてくれる学生(ティーチングアシスタント)は、そのOSをよく理解している必要がある。たとえセンターがOSのインストール、管理をしてくれるとしても、トラブルが生じたときセンターの責任かユーザーの責任かを判断できる程度に理解している必要がある。それを前提として、残りの教官と学生は、末端ユーザーとして使うことができるわけだ。
わたし自身は、この意味でのエキスパートになることから逃げ回りたい気持ちなのである。確かに、HITAC VOS3で数値処理、Fortranプログラミング、データ解読、作図をすることに関してはエキスパートだと言えるし、その知識をFACOM MSP用に読みかえることもできている。(もっとも、ハードウェアはまるで知らない。センターの人がシステムを維持してくださるのを前提として、その上で0と1の列を処理することの経験を積んでいるだけである。) MS-DOSに関しでも、エキスパートとまではいかないが、初心者の質問に答えられる程度には知っている。Unixも、入門はすませているつもりである。しかし、数十・数百メガバイトのデータを扱い、作図するような仕事をしだすと、それだけではすみそうもない。それぞれの計算機のファイル容量などを意識し、試行錯誤しながら、実践的に対処し、知識として整理していかなければならないだろう。それだけの頭の余裕がわたしにはないような気がするのだ。(汎用機かパソコンに関する技能を忘れればまだ取りこめるかもしれないが、消去するのはちょっと惜しい)。
いや、計算機が専門ならばまだまだ余裕はある。プログラマ35才定年説など信じない。しかし、わたしの存在意義は、地球環境に関するデータに関する知識(どんな観測がされ、どんな形でデータが蓄積されているか、そのデータからは何がわかるか)を集積し、研究者がアクセスできるようにすることである。計算機に関する環境整備も、そのための手段として必要なのだが、それで頭をいっぱいにするわけにはいかないのだ。
というわけで、わたしのとる道は、計算機利用に関する基礎的環境整備は専門家(および準専門家になって努力してくれる同業のボランティア)に任せて、その上に応用技術を積み上げることにしたいのである。関連するみなさんのご協力をお願いするしだいである。
計算機の利用形態はいろいろある。数値計算や、データ集計も当然ながら、文書作成、メイル・掲示板といった機能も、いわゆるコンピュータ・リテラシーの要素として無視できなくなってきた。その中で、わたしが強調したいことは、「データの可視化」である。現代の科学研究には、とても数字では見きれないほどのデータを活用することが求められているものが多い。またデータのとぼしい領域でも、むしろそのことゆえに、データをいろいろと料理して見ることが重要となる。統計的要約だけではじゅうぶんではない。パタン認識に関しては、機械による方法も進んできてはいるが、人聞の目と直観力を使うことがだいじだと思う。データを人が見るための準備を計算機にやらせ、マン(注: 男性を意味しない)・マシン・システムとしての性能を上げていくことが現代の科学研究には必要だと思う。このための基礎教育を、プログラミング技能の習得と組み合わせてやりたいというのが、わたしの構想である。
データの可視化は地球科学に限ったことではないと思うのだが、出版されている本で直接参考になるものは意外に少ない。データ解析の本は統計学的手法の紹介がほとんどである。コンピュータグラフィックス関係の本は、芸術的画像を作るものか、CAD関係のものが多い。パソコンと言えばBasicだった時代には「ビジネスグラフ作成法」の本があり、多少は参考になったのだが、それらは表計算ソフトの使い方にとって代わられてしまった。
Cleveland (1985)とChambers et al. (1983)は、数少ない参考書である。前者の本は、Kernighan & Plaugerの「プログラム書法」に対応する「グラフ書法」の事例添削つき教科書である。日本語訳もあるが、残念ながら意味の通らないところがあり、改訂が望まれる。著者はいずれも有名な統計パッケージ「S」を作ったBell研究所のグループに属し、「探索型データ解析」の主唱者Tukeyの影響も受けている。特に興味深いのは、関連して変わる複数の変数があるときの解析の手段として、散布図を総当たりで作る散布図方陣(scatterplot matrix)が最適であると述べ、さらに方陣の中のある散布図中で点のグループを指定すると他の散布図にも対応する点が色をかえて表示されるような対話型システムが有効だと述べていることである。ただし、これらの本の対象は、時空間の関数としてではなく、いわば孤立して存在するデータが中心であり、いくらか時系列の扱いにふれている程度である。
可視化に限らないことにすれば、時系列(時間の関数であるデータ)の処理に関しては、スペクトル解析やディジタルフィルタを中心とするものなど、教材はたくさんある。ただ地球科学のデータを実際に扱う場合には、観測機の故障や情報伝達のミスのためにとんでもない異常値がまざっていることがあること、時代とともにデータの質が変わることがあることなど、工学系の教科書ではあまり考慮されていない問題が出てはくるが。
ところが、地球科学で欠かせない空間分布するデータの扱いとなると、なかなかよい教材がない。Ripley (1981)は多くの統計的手法をレビューしているが、地球科学者からみると数学的すぎる。野上・杉浦(1986)、塩野ら(1990)はそれぞれ地理、地質の分野での先進的な演習書であるが、プログラム例が構造化されていないBasicという言語で書かれているのでわたしとしては使いにくい。気象関係で使われているデータの空間内挿法の参考文献はいくつかあるが、やや対象が限定されすぎているように思われる。衛星による地球観測のデータ処理も重要な分野である(たとえば、Toselli編、1989参照)。空間分布するデータの処理(特に可視化)の教材整備は、わたし自身の課題の柱の1つだと思っているが、なかなか進んでいないのが現状である。
データの可視化の道具にもいろいろある。ハードウェアとして、紙などのハードコピーと、画面出力があるが、もちろん両方使えることが望ましい。さらに、図形情報を計算機のファイルとして保存したり、転送したりすることもできたほうがよい。
道具の整備の方針として、わたしは、装置の性能を最大限に発揮することよりも、互換性を重視したい。低分解能のグラフィックディスプレイの画面に表示するのにも、精密に紙に印刷するのにも、プログラムの変更は最小限ですませたい。また、進級とか、転勤とか、新しい計算機を買ったとかで、慣れたものと違う計算機を使う場合も、同じ仕事をするのにプログラムをなるべく書きかえないですませたい。そして、基本的な部分(装置に依存する部分と応用的部分をつなぐもの)は、学生が理解もでき、持って移動することもできるようなものにしたいと思っている。
また、拡張可能性も重視したい。多くのデータ処理パッケージは、空間分布するデータを扱うように作られていない。また、空間分布を扱う場合も、線画(ペクトル情報)系と画像(ラスター情報)系が別々になっていることが多く、両者を重ねて扱うことは考慮されていないことが多い。必要が生じた際に拡張できるようになっていないと困る。
また、特定のメーカーやOSに依存しない、標準を重視したい。特にISOなどの国際標準があればなるべくこれに従いたいと思っている。実際の標準を見ると、不便や不合理を感じるところもけっこうある。しかし、多少の不便は妥協して標準を使うことにより、おたがいにてまがはぶけるのだと思う。もちろん、標準を作る段階ではなるべく合理的に考えるべきではあるが。
これらのことを考慮すると、現状ではわたしはサブルーチンライブラリと手順だて型のプログラム言語をデータの可視化の道具として重視したいと思う。サブルーチン方式はプログラムが全体として大きくなるという欠点があり、オブジェクト指向が普及すれば図形処理装置と対話する発想のプログラムに置きかわっていくのではないかと思うが。もう一つ、図形情報をデータファイルとして交換することも大事である。違うプログラム言語やパッケージを連結して同時に使うことはむずかしいが、いったん共通の形式のファイルに書き出せばなんとかなる。
これらの中でわたしが推進したいのは，GKSとCGMである。GKSだけでは実用にならない(軸や目もりをかくルーチンもない。そういったものは応用プログラムと位置づけられている)。また、もうPHIGSの時代でありGKSは古い、という話も聞く。しかし、パソコンも汎用機も含めてPHIGSが2、3年のうちに動くようになるとは期待しにくいし、PHIGSはGKSと共通の概念が多いので、むしろ複雑なPHIGSへの入門用としてGKSを使うことも意味があるのではないかと思う。
地物3年後期の「地球物理学基礎演習」では、約30人のクラスを7人の教官が交代で担当する。1人の教官の担当は2週間に集中した6回である。自分の担当の授業計画をたてるにあたって、これだけの回数で、空間分布するデータの処理にまで踏みこむのは無理があると判断し、Clevelandの線に沿った、散布図と時系列グラフを作ってみる実習にすることにした。
教育用計算機センターの設備を使うことは決めていたのだが、どのOS、グラフィックシステムを使うかでは迷った。上に論じたような理由で、できればGKSを使いたかった。しかし当時のセンターでGKS準拠のパッケージは、セイコー電子のGKSP2があるにはあったが、特定のグラフィックディスプレイ(D-SCAN)への出力しかできないようだった。その他のFortranで使えるグラフィックサブルーチンライブラリとしてはMSP上のPSPがあったが、(当時のわたしおよびセンタースタッフの知識では)出力先がNLPというプリンタに限られ、しかもNLPでは1回ごとに表紙がつくので紙がもったいない。プロッタルーチンが旧時代のものであることも考えあわせると勧める気になれなかった。UTS上のグラフィックサブルーチンの存在はよくわからなかった。(実のところまじめに調べなかった。UTSで実習をしてデバッグ相談に答えるのはしんどいと思ったからである。) FMRのMS-DOS上のFortranで動くグラフィックライブラリは見当たらなかった。金子(1991)のライブラリはすでにできていたらしいが、当時は知らなかった。
そのようなわけで、FMR(MS-DOS)のTurbo Pascalで動くECC版CGMライブラリ(吉村、1987)を使うことにした。これならば、画面出力のほか、「HOSTOUT」機能能によるプリンタ(MSPのNLP)への出力がライブラリのさしかえだけでできる。ただし当時、本郷のHOSTOUTは動かなくなっており、復活のためにセンターおよび富士通のスタッフをわずらわせることとなった。
CGMは本来図形情報ファイルのISO標準であり、GKSの代わりではないが、その要素の構成はGKSと似ている。ECC CGMライブラリは、CGMの要素を1つずつ作るPascalの手続き(procedure)からできている。1つの版は実際にCGMファイルを作るものになっており、HOSTOUTというのはそのファイルを転送してホスト側で作図するものである。もう1つの版はFMR (1987年当時はFMI6β)のグラフィック機能(GDS-BASE)を呼び出してすぐに画面に作図するようになっている。実はGDS-BASEがCGM(というよりもその姉妹規格であるCGI)に準拠するように設計されており、ECC版ライブラリはその1つ1つの機能をPascalから呼び出せるようにしたものである。
わたしはこのライブラリが本郷で公開されると同時に試してみた。そのころから普及したキャノンのプリンタ「レーザーショット」のコマンド(LIPS)のグラフィック関係の部分がCGMに近い(CGIの前身となった案であるVDMに準拠している)ことに気づき、それ用に改造してみた。また、NEC PC9801のグラフィック機能(GLIO)利用のものも作りかけたが、16色モードにするのがむずかしく、Turbo Pascal Ver. 5が出たのを機会にそれに付属するBGIを利用するものに切りかえた。そのような蓄積があったので、教育用センターのFMRで学生に使わせるプログラムを、自宅のPC98でデバッグし、研究室のレーザーショットで図の見本を作ることができた。互換性のある道具を作るのにはある程度時聞をかけても悪くないと思う。
また、CGMの座標系は抽象化された装置座標系だけで、データと対応づけるのに不便なので、CGMライブラリのユーザ側に、GKSにならった正規化装置座標と世界座標の描画ルーチンのライブラリを追加することにした。それから、グラフのワクをかくことなども初心者にはかなりの試行錯誤を要することなので、とにかくグラフの形が整っている(しかもCleveland先生の指針に従っている)プログラム例を1つ配って、それを変形して使ってみることを勧めてみた。
最初の予定では5回めまででレポートとして自作のグラフを提出してもらい、6回めに講評するつもりだったのだが、2回半ほどを講義に使ってしまったせいもあって、多くの学生がシステムに慣れるのにてまどり、最終回まで計算機作業になってしまった。大部分の学生がグラフを作ることができ、いちおうの目的は達したと思う。しかし、この演習の時間以外にこのグラフィックライブラリを活用した話や、自発的にデータをプロットしてみたという話は聞いていない。
4年生の「地球物理学演習」は小グループで、同じ教官が半年つきあう形である。時間の順序は逆になるが、1990年度前期の4年演習も担当した。こちらは空間分布するデータを扱ってみた。題材は地表面の熱収支の各項の地球上の分布である。このような情報は多くの人が地図帳の形で出版しているが、地図投影法が違うのでそのまま重ねて比較することができない。そこで、地図上の等値線の位置をディジタイザで読み取り、地図投影の逆変換をして緯度・経度にして、同じ地図に重ねてみようということにした。作図部分は上記のCGMライブラリを利用して筆者が作ったプログラムを学生が改造して使った。ただし作業時間を自由にとりたいということから、センターではなく研究室のPCを利用した。一方、数表の形になっているデータは、分散配置FMRの表計算ソフトを利用して入力やグラフ化をした。実用的逆変換システムには至らなかったものの、充実した演習であった。難点としては、プログラミングを比較的得意とする学生がどんどん進めてしまうために、他の学生は技術的な詳細を知らないまま進んでしまうということがあった。
今年度も後期の3年演習を担当することになっているが、今度はセンターにGKS準拠のパッケージが導入されたので、GKSを使ってデータを作図することにしようと考えている。これまでに、MSPの「GKS85」で、FMR(F6683エミュレータ)の画面と、NLPとに同じプログラムで出力できるようにした。GKS準拠のライブラリであれば、サブルーチンの名まえ、形式などが同じなので、利用者が他のシステムに移るのは比較的やさしい。(とは言っても、個々の装置の指定のしかた、色の番号、1画面かき終わった時の処理など、それぞれのライブラリごとに確認しておくべきことがある。) 将来の教育への継続性からいうと、UTSあるいはSun-OS上で演習をしたほうがよいかもしれない。問題は、11月までに、わたしがこれらのOS上のGKSライブラリに慣れる時間がとれるかどうかである。なお、わたしの授業では使わないつもりだが、TDに慣れている学生のために、KEK Drawerも導入しておきたいと考えている。
今年度も前期の4年演習も担当している。内容は、全地球規模の気象データを使った熱収支の集計である。今度はデータが比較的大量であり、わたしの指導能力を考えて、MSPを利用して計算させることにした。作図部分は、NCARグラフィックス(東大版NCARG)を、PSPを呼ぶようにインストールして使ったが、これはNLPにしか出力できないので不便だった。現在、GKS85の上で動く(画面出力もできる)NCARGを整備中であり、公開できそうである。
この4年演習では、わたしが6年前に研究として大型計算機センターで処理した中間結果を使わせるつもりだった。ところが、磁気テープがいたんでいて正しく読めない部分があった。プログラムは保存してあり、再計算はむずかしいことではない。CPUの能力としては、今の教育用センターのMSPでじゅうぶんである。が、2ギガバイ卜(6250 bpiのテープ16本)のデータを読む必要がある。教育用MSPでは、ディスク量が小さく、教師用のユーザーIDでも一度にテープ1本つまり150メガバイトのデータをディスクに入れることができなかった。テープを直接読むようにアルゴリズムを変えれば動かないでもなかったのだが、急いでいたこともあり、わたしは大型センターで前処理をした。しかし6年前の研究の再現自体、今や学部演習としてやらせたいスケールである。教育用センターには、100メガバイト規模のデータを収容できるディスクが必要だと思う。光磁気ディスクがよいかもしれない。
グラフ、地図のような線画作図の環境整備が一段落したら、次にやりたいのは、衛星観測などの、画像(ラスター)データの可視化である。第1に、画像表示である。現在、わたしのふだん使える範囲に、精度のよい静止画像表示装置はない。(大型センターに動画ビデオ作成装置はある)。学科としての教育用計算環境整備と矛盾しない形で実現するしかたを考えていきたい。第2に、座標変換である。衛星から見た画像を緯度・経度座標に変換するのは衛星観測データ利用の基本的処理である。幸い、科学研究費のグループでこの機能をもつプログラムライブラリの整備が進行しているので、これを組みこみたい。第3に、Clevelandらが示している散布図方陣の会話型システムのようなものを、空間分布を含めて実現したい。つまり、地図上である領域を限ったら対応する画素が散布図上でも表示され、散布図上で領域を限ったら地図上でも表示されるようにしたいのである。ただしこれらの目標の実現の見通しはたっていない。
計算機の分散化が進み、同じ計算機資源を共有する必要は必ずしもなくなってきた。その一方で、計算機の専門家でない人が計算機を管理し、道具を整備する必要がある。学生ばかりではなく、教官・職員の研修の場も必要である。大学の情報処理教育センター(東大の「教育用計算機センター」に対応するもので最近設立されるところは多くがこのような名前である)の今後の主要任務は、情報処理に関する知識の共有ではあるまいか。
知識の共有はフロー(流れ)とストック(蓄積)に分けられよう。フローの手段としては、教育用計算機センターでは、すでに多くのボランティアの努力により、BBSが動いている。情報処理教育に関心がある(困っている)教官のみなさんには、これに積極的に参加していただきたいと思う。BBSに情報処理教育のボードを作ることも検討課題として提案したい(あるいはjunet newsのグループのほうがよいかもしれない)。一方、BBSをもう少し便利にする努力もお願いしたい。少なくともMS-DOSやMacintoshで作った日本語テキストを、漢字コードが化けないように投稿するためのマニュアルを確立してほしい。
ストックの整備は、人事、予算措置も含めた継続的努力を必要とする、重い問題になってしまうかもしれない。道具の面に限れば、ハイパーテキストとテキストデータペースを兼ねたようなソフトウェアがあるといいと思っている(増田、1991)。