2012年4月26日木曜日

LEGO Serious Play™ その4 構成主義、モンテッソーリ教育、Googleの創業者たち

Lego Serious Playについて、これまではその効果や価値について書いてきましたが、源流を辿ってみることにします。

はじめに言ってしまうと、LSPは構成主義 (Constructivism) の考えに基づいて作られたメソッドです。構成主義について真っ向から書こうと思うと哲学の世界に迷い込んでしまって、そうした議論になると自分の手に余るのですが、基本的な考え方としては、人間が自分の環境をどのように認識(構成)していくかを問うたものです。

教育的側面から見ると、学習というものを、教師から生徒への体系だった知識の伝達と考えるか、あるいは生徒が自力で物事を発見していく過程として捉えるか、という問題です。伝統的な学校教育が前者であるのに対して、構成主義は後者の立場にあります。

構成主義における学びとは、学習者があらかじめ持っている知識や興味を出発点として、ある理解を構成する特色と経験との間の相互作用として立ち上がるものとされています。言い換えると、出来上がった客観的、体系的知識を教師が植え付けるのではなく、学習者それぞれが持っている情報と学ぶ内容を紐付け、意味付けていくプロセスということになります。ここでは教師は生徒を先導するのではなく、その学習を促すファシリテーターという位置づけです。

こうした構成主義の考え方について、学習者が体系的な知識を身につけるには十分ではない、という批判や反駁を予想することは簡単にできます。もちろん、現実には体系的学習と、発見的学習とのバランスを見ながら実践していくことになるのでしょう。そして、その実践者としては貧困層や知的障害児への教育を行なっていたマリア・モンテッソーリという人物がいます。

マリア・モンテッソーリの名前を聞いたことのない人でも、彼女の考案したモンテッソーリ教育について聞いたことがあるかも知れません。特にここ数年、Googleのセルゲイ・ブリンとラリー・ペイジ、Amazonのジェフ・ベゾス、wikipediaのジミー・ウェールズなど、今のウェブ業界の巨人達がモンテッソーリ教育を受けていたことは有名な話です。Googleについての秀逸なルポルタージュ、"In the Plex(グーグル ネット覇者の真実)"でもこの事実は繰り返し強調されています。

恐らくこれは偶然ではなくて、以前にも書いたブリコラージュ的な方法論というのは、プログラミングと親和性が高いのですね。そして、レゴに関して言えば、LSPよりも前に、ピアジェと親交のあったシーモア・パパートという学者が、レゴ・マインドストームというレゴとプログラミングを組み合わせたおもちゃを開発しています。

この人がまたMITの教授であったことからも、アメリカの知的潮流の底流を見たような思いがします。実はわたしもモンテッソーリ教育を受けたクチですが、構成主義についてももLSPのトレーニングを受けてから知ったものですし、LSP経由でもう一度モンテッソーリに戻ってくるというのは、とても奇妙な感じがします。宿命的なものすら感じられるというか。

2012年4月22日日曜日

Studio2009はAK-47か

業界のデファクト・スタンダードのツールであるTrados。Studio 2009になってからインターフェースと設計思想ががらりと変わったせいで拒絶感を示すユーザがいました。未だに使っていない人も多くいます。

自分もあまり好きではなかったのですが、理由をよくよく考えてみると、作成者の想定した使い方しかできない(少なくともはじめはそのように感じられる)ことが根本にある気がします。

プロジェクト管理の視点のみで語ると、2007までのTradosは、洗練はされていないものの、WorkbenchとTagEditorの個別の機能を組み合わせると色々なことができました。「色々なこと」のなかには、試行錯誤できるパターンの数やバッドノウハウも含んでいます。結果として、受け取るファイルのデータ構造やテキスト配置が整理されていなくても、系全体としては何となく処理できてしまう特性がありました。

AK-47が過酷な環境でも動作するという話(リンク)は、これに近いものがあります。ゆとり、疎結合、遊び(可動範囲)といった領域をとっておくと変化へ対応できる可能性が増える。逆に系を構成する部品たちの精度と緊密性が高まると、意外と簡単な問題で躓いたりする。

この意味で、Studio2009を単独で見るとイノベーションのジレンマに陥っているように見えるのですが、TMSなどにより原文データが整理されたものになれば、一概にそう言えるものでもないのですね。いつまでもジャングルでゲリラ戦をやってるわけにもいかんので、別の戦場で戦いましょうというのが開発側の基本的な考えです。

しかし、より重要なのは、Studioが連携を図るTMSなどのシステムは、特定の課題を解決するためのツールとは異なり、多くの場合においてローカリゼーション・プロセスのリエンジニアリングを意味するものであるという点でしょう。