2008-03-30

最近読んだ本: 市場を創る - バザールからネット取引まで

表紙がすてきで買ったまま積読してたのを消化. とてもおもしろかった.

帯に "教科書が教えない<市場>の原理. 新しい時代の経済学入門" とあるとおりの 経済学読み物. イメージとしては経済学の教科書から ケーススタディのところだけを集めて一冊の本にしたかんじ. オランダの花市場から始まり, 製薬市場と途上国の対決, 電波オークション, 特許と著作権, ブラックマーケット, 排出権取引...と, 市場の設計を切り口に, 経済学の話がおなかいっぱい読める. 満腹満足.

色々面白かったのだけれど, 印象的だったところをひとつ抜粋してみよう:

企業は市場経済を眺望するときにもっとも目をひく存在である. ここにパラドックスがある. 企業はある種の集権的計画によって 運営されている存在だからである. 責任はすべて最終的にトップが引き受ける. 企業内の取引は, 市場ではなく, 階層的コントロールに従っている. 企業は企業間の取引に関しては市場を用いる一方で, 企業内部の取引については意図的に市場を封じている. 計画は, 共産主義経済では 過去の遺物になっているが, 市場経済の企業においては今も盛んに行なわれているのである.

このパラドクスをどう解決するか? 本の中では市場の言葉でそれを説明しているけれども, まったく精巧なものだと思う. 大企業なんてよく潰れずやってるよね. 現代の奇跡というほかない.

<民主主義は最悪の仕組みだが, それまでのどの仕組みよりもマシ>だという チャーチルの言葉を引いたあと, 著者は締め括る.

市場システムは民主主義のようなものである. これまでそのときどきに試みられてきた すべてのものを除けば, 市場システムは最悪の形態である. 市場システムが成功するのは, まさにフォースターの民主主義に対する見方のように, それが多様性を認め, 批判を許容するからである. 市場は, 他のどのような形態の経済組織によっても解決することのできなかった, ほとんど手に負えない問題を解決しているのだから, われわれは市場システムに万歳というべきである. 市場は富を生み出し, 貧困を緩和する. しかし市場には限界があり, できないこともある. 期待されたことさえ, 必ずしもできるわけではない. 市場はうまく設計されたときにのみ, うまく機能するからである. だから 2 つの万歳で十分である.

この限定つき最悪宣言は, 市場を構成するあらゆるメカニズムにあてはまる. 企業もそうだ. 毎日朝早く(もない)から夜遅くまで拘束される最悪. 一方で自分のようなろくでなしが コードを書くだけで給料をもらい暮らしている万歳. 今と同じ生活水準で食ってく方法なんて他にわかんないよ.

こうして人類の偉業と会社員の幸せを噛み締めた一冊でした.

フレームワークと市場

さて, ソフトウェア開発の市場性について考えることがある. たとえば agile は市場主義的であり, upfront big design は計画主義的で あるだろう, とか. これは以前から感じていた. 今も考えは変わらない.

最近は, もっとコード寄りのことをよく考える. 考えはまとまっていないけれど, 当分まとまりそうもないので飽きないうちに書いておく: 市場主義的なコードとは何だろう. あるいは, コードにとって市場とは何だろう?

プラットホームという言葉がある. プラットホームはコードにとっての市場かも知れない. ただプラットホームに自体はコード以外のものも多く含んでいる. それに私はプラットホームに興味が薄い. もう少し話題を絞りたい.

フレームワークはどうだろう. <フレームワークはコードにとっての市場である>. そんな気もする. たとえば COM や EJB はコンポーネントの経済を作ろうとした. 昨今 SOA とか言ってる人々にも似たような意図があるだろう.

もう少し言葉あそびをつづけてみる. <良いフレームワークとは, 良く設計された市場のようなものである>. そんな気もする. それじゃ, 良い市場ってなに?

そもそも, フレームワークという市場の登場人物は誰だろう. 売り買いされる商品(財)はフレームワークの上で動くコードだ. コードはフレームワークに plug するモジュールかもしれないし, アプリケーションかもしれない. 買い手はコードを使うひと. アプリケーションプログラマが買い手だ. 売り手は使われるコードを書く人. モジュールを書くプログラマがそう. ただしそのモジュールが他のモジュールに依存するなら, プログラマは売り手と同時に買い手でもある.

