ised議事録

06-012. 設計研第4回: 井庭崇 講演(2)

題目:「自己革新的な社会に向けての教育とメディア」

設計研第四回:自己革新的な社会に向けての教育とメディア

1-2. コラボレーション――「コミュニケーション」としての「つくる」観

 ここまでの「つくる」とはなにかをめぐる議論をまとめると、それは「コミュニケーションとしての『つくる』」ということになります。これはさきほども触れましたが、単に個人や分業によってではなく、その複数人によるコミュニケーションがなければつくれなかった、という意味でまさに「コラボレーション」(協働)ということなんですね。

 ここでコラボレーションというのは、複数の人々が、ひとりでは決して到達できないような付加価値を生み出す協働作業のことを意味しています。コラボレーションに関するさまざまな研究によると、有効なコラボレーションが行われている組織やグループでは、単に効率的な分業をしているだけではなく、誰がオリジナルなアイディアを出したのかがわからないほどに、アイディアが行き交って共鳴し増幅するというプロセスが見られるといいます。

 こういったコラボレーションは、もちろんコミュニケーションによって行われます。しかし、単に情報伝達的なコミュニケーションがあるだけでは足りません。マイケル・シュレーグはこういいます。

「おそらく、コミュニケーションすることなしにコラボレーションすることはできないであろうが、だからといってコミュニケーションがあれば必ず効果的なコラボレーションへと導いてくれる、とはかぎらない」

「コラボレーションの環境においては、人々は、実際に行動するのと同程度の時間を、今、自分たちが何をしているのかを理解することに費やす。ボキャブラリーは正確に定義され、アイディアを説明する比喩は了解される。各人は自分だけではとうてい達成できなかったと思われる共通理解をつくり出す。」

マイケル・シュレーグ「マインド・ネットワーク」(プレジデント社、1992年 asin:4833414368

 つまり、「自分たちがいまなにをしようとしているのか」という位置づけがあったうえで、「それなら他のアイディアを持ってこれないか」といったアイディアも生まれ、コラボレーションが成功するといったことがいわれているわけです。

 それでは、コラボレーションについて、いくつかの形態に分類して考えてみることにしましょう。ここで考える分類は、1) ペア・コラボレーション、2) チーム・コラボレーション、3) オープン・コラボレーションの3つです。

1) ペア・コラボレーション

「ソフトウェア開発は、(リソースの限られた)創作とコミュニケーションの協調ゲームである。」

「最新の、特に「アジャイルな」方法論では、従来よりもコミュニケーションを重視する。」アリスター・コーバーン『アジャイルソフトウェア開発』(ピアソン・エデュケーション、2000年)

 まずソフトウェア開発の例ですが、プログラマーというと画面に向かって孤独に作業しているというイメージがあると思います。しかし、最近ですと「ソフトウェア開発は、(リソースの限られた)創作とコミュニケーションの協調ゲームである」といわれ、いまはイメージが変わりつつあるんですね。

 そのなかで注目されているのが、ペアプログラミングといわれる手法です。プログラムの開発を、1台のコンピュータを用いて2人で行うというものなのですが、まず「ドライバー」と「ナビゲーター」に分かれます。ドライバーは、コンピュータに対してキーボードで打ち込んだりマウスで操作し、実際にコードを書いていきます。そしてナビゲーターは、ドライバーの作業を横から眺めて、「そこは違うんじゃないか」といったミスの指摘や、「次はここだね」といった全体像と進め方の戦略を把握しておきます。そしてしばらくすると両者は交代するわけですね。一定時間で区切る場合もあれば、「ここは実装を担当してもいいかな」「ちょっとやらせてよ」といったきっかけで、即興的に交代することもあります。

ペアプログラミングとはひとりがプログラミングをし、ひとりが見ていることではない。・・・ペアプログラミングとは2人の対話によって、プログラムする(分析、設計、テストする)と同時にプログラムをよりよくすることである。」

「私の経験では、ペアプログラミングは仕事を2人に割り振って結果を結合するよりも生産的である。」

