ised議事録

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

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

EAエンタープライズ・アーキテクチャ)とオープンソースの対比

東浩紀(以下、東):

 たいへん詳細なお話、ありがとうございます。

 ところで、僕は経営学は素人なので的を射ない質問かもしれませんが、いましがたのお話で一貫していたのは、村上さんがメンバーの自覚に重点を置かれていたところだと思います。たとえば、いまも話題に出た「全体最適」を可能にするための業務計画として、村上さんは「エンタープライズ・アーキテクチャ」(EA)という行動計画を策定されている。その思想は、僕のような素人の目から見ると、きわめてトップダウン的なものに見えるんです。企業あるいは組織の構成員が、自らの組織がどのような構成をもち、どのようなミッションをもっているかを自覚するためにこそ、EAという業務計画が策定されている。

 だとすると、今日の講演で例として出されたIETF*1と、EAは実は対照的な組織哲学に基づくものだと言えないでしょうか。そもそもインターネットの誕生に立ち会ったプログラマたちは、だれも「ネットはこうなるべきだ」という大きなミッションを自覚していなかったでしょう。言い換えれば、「全体を見通しているひと」はだれもいなかった。エリック・レイモンドが『伽藍とバザール』で「バザール方式」と呼んだ組織構成ですが、これを村上さんの言葉で言えば、全体最適可視化されないまま、むしろ部分最適の集積と連続だけでうまくいってしまう、そういう組織だと思うのです。

 そこの対照性については、どうお考えでしょうか。

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

 同感です。正直申しますとここでの例として適切でない気もしますが、僕はOSIとTCP/IPについては別の裏舞台も見ているので、なぜTCP/IPが優位に立つことになったのかといえば、やはりインターネットという形で、バザール的なアプローチを重視した結果、実装されたアプリケーションがたくさんついてきたからだと思うんです。

 当時OSIをベースにして物を作ろうと色々考えた側は、サプライサイド・オリエンテッドに、「こういうものを作りたい、そのためにOSIという標準を実装する必要がある」と動いた。しかしその実装しているものが国の代表ごとにもっているイメージがズレていたので、そこの調整に手間取ってしまった。ところがTCP/IPのほうでは、そんなことを言わずに、どんどん実装が先に進んでいった。そういう意味では94、95年頃が一つのターニングポイントかと思うんですけれど、そうして実装されたものが、「なんだこれって便利じゃん」という形で、ややこしい議論をすり抜けてどんどん使われ始めた、と。こういう側面がTCP/IPのほうが結果としてOSIを凌駕していった理由ではないかな、という気はします。

東:

 お話は分かりますが、サプライサイドか否か、という点に問題があるでしょうか。というのも、TCP/IPあるいはIETFの動きも、実はサプライサイド寄りだったように思えるからです。インターネットの開発については、消費者のニーズなるものはまったく存在しなかった。むしろ、完全にサプライサイドの都合だけで作り上げたものが、事後的にそれなりに便利なものだということが発見された、ということだと思います。

 問題は、消費者サイドのニーズをサプライサイドが発見するとして、その統合の方法にあると思います。EA的な発想では、消費者のニーズをサプライサイドができるだけ完全に把握し、全体最適を図ったうえで企業のヴィジョンなりミッションなりを構築していくという方法がとられている。しかし、それとはまったく異なった方法で成功したのが、実はオープンソース・コミュニティなのではないか。

 とはいえ、ネットで発表されている文章などを拝読するに、村上さんは他方ではオープンソース・コミュニティに対して強い関心と理解を示されている*2。そこで、その村上さんのなかで、EAの哲学とオープンソースについての理解がどのように擦りあわされているのか、その点をお聞きしたいんです。

村上:

