Radium Software Development

初代 "Jak and Daxter" は「全年齢対象」 (Everyone) であったのに対して， "Jak II" 以降は「１３歳以上対象」 (Teen) へと変更されている。実際のゲーム内容も，冒険探索的な内容から物語性を重視した内容へと変化しており，キャラクターデザインや世界観に関しても「大人っぽい雰囲気」を意識した様子がうかがわれるようになっている。

また， "Metal Gear Solid" シリーズにおける表現の変化なども印象に強く残っている。

前作 MGS2 は「１５歳以上対象」に分類されていたのに対して，最新作 MGS3 は「１８歳以上対象」にまで引き上げられている。また，去年夏頃より新設された「コンテンツディスクリプターアイコン」も数点増やされている。ここでの「犯罪」の表示が作品中のどの辺りの表現を指摘しているのかは定かでないものの，「恋愛」・「セクシャル」に関しては思い当たる節がある。ちなみに，「飲酒・喫煙」の表示が無いのは，国内の審査においては違法な飲酒・喫煙のみが指摘の対象となっているためであると思われる。

純粋に販売上の都合だけを考えるならば，「全年齢対象」の評価を得ることが最も有利であるはずだ。そこを敢えて対象年齢を引き上げる理由は，より印象的な表現を用いることがユーザの関心を掻き立て，娯楽性の向上に繋がるためであると考えられる。なかでも，暴力的な表現が作り出す刺激の重要性に関しては， Gamasutra の記事 "Manhunt to Mortal Kombat: The Use and Future use of Violence in Games" に簡潔にまとめられている。

欧米市場においては， "Grand Theft Auto" シリーズの圧倒的な支持や， "Halo" シリーズを始めとするシューター系ゲームの隆盛などがあって，暴力性の高いゲームが好まれる傾向にあると感じられるものの，実際には，これらの「暴力性の高いゲーム」は依然として少数派を保っているという指摘も存在する。

上の FileFront の記事 "Mature Video Games in the Minority" によれば， 2004 年に発売されたビデオゲームタイトルのうち，「１７歳以上対象」を表す "Mature" が付けられたタイトルは，全体の売り上げの 18% を占めるに過ぎないと指摘されている（もっとも， 18% を「過ぎない」と考えるかどうかは，意見の分かれるところであると思う）。

また，下の Chicago Tribune の記事 "M-rated video game sales raising more concerns" によれば， 2004 年中の全売り上げのうち，実に 55% が「全年齢対象」タイトルであり，次いで 27% が「１３歳以上対象」タイトルであったと指摘されている。

市場全体の売り上げに対する Mature タイトルの割合は，現在も緩やかな増加傾向を保っているものの，その売り上げの多くが GTA シリーズを始めとする数個のキラータイトルによって支えられているという背景も存在する。もし今後， GTA シリーズの新作が発売されない年があったとして，その年も Mature タイトルが増加傾向を保つかどうかという点に関しては，興味の湧くところであると思う。

いずれのレーティング機構も，所属の審査員が一定の倫理規定に基づいて柔軟に評価を行うという基本的な手法に違いは無い。ただし，どのような表現に対してどのような評価が行われるのかという点に関しては，いずれの機構においても曖昧にされている部分がある。何かルールを守っていれば確実に通過できるというわけではないため，その対策に苦慮することも少なくない。特にドイツの USK は，評価基準が曖昧な割には厳しい評価を行うことで知られており，たとえ大人向けのタイトルであっても血の色を変えるなどの対策を行っておくことが慣例化しているというような話を聞く。

アメリカの ESRB は， "Teen" （１３歳以上対象）を与えることに関しては比較的寛容でありながらも， "Everyone" （全年齢対象）に関しては厳しい態度をとっているような印象を受ける。特に，暴力の表現や銃の描写に関しては，かなり厳しい評価基準を適用しているようだ。例えば，日本国内では「全年齢対象」の評価が与えられている「ラチェット＆クランク」や「ドラゴンボール」等のタイトルも，北米では "Teen" になってしまっている。両タイトルに見られる銃器や暴力等の要素が評価に影響を及ぼしているであろうことは想像に難くない。

