>>アフリカ地域研究専攻ホームページ  >>木村大治プロフィール Top  >>エッセイ,論文PDF

(本稿は,福井大学情報処理センターニュース NETWORK 6-2 (1992年発行) pp.8-22 に掲載されたものを,同センターの許可を得て再録したものです。)


アフリカ熱帯多雨林でコンピュータを使う

1.耳年増

 私は子供の頃からコンピュータ好きだった。小学校の頃は鉄腕アトムのファンで、光文社版のシリーズを全部買ってもらっていたが、その別冊にコンピュータの特集があった(もう一冊の特集はロボットであった)。ENIACの名前を知ったのはその頃である。中学校ではNHK教育の「コンピュータ講座」をかかさず見ており、テキストも買った。FortranだALGOLだといった名前を、文法も知らずに覚えこんでいた。実際にコンピュータがいじれるわけはなかったので、いわば「コンピュータ耳年増」だったわけである。(いまでもその傾向はあって、聞いたことはあるけれど実際には使えないハードやソフトが多いので、コンピュータができる人間だと思わないでください。)
 大学に入って、計算機実習でコンピュータが使えるようになったときはうれしくて、ひとの使用時間までもらって、TSSのFortranでコンウェイのライフゲームをプログラムしたりしていた。
 それがどういうわけか人類学を専攻することになった。人類学といえばフィールドワークである。もちろんフィールドで得た結果をじっくり分析することも必要だが、そればっかりやっていると馬鹿にされる。人類学者は安楽椅子には注意して座らないといけないのである。
 私はコンピュータも好きだが、フィールドも嫌いではない。大学院に入って2ヵ月目にフィールドを探しに南西諸島に出かけ、ある離島を選んで帰ってきた。その後足掛け6ヵ月間、私はその島に住み込むことになった。当時、研究室にはパソコンPC-8801が入ったばかりだったが、TSSの課金に気兼ねすることなくコンピュータをいじれる「パーソナルな」環境は画期的だった。フィールドから持ち帰った島民の対人関係のデータを、その88で処理することにした。そこで大量のデータのインプットという作業が必要になってくる。だがやったことのある方はおわかりだろうが、これほど退屈で、非生産的で、苦痛な仕事はない。そこで、フィールドで直接データを入力できれば、という夢を描きはじめるのは当然のなりゆきである。
 その後博士課程で、アフリカ・ザイール共和国の農耕民ボンガンドの調査に行くことになった。その頃、PC-8201というハンドヘルド・コンピュータ(なつかしい呼び名である)が発売されていたが、買おうかと考えているうちに出発の日が来てしまった。1986年10月のことである。

2.ノリコ

 3ヵ月の予備調査を終え、12月の末に一人で首都キンシャサに出てきた。とりあえず言葉が喋れるようになり、ある程度の土地勘もできたが、論文にできるような収穫はなにもなかった。はじめての調査はそんなものかもしれない。正月は疲れが出て発熱し、ホテルで寝ていた。少し回復してから日本大使館へ顔を出し、日本の古新聞と週刊誌を借りた。活字に飢えていたのである。ホテルに帰るのももどかしく、大使館前の道端に腰をおろしてむさぼるように読んだ。1面の下段に出ていたのが、PC-98LTという新しい機種の解説本の広告であった。私は照りつける太陽の下で、帰ったらこれを買おうと決心した。
 PC-98LT(以下LT)は、98シリーズではじめて出たラップトップ(この呼び名も死語になりつつあるが)であった。画面まわりをけちっており、98と完全コンパチではないので、98のソフトでビデオRAMをいじっているものはまともには走らない。だから一太郎も使えず、下位バージョンである「サスケ」を手に入れねばならなかった。だがdBASEVは変な技巧を使ってないせいか、そのまますなおに走った。ソフトはこのほか、MS-DOS版N88BASIC、RUN/Prologを用意した。
 講談社の野間アジア・アフリカ奨学金に当たって、1987年4月から1989年3月までの2年間、次のフィールドワークに行けることになっていた。私は3ヵ月の準備期間で、あたふたとコンピュータ関係の機器を購入した。LTとプリンタは買ったが、問題はどうやってそれを駆動するかである。私のフィールドは熱帯多雨林の中にある焼畑農耕民の村で、電気はない。ランプを灯せるのも、灯油が手に入る裕福な家だけである。ラップトップは乾電池で駆動できないわけではないが、2年分の電池を持っていくのはたいへんだ。そこで私は、太陽電池を使うことにした。
 私がもといた研究室は「人類進化論講座」という名前で、みんな「ジンルイ」と呼んでいた。私はジンルイではじめてコンピュータをフィールドに持っていく人間になったわけである。しかし周囲には、コンピュータを持っていくことについて否定的な意見を述べる人もあった。フィールドワークは人類学者にとって、自分の感性を最大限に開き、なにごとかを感じ取ろうと努力する場である。そういった場にコンピュータを持ち込むと、見えるものが、コンピュータの分析に乗るつまらないものだけになってしまうのではないか。その人たちはそう心配したのである。
 しかし私としては、じゃあ止めます、と引き下がるわけにはいかなかった。コンピュータをもっと気楽な相手として考えられないか。それを自分の窓口を限定してしまうものとしてではなく、見聞きする能力を補助する、いわば双眼鏡や顕微鏡のような「道具」として考えられないか。私は忠告を聞くたびにそう思った。

