ised議事録

06-117. 設計研第4回: 共同討議 第2部(1)

「分業」と「コラボレーション」

鈴木健(以下、鈴木):

鈴木健
鈴木健
 それでは共同討議第2部に入りたいと思います。第1部の江島さんのコメントに、「メタメディアの権力性」という論点がありました。情報技術の発展とともに、結局はプログラム書く人がエリートで、書けない人が大衆化しているのではないかということです。そして井庭さんは、シミュレーションという新しいメディアを、誰でも使えるようにするツールを提案してくれました。しかし江島さんは今後ユビキタス化によって、さらにメタメディアの権力性は加速していくのではないかと危惧している。

 さて、そこでプログラマーのエリートといえばオープンソース界のハッカーたちだと思いますが、彼らと日常的に交流されている八田さんのほうから、メディアをつくる権力についてお話を伺いたいと思います。

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

 はい、井庭先生の今回の発表は、非常によくわかるものでした。私の理解はかなり偏った理解なのかもしれませんが、要するにエレメンタリーなレベルで<教える>ということが重要だということです。もちろん分野ごとに専門知識が必要なので限界はあるけれども、とにかくつくることの敷居を下げることが非常に重要である、というメッセージを受け取りました。

 そこで江島さんがエリート/大衆という図式で分けたことが、前回東さんのおっしゃった指摘と同じだと思ったんですね。東さんは「設計者ははたして誰か」という楠さんの問いに対して、結局普通の人々からすれば、プログラマー全体が設計者であって、プログラマーが権力を握っているということにすぎない、と指摘されていました*1。権力を握っているといいますか、デファクトスタンダードをめぐる競争によって設計者という主体は存在しないといっても、それはある種情報社会の実権を握っている人々のあいだでやり取りが限られてしまっている、ということだったと思います。

八田真行
八田真行
 こうした二分化された、つまりなめらかでない状況は非常に不毛である。この状況を打破するためには、やはり「つくる」こと、そしてエレメンタリーなレベルで<教える>ということが非常に重要なんだ、ということです。そしてこれは僕が設計研第2回で、正当化しうる環境管理型権力の4条件として提案した「再定義可能性*2に非常に直結していると思います。要するに、なにをやっているのかはわからないとしても、そこに参加できる回路を一応開いておくということ、あるいはその回路をよちよちでもいいので歩けるスキルを身につけさせるということです。

 ただ、ひとつ井庭先生にお聞きしたいことがあります。たしかにつくるということに関して、教育の重要性はよくわかったんです。ただ井庭先生のお話では、つくるというプロセス自体、イノベーションを誘起する一般的なプラクティスとして社会全体に広げていこうという意図が感じられました。およそイノベーションというのは、コミュニケーションが連鎖するコラボレーションによって遍在していく、とおっしゃっていたと思います。それについて村上さんは肯定的に捉えていましたが、楠さんも指摘されたように、これは分業との関わりを考える必要があると思うんです。

 たしかに自分の手を使ってつくるということは楽しい。しかしつくることと楽しいということは、あまり直結はしないと思うんです。自分のニーズを満たすためには、お金を出して誰かにつくって欲しい場合もかならずあるはずですし、そのほうが社会的な効率も上がる場合もある。このようなコラボレーションと分業の棲み分けに関して、井庭先生はどうお考えになっていらっしゃるのでしょうか。つまり、「つくる教育」の重要性はよいとして、これを社会全体に広げていくという意図があるとすれば、コラボレーションと分業の関係をどうお考えなのか。

井庭崇(以下、井庭):

 ここでいう分業というのは、「つくる」ことを他の人に任せてしまうという意味の分業でしょうか?

八田:

 ええ、そうですね。

井庭:

 近藤さんもおっしゃるように、既存のブラウザを一切使わないで、全員自分でつくる人になるかというと、それはないと思うんですよ。世界にモノが一個しかなければ、つくる人/使う人がきれいに分かれる可能性もありますが、実際の世の中にはいろいろなモノや考え方があるわけです。結局相互に分業していけば、誰かはなんらかのかたちでつくることに参加しているともいえる。たとえば企業に勤めている場合でも、もちろんつくることに参加していることにはなる。ただ今日提案したようなスキームによって、つくる/使うという二元論的な関係から、なめらかな関係になるのではないかということです。なぜなら情報社会化によって、いろいろな情報が結びつくことができるようになって、なめらかなことができるようになった。たとえば、開発者とコミュニティが、一緒に新しい機能のアイディアを出していく、というはてなの例もありました。

 分業はもちろんたくさんあるわけですし、それを否定するわけではありません。あるいは個人で考えるということもたくさんあるでしょう。八田さんがおっしゃっていたのは、分業とコラボレーションの総和は一定であって、コラボレーションが増えてしまうと分業が減衰してしまうのではないか、という量的な把握をされていたと思います。しかし僕の議論は、いままであったこうしたプロシューマー的な現象が、さらに開かれていく、なめらかになっていくという質的な議論なんですね。

