2007-11-08

_ 知識、知恵、静的、動的、インスタンス化

かなーりメタな話を書いてみる。

私は随分昔からHOWTO批判を繰り広げてきたが、 それを抽象レベルで一体どうしてなのかを考えてみた。

人間の脳味噌には構造的・機能的に多くの限界が存在する。 ここんところは、コンピュータと大差ない。 頻繁に問題になるのは、速度と容量である。 人間が考えられる速度はそう大したものではないし、 覚えていられる事柄についても量についても、 相当な限界がある。

記憶には短期記憶と長期記憶があることがよく知られていて、 一般的に、短期記憶は容量が小さく、すぐ忘れる代わりに、 アクセスは早い。 長期記憶は忘れにくく、容量もかなり大きめなようだが、 アクセスは遅いし、リンクが辿りにくいようだ。

しかも、人間の記憶力に相当深刻な欠陥があって、 本人はちゃんと覚えたつもりでも消失してしまうし、 もっと悪いことに、覚えた時と思い出した時で内容に一貫性がまるで保証されていない。 この失敗の確率はコンピュータの比ではない。 もちろん、認識レベルでの間違いってやつも当然あって、 記憶される以前に誤認されていることも多いのだが、 そこんところはコンピュータとあまり変わらないと言えるだろう。

しかし、必要な、あるいは、有用な情報量はすさまじい分量だ。 そこで人間の限界や嫌な特性を乗り越えるため、 さまざまな技術が、コンピュータ上であれ、生活の知恵みたいなものであれ、発展を遂げてきたわけである。

例えば、大量の文書に対処するという問題が考えられる。 ありとあらゆるデータは、少なくとも原理的には、文書化が可能なはずなので、単純にデータと言い替えてもよい。

これに対応する方法論には、私の思うところでは、基本的に二つの手法しか存在しない。 一つは、分類法である。 フラットな分類と階層化された分類が考えられるが、 いずれにしても、文書を何らかの概念に基づいてクラスタリングしてしまおうってわけである。 そうすると、一度に捉えなければならない数を著しく減少させることができるので、人間でも対処できるようになる。 一説によると、人間の「理解」とは「分類すること」であるとか、何とか。

もう一つは、キーワードを用いる方法である。 それぞれの文書にキーワードを単数または複数割り当てておき、 キーワードでクラスタリングを行う。 これのある意味極端な応用例が全文検索である。 全文検索とは、文書に表れる文字列(の一部)を片っ端からキーワード化することに他ならない。 キーワードの数が増えすぎるので、当然人間には全文検索方式は向いていないが、コンピュータを利用することである程度は克服できる。

ちなみに、理論的には、分類方式はキーワード方式の一例に過ぎない。 階層は親子関係を表現するキーワードを割り振っておけば表現できるからだ。 しかしながら、そこで必要になる計算量やアルゴリズムにはかなりの違いが生じるので、現実的な意味合いで同じだとは言えない。

さて、ここまで書いたことは静的な世界である。 つまり、すでに存在する静的データが存在していて、そこをどう探すか、 という問題だ。 コンピュータに慣れている人なら誰でも知っているように、 静的に対して、動的な概念というのも考えられるわけだ。

ものすごく極端な話をすると、 データをビット列として捉えてしまうと、 ビット列は関数で生成することができるわけだから、 比較的わずかな情報を覚えておくだけで再現することが可能である。 例えば、0208268042のような、さっぱりどう覚えていいかわからない電話番号があったとして、Pythonで書くと、

def f(x): return 3 * x + 2
v = 0
for i in xrange(5):
  v = f(v)
  print '%02d' % (v % 100)

で再現できるわけだ。 a * x + bという関数の形や初期値ゼロを無視すれば、 「3を書けて、2を足して、下二桁とってくることを五回繰り返す」 とだけ覚えればよいので、 データとしては四つの一桁の数字しかないわけである。 明らかに覚えるべきデータ量は減少している。

もちろん、こんなのは極論であって、こんな方法で電話番号を覚える人間が実在するとは信じていないが、 情報を動的に生成することも可能だと言いたいのである。 そして、実際に人間はそういうことを日常的にやっている。 それは普通、論理とか演繹とか類推とか、いろんな用語で呼ばれているが、 やっていることは動的生成なのである。

コンピュータにおける動的と静的に関する議論はストレートに人間にも当てはめることができる。 静的なものは融通が効かない、変更に弱い、しかし計算コストは低い(本当にそうかどうかは検索コストがあるので疑問視されるべきだが)。 動的なものはその反対。 必ず計算が入り込むので、オーバーヘッドが発生するのは避けがたいが、 応用がきくし、柔軟だ。