写真1: 家の屋根上の太陽電池パネル

 いずれにせよ、出発してしまえば終わりである。キンシャサの国際空港の税関をすり抜けたLTに、私は「ノリコ」という名前をつけていた。私は家でリカちゃん人形を飾っているわけでもなく、ビデオの山に埋もれているわけでもない。「ノリコちゃんには不満がいっぱい」という記事が「ザ・ベーシック」という雑誌に載っており、その中に、LTの開発コードネームが「ノリコ」であったということが書かれていたので、そう呼んだのである。(もっとも、UNIXユーザならマシンに名前をつけることはそう変には思わないだろうが。)
 現地の村につき、別送の太陽電池システムを荷ほどきし、パネルを屋根に乗せた。ノリコは無事に動きはじめた。(太陽電池の使用ノウハウに関しては別の所)で報告しておいたので、興味のある方はそちらを参照されたい。)

3.ロンガンド語彙集

 人類学者がフィールドに入ってまずしなければならない仕事は、現地の人と意志を通じる手段を確保することである。できれば、その人たちが日常使っている言葉を習得することが望ましい。通訳を使って珍妙な誤解が生じた例はいくらでもある。「カンガルー」というのがオーストラリア原住民のことばで「わからない」という意味だった、というのは有名な話である(ほんとか嘘か知らないが)。
 私は現地の人と話し合うのに、現地語ロンガンド(Longando)ではなく、ザイールのリンガ・フランカ(部族間共通語)のひとつであるリンガラ(Lingala)を使った。彼らはみんな、ロンガンドとリンガラの両方を話せるのである。しかしリンガラは、もともと軍隊で共通語として使われたことから広まった、ある意味で「粗野な」言語である。覚えるのは比較的簡単で、語学の苦手な私でも数ヵ月で十分話せるようになった。しかしリンガラでは、現地語のもつ微妙なニュアンスの相当部分が消えうせてしまっているようであった。ロンガンドをやらねばならない、と私は心に決めていた。
 しかしこの言葉には、文法書も、辞書もないのである。しばらくして、近くのカソリック・ミッションの神父さんに、自作の文法書を見せてもらうことができた。しかしそれは私の滞在する地域のとはずいぶん違った方言のものであった。すべてを一からはじめなければならなかった。
 インフォーマント(現地人の情報提供者)に、リンゴモ・ボンゴリ氏という、大学出で英語ができる優秀な人を雇うことができた。私と同い年であった。最初にやってもらったのが、dBASEのデータ入力のしかたを覚え、自分の知っているロンガンドの単語とその英訳を片っ端から入力する、という作業だった。飲み込みの早い彼は、1ヵ月で約2000語の入力をやってのけた。