村上敬亮
D1:村上敬亮

 ふたつポイントがあります。ひとつに、オリジナルのTCP/IPの議論とか、IETFで最初の段階に行われていた議論というのは、たしかにサプライサイドの論理から抜け出ていなかったと思います。つまり、そういう意味での部分最適の積み重ねの動きでしかなかった。ただもうひとつが、これはオープンソースにも通じると思うんですが、サプライサイドに立っていても積極的に中のものを開示しようという努力があったことです。つまり、「私は裸です。だれか、うまく使える人がいたら僕を見出してください」という流れとでもいいましょうか、少なくともそこまで意図しなくても、結果として「裸」であったこと、そしてそのことによって続く誰かが見つけていった。そしてそれによって用途が広がりアプリが広がり、全体最適へのパスが拓けていった。OSIとTCP/IPとを比較するとき、結果として前者は部分最適にとどまり後者は結果として「自由にさせた」という意味においてパスが開かれていったということですね。

東:

 結果として全体最適を生み出していった、ということでしょうか。

村上:

 そういう意味では、今後オープンソースについても、全体最適につながるパスはまだいくらでも残されているのではないか、ということが僕の意見です。

東:

 なるほど。

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

 僕はむしろ、オープンだということは「参加」が開かれていたことが大きいかなと思っています。いまディマンドサイド・サプライサイドという軸で議論されていましたが、ディマンドサイド側にいたユーザのひとりひとりが、サプライサイド側に移り変わる可能性というものは、少なくともOSIの枠組みにおいては非常に少ない。ところがIETFというのは、「場の重なり具合」ということばと関係してくると思うんですが、この立場の移転が容易であったと思うんです。

東:

 つまり、オープンソース・コミュニティは、ディマンドサイドがつぎつぎとサプライサイドへと移っていくような仕組みを整えていたがゆえに、ディマンドサイドのニーズを可視化しなくても自動的にそれが取り込まれ、全体最適が実現されるシステムだった。このような理解でいいんですかね。

村上:

 そうですね。

楠正憲

楠正憲
D1:楠正憲

 付け加えますと、オープンソースの議論においてはレイヤリング(レイヤー構造化)とモジュール化が非常に重要なところではないかということなんですね*3。要はIETFで行われている個々のワーキンググループの議論というのは、経路表をいかに小さくするかというようなきわめてテクニカルで専門的なものです。けれども、たとえばWWWというディマンドを見つけたティム・バーナーズ・リーは、別にIETFでのルーティングの議論には参加しなくとも、とにかくそのSocket APIを使ってブラウザを書くことができたわけです*4。他のレイヤーの細かい議論はパスしても、とにかく実装はできる、と。さらにそのあと、NCSA(National Center for Supercomputing Applications 米国立スーパーコンピュータ応用研究所)でアンドリーセンがWindowsやMacintoshでも動くブラウザMOSAICを作り、Netscapeという会社を起こしてWEBを使うということを広くマーケティングを行って、世界中にユーザが増えたんだと思うんですよ。ここでの流れのポイントは、サプライサイド側に近い、たとえばルーティングの設計を行うレイヤーの人々は、カスタマーのニーズを最後まで知らなくても特にボトルネックにならなかったということではないでしょうか。

東:

 レイヤリングやモジュール化の手法は、結果としては全体最適をもたらすけれども、構成員ひとりひとりは部分最適さえ考えればいいという組織を作り出すものですね。個々の設計は部分最適的に行われていても、レイヤリングという一種のメタ設計が働いているからこそ全体最適が達成される。こだわるようですが、村上さんのEAの思想は、それとはずいぶん違うように思うんです。

