ised議事録

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

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

ソフトウェア設計と制度設計――楠正憲からの応答

東浩紀(以下、東):

 では、このあたりで質問は終えて、楠さんからのコメントをお願いしたいと思います。

楠正憲

楠正憲

 今日は「ソフトウェア設計と制度設計」を比較するということでコメントいたします。八田さんの講演ではオープンソースというものを制度設計と重ねながら議論されつつ、後半ではその議論にいくつかの留保条件をつけていた。そのあたりの補足的議論をメインに展開することになると思います。ですが、まずは一個人としてのお話から始めさせてください。

 ちょうど2年位前にストールマンが日本に来たとき、私も彼に会いに行っていろいろと話をしたんですね。もともとUNIX少年でしたから、中学生の頃からスーパーアスキーなどを読んでは「Emacsを動かしてみたいな、gccを使ってみたいな、TeXで文章を打ってみたいな」と思ってみても、UNIXが動くワークステーションが高くて買えなかった……という中学生でした。ですからストールマンに言ったのは、「あなたはソフトウェアをフリーで出したかもしれないけれども、残念ながら僕の手元にはあなたがたのソフトを動かす環境がなかったんだ」と(笑)。そして、まあ嫌味なことですが、「その環境をつくったのは結局ビル・ゲイツだよね」みたいな話をしたらですね(笑)、彼はすごく嫌そうな顔をして「いや、インターネットが普及したからパソコンは普及したんだ」というような話になり、なかなか議論の一致するところを見出せなかったんですけれども(笑)。

 さてまずは議論の前提として、オープンソースというのは様々なコンピュータの世界のイノベーションが蓄積している上に成立しているということを確認したいと思います。そもそも、異なるコンピュータのあいだで同じプログラムが走るようになったのは、1960年のシステム360*1といういわゆるIBMのコンピュータからです。それまではモデルが違えば違うプログラムをそれぞれ書いていましたし、アセンブラのニーモニック*2も違いました。とにかくハードウェアの値段が高かったこともありましたから、それぞれのハードごとに独自にソフトウェアを書くのが当時の考え方でした。

 その後メインフレームよりも価格の安いミニコンのようなものが登場し、そのミニコンで動くものがAT&Tでケン・トンプソン(Ken Thompson)博士によって書かれたのがUNIXになります*3。そしてこのUNIXLinuxの設計に非常に大きな影響を与えているわけですが、実際リーナスはLinuxをつくるとき、早い段階でUNIXの標準ドキュメントを見ながらそれを満たすようなものを書いていたという歴史的事実があります。

 また、みなさんがいまパソコンを使うとき、たとえばウィンドウシステム、GUIのメタファーやイーサネットによるネットワーク、あるいはプリンタに普通に出力できるといった環境で仕事されていますけども、こうしたWYSIWIG*4的な環境は1970年代にXEROXのパロアルト研究所*5で開発されたものですね。

 そして八田さんのご指摘にあったように、ネット上での分散コラボレーションを実現するインターネットはDARPA(Defense Advanced Research Projects Agency(米国防総省)高等研究計画局)の研究から開発されました。またリーナスが386*6のマシンをお小遣いで買えたのは、インテルマイクロプロセッサーというものを出して、何百万円もするコンピュータではなく20万~30万円でパソコンが買えるようになったという歴史的背景があります。

 こうした歴史的蓄積のうえにオープンソース的なコラボレーションが成立しているのであって、オープンソースで構成し得るのはコンピュータをめぐる世界のごく一部に過ぎないともいえる。ただし、ソフトウェアの開発プロジェクトはきちっとまわる状況になってきたという点ははっきりと評価できる点ではないかと考えられます。(図:ソフトウェア設計と制度設計)