写真2: コンピュータへのデータ入力

 そこからがコンピュータの出番である。私はdBASEを使い、彼の入力してくれた語彙集のデータを加工した。まず英語訳を日本語にし、品詞の分類項目をつけ、品詞別にソートし、足りない単語をつけたし、さらにソートし・・・。ところが途中から、dBASEを使うことに不自由を感じはじめた。dBASEでは「ひとつのロンガンドの単語に対して複数の日本語訳をつける」などという作業が非常にやりづらいのである。たとえば、"nd-anga"という動詞に対して、「好きだ」という訳と「愛する」という訳をつけたくなる。しかしdBASEで2つの訳を1つのレコードに収めるには、別々のフィールド(「訳1」「訳2」・・・など)を作らねばならない。それらを対等な立場で扱うのは非常に厄介なのである。そのようなことは大型機に備えられているデータベースソフトでは「多値フィールド」という名前で可能になっているらしいが、私の知る限りでは、パソコンレベルのデータベースでそれができるものは存在しない。
 私はやむをえず、自分でデータベース・システムを作ることにした。都合のいいことに、持参していたPrologは、リスト構造が使えるので、そういった作業がわりあい自然にできた。リストの中身は、外からみれば同等な手順で扱うことができるからである(ただし実際にPrologがする作業は、データがリストの深いところに置かれるにしたがって増えてくる)。Prologは、実用的なプログラムを組むという点ではけっこう難しいところがあるのだが、考え方そのものは面白く、親しみのわく言語であった。調査中にはいろいろなデータベースを作ったが、それらは高速ソートが必要な場面以外はすべてPrologで処理した。(Prologについては本誌でまた機会があれば書いてみたい。)
 長い校定作業の後、語彙集が完成した。私はたっぷり一日かけて、語彙集を印刷した。100ページのものができた。それはさらにたくさんの書き込みを加えたまま、私の手元にある。きちんとした形で出版したいがいまだに果たしていない。

4.インクリボンの巻き戻し

 ノリコと一緒に、セットで発売されていた小型の熱転写プリンタを持参した。これは当時手に入るものでは一番小さいプリンタだったように思う。太陽電池で元気に動き、印字も十分きれいだった。印字用紙は、熱転写プリンタ用のものなど使わなくても、ザイール製の粗末なノートをばらしたもので十分であった。
 ノートは村人たちの間では貴重品である。子供たちは学校の勉強のために、いつもノートをほしがっている。一冊のノートを上下半分に切ったものを、このページにはフランス語、こちらには算数と、全部の教科に使ったりしているのである。私がはじめて村に入り、自分の部屋で荷物をかたづけているとき、ドアにノックの音がして、女の子がふたり顔をのぞかせた。はずかしそうに"Kimura, pesa ngai kaie"と言った。「キムラ、ノートをちょうだい」という意味である。私がはじめて個人的にかけられた言葉なので、心に残っている。
 私は現地の人の水準からすると、想像もできないような「金持ち」であったから、プリントアウト用には湯水のようにノートを使うことができた。問題はインクリボンである。最近は熱転写プリンタのリボンでも複数回使用できるものがあるが、私のプリンタのリボンは一回こっきりのものであった。それを見越してたくさん持って行ってはいたが、どうしても印刷するときに、もったいないという気がしてしまう。
 ある日ふと思いついて、ケースを開いてリボンを巻き戻してみた。印刷すると、ほとんど何の遜色もない印字が得られた。その瞬間、脳裏でザイールでのコンピュータ・ライフの将来が薔薇色に輝いた。これでインクリボンに遠慮することなく、いくらでもプリントアウトができるのだ。いろいろ試してみると、印字の濃度を薄くすれば、4回は巻き戻して使えることがわかった。それを一回しか使えないようにしているのは、コンピュータ業者の陰謀としか思えない。ただ、インクリボンのケースが構造的に巻き戻しができないようになっているので、作業は微妙であった。ときどきリボンがあふれだして、どうにもならなくなることがあった。そんな時は、くそ、とつぶやきながらインクリボンを焚き火に放りこんだ。