鈴木:

 八田さんが、再定義可能性にとって、つくるという行為を通して教えるということは非常に重要だとおっしゃっていましたが、これはとても面白いと思いました。

 それから、つくる/使うの間のなめらかなものは何なのか分からないというお話がありましたが、僕は、「読む」という行為がそれにあたると思うんです。みんなが小説を書くわけではないけれども、みんな小説は読む。それと同じように、プログラムをつくるとか、モノをつくるというだけではなくて、「読む」という行為はけっこう重要ではないかと思うんですよ。

 そこで「プログラムを読む」というとき、井庭さんや江島さんの取り組むヴィジュアル言語は強力だと思うんですが、近藤さんはどういう印象をもたれたでしょうか。実際、普段からプログラムを読むという行為をよくやられていると思うんですけれども。

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

 えー、そうですね……。

鈴木:

 はてな? という感じですか?(笑) 江島さんのほうから先にコメントをいただけるようですので、どうぞ。

江島健太郎:

 まさに分業体制がなめらかになっていくという観点から、ASTERIAが使われている現場で起こっている例をご紹介したいと思います。いままでのシステムの構築、特に大企業のシステム開発の場合は、だいたいコンサルタントがユーザーの要件をヒアリングして、それをポンチ絵にまとめることからはじまります。あなたはつまりこういうことをやりたいのですねと。そして次に、SEと一緒に設計を考えていく。そこでコンサルタントのポンチ絵は具体的な要求仕様に落ち、最後はコーダー、つまりプログラマーに移る。そしてプログラマーが仕上げた成果物を、その逆順にユーザー側へ戻していくというプロセスをやってきたわけです。

 ところが、いまお話したイメージからもわかると思うのですが、ここには非常に大きなギャップがあるんです。コンサルタントはSEから上がってきたトンチンカンな成果物をみて、どこでどう間違えたらこんなことになるのかがわからないし、プログラマーはSEのことをバカにしているし、SEはコンサルタントとプログラマーの板ばさみで、誰も理解者がいないという状況だった。

 つまり、ソースコードはこの体系のなかで唯一誤解の余地のない合意書であり仕様書なのですが、残念なことにプログラマー以外には読めない宇宙語で書かれた文書ですから(笑)、最後にアウトプットが出てくるまではほんとうに全員が合意に達したかどうかを知るすべがなく、モノをつくることが不可逆なプロセスになってしまっていたんです。しかしASTERIAを使っている場面でどういうことが起きているかというと、まず開発をするとき、コードを書く人がユーザーのところにおもむいて、「こんな感じでいいですか?」と聞きながら、マウス操作でアイコンを並べてシステムを仮組みするわけです。すると、目に見えるポンチ絵*3それ自体がすでに動くコードとシンクロしていて、実行するとOracle DBからデータをもってきて、結果をメールで送ったりFTPで転送したりする処理までできる。つまり、井庭さんの言葉を借りれば、その場で「プロトタイプ」をつくるということです。実際に動くプロトタイプを素早くつくることで、イメージのズレが生じなくなるんですね。こうした状態でプロジェクトを進められるので、先に述べたような分業特有のストレスがない。いまイテレイティブな(iterative)開発*4という方法論があちこちでいわれますが、それはASTERIAのようなコミュニケーション言語の登場によって現実味を帯びだしているなと思います。

江島健太郎
江島健太郎
 このイテレイティブな開発という方法論の本質は、やはりコミュニケーションだと思うんですね。これこれをやりたいという要求を持っている人と、つくる能力を持っている人がひざを突き合わせてコミュニケーションできるかどうかが重要である、と。井庭さんの紹介していた、階層ではなく対等な関係で一緒にひざを並べてキーボードに向かうペアプログラミングと同じイメージですね。実際、大規模なシステムではユーザーとプログラマーがプロジェクト終了までに一度も顔を合わせないことがほとんどで、分業といえば聞こえはいいですが伝言ゲームみたいになっていると思います。これまでソースコードをユーザーが読むなんてことは絶対になかったんですが、グラフィカルな言語でプロトタイプをつくることが可能になって、ユーザーとプログラマーというぜんぜん異なる立場の人たちが、同じ会議室で同じ画面をプロジェクターで見ながらイメージを共有できるようになった。そして、その場でプログラマーの側は正常系シナリオの処理はつくってしまって、持ち帰ってから残りの例外系の部分など、細かいリファインをするという体制になりはじめています。

 このように、グラフィカルな言語の登場によって、ジョイントアテンション*5で成果物を眺めることができるようになったことで、分業はなめらかになりつつあると強く実感しているところです。