情報の変化が激しい世界においては、静的なやり方は困難を極める。 書き換えが多いからだ。 ディスクは読むより書く方が遅い。 人間の頭はもっとそうだ。 思い出すのは割合簡単だが、新たに覚えるのは大変だ。 どうせすぐに役に立たなくなることのために記憶力を費すのは、 人間の貧弱な脳味噌においては、あまりに惜しい。

だから、内容を覚えるよりも探し方を覚えろとか言われる訳である。 動的な作業が生じる代わり、圧倒的に記憶領域を節約することができる。 内容が変化しても、ほとんど影響を受けない。 この方がずっと効率がよく、優れていることは言うまでもあるまい。

というわけで、すぐ使えなくなるし、それ自体を知っていたからといって、 滅多と役にも立たないHOWTOを追いかける暇があるなら、 もっと応用のきく原理や概念や演繹能力を鍛えた方がずっといい。

と、ずっとぐだぐだ書いてきたが、実はここまではまだ前振りだったりする。 本当はHOWTOなんてもうどうでもよくって、単なるネタにすぎない。 それよりも、この「動的な脳味噌の活用」の方が本題。

いきなり、ソフトウェアの世界に限定した話になってみる。 ソフトウェアの開発の流れとは、一般に、 「設計→実装→導入→利用」である。 XPの好きな人なら「設計→テスト→実装」だとか、 いまだにウォータフォールを信じている人なら「設計→モジュール分割→実装→統合→ユーザテスト」だとか、 やれループがあるだ、やれ分岐があるだとか、いろんな声が聞こえてきそうだが、 ここではそんな細かい話は抽象化の妨げでしかないので、 無視することにする。

「実装」とは、唐突だが、「設計」のインスタンスである。 青写真の具体化に他ならない。 これは人間の「動的活動」である。 脳味噌だけの活動ではないという点において、上記の話からはみ出す部分もあるが、大部分は脳味噌の活動である。 人間の価値とは、動的生成のプロセスにこそ潜んでいる。

しかし、抽象的には、これらのあらゆる段階がインスタンス化だと言える。 「実装」はソフトウェアの存在という意味ではインスタンス化されているが、 「導入」によって、ある特定のコンピュータに存在するというインスタンスとなる。 そして、「導入」はコンピュータに入っているという点ではインスタンスだが、 実際のソフトウェアを利用した活動に反映されていないという意味で、 いまだ抽象の領域に留まっている。 これが「利用」によって、ある特定の日常活動に入り込むというインスタンス化が行われる。

実は「設計」もインスタンスである。 それの大元は、おそらく「思想」、「知性」、「概念」であり、 それらにもさらに上流が存在するのだろう。 しかしそこんところが本当に何なのかは私にはよくわからない。

先の議論にもあったように、動的なものは柔軟性があり、 変化に対応できるわけで、抽象的にはより一層大きな価値を持っている。 だから、ここで述べたものの中では、人間がどのように物事を捉え、 どのように方向性を与え、どういう演繹の仕方をするかという、 「思想」、「知性」、「概念」のレベルこそが最大価値を持つ。 こういう抽象レベルを軽視する人は、その分、損をする。

別の言い方をしてみよう。 静的なものは変えにくい。 インスタンス化の下流にあるものは動的に生成されているわけだから、 それなりのオーバーヘッドを覚悟すれば、作り直すことができる。 しかし、上が腐っていると、下は必ず腐るので、どんどん遡るしかなく、 工程が増加するので、オーバーヘッドはどんどん大きくなる。 だから、上流に行けば行くほど、その重要性は高まる。

例えば、駄目な概念で設計されたソフトウェアはどうあがいても駄目である。 駄目な設計で実装されたソフトウェアは、どんな天才ハッカーでも素晴らしいソフトウェアにはできない。 だから、実装が腐っているのは、設計が腐っていることほど重要ではないとも言える。

もっと考えていたことはたくさんあるのだが、 そろそろ書くのに疲れてきたので、この辺でやめる。 設計をインスタンス化するフレームワークがプログラミング言語であるなら、 導入や設計や思想における「プログラミング言語」とは一体何なんだろう、とか、 XPのような方法論を異なる段階に当てはめるとどうなるんだろう、とか、 下流から上流への逆方向へのフィードバックのこと、とか、 方向性が存在することにおけるSI事業者やソフトウェア利用者の役回りとその価値、 とかとか。

[]