5.Vector Data Processor

 ボンガンドの土地は、熱帯多雨林のただ中にある。彼らはその中を走る自動車道路に沿って村を作り、村の周囲の森で焼畑をおこなっている。森への道は、アフリカショウガなどがぎっしりと生えた二次林(いちど人の手が入り、それからまた植物が生えてきた林)の中を曲がりくねって続き、意外なところにぽっかりと畑が開けていたりする。いったいどのくらいの広さの畑が、どのくらい村から離れた所にあるのだろうか。私は森への道を歩くたびに疑問に思った。村・森・畑の地図を正確に描くことは、この人々の生態を描き出すために重要な作業となるに違いない。
 しかし、航空写真などというものは手に入るわけもない。軽飛行機をチャーターして上空を飛んでもらい、写真を撮ることは不可能ではないが、それで私の調査費のかなりの部分は消えてしまうことになる。
 そこで、歩測で地図を描いてみようと考えた。むかし、学部学生の頃、地学の実習で同じようなことをやったことがあるのだ。その時はひとつの建物の周りを短い直線で区切りながら一周し、その直線の長さと方向を測量した。あとでそれらのベクトルを紙の上で足しあわせると、歩いた経路の地図ができるのである。しかも一周して出てきた誤差は、その誤差の逆ベクトルをそれぞれのベクトルに比例配分してやれば消すことができる。うまい方法である。これと同じことを、距離は歩測で、方向は方位磁石で測ってやってみることにした。
 学部の実習を思い出しながら、N88BASICでプログラムを書きはじめた。最初はファイルを読み書きするのと図を書くのを別のプログラムでやっていたが、いちいちロードしなおすのが面倒になって、二つを合体してメニューで呼び出すことにした。ためしに、近くの畑まで行って、帰って、行って、帰ってと4回測量して図にしてみたが、それらはかなりの精度で一致していた。使いものになるな、と気をよくし、村のまわりのすべての畑と道の地図を作ることにした。
 プログラムは使っていて不便を感じたらどんどん改良し、新しい機能をつけ加えていった。ファイルの入出力回りを整備し、二つのバッファが使えるようにし(このあたりは一太郎の影響か)、地図の画面にグリッドが出るようにし、マクロが使えるようにし、等々。私はこのプログラムにVector Data Processorという仰々しい名前をつけた。
 毎日、午後の2時間ほどを「測量」にあてた。助手をつけたこともあるが、たいてい一人ででかけた。片手に方角を測定するための長い棒を接着した方位磁石を持ち、片手にはマシェット(山刀)をもつ。測る道や畑の周囲を、数メートル歩数を数えながら歩いては方角を測り、それをフィールドノートに記録する。それを繰り返す。暑く、単調な作業である。ハリナシバチが汗に群がり、追っても追ってもついてくることもある。
 楽しみは帰ってからのデータ入力である。見返しても何のことやらわからない数字の列が、VDPの「描画」のコマンドで、画面上に伸びていく曲線に変換される。ここは意外に近かったな、とか、あの曲がり角がここだな、といったように、歩いた場所の風景が浮かんでくる。2ヵ月ほどかけて、私の住んでいた村の周囲の地図が完成した。
 帰国してから、XYプロッタに出力する機能を追加し、論文用の地図は全部それで書いた。今後は完成した地図をもとに、畑の分布の数量的な分析などもしてみたいと思っている。
 こういった簡易測量は、フィールド屋にはけっこう需要があるだろうから、いつかVDPをPDSとして公開したいとも考えている。しかしN88BASICで書いているものだから、ソースは人に見せられないどころか、あとで自分が見ても何をしているのかよくわからないスパゲッティになっている。Cかなにか、もうすこし格好のいい言語で書き直してからにしたい。

