ised議事録

02-129. 設計研第2回: 共同討議 第2部(2)

D2:共同討議 第2部
(開催:2005年2月12日 国際大学GLOCOM / 議事録公開:2005年4月9日)

「人文系オープンソース」としてのはてなと、メタレベルの再定義可能性

鈴木健

 なぜ僕が生産プロセスの可視化ということを言うのかというと、実際、会社の現場でものづくりする際に一番のボトルネックになるのは経験上コミュニケーションコストだからなんですね。たとえば会社で小さい5人のチームが10個あって、トータル50人体制だとします。すると、その小さなチーム間でも情報交流ができなくなる。そこで全社会議に研究会や勉強会をやることになるんですが、こうしたナレッジ・マネジメントは重要視しているところも多いですし、よく試みられるけれども、だいたい失敗することが多いんです。やはり、日々の業務で忙しいところに、新人がプロジェクトに入くればナレッジ・トランスファーをしなくてはいけない。新人にこういうアイデアはどう思うと聞いてみないといけないというのは、非常にコストになるわけです。

 しかしオープンソースに関わる人々は、ある意味でこうしたコミュニケーションコストを普段から受け入れている。それはなぜ可能なのかが興味深い。

 こうしたオープンソース的なものを企業として実現しているのが、はてなだと思うんです。僕としては、はてながユーザーとのコミュニケーションコストを会社としてどう捉えているのかをお聞きしたいんですね。それがもし敷衍できれば、他の分野にも応用できると思うんですよ。

東浩紀(以下、東):

 おお、司会者のようなすばらしいパスだ(笑)。ありがとうございます。では、近藤さんお願いします。

近藤淳也(以下、近藤):

近藤淳也
近藤淳也

 はい、僕も今日の話を伺いながら、はてなのコミュニティというのはすごくオープンソース的だと思ったんですね。はてなオープンソース的だとするならば、いったいどこがそうで、それを規定している要因はなにかについてお話したいと思うんです。

 まずどこがオープンソース的なのかといえば、ユーザーの参加性です。たとえばはてなのユーザーからの機能要望や、動作のおかしいところのご指摘といったものが数多く寄せられるのですが、はてなの側でも、それをなるべく多く早く採用しているんですね。ここにユーザーのはてなへの帰属意識や所有意識が非常に強いという、前回の設計研でも出てきた部分とが関係しているんだと思うんです。

 ただ本来のオープンソースとの対比で考えてみたのですが、基本的にはてなソースコードというのは公開されていないわけです。公開されていないけれども、たくさんの人がコミットしているのはどこかといえば、その機能やアイデアの部分なんですね。つまり、「人文系オープンソース」をはてなはやっているんだと思うんです。たとえば脆弱性の発見はコードを知らなくてもできるという話とよく似ている。

 同時に「人文系バグ」とでも呼べるものがはてなには多いんです。たとえば規約上ではグレーな部分があって、たとえばはてなダイアリーにはキーワード機能というものがありますが、そのキーワードはなるべくこう使って頂きたいということは申し上げていても、あやふやなグレーゾーンも多いんです。たとえば差別行為は禁止という規約がありますが、どこまでが差別でそうでないかの線引きはグレーなところが大きい。それに気づいたユーザーには、「いったいこういうキーワード作ってみたらどうなるかやってみよう、許されるのかどうか試そう」と実践される人がすごく多いんです。ただ、僕としては彼らを「規約の違反者」だとは思っていなくて、むしろ「人文的なハッカー」だと思うんですね。つまり、グレーゾーンを潰していくというデバッグ作業をしてくれていると考えているんです。

 ほかにも、はてなでは目標の設定をそれほど明確には置いていないという点も共通点かと思います。たとえば、はてなダイアリーキーワードの目的は「百科事典をみんなで作りましょう」といった明言はあえてしていません。基本的に、ユーザーのほうで何度でも再定義できる自由を持たせているんです。あとはその離脱可能性の確保もそうですね。はてなを止めて、よく似た他社のサービスにいくことはもちろん自由です。こういった点において、はてなオープンソースと類似しているのではないかと思います。

 ただ、違う点もあります。たとえばコピーレフト的なライセンス契約はいま存在していませんし、ソースコード自体は公開されていないわけです。それでは、いったいなにがはてなオープンソース的にしているのかというと、個人的に大事だと思うのは、変更していく方法それ自体が公開されていることです。つまり、自分がこういう要望を出すと、運営側にこういうふうに受け入れられ、実際にこのように変わっていくというそのプロセスが開示されているという意味においてです。オープンソースのほうでも、プログラムソースをオープンにし、誰でもいじれるようにすることは確かに重要だったかもしれません。そして企業が作った商業の大規模システムに対抗するというモチベーションがそれを支えたかもしれない。しかし、本質的なのは変更方法がオープンであるということではないかと感じています。

