|
|
|
|
|
|
|
|
最初からとばしていますね。危険（Risky）で、イカれてて（Crazy）、少しホット（Sexy）な学習環境って、どないなことやねん！って感じですが、あまり意味はありません。要するにお題にキャッチーなコトバをつけて、人をアッと言わせて、このページを読んでもらうことが目的だったわけで、別に、たいした意味はないわけです。 要するに言いたいことは、「学習者がハラハラドキドキしてしまうような学習の場をネットワーク上につくるには、どうしたらいいか」っていうお話をしたかったのです。 さて、最初から意味不明な感じになってしまいました。 ところで、この話をする前に、二つだけ断っておかなければならないことがあって、まずひとつめは何かっていうと、これからお話しする話は、別に全然学問的じゃないってことです。要するに、僕の経験から、こんなことが言えるんじゃないかなってことです。あくまで「From my experiences」。いわゆる経験則であって、法則ではありません。もちろん、そんな理論があるわけでもないのです。 でも、だからといって、あまり意味がないとは思えないのです。 思えば、これまでいろいろな学習環境をネットワーク上に構築するプロジェクトに僕はかかわってきました。もちろん、周辺的にかかわるだけではなくて、僕自身もいくつかのプロジェクトでかなりドップリとかかわってきたところもあります。そして、これからもいろんなオモシロイことをタクランデいくと思います 少なくとも、僕がメインでドップリつかったプロジェクトで構築した学習環境に話を限って言えば、それは、まだまだ「学習者がハラハラドキドキするレヴェルのもの」ではないです。これは僕の力不足です、本当に申し訳なく思っています。でも、経験というのは確実に僕の中に蓄積しています。で、その経験から「こんなこといえるんちゃいまっか」ということを書こうと思ったのですね。 というのは、最近、いろんなところで、「コンピュータを用いた共同学習プロジェクトをやりたいー」っていう声を聞くんです。で、そういう方々に僕が少しでもお役にたてたら、と思って書きたいわけですね。 まず、そうしたプロジェクトの＜組織論＞みたいなものから確認しましょう。たかが、組織論とあなどるなかれ。これが結構重要だったりするのです。
まず、１から説明するとして、。だいたい、「ネットワーク上で共同学習しましょうよ！」みたいな話は、個人ではなかなか達成しにくいんです。なぜなら、作業量が膨大すぎるし、また厳密にいうと、CSCLの理論がよっている認知科学の理論が、いろいろな人々のかかわりを求めてしまうんです。 たとえば、近年の学習理論は、学習者が実際に社会に偏在するコミュニティに参加していって学ぶというモデルをもっています。コミュニティがあるってことは、そこに見えるカタチであれ、見えないカタチであれ、様々な社会的背景をもった人々がかかわることになります。だから必然的に、こうしたプロジェクトは、様々な人々の共同作業として達成されます。 要するに、協同学習をしかける側もコラボレーションとしてこれを達成してしまうという宿命にあるのです。 ２に関しては、デザイナーとプログラマーのところだけは注意した方がいいような気がします。プログラマーは、プログラムをする人。デザイナーはWebなどのインタフェースを整える人です。もちろん、一人でこの二つを兼ねてしまうことは可能ですが、多くの場合は、これは別になることが多いようです。ていうか、プログラマーって人は忙しいから「絵は他で描いてよー」って言われちゃうことが多いと思うのですね。 ３に関しては、CSCL研究ではよく言われることです。CSCL研究っていうのは、はじまってずいぶんたつのですが、最近、問題になっていることがあります。それは何かっていうと、CSCLシステムをしかける研究者の手をはなれたCSCLは成功する可能性が低いってことだと思うのです。これはクリティカルですね。 要するに、Collaborative Learningが何かってことに興味関心のない人の間には、なかなか普及しないし、導入されてもなかなかうまくいかないことが多いのです。それはもしかしたら、テクノロジカルな理由かもしれませんし、CSCLをしかける側のマネジメントの稚拙さによるのかもしれません。よくわかんないんだけれども、いずれにしても、現段階では、CSCLのカンガエカタみたいなものを少しでも共有していた方がいいように思います。 ４に関しては、完全に経験則ですが、よくあるハナシです。研究者＝研究するだけ人、実践者＝実践だけする人というタイトな役割分業を認めてしまうと、まぁ、そうした役割分業もある程度はシカタないとは思うのですが、お互いの活動がドンドンと不可視になっていき、そこにモノスゴイ境界（Boundary）ができてしまうことが多いです。境界がはっきりするということは、相互不可侵みたいなハナシになって、対話の可能性も限りなく少なくなってしまうわけですね。だから、お互いの専門性を認めつつも、基本的なプロジェクトの達成は、コンセンサスをとりながら行った方がいいと思います。 ５に関しては、要するにCSCLをやる人は、自らもCSCLした方がいいってことです。これには、「Teacher as learner」的な側面もありますね。自分がCSCLをやることによって、CSCLがなんたるかがわかるし、段々と感覚みたいなモノがついていくような気がします。 また、明示化（ドキュメンテーション）も面倒くさいですが、やった方がいいです。CSCLツールでコミュニケーションしていれば、自然にアトに残るドキュメントは残りますので、そんなに気張る必要はないですが、これは重要に思います。なぜかっていうと、要するにCSCLには多くの人々が絡んでくるわけですね。多くの人々が「どのようなタイミングでどのようにに動くのか」っていうのは、キチンと把握しておかないと、非常に苦労することになるし、コンフリクトの原因になることが多いです。マックス＝ウェーバー的官僚制みたいで、あんまり好きじゃないんだけれども、ドキュメンテーションは、非常に重要です。 以上が＜組織論＞的な側面です。で、次に、いよいよCSCLの導入です。まず、CSCLを導入するときに、一番最初にやりたいことは、＜ヒアリング＞です、要するに＜調査＞。＜ヒアリング＞っていっても、アルクじゃありません、僕は先日からこれで学習をしているけれど、それじゃないんです。 ヒアリングの過程の詳細をお話しする前に、なぜヒアリング、あるいは綿密な調査が必要になるかってことも重要なことなので、お話ししておきます。 これは要するに、モノをデザインするってコトは、モノをつくるだけでハナシは終わらないからです。これはテリー＝ウィノグラードという人が言ったコトバなのですが、「デザインとは、モノとそのモノが使用される状況をつくりだすこと」を言います。そして、開発されるモノと同じくらい大切なのは、＜モノが使用される状況＞であることが多いのですね。 しかし、少し考えてみるとすぐにわかることですが、この＜状況＞というヤツは、ホントウにつくりだせるのかは非常に不安になってしまうシロモノです。＜状況＞とは空間であり、道具であり、そこに偏在する他者であり、学習を企画する自分の位置なわけですから、これをつくりだすのはホントウにムズカシイ。だから、せめて「これまで現場がどういう状況であったのか」ということを、正確に把握した方がいいです。 ヒアリングでは、以下の事柄に留意することが重要になります。
１に関しては、現場理解のデータとしては、一番基礎的なものですね。「どのような方法論を用いてこれを明らかにするのか」は、ここでは詳細を述べませんが、これらについて十分データをそろえておくのは重要なことです。現場の社会的状況や文化的状況っていうのは、一朝一夕でわかるものではありません。経験をつんだフィールドワーカーがキチンと定まった期間で調査をして、明らかにする必要があります。 この際、特に忘れがちなのが、現場の空間配置です。これは、できれば図面を描いた方がいいと思います。「コンピュータを用いた協同学習をするのに、なんで空間配置が重要なのだ」と思われる方もいらっしゃると思いますが、これはあとで聞いてくるものなのです。協同学習が生起しやすいように、開発物やコンピュータやその他のデバイスを配置する必要があるからです。 ２は要するに、現場で実践を行う実践者のビジョンを明らかにしておくということです。教育っぽくいうのなら、「学習者にどのような知識を獲得してほしいのか？」あるいは「学習者にどのような技能を獲得してほしいのか？」を明らかにしておくということです。これがあいまいですと、あとから評価ができないってことになりかねません。評価ができないってことは、学習をマネジメントもできないってことです。最近、マネジメント理論っていうのが僕のお気に入りで、よく読んでいるのですが、マネジメントの常識みたいです、これは。 また、学習者が学習に取り組む際、「これに取り組めば、オイラはこんな風になれるんだ」というイメージを提示しておくことは、非常に重要なことです。これが不可視ですと、学習者は、「なんでこんな面倒くさいことをやるんですか？」となってしまうわけです。 ３はできればでいいのですが、現場の実際の学習場面を観察して、どのようなコミュニケーションチャネルになっているか、ソシオメトリクスをなしているかを、ある程度、把握しておくと、かなりいい感じです。なぜかっていうと、ネットワーク上で学習が進行した場合に、そこでの学習をコーディネートするには、ある程度「学習者がどんな人物であるのか」を把握しておくと、かなり有利にかつ効果的にこれを行えるからです。 ４に関しても、なるべくリッチなデータがあればいいでしょう。開発物のインタフェースに何を採用すべきか、どういう風にそれを構成するべきか、そういうことをアトになってくると考えますね。そのときに確実に役に立ちますし、先の３にものべたとおり、ネットワーク上の学習をコーディネートする際にも、学習者の背景ってのは、なるべく知っておいた方がいいです。 ５と６は、ここまで述べたことをプロジェクト全員で議論する段階ですね。その際には、なるべく「学習理論があーだこーだ」というハナシよりも、より具体的に具体的にハナシをすすめることが重要になってきます。専門用語はなるべく廃した方がいいです。「あの教室の○○ちゃんは、○○だから、こんな風にするべきだ」だとかいう会話パターンが奨励されるべきでしょう。 なぜかっていうと、ここで抽象的なことを話してしまいますと、いっこうにハナシが先にすすまないってことがおうおうにして起こっちゃうわけです。また、専門用語は、具体的なハナシ、そしてそれに派生する開発物の具体的なデザイン像をときに、ぼやかしてしまいます。あくまで、そういうハナシは、その前の段階、つまりは先に記述した＜組織論＞の段階で終わらせてしまうのがいいでしょう。 また、最初から発展的にハナシをすすめることも重要なことのように思います。これは僕の持論ですが、少なくともこの手のサイエンスに関しては、基礎的な事柄をいくら積み重ねても、発展的な課題にたどり着かないような気がします。自然科学は違うのでしょうけれど、この手の実践的に人間がかかわるサイエンスでは「発展的なクワダテをおこすためには、最初から発展的に問題を設定し、それをクリアしていくこと」が重要だと思うのです。 たとえば、プロジェクトのこの段階っていうのは、現場の各種の制約が見えてくる時期なのですね。これは現場の制約なので、イタシカタない。で、よく陥りがちなのが、最初の理念を捨てて、小さく小さくハナシをまとめようとするってことです。これは僕がよくやってしまうことなので、自戒をこめて言っています。 とにかく、この段階では、プロジェクトメンバーが全員納得するまで、キチンとハナシを具体的にすることが重要です。よく「On-going design」とかいって、「プロジェクトの進行にあわせて、ハナシを具体的にしていきましょー、だから今はキチンとつめないでおきましょー」という風にしてしまうのですが、多くの場合、これは無理であることが多いです。なぜかっていうと、プロジェクトはいったん走り出してしまったら、サーヴィスをとめることってナカナカできないのです。それに、開発者にとってみたら、On-going Designっていうのは、一番イヤなパターンです。無限大にタスクが増えていくし、多くの場合、プロジェクトメンバーのリクエストはコンフリクトを起こすモノなので、そうした中で開発するっていうのは、非常にシンドイです。開発者が研究者である場合は、まだマシだと思うのですが、ソフトハウスのプログラマだったら、一番嫌います。 「On-going Design」っていうのは本来ならば、「システムに対してFormativeにimprovementがおこること」を言うのであって、「この段階でキチンとつめない」っていうのはちょっと違います。もちろん「システムに対してFormativeにimprovementがおこること」はいいことです。ですが、これは一番労力がかかり、一番時間がかかることであり、一番お金もかかることであり、一番開発者を泣かせることだっていうことを確認してください。確かに「On-going Design」は現在研究方法論として、多くの試みが行われていますので、それにチャレンジする場合は、別にこの限りではありません。 ７は、コンサルティングファームで言えば、一般に「Output」になるところです。要するに現場の「変革（Change）」の企画書でありますので、これはキチンとドキュメンテーションして、プロジェクトメンバー全員が共有する必要があります。あと、特に重要なところは、評価についてです。 一般に、評価っていうのは、開発とかデザインとかと同じくらいムズカシイです。これを行うためには、方法論に対する知識や技能と、観察力、労力が要求されます。でも、最低でもベータ版がでるくらいまでは、評価をキチンと行わないと、とてもユーザーが使えるモノは作ることができません。よく「学習を一方向的に評価したくない」とか「学習を評価することなんてできない」ということを聞きますが、少なくとも僕自身はこれに全く同意できません。 それはなぜかっていうと、いろいろ理由があるんですが、まず第一に研究のアカウンタビリティというか、そのプロジェクトのアカウンタビリティを果たすことであると思うのです。「このプロジェクトは、これだけのイノベーションを導入し、これだけの成果をあげた」と言えなくては、アカウンタビリティを果たしてるとは言えないと思うのです。第二に、それを使うユーザーの満足度を高めるためには、どうしても評価が必要になります。それをしないで、開発物をユーザにおしつけるのは、ちょっとなーと思ってしまいます。 次にいよいよ開発です。開発の際には、以下の事柄を特に重要視した方がいいと思います。
まず１から５ですが、これらすべてが「学習者の学習活動」が基礎になっていることに注意してください。よくネットワーク型の協同学習ツールを作る場合には、やれ掲示板、やれチャットだという風になりやすいですが、「実現可能な機能をすべて盛り込むこと」はデザインとはいわないのではないでしょうか。 学習者がそこで行う学習活動を一番最初に想定して、できることなら、そのフローをある程度明示化して、機能選定を行うことが重要です。重ね重ねいいますが、この部分を適当に行うと、「機能やインタフェースはあっても、ユーザーに使用されないもの」をつくることになりますので、注意が必要です。 また、「学習者の学習活動」を考える際には、「なぜここでインタラクションするのか？」「なぜここで自分の意見を表明する必要があるのか」「ここでインタラクションした結果は自分の何に役にたつのか」などを明示化するように、学習活動を構成する必要があります。そうしないと、とってつけたような、学習者にとっては、何の益もない学習を行わせてしまうことになります。これをふまえた上で、余計なものは何もひかず、何もたさずつくりこんでいくのがいいと思います。 繰り返しになりますが、何でもかんでもパッケージ化してしまうのは、デザインとはいいません。すべてに汎用の学習システムっていうのは、なかなかムズカシイし、それができたとしても、僕の経験上、学習者はそうしたものを忌避する傾向があります。 また、すべてをデジタライズする必要はありません。学習者がFace to Faceでインタラクションを行えるときには、「デジタライズすべきはどこかのか」をしっかり同定する必要があります。 ６はいよいよインタフェースの決定です。ここでは、デザイナーさんの活躍場面になります。よく見られる作業工程としては、いくつかデザイン案をもってきてもらって、プロジェクトメンバー全員でコンペティションをするのがいいのではないでしょうか。 ７は、一見トリヴィアルなように見えますが、かなり重要なことです。ネットワーク型のソフトウェアを作る場合には、それがインターネット標準の仕様に従っているかはチェックした方がいいです。 たとえば、メーラーというのは、通常、すべてのユーザーが自分の好きなメーラーをもっていますよね。また、インターネットである程度標準化されています。これを崩してインタフェースをデザインしてしまうと、まずユーザーには忌避されます。 また、デザインされたインタフェースによっては、学習者のオペレーションに対するレスポンスの悪さが生じてしまう可能性がありますが、これはかなり手痛い問題であることに留意してください。クライアントソフトならば2秒くらい、Webならば8秒くらいが、何のレスポンスなしでユーザーの待っていられる限界だと思います、経験的に。 これ以上、長くなると、ソフトウェアがフリーズしてしまったのではないか、うまく機能していないのではないか、とユーザーが疑うことになってしまいがちです。もし、レスポンスが悪くなる場合には、作業の進行中をあらわすスライダーバーなどをつけておくといいでしょう。 ８はいよいよネットワークの構成です。まず、基本的にひとつのマシンにはひとつのサーバという風にした方がいいと思います。お金はかかりますが、あとでトラブルがおきたときに原因を切り分けることができなくなってしまいます。また、管理もその方が楽です。 サーバーになるマシンには、値段は安くてもいいので、電源管理機能のあるサーバ用のマシンを購入した方がよいでしょう。ノートパソコンなどでサーバーを代用するのは、全くおすすめできません。それように内部ができていないので、フリーズの原因になります。 あとセキュリティも問題ですね。ゾーンを区切るとか、ファイアーフォールをたてるとか、いろいろ方法はありますが、これは専門的になりすぎるので、ここでは詳細を述べません。最低でもスパム防止とかTCPWrapperくらいはかけておいた方がいいと思います。 というのは、海外からの不正アクセスは案外多いです。僕もいくつかのサーバー管理をしていますが、ログを見ると焦ってしまうことが多いです。IP Addressが"0.0.0.0"からのアクセスなんかもあります。そりゃないべ！って感じですね。だから、あんまり神経質になりすぎるのはどうかと思うけれど、最低限のことはした方がいいのではないでしょうか。 サーバーの分散化については、たとえばデータベースサーバ、動画配信サーバなどという具合に、出来る限り分散化するといいと思います。また、最悪の場合は、Webサーバを別々のマシンにわけて、トラフィックを分散するシカケを用意した方がいいです。まぁ、これをやるとなると、かなりのスキルとお金が要求されますので、通常はそこまでしなくても大丈夫です。ですが、サーバーへの負荷は、いつも念頭において開発を進めないと、あとで大変なことになりがちです。 ９もトリヴィアルでいて、あとで気づくとエライことになります。一般に、OSとブラウザの無数の組み合わせによって、Webの表示のされ方は異なります。特に、MacOSは要注意ではないでしょうか。できれば、Cookieなどを取得して、自動でスクリプトを変形させるプログラミングを施したいものです。また、JavaやActiveXなどですが、これは環境によって、かなり怪しい動きをします。注意が必要です。 最後に、いよいよ開発がはじまりました。この際には、何に注意したらよいでしょうか。僕の経験からいうと、それは以下のようになります。
１に関してはそのまんまです。モックアップというのは、メーカーさんで言えば、「機能試作」の段階にあたります。要するに＜ミテクレ＞と＜主要機能の動作確認＞だけで結構です。モックアップは、アルファ版、ベータ版、最終版という具合にレベルアップしていきます。 ２は結構忘れがちなことなんですが、かならず行った方がいいです。業務用ソフトではないので簡単でいいです。TCP/IP上で使用しているプロトコルでリクエストを少しずつかけていって、どのあたりでサーバーが「グー」の音をあげるかを確認します。これをやらないと、あとでトラブルが起こったときに、サーバーのトラブルなのか、ユーザーの所業なのかわからなくなってしまいます。 ３に関しては、先ほども述べましたが、評価の部分にあたるところです。評価は大事です。しかるべき方法論をもって、しかるべきデータを採集した方がいいです。 ４はできるだけプロジェクトメンバーのコンセンサスをとりながら行った方がいいというオセッカイでした。 ５に関しては、これも忘れがちなことですね。一般にプログラマーとかデザイナーという人々は、お金をだしたら別でしょうけど、通常、システム管理を請け負いません。それは仕事の範疇にははいっていないわけで、オプションになります。 だから、このころからシステム管理内定者を、なるべくプログラマーとコミュニケーションをとらせるようにするといいのではないでしょうか。蛇足ですが、システム管理というのは、しょっちゅうサーバーが落ちるわけではないので、普段はやることがないのですが、落ちたときは最悪です。またユーザー登録も大変です。 さて以上、「To build a Risky, Crazy and Sexy Learning Environment on Network」ってお題で、全然学問的ではない経験則をツラツラと述べてきました。経験則とはいえ、当の本人はここに書いたことを「わかっちゃいるけど、できていない」ので、ホントウは経験則ではないですね、もはや願望であったりします。 こうして書いてみると反省するべきところばかりですが、これがすべてできたら、有森祐子じゃないけれど、まさに「自分をほめてやりたい」って感じです。 僕も明るく楽しく努力します。みなさんも「Risky, Crazy and Sexy Learning Environment」づくりにチャレンジしてくださいね。 |