6.親族関係分析とProlog

 そもそもPrologを持っていったのは、親族関係を分析したい、という目論見があってのことであった。
 修士時代、南西諸島の調査をやっているとき、島の親族関係を分析したことがある。ところが、データを前にしていざ家系図を書こうとすると、親族関係があまりにも入り組んでいるために、とても一つの図におさまらないのである。そこでコンピュータを使うことを考えた。国立民族学博物館の杉田繁治先生に相談すると、PL/Iで書かれたkinprogramというプログラムを紹介してくださった。リストもいただいたのだが、PL/Iは使ったことがないし、あまりにも大きなプログラムだったので、解読するのはやめた。けっきょく、大型センターのPascalを使って自分でプログラムを書いた。Pascalはポインタが使えるので、親族関係が比較的簡単に表現できたのである。
 その後、Prologのことを知った。Prologのデータやプログラム(実はこの二つには区別がないのだが)は関係の表現そのものであり、これこそ親族関係の分析に最適の言語ではないかと思った。実際、Prologの教科書にはサザエさん一家の親族関係(あの複雑な)の表現と分析、なんてのが出たりしている。たとえば
親子(サザエ,タラ).
親子(マスオ,タラ).
親子(波平,サザエ).
親子(フネ,サザエ).
親子(波平,カツオ).
親子(フネ,カツオ).  夫婦(マスオ,サザエ).  夫婦(波平,フネ).
祖父母_孫(X,Y):- 親子(X,Z),親子(Z,Y).
キョウダイ(X,Y):- 親子(Z,X),親子(Z,Y),X\=Y.  オジオバ_オイメイ(X,Y):- キョウ ダイ(X,Z),親子(Z,Y).
などという具合である。 最近作者が亡くなったので、なつかしくてつい熱心に書いてしまった。
 最初はアフリカのフィールドで、何千人分ものデータを集め、「ボンガンドの親族と婚姻」というテーマで詳細な研究をしてやろう、という遠大な計画を立てていた。しかしデータを集めはじめたのは、2年目も半分以上過ぎた頃からであった。だんだん難しさがわかってきたので、実行に移せなかったのである。
 まず困ったのは、一人の人がたくさんの名前を持っていることであった。本名、父の名、クリスチャンネーム(ふだんはこれで呼ばれることが多い)、他人がつけたあだ名、自分がつけたあだ名、引き継いでいる祖先の名前・・・これらはすべて、その人の名前なのである。また、知り合い外国人の名前を子供につけることもよくある。ちなみに、向こうには「キムラ」という名前の子供が二人いる(私の子ではない)。さらに、兄が死ぬと弟が兄と同一視され、社会的地位や名前を引き継ぐということもおこる。これは「兄弟姉妹同一視の法則」と呼ばれ、多くの民族でみられる現象である。そのとき、名前や親族関係について聞いていると、その人自身のこととその人の兄弟のことが混同されてしまう。このように、名前によって個人を特定することがなかなか難しかったのである。
 また、この社会では離婚は珍しくなく、異父キョウダイや異母キョウダイがごろごろいる、という人が多いのも困ったことであった。すべての親族関係を聞き出すのが大変なのである。
 ただし分析用のプログラムの方は、Prologで比較的きれいな形で書けた。Pascalで数百行かかった仕事が、わずか80行におさまった。こういった「関係」そのものを扱う問題に対するPrologの記述性の良さがわかる。
 プログラムの使い勝手をすこし紹介してみる。
 データは核家族単位で