図:ソフトウェア設計と制度設計
図:ソフトウェア設計と制度設計

 いよいよ本題ですが、ソフトウェアの設計と制度設計というのを突き詰めて考えると、この両者の違いは大きいのではないか。それを比較したのが図:ソフトウェア設計と制度設計になります。

 まず、ソフトウェアはコンピュータが実行するものですから、その実行結果にはランダムなところも発生しないわけではないけれども、あくまで非常に決定論的なものです。かたや制度というのは、それを解釈し実行するのは人間ですから、その運用にはかなりの裁量がききます。

 次にソフトウェアは非競合的で、制度設計は競合的です。これはどういうことかというと、たとえばコンピュータは山ほどあって、それぞれのコンピュータで違うソフトウェアを動かすことができる。たとえば私のコンピュータではWindowsXPTablet PC Editionが動いていて、八田さんのPCではおそらくDebianLinuxが動いている。けれども法律や制度はそうはいかない。たとえば私も八田さんも同じ日本の法律を守らなければいけない。これはつまり、ソフトウェアは本質的に多様性を実現しやすいけれども、法の世界では社会全体を時間的にも空間的にも一貫性を貫くことが重要になる。もし法制度の多様性が許されると、おそらく楽なほうへとズルができるほうへと流れてしまい、社会全体がまわらなくなる。

 このソフトウェアの多様性は、取替可能性につながります。たとえばWindowsが気に入らない、価格が高いと思えばLinuxにすることもできますし、逆に、Linuxかな漢字変換Wnn*7があまり賢くないからWindowsを使いたいという選択肢も可能です。一方で制度はそう簡単には取り替えがきかない。ここでは「不可逆的」という表現をしていますが、要は一度決めた法律で死刑が決定したとして執行されてしまったら、それは元に戻すことはできません。もちろん法改正等はできるわけですけれども、ソフトウェアのようにころころとアンインストールすることができるわけではない。あるいは、たとえば消費税を5%から15%にしたところ、景気が腰折れしてしまった場合、2年前に戻って「あのときの国会決議を変えましょう」といったことはできないわけです。

 またソフトウェアは、きちんと早く動作するといった「結果」によって正当性が生まれます。たとえば銀行のシステムであれば、適切に口座が管理されていればオッケーですし、気がついたらみなの口座残額が増えてしまって銀行が損してしまうというようなシステムではダメなわけです。一方で制度設計の場合、結果として失敗に終わる立法も起こりうるわけですが、それは簡単には元に戻らないし、事前にこう制度を設計すればこうなるというif - thenの予測をするのは難しい。ですから、むしろその時々に法律をどのように決めていったかという「過程」における正当性が重要になる。

 八田さんもおっしゃられていたように、ソフトウェアの世界は離脱が可能です。これには二種類の意味がありまして、開発者でなくなるという離脱可能性もあると同時に、それを使わないという離脱可能性があります。しかし制度はどうでしょうか。たとえば国民として、パブリックコメントを出さない、投票をしないという自由はありますけれども、日本国民であることをやめるという離脱は難しい。ざっと見てきましたが、こういった点でソフトウェア設計と制度設計のあいだには大きなギャップがあり、前者の議論をそのまま後者に敷衍できるかというと非常に難しいといえるのではないかということなんですね。(図:規律社会と管理社会)

図:規律社会と管理社会
図:規律社会と管理社会

 もうひとつ今回、規律訓練型権力と環境管理型権力というキーワードがでてきました。この軸も検討しておきたいと思います。たとえば、マイクロソフトにとってユーザーにライセンスを守っていただくのは非常に重要なビジネスの根幹なのですが、大きくふたつのやり方があります。ひとつはライセンス使用許諾契約というのをつくって、ソフトウェアを最初に起動したときに、「同意します」というボタンを押していただくというものです。もうひとつはWindowsXPのように「アクティベーション」という仕組みがありまして、実際に購入したものでないことを自動で認識すると1ヶ月くらいで自動的に動かなくなってしまうという仕組みです。前者が規律訓練型の権力で、後者はおそらく環境管理型というわけです。

 規律訓練型というのは要するにルールを各人が守るということですから、合意が必要なわけです。「あなたはこれを守るといいましたね」というような合意を、たとえば個別の契約であったり、その他の法的根拠によって取り付けることになります。一方で環境管理型権力の場合には、その正当化にはふたつの議論がありうる。ひとつは東さんが前回の白田先生の回でおっしゃっていたような「何によって正当化されうるべきか」というような「べき論」です。それともうひとつ、現実問題としてそれはどのように承認されているかという問題を分けて考える必要があると思います。そしてここでは後者の問題を扱いたいんですね。

 たとえばCCCDの問題をみてみますと、これは技術的にコピーをある程度防ぐことができるということで、著作権を盾にレコード会社によってなかばユーザーを無視したかたちで正当化をされてしまった。ただ最近、これだと非常によく売れているiPodに音楽を転送できませんから、これではCCCDは売れないということになってきた。こうして、市場によってCCCDの正当性がリジェクトされ、この技術はいまのところ廃りそうな雰囲気です*8。このように、現実問題として環境管理型権力がどのように承認されるかというと、おそらく単純に技術的に可能であるか、それがマーケットのなかで受け入れられるかというところのバランスで決まることが多い。

 また革命権の議論が東さんの『情報自由論』にあったかと思うのですが、規律訓練型権力の場合は倫理の内面化による支配ということですから、それを覆すには動員をもってして革命とする。つまり広場に何十万人も集まったらそれは革命なんだというわけです。それに対して環境管理型権力では、そもそもその存在を技術的に乗り越えることによって革命が起こるのではないか。あるいは、マーケットから受け入れられないなどの理由で覆される場合もあるでしょう。

