馴染みとは？/ プロミス
[ 179] SituatedSoftware -
[引用サイト] http://www.hyuki.com/yukiwiki/wiki.cgi?SituatedSoftware
|
私は NYU の インタラクティブ・テレコミュニケーション・プログラム (ITP) で教えている。 そこの生徒たちの半分は美学を重んじる技術者、もう半分は機械を怖れない芸術家であり、未来を見通すにはもってこいの場所だ。 やがてくる未来ではソフトウェアの生態系がかわると私は信じている。その生態系を、ここでは 馴染系ソフトウェア (Situated Software) と呼ぶことにしよう。特定の場面や文脈のために設計されたソフトウェアのことだ。馴染系ソフトウェアを作る方法は、いわゆるウェブ学派(かつて私がプログラミングを勉強した場所)のやりかたとは対照的だ。ウェブ学派はスケーラビリティや汎用性、完全性を美徳としてきた。 私の生徒達はウェブ学派の流儀をあっけらかんと無視し、それでいて面白いものをつくっている。ここ一年ずっと、私はそれが気になって仕方がなかった。まだ未完成な状態ではあるが、 このパターンについて説明しようとおもう。なぜなら、これと同じものを他所で見たひとがいないか知りたいのだ。 馴染系ソフトウェアと古典的ウェブ・アプリケーションの最大の違いは、数十人のユーザ向けのソフトウェアを作るのが非常に簡単になるという点にある。ユーザ数が数十人だなんて、現行の設計方式からするとありえない。小さなユーザのグループ向けにぴったり合ったソフトウェアを作るというのは、これまでだと地方の銀行や研究所の実験室での話だった。なにしろ費用がかかるので、ウェブ学派のアプリケーションは大人数を相手にすることに専念してきた。そしてスケールによる価値を手に入れた結果、別の種類の価値、特に社会的な価値はかやの外に置かれてしまった。 そのおかげで、特定のグループ向けに作られたソフトウェアにはいくつか嬉しい特徴ができる。まず作る側にとっては安くて簡単。スケーラビリティの問題が少ない。対象となるユーザにわかりやすいものにしやすい。逆に明らかな弱みもある。もともとの場所の外では使いにくい。もし後から大人数のグループを扱おうとすると弱い。ソフトウェアの寿命は短くなるかもしれない。 私の生徒達はいくらかこうしたトレードオフに甘んじた。とはいえ、ウェブ学派がとりくんでいる難題、高価なハードウェア、優秀なプログラマの不在、疎に分布したユーザなどは、もはや制約にはならない。 その溢れんばかりの社会的エネルギーをわかっていたのに、私は Teachers on the Run のもつ重要性をつかみそこねていた。これがうまくいったのは何かしら不公平な理由が色々とあったからだと自分に言い聞かせていた。利用者はプログラムした連中と知り合いだ。教授の名前データベースが前もって用意されていた。プログラマは学内のメーリングリストを使ってアプリケーションの告知をすることができ、プレスリリースやバナー広告が必要なかった。そして最低なことにスケールしないのだ。それがウェブ・アプリケーションが成功する必須条件だというのに。死亡決定。証明終。 昨秋私が教えていた Social Software という授業で、生徒達は小さな組になって何かしらのグループ間交流を支援するようなソフトウェアを作った。出発点を与えるため、ITP の学生に使ってもらえるものになるようプロジェクトをやらせた。この方式の第一の利点は単純: 設計者はユーザと同じ集団に属しており、したがって設計者自身が自分の直感を正しいとみなすことができる。ベータテスタは廊下でつかまえてくればいい。こうした利点のおかげで 「海を沸かす」 というような大言壮語へ走らずにすむ。 私は第二の利点を見落していた。授業のグループは何度も問題につきあたるのだが、そうした問題の一部は、社会基盤や文脈依存の情報という利点を活かして解決されていた。ウェブ学派のやり方にこだわっているとこうした利点を活かすことはできない。二つの戦略の違いは際だっている。 しかしどちらのプロジェクトもそうした仕組みを用意しなかった。かわりにただ不払いユーザを記録し、不払いだったら名前をだすと威嚇するに留めた。ユーザはみな ITP コミュニティの一人だからだ。コミュニティで恥を晒されるという可能性がアプリケーションの設計にくみこまれている。コミュニティや恥をかくことは、アプリケーションの枠組みの外側にあるにも関わらず。 どちらのプロジェクトでも古典的な更新通知の問題がある。ユーザは作業を中断して、見逃した更新がないよう気をつかわなければならない。ウェブ学派のアプリケーションでは、ユーザはサイトをブックマークし再訪するという前提のもと、あるいはメールでの通知をいそいそと読むという前提のもと、開発に億単位の投資がされてきた。しかし Schwab.com や eBay のような成功が広く宣伝されている一握りのサービスを別にすれば、ユーザは大抵 「まめにチェックする」 ことを嫌がるのだ。 これらのプロジェクトはすべて授業のもともとの条件 ... アプリケーションはコミュニティにとって有用であること ... を満たしている。そして当然の帰結 ... コミュニティはアプリケーションにとって有用であること ... を使うことにもなったのだ。 ソフトウェアの設計をする際、私達は常に個人の認知能力に依拠している。ユーザがマウスとカーソルを関連づけると仮定しているし、アイコンは意味がわかるものにする。私達がグループの認知能力をあてにすることは稀だ。しかし、実世界での私達はそうした力に依拠しているのだ。 ブレインストーミングをすると、グループは各個人が別々に考えたアイデアをまとめるより多くの方向性のアイデアをうみだすことができる。そしてグループの総意は、グループで一番ものをわかっている個人による推理より正しい場合が多い。グループはまた、自身についても多くを知っている。グループのメンバーは、他の誰に設計上の助言を求めればいいか知っている。ピンチのとき頼りにならないのは誰かも。正式な指名がなくてもこういう役割はわかる。社会的なグループのメンバーは、誰と飲みにいくのが楽しいか、誰に金を貸さない方が良いかを知っている。(大抵同じ人だ。) FAQ に文書化する必要はない。 ウェブ学派のソフトウェアはこの種の知識を無視している。それを明示化するのは難しいからだ。例えば大規模なメーリングリストではたった一握りの人間が議論を始め、大多数の投稿者はただそれに従う。より上のレベルでみると、たった一握りの人間が投稿し、大多数はただ黙って見ている。十年来の見慣れたパターンだ。にもかかわらずメーリングリストのソフトウェアはスレッドを始めたり続けたりするのを支援する仕組みを持たないし、大量投稿者と読むだけの人を区別もしない。 しかし、別の方法もある。ユーザがアイコンを見分けられるのと同じように、デザイナはグループがある能力を持つと仮定することができる。コードでそれを表現しなおす必要はない。共同購入で未払いをみつけたら、プログラムは単に 「未払い警告。処置せよ」 とメッセージを出すだけでいい。実世界のグループは何とかその問題を扱うだろう。ふつうはモラルに訴えかけるか、名声に傷がつくと言ってやるだろうし、極端な場合は未払いユーザを追放するだろう。 これはオフラインのグループで毎日起きていることと変わりない。しかしウェブ学派の語彙では、この解決策を間違っていると感じてしまう。なぜならそうしたウェブ・アプリケーションは暗黙の信用評価システムがあるとみなすことができないからだ。既存の社会的設備を使うため、馴染系ソフトウェアはウェブ・スケールのアプリのようにスケールはしないことが確定する。しかし同じ理由から、ウェブ学派のアプリにできないことができるのだ。 こうしてようやく私は馴染系ソフトウェアを現実的なソフトウェア開発の戦略としてとらえるようになった。「本物の」 アプリケーション開発が縮退したものではないのだと。Social Software の授業の中間批評で、外部のレビュアを招いたのがきっかけだ。レビュアは実際のソーシャル・ソフトウェア開発場面で仕事をしている人達で、批評のセッションはとても価値あるものになった。しかし、2 点の提案については、私にはおかしなものに思えた。 迷いの晴れる瞬間だった。これらのコメントは a) 私が他の授業に外部レビュアとして招かれて述べていただろうことと全く同じで、そして b) グループがとりくんでいる問題へのアプローチとしては明らかに間違っていたのだ。 CoDeck? インターフェイスのアクセシビリティに関する提案は、御丁寧な質問つきだった。「なぜできるだけ広くからアクセスできるようにしないのか？」 ウェブ学派。もちろん答えはこうだ。「そうしない理由はない」、なぜならユーザは 「多いほど良い」から。しかし CoDeck? にはそれを単なるウェブ・ビデオ・アプリにしないでおく良い理由が幾つかあった。 まず、ベータマックスのデッキを使ったインターフェイスの物理化はコミュニティでのアフォーダンスをもたらす。これをウェブ全体に再現することはできない。次に、CoDeck? はある一つの親密なコミュニティにとって有用であるように設計されていた。CoDeck? の一般的なアクセシビリティを高めると、ITP のビデオ・アーティスト達のコミュニケーション密度は薄まってしまうだろう。第三に、ラウンジにビデオデッキを置くことで自治がなされた。コミュニティに強く繋がることで悪用から逃れられたのだ。自由にアクセスできてパスワードのない 「アップロードと批評」ビデオサイトは、すぐにポルノの巣窟になってしまうだろう。最後に、ローカルなコミュニティにサービスを提供するならローカルネットワークの帯域を最大限活用でき、公開システムであれば帯域的に耐えられないような機能も可能になる。 これらのサイトはポジティブ・スパイラルを前提としている。ユーザが多いほど安くあがり、安くあがるほどユーザは増える。しかし、どこかで誰かが楽をしているというだけではユーザを魅きつけることはできず、クリティカル・マスを越えられなかったシステムは悪循環におちいった。RateMyProfessors?.com と同じように、ウェブ学派のアプリはただそこにあるだけでは駄目だ。数万人のユーザ向けに作られたアプリケーションは、数十、あるいは数百のユーザを扱うことができない。 煽り役として、Scott はカルマも得た。参加した皆がいくらか金を節約でき、彼の信頼は増した。現金収入と違い、信頼はより小さく閉じたコミュニティから比較的容易に集めることができる。WeBe? が生まれたのは、Scott が、共同購入は成功だったけれどエネルギーが要りすぎる、と言ったこともある。ITP で共同購入するのを楽にするにあたって、WeBe? のグループは認証や信用評価のシステムを作る必要はなかった。ソフトウェアが特定の(そしてごく親密な)コミュニティの中で使われるものだったからこそ、そういうことを手間をかけずに実現できたのだ。 ウェブ学派がうまくゆく場面があるのは、ある種の不足にたいする合理的反応だからだ。たとえば資金: サーバが高い、ロードバランスのルータ、テープのバックアップ、その他厳しい稼働に耐えうる装備。才能: 優秀なプログラマはなかなかみつからない。偉大なプログラマはいないに等しい。ユーザ: ユーザは忙しい。ユーザは習慣に従う生き物だ。気を引こうとする競争相手も多い。 しかし、こうした不足問題に立ち向かおうとして、ウェブ学派の設計方針は出口の見えないものとなっている。アプリケーションはスケールしなければいけない。なぜなら良くできたウェブ・アプリケーションは費用がかさむからだ。しかしスケールしろという要求自身からくる出費はずっと大きい。更に、ある物がない時は他のものも足りないものだ。スケールするアプリケーションを動かすハードウェアには大きな予算が必要になる。そうしたアプリケーションを作るには、優秀なプログラマや管理者が必要で、その人件費がかさむ。人件費を稼ぐには十分な数のユーザを得て支払いをうける必要があり、そのためには広告費がかさむ。 私の生徒がやっていることは、この流れから降りることではないかと思う。そうできるのは、ウェブ学派が挑んでいる不足問題はもう問題ではなくなってきているからだ。ムーアの法則同様ストレージは大きくなっているし、OS の機能はよくなりつづけている。そのおかげで 800 ドルで買ったデスクトップマシンが、そのまま十分にいいサーバになる。 次に、かつてはユーザの興味をひくことが難しかった。ひとつにはユーザの少なさが原因にある。90 年代に作られたウェブ・アプリケーションは実世界の特定のコミュニティと直接のつながりがなかった。インターネットのユーザは広く浅く分布していて、IT 産業以外の場所では、オンラインのメンバは実世界のグループのごく小さな部分でしかなかったからだ。 そうした時代は終わろうとしている。場所によってはもう終わってしまった。今日の米国では、35 歳以下か 年収 3万5千ドル以上の人はおそらくオンラインだ。したがってあなたがオンラインならあなたの知り合いもオンラインだろう。今や実世界のグループに合わせたアプリケーションをつくることができる。そのグループのメンバ皆がインターネットにアクセスできると考えてよい。 同じ事がプログラミングにもおこる; 全ての関心はアウトソーシングに集まっているが、多くのダウンソーシングもまた起こりつつあるのだ。プログラミングは職業上の技能から、より広く身につけられるスキルになりつつある。もしプログラマという言葉が 「コードを書いて給料を貰っている人」 ではなく 「コードを書く人」 を指すなら、2015 年にむけてその数は増えつづけるだろう。perl や JavaScript、Flash を使う人の多くは自分をプログラマだとは思っていないけれど。 これはウェブサーバ・ソフトウェアと平行した現象だ。90年代なかば、ウェブサーバを動かすことは それ自体が目標となってしまうような厄介な仕事だった。それから Apache が登場した。ウェブサーバを立てるのは簡単な仕事になり、単純に、より大きな事ををするための構成要素となった。 MySQL はデータベースの分野で同じことをしている。これはグループ・アプリケーションを開発する上で意味のあることだ。なぜならソート機能は公共財だから。もし Teachers on the Run が単なるコメント付きの講師リストだったら、書きこみ専用のアプリケーションになってしまっただろう。ニュース記事によくある「あなたの考えを聞かせてください」 という(何の役にも立たない)コメント用フォームがあるだけ、というような。どんなグループでも、何より知りたい重要事項の一つは 「他の皆は何を考えているか」 だ。特にグループとしての知識が個々人の知識を上回るなら。「ユーザがコメントを格付けする」 機能をもたせ、更に時間ではなく格付けの順で表示するようにしたことで、システムは価値あるものになった。 もしろんこうした機能をデータベース以外の方法で実現することもできるだろう。しかし MySQL をつかえば仕事はずっと簡単になる。実際 MySQL 以後、問題は別の場所に移ったのだ。MySQL を使うか他のデータベースを使うかについては技術的に入り組んだ議論がある。しかしそうした議論はもう焦点ではなくなっている。理由はどうであれ、これら新しいアプリケーションでは MySQL がコア・ツールになっているようだ。 馴染系ソフトウェアは技術的な戦略ではなく、ソフトウェアとそれを使うユーザ・グループの密着度をどう考えるか、である。そしてスケーラビリティや汎用性、完全性を無条件に善として受け入れるのを拒むことだ。この境地のもとでは、ウェブ学派のソフトウェアがパーソナライゼーションに固執するのは自明な真実からの言い逃れに見える。大半のウェブ・アプリケーションはその設計からして個人向けでない。総称的なユーザを相手に作られているのだから。ユーザがウェブサイトのインターフェイスをカスタマイズできるのは便利かもしれない。しかしそれは ATM 現金を吐きだす時にユーザの名前を表示するのと大差ない。 私の生徒の一人はウェブ・アプリケーションを母のために作ったという。学校の教員である母親が使う、授業の記録をつけるアプリケーションだ。ただひとり、給料を貰うわけでもなく、余暇を利用してアプリケーションを作っていても、すべての教員のために汎用的で完璧なものを作ることはできない。しかし、母親のためのものなら作ることはできる。 もちろん、目的がはっきりとした小さなアプリケーションはこれまでも存在していた。かつては PC の持主にメッセージを表示すべく BASIC を学んだものだし、投資銀行や研究所といったデータが重要な組織では小さなグループのユーザ向けにソフトウェアを書く。しかし今、良い道具や優れたユーザがあらわれ、またインターネットが社会の舞台となった。これらが組み合わさることでそうしたソフトウェアを作るのは簡単になり、できあがるものの品質はあがった。ユーザがそれを使うには単にリンクをクリックするだけでいい。数十人を相手にしたソフトウェアを設計する、かつては困難だったこのことがやがて一般的なものになるかもしれない。 では次に何がおこるのだろう？ 私が目にしているのが一時的なものだったり、限られた一部の現象でないのなら、こうした小さく身の丈にあったアプリケーションが増えていくことになる。これははっきりし問題を抱えている。開発者はコミュニティのサポートを押しつけられるだろうし、こうして作られたソフトウェアの寿命は短いだろう。 しかし長生きを期待するのはある種のスケーラビリティだと言える。アプリケーションを長く使いたいと考えるのは、それを作るのにコストがかかるからだ。安く簡単にソフトウェアを組めるようになれば、この原則は弱まる。ビジネスでは稼ぎのいい人々に数百時間をかけて PowerPoint? のスライドひとつをつくらせることがよくある。そのスライドはミーティングで一度使うだけだ。ソフトウェアを多くのユーザに使えるようにする、あるいは多くのユーザのために残すというのは慣習にすぎず、ソフトウェアそれ自身の要件ではない。 実際問題、多くのユーザに長く使ってもらおうと作られた大抵のソフトウェアはその両方の目標を永久に達成しない。馴染系ソフトウェアはこう主張することができる: 「大抵のソフトウェアは短い期間、少しのユーザに使われるだけだ。なぜその利点を設計に生かさないのか？」 こうした事態は、奇妙なことだが、進歩といえる。馴染系ソフトウェアが他のアプリケーションを駆逐するからではない。そうはならないだろうからだ。現在のソフトウェアがつくる生態系のもつ価値はどれも、一握りのユーザが数ヶ月使うアプリケーションがもたらすものではない。私達は新しいソフトウェアのニッチをみつけたのだと思う。コミュニティは個々の特別な要求にぴったりのツールを手に入れる。そのツールはこれまでの設計品質や成功のための試験には落ちるだろうが、にもかかわらずよく機能する。そのソフトウェアは、それを使うコミュニティによく馴染んでいるから。 |
プロミスのサイトです。
