ised議事録

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

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

現場と経営の二重構造――オープンソース組織論

東浩紀(以下、東):

 それでは、第2部の議論に入りたいと思います。さきほどの鈴木健さんは、オープンソースはいまや人々の「コミュニケーション・メディア」として機能しているのではないかと指摘されましたが、今日の討議は、まさにその指摘どおり、オープンソースについてみな好き勝手に語りたいことを語るという状態になりつつあります(笑)。司会としてはいささか胃が痛いですが、それもまたよいのかもしれません。

 ともあれ、さきほどはコメントを頂かなかった村上さんと近藤さんからお話を伺っていきたいと思います。まずは村上さん、いかがでしょう。

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

村上敬亮

 それでは、皆さんのお話を伺いながら、市場・社会の二重構造化ということを考えておりました。

 オープンソースという現象は局所的な現象ではないかというイメージが一般の方にはあると思います。だから制度設計一般に敷衍できないという感じがするわけですが、しかし、オープンソースの生産開発プロセスにおけるモチベーションの連鎖を重視した仕組みと、可視化というモメントを大きなベースに据えるということは、いま普通の企業にもあちこちで少しずつ始まっていると思うんですね。

 オープンソースの場合、楠さんがここにいらっしゃるので恐縮ではありますが、ある側面では、アンチ・マイクロソフトというわかりやすい社会的命題と結びついています。そしてそこに多数の支持がついているからこそ、オープンソースは社会的に大きな存在として見えている側面もあるでしょう。

もちろん、オープンソースとアンチ・マイクロソフトという話は直接的には全く関係ありません。オープンソース・コミュニティにいる人々の動機の純粋さを疑っているわけでは微塵もないんですけれど、ただし、IBM社の莫大なる人と金の面でのスポンサーシップという事実はオープンソースをここまで大きくしたものとして無視できないと思います。こうした様々なモチベーションがオープンソースの周囲に複雑に絡んでいるからこそ、あえて八田さんが言及を避けられていた、イノベーションの話にもつながる大きな動きになっていく可能性があるんじゃないかと思うんです。

 時代を丸ごと変えてしまうような夢のある技術が語りにくくなっている今、社会全体にある種の閉塞感がある。本当のイノベーションフロンティアがどこにあるのか見えなくなっているという感じがします。もしイノベーションをすべき方向性が明確に見えているのならば、特にオープンソースのようなモチベーション連鎖型の動きに頼らなくても、管理型社会だけで邁進できる。しかし、そのやり方では、新技術がどこへ進むべきなのかが不明瞭になっていると思うんです。

 たとえば審議会でこういう議論をしています。DVDのような規格型のイノベーションと、Wintel(Windows+Intel)のイノベーションは違う構造を持っている。DVDはイノベーションのネタを供給側が自分たちで出さなければいけない。それに対して、Wintelはアプリケーションを開発する人、ネットワーク上でサービスを展開する人など、よそ様から知恵を頂いている*1。技術的なイノベーションをすべて自分たちが出し続けるのは苦しいことですから、よそ様から知恵をいただける構造のなかに、うまく自分たちを乗せるという構造にしているわけです。つまり、それくらい競争の変化は速まっている。そういう時代に、たとえば社長が率先してイノベーションの方向性を見定めて社員を導くという操舵法はもはや通用しないんですね。

 このように、ミクロのプロジェクトの動きが全体の大きな動きにどのようにつながっていくのか良く見えない、そういう時代になってきているからこそ、ポートフォリオ管理が重要になってきているように思います。組織の大目標とリソース配分は経営者側で管理するが、そこから先の現場はできるだけ現場に任せてしまう。大目標というのは、どの顧客に対してなにを目標とするのかということで、それに基づいて資金や人的資源をどれだけ出すのかというリソースの配分管理も経営者側が担当する。しかしそこから先の、与えたミッションとリソースのなかで現場がなにをするのかには関与しない。これは、全体を管理する際のプログラム・マネージメントと、現場でのプロジェクト・マネージメントのやり方は全く異なるとも表現されています。

