私のコンピューター史 2

 東京語アクセント資料では国研の大型計算機にすべてのデータを入れてデータベース化をしたが、これが使えなくなったときにPCで使えるようにデータを移行させるのに失敗してしまった。これにはいろいろな歴史があり、ここでは書き切れないのだが、一つだけ言わせてもらえば、当時のPCではハード的にとても容量が足りなかったし、MSDOSの時代だったのでデータベース化するためのソフトもなかった。これが30年後に国研(当時)の三井はるみさんの手でエクセルのデータとしてよみがえったのには感激した。エクセルがこの巨大なデータを受け入れたことにもハードとソフトの進歩を感じた。
 ただし、東京語アクセント資料については2017年に国研で行われたMETHODSで鑓水さんを加えた三名で発表をしたきりである。proceedingsには書かせてもらったが、いずれ包括的な研究をまとめたいと思っている。あれだけのデータ量のアクセント調査はあとにも先にもない。相澤正夫さんの詳細な研究はあるが、コンピューターならではの分析による研究はまだ十分ではない。
 GAJのデータをデータベースにするべく、1985年ごろから予算をとって入力作業をしていたが、前にも述べたハードソフトの制約から私が国研を去る1990年までにデータベースを実現することはできなかった。しかし、そのデータを使って資料一覧を印刷することができ、2010年ごろ(私の記憶による。もっと前だったかもしれない。)に大西拓一郎さんの手でウェブ上に公開され、さらにはユニコードによるIPAの表示も行われた。表現法のような複雑なものは地図化するよりはデータのままのほうが後の人が利用しやすいので、データの公開はとてもありがたい。1980年代はインターネットが存在していないわけではないが、一般の人間にとってはないも同じだった。また、ユニコードが一般化するのも2010年前後だったように思う。
 徳之島方言のコーパスを作る作業については当ブログの「『徳之島二千文』からKWICを作る」で述べていて、続きを書く予定なのでここでは省く。
 私の言語地図の孤例の研究は「『日本言語地図』の語形の数量的性質」(『方言研究法の探索』)(1988)に始まっている。言語地図の「孤例」はもともとは徳川宗賢さんが提唱した(「言語地図における孤例」(『ことばの研究 第4集』)1973)概念である。
1987年にこの研究を始めたときはLAJのなかからいくつかの項目を選んでデータ化したものをもとに孤例を見つけるということをした。最初は国研の大型計算機を使ったのだが、同じことが自分の持っているPCでもできるということを発見した。MSDOSの時代だったが、大型計算機とごく普通のPCが能力的にほとんど拮抗していることに驚かされた。
 2013年には「孤例についての諸問題」(『大規模データの多角的分析 成果報告書ー言語地図と方言談話資料ー』国立国語研究所共同研究報告12-05)を書いた。これは熊谷康雄さんが作成中のLAJDBを利用したもので、LAJの項目の大部分をデータとして使った。孤例の概念を発展させて「n例」というものを考えた。「3例」「2例」となった先に孤例があるというものだ。使ったプログラム言語はawkである。
 孤例の研究についてはもう一度LAJのデータを使ってまとまったものを書いてみたいと考えている。今までは「どうして孤例が存在するのか」「孤例にはどんな意味があるか」について述べていないが、語形の伝播の過程で孤例が生じることをうまく説明できるかもしれない。もしそれができたら孤例を論じることに大きな意味があることになる。
 孤例からちょっと離れるが、2020年に「LAJにおける同音衝突 プログラムとデータ」(『語史再構における言語地理学的解釈の再検討ー類型的定式化の試み』科研費研究成果報告書)を書いた。VBAを使ってLAJDBに入っているすべての項目(LAJの項目の大部分)のデータの一部(項目名、語形、地点番号)を読み込み、そのままソートした。どれぐらいの大きさのデータかというと全部で300万要素よりは少ないがそれに近いぐらいである。一つ一つの要素は文字列で平均の長さが10とすると3000万バイトのメモリーを使うことになる。プログラム言語はVBAだった。
 私自身は32Kバイトの内部メモリーのPCから出発した貧乏性なのでこれほど大きなデータをまるまる飲み込んで処理することができるようになったことにただ驚くばかりである。3000万というのは30メガなので本当はこれくらいで驚いてはいけないのだ。今のPCは内部メモリー8ギガバイトが当たり前である。ハード・ソフト両面での進歩はすばらしい。
 このプログラムでやっているのは沢山の項目をまとめてソートし、同じ語形が異なる項目で出現したケースを拾い出すことなのだが、ソートのやり方を変えれば孤例の検出もできる。今までの孤例のための技巧的で複雑なプログラミングを単純化できるのだ。
 このプログラムと同じことを人手ですることもできる。各項目のエクセルのデータを根気よくコピーして巨大なエクセルのファイルを作り、これをソートするのだ。200項目弱のエクセルファイルを扱う、気が遠くなるくらい手間がかかる作業だが、やってできないことはない。問題は人手の作業には必ず間違い(入力・編集のエラー)が混入することだ。これだけ大量の手間がかかることであれば、全く間違えないほうが難しい。しかも同じ項目のデータを2回コピーしてしまうとか、逆にある項目をコピーし忘れるようなことをすると全体が台無しになる。
 プログラムを使えば、データの入手からソートまでをすべて人手を介さずに行うことになる。プログラムが間違っていなければ完全に正確に作業することができる。
 エクセルの作業の自動化のためにRPAと呼ばれるソフトがあるが、これは企業向けのもので、当然コストが発生する。研究者向けとは思えない。
 VBAのプログラムは一度誰かが正しく動作するものを作っておけば、後の人はそれをアレンジして使うことができる。そのためにもプログラミングが研究者の間にも普及してほしい。

私が継続して研究しているテーマは最初期のころのPCでは満足にできないものだった。一度に扱えるデータ量が限定されているとしたら、プログラミングを工夫するしかない。今はハード・ソフトの進歩で非常に快適に作業ができる。30数年前はいかにプログラムの実行時間を短くするかを必死に考えていたが、ハードの性能が最初期の何万倍にもなった今、特に速いアルゴリズムでなくても十分速く処理ができる。むしろ発想をがらっと変えて、ハードの性能を活かした単純で分かりやすいプログラミングのほうが望まれる。
扱っているデータは東京語アクセント資料にしてもLAJにしてもデータ量が非常に大きいが、そのためにいまだに新しい見方や新しい切り口が見つかって研究に終わりがない。

コメントする

メールアドレスが公開されることはありません。 が付いている欄は必須項目です