micro* (1): microな考え方／やり方
本編「micro* (1): microな考え方／やり方」のコピー。
microformatsが、どうして"micro"という言葉を選んだのか、どうも腑に落ちない感じがしました。（だって、Microsoftだってmicroだし。）
武田の近況報告「Microformats (とSemantic Web）」とAmazon Web サービス ブログ「Microformats 運動」を引用してみます。なお、ブラケット内は僕が挿入したものです。
そもそも[なぜ]Microなのかというと，既存の大量な詳細なドキュメントで規定される人間が読むことができないようなフォーマット("megaformat!")に対して，format自身も小さいし，簡単に理解できるようなフォーマットだから，ということでしょう．
Microformats運動は、必ずしも新しい形式を作るのではなく、現在動いている既存の方法にほんの少し手を加えて、多くの人が共通に悩んでいる問題にシンプルな解を提供し、かつそれによって今動いている仕組みには最小限の影響しか与えないことを目指しています。
大げさ大規模ではない、少ない手間でそれなりの効果を得る、変更を最小化する、というようなところがマイクロ（極小、微少／微小）なんでしょうかね。
で、言葉自体の詮索＜せんさく＞はやめて、microという形容詞を「microformatsの意味におけるmicro」だと解釈すると、その背後には、なにかmicro主義とか、microの哲学とでも呼ぶような発想があるような気がします。もっとも、「主義」とか「哲学」という大仰＜おおぎょう＞な言葉はmicroじゃないので、“microな考え方／やり方”と呼んでおきましょう。
「Microformats (とSemantic Web）」から再び引用します：
推進しているご当人のよると，microformatsの基本理念とは
- 特定の問題を解け
- できるだけ簡単に...発展的な改良
- 人が先,機械は後... 表示可能で処理可能，現状のやり方に合わせろ
- いまあるスタンダードを使いまわせ... semantic (X)HTML, RFC
- モジュラリティと埋め込み可能性
だそうです
これは、ソフトウェアツールズ、したがってパイプ＆フィルターに通じるものを感じます。ソフトウェアツールズ的発想は、新しいプログラムはできるだけ書かずに、ひとつのことを上手にこなす小さな既存ツールを組み合わせろ、ってことですから。
実際の個別format仕様（hCard, hReviewなど）を見ると、ショボイ感じがするのですが、そのショボサがmicroさであり、メリットにつながっているようです。つまり、誰でも短時間で理解できて、今すぐそれで何かをできる、ということ。
僕は、基礎から作り直すアプローチも嫌いではない（いや、好きかな）けど、基盤整備に時間がかかって「いつになったら、やりたいことができるんだよー」というイライラ感も理解できるし、自分もイライラしたりしますから、microな（あるいはminiな）アプローチの必要性もけっこう切実に感じます。
僕自身のバイアスを入れて、microな考え方／やり方をまとめれば、まずは、単純（simple）、軽量（lightweight）、枯れた既存技術の（新しい）組み合わせ（a (new) combination of mature technologies）であること；この特徴は分かりやすいでしょ。
それと、非制限的（nonrestrictive）って条件が入るかな；非制限的とは、そのアーキテクチャやフレームワーク全体の使用を強要しないってことです。all or nothingみたいなことではなくて、利用したい人は一部分だけを選んで使ってもよいし、それでもちゃんと役に立つ、と。その技術や手法の体系内にロックインしないということです。
microな方法は、短期的な解決策である可能性が高いから、ロックインしたりしたらダメです。そして、現状うまくいっているものにインパクトを与えてもまずい。今の不便さを解消して、何かをできるようにする（enabling）けど、囲い込み（encompassing）はしないようなやり方。
このような考え方／やり方をmicroなんだと捉えれば、formats以外にも適用が可能なんじゃないでしょうか。それで、ワイルドカードのつもりのスターを付けてmicro*って見出しを付けたのです。… 続くかもしれない。