村上敬亮

 こういう二重構造の中で、プロジェクト管理の現場では、あらかじめモチベーションなりリテラシーなりが揃えられるという前提もありますから、今日のお話にも出てきたようなオープンソース流のプロジェクト運営法が適用できると思います。他方、実際の社会的な動きとすり合わせていくという一段抽象度の高いフェイズをどうするのか。現場でのモチベーションの連鎖を崩さないようにしながら、リソースの配分と大目標については環境管理的に、手続き的な管理をしなくてはいけない。こういう二重構造があちこちで出来ているのではないか。

 つまり、一方ではモチベーション連鎖型の開発プロセスはミクロな現場にどんどん入っていくという方向しかないと思います。しかしもう一方で、既存の工業社会的な組織運営の論理は残り続けると思うんですね。そこで現場のモチベーション連鎖を崩さないように現場の自立性を保ちながらも、この両者をすり合わせるような大ミッションや大リソースの管理ができる経営者という、新しい経営者像が要請されると思うんです。こうした問題がいま切実なものになりつつありますから、八田さんの議論がイノベーションの問題を避ける必要はないと思うんですね。

 また楠さんの指摘していた、設計思想の内面化や権力側から見た被支配者の可視性という点からいうと、やはり現場ではオープンソース型でいくしかない。そして経営者は現場に対して、見えないものは見えない、設計思想を同じ熟度では内面化できないと割り切ったうえで、どうポートフォリオ管理するかを考えないといけない。ここで経営者は、ある種のインターメディエイター(中間媒介者)としての役割を果たすことになるわけです。こうしたある種の二重構造化が、いま現実に起きているのではないかという感触を日々感じているところです。

東:

 なるほど。いまの話を裏返すと、オープンソース的なモチベーション連鎖はミクロな開発現場では使えるけれども、よりマクロな部分、たとえば開発者と社会とのインターフェイスになってくると、オープンソースのモデルはあまり機能しない。異なるタイプのコントロール手法が必要になる、というお話ですね。

村上:

 オープンソース型は皆さんも指摘されていた通り、ある種のリテラシーとモチベーションの均質性がどうしても必要になってきますから、それが成立するところでしか実現できないと思うんですね。もし日本全体でその条件が成立するのであれば社会全体でも機能すると思いますが、それは無理でしょう。だからこそ、すり合わせを行うインターメディエイターが必要になると思うんです。

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

 おっしゃることはよくわかります。オープンソースの構造からはみだした部分として、イノベーションを促す構造というのがまた別にあるというのはその通りだと思います。また現場にオープンソースの手法が応用できるというのは、鈴木健さんの話にもちらっと出てきましたが、企業内の開発現場でオープンソース的な方法を使うアジャイル開発プロセスという手法*2がありまして、そのイメージかなとお聞きして思いました。実際オープンソースの構造の類型というものは存在していて、その類型自体は応用可能とは思うんです。

村上:

 そして、オープンソースの外側も含めた二重構造性を意識することで、オープンソースの世界がもっと活きるはずだと思うんですね。

楠正憲(以下、楠):

 ただ、オープンソースという言葉をここで使うのが若干混乱の原因になっている気がします。たとえば、会社のなかでのインタラクションや情報共有をまるごとオープンにしてしまったら、そこに付加価値は生まれない。村上さんの議論は、むしろ企業のなかの風通しを改善するということ、たとえばマネージメント側とテクニカルリードやインプリメンテーション(実装)側との権限分離を進めていきましょうといった話ですよね。たとえばマイクロソフトがここ十何年かスピード感のあるビジネスができたのは、まさにそういう組織ガバナンスをやってきたからだと思います。ただこれはどちらかというと欧米企業、とくに米国の西海岸的な組織文化だと思うんです。これはオープンソースに触発されたものなのか、むしろオープンソースもこの西海岸カルチャーから由来したものなのかな、と。