fam(父親,母親,[子供,子供,....]).
という形式で入力する。
fam(lokalo_bokoli,mboyo_likenge,[bongolo_lokalo,nkumbo_lokalo]).
fam(embele_bohanda,mboyo_likenge,[baombo_embele,lokemba_embele,nkanga_embele,
bokomba_embele]).
fam(nsimba_boheko,bokomba_nkenge,[bokumbe_nsimba,belake_nsimba]).
....
のようにテキストファイルで書いておき、それをPrologに読み込ませる。そして分析プログラムを読み込ませて、
rel(lokalo_bokoli,nkumbo_lokalo).
すなわち「lokalo_bokoli氏とnkumbo_lokalo氏の(最短の)親族関係は何か」と質問すると、プログラムは親族関係の連鎖を探索して、
0親等3人追跡
1親等6人追跡
[Ego,C]←これはEgo(自分)のC(Child)
[lokalo_bokoli,nkumbo_lokalo]がnkumbo_lokaloであることを示す
親等= 1婚姻結合= 0
と出力する。また、
trace(nsimba_lokemba).
と質問すると、nsimba_lokemba氏の親族を近いほうから追跡して
nsimba_lokemba 0-0 [Ego] [nsimba_lokemba]
esanga_botsili 0-1 [Ego,W] [nsimba_lokemba,esanga_botsili]
bikomba_boseleka 0-1 [Ego,W] [nsimba_lokemba,bikomba_boseleka]
....
mpaa_nsimba 2-0 [Ego,Sib_m] [nsimba_lokemba,mpaa_nsimba]
boheko_bokoli 2-1 [Ego,M,H,F] [nsimba_lokemba,bato_ahe_bombele,nsimba_boheko,
boheko_bokoli]
....
という形で出力するのである。
 この結果をもとに、姻戚関係のクラスターを求めたり、特定の親族関係同士(たとえば母方交差イトコ)の結婚が有意に多いかどうかを検定したりなど、さまざまな分析が可能になるはずである。
 しかし肝心のデータの方が集まらず、この仕事はやりかけで止まっている。ソフトのRUN/Prologの方にも問題がある。大量のデータを一度に分析するには遅すぎるし、ちょっと大きなデータを入れると「スタックが足りません」(もう覚えられまへん、の意)と言ってへたってしまうのである。プログラムをもっと大きな機械で走るPrologに移植することも考えねばならない。
 Prologを使ったデータベースは、ほかにもいろいろ作った。Prologを使うと、dBASEのような単純な表型のデータ構造だけでなく、階層的なデータ構造もうまく表現できる。たとえば動物の分類では、まず哺乳類か、爬虫類か、などというのが最初に来て、次に哺乳類なら何科か、という分類が来る。さらにそれが細かく分類されていく。このような「入れ子構造」をもったデータには、Prologのような、再帰的な呼び出しが可能な言語がよくマッチするのである。動植物の分類、植物の名前、畑の位置・所有者・作物、病気の種類と治療法など、いろいろなデータベースを作った。工夫したプログラムをまとめて、PBase(Prolog DataBase)などと呼んでいた。最近同じ名前のデータベースソフトが発売されたが、登録商標(?)がそちらに取られてしまったのは残念である。

7.フィルタの発見

 いろいろなデータを、集めては加工し、修正しては加工し、という作業を繰り返していると、だんだん仕事のパターンが見えてきた。
 まず、とにかく手当たり次第にデータを集め、テキストファイルの形で入力する。たとえば、ボンガンドの人々が認識している病気のデータの場合、最初は、聞いた病気の名前やら、治療法やらを覚え書き程度にテキストファイルに書き込んでいく。また、別の人が集めたデータがあったので、それも同時に入力する。
 データがたまると、ソートをかけたくなってくる。Prologでソートするプログラムを組んでいたが、その前にPrologに認識できる形にデータをそろえねばならない。データの整形にはエディタやサスケの置換コマンドを多用した。しかしへたな書き換えをすると、書き換えてはいけない部分まで変えてしまうので、どういう順番でやるかはよく考えないといけない。パズルを解くようなおもしろい作業であった。(その頃はSEDなどというものの存在は知らなかった。)
 データをソートすると、けっこういろいろな入力ミスが見えてくるものである。同じデータを二回入力していたり、同じ発音を違う表記にしていたり、等々。それを修正し、またソートし、さらに別のキーでソートし、ということを何回か繰り返すと、データの質はずいぶん高くなってくる。
 また、新しい項目もつけ加えたくなってくる。病気のデータベースの例でいうと、その病気が何科にかかるべき病気なのか、という分類をしたくなる。そこで新たなフィールドを作り、皮膚科、消化器科、眼科などという分類を入力する。
 要するに、私がフィールドでやっていたデータ処理の仕事は、ほとんどが「ファイルを書き換える」という作業であったのだ。あるテキストファイルを、ある規則にしたがって、別のテキストファイルに書き換える。その仕事を何度も繰り返しながら、すこしずつデータベースの質と量を高めていくのである。
 そのようなことを繰り返しているうちに、"PBase"のライブラリの中には、ソート、フィールドの順番入れ替え、フィールドの抽出、合計など、いくつもデータ変形用のプログラムがたまってきた。日本に帰ったらそれらを体系だてて整理しなければならないな、と考えていた。
 賢明なる読者諸氏はすでにお気付きのことと思うが、私は結果的には、UNIXでいうところのフィルタを作っていたのである。帰国して本屋をうろついていると、「プログラミング言語AWK」という本が目に止まった。ぱらぱらとめくってみてショックを受けた。私がやりたかったことがまさにそこに実現されていたからである。その頃はUNIXが使える環境にはいなかったから、急いでMS-DOSで走るAWK(JGAWK)や、その他のフィルタ系のユーティリティを集めた。
 AWKについては、本号のイエローページに解説を書いているので、その後日談はそちらを見ていただきたい。

