ised議事録

12-125.設計研第1回: 共同討議 第1部(3)

D1:共同討議 第1部
(開催:2004年12月12日 国際大学GLOCOM/ 議事録公開:2005年2月11日)

全体最適か、部分最適

東浩紀(以下、東):

 オープンソースとはメタライセンスなのだ、というきわめて含蓄の深い議論が出てきました。ライセンスをたえずメタ化しようとする運動こそが、オープンソースの開放性を支えていた、というのは、ほかの組織運営にも応用できそうです。

 ところで、ここで株式会社はてなの近藤さんにもお話を伺いたいと思います。近藤さんが運営されているはてなの日記サービスは、まさにプロシューマー的なユーザのコミュニケーションの場を提供しているものだと思うんですね。近藤さんもまた、村上さんや八田さんとは異なった意味での場の設計の実践者なわけでが、ここまでの議論を聞いてどのような考えを抱かれましたか?

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

 はてなに引きつけて考えるとき、これは大きい要素だなと思ったのは、石橋さんのプレゼンテーションの最後に出てきた設計者と利用者の関係を描いたこの図でした。

図:産業社会と情報社会の設計
D1:図8

 左の従来型の組織においては、この図には描かれていませんが、その設計者の向こう側に資本をもっているステークホルダーがいるわけですね。そしていま右のモデルが本当に廻っているとするなら、それはステークホルダーのものであるという感覚が薄いからだと思うんです。つまり大規模なネットコミュニティの多くの基本的な運営母体は「会社」ですが、じっくりと付き合い育ててきたコミュニティに対して、「これは自分たちのものである」というコミットメントをもつようになります。はてな以外にも、いま現実的にネットのコミュニティで栄えているいくつかのコミュニティというのは、案外そういう仕組みで運営されているところが多いのではないでしょうか。

近藤淳也
D1:近藤淳也

 また、実際ネットコミュニティを作っていると方々とお話する機会をもつのですが、今日のお話に出てきたような設計をするときの概念や定義というものについては、自分も含めてかなり「無自覚」にやっていると思います。ただ「それがなぜ許されているのか」と考えたんです。というのもやはり、ネットコミュニティは車などと比べて、人の安全性というものに対する危険度が全然違うわけですね。要するにネットコミュニティでは、設計者の意図の範囲で人を生死に関わる危険にさらすということは難しい。具体的にネットの世界のどういうところにその現れているかと思うと、たとえばインフォメーション・アーキテクト*1といった肩書きをもつ方々がこの世界にはいますが、どちらかというと芸術系の大学を出た方々が多いんですね。一方で建築家というのは生死にも関わる設計ですから、ソフトウェアと比べてより工学的なものが非常に要求されているということにも現れているのではないかという印象をもっていました。

 また「無自覚」ということで続けてお話しますが、たとえば自分からはよく、はてなダイアリーというブログのコミュニティについて、「オープンカフェのような場所です」と説明させていただくことがありまして、確かにこれがインターネットそもそもの設計に近い考え方なのかもしれません。しかし、それがはてなダイアリーの「一般化」の阻害になっていると思うことがあります。

 たとえばブログなりダイアリーなりのアーキテクチャを世界中に広めたいのであれば、まずそれを概念的に可視化するプロセスといわれるものがあり、様々な方々とのやりとりを通じて淘汰・洗練していくということになるでしょう。しかし現実には、そのような自覚的な可視化や一般化をすることはほとんどありません。実際の現場で日々のコミュニティとの付き合いを通しながら、自分たちの感覚によって設計しているのが現状なんです。

東:

 なるほど、むしろネットコミュニティの運営の現場においては、村上さんのいう「リーダーシップとオーナーシップの分離」がなされていないということですね。つまり分離がなされていない設計者と利用者の接近した場所では「特殊化」への志向性が強く働いている。

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

石橋啓一郎
D1:石橋啓一郎

 そこで付け加えたいのが、僕は最近「地域情報化」のお仕事を中心にやらせていただいている文脈*2で、その最新事例についてなんですね。そこでも事情が似通っていて、リーダーシップとオーナーシップの分離は行われていないケースがむしろ多かったんです。しかし最近、非常にうまく行っているケースがあると、「ぜひその方法をコピーさせてくれ、うちも同じやり方で地域活性化に取り組みたいんだ」という具合に、よそから経営ノウハウとしての設計情報(これをリーダーシップ、とここで仮に分類するとします)を借りて、所有先(オーナーシップ)を移していく、という横展開現象が起きているんですね。

 それが起こるのはなぜかを考えると、(現実に中小企業における所有と経営の分離が難しいように、)地域というコミュニティが小さいからかもしれない。つまり単純に規模の問題だということです。たとえば、さきほど村上さんがおっしゃったケースというのは千人や二千人ではきかない、かなり大規模な組織のマネジメントを前提とした議論ですよね。はてなの場合も、実際の運営や経営については非常に少人数でむしろ廻されている。規模が小さいときには、所有と経営は一致しているほうがいいのかもしれない。