ESRB が Teen に関して寛容であると感じられるのは，戦争系のゲームを始めとして，意外なタイトルが Teen に分類されていることがあるためだ。例えば "America's Army" や "Medal of Honor", "Battlefield" 等のタイトルは，実在する武器を使って人間を撃ち殺すような内容であり，タイトルによっては血の描写があるにも係わらず， Teen に分類されている。

この辺りの事情に関しては，前出の記事 "Manhunt to Mortal Kombat: The Use and Future Use of Violence in Games" において軽く触れられている。

「"Medal of Honor" や "Call of Duty" が Teen に分類されている理由はいくつか挙げられます」。 ESRB の委員長である Pat Vance 氏はそう述べた。まずひとつには，これらのゲームは史実に基づくシミュレーションであることが挙げられる。次いで，無意味な殺傷を描写していないこと，血の量を最低限に抑えていること，同士討ちが無いこと，等々が挙げられる。「これらのゲームは第二次世界大戦の忠実なシミュレートを行っています。開発者たちは，無意味な殺傷を始めとして M レートのゲームで描かれているような種類のものを，このゲームには組み込まないという申し合わせを行っていたのです」。

実際に Everyone の評価を与えられるタイトルはどの程度存在するのだろうか。 ESA (Entertainment Software Association) による市場報告書 "Essential Facts" を参照してみると， 2003 年に米国内で販売されたゲームソフトのうち，全売り上げ（本数ベース）の 54% が Everyone に分類されると記されている。

同報告書には，ジャンル毎の売り上げの比較も載せられている。それによれば，アクションゲームが 27.1% と最も大きな割合を占めており，次いでスポーツゲームが 17.6%, レーシングゲームが 11.3% を占めているとされている。

スポーツゲームとレーシングゲームに関しては，よほど特殊な内容でない限り Everyone の取得が可能であることから，そのほとんどが Everyone に分類されているものと考えられる。そこで単純な引き算を行ってみると， 54 - 17.6 - 11.3 = 25.1 ということで，約 25% ほどが「スポーツでもレースでもなく，かつ Everyone に分類されているタイトル」として存在するものと考えられる。予想したよりも案外大きな割合であるというのが個人的な感想だ。

上の記事において氏は，とある C# の解説書にあった例外処理のサンプルコードと，そこに添えられた解説文を引用している。

この方法の方が，簡潔かつエレガントであることが分かると思います。

簡潔かつエレガントであり，しかも間違っている。

例えば， GenerateDatabse の末尾で呼んでいる CreateIndexes の中で例外が発生したらどうなるだろうか。例外は GenerateDatabse を通過し上の層で捕捉される。これは一見，正しい挙動のように思えるものの， GenerateDatabase を脱出してしまった時点で，データベースの生成がどこまで進んでいたかという情報は失われてしまう。結果として， PhysicalDatabse と Tables は破棄されずに，メモリないしはディスク上のどこかに残ってしまう（リークしてしまう）というわけだ。

一見，何気ない記述のように思えるこのコードも，例外処理に関して問題をはらんでいる。 ChooseRandomTeam で例外が発生した場合，オブジェクト guy の属性 Team には何の値も設定されないまま，この関数は終了してしまう。しかし，オブジェクト guy は AddToLeague によって League 登録されてしまっているため，後に League から Team 属性を利用するような処理があった場合に，参照先が存在しないという不具合が発生してしまう。

この不具合を修正するには，以下のように順序を入れ換える必要がある。

この順序であれば， ChooseRandomTeam が例外を投げたとしても，未登録のオブジェクト guy がガベージコレクタによって破棄されるだけであり，安全に終了することができる（例外を処理するのは上層の仕事だ）。

これらの例からも分かるように，例外を利用したエラー処理における「ダメなコード」と「正しいコード」の差は非常に微妙なものとなってしまう。この難しさについて触れていたのが， Raymond 氏の先日の記事 "Cleaner, more elegant, and harder to recognize" だ。