村上:

 別の言い方をすると、前者というのは、評価における単発的なROI(Return On Investment 投資対効果)が連続しているだけの時代であり、後者というのは、そこに時間軸の広がりを加えた、PDCAサイクル*5ポートフォリオ評価あるいはポートフォリオ管理の時代であり、投入した資産のROA(Return On Asset 総資産利益率)の最大化・最適化を目指している。後者は何を意味しているかといえば、広がりゆくPDCAサイクルを保障できるか、ということなんですよね。つまり、まず組織の内側にこういうものがある。つぎに、外側からこういうものがコミットしてくれる可能性がある、そういう風に知恵が外から転がり込んで、それが次のビジネスサイクルの拡大につながる。そういうPDCAサイクル作りを実現すると。

 具体的な話にしてみます。電子政府のなかで調査統計についてEAを書いてみようという話があるとしますね。理想をいえば、政府全体で小泉さんをトップにして、経済産業省も総務省の統計局も農水省の統計もみんないっぺんに全体最適化するためのアーキテクチャをまず書くプロジェクトから始めようとします。ところが実際には、各省ごとに統計のもっている意味、使い方、人間のもっているカルチャーなどが全然異なっているわけで、大上段構えて全体を設計するといっても大体ひっくり返るに決まっています。

 ではどうするか。経産省の統計から、農水省の統計から、ないしはこういう分野の経済統計からやりましょうという部分単位から、トップダウンアーキテクチャを決めてくという議論をしていきましょう。ところが、その単発で止まってしまえば意味がない。それではその経産省全体最適がうまくいけば、今度はオール政府でやってみようであるとか、今度は民間統計まで含めたナレッジポータル作りまで取り組んでみようというかたちで、射程を徐々に広げていくということをやる必要がある。

 でも、その時は、役所の内部的なモチベーションだけでは、縦割りの壁は越えられない。経産省統計、農水省統計、総務省統計それぞれのユーザから、様々な統計館のリンクのニーズを引き出す必要がある。でもそうした知恵を引き出すためには、全体最適化に取り組むということ、そのための射程を広げる気があるということをユーザ側に明確に伝え、そのメッセージを拾い上げていく仕組みを確立しなくてはなりません。

 ここでこの次の段階に行けるかどうかの時にキーワードになってくるのは、そのPDCAサイクルのプロセス・マチュアリティ(成熟度)*6なんです。顧客のニーズと提供側のサービス改善の間の相互作用の高さ、応答性の良さみたいなものでしょうか。単発的な投資の投資対効果を個別に測定したところであまり意味はありません。知識のパフォーマンスを上げるために必要なのは、PDCAプロセスの成熟度とかコミュニケーションの濃さ、なんですよね。その仕組みをどういう風に作っていけるか、というところが、個々の投資が目指すモノよりも更に重要なポイントになっていく。

 だからOSS(Open Source Software)にしても、今のコミュニティの中のプロセス成熟度はものすごく高い。だけれども、それが本当にたとえば業務アプリであるとかというところにまでリーチできるような改善サイクルができるかというと、いまは残念ながら多少そのベンダーのコマーシャルな思惑といった色々なものが間に介在しているために、難しい。しかし、いまはパスが開かれているからこそ、可能性はある。つまりプロセス・マチュアリティがどういう風に濃くなっていくか、という意味で、おっしゃられたような部分が花開いていくかが決まるのではないか。

石橋:

 なるほど、つまりある意味でモジュール化とは全く違った考え方なんですね。要するに、最後には全部一体になるように範囲を広げていく。

村上:

 そうですね。ただしその時に仮説としてのレイヤー構造化やモジュール化などの議論が必要な理由はこういうことです。要するに最初から経済産業省の統計調査しか議論しないつもりならいいけれども最終的にはもっと広げて見ていきたいわけですから、あらかじめ全体の大雑把なストラクチャーやレイヤー構造がどうなっているのかは、先に可視化しておいた方がそのPDCAサイクルが広がっていく余地が高いわけです。モジュール化可視化は、それ自体に目的があるのではなく、次の段階で更に大きな全体最適化、知恵の集積を効果的に進めるために不可欠となる手段なんです。たとえば経済産業省の調査統計から始めるといっても、そこばかりを一生懸命掘っていないで、「そもそも統計業務ってどういうストラクチャーをしているのか」と問いながら、レイヤー構造やモジュールの仮説も作っておきながらアプローチをしていくほうがよい。

鈴木健

 それはつまりBPR(Business Process Reengineering ビジネス・プロセス・リエンジニアリング)*7なんでしょうか。

村上:

 そうですね、そうかもしれません。

鈴木健

 インターネットがどのように作られてきたかというプロセスを見たときには、既存の資産とか既得権益といったものは無かったために、先ほどまでの議論のように場の構築を行うことができた。しかし、その場所に既存の資産があるときにはBPR的な発想でやっていかなくてはならない、ということですね。