東:

 単に規模の問題で片づけられるかどうかは、難しいところですね。村上さん、いかがでしょうか。

村上敬亮(以下、村上):

 ここで、EAというものについてより抽象的に定義をしておきますね。それは「その組織全体で起きている業務とシステムを、共通の言語でリステイトメント(re-statement 再言明)する」ということなんですよ。それは具体的にはどういうことか、さきほどの経済産業省の調査統計部の例で説明しましょう。たとえば調査統計部の中でも、鉱工業生産指数であったりサービスの統計であったり製造業の統計であったりと、いろいろな統計をもっているわけですけども、実はその統計業務ごとに業務も違うし、F/N/H*3ばらばらのメインフレームが入っているという具合に全てバラバラなわけですね。ところがお互いがお互いに業務の仕方やプロセスやシステムの設計を知っているかというと、いざとなったら情報システムを開発したFさんHさんNさんに聞かなければわからないし、ひどい場合には聞いたとしても、さらにその開発の下請けに聞かなければわからない。そこで下請けまで出向いてみると、そもそも設計図が捨てられてしまっているというオチがついていたりします(笑)。

 こういう状況で、一体いかにしてシステムと業務をインテグレーションしていくか。まず、それぞれの仕事の仕方やその裏に入っているシステムというのはどうなっているのか、政府が自分で理解できる共通の言葉で書きましょう、というのがAs-Is(現在)のEAを書くということなんですね。さらに5年10年をかけてさまざまな制約条件を外してみたときに、どういう形でインテグレートされてくのかを決めていく。さきほどの例に戻りましょう。たとえば理屈だけで考えれば、ある種のWEBサービスベースのデータオリエンテッドなアーキテクチャに統合されていくはずですけれども、実際にゴールがどこにあるのかを見据えたうえで、その間の移行プロセスにおいて来年どういった調達をするのか決めていく必要があるわけですね。このように、個々のシステムを発注する前にまず全体のアーキテクチャについて言明し、同じ言葉で業務についてもシステムについても書くべきである。これが、システムの側面から出てきたEAの議論です。

 さてこうした再統合に携わっている身から、近藤さんと石橋さんのコメントに一言だけ付け加えさせていただきますと、たしかに経験的にいっても文化が共有されている小さなコミュニティでは、それほどEA可視化だと騒がなくても改善サイクルは回ってしまう場合が多いんですね。たとえば、EAを始める段階でも、小さなコミュニティから段々と仕掛けていくのですが、たとえば経済産業省の調査統計部であれば、「先輩は誰が何をやっていて、あいつはこんな考え方する奴で、今の部長はこういう性格の奴で、こいつがこう動くと大体こうなるか…」という流れが大体共有されていますから、そんなものを可視化してしまうと逆に都合の悪いことの方が多いわけですね(笑)。

 ところが組織を超えて、農水省と一緒にやる、総務省統計局とも一緒にやるという段になってくると、そこで誰がどういう時にどういうリアクションが返ってくるのか想像ができないという事態が発生する。また現状も見えない。ここである共通の言葉でステートすることに意味が出てきますし、To Be(あるべき将来)モデルというのは少なくともそういうとこまでいかないといけない。そうでなくては、顧客オリエンテッドでものを考えるとき、経産省の中だけで調査統計いくら良くするといっても、そもそも顧客である国民から見れば「まあそんなの、やらないよりはやってもいいけれど、なんでもっと政府統計全体で見やすくならないのだ」という話に短絡してしまうので、逆にいつまでたってもそこにリーチできないんですね。それを避けるためには共通言語を定めること、そしてその中にリーダーシップを取る者がいることが、全体のPDCAサイクルをうまく回すポイントになってくるわけです。

八田真行(以下、八田):

八田真行
D1:八田真行

 いまお聞きしていて思ったのですが、オープンソースの定義というものは、村上さんがおっしゃるところの、ある種のEAと考えていいんですかね? その「共通の言語による再言明」というものが、さきほど自分が発言したメタライセンスとしてのオープンソースという考えと符合するのかなという気がしたんですが。

 さらに補足すると、要するにライセンスというのは契約文書ですからさまざまな情報が入っていますけれども、致命的に重要な差異、というはわずかなものです。曰くコピーレフトを主張するかしないか、商用配布を認めるかどうかといった各要素を抽出したのがオープンソースの定義だとすれば、それはいまお話を聞いたEAというものと非常によく似ているのかな、と。複数のアクター、たとえば農水省経産省というのと同じように、FSFDebianといった個々のライセンスを使っている人たちがいる、という風にパラレルに考えれば。