「より簡潔で，よりエレガント，そして，より見分け難い」という表現は，例外の持つ難しさの本質を言い当てているように思われる。「エラー値の返却」を利用した昔ながらのエラー処理は，返却値の確認を行っているかどうかで対処の有無を知ることができるうえ，エラーの発生するタイミングとそこからの流れが分かりやすいという特徴を持っている。そのため，「ダメなコード」と「正しいコード」の判別がつきやすい。しかし例外の場合は，エラーへの対処が暗黙的であり，しかも前出の例のような些細な違いが差を生み出すため，多くのコードの中から「ダメなコード」を見つけ出すことが非常に難しくなってしまっている。 Raymond 氏はそのために，例外を用いたコードを書く際には，「最初は手を抜いて書いて，あとから直す」というような「贅沢なやりかた」はしないように心掛けていると述べている。

これらの記事において Raymond 氏は，例外という仕組み自体が悪いと主張しているわけではない。例外を利用したエラー処理が非常に簡潔にまとまることは事実であるし，プログラミングのコストはトータルで軽減されるものと捉えることができる。ただ，例外処理を本当に正しく記述するには十分な注意深さが必要であり，さもなくば，非常に発見の難しいバグと奮闘する破目に陥ってしまうということだ。

Windows の Program Files フォルダを調べたことのある人なら誰しも，そこに "xerox" という名前のフォルダが存在することに気付くだろうと思う。 Xerox 社の関連機器を利用している人ならともかくとして，多くの人は身に覚えのないフォルダが存在することを不思議に思うはずだ。そのフォルダの中身をのぞいてみると， "nwwia" という名前の空のフォルダが存在するのみであり，他にファイルは何も見当たらない。まるで何かの残骸のように見えるので，とりあえず削除してみようとすると，フォルダ自体が何かのプロセスによって保護されており，削除できないことに気付く。削除エラー？一体誰がこんなフォルダを保護してるって？

Raymond 氏によれば， Program Files 下に "xerox" フォルダが存在し，しかもそのフォルダを削除することができないのは， Windows File Protection (WFP) システムが，このフォルダ内にインストールされるファイル "xrxflch.exe" を監視しているためであるとされている。 WFP は存在しないフォルダ内のファイルを監視することができないため，当該ファイルの存在の有無に係わらずフォルダが存在するようになっているということだ。

WFP が "xrxflch.exe" を監視している理由に関しては， Raymond 氏も推測を述べるにとどまっている。恐らくは，これも Windows の互換性維持のための処置なのであろうと思う。何らかの複雑な事情があって，各種のセットアッププログラムによって "xrxflch.exe" が書き換えられてしまうのを防ぐ必要があるのだろうと述べられている。

ここで，当該ファイルを書き換え不可として保護するのではなく，書き換えを監視するという受身的な方法を用いている点が，いかにも Microsoft 的であると感じられる。書き換え不可として保護すれば，システムが破壊される恐れはなくなるものの，セットアッププログラムはインストールに失敗したものとして中断されてしまう。そうすれば，ユーザーはその原因究明の手間を負うことになってしまう。そのような事態を避けるには，当該ファイルの書き換えを直接に阻止するのではなく，ファイルの書き換えを検出するようにしておいて，あとでシステム側が復帰を行うという手順を踏まなければならない。これは，技術者にしてみれば酷く面倒な回り道であるように感じられるものの，ユーザー本位の観点からすれば正しい解決法であるはずだ。そのような姿勢を徹底して貫いていることが， Microsoft 製品の品質の高さの一端を担っていると捉えることができると思う。

番組の性質から必要以上にセンセーショナルな扱いをされてしまってはいまいかと心配していたのだけれど，思いのほか落ち着いた内容だったので安心した。実のところ，自分も純粋に番組を楽しむことができた。特に，トラブルが発生してからの展開などは，番組制作側にとってみても思いもよらぬ展開だったのではないかと思う。内容に関して詳しく触れることはできないものの，現場の緊迫感がリアルに伝わってくる内容であったことは間違いない。

番組を見ていて印象に残ったシーンのひとつとして，ＰＤ社の充実した職場環境を紹介した部分が挙げられる。「どうしても職場に長く居る必要のある仕事だから，長く快適に過ごせる設備を整えた」という山内氏の弁には，恐らく賛否両論があると思われるものの，ここまで環境の整備に投資を行った事例は珍しいため，試みとしては興味深いものであると感じられる。

これを見て連想したのは，ブログ "Ninetyninezeros" の Mark Jen 氏による考察だ。氏は同ブログにおいて， Google 社の社員が受けることのできる「特典」に関して触れたうえで，様々な考えを巡らせている（ところで，どうやら氏は本当に入社後１０日間で解雇されてしまったようなのだけれど……これはまた別の話）。