楠正憲

 ここまでの整理を踏まえて、論点を提示していきたいと思います。

 まず、はたしてオープンソース環境管理型権力と呼びうるのか。オープンソースというのはメタライセンス*9であって、それぞれのソフトウェアは個別のライセンス、つまり契約によって守られている。おそらくこの点での強制力に関しては、規律訓練型の権力だと思うんですね。これはどういうことかというと、もっぱらこれまで八田さんの話というのは、石橋さんも確認されていたようにプロジェクトリーダーに対してどう環境管理型権力として働くかという議論だったと思うんです。けれどもソフトウェアのユーザー、あるいは派生物を作成する人にとっては、たとえばGPLを破ってエンベッデドな製品を作ったとしても、「これってGPL違反だよね」とコミュニティで騒ぎになって、ソースを公開しなければならなくなるというリスクはあるけれども、こっそりとライセンス契約を破ることはできてしまうわけです。つまり、アーキテクチャ上それができないというような環境管理型の規制は、ここでは働いていない。ライセンスを破ったのがバレて、あとから揉め事になったりすることに怯えつつ、ライセンスを守るか守らないか悩むという意味では規律訓練型の権力だろう、と。ただ八田さんの論じていたのはこういうことでした。フォークの可能性を想定すると、他の開発者の協力を得るためにはオープンでフラットな開発スタイルをとらねばならない。こうした開発に積極的に関与する人間に対して環境管理型権力として働く側面は確かにあると思います。

 次の論点は、ソフトウェアの設計をそもそも制度の設計に敷衍できるのかという問題です。もちろんオープンソースから学ぶべきところは多い。道具と情報の公開を行い、知識生産の過程を形式知化してベストプラクティスを蓄積し、よき設計者・設計思想を育てるという手法は政策形成過程の改善にも応用できるのではないか。いわゆるコマーシャルソフトの開発あるいは開発環境においても、サンプルコードをいかに充実させていくか、あるいはドキュメントをどれだけ増やしていくか、どれだけツールを提供して生産性を高めていくのかということは重要なんですね。こうしたプロジェクトの生産性を高める、あるいはベストプラクティス(実践事例)*10を横展開する手法は、もっともっと政策形成過程にも応用できるのではないかというふうに思います。

 ただ一方でそう簡単にいかないところも多い。ソフトウェアの場合には多様性が認められ、離脱可能性があり、設計者と利用者との利益相反が小さい。これはどういうことかというと、おそらくソフトウエアを作る側も利用する側も、よいソフトウェアとはなにかについての認識はかなり一致しているはずなんですね。たとえば実行速度が遅いより速いほうがいい。いろいろなデバイスが扱えたほうがいい。もちろんエンジニアリング・トレードオフといって、たとえばOSのスケジューラを設計する場合に、スループットをとるかリアルタイム性をとるかといった両立しない要素もありますが、おおむね良きソフトウェアはなにかというベクトルにブレはありません。

 しかし制度はどうでしょうか。たとえば日本政府が気に入らないからといって日本人を離脱するのはなかなか難しい。政府がどんな決定やインプリメンテーションをしたとしても、そこには必ず利益相反がありますから、なにが良き政治的決定であるかについてはブレが生じてしまう。ですから、ソフトウェアの流通や頒布には、オープンソースのように一種の市場主義的なアプローチをしても混乱が生じにくいかもしれません。ですが、制度の場合には市場主義的にいきあたりばったりをしてしまうと、余計に混乱が生じる可能性がある。