ケント・ベック『XPエクストリーム・プログラミング入門』(ピアソン・エデュケーション、2000年asin:489471275X

ペアプログラミングは、互いの役割として弱い部分を補うことで相乗効果を生み出している。」

ウィリアム・C・ウェイク『XPエクストリーム・プログラミング アドベンチャー』(ピアソン・エデュケーション、2002年 asin:4894713691

 重要なのは、頭のなかで考えていることをコンピュータ上に実現されているプログラムにするという外部化、そしてそれを見て理解するというプロセス以外に、となりにいる人と会話をする、つまりコミュニケーションをするという点なんですね。たとえばいま自分がなにをしているのか、そして行き詰ったとしたらなぜ行き詰っているのかと考えると、突然キーボードを打つ手が止まってしまいます。すると、ペアの相手は不思議がる。そこで「どうしたの」「あの変数ってどういうものだったっけ」という話になれば、隣りの人が「それはこうだ」「ちょっと調べてみよう」と会話がどんどん連続していくわけです。そして、つくるということが促進されていくということになる。しかもプログラムを書いている人というのは、主導権は持っているけれども、その人だけで書いているわけではないんですね。横から口を出していくことで、どっちが著者かといった話ではなく、それがブレンドされたかたちになっていく。

 こうしたペアプログラミングは、広い意味でのプログラミング・分析・設計・テストを行うにあたって、別々に仕事を割り振る分業よりも、質が高かったり生産的であるといわれています。ポイントは、互いの弱い部分をその場その場で補いながら相乗効果を生み出しているという点にあるわけです。ペアプログラミングは、ふたりで行う最低限のコラボレーション、つまりペア・コラボレーションの格好の例だと思います。

 ではこのようなものはソフトウェアの世界だけのことかというと、必ずしもそうではありません。コラボレーションについて書かれている『マインド・ネットワーク』という本のなかに、ペアライティングという話が出てきます。ペアライティングという言葉は出てこないんですが、それはこういうものです。

ワシントン・ポスト紙の記者だった私は、しばしばほかの記者と共同で記事を書いていた。……ある日、締め切りが前倒しされて、いつもの方法で共同で記事を書くための十分な時間がなくなってしまった。そこで、私と同僚は、キャスター付の脇机の上に置いてあったキーボードの前に並んで座り、まず私がリード文を書き始めた。同僚が修正を提案すると、私がそれに同意してタイプしていった。私はタイプしながら彼と話し合っていた。すると彼は「ちょっと待った」と言って私からキーボードを取り上げ、自分でタイプし始めた。今度は、彼が原稿を書くそばから、私が意見を言う番だった。しばらくしてインスピレーションがひらめいた私は、再びキーボードを取り上げ、主導権をとった。……」マイケル・シュレーグ「マインド・ネットワーク」(プレジデント社、1992年asin:4833414368

 ここで語られているのは、締め切りに追われた新聞記者たちが、一緒にふたりでコンピュータの前に座ってペアプログラミングさながらに記事を書いたということです。片方が書いては、もう片方が、いやそこは違うんじゃないか、と口を出す。しばらくするとキーボードが自然と交代して、かちゃかちゃとやりだす。そしてインスピレーションを受けたもう片方がキーボードを手に取る、というプロセスですね。

 そしてその記者はこう語っています。

「この原稿を共同で書き上げたプロセスの全体は、私がこれまで経験したことのない新しい社会的・専門的な相互作用だったと言える。しかし、それは理にかなっており、非常にうまくいった。でき上がった記事は中身の濃いものだったし、またそれぞれのもっていた異なるアイディアや視点が、原形をとどめなくなるほどにはごた混ぜにならずに、ほどよく組み合わされていた。キーボードを共有して書いていくというこのやり方は、私とほかの数人の同僚記者たちの間ではコラボレーションのごく日常的な方法となった。」(前掲書)

 すると、いままで書いたようなものとは異なる、お互いの考え方がうまくブレンドされたいいものができたと彼はいいます。そしてこのコラボレーションは日常的に行われるようになったということです。このように、ペア・コラボレーションは単にソフトウェア開発だけではなく、ものを書くときにも役立ちそうであることをイメージしていただけたかと思います。

 また後ほど触れますが、私の研究室では「ペア・モデリング」ということをやっています。このように、「ペアでやる」ということはもっといろんな分野で試されていいのではないかと思います。


2)チーム・コラボレーション

 つぎにチームでのコラボレーションの事例を見ていきましょう。いわゆるコラボレーションと世の中でいわれているものはこれですね。複数の人数、たとえば5人、6人、もっと多い状況下で、メンバーたちが協調して相乗効果を生み出しつつ、新しいものをつくっていくのか。そのときに用いられる有名な手法は、実は、コミュニケーションの連鎖をうまく引き出す仕組みになっています。ここでは、ふたつ紹介したいと思います。

図:チーム・コラボレーション
図:チーム・コラボレーション

 ひとつめの手法は、「ブレイン・ストーミング」です。たとえばコンセプトや商品のアイディアを考えるときに使われます。

 これにはいくつかのルールがあります(図:チーム・コラボレーション)。まず、創造的思考は2段階で分けて考えるとよいといわれます。ひとつは発散思考、つまり、とにかくたくさんアイディアを出す、アイディアの断片を出していく段階と、それをまとめる収束思考の2段階ですね。そしてこのブレイン・ストーミングというのは前者の発散思考にあたります。とにかくたくさんのアイディアを出す場をつくり、他人のアイディアは決して批判せず、どんどん上乗せして相乗効果を高めていってアイディアの嵐を起こすというものです。

 そのためのルールとして、「判断の先送り」「自由な展開」「質より量」「組合せと改良」というものが挙げられます。「判断の先送り」というのは、いいか悪いかはあとで判断して、とにかくアイディアを出そう、という意味です。「自由な展開」というのは、緊迫した状況をつくるのではなくて、自由に思いついたことを発言できる場にするということ。私の経験では、音楽か適度な雑音、そしてコーヒーがあると、だいぶ雰囲気が変わってきます。「質より量」とは、文字通りとにかくたくさんアイディアを出しましょう、という考え方。そして「組み合わせと改良」というのは、アイディアを組み合わせたり改良したりして、どんどん上乗せしていく、ということです。

図:シナリオ・プランニング
図:シナリオ・プランニング

 紹介したいもうひとつの手法は、「シナリオ・プランニング」*1という手法です(図:シナリオ・プランニング)。プランニングという名前ですが、よい計画を立てるということを目的とするのではなく、計画をみんなで立てるということに重点がおかれます。複数人で未来像について語り合うプロセスのなかで、各人が学ぶ、あるいは組織が学ぶということです。

 つまり、アウトプットとしての計画はさほど重要ではなく、プロセスとしての計画が重要だということです。みんなが知恵をしぼって計画をすることで、たとえば自分はこういうことが起こると思う、なぜならこういういま市場の環境になっているからだ、といったような話をどんどんしていくわけです。みんなが思っていることを表に出して、自分たちが将来危機的な状況に陥らないためにどういったシナリオが考えられるかを議論する。そうやって複数のシナリオを立てると、どのシナリオが起きたとしても対処できるような、組織づくりや戦略立案について議論されることになります。ここで重要なのは、未来の予測をするのではなく、「未来がどのようになるのか」や「その未来がなぜ起こるのか」について徹底的に語り合うことで、組織の各メンバーのメンタルモデルを柔軟にするということです。これを可能にするのが、プロセスとして計画を捉えるということなんですね。これも、コミュニケーションの連鎖を引き起こす手法の格好の例といえるでしょう。


3)オープン・コラボレーション

 最後にオープン・コラボレーションとして、一番有名なLinuxオープンソース開発の例を挙げておきます。オープンソースというのは、誰でも参加できるオープンな状態でつくられていったわけですが、実際のところ改良されなければオープンソースである意味はありませんね。ソースが公開されているだけでは意味がなく、それを他の人が拾い上げてつくり変えていく。そういう連鎖が起きて初めて、オープンソース開発の意味があるわけですね。Linuxはまさにその連鎖に成功した非常に面白い例で、設計研第2回では、このオープンソースがソフトウェアの世界に限らず、どこまで適用できるかが議論になりました。

2. 「つくる」を重視する教育

 以上、コラボレーションというものの具体的なイメージを掴んでいただくために、ペア・コラボレーション、チーム・コラボレーション、オープン・コラボレーションについてお話ししてきました。「コミュニケーションの連鎖によってものをつくる」ということのイメージができたのではないかと思います。

 そこで、今日2つめの話題に入りたいと思います。それは教育です。つまり、こういったコミュニケーションの連鎖のために、いかなる教育がありうるのか。私は大学で研究と教育をしているわけですけれども、授業やカリキュラムを設計するときに、今後どこに重点を置けばよいのかを考えます。そこで、こうした話題についてお話したいと思います。


「つくる」ことに重点が置かれる

 まず第一に、これからの教育は「つくる」ことに重点が置かれるのではないかと思います。いままでの教育では、いろんな知識を知って世の中を正しく見るということ、あるいはしっかり分析できるようになるということに重きが置かれてきました。しかし、これからはそれだけではだめで、つくることができなければならない。もちろん、「つくる」ためには、結局ものを知らないといけません。しかし、インプットを先にやって、後に卒業論文としてアウトプットしましょう、という普通の順番ではなくて、の向きを逆転させたいわけです。つまり、アウトプットを出すことに重きをおいて、そのためにはなにが必要かを逆算して考え、学びながらアウトプットを行っていくというスタイルが重要だと思うんですね。

 また「つくる」というとき、今日のこれまでの議論を照らし合わせて考えてみると、コミュニケーションの連鎖によって複数人で大きなものをつくる、ということが重要なわけです。そうすると、個人がつくるというときには、その人の「つくる能力」のスキルアップが必要だという議論になる。たしかに、それはそれで重要です。しかし、これからはそれに加えて、コミュニケーションの接続性をいかに高めていくか、どうやって場づくりをするのかという能力の育成が重視されていくと思うわけです。


「教える、教わる」ではない関係性

 そこで、大学での私の試みを紹介します。私は「コラボレーション技法」*2という授業を担当しているんですが、授業のはじめに私は必ずこういいます。「この授業ではコラボレーション技法について私は教えません」と。どういうことかというと、結局コラボレーションのやり方は人によって違うわけです。その人なりのやり方があってしかるべきで、それを、授業内外で行われるグループワークによってつかんでください、ということなんです。私は私なりのやり方や、先人たちのやり方の紹介はするけれども、それはあくまでヒントにすぎなくて、答えではありません。それを教わって覚えても意味がなくて、本当の意味の学びは、自分が実際に試行錯誤して体得するということだ、という話をしています。

 そうすると、従来の「教師(教える)・学生(教わる)」という関係は変質を求められます。たとえばブレイン・ストーミングを授業で試してみるとき、すでにその知識を知っている人が、知らない人に伝達するというかたちにはなりません。自分たちなりの答えをつくっているところに、私は助言をしていきます。あるいは、SA(授業スタッフ側の学生)が一緒になってそこに参加する。しかし私が「正しい答え」というものを知っているわけではありませんし、ブレイン・ストーミングに客観的なな正解があるわけでもない。ここで教員は教える側というよりは、同じ目的に向かって試行錯誤に参加するという構図になるわけです。教員は、ちょっとしたコツをその場その場で提供していくことなるのです。

図:「教える、教わる」ではない関係性
図:「教える、教わる」ではない関係性

 たとえば、「新しいタイプの目覚まし時計について考えてくださいというテーマを出します。教室のメンバーをいくつかのグループに分けて、とにかくブレイン・ストーミングでいろんな種類の目覚まし時計を考えてもらうんですね。ひとりで考えていると、5個とか10個出てきて限界なんですが、皆で話し合えば、「そういう視点があるのか」とイメージが連想されていって、いろいろなものが出てくる。あるいは「面白い」ものにはどのような種類があるのかを考えてももらって、それぞれ面白いというものを20個出して、自分たちなりの分類カテゴリーをKJ法でつくっていく。こうしたグループワークを1時間半の1コマのなかですることで、ひとりでは考察できないものをみんなでつくったという感覚を得ることができます。

 今年は60人ぐらいのクラスで制限して小さくやっているんですが、去年は170人で授業をしました。大講堂でKJ法をやるのは、結構難しいけど面白い(笑)。机はないし、椅子は動かせないので、どこでやろうかと、大講堂を見渡すと、そこには、広大な舞台が。。そうまさに、一番広いところとしてステージを使うわけです。ステージの前のほうで、床を使って寝そべったり座ったりしながら、アイデアを書いた付箋をペタペタ皆で貼っていく様子は、さながらかるた大会のようでした。

 最終的には、グループごとの提案をしてもらうんですが、去年は「魅力的な場を提案してください」というテーマ、今年は「宇宙時代の生活社会をデザインしてください」というテーマでした。これらは抽象的なテーマです。そもそも魅力的な場といっても、誰にとって、どういう魅力なのかがわからない。場とはなにか、ということもわからない。あるいは、宇宙時代や生活社会とはなにか。こうした問いをグループのなかで全部議論しながら、アイディアも考えていってもらう。最終発表会では、映像や劇を交えたり、配布物を配ったりもします。

 つくるということを重視すると、授業は必ずこうした構図になっていくと思うんですね。また、つくる教育というのはたとえば芸術系で行われてきましたが、あくまで少人数の規模で行われてきたと思うんです。この規模をいかに拡大していくことも課題だと思います。


ペアやチームで取り組む

 またソフトウェア開発やコンピュータ・シミュレーションの開発といった場面になると、ペアでやるにはプログラミング能力以外のスキルが必要になってきます。ソフトウェア開発が「創作とコミュニケーションのゲーム」であるとすれば、大学教育もコミュニケーションを重視しなくてはいけません。たとえばデンマークのアールボルグ(Aalborg)大学では、情報科学科がソフトウェア設計とコミュニケーション・スキルの2本柱を立てているそうです。ここの学部長の方は、いままでプログラマーというとひとりで黙々と作業するという教育をされてきたので、実際に職場でもそうなってしまっている、といいます。しかしうちの大学では、プログラムだけではなくて、他の人とペアで作業をやっていく、チームでのコラボレーションがうまいということを強みにした人材を社会に輩出したいといっています。

コミュニケーションの連鎖を支援する

 もうひとつ、教育のなかでコミュニケーションが連鎖していくためには、それに参加する人がどのようなことをどのように語ればいいのかを知る必要があります。しかし、たとえば建築のような専門分野があったとき、なかなか素人や初心者は設計に参加できません。そこで、初心者でもその語りの連鎖に参加できるための語彙を提供しようというとき、「パターン」という考え方があります(図:「つくる」ためのノウハウの記述と共有)。

図:「つくる」ためのノウハウの記述と共有
図:「つくる」ためのノウハウの記述と共有

 たとえば一般市民が建築や都市設計のプロセスに参加することができるために、クリストファー・アレグザンダーはパターン・ランゲージ*3というものを考えました。これは253ぐらいのパターンで都市はできていると抽象化して定義を行うことで、建築家の玄人のノウハウをパターン化するわけです。たとえば玄関はこういう関係性で成り立つ、廊下というのは部屋と部屋をつなぐものである、といった関係性がすべてパターンで定義されている。そういったものを定義してあげることで、いままで共通の言葉を持たなかったユーザー側が、建築家に対して提案をすることができるようになるというものです。非常に面白い試みだと思います。またエリック・ガンマという人は、そのパターン・ランゲージの考え方をオブジェクト指向のソフトウェア設計にも適用して、デザイン・パターン*4というものを提案しています。

 こうしたパターンの考え方は、建築やプログラミング以外の分野にも適用可能ではないかということで、井庭研究室ではシミュレーションモデル作成のパターンというものを研究しています*5。また体験学習ゲーム(ゲーミング・シミュレーション*6)、つまり研修や小中学校で行われるゲームの作成パターンを抽出してみる試みなどをやっています。

 パターンをつくることは、ノウハウを抽象化して共通言語化することといえます。それによってと他の人たちが使うことができ、コミュニケーションの連鎖に参加できるようになるわけです。これは教育とメディアの中間にある話ですね。

*1:註:キース・ヴァン・デル・ハイデン『シナリオ・プランニング』(ダイヤモンド社、1998年 asin:4478490252

*2:註:井庭崇 SFC担当科目 (2004年度)「コラボレーション技法」

*3:註:isedキーワードパターン・ランゲージ」参照のこと。

*4:註:以下の記事を参照のこと。→@IT:オブジェクト指向の世界 (7)

*5:註:井庭研究室 研究成果の対外的なアウトプット (2004年度)「ゲーミングのタイプとパターン分類:学習ゲームの作成を支援する」(赤石 真依, 野田 尚子, 斎藤 卓也)

*6:註:ゲーミング・シミュレーションとは、あるゲームプレイを通じた、複雑なルールや制度の学習や研修に用いる手法のことで、社会学・コミュニケーション論・教育学の研究プログラム。現在の日本シミュレーション&ゲーミング学会では、その枠に留まらない幅広いゲーム関連、シミュレーション関連の研究が参加している。書籍としてはキャシー・スタイン、グリーンブラッド『ゲーミング・シミュレーション作法』(共立出版、1994年 asin:4320027043)などを参照のこと。

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