これらの「特典」の多くは，厚いベールに覆い隠されているものの，本当は僕らを仕事場に居させるための時間節約の手段なんだということに気が付いた。無料の昼食・夕食なんかは，まさにその一例だ。 Google にとってみれば，これは随分と割のいい方法なんだ。なんで他の会社は，この価値に気付かないんだろうと思う。考えてみるといい ― Google の負担は，多く見積もっても，１社員あたり昼食に３ドル，夕食に５ドル程度だろう。つまり一日あたり８ドル程度でしかない。でも，それで昼食は３０分ぐらいしかかからなくなるし，しかも夜遅くまで働くようになるという事実を考慮すれば，８ドルを遥かに超える利得が会社側にあるということに気付くだろう。もちろん，人々がこの「特典」を素晴らしいものであると考えることによって，非常にポジティブな力が生み出されることは言うに及ばない。端的に言えば，この「特典」は会社にとっての特典であって，社員にとっての特典ではないんだ。

Google 社には他にも多くの特典が存在する。社内に常駐の医者，常駐の歯医者，社内カーウォッシャー，無線ＬＡＮ完備のシャトルバス，等々……。様々な日常の雑務を軽減する「特典」を用意することによって，より仕事に集中することのできる環境を作り出すことができる。特に， Google 社のように高度な知的労働を要求する環境においては，そのような「特典」が重要な違いを生み出すため，会社側も惜しみない投資を行うということなのだろうと思う。

余談になるのだけれど，氏の話の中に出てくるシャトルバスのサービスなどは，まさに労働時間を増やすための合理的な手法であると感じられる。車内に提供される高速無線ＬＡＮによって，社員は通勤中も仕事をこなすことができるようになっているということだ。

ここで紹介されている Blue Fang Games 社の "Zoo Tycoon 2" 制作チームは，「１日あたり８時間，１週間あたり４０時間，残業無し，休日出勤無し」という勤務体系で同タイトルの制作を行ったとされている。記事中には，このような開発体制を守るために必要とされた様々な手法が提示されているものの，それらの基本的な考え方はいずれもよく耳にするものばかりだ。曰く，「優先度を明確にせよ」，「何が切り落とせて何が切り落とせないかを把握せよ」，「不測の事態に備えよ」，「スケジュールを頻繁に更新せよ」，等々……。何かとっておきの特効薬（あるいは「銀の弾丸」）が存在するわけでもなく，ただそのような「あたりまえのこと」を忠実に守ることによって，無理のない開発体制を実現しているということだ。

中でも特徴的なのは，労働時間の延長を明示的に否定している点であると感じられる。

我々は，素晴らしいゲームを期限と予算の中で作り上げてきた技術に誇りを持っています。つまるところ，我々の会社のポリシーは，社員が自分自身のための週末を過ごせるようにし，積極的かつ成功裏に残業の類を否定することにあるのです。

そんな氏等も，短期的な残業は消極的ながらも肯定しているという点が興味深い。記事によれば，マイルストーン毎に１週間から２週間の長さの「修羅場週間」 (crunch week) が設定されたと述べられている。その週は１日あたり１０時間勤務が基本とされ，任意の１日だけ８時間勤務を選択することができるようになっている。この「修羅場週間」の予告はあらかじめ明示的に行われ，社員やその家族がそれに予定を合わせることができるように配慮されている。

更には， "Zoo Tycoon 2" のマスターアップ間際には，締め切りを守るために 26 日間の休み無し勤務が強いられたと述べられている。ただ，これが一般的な「マスターアップ修羅場」と異なるのは，この止むを得ない行為をも徹底して否定的に捉えているという点だ。

我々は，社員の努力に対して最大限の感謝を行うようにもしました。社員が週末を潰さなくてはならなくなった場合，その家族には花が贈られました（この試みは，少なくとも最初のうちは大変感謝されました）。また，社員の休日出勤は絶えず記録されており，その日数をもとに代休が与えられることになります。我々は事後分析を経て改良すべき部分を特定し，悪く転じてしまった点を修正します。そして今後も，期限通りに高品質のゲームを制作しつつ，社員の「生活の質」 (quality of life) を尊重し続けることでしょう。