8.フロッピーの中の星雲

 コンピュータを持っていくにあたって一番心配だったのは、現地でそれが故障することであった。高温多湿なところでは基板の接着剤にカビが生えることがあるという恐ろしい話を聞いていたので、LTのニッカド電池を入れる所に、写真用の防カビ剤を放りこんでおいた(電気は太陽電池につないだ大型バッテリーから直接とっていた)。途中でディスクドライブの調子が悪くなり、分解してみたことがある。故障はドライブに乾燥用のシリカゲルの粒がはまり込んでいたせいで、基板そのものは何も問題はなかった。小さな蜘蛛が中で巣を張っていた。
 ほこりが多い場所で使うので、フロッピーディスクが壊れるのは覚悟していた。私は部屋が4つもある豪邸(向こうの水準にすれば)に住んでいたが、床は粘っこい土をつき固めた土間で、時々水を撒かないとすぐほこりっぽくなる。当時は3.5インチのディスクは信頼性がもうひとつだという噂もあったので、三重ぐらいにバックアップを取っておいた。しかし毎日使っていたサスケやdBASEのディスクは、まったく壊れる気配はなかった。
 ところが不思議なことに、使わずに大事にしまってあるバックアップ用のディスクの方が、次々と壊れはじめたのである。大事なデータを失ってしまうという事故が一度あった。データはノートを参照してなんとか修復できたが、それ以後、私はますます念入りにバックアップを取るようになった。
 帰国の3ヵ月ほど前、ふと壊れたディスクのシャッターをあけて、表面を光にかざしてみた。すると小さな円盤の上に、ほこりによる円弧状の傷ではなく、ぼんやりと広がる星雲状の曇りが点々と散らばっているのが見えた。それはまぎれもなくフロッピーディスクに生えたカビであった。
 疑問は氷解した。よく使うディスクは、使うことによってディスク表面の風通しがよくなる。しまっておいたディスクの方が湿気がこもり、カビが発生したのである。おそらく高い性能を要求される3.5インチディスクには、表面の性質をよくするためのさまざまな有機物が塗布されているのだろう。私はあわててディスクをしまってある箱に、ありったけの防カビ剤を放りこんだ。
 人類学者にとってフィールドノートは命の次に大事なものだが、私にとってはフロッピーディスクも同じであった。帰国の時は、2セット同じものを作り、手持ちとアナカン(別送手荷物)と、二つの経路で持ち帰った。そのカビディスクは、手垢にまみれたまま今も私の机の上にある。データは全部ハードディスクに落としているのだが、なんとなく捨てる気にならないのである。
 帰国した直後、研究室の先輩にカビの話をしたら、少したってから、そのディスクを数枚くれないか、と言われた。彼の奥さんの兄弟がフロッピーディスクを作っている某社に勤めていて、ぜひ研究用にそのかびたディスクが欲しいと言っているそうなのだ。3枚ほど進呈すると、お礼に10枚の新しいディスクをくれた。カビでフロッピーが釣れたわけである。そういえば修士の頃に、爬虫類をやっている人に南西諸島からヤモリを持って帰ってあげると、お礼にワインをくれたこともあった。人類学者の役得である。