村上:

 そうですね、企業内の現場管理をオープンソースになぞらえるのは違和感があるというのはおっしゃる通りで、僕自身も整理できていないところがあります。一点だけやや共通する部分があるとすれば、完全に社内だけにコードが閉じているかというとそうではないと思うんです。ミクロな現場から見て外部のステイクホルダー、たとえば消費者やユーザーに対してはオープンになる部分がでてきている。

楠:

 そういう意味では、おそらくIBMメインフレームの開発をしていた時代からそうでしょう。

村上:

 そうですね、そこは多分モジュール化の話になると思うんですが……。

鈴木健

 モジュール化するというのは、インターフェイスの話じゃないですか。でも、生産プロセスを可視化するというのは中まで見せるというということです。両者ではスケールが全然違うんですよね。

村上:

 そうですね、言いたかったのは、作り手がユーザーの側に情報開示をすることでユーザーからも知恵をもらう部分があるという現象が、既存のビジネスの現場でも出始めている。そこに、オープンソースと似たものを感じるということなんですよ。

鈴木健

 なるほど。

鈴木謙介(以下、鈴木謙):

鈴木謙介

 オープンソース的という言葉の意味がぼやけてしまっていると思いますが、いまの話というのはつまり、企業の内と外とをつなぐ知のフィードバックシステムを用意しておかないと、もはやビジネスがまわらないという話ですよね。たとえばインターネットサービスを提供する企業があったとして、いままではトップダウン式に、いまはこういうのが流行るというのをマーケティング的に決め打ちしたり、あるいはカリスマ的な開発者がいて偶然ながらも大成功するといったプロセスだったとしましょう。

 ただこれからは、インターネットサービスの付加価値はユーザー自身が決めるんだというわけですよね。ボトムアップ式にビジネスのシステムを設計する必要があるんだ、と。ただし消費者の側で生まれるコミュニケーションによって、どんな付加価値がついてそれに人々がどうコミットしていくのかということについては、企業はタッチしない。あくまでインフラだけを提供する。こうしたスタンスが企業のウリになっていくというようなプロセスのことだと理解したんですが。

村上:

 おそらくそれでよいかと思います。特にオープンソースと似通っている部分はモチベーションの部分なんですね。現場に最初に知恵をもたらすモチベーションというのは、やはり「面白い」という部分なんですよ。こうしてみたら面白いんじゃない、と作り手がミクロな現場で勝手にあれこれ試行錯誤をするところにイノベーションが生まれる余地があるんですね。

 ただ、面白いじゃん、というだけではそれを大量生産して既存の工業社会の論理に乗せていくというところではうまくいかない。だから企業としては、その変換装置は持っていないといけないわけです。それをビルトインできた企業はイノベーションサイクルに乗れるでしょうし、そこに乗れずに、あくまで自社のリソースに閉じこもったところで次はこんな技術革新だと叫んでいるようでは、プロフィットの低いところに留まらざるを得ない。

鈴木謙:

 たとえば携帯電話やiモードなどが、一時期そのようなものとして語られていたと思うんです。つまり、面白いという動機をシステムに実装して、売り物にしたところにあれは意義があった、と。

村上:

 まとめますと、まずソースに近いコードのようなものが開示されている、と。そしてそれを見て面白いと思うステイクホルダーがでてくる。そうしたコミュニティを、ミクロな現場が組織外に持てば持つほど速いイノベーションサイクルに乗れる。そのベースには面白いという動機づけがある、と。