Reynolds 氏は "Steering Behaviors" のページなどで有名なゲーム技術研究者だ。現在は SCEA の R&D Group に所属し，各種の技術研究や "OpenSteer" 等のプロジェクトの管理を行っている。

件のページ "Game Research and Technology" には，氏が各種の学会等から集めてきた文書へのリンクがまとめられている。主として集められているのは AI 関連の技術であり，ここまで丁寧にまとめられたリンク集は，ゲーム AI に限って言えば他に無いと言っても差し支えないだろうと思う。例えば，グラフィック関連の技術ならば "Real-Time Rendering" のリンク集のように素晴らしいものがあるが，これはそのレベルに相当するものであると感じられる。

この中から適当に選択して先日読んでみたのは， Nathan Combs 氏の "Declarative versus Imperative Paradigms in Games AI" だった。

これは，直訳するならば「ゲーム AI における宣言的手法と命令的手法の比較」というようなものになるが，もう少しくだけた感じに直すならば「ルール方式とスクリプト方式の比較」となると思う。この論文において Combs 氏は，現在のゲーム AI の主流がスクリプト方式に偏っていることを指摘しつつ，ルール方式を用いることの利点を説こうとしている。

ゲーム AI の方式がスクリプトに偏る傾向があるという氏の指摘は，たしかに正しいものであると思う。恐らく，本格的なルール方式（プロダクションシステム）をゲームに導入した事例は，非常に限定されるのではないかと思う。自分の場合は，プログラミング言語 "SOAR" について調べた際に，初めてルール方式の概念に触れた。しかしこれは，自分の知識の中にあるプログラミングの概念とはかなり異なるものであるように感じられた。

Nathan 氏は，ルール方式の利点として抽象性の高さを指摘している。シチュエーションに依存してしまうスクリプトとは異なって，抽象性の高いルールはゲームの様々な箇所に適用することが可能であるし，場合によっては異なるゲームに対しても適用することが可能かもしれない。また，その抽象性の高さから多様性や創発性 (emergency) を生み出しやすいという利点もある。そのような利点を考慮することなく，安易にスクリプト方式を用いてしまってはいないだろうか……というのが，件の論文の主旨であると感じられる。

しかし，氏の指摘をすべて受け入れたとしても，なおルール方式が有効なケースは限られるだろうと思う。多様性や創発性が遊びを構成する要素のひとつとして見出されつつあることは認められるものの，すべてのゲームがすべてのシーンでそれらを必要としているわけではない。制作者の「狙い」を意図通りに見せるには，決まったシチュエーションで決まった反応を起こすことが求められる場合もある。そのような要求に対しては，ルール方式はかえって手間となる危険性が考えられる。そこで必要とされているのは，まさに文字通りスクリプト（脚本）の記述を行う手段であるということだ。

この論文では， GPU を利用して群集シミュレーションを高速に処理する手法について触れられている。

ここで扱われている群集シミュレーションの基となっているのは， Dirk Helbing 氏の考案した群集モデルだ。参考文献として Nature 誌に掲載された論文 "Simulating dynamical features of escape panic" が挙げられている。ちなみに，この論文は Helbing 氏のサイトから入手することができる。

Helbing のモデルでは，群集をベクトル場の中に漂う粒子群として扱うことができる。このベクトル場は，目標の方向を与えるベクトル，個体同士の反発力のベクトル，周囲の環境（障害物）から受ける反発力のベクトル，以上計３つから構成されている。これらのベクトルを足し合わせたものが個体の加速度として用いられる。そして，このベクトル場の分布をテクスチャ画像（ルックアップテーブル）に変換してしまえば，それぞれの個体の運動を GPU によって高速に処理することが可能になるというわけだ。

なお，それぞれの個体の運動方程式はリープフロッグ法 (Verlet leapfrog scheme) によって解かれる。この辺りは，粒子の運動を扱う場合にはお馴染みの手法かもしれない。

問題となるのは，ベクトル場の分布をテクスチャ画像に変換する際の方式だ。狭い範囲であれば十分な解像度で画像化することが可能であるものの，広い範囲を扱うとなると，十分な解像度を得られないか，あるいは解像度が高過ぎて処理が重くなってしまうかのどちらかだ。それらに加えて，３次元の情報を扱うことが難しいという問題点もある。

