|
 |
 |
| ▲ゴト技top｜ 第12章 1｜ 2｜ 3｜ 4｜ 5｜ 6｜ 7｜ 8｜ |
|
| ［第12章●パーソナル“なんでも”データベースのすすめ］ 3… 経緯をまとめる |
［2003.09.11登録］［2003.09.12更新］ |
 |
|
| 石田豊 |
まとめてみよう。 以下に書くことは前回の記事とまったく同じ内容を違う観点で眺めなおしたものだ。 住所録専用ソフトでもいいし、アクセスやファイルメーカーといったデータベースソフトで作った住所録でもいいんだけど、氏名、郵便番号、住所などというように記入欄にわけられたタイプのソフトを「住所録ソフト」と呼ぶことにする。 住所録ソフトは ・欄が不足したり、余ったりする ・起動するのに時間がかかる ・入力も面倒 などの問題がある。 住所録ソフトが有効な使用法は、宛名シールを出力するとか、諸条件な組み合わせてフクザツな検索・抽出を行うということ。 ちょっと電話番号を調べたいとかのニーズの中では、どうしても使わなきゃならないというものではない。 名前や住所の一部の文字列で検索できれば、それで充分。 そこで、でてくるアイディアがジャック・レモン・メソッドというか、京大型カードのデジタル化というか。 つまり、タイトルと中身の2つのフィールドで構成されるデータベース。「中身」の方はフリーフォーマットで、何を書いてもよい。住所録として使いたいなら、住所や電話番号、ファックス番号、通称、ニックネーム、趣味、なんでも書けばよい。 こうしたシカケなら、メールの署名欄をコピペして登録することもできる。 住所録ソフトからこのデジタル京大式カードに移行することで、入力の手数が激減する他に、入れるデータが住所情報に限定されなくなるというメリットも生まれる。 個人が「覚えておきたい」データはなにも住所情報だけではない。たとえば読みたい本の書誌や、読んだ本の記録、ちょっとした統計数字のメモ、人から聞き込んだ話題など、なんでも記録することができる。 ただ、このやり方に移行しても、所詮、データベースソフトを使うことに変わりはなく、起動に時間がかかるという点では、住所録ソフトと同じだ。データベースソフトはえてして巨大で、起動にもそれなりの時間がかかる。常時起動されているようなソフトではないので、カードを書きたいと思った際にも、起動にかかる時間を思うと、かったるくてついつい後回しにするようなこともままある。後回しにすると、たいていそのまま忘れちゃう。 データベースソフトを使うもっと大きな問題点は、そのソフト固有のフォーマットでデータが構成されているということだ。そのソフトでなければ読み取ることができないから、そのソフトがなくなっちゃえば終わりだ。他のソフトで読むことは、おおむね無理と考えておいてよい。汎用性がないのだ。 データベースで扱うデータは一生モノだが、それに比べると、データフォーマットの寿命はあきらかに短い。それでも会社のデータベースだったら、問題はない。データをお守りするための人員や予算を確保しているからだ。ソフトの機能さえ大きければ、組織にとってはどーってことはない。イザとなればそそくさと乗り換えればいいのだから。 しかし、個人が自分自身のために運用するとなると、こうした「寿命の短さ」「汎用性のなさ」は致命的だ。 現実問題として、パソコンソフトの業界は、黎明期を脱し安定期に入ってきたと考えられる。黎明期にあっては、非常にアナーキーというか、シロウトくさいというか、あまたの製品がうたかたのように生まれては消えていったが、今は、そんなことは少なくなった。少なくともアクセスやファイルメーカーといった人口に膾炙したソフトを使っている以上、「ある日とつぜん消えてなくなる」というような危険は小さくなってきたことは事実だと思う。現にこの2ソフトとも、発売以来すでに10年以上が経過している。10年も続くソフトは、これまでは非常にマレだった。こういった「地位を確立したソフト」を使っている限りは、急になくなるとか読めなくなるという危険は、事実上きわめて小さいということは認めてもいい。 でもなあ。 私はこれまで何度も痛い目にあっている。過去に作成したデータが、アプリケーションが無くなっていたり、バージョンがあまりにも変わっていたりして読めなくなっているのに気がつき、大慌てに慌てるなんてことは何度もあった。私企業が作るアプリの継続性なんか、信用しちゃいないのだ。 特定のソフトのデータフォーマットに強く依存してしまうのはまずいという「理念的潜在的危険性」の認識と、常時たちあげておくようなアプリでないことから起動に時間がかかるのがウザいという「運用時隔靴掻痒感」から、このデジタル京大式カードもけっして最強のシステムとは言い難いのだった。 その煩悶から、私が次に思いついたのは「テキストデータベース」と勝手に命名した方法だった。 デジタル京大式カードは、データベースソフトを使用するため、書き込んだり検索したりする際に、わざわざそのソフトを起動しなくちゃならない。それがめっぽう面倒だ。だったら、いつも起動しているソフトでなんとかならんか。それが発想の元だった。 主たる業務である原稿を書く時だけではなく、メールの下書き、メモ・資料作成、WebサイトのHTMLファイル編輯など、なんでもかんでもテキストエディタを使っている。私の環境ではテキストエディタは常時起動しているソフトのひとつだ。 テキストエディタとは、ざっくり言ってしまうと「簡易ワープロソフト」だ。マイクロソフト・ワードなどのワープロソフトは、文書の整形などの多彩な表現力を持つ。たとえば絵を組み込むとか、文字を中央揃えにするとか、ヘッダ・フッタを付けるとか。つまり「ワード」（ことば）を「プロセス」（生成）するソフトでは、もはやなくなっており、いわば「ドキュメントプロセッサー」になっている。 それはそれでいいことなんだけど、そのため、非常に重いソフトになってしまった。起動にも文書のハンドリングにも時間がかかる。原稿書きにはワープロで実現できる装飾は、害こそあれ、メリットはほとんどない。であるので、原稿のデジタルでの授受はプレーンなテキストファイル（10章参照※まだ書いてません）で行うのが業界の基本ルールである。プレーンテキストを作成するには、なにも重いワープロソフトを使う必要はない。そこでテキストエディタを常用する。 私はWindowsではK2Editor（フリーウエア）、MacではJEdit（シェアウエア）を使っている。どちらも正規表現での検索（置換を含む）ができるからだ。JEditはずいぶん前にお金を払ったことから継続して使用しているのであるが、フリーという点ではmiがいいと思う。 テキストデータベースは、デジタル京大型カードをテキストエディタを使って実現するという考え方だ。カードに記入したい事項をデータベースソフトで作成したデジタル京大式カードではなく、テキストエディタで作成したファイルに書き込むだけ。 ルールは単純で、1情報（つまり1カード）はかならず1行で書くということ。行頭に日付を書き込んでおくということ。それだけ。 検索・抽出はエディタの検索機能もしくは検索専門のソフトで行う。 複数のテキストファイルから指定した文字列を含む「行」を抜き出すソフトはいくつもある。またAWKやPERLといった言語を使っても、それは簡単（使い方を覚えなきゃならんが）に実現できる。 テキストデータベースに移行したことで、起動にかかる隔靴掻痒感はなくなった。テキストエディタは常時起動しているからだ。 検索もPERLを使うと、そこいらのデータベースソフト真っ青のスピードだ。 私は、この方法を95年から数年間愛用していたし、前にも書いたように、この方法を単行本や雑誌記事の中で人さまにお勧めもした。少数ではあるものの、この方法を気に入っていただき、いまだに常用していただいている方もある。最近になっても「使ってますよ」という報告メールをいただくほどだ。 しかし、言い出しっぺが裏切るのもナンなんだけど、私は現在この方法を使っていない。 欠点があるのだ。 すべてがテキストデータベースに集約できないでいた。 シゴトでの必要に迫られて、もしくは個人的な好奇心から、いろんなことを調べる。たとえば旧暦に関する記事を書かなきゃならないとする。当然、旧暦に関しての調査を行う。昨今はWebだけでもいろんなことがわかっちゃうので、非常にラクになった。この調査の過程で、いろんなことを知る。そのままじゃ忘れてしまうので、当然、メモを取る。有用な記事の梗概とそのURLなど。 こうして調べた情報は、経験上、そのシゴトが完了した後になっても有用である場合が多い。何ヶ月、何年か後に再び必要になる場合が少なくないのだ。だから、ホントはこういうのもテキストデータベースに登録しておかなきゃならない。 でも、やってなかったんですね。 必要に迫られて作成した「旧暦関連有用サイトURL集」は、ひとつの独立したテキストファイルになってしまう。また「取材メモ」なんかも独立したファイルになっちゃう。テキストデータベースに一元化できないのだ。 数ヶ月たつと、そんなこと忘れちゃうから、いろんなところをひっくり返して探さなきゃならなくなる。 またテキスト化しにくい情報とか、1行では表現しづらい情報（たとえば表とか）もある。 情報の集約化を目指したはずなんだけど、思うようにいかなかったわけだ。 そうこうしているうちに、OSがMac OS Xになった。検索時に愛用していた「ファイル検索犬ポチ」（ソフト名です）もMacPerlもテンでは動作しない。本質的な問題ではないのだが（別の方法があるので）、作業能率はがた落ち。困った。 こうした事情から、テキストデータベースに関するモチベーションはどんどん低下してしまった。そんな頃にバックアップ時の事故をおこしてしまった。 これが「gura」と（これまた勝手に名付けた）「個人情報なんでもデータベースシステム」をでっち上げるまでの経緯である。 こうした哀しい経緯をふまえて、私はguraを作った。昨年のことだ。 |
|
|
この記事は
|
お読みになっての印象を5段階評価のボタンを選び「投票」ボタンをクリックしてください。 |
|
|
投票の集計 |
投票［ 15 ］人、平均面白度［ 4.3 ］ ※「投票」は24時間以内に反映されます※ |
|
|
大富亮さんより ［2003.09.12］ |
毎回楽しみに拝読しています 自分が物を書くために（こういう仕事です：http://www9.ocn.ne.jp/~kafkas/）、手元にあるファイルメーカーproを活用できないか、いろいろ試した時期があるのですが、過去記事データベースを作るのも、これまで収集したデータをデータベースにするのも、結局挫折しました。記憶のほうがあてになるからです。人から話を聞いた時に、「これはどこかで聞いたことのある話だ！」というひらめきがあると、1つの事実に対するクロスリファレンスは、その時点でほとんどできたようなものです。あとは「どこかで読んだ」が記録になっていればいいのですが、その程度の文献メモならば、年間５冊ほど費やす手書きの日記の中に押し込むことにしています。 私の場合は利益を度外視してＷｅｂで情報を発信しているのですが、このサイト自体、メモというか、一種のデータベースのようにつかっています。ですから、かなり断片的な情報も貼り付けてしまいます。何年何月、ある軍人が某所にいた、といった、役に立つかわからないこともサイトに書き込んでいます。年表や個人別情報に追加していくことで、あとあと資産になります。こういう形でのデータベースができるのは、「読者がいる」という緊張感ゆえと思います。サイト以外でのデジタル情報集積の努力というのは全部挫折していますから、大事な情報はやっぱりプリントアウトするしかないかな・・・というのが今のところの考えです。 しいてデジタル情報収集の努力をあげると、収集したデジタルテキストの情報は、ほとんどメールで管理するようになりました。テキストと、ＵＲＬを本文に貼り込み、適切なタイトルをつけて自分宛てに送ります。常時立ち上がっているのはメールソフトですから、こういうふうに格納しておけば検索も簡単ですし、めったになくなりません。 ＿＿＿＿ ありがとうございました。「読者がいるうえの緊張感」は理解でき、納得できます。また“自己宛メールを備忘DBとして使う”は実践されているかたが多いようです。わたしもスケジュール系の備忘事項は自己宛メールで管理しています。（石田） |
|
|
ご意見をお聞かせください |
|
|
| ←デジタル／シゴト／技術topへもどる | page top ↑ |
| ▲ゴト技top｜ 第12章 1｜ 2｜ 3｜ 4｜ 5｜ 6｜ 7｜ 8｜ |
|