村上:

 なるほど、確かにオープンソースEAでは、そもそも既存の諸関係とどのように付き合うのかという部分で出発点が違うかもしれないですね。

メタライセンス」としてのオープンソース

東:

 冒頭から、組織設計の哲学をめぐって、かなり本質的な議論がなされたのではないかと思います。

 それではここで、japan.linux.comの主筆を務めるなど、オープンソース・コミュニティの運営に深く関わっている八田さんからお話を伺いたいと思います。いままでエンタープライズ・アーキテクチャの考え方とオープンソース的なモジュール化・レイヤリングの差異が問われてきたわけですが、ここまでの話を聞いていかがでしょう。

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

 まずはじめに重要な点はですね、別に僕はオープンソースの代表ではないんですね(笑)。

東:

 わかりました。あくまで僕がそう考えている、ということでいいです(笑)。

八田:

八田真行
D1:八田真行

 いやはや(笑)、これはけっこう重要なポイントなんですが。さておき、それではまずオープンソースという言葉がなにをそもそも意味しているのか、自分なりの考えを提示しておきます*8。自分はこう考えています。オープンソースというのは「あとから出てきたもの」である、と。たとえば、まずBSDライセンスであったり、GNU/GPL(General Public License 一般公衆利用許諾契約書)*9という具体的なライセンスが存在していたわけですが、その上に被さるものとして、いわば「メタライセンス」としてオープンソースの定義は出てきたわけです。この構造が先程の村上さんの話と関係するのかまだ判然としませんが、つまり、大まかに「オープンソースとはこういうものでしょう」という概念の共有をし、その下にモジュールとしてのライセンスが多数ぶら下がっているという構造をもっているのが、結局オープンソースというものなのだろうと僕は思っているんです。

 そしてオープンソースに関して僕が興味深いと思っているのは、このモジュールが多数存在していて、しかも互いに対立しているんだけども、「共存できている」ということなんです。たとえばLinuxBSD或いはLinuxGNU/Hurdというカーネルの対立、またライセンスに関してはGPLとBSDL、またコピーレフトとそうでないものの対立。さらに人間の単位でみても、リーナス(Linus Torvalds)*10ストールマン(Richard Matthew Stallman)*11は必ずしも一致しているわけではない。それから自分が参加しているDebianをあんまり特権化してもしょうがないのですが、Debianというディストリビューション*12というのがありまして、そこはある意味オープンソースのテストベッドとして機能している。「実際にオープンソースをやっているのはあそこだ」という側面があると思っているのですが、ただDebianFSF(Free Software Foundation フリーソフトウェア財団)*13では、長いことGFDL(GNU Free Documentation License)というライセンスを巡ってケンカしている。またOSI(これはオープンソース・イニシアチブ(Open Source Initiative)*14の方ですが)とストールマンが設立したFSFは、仲が良くないとは言わないけれども、必ずしも意見が合致しない。

 こうした思想や意見の対立するアクターたちがオープンソースという枠のなかに共存しているという状況があり、結果としていい方向に向いている。これは結局のところなぜなのか。それは、オープンソースというメタな「くくり」があり、しかもみながそれを突っつくことで再定義できるような構造になっているということに拠るのではないかと思うんです。かつその、あえて比喩的に表現すればインターオペラビリティ(相互運用性)といいましょうか、相互がとりあえず回復不能なほどには対立していないということが大事なのではないかと。

鈴木謙介

 なるほど、そこで「再定義できる構造」というのは、どのような構造を指すのでしょうか。そして、そこでのオープンソースというのは、概念としてのオープンソースなのか、それとも何か具体的な集団のことなどを指すのでしょうか。

八田:

 まず後者についてですが、僕はそのオープンソースの概念と定義というものは一致していると思っています。

 そして再定義というのは、どこかに任意のオープンソースの定義があるとしたときその下のほうから「いや、その定義はおかしい」という声があれば、書き換えてもいいということです。書き換えてもいいというのは、そういうコンセンサスがいくつかのアクターの間で取れれば、オープンソースの定義自体が書き換わる可能性があるというわけですね。

 なぜこのような話をしたかというと、村上さんのお話されたEAというものとオープンソースとの間の問題を考えるときに、オープンソースはただの部分最適の積み重ねではないと思ったからなんですよ。つまり、大まかなメタライセンス的な枠組みがあり、さらにそれを常に再定義できるように構造として開かれているということ。これが致命的に重要だったんじゃないか。