また，論文では結果として CPU を用いた方式との比較が行われているものの，実は GPU を用いた場合もそれほど速くなっていないという結果が明らかにされている。これを Courty 氏はバスの帯域幅によって生じる制限であると指摘しているものの，実際には，よほど多くの個体が密集していない限り CPU と GPU の間に大きな差が生じることはないだろうと思う。

このような類の群集シミュレーションは，並列処理に適していることから，今後のハードウェアの流行からもたらされる恩恵をいち早く被ることになるのではないかと予想している。特に，ここで用いられている Helbing のモデルなどは，個体間の相互干渉をベクトル場という間接的な関係として扱うことができるため，並列化に適していると考えることができる。

個人的に今後調べてみたいと考えているのは，もう少し高度な相互干渉を持つシステムを，並列化に適したモデルで表現する手法だ。 Helbing のモデルは基本的に「何も考えていない群集」を扱ったものであるため，単純な相互干渉で済ますことができているものの，これを「個々に意思の感じられる群集」に変えていくには，もう少し複雑な相互干渉を扱う必要があると考えられる。しかし，相互干渉が複雑になればなるほど，他方で並列化は難しくなるというジレンマが存在するわけだ。

これは， Craig Reynolds 氏の "Steering Behaviors" の改良版にあたるものだ。

件の論文において Jared 氏らは， Reynolds 氏の Steering Behavior の欠点として，複数の挙動 (behavior) の合成が難しいという点と，評価範囲が局所的であるがゆえに制御が難しいという点（例えば，密集した障害物の中を車で高速に走り抜けるなどというのは非常に難しい），等を挙げている。

氏らは，これらの弱点を補うために，特定の経路に関して評価を行う方法を導入している。現在地点から辿りうる軌道の組み合わせを導出し，それらの軌道を経路として評価を行い，その中から最も良い評価を得たものを結果として用いる……というような仕組みであるようだ。

このように，概要だけ見てみると，それなりに面白そうな手法ではあるのだけれど，実際に読み進めてみると，問題に対してあまりにも正直な対処を行っている観があり，途端に興味が失せてしまった。特に，軌道の導出を前計算によるデータ化で対処してしまっている部分などは，力技であるという感じが否めない。完全に動的な環境に対しても適用することができるという点や，汎用性の高い挙動を柔軟に組み合わせることができるという点などは，それなりに大きな利点として考えられるものの，それを実現するのに要されるコストが，それらの利点に見合うものであるとは感じられないというのが率直な感想だった。

Reynolds 氏の Steering Behavior は，ウェブ上で動いているアプレットを眺める限りでは，とても上手く動くアルゴリズムのように見えるのだけれど，実際にキャラクターをこれらのアルゴリズムによって動かしてみると，何とも言えない違和感を覚えることになるだろうと思う。時間・空間の両方に関して局所的な評価しか行わないために，環境の変化によって細かく動きがブレてしまい，どうしても「ロボットくさい動き」になってしまうという傾向がある。

例えば， "Obstacle Avoidance" のページなどを見てみると，上手い具合に障害物を避けることができているように見えるものの，よく動きを見てみれば，頻繁に進行方向が左右していることが分かるだろうと思う。このようなブレが，微妙な不自然さを生み出すことになる。

このような不自然さを防ぐには，評価の局所性を低める必要がある。 Jared 氏らの手法はそれを実現したものであるとも考えられるものの，あまりにも真っ当な取り組み方をしており，コスト対効果が微妙なものになってしまっている。実際には，障害物の多くは静的であることを利用して，効率よく滑らかな動きを作り出すことが可能であるはずだ。そのような合理的な手段が用いられない場合 ― 例えば環境が完全に動的である場合など ― は， Jared 氏らの手法のような解決法が役立つことになるのかもしれない。

Joel Spolsky 氏は，極めて分かりやすい明快な物言いが魅力のエッセイストだ。多くの人が同意できる当たり前のことを当たり前に言うことができ，かつそこに豊富な経験や鋭い洞察からくる説得力を加えることができている。氏の思想は典型的なソフトウェア技術者のそれに忠実に沿っており，多くの技術者（特に実利志向の技術者など）は，氏の言説を聞くことで自分の思想が裏打ちされる気分を味わうのではないかと思う。そこが氏の人気の理由であると考えることもできる。