村上:

 そうですね、たしかにそういう側面もあると思うんですけれども。

東:

 とはいえ、そこは差異を際だたせたほうが議論が明確になると思います。僕がオープンソースGPLに関心があるのは、そこには、ノードノードが情報を交換するときのプロトコルだけ決めておけばあとは全体がうまく回る、という独特の設計思想が暗黙に含まれているからなんですね。ノードというのはこの場合人間のことです。オープンソースに参入してくる人間が、それぞれある決まったライセンス=プロトコル=形式に基づいて情報をばら撒いていれば、その内容を問わなくとも全体最適が自動的に達成される。

 しかし、EAで奨励されているのは、もう少し内実や意味にまで踏み込んだリステイトメントです。

鈴木謙介

鈴木謙介
D1:鈴木謙介

 さきほど人数規模が問題ではないかというお話が出たんですけれども、僕はずっと疑問に思ってきたことがあります。たとえば石橋さんの報告には、「場というものがルールと構造(組織)等をもつ」と書いてある。しかし社会学の定義からすると、「組織」と言う言葉が果たしてオープンソース・コミュニティが作り上げてきたものに馴染むのか、ちょっと疑問があるんですね。どういうことかというと、つまり近代的な「組織」というのはそれこそ村上さんが関わっていらっしゃるようなハイアラキカルな官僚制のことを言うわけです。ある種の構造・組織図があって、文書化されたルールがあって、命令系統がある。これがマックス・ウェーバーの近代組織、官僚制?の定義*4ですね。この存在の有無が組織であるかないかを分別するものとして重要なのではないか。

 であるならば、こうしたものを石橋さんがIETFを例に提起された場というものはもっているのか。それはもっていないだろう。では無い場合にはその代わりに何があるかといえば、そういう文書化された命令系統といったものが必要ないような、なんらかの共有されたカルチャーだったり、あらかじめの合意であったりではないか。

 そして前回での倫理研の発表に引き付けていうと、つまり文書化された命令系統をもつような組織(国家)のもつ力というものが世界的に退潮してきたとき、「それが無くともやっていける」というコミュニタリアンリバタリアンという二者の思想的立場が情報社会に入って再来してきているという話だったんですね*5。そこでEAオープンソース型かという今の対立軸というのは、規模の変数などによって同じものとして把握するよりも、違いを際立たせていくべきではないでしょうか。

東:

 話を整理しましょう。問題はこういうことです。一方には、部分最適を達成するミニマムな約束事さえ決めれば、全体はうまく回るという思想がある。鈴木さんが指摘したように、これは要はリバタリアニズムです。他方では、各構成に全体最適を内面化させなければ全体はうまく回らない、という思想がある。それは、コミュニタリアニズムに相当しますね。このように捉えれば明らかなように、メタライセンスとしてのオープンソースの理念がEAを包み込めるというさきほどの八田さんのお話は、メタユートピアとしてのリバタリアンの思想がコミュニタリアニズムを包み込めるというのと完全に並行しているわけです*6

 したがって、倫理研の議論と設計研の議論は深く繋がっているわけですが、このような文脈のうえで、情報社会にふさわしい新しい組織運営の哲学はどのようなものなのだろうか、というのがいま議論されていることです。

 さて、そこで組織の規模が小さいとき、あるいは物理的な近接性が基盤になっている地域情報化のような場合には、そもそも文化が共有されたコミュニティが前提になっているので、あまりいろいろ考えなくても組織運営がうまくいく。これはいいんです。あらためて議論するまでもなく、だれもが常識で知っていることです。

 しかし、組織の規模が大きい場合はどうすればよいか。そこで、全体最適を達成するためには、構成員にミッションやヴィジョンを共有させる必要がある。これがEAの立場です。それに対して、そのような全体的なミッションやヴィジョンは必要ない。構成員がみなローカルな知識しかもたず、バラバラに動いても何とかなるんじゃないか、というよりもむしろそちらのほうが効率がいいのではないか。これが、少なくとも世間一般がオープンソースについてもっているイメージ――八田さんがこのイメージに異論をもたれているのは承知していますが――ですね。つまりは、巨大な組織の運営について、ふたつの異なった哲学があるわけです。



*1:註:以下などを参照。@IT:ITアーキテクト宣言!

*2:註:GLOCOM智場:石橋啓一郎「変わるIT調達、調達側に求められる責任」

*3:註:業界用語で、富士通/NEC/日立の略。

*4:註:isedキーワード官僚制」参照のこと。

*5:註:isedキーワード「サイバーコミュニタリアン」あるいは「サイバーリバタリアン」参照のこと。

*6:註:isedキーワードリチャード・ローティ」を参照のこと。

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