井庭:

 すごく面白い話ですね。私はずっと映像をやっていたので、それを例にいうと、映像編集というとついこの前まで、VHSやHi8などのテープを用いたもののことでした。映像を編集するには、デッキを2つ並べるか、あるいはダブルデッキという、左は再生、右は録画という機械を用いて、再生と録画を繰り返して映像を切り貼りしていくんですね。私はその時代に大学で学生コンサルタントというのをやっていましたが、なかなかこのテクニックは一部にしか広がりませんでした。

 ところが、PCでデジタル入力できるようになり、ノンリニア編集ソフト*6で、写真をコラージュするようにシーンを切り貼りするだけで、映像が編集できるようになりました。すると、あっというまに家庭にも普及するわけですよ。お父さんが運動会を撮って編集する、ということができるようになる。この違いはすごく大きいと思うんですね。つい最近まで、映像というのはテレビや映画館で流れているものであって、ほとんどの人にとっては消費する対象でしかなかった。それに対して、テクノロジーが進化して、自分でもつくれるようになった。自分がつくる側にまわるためのテクノロジーとして、PCの果たした役割というのは大きかったんです。これと同じような変革が、シミュレーションによってできるのではないか、というのが、今日の話の後半の着想だったんです。

 ただ、ひとつ誤解がないようにいっておきたいのが、今日の講演で1番目と3番目の話、つまり「コミュニケーションによってつくる」という話と、「シミュレーション」という話は、それぞれ独立の話しなので、別々に捉えてください。シミュレーションというのは、あくまで「コミュニケーションによってつくる」ことを支援するツールの一例として提示したのであって、社会の全員がシミュレーションを使おうという意味ではない。映像や文字といったメディアのひとつとして、シミュレーションもつくれるようになったらという話であって、あくまでワンオブゼムにすぎません。新しい可能性のひとつを提案したのが3番目のシミュレーションの話だったわけです。


鈴木:

 わかりました。では近藤さんお願いします。

近藤:

 はい。さきほど答えられなかったのですが、鈴木さんのおっしゃった、「つくる」と「使う」のあいだに「読む」という層があるのではないかという話についてです。たとえば、はてなPerlという言語をつかって開発をしています。そうすると、世界中で共有されているモジュールがたくさんあるので、有名なモジュールを読むことで美しいコードのつくり方を学ぶことができます。ただ、そこで期待しているのは、「美しいコード」というように、なにか創作性に関わることなんですよ。

 ところが、いまの話の流れはそうではないと思うんです。たとえばはてなでもペアプログラミングをするのですが、すると共有のフレームワークをつくって、交換可能性のようなものを確保することにやはり重点がいくんですね。つまり、誰がつくっても、ある程度予想のできるコードを書く必要があるわけです。またヴィジュアル言語の場合、自動生成されるコードはいつも同じように操作すれば同じような出力になります。すると、コードのレベルでは創作性はあまり発生しなくなって、そこに対する興味はどんどん薄れていくと思うんですよ。

鈴木:

 それはいいことなのか、悪いことなのか、どちらだと思いますか?

近藤:

 それはわからないんですが、少なくともつくる側としては面白くないわけです。なぜかというと、そこには自由度がないからですね。ただ、いまつくり手のメッセージはどこに込められつつあるのかといえば、それはコードではなくて、サービスのインターフェイスやその機能だと思うんです。それは「使う」ということによって受け取るメッセージですから、「つくる」と「使う」のあいだに「読む」という中間層が重要になるという話ではないという気がします。

*1:註:設計研第3回: 共同討議 第1部(1): 設計者は存在するのか/デファクト競争における正統性の不在

*2:註:isedキーワード再定義可能性」参照のこと。

*3:註:イメージ図、概要図の意。

*4:註:和訳すると「反復型開発」。以下の解説記事を参照のこと。→@IT:開発プロセス再入門(1)

*5:註:共同の注意、共同志向。認知発達心理学の用語で、幼児期に指を指して親と同じものを同時に見ようとすることを指し、コミュニケーションの重要な要素と考えられている。

*6:註:IT用語辞典 e-Words : ノンリニア編集とは 【nonlinear editing】 ─ 意味・解説

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