近藤淳也

 そこで僕自身はオープンソースをこう理解しているんです。結局インターネットを使えば、どこにいても簡単にコミュニティができるので、せっかくだからみんなで面白いことをするための方法論かなという気がしています。そして、みんな大勢で面白いことをするのはいいけれども、これだけは守りましょうといういくつかの約束事があるわけですね。たとえば「お互いの意見はちゃんとききましょう」というのは多様性の確保ですし、「変更の方法は守りましょう」「秘密をやめましょう」というのは可視化ですね。そして「出来たものを独り占めするのはやめましょう」というルールがあって、「いやならいつでも抜けられる」という離脱の自由が確保されている、と。かなり単純化した理解ではありますが。

石橋啓一郎(以下、石橋):

 いま変更のルールを公開されているというお話が出たんですが、その変更は頻繁に行われているんでしょうか。

近藤:

 そうですね。たとえばはてなダイアリーでは、新機能や機能変更という要望を受けるフローはどんどん変わっているのですが、初めからその流れをシステム化しているものは少ないですね。

石橋:

 なるほど。さきほど東さんが、情報社会においてはメタレベルで常に再定義がなされるという話をされていたんですが、それを横糸に議論をつなげられると思うんです。

 前回僕はIETFの話をしながら場の設計という議論をしたのですが、IETFでは個別のワーキンググループが数多く存在し、標準化のプロセスが走っていました。それは時とともに劇的に変化したのですが、やはり再定義可能性が非常に強く働いた結果だと思うんです。オープンソースはてなも同じことが言えるのではないか。

 そこで、前回の設計研のキーワードとして全体最適部分最適の話がありました。部分最適というのは個別のプロジェクトたちがルールに従って自律的に走っていくプロセスだとして、そこにメタレベルでの再定義はどのように入ってくるのでしょうか。おそらく、現場で起きている問題を横に比べるといった情報交換が起こっていて、それが再定義のプロセスになっていると思うんですよ。IETFの場合も、エリアディレクターは自分たちのプロジェクトだけを見ているのではなく、他のプロジェクトとの比較検討と情報交換をするわけです。

 つまり全体最適は起こっていないけれども、部分最適を志向する各プロジェクトのあいだをつなぐ機能を、再定義プロセスは果たしているんじゃないかなと思うんですね。

(左から)近藤淳也東浩紀

東:

 なるほど……。いまのは含蓄の深い指摘だと思います。

 ここまでの議論を整理しますと、まず、ある環境の規則がつねに再定義可能である、それが情報社会、というか情報技術に依存した社会秩序の特徴である。そして、オープンソースはてなのような、「みんなで楽しいことをする」というモチベーションで動くコミュニティでは、その再定義の過程を、可視化し共有することでうまく管理することができる。また村上さんが指摘されたように、既存の企業においても、現場の開発ではそのような新しい組織モデルの適用が始まっている。

 しかし、その成功は成功として認めるとしても、社会すべてがそのようなモデルで動くだろうか。この部分で、微妙に意見が分かれているように思うんです。つまりは、オープンソース型の組織モデルは、特殊な条件に縛られた局所的なものにすぎないのか、それとも、今後の環境管理型社会において普遍的に適用可能なものなのか。そのように議論の軸が作られてきたのですが、いまの石橋さんの指摘は、そもそも全体最適部分最適を対立させるのが間違っているのであって、無数の盲目的な部分最適のあいだを相互調整する機能こそが「メタレベルの再定義可能性」なのではないか、ということですね。

 この指摘については、これからも引き続き考えていきたいと思います。ところで、そのまえに、鈴木謙介さんが社会学的観点からまた別の議論を提起してくれるということですので、お願いします。





sughimsisughimsi2005/04/10 10:59左右反対ではないですか?

isedised2005/04/10 21:25ご指摘ありがとうございます、修正しました。

トラックバック - http://ised-glocom.g.hatena.ne.jp/ised/04090212