東:

 オープンソースのイメージをここで整理したいんですが、さきほどの井庭さんは、オープンソース化とはただ単に消費者のニーズを企業の商品開発に巻き込んで参加させるということとは違う、と言われていました。またさきほど鈴木健さんが、モジュール化*3オープンソース化は分けて考えるべき、と指摘されましたね。このあたりがクリティカルではないか。

 僕自身も含め、一般のオープンソースへのイメージというのは、開発者が経済的なモチベーションだけではなく「楽しさ」を基盤に据えているし、開発者とユーザの障壁も低いので、何となく消費者のニーズにも細かく対応できそうだ、というような漠然としたものだと思うんですよ。でも、井庭さんによれば、そこに注目しても面白くない。他方、オープンソース化によって多数の開発者の協働がうまく行くようにモジュール化が進められたとしても、それはつまり良くできた分業にすぎないのであって、やはりオープンソースの話とは違う。

 鈴木健さんがおっしゃたように、ソースだけでなく生産過程も含めてすべて可視化されていることこそがオープンソースの特徴だとしたら、村上さんのいままでの議論は井庭さんや鈴木さんの「オープンソース」とは違ったものが対象だと思うんですが、いかがですか。

村上:

 たぶん違うんだと思います。最初にキーワードで二重構造性と申し上げたんですが、僕はそっちに引っ張られてしまったせいだと思います。つまり、ミクロな現場で使い手にも作り手として参加してもらう構造をうまく作る、その動機として面白さがある、こうした新しい組織運営のロジックをうまく使いたいという企業論理を二重構造性と表現しました。また、たとえば使い手の方から権利を主張されないように、コミュニティをどうやって取り込むのか。内部的な面白さの連鎖はいいんだけれども、どんどん暴走しないように管理するのか、といった視点ですね。つまり僕は企業論理から見たオープンソースという話になっているので、視点が逆に限定的になってしまっている可能性があります。

 ただ、こうしたミクロな現場で起きている現象を、さらに外側でしっかりとルール化する仕組みというのはまだ確立していないと思います。このあたりがうまくいけば、たとえば今後、情報家電をプラグアンドプレイでつなげる際の開発ルールなどに応用できるんじゃないかといった関心を持っているんです。

東:

 わかります。とはいえさらに突っ込ませていただくと、八田さんは、まさにその「外側でのルール作り」こそがOSDの10か条だとおっしゃっていたと思うんです。つまり、かなり少数の必要最低限のライセンスをもとに、生産的な開発過程が自己増殖していくようなことがオープンソースでは可能だったんだ、ということです。

八田:

 そうですね。村上さんの話を伺っていて、アルフィ・コーンの議論*4に関係するのかなと思ったんです。要するに、人間というのは金銭的な報酬ではないモチベーションで動くほうが、いい仕事をするという研究ですね。また日本の企業でも、現場ではお金もらえるからというよりは、楽しいからいい仕事をしているという側面がある。ただ現場だけに任せてもうまくいかない。そこで大目的などの大枠は決めて、あとはモチベーション高めておきつつ現場にまかせるという構造を作ろうというお話として理解しましたが。

井庭崇

 オープンソースはモチベーションありきだという議論をもっと突き詰める必要があると思うんですね。オープンソースにおけるソフトウェアの自律的連鎖のダイナミズムを決めているのは、経済的な要因によるものではない。それはあくまで外部要因でしかない。そうだとするならば、ビジネスの現場という経済的動機付けありきの場の内側で、そもそもそうした連鎖は可能なのかが論点になると思うんです。そのとき、生産プロセスの可視化という議論との接続点が見えるんじゃないか。





*1:註:WindowsやIntelは、OSやチップというかたちで各企業の技術のプラットフォーム(基盤)を提供することに基本的に徹し、その上で各企業がイノベーション競争を行うという「水平分離(分業)」のモデルの代表としてしばしば扱われる。

*2:註:以下の記事を参考のこと。→@IT:特集:.NET開発者のための開発プロセス入門(前編) アジャイル開発を導入できていない.NET開発者たちへ

*3:註:isedキーワードモジュール化」参照のこと。

*4:註:たとえば次の論文などを参照のこと。→Studies Find Reward Often No Motivator - GNU Project - Free Software Foundation (FSF)(邦訳:「報酬と動機」)。アルフィ・コーン『報酬主義をこえて』(法政大学出版局、2001年 asin:4588007041

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