楠:

 ただ、そのときのオープンソースの定義というものは、オープンソース・イニシアチブで決めているという意味ですよね。しかしあのオープンソース・ディフィニションというものがいわゆるラベリング以上の意味でどういう社会的な意味合いがあるのか、八田さんのお考えをお聞きしたいんですね。というのも、たとえばGPLひとつ取ってみても、これはあくまで契約なわけです。そして確かにそのライセンスは守らなくてはいけないわけですが……

八田:

 強制力がないではないか、というご指摘ですね。

楠:

 そういうことです。

八田:

 強制力は実際のところ全くないといっていいと思います。ただ、取引費用の低下にはつながっていると思うんですよね。使う人から見れば、オープンソースの定義の10ヶ条*15に従ってさえいれば、この10ヶ条に関して何某の為しうることは保障されている。逆に言えば、オープンソースの定義からは、いつでも降りてしまっていい。

 ただオープンソースの定義が社会的な意味合いをどうもつのかというとき僕が考えているのは、全然関係のない人たちが共存するという構造あるいは場があるとき、それを何らかのコストを払ってでも確保するということはきわめて重要であるということです。ですから、マイクロソフトもそのアクターの一つとしてプロプライエタリ(独占的な・非オープンの)という存在を代表するものとして存在していてほしい。そうした多様性の確保を行っているのが恐らくオープンソースの定義、あるいは再定義可能なメタライセンスというものなんです。



*1:註:設計研1回 石橋啓一郎 講演「情報社会の二つの設計」の第2章参照のこと。

*2:註:たとえば村上による以下の論文では、現行著作権法を「優れたコンテンツを発見し紹介するというユーザ側の知的貢献をやや軽視している」と指摘、知的生産の主体が(情報家電政策のときと同じく)消費者サイドにシフトしていくことを前提とする。また、著作権制度の今後の方向性を、「禁止権をベースとした権利法から競業規制や約款規制」といったローカルな主体間の「契約」を扱うものへシフトする可能性について言及している。→村上敬亮「オープンソースを巡る著作権論議と知的財産政策への示唆」(特技懇231号、2004年)

*3:註:設計研1回 石橋啓一郎 講演「情報社会の二つの設計」の第2章isedキーワードモジュール化」参照のこと。

*4:註:ティム・バーナーズ-リー「Webの創成 ― World Wide Webはいかにして生まれどこに向かうのか」(毎日コミュニケーションズ、2001年 asin:4839902879

*5:註:Plan-Do-Check-Actionの略。以下を参照のこと。→@IT情報マネジメント用語事典 [PDCAサイクル]

*6:註:ソフトウェア開発に関する組織工学的なものとして、CMM(capability maturity model 能力成熟度モデル)と呼ばれるものがある。以下を参考のこと。→@IT情報マネジメント用語事典 [CMM (capability maturity model)]

*7:註:企業活動全体を、リジッドな組織構造型ではなくフローなプロセス志向型の視点から抜本的に再構築すること。→@IT情報マネジメント用語事典 [BPR(business process re-engineering)]

*8:註:isedキーワードオープンソース」参照のこと。オープンソース論争。レイモンド。

*9:註:八田真行による邦訳は以下。→GNU 一般公衆利用許諾契約書 - GNU プロジェクト - フリーソフトウェア財団 (FSF)

*10:註:Linuxカーネルの原作者。

*11:註:isedキーワードストールマン」参照のこと。

*12:註:Linuxの配布パッケージのこと。

*13:註:isedキーワードストールマン」参照のこと。

*14:註:Eric S. Raymond氏らによって創設・運営されているオープンソース文化を啓蒙するための非営利組織。オープンソースの定義を公開している。

*15:註:八田真行による日本語訳は以下。→The Open Source Initiative: オープンソースの定義(日本語)

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