9.フィールドと肩凝り

 私はザイールのフィールドワークのかなりの時間を、コンピュータとつきあって過ごした。元来人づきあいがそれほど得意でない私は、仕事があると理由をつけて、コンピュータに向かう方を選んでしまったのだと言えなくもない。今から思えば(いや、やっている当時もそう思ってはいたが)、もうすこし積極的に外に出て人と話すべきであった。その意味では、コンピュータを持っていったことがマイナスに働いていたと言えるだろう。
 おかげで、アフリカにいてずいぶん肩が凝った。腱鞘炎や肋間神経痛にもなりかかった。ザイールまで来て何でOA症候群にならんといかんの?と何度も苦笑した。
 しかし、コンピュータを持ち込んだことが全面的に悪かったとはもちろん思っていない。コンピュータが感性を鈍らせた面もあったかもしれないが、逆にコンピュータを使ったからできた発見もあった。大量のデータを集めて分析するという手法も、コンピュータなしにはおそらくはじめる気にならなかっただろう。
 かつて、人がコンピュータに対して「コンピュータに何がわかる」と強い拒絶反応を示す場合と、「コンピュータでわかったことだから」と全面的に信じてしまう場合にはっきり二分される時代があった。しかしいま、コンピュータは人間が使う道具だ、という単純な事実があらためて認識されつつあるような気がする。コンピュータの使用がアプリオリに良い、悪い、というのは、金槌が「それで釘が打てるからよい」のか「それで人を殴れるから悪い」のかを議論するのと同様に意味のないことである。良い面も悪い面も噛み分けた「大人の関係」を、コンピュータとの間に作っていく時代なのではないかと思う。

10.ノリコ4号

 ザイールにいた当時は、遅くて画面が見にくくてフロッピーディスクしか使えないLTをなだめすかして使いながら、ハードディスクがあったらなあ、とか、広いメモリ空間が使えたらなあ、といつも思っていた。日本に帰って新しいコンピュータを買う夢を、たとえではなく本当に見たこともあった。今、私はPC-9801 NS/Tでこの原稿を書いている。この環境は、その当時の夢の世界である。
 帰国してからはLTノリコを人に売り(嫁にやったというべきか)、デスクトップの9801RAを買った。そのあと1年ケニアに行ったが、出発前にそのRAも人に売り、帰国してノート型のNSを買い、この4月にそれをまた人に売ってNS/Tを買ったのである。(こういうことをするので私は「ジンルイのわらしべ長者」と呼ばれていた。)NS/TはLTから数えて4台目なので、さしずめノリコ4号とでも呼ぶべきであろうか。私の道楽はコンピュータだけなので、さらに持ち運び用に、軽量の9801NL(ノリコ5号)も買って使っている。
 最近、フィールドにコンピュータを持っていこうと思うのだがどうしたらいいのだろう、という相談を受けることが多くなった。時代は否応無しにそうなりつつあるのだろう。将来はマルチメディアだというのがコンピュータ界のもっぱらの話題だが、もっと身近に考えなければいけないことがあるような気がする。はじめは思いつくままにデータを入力し、それをうまく変形しつつ新しい情報を抽出する、そういった「ノート代わりのコンピュータ使用」の方法論である。
 データをまとめる体系的な方法論としてすぐ思い出すのはKJ法だが、よく雑誌で見る「コンピュータでするKJ法」などという記事は、実際には役に立たないものが多い。それらが、コンピュータの特徴と弱点を考えずに、単純に紙をコンピュータに置き換えただけの発想だからだろう。
 かつてUNIXがそうして育ってきたように、コンピュータの特性を生かした「身近な情報処理」を、文化として育てていくことが必要なのではないだろうか。


追記 (Mar. 1998): その後私のコンピュータ環境は,OS/2に手を染め,TeXに走り,等々と目まぐるしく変化しました。今はIBMのThinkPad560(ノリコ何号になるかもう忘れた)上のOS/2で,秀丸を使いながらこれを書いています。VDPのバージョンアップ,pbaseの整備などはまだ果たしていません。