良い市場の基準は何だろう. <市場を作る> では, 取引費用の低さ, 外部性の少なさ, 規制の少なさ, それに不正ができない信頼性などが挙げられていた. どれも市場で取引をする動機につながる. どれも trade-off がある. 簡単なことじゃない. この trade-off をのりこなす難しさと妙技が <市場を作る> の主題だった. 経済学の主題の一つと言ってもいい. (ちがったらごめん.)

取引費用の少さから考えてみよう. これはわかりやすい. あるモジュールを呼び出すのに boilerplate な初期化や設定を求めるのは取引費用が高い. 初期化しただけで使われる大量の主記憶も取引費用といえる. 文書を読む手間も取引費用だろう. 全般に, 成果に見あわない複雑さや面倒が取引費用にあたる.

つぎは外部性. たとえば, バグの切り分けがしにくいフレームワークは外部性を持つ, かもしれない. 買い手は原因究明を売り手におしつけてしまう. 良い売り手は市場から逃げだし, 檸檬だけが残る. コプロセッサへのアクセスが制限されていない数値計算フレームワーク. 個々のモジュールが資源を奪いあい, スラッシングの悲劇がおこる. ...うー. 取引費用ほどわかりやすい例はないなあ...

規制の少なさ. フレームワークはある意味で規制そのものだから, これは例に困らない. 特定の命名規則を強いる. 特定のインターフェイス実装を強いる. システムの API 呼び出しを禁止する. パラメタのないコンストラクタを強いる. ほら, いくらでもあるでしょ. けれど, 制約は少ないに越したことはない. ここには他の要件との trade-off がある.

国営モジュール

市場のメタファはフレームワークの一面でしかない. フレームワークは, 市場だけでなく売り手でもあるのが普通だ.

たとえばクロス環境のグラフィクスエンジンには, 環境の差異を隠したプリミティブな描画 API だけでなく, モデルデータのローダやちょっとしたアニメーション機能もついてくるだろう. フレームワークの開発者は, 自分の作ったクロス環境 API (市場)の上で, こうした追加機能(財)を売り込もうとしている.

SNS 用アプリケーションの抽象化フレームワークである OpenSocial も同じ. ユーザ情報へのアクセスやリモート資源へのアクセスといった 最低限の標準化以外に, 永続化や GUI のような付加機能を提供している.

フレームワークの機能が豊富なのは歓迎すべきことに思えるけれど, 市場の見方に立つとあまり嬉しくなさそうだ. フレームワークが提供する機能は, 言ってみれば国営企業のようなもの. それは健全な競争を妨げるかもしれない.

なにかが直感に反している. フレームワークに用意された負荷機能が悪, とは思えない. むしろそれを求めてフレームワークを使うのが普通だろう. 一方で, 市場としての役割と売り手としての仕事をはっきり区別しない フレームワークも多い. これはこれで気に入らない.

フレームワークに癒着したモジュールは, 税制で優遇されている国営企業や規制産業のようなものだ. 自分だけが使える秘密の権利で, 余所者の参加を妨げている. 同様に, フレームワーク付属モジュールの中には非公開の API を使い実装されているものがある. またはフレームワークの中に特定のモジュールを特別扱いするコード, if(obj.getClass().equals(SomeComponent.class)) { ... } みたいのが埋めこまれている.

フレームワーク提供のモジュールに不満があっても, それを置き換えることができない. これはとても不愉快なことだ. かつて Micosoft は Office で非公開の Windows API を使い顰蹙を買った. それと同じことが多くのフレームワークでおきている.

透明で小さなカーネル

こうした不愉快は不信につながる. 不信を避け信頼を得たいなら, フレームワークは市場としての役割と 売り手としての役割をはっきり使いわけるべきだろう. 利用者に課した制約には自身も従う. 機能追加のために増やした抜け穴は公開する. フレームワークは市場の部分で価値を埋むのではなく, その市場で交換する財によって価値を持つようにしてほしい.

市場のメタファでいうなら, 市場を運用する政府は公平かつ透明であってほしい. ついでに機能はなるべく民営化して市場に移し, 政府は小さくあってほしい. 小ささは透明性にもつながるし, ユーザは税金より代金を払いたいからね.