それに対して， Hacknot の Mr Ed 氏は，典型的な批評家だ。氏はソフトウェア産業に蔓延る流行を冷ややかな批評眼で見つめ，その熱気の裏に隠された愚かさを的確にあげつらう。氏にとって批判の対象は日常的に存在している。ＸＰ，アジャイル，ペアプログラミング，等々……。最初はどんなに優れていたアイデアも，多数の人がそれに群がるうちに本質がぼやかされ，次第に方法論は欺瞞の道具と化してしまう。氏はそのような状況に対峙し，最も理性的な方法で反駁を繰り返す。氏の文体が滑稽なまでに理性的であり，かつ批評に徹しているのは，氏の持つユーモアの一面であると共に，批評家としての自らの立場を明確に示す意図があるのではないかと思う。

先日投じられた新たなエッセイは，またいつもの調子が光るネタだった。 "Wikiphilia - The New Illness" と題して， Wiki とそのコミュニティを真っ向から批判している。

少し皮肉っぽくなっているきらいはあるものの，大方の指摘は的確であると感じられる。 Wiki というシステムそのものに対する批評と言うよりかは， Wiki コミュニティに対する批判の方が比重が重くなっている。 Wiki を万能であると信じ込んでいる人々や，その万能性をうそぶく人々が，ここでの批判の対象だ。

基本的に Wiki は極端なコンセプトに基づいたシステムであり，決して万能なコラボレーションツールではない。この点は多くの人々の同意が得られるところであると思う。したがって，その特徴を良く理解して運用することが重要であると考えられる。しかし Wiki コミュニティの人々は，その適応性を拡大的に解釈してしまったり，あるいは，誤った思想によって問題を覆い隠してしまっている節があると氏は批判する。そのような懐疑的な視点の欠如を "Wikiphilia" ― 「ウィキ病」と呼び揶揄しているというわけだ。

Larry Sanger 氏は， Jimmy Wales 氏と共に Wikipedia を創立した主要メンバーの一人として知られる人物だ。現在は同プロジェクトから手を引き，オハイオ州大において哲学コースの講師として勤めている。

件の投稿において氏は， Wikipedia プロジェクトが直面している問題に関して言及している。同プロジェクトの内情をほとんど知らない自分にとっては，非常に参考になる内容だった。

Sanger 氏の指摘する一つ目の問題点は， Wikipedia は未だ信頼するに足る存在であると公には認められていないという事実だ。現時点において Wikipedia の内容が正確であるかどうかは，ここでは問題とされていない。ただ， Wikipedia が更なる成長を遂げるには，その内容が信頼に足るものであると公に認知される必要がある。さもなくば，学術的な価値を持つことは到底できない。学術方面からの支援を得るには，そうした価値を持つことが必要であるということだ。

しかしながら， Wikipedia は自身の信頼性を高めるための機構を備えようとしていない。古典的なレビューの類は存在せず，専門知識の有る無しに係わらず誰でも記事を編集することができてしまう。たとえ専門家の協力を得る幸運を引き当てたとしても，その成果を凡庸な執筆者が書き直してしまえば，たちまちアマチュア的な内容の記事へと退化してしまう。そのような環境が是正されない限りは， Wikipedia の信頼性に関する問題が改善されることは難しいだろうと Sanger 氏は指摘する。

二つ目の問題点は，プロジェクトに参加している人間の問題だ。 Sanger 氏は，いわゆる "troll" と呼ばれる類の人々が，このコミュニティには存在すると述べている。 "troll" とは，いわゆる「荒らし」に代表されるような，議論の質を落とすような振る舞いを行う人々のことだ。 Wikipedia の編集に参加するには，単に記事を執筆する労力を払うだけではなく，そのような人々の攻撃から自分を守ることにも労力を費やさねばならない。そのような労力の浪費が Wikipedia の成長を阻害していることは想像に難くないものの，それを回避するための機構もまた Wikipedia には備わっていない。極端にオープンな Wiki のコンセプトや，後に述べられているような思想の存在が，この問題の改善を難しくしている。