図:論点1
図:論点1

 次に、設計者コミュニティの脆弱性という論点がありうると思います。設計者コミュニティというのは、おそらく皆でやいのやいのと議論していてもあまり意味がありません。要は実装している人間がとにかく偉い。これは前回石橋さんも講演で言っていましたが*11、なにか文句があるんだったら、とやかく言わずに実装してみせろというのがプログラマーの世界です。「いいだしっぺの法則」という言葉がありますけれども、いいだしっぺ同士が頑張っていけるという意味では非常にうまくまわる世界です。いわば好意的な無関心によって支えられているといっていい。

 しかし利害関係者が増えてきた場合には、これではなかなかうまくまわらない。利害関係者のなかにはソフトウエアをよりよくしようという動機だけで動く人ばかりではなくなります。たとえば自分の利益に基づいて行動する、あるいは下手をすると足をひっぱること自体がその人にとって利益になるような場合が当然あるわけです。そうすると、緩やかなコンセンサスでプロジェクトを進めるのが非常に難しくなってくるでしょう。さらにその利害関係者は影響力が強まれば強まるほど増えますから、そのプロジェクトは次第にスケールしなくなってしまう。こうした問題をどうするのか。

 また環境管理型権力における設計者または設計思想の正当性という問題についてです。現実には、規律訓練型の権力と比較して、より強制力が強い・効率的である・低コストであるといった程度の理由で正当化されている場合があるのではないかと思うんですね。あるいは倫理的なトレードオフという問題があって、たとえば環境管理型権力が自由の侵害になるかもしれないという理念的な問題が出てきた際、それと環境管理型権力によって犯罪被害を抑止できるという現実的な効果を、本当に天秤にかけてよいのか。こうした問題には議論の余地があると思いますが、現実的にはこういう事件を防ぐためには単に必要だから、というシンプルなロジックが適用されている傾向にある。これでいいのかという問題ですね。

 また八田さんは、ルールが書き換え可能であると同時に、その書き換えに対するアクセスの平等性・中立性を確保すべきと提案されていました。たしかに、ものづくり集団のコミュニティであればいいだしっぺの法則でいいと思うんです。しかし社会には非常に幅広い参加者がいる。たとえば目が不自由で文章を読みあげてくれるプログラムが欲しいひとが、自分で実装してナンボだからといって、C言語でゴリゴリと音声合成のプログラムを実装できるかというと、そうとは限らない。すると実装ありきによる社会参加としてしまうと、いろいろなものごとのプライオリティが実装能力のある人のところに非常に偏ってしまうという問題がある。これにはオープンソースとコマーシャルソフトで補い合うことで対処すればよいのですが、それを政治制度等に応用するときには必ずマイノリティの問題を考えねばならないのではないか。

 最後に、設計者の教育・成熟という話をしておきます。規律訓練型権力の場合には支配される側もその権力の哲学を内面化されているわけで一応は理解しているわけですから、より理解している度合いの高い人間をひっぱりあげ、支配する仕組みを設計する側にまわせば良かった。しかし環境管理型権力の場合というのは、そもそも無意識のうちに泳がされているという世界です、そのなかで設計者を今後もどうやって育てていくのは、そろそろ考えなければならないことではないかと思います。

 なぜこのような話をするのかというと、インターネット・エンジニアは30代後半から40代までの方が多いんですね。というのもその世代の人々が学生の頃インターネットを使うためには、ルーティング*12を知らなければいけなかったし、自分でMosaic *13をコンパイルできなければWorld Wide Webにアクセスできなかったわけです。この時代のユーザーがインターネットのエンジニアになっている一方で、すでに物心ついたときにはWindows95があって、ダイヤルアップでネットにつなぐことができた世代には、そうした苦労話的な経験もカルチャーもない。これと同様に、制度が環境管理型権力として定着すればするほど、支配される側はその存在に気がつかなくなっていくわけですから、その制度をメンテナンスすること自体の意義も、その方法への関心も薄れていってしまうでしょう。

 こうして次第に権力が隠蔽されていけばいくほど、それに対する文句も出なくなってくる。あるいはもっとこうしたほうがいいよという話も出てこなくなってきてしまいますから、制度をよりよくするためのフィードバック回路を形成することが難しくなるわけです。そこでどうすればよいのか。最近のWindowsの技術ですと、たとえばオンライン クラッシュ ダンプ解析サービスといいまして、システムがクラッシュして青画面になったとき小さいダンプファイルを吐いておき、次に立ちあがったときにはそれをサーバーに送信して解析し、最近はこのドライバで落ちることが多いらしいであるとか、あるいは落ちる件数がこの半年でどれくらいの件数になったのかを分析する仕組みがあります。このようなフィードバックを得るための仕組みを環境管理型権力そのものに組み込んでいかないと、制度が非効率になったり現実から遊離してしまうことに歯止めがかからなくなってしまうかもしれません。こうしたビルトインについて議論をする必要があるのではないか。以上でコメントを閉じたいと思います。