よくできたフレームワークの中には, マイクロカーネル的アプローチをとるものがある. 中心となるカーネルは明確なルールと最低限のサービスだけを提供する. 各種機能はその上に構築される. ここには透明で小さな政府がある.

小さな政府の実現が難しいように, マイクロカーネルの実現も難しい. 設計についてある程度意識的なプログラマなら誰でも, フレームワークの核を小さく保とうとするだろう. とはいえ不満のない形でそれを実現するのはむずかしい. アプリケーションの要件を満たそうとフレームワークが肥大化するのはよくあること. 目標に対して実力が足りないと作り手を責めるのは簡単だが, 他人事でもない. いつだって自分を責めている.

闇市場のモンキーパッチ

肥大化, 官僚化によってユーザの自由を奪ったフレームワークは 市場として失敗している. 潤沢な開発資源をもつ大企業でもない限り, 計画経済を運用することなんてできない.

そんなフレームワークを作ってしまったら, プログラマはどうすればいいだろう. ヒントは現実の市場にある.

政府に力のない国でも, 人々は闇市場を通じて生活を営んでいる. <市場を創る> では, そんな例をいくつか紹介している. 闇市場を取り締まろうとする政府もあるし, 計画経済の抜け穴を自らあける政府もある. (後者の例として中国がとりあげられていた.)

計画経済フレームワークに対する闇市場のメタファはあるだろうか.

フレームワークに "非公式な" 穴があることはよくある. 文書化されていないメソッド, リフレクションごしにしか見えない実装クラス, アーカイブ化された設定ファイル, ブートストラップのバッファ溢れ. こうした非公式の API(?) を通じてフレームワークをハックできるなら, それは闇市場の基盤になりうる.

フレームワークのコードが手に入るなら話は早い. それを改造した自家製フォークは闇市場と言えるだろう. オープンソースでなくてもコードを提供しているフレームワークは多い. そうしたフレームワークの作者は, 自分のコードが官僚的, 不透明だと自覚しているのかもしれない. コード全体を提供できないなら, 根にある市場だけを部分的に公開してもいい.

軽量言語の多くは処理系の性質としてコードが公開されてしまう. そのせいか, この分野には闇市場, ハックの歴史がある. やりくちも洗練されている.

その一例が "モンキーパッチ(monkey patch)" だ. ruby をはじめとする動的な言語の多くは, 実行時にクラスを書き換えることができる. おかげで本体のソースをいじらず挙動だけを変更できる. この仕組みを使う変更をモンキーパッチと呼ぶ. モンキーパッチは処理系という市場にあいた闇市場への入口だ.

Rails の plugin は積極的にモンキーパッチをあてる. (The Virtues of Monkey Patching など参照.) もはやイディオムと言ってもいい. Rails はフルスタックのフレームワークで, マイクロカーネルとは言い難い. けれどコミュニティのもつ闇市場の文化が官僚性を飼い馴らした...のかもしれない. フレームワークと闇市場の関係について, Rails から学ぶところは多いと思う.

理想と保険

モンキーパッチがフレームワークに対する銀の弾丸になるとは思えない. モンキーパッチは既存のコードを不安定にする. ウェブをみても議論には賛否がある. この議論は闇市場を巡る葛藤の双子に見える. ユーザは賄賂のはびこる市場を望まない. そう先に書いたばかりだ.

フレームワークの中には, 何でも差し替えられりゃ良いんだろとばかりに 山のようなフックを用意しているものがある. これは理想と必要悪を履き違えている. その典型が AOP だ...なんていうと刺されそうですね. AOP はさておき, フックをつくる前に市場と売り手の役割分担をよく考えて欲しい. フックをつくるのは市場の失敗に供えた保険にすぎない. 保険をかけるだけでなく, 良い市場を作ることに知恵を使おう. 賄賂と抜け穴のある政府をつくるより不完全な売り手でいる方が, 市場はよく働いてくれるよ. きっと.

まとめ

うう. やっぱりまとまりのない考えを書くと無駄に長くなる. ごめん. といいつつまとめ:

ついでに書こうと思ったけど収まりが悪くてやめた話を言い逃げしとこう:

そういえばプログラマは経済学を勉強しとけって Joel も言ってた ね:D