最後に挙げられている問題点は， Wikipedia に備わっている "anti-elitism" ― 「反エリート主義」の思想の問題だ。 Wikipedia はエリート ― つまり「選り抜きの集団」の存在を否定しようとしている。しかしその思想は，専門家の存在を重視しない風潮を生み出し，無思慮なまでに徹底して平等であることを望んでしまっている。そのような思想の下では，前述のような問題を根本から改善することは非常に難しいと考えられる。

この問題を更に深刻にしているのは，創始者の Jimmy Wales 氏を始めとした主要な運営者達が「反エリート主義」を固持しているという点にある。 Sanger 氏はそのような状況にありながらも，識者と「非」識者が共に貢献することのできる道を模索し続けてきた。しかし，その試みも結局は失敗に終わってしまったということだ。

ことの始まりは， Baldwin 氏が自身のブログサイト "defective yeti" に投稿した何気ない内容の記事にある。

氏は記事の中で，とあるバースデイ・クラウン（ピエロ）がインタビュー中に語った「仕事の知恵」を紹介している。ここから，氏が寄稿を行っているオンラインマガジンサイト "The Morning News" に，様々な職業の「仕事の知恵」を紹介する記事を書いてみたいという話になり，読者にネタの提供を募ったところ，予想以上の反響が寄せられたため，このネタだけで別途にサイトを立ち上げてみようということになった……というのが顛末であるようだ。

読者から寄せられた「仕事の知恵」とは……たとえばこんな感じだ。

看護婦

患者は時折，意識不明になった「ふり」をすることがある。これを見分ける確実な方法は，患者の手を握り，顔の上まで持ち上げ，そのまま突きつけることだ。もし手が顔に当たったなら，患者は本当に意識不明に陥っている可能性が高い。もし当たらなかったならば，患者は「ふり」をしているだけだ。

自動車技師

クルマの整備を行った後には，バッテリーの端子にカッパー（銅）グリスを盛っておく。その効果は取るに足らないものであるが，そうしておけば，顧客がボンネットの中を覗いたときに，何かが変わっていることを即座に見ることができるため，喜んで支払いを済ませてくれるようになる。

テクニカルサポート

電話越しにコンピュータの修理をサポートする際に，ケーブルが正しく繋がれているかどうかを確認して欲しくなることがある。ここで「ケーブルが繋がっていることを確認しましたか？」と聞いてはいけない。顧客は常にこう答えるだろう ― 「もちろんだ。あんた，バカにしてるのか？」。代わりにこう言おう ― 「ケーブルを一旦抜き，コネクタのホコリを吹き飛ばしてから繋ぎなおしてください」。すると，顧客は大抵こう答えるだろう ― 「ははっ，動いたよ。たぶんホコリが詰まってたんだな！」。

他にも様々な知恵が紹介されており面白い。個人的なお気に入りは，ピアノのセールスマンが紹介する「仕事の知恵」だ。

もし，ピアノに見入っている潜在客を見つけたならば，その客の年齢を見積もって，１８歳だった頃の年を逆算する。そして，客が見入っているそのピアノで，その年のヒット曲を演奏する。これには入念な準備と多少の幸運が必要とされるが，その客が純潔を失い，あるいは結婚し，あるいは初めて車を運転した日々に聴いていた曲を，ずばり当てることができるかもしれない。そうすれば，感情の共鳴は購入への抵抗を抑え込み，むしろもっと高価なピアノのために財布を開いてくれることだろう。

人間の感情を揺さぶるのに，記憶と音の関連性を利用するのは，なかなか面白い手法であると思う。特に自分はこういうのに弱いかもしれない。

こうして「知恵」の数々を見てみると，その多くが人（客）の操り方に関連していることに気付く。恐らくは，どんなに特殊な職業でも人との接し方には一般性があり，話題として共感が得られやすいということなのだろうと思う。かく言う自分も些細な知恵をいくつか持っているつもりではあるけれど，ネタにするほど面白いものや，まとまったものではないので，敢えて話題には出さないでおこうと思う……。

Rating

E-Rated Games

Exception Handling

Xerox Directory

Benefits

40 Hours Per Week

Rules vs. Scripts

FastCrowd

Autonomous Behaviors

Wikiphilia

Wikipedia and Anti-Elitism

Tricks of the Trade