図:論点2
図:論点2

東:

 ありがとうございます。講演一回分の情報量がありそうなたいへん刺激的なコメントでした。そのせいで時間が早くも押してきていますので(笑)、八田さんから簡潔に答えるべきことがあれば。

八田真行

 それでは簡潔に応答します。まずご指摘のとおり、今回の講演では、なにか新しいものが生まれるフェイズ、つまりイノベーションの話をしていません。新しいものができた後、それを維持するためのプロジェクトをどう運営するかという話にかなり絞っている。ただイノベーションの話はさきほど村上さんと休憩時間にお話したので、第2部には議論の対象になるかと思います。

 次にオープンソース環境管理型権力かという問題ですが、おそらく楠さんと僕の定義がすこし違うだけかな、と。そしてソフトウェア設計の議論を制度設計に敷衍できるのかどうかですが、これはできないと私も思います。ちなみに講演のなかで制度設計という言葉は何度か使ったものの、あくまで環境管理型権力の条件を引き出すのが今回の講演の目的であって、制度設計を分析する経済学の枠組みから環境管理型権力について理解できるのではないかということです。ソフトウェア設計の議論をそのまま制度設計に当てはめようという意図はありません。

 次に、設計者コミュニティの脆弱性という問題。これはまったくその通りだと思います。ですから僕の講演の根底にあったのは、もうハッカー倫理のような規律訓練型のモデルは頼れないという認識なんです。ハッカー倫理なるものはもはや残っていない。その倫理にかわるものを何とかしてつくらなければならないというとき、個人的な意見としては新しいハッカー倫理を再定義しなくてはいけないのだと思う。それはどういうものかというと、偶然にせよ成立しているオープンソースの構造を維持すること、そのことに意義を見いだせるような倫理しかありえないのではないかと個人的には思っているんですよ。こうした動機付けは脆弱といえば脆弱ですし、その倫理観の脆弱さを補うためにこそ構造という話を持ち出したということでもあるんですね。

 またオープンソースとプロプライエタリの共存についてですが、僕も多様性の確保という視点から両者は共存したほうがいいと考えていることは講演で触れたと思います。お伺いしていて、基本的には楠さんのご意見と僕の意見はあまりズレていないと思いました。貴重なご意見をありがとうございます。




*1:註:いわゆる「汎用機」という呼び方はここから来ている。以下参照のこと。→システム/360 - Wikipedia

*2:註:以下の解説を参照のこと。→@IT:Insider's Computer Dictionary [ニーモニック]

*3:註:簡単な歴史については以下。→@IT:Insider's Computer Dictionary [UNIX]

*4:註:“What You See Is What You Get”の略。「見たものがそのまま得られる」という意味で、ワープロのように、モニタに表示されたものをそのまま編集することができる形式を指す。

*5PARC: Palo Alto Research Center

*6:註:以下の解説を参照のこと。→Intel 80386 - Wikipedia

*7:註:以下の解説を参照のこと。→Linux用語事典 [Wnn]

*8:註:avexの方向転換を手放しで喜べるか - SOUL for SALE

*9:註:isedキーワードメタライセンス」参照のこと。

*10:註:以下の解説を参照のこと。→@IT情報マネジメント用語事典 [ベストプラクティス]

*11:註:設計研第1回: 石橋啓一郎 講演(1)にて、OSIとIETFの標準化策定プロセスを比較し、「IETFは実装ありき」と論じられた。

*12:註:以下の解説を参照のこと。→IT用語辞典 e-Words : ルーティングとは 【routing】 ─ 意味・解説

*13:註:世界初のブラウザのこと。以下の解説を参照のこと。→Mosaic - Wikipedia

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