Radium Software Development

他に，役に立つかどうかは分からないものの，興味深いテクニックとして触れられているのが "Single Compilation Unit" －「単一コンパイル単位」の手法だ。これに関しては，以前 Jamie Fristrom 氏も Gamasutra の記事 "Manager In A Strange Land" の "Turnaround Time" の回において触れていた（ここでは "metafile" と呼ばれている）。

これはつまり，プロジェクトに含まれる全てのソースコードを単一のファイルに結合し，たった１回のコンパイルによってビルドを済ませてしまおうという，とんでもなく豪快なテクニックだ。一見すると変態的なネタのようにも思えるのだけれど， Llopis 氏はこのテクニックによって実際に効果が得られることを指摘している。曰く，通常の方法ではビルドに２分３０秒を要するプロジェクトが，単一コンパイル単位にまとめてしまうことで４３秒まで縮まったとのことだ。実に 70% 以上もの時間が削減されているのだから，これを単なるネタとして片付けてしまうのは勿体ない話ではないかと思う。

実際には，この手法によって縮められるのはフルビルドの時間だけだし，無名ネームスペースやファイルスコープの扱いが破綻してしまうことから，運用上の問題が無いわけではない。しかし，フルビルドの時間だけに話を限定すれば，非常に大きな効果を上げることができていると言える。もし，何らかの理由になよってフルビルドを頻繁に行う必要性があるならば（例えば，デバッグ用に定期的な自動ビルドなどを行っている場合など），このテクニックは役に立つかもしれない。心に留めておいても損はしないだろうと思う。

C++ の物理的構造という面に着目した場合，最近個人的に気になり始めているのは，シンボル数の増加に伴うリンク時負荷の上昇の激しさだ。コンパイルの過程に関しては，さまざまな工夫を凝らすことによって負荷の軽減を図ることができているのだけれど，やはりそれだけではリンク時の重さから逃れることはできない。先月のような忙しさの最中には，４・５人のプログラマが同時にリンク処理を発行してしまうことも珍しくなく，そう言った場合には恐ろしく膨大なリソースが要求されることになる。 CPU への負荷が飽和したところでさほど困りはしないものの，おおかたメモリが足りない状況にあるから，マシンは途端にスラッシングを始めてしまい，ほぼフリーズとも呼べる状態に陥ってしまう。

このような場合は，マシンの性能を増強するというのが最もまっとうな解決手段なのだろうと思う。あるいは，ソースコードの物理的構造に気を配ることによって，リンク時の負荷を軽減するようなことはできないものかと思う。

以前， Ned Batchelder 氏は "Speeding C++ links" と題された記事において， C++ のリンク時間を短縮する手法について触れていた。

Ned 氏の解説によれば， Visual C++ においては，クラス宣言内に直接記述されたメソッドや，デフォルトで追加されるコピーコンストラクタや代入演算子の類は，そのヘッダファイルをインクルードするすべてのオブジェクトファイル内に生成されてしまう。これらの多重に実装された関数・データに関しては，リンカが適切な結合を行ってくれるものの，無駄な情報が多いゆえに処理が重たくなってしまうのは容易に想像できることだ。

ここで氏は，多くのソースコードからインクルードされるヘッダファイルには無駄なクラス定義を置かないことや，コピーコンストラクタなどのようにデフォルト定義が用意されているメソッドに関しては， private に無効な宣言を行っておくことによってデフォルトの生成を防ぐなど，細かな調整によってリンカへの負担を減らすことが可能であると述べている。その結果，実に 80% もの時間を削減することができたというのだから，大したものだと思う。

ただし，この手法は GCC では役に立たないだろうと思う。 GCC においては，これらの無駄な関数の実装は生成されず，基本的にインライン展開が行われるためだ。そもそも， GCC においては一体何の要素がボトルネックとなっているのか掴みかねているところがある。今しばらく，この問題に関しては調べてみたいと考えている。

このセッションは Llopis 氏が司会を行っているもので，レポートも氏によるものが毎年上げられている。今年も三日連続で行われた模様だ。

去年までのレポートは，読んだ後に「まあ，こんな感じかな」という感想を得る程度のものだったのだけれど，今年のは，僅かながらも変化が現れつつあるように思える内容だった。机上の議論でしかなかったものが，徐々に実践へと移されているような感触だ。

例えば，テスト駆動開発 (test-driven development) の話題では，参加者のうちの 18% が「何らかの形によってテスト駆動開発を行っている」と答えている。 18% というのは小さな数値だけれど，自分はこの種の技術に関していまだ具体的な有効性を見出せていないがために，僅かながらでも実践にまで持ち込んでいる人々が存在することに驚きを感じる。

ゲーム開発におけるテストの自動化は，現状では到底解決しえない問題であるように思える。僕はいまだに「熟練したプレイヤーが勘に任せてプレイする」という以外の具体的なテスト手法を知らない。この手法は，ある面においては不可欠なものである（人手によるＱＡが不要になることは絶対に無い）ものの，別の面では不確実性を抱えるものであるし，一定の時間を要するものであるし，世知辛い話をすれば，人件費だって決してばかにならない。これが部分的にでも自動化されれば，開発の様々な場面において有利に働くものがあるだろうと確信している。

今年の GDC では，テストの自動化に関するレクチャーがいくつか開かれていた模様だ。ペーパーか何かの形でその内容が参照できればと思う。

他に興味の引かれた話題としては，自動ビルドの機構を導入している所が 40% に上ることや， Wiki の利用者が 50% にまで上っていることなどがある。これらの要素は別段珍しくないものの，普及率の上昇が著しく感じられる。自動ビルドが必要とされているのは，ソースコードやアセットの量が肥大化する傾向にあることと関連があるのだろうと思う。

XP (extreme programming) に関しては，やはり今も煮え切らない雰囲気が漂っているように思える。部分的には取り入れられつつあるものの，思ったような効果を得ることができてないというのが多数の意見であるように見える。例えば，コードレビューに関して良い結果を得ているところは少ないようだし，ペアプログラミングに関しても具体的な成功例を見たことがない。導入のやり方が悪いのかもしれないけれど，導入が難しいということ自体に問題があると言えなくもない。

XP やアジャイル手法に関連する話題としては，唯一 SCRUM に関して具体的な記述が載せられている。

SCRUM に関しては疎いものの（実のところ，名前しか聞いたことがない）， XP ほど「過激」ではないことや， Sammy Studio において既に実践に着手されていることなど，興味の引かれる点も多い。今後，アジャイル方面で調べてみることがあるとすれば，この辺りを軸とするのが良いかもしれないと思う。

もうひとつ面白かったのは，オフィスレイアウトに関する記述だ。

エクストリームプログラミングでは開放的な環境（ブルペン環境）の導入が勧められている。雑音の存在がコミュニケーションを増加すると考えられているためだ。ここで，参加者の意見は明確に二分化された。ある人々はそのような環境が非常に有効であるとし，他の人々は集中力と生産性を上げるためにも静寂な個室の存在が望ましいとした。またある人々は，開放的な環境とプライベートな個室の両方を持っており，より高い集中が必要とされる場合は個室を利用することができるようになっていると述べた。最終的に言えることは，誰もキュービクル（パーティション）を好んでいないということだ。キュービクルは両者の意見において最悪の条件を備えている。ノイズにまみれておりながらも，開放環境ほどコミュニケーションに開かれていないのだ。

これは単純な意見ではあるけれど，ある種の結論でもあるように思える。集中力を生み出すために閉鎖的な環境が必要であるとしても，それは単純な仕切り壁程度で実現できるものではなさそうだ。恐らくは，状況によって個室と開放空間の両者を選択することができるというのが，最も理想的な環境なのだろうと思う。東京の地代のことを考えると，それを実現するのは簡単なことではないだろうとは思うけれど……。

オランダはアイントホーフェン大学でコンピュータ・インタフェースのユーザビリティを教えている技術者 Marcin Wichary 氏のページだ。古今東西の GUI に関する画像資料を収集し，詳細な分類と解説を行っている。単に量だけ見ても凄いものなのだけれど，分類に関しても非常に良くまとまっている。例えば，各 GUI システムの持つコントロールパネルの比較を行ってみたいと思ったならば……このページを見てみれば一目瞭然だ。

"Desktop with applications" のページなどを覗いてみれば，各 GUI システムの持つ概観をざっと見渡すことができる。

こうして並べて見てみると，初代 Mac は本当に偉大だったんだなと思う。いや， Longhorn の垢抜けっぷりにも驚きだけど。

別ページではアイコンに関してもまとめられており，こちらも素晴らしい仕事となっている。よくぞここまで集めたものだと思う。

アイコンに関しては，氏の個人ページの方に面白い記事がある。 "One thousand square pixels of canvas" －「千のピクセルを持つキャンバス」と題されたこの記事では， GUI システムの変遷に伴うアイコンの進化の過程を辿りつつ，各時代におけるデザインの傾向と進化の方向性について簡潔な解説を行っている。

氏はこの記事に関して満足していないようだけれど（実はやっつけで書いた記事らしい），それでも非常に面白い内容となっていると思う。

氏のページは他にも記事の類が充実していて面白い。単なるカタログに終わっていない所が素敵だ。 "Articles" のページには，元祖 GUI こと "Alto" や，その後釜である "Star" ，それから， Mac の前身となる "Lisa" など，モノクロ GUI マニアにはたまらない……もとい， GUI の誕生を語る上では欠かすことのできないマシン達の解説記事（当時のもの）などが転載されている。

まだ GUI やマウスなどの存在が一般的でない頃の記事だから，その辺りが既に記事のネタとなっていたりして面白い。「卓上におけるマウスの絶対位置は重要ではない。なぜなら，その位置の変化量のみが通知されるためだ」なんて感じで，改まって解説を行っていたりする。あと，なにげにアプリケーションの中にゲームが多いのもポイントだ。当時は，何か新しいシステムが登場したときに，まず作ってみるものというのがゲームだったのかもしれない。

Alto のメインプロセッサが TTL 回路であったというのも初耳だ。もっとも， Alto が登場したのが 1978 年で，マイクロプロセッサ (8080) の登場が 1974 年だから，微妙なラインかもしれない。その約５年後には 68000 ベースの Lisa が動き始め，そしていよいよ Macintosh の登場へと繋がることになる。

"Happy Mac" のアイコンは Susan Kare によってデザインされたものであり， 1984 年に Macintosh と共に登場した。このアイコンは全ての Macintosh ユーザが最初にディスプレイ上で目にするものであり，同時に Macintosh の GUI の優位性を表すものでもあった。 PC のようにわけのわからないブートメッセージを垂れ流すのではなく，調子がよければ "Happy Mac" を，何か障害があれば "Sad Mac" を表示するわけだ。

（中略）

しかし，多くのユーザが愕然としたことに，このアイコンは「古き縛りを断ち切る」という企業戦略の犠牲者となってしまい， 2002 年の Mac OS X (Jaguar) では灰色の Apple ロゴに入れ換えられてしまった。

ここで登場する "Happy Mac" アイコンの作者 Susan Kare 氏のページも面白い。どうやら相当に有名なデザイナであるようだ。

ポートフォリオのページには，氏の係った仕事の数々が展示されている。そこには，初期 Mac の著名なアイコン群や， Mac を象徴するフォントである "Chicago" や "Monaco" ，それから， Mac のコントロールパネルのデザイン， Windows の「ソリティア」のカードの絵柄のデザインなど，誰もが一度は目にしたことのあるデザインが多く存在する。

それにしても， "Happy Mac" と「ソリティア」のカードが，同じ人物の手によるものであったとは……。

面白かったのは，資料の中に登場する Jacques Carelman 氏の作品群だ。

「マゾヒストのためのポット」「婚姻者のためのタンデム」「筆記と食事を同時に行うペン・フォーク」「床掃除の靴」……どれもなんとなく形にはなっているのだけれど，ユーザビリティに関して致命的な矛盾を抱えたものばかりが登場する。

ウェブページ "Objetos Imposibles" は， Carelman 氏の作品を紹介するページだ。残念ながらスペイン語のコンテンツしかないのだけれど，作品群を閲覧するぐらいであれば，それでも問題ないだろうと思う。

このサイトにある紹介文によれば， Jacques Carelman 氏は前世紀に活躍したフランス人のイラストレーターであるようだ。これらの作品群は，フランスの通販業者として有名な Manufrance のカタログをパロディーした作品 "Catalogue d'objets introuvables" によるものであるとされている。

これらの作品群を見ていると，まるで何かの悪い冗談か，あるいは奇妙な夢の中に迷い込んでしまったかのような印象を受ける。総体としては体をなしているのだけれど，どこかしらに救いようのない理不尽さを抱えている。「不思議の国のアリス」に通じる世界観かな……。

そんな Carelman 氏の「ポット」を表紙に備えた本が，認知心理学者である Donald Norman 氏の著書 "The Design of Everyday Things" だ。

この本は「誰のためのデザイン？－認知科学者のデザイン原論」という題名で邦訳されている。

ちょっと面白そうな本だ。ユーザビリティの分野なんてのはまったく縁遠いものだけれど，ちょっとぐらい覗いてみたって罰は当たらないだろうと思う。

コンピュータの分野でも，黎明期には「個性」として許容されていた要素が，現在では「ユーザビリティの欠如」として簡単にマイナス視されてしまう状況がある。 Wichary 氏のウェブにある "Mapping" のページなどは，まさにその例を指摘したものだ。

僕の愛する PC-88 FR も，カーソルキーがえらい配置になっていて，ひどく苦しめられた記憶がある。方向と配置が一致していないカーソルキーなんてのは，ユーザビリティの欠如もいいところだと思うのだけれど……。

"Error Messages" のページなども面白い。まるでユーザをおちょくっているかのようなエラーメッセージの数々……このようなメッセージを数回見させられるだけで，そのアプリケーションに対する印象は悪くなる。僕もいまだに Lotus Notes なんかを使い込んでいると，この手のエラーメッセージを拝むことが稀にある。

資料の最後のページには，「指定された仕様を持つダイアログボックスを作成する」という課題に対する生徒の提出作品が掲示されている。やはりどうにも使い心地の悪そうなインタフェースばかり並んでしまっているのがポイントだ。

Topix.net は，いわゆる「自動ニュース収集サービス」の一種であり， "Google News" の対抗馬として注目を集めているサイトだ。

Topix.net の開発者の一人である Rich Skrenta 氏は，このポストの中で Google の新サービスである "Gmail" について触れている。

Skrenta 氏によれば， Gmail サービスの強みのひとつとなっているのが "Google File System" こと GFS の存在のようだ。 Google のウェブ検索サービスに利用されているのと同じ技術的バックボーンが，より速く，より安く，より信頼できるメールサービスを実現する。氏の試算では Google の記憶領域に対する管理コストはギガバイトあたり２ドル程度であり，一人のユーザから年間数ドルの利益を出すことができればビジネスとして成立しうると述べている。

GFS の仕組みに関しては，件のポストからのリンクにある論文 "The Google File System" に解説されている。

GFS は Linux システム上に構築される分散ファイルシステムであり，数百テラバイトの記憶領域に対して高速な読み書きアクセスと高い冗長性を提供する。分散の構造としては，ひとつのマスターサーバに対して数百のチャンクサーバがぶら下げられるようなものとなっている。マスターサーバはチャンクのインデクシングのみを行い，実データへのアクセスはクライアントとチャンクサーバが直接にやりとりすることによって実現される。マスターサーバを敢えて一個に限定することや，インデクシングに用いられるメタデータ構造を RAM 上に収めることなど，いくつかの「割り切り」を行うことによって比較的シンプルな設計を保つことができているようだ。

Skrenta 氏が指摘しているのは，そのシステムの冗長性の高さと，管理コストの安さだ。 GFS は，各チャンクに対して標準で３つのレプリカを別々のチャンクサーバ上に作成する。このレプリカが破壊されると， GFS は自動的にレプリカの再構築を試みる。論文に提示されている例によれば， 600GB の容量を持つチャンクサーバをひとつ潰したところ，そのレプリカが再構築されるまでに 20 分程度の時間がかかったとのことだ。 20 分と言うと少し長めにも感じられるけれど，稼動しているアプリケーションに大きな影響を与えることなく，秒間 440MB もの速度で復帰を行うことができているのだから，大したものだと思う。

更に重要なのは，この冗長性はサーバ単位によって実現されているということだ。 Skrenta 氏の指摘によれば， Google ほどの大規模システムにもなると，通常の RAID システムでは埒が明かなくなってしまう。故障の際にハードディスクを交換する手間がばかにならないし，そもそも RAID ハードウェアが比較的高価であることが問題となってしまう。その点， GFS のようなシンプルかつ自動化されたシステムならば，管理も比較的楽に行うことができる。 HeartBeat メッセージを送信してこなくなったブレードをラックから引っこ抜き，新しいブレードと交換するだけでいい。あとの復帰はファイルシステム側が勝手に行ってくれる。安価な専用ハードウェアを利用していることも重要なポイントだ。

この GFS に代表されるようなウェブアプリケーション専用の大規模クラスタリング環境を確立できていることこそが Google の強みであると Skrenta 氏は指摘している。 Google の競合他社は， Google の提供する特定のサービスと張り合うことばかりを意識しており，汎用性のある技術的バックボーンを構築することに対して十分な関心を払うことができていない。パフォーマンスとコストがクリティカルな要素となるウェブアプリケーションの世界において，このような基礎技術の開発は非常に重要な任務となるはずだ。その点において Google に勝つことのできる企業が現れない限り， Google の天下は当分続くことになるのだろうと思う。

今より少し昔のこと，僕は上司である Wade と，僕の編み出した小粋なアルゴリズムについて雑談を交わしていた。僕のそのアルゴリズムは，書き込みリクエストをキューイングし，その実行を対応する部分の読み込みと連動させることによって，余計なディスクシークを軽減させるというものだった。僕は，このアルゴリズムが非常にイカしたものであると考えていた。

しかし，それを聞いた Wade は僕の頭を小突くと，なぜ今さらディスクのことなどを気にしているのだと問いかけてきた。ディスクは既に時代遅れの存在だ。そんなアルゴリズムのことはさっぱり忘れて，必要なものはすべて RAM に載せてしまえ……そう彼は言い放った。

Orkut は恐ろしく高速だ。一体どうしたら，信頼性のあるスケーラブルなウェブサービスを，ここまで高速に動作させることができるのだろう。答えは簡単だ。すべてはメモリに載っているのだ。ゆえに，ユーザのリクエストは決してディスクの動作を待つことがないのだ。

ここで氏は更に恐ろしい試算を展開している。氏によれば， Google はウェブページのデータのすべてをメモリ上に載せているのだという。これはつまり，世界中に存在するウェブページのレプリカが，すべて Google サーバの持つメモリの上に構築されているということを意味している。

ただし，ここでの Skrenta 氏の指摘は詳細に欠けており，その「すべての情報がメモリ上に格納されている」ということを確信できるほどのものではないと感じる。恐らく，重要度の高めなページのほとんどがメモリ上に載っているというのは真実だろうけども……。

氏がそのように考える最大の理由は， Google での検索結果に添えて表示される "snippet" の機能にある。 Google は検索結果を表示する際に，与えられたワードとヒットした部分の前後を引用して表示する。ここで例えば，ワードにヒットしているかどうかという判定を行うだけであれば，高速なワード検索のアルゴリズムを利用することによって解決することができるものの，その本文から適切な部位の引用を行うには，やはり全文が瞬時に取り出せるようになっていなければならない。 Google ではこの機能が非常に高速に実現されていることから，すべてのページがメモリ上に格納されているのだろうと推測しているわけだ。

この推測が的を射ているものであるかどうかは，ひとまずおいておくとして，「高速なアクセスが必要とされるならば，すべてをメモリに載せてしまえばよい」という結論は，まさに富豪的ソリューションの極みであると感じられる。まあ，メモリモジュールの大容量化が進み，単価も順調に下降しつつある今，このような富豪的なアプローチをとることも，決して無謀な試みではないし，むしろ妥当なソリューションであるのだろうと思う。銀行のオンラインシステムのようなものはともかくとして，ある程度のトーレランスが認められる分野であれば，大容量メモリの投入によってパフォーマンスの劇的な改善とアーキテクチャの単純化が可能となるのではないかと思う。

Bloom filter は，複数の要素から構成される集合のなかに，任意の要素が含まれているかどうかを判定するアルゴリズムだ。複数のハッシュ関数と巨大なビット列を利用し，定数オーダーによって判定を処理することができる。ただし，判定は必ずしも正しいとは限らず，「擬陽性」 (false positive) が検出されることもある。そのため，例えばワード検索におけるキャッシュ処理のように，複数の集合の中から包含の可能性のあるものだけを高速にフィルタリングしたい場合などが，主な応用の場となる。

Bloom filter において擬陽性が検出される確率は，要素の個数とハッシュ関数の個数，それからビット列の長さによって変化するため，用途を考慮したうえでそのバランスを加減することが課題となる。その辺りの理論と検証については， Batchelder 氏のポストからもリンクされている Li Fan 氏らの論文の中にまとめられている。

このようなアルゴリズムが Google において利用されているかどうかは定かでないけれど……恐らく，これと同じように，任意の集合からの包含の検出を固定オーダーによって処理する何らかのアルゴリズムを導入しているのだろうと思う。

もうひとつ， Batchelder 氏のブログにおいて紹介されていたのが "Exact String Matching Algorithms" のページだ。

このページは，その名が表す通り，文字列マッチングのアルゴリズムを集めたページなのだけれど，面白いのは，それらのアルゴリズムの動作が視覚化されているという点だ。各ページにある "visualization" のボタンを押すと，別ウィンドウに Java アプレットが開き，そこでアルゴリズムの動きが「実演」される。

同じように Java アプレットを利用したデモとして，各種ソートアルゴリズムのデモなどがあったけれど，あれの文字列マッチング版だと思えばいいかもしれない。

例えば "Brute Force algorithm" と "Skip Search algorithm" のページを参照してみれば，高速な判定アルゴリズムにおける無駄の省かれ方が，視覚的に実感されるのではないかと思う。

仕組みの単純さから言っても，この skip search 辺りが丁度良い選択肢となるのではないかと思う。

マッチングを行う文字列が最初から特定されており，実行時には入力のみが変化するという場合には，有限状態マシンを利用した実装が適していると思う。

このような有限状態マシンの実装には，いつか調べた状態マシンコンパイラ (state machine compiler) を役立てることができる。複雑なマッチング処理を行うコードを，静的なコードとして自動生成することができるわけだ。

格闘ゲームにおけるコマンド入力などのように，特定の文字列に対するインクリメンタルなマッチングが行われる場合には，この方法がうまく適合するのではないかと思う。ただ，仕様によっては特殊な条件が設けられることもあるため，必ずしも既存のコードジェネレータが役に立つとは限らないけれど……たいていの場合は正規表現によってカバーすることができるのではないかと思う。うーむ，どうだろうね……。

ESX-1 こと "ELECTRIBE SX" の登場によって ES-1 は発展的解消を遂げたものかと捉えていたのだけれど，どうやら廉価帯商品群の一員として ES-1 シリーズも継続していく構えのようだ。 ESX-1 は現在でも７万を超える価格で販売されているのに対して， ES-1 mkII は既に３万を切る価格で販売されている。

価格も重要だけれど，大きさもノートＰＣ程度に収まっているし，応用性もそれなりにあるし……と，ホビー向けのシンセサイザーとしては手頃な条件を備えた製品となっているのではないかと思う。

ES-1 は，位置付けとしては「サンプリング・リズムマシン」ということになっている。９パートのサンプリング・パートに加え，１パートのスライス・パートを備えている。この「スライス・パート」では，入力されたフレーズを自動的に分割し，任意のシーケンスに再構築することが可能となっている。最近のサンプリングマシンには必ず搭載されている機能だ。「チョップ機能」などと呼ばれることもある。

エフェクトには，ディレイ専用が１系統と，マルチエフェクタが１系統搭載されている。モーションシーケンス機能によってノブの動きを記録することもできる。記録できるのはパート毎に１ノブのみと限られているけれど……まあ，価格からするとこんなものなのかな，と思う。

位置付けとしてはリズム専用マシンなのだけれど，サンプラーとして基本的な機能は一通りカバーしているため，使いこなせばそれなりに凝った操り方もできるマシンとなっているようだ。 ES-1 を上手く使いこなしている例としては，名も知らぬミュージシャン氏の作品が参考となる。

korg.com の方に置いてある James Bernard 氏のノリノリのデモも面白い……こんな KORG 製品漬けのミュージシャンなんて，実際にはなかなか居ないだろうけど……。

本体のデザインに関しては，個人的には旧 ES-1 の方がガジェット感があって好きだった。 ES-1 mkII のデザインは高級感を狙っているのかもしれないけれど……なんとなく不相応な気もする。シャンパンゴールドのシンセって，うーん，どうなのかね……。

ともかく，この新製品 "ES-1 mkII" は，趣味的にシンセを楽しみたい人のための廉価なサンプラーマシンとして，有力な候補となり得るのではないかと思う。

ところで，このように旧 ELECTRIBE シリーズが順にリファインされていることを考えると，次は "EM-1 mkII" の登場となるはずだ。サンプリングに特化されたマシンよりも，無難に音を出すことのできるマシンが欲しい人にとっては，こちらの方が有力な候補となるのかもしれない。

このように，サンプリングがしたければ "ES-1" を，楽器として使いたければ "EM-1" を，アナログモデリングでウネウネしたければ "EA-1", "ER-1" を……というように，用途によってモジュール化の進められているのが，廉価帯 ELECTRIBE シリーズの特徴だ。何でも１台でカバーしたい人にとっては中途半端なスペックなのだけれど，何か特徴的な楽しみ方のできるマシンを安価に手に入れたいと考えている人にとっては，なかなか面白いラインナップとなっているのではないかと思う。

普段テレビを見ない生活を送っていることもあって，新しい映画の話題などまったくついていけない状態になっているのだけれど……まったくノーマークだったこの映画が意外と盛り上がりを見せているようで驚いた。紀里谷和明氏の初監督作品ということで，実のところあまり良い印象を持っていなかったのだけれど，サイトに掲載されている画像や予告編の映像から伝わってくるオーラは，かなりの本気だ。評判が良ければ連休中にでも観に行こうかと考えている。

少し面白かったのは，この映画の存在がさっそく海外のオタク層にキャッチされていることだ。 Slashdot や Penny Arcade, Boing Boing 等で取り上げられたのを皮切りに，様々な人々が反応を示している（その殆どがブログであるというのも，面白いところだと思う）。

エキゾチックなパラレルワールドの世界観に，現代風アレンジの施された純和風ヒーロー像，それに，ファンタジックなＣＧ表現と実写の融合を果たしたアートワークなど，映画作品としてユニークな点は少なくないように思える。 Slashdot 内での議論では，こちらが臆してしまうような "Matrix" や "LOTR" との比較が遠慮なく繰り広げられている。また，いきなり凄いところを引っ張ってくるなあ……。

何はともあれ，まずは「イノセンス」を観に行くべきなのかもしれないけれど……なんか，周囲の評判を聞いていたら気合が抜けてしまったというのが実情だ。むむ，せめて溝の口に映画館があれば良かったんだ……。

この会社は技術文書やビジネス文書の翻訳作業を主な業務として扱っているようであり，このコンテンツも，その手の文書の翻訳に焦点を絞ったものとなっている。技術文書やビジネス文書の中でも，例えば特許文書や契約書の類などは，翻訳の際に特別な注意を払わなければならない。文書の性質上，単に訳文を作り出すというだけでなく，原文の意味に忠実な日本語の文章へと「変換」を行わなくてはならないということだ。このコンテンツでは，その「変換」を行う際に必要とされる様々な「コツ」について触れている。

明白なことではあるけれど，英文の「読解」と「翻訳」とは，別々の領域に属する問題だ。「読解」は文脈さえ理解できればそれで良いのだけれど，「翻訳」はそれを日本語の文章へと再構築しなければならない。それが日常的な文章や文学的なものであれば，元の意味や意図を保っている限りアレンジなども許されるのだけれど，ここで扱われているような技術文書やビジネス文書の翻訳においては，元の英文に正しく対応する訳文を導き出さなければならないという制限が加えられる。

しかし，これらの文書の中には，比較的シンプルな文体のものもあれば，やけに格式ばった書き方のされたものなども存在する。例えば，関係代名詞によって長く接続された文書などは，そのまま日本語に訳してしまうと，どうしても野暮ったい言い回しになってしまう。分詞・動名詞・不定詞構文なども，ベタな変換を行ってしまうと，奇妙な日本語になってしまうことが多い。

この「翻訳の泉」にある「翻訳教室」は，そんな翻訳作業の難しさを解決するために必要となる「コツ」の数々を伝授してくれるコンテンツだ。ここでは，日本語としての格好を保つために「超訳」してしまうよりかは，むしろ「直訳」を行う方が推奨される。「いかに元の文書に対して忠実な翻訳を行うか」という問題の領域においては，「読みやすい直訳」を作り出すことが重要な課題となってくるわけだ。

まだ全部は読めていないのだけれど，ぼちぼちと上から順に読んでいってみている。ここで解説されている文法の数々は，基本的には高校の英語の授業で習うものばかりなのだけれど，適当に英文読解を行うぶんには意識しないものばかりなので（ブログなんかは口語調のものも多いし……），今更ながら悟らされることも多い。

本当は参考書などを買って勉強するのが正しいのだろうけども……手軽に勉強を行うには，非常に有難いコンテンツであると思う。

謎のライター "Mr Ed" 氏による，ソフトウェアエンジニアリング関連の話題を扱ったサイトだ。ここで読むことのできる記事の数々には，氏自身の持つ確かな知見が含まれており，その言説には，流行や迷信といったものに惑わされることのない堅牢さを感じることができる。むしろ，この分野に蔓延する「虚構の事実」に対して，積極的に斬りかかっていくかのような意思が感じられる。とにかく，非常にユニークかつ興味深いサイトであることには間違い無いと思う。

ただ，氏の書く文章は非常に形式的であり，なんというか……かなり「お堅い」雰囲気の感じされるものとなっている。まるで教科書のようにがっちりした文語調だ。なんとなく文脈を理解することは難しくないものの，細部の正確な意味まで把握したり，あるいは日本語に直してみたりしようと思うと，非常に苦労してしまうことになる。僕にとってこのような文章は，読むのが難しく感じられるものとなっている。

そんな Hacknot にあった先日のポスト "Anecdotal Evidence And Other Fairy Tales" －「逸話的な論証と『おとぎ噺』について」は，ソフトウェアエンジニアリングの分野における「経験偏重」の傾向に関して危険性を唱えるものとなっていた。

This is natural enough, given that we have no agreed upon body of knowledge to which we might turn to resolve disputes or inform our opinions.

僕は，この一文を読むのに非常に苦労してしまったし，最終的に正しく理解できている自信もない。 "given that" って言い回しはどういう意味？ "have no agreed upon" って書き方はありなの？ "knowledge to which" って関係構文の "to" を使ってるのはどの動詞？

なんだか，英語のテストを受けているような気分になってきたのだけれど……直訳すると次のような日本語になるのではないかと思う。

議論の解決や己の意見の主張に傾きがちな知識そのものに関して，我々は合意を得たことがないのだから，これは十分に自然なことだ。

……なんだか野暮ったい日本語だなと思う。そもそも，意味もよく分からない。長い言い回しが文章を読み難くしてしまっているように思える。こういう場合は，無理にひとつの文章にまとめるのではなく，適当に分割を行ってしまった方が良さそうだ。ついでに言い回しなども多少変化させてみると，最終的に次のようなものになった。

我々は，知識そのものに関しては，議論の解決や意見の主張へと偏ってしまう性質を持っており，そこに合意を得たためしがない。ゆえに，これは十分に自然なことなのだ。

これでも，まだ辛い感じがするけれど……元が格式ばった言い回しなんだから，ある程度はしょうがないと思う。

限定された範囲での経験に基づいて方法論の評価を行うには，そこに混入するであろう恣意的要素を注意深く取り除き，客観的な視点から誠実な判断を行うようにしなければならない。その努力を怠れば，結果の一面にしか目が届かなくなってしまい，容易に不誠実な評価が導き出されてしまうことだろう。

ここで "Mr Ed" 氏は，「逸話による危険な論証の例」として，以下のようなストーリーを挙げている。

XP 支持者

ライアンと彼のチームは，このところ XP 関連の資料を読み続けており，自分達のプロジェクトにもそれを導入したいと熱望するようになってきていた。しかし彼らの上司は， XP におけるペアプログラミングや非形式的な文書化手法などのようなやっかいな側面に手を焼いており，その彼から許可を得ることは難しい状態にあった。それでも継続的に嘆願を続けていたところ，ライアンはついに新プロジェクトにおいて XP を導入する許可を得ることができた。しかし，その上司は，プロジェクトの進捗を非常に厳しく監視し，もし XP が上手く行かないと感じたならば，社の標準的な方法論へと切り替える権利を保持すると警告した。大喜びしたライアン達は，その新プロジェクトを XP によって開始した。それからの６ヶ月というもの，彼らは鬼のように働き続け，プロジェクトを成功させるべく，あらん限りの力を振り絞った。そして期間の終わりには，そのプロジェクトは高品質の初期リリースを作り上げ，注意深く選択された小数の顧客の下へとそれを届けた。それらの顧客からのフィードバックは，まったく否定の無いポジティブなものばかりだった。件の上司は目論み通り感心し，ライアン達はほっと胸を撫で下ろすのであった。

この「逸話」には，主観的な視点からでは気づきにくい幾つかの前提条件と心理的効果が含まれている。それらの要素を考慮せずに，ただこれを XP の「成功例」として受け取ってしまえば，誤った知見しかしか得ることができないだろう。それこそがまさに Mr Ed 氏の警告しようとしていることであるわけだ。

まずは，ライアン達のチームが，基本的に XP 支持者によって構成されていることを考慮しなければならない。 Mr Ed 氏はこのような前提条件のことを "population bias" （構成人員の偏り）と呼んでいる。

また同時に，彼らが既に熟練した技術者であったことも考慮しなければならない。彼らがプロジェクトに成功したのは，彼ら自身にその素質が備わっていたからであり， XP の導入が直接の原因となったわけではないかもしれない。そもそも，自ら XP を実践しようと働きかけること自体が，彼らの素質の高さを裏付けていると氏は指摘する。

また，彼らはあらかじめ上司から厳しい監視の下にさらされることを宣告されており，しかもその結果次第では中断さえも有り得ると脅しをかけられていた。これは「ホーソン効果」 (Hawthorne Effect) と呼ばれる心理的効果を生み出している可能性がある。

ここで登場する「ホーソン効果」とは，「己が観察の対象となっている」という意識が生産性を向上させるという心理的効果のことだ。

照明の強さが生産性に対して与える影響を調査するため，研究者達はまず照明を弱くしてみた。すると，生産性は向上した。次に照明を強くしてみると，生産性は向上したままだった。最後に照明を元の強さに戻してみると，やはり生産性は向上したままだった。

ホーソン効果とは，プロセスに対してあからさまな観察を行う際に，その初期段階において引き起こされる生産プロセスの向上のことを指す。この効果は Western Electric 社のホーソン工場において発見された。生産性は労働環境の変更によって向上したのではなく，経営陣がそのような向上に対して興味を示したことから引き起こされたのである。

これらの要素による影響を考慮せずに，単純に成功の要因が XP にあると決め付けてしまうならば，それは "Ignoring Rival Cause" のパターンに囚われているのだと氏は指摘する。つまり，「他の同等の理由を無視」してしまっており，彼ら自身の望んだ結果にしか目が届いていないということだ。

彼らは「XP によって成功した」というよりも，むしろ，「XP にもかかわらず成功した」と言うべきであろう。

この記事において氏は，前ポストにおいて指摘されたような現象が実際に発生してしまっている例として， Laurie Williams 氏の博士論文を挙げている。この論文は，ペアプログラミングの効用に関して調査を行ったものであり，ペアプログラミングの有効性を具体的に示すものとして引用されることが多い。ちなみに，同じ実験を元にした論文として IEEE Software への投稿記事 "Strengthening the Case for Pair-Programming" を挙げることができる（博士論文の方は長過ぎるので，参照するにはこちらの方が良い）。

ちなみに，これらの論文の著者である Laurie Williams 氏は， "Pair Programming Illuminated" 等のペアプログラミング関連の著作でも知られる人であり，代表的なペアプログラミング支持者の一人でもある。

件の論文では， Williams 氏が実際にユタ大学の授業においてペアプログラミングを適用した結果が論証の材料として用いられている。しかし Mr Ed 氏によれば，この実験の方法には前ポストにおいて指摘されたような問題が数多く含まれている。曰く，人員構成の偏りや，監視によるホーソン効果の発生，プラシーボ効果による希望的な解釈，等々……。その指摘は極めて具体的であり，この論文に含まれる問題点を鋭くえぐり出すように述べられている。

Williams 氏の実験は，偏見の影響を挙げればきりが無く，統制上の問題を挙げれば，その結果は殆ど意味を無くしてしまうほどだ。
まとめると，以下のような点が疑問として指摘される。
* 実験群は無作為に選出されていない。
* 実験群におけるペアリングは無作為に行われていない。
* 実験群は，統制群には無かった追加課題を受けている。
* 実験群は CSP (Collaborative Software Process) を利用しているのに対して，統制群は PSP (Personal Software Process) を利用している。
* これらの実験は独立して行われていない。
* ４回の実験のうち，最後の実験は無効とされており，最初の実験は変則的であるとして無視されており，所要時間の情報は統計的に重要でないとされている。

結論として Mr Ed 氏は，この実験において見られる信頼性の低さを大いに批判し，それと同時に，この論文を論証の拠り所としてしまうコミュニティの現状をも暗に批判している。それは，ペアプログラミング自体に対する直接的な攻撃ではないものの，その有効性を盲目的に信奉してしまっている人々に対しての辛辣な批判であることには違いない。

何故にこのコミュニティは，このような代物を無批判的に受け入れてしまっているのだろうか？私はその理由を知りたい。実際には意味の無い実験であるにも係らず，何故に多くの人々（Williams 氏自身も含む）が，この実験と結果をペアプログラミングを擁護する手段として引き合いに出しているのだろうか？この実験の方法に対して批判的な論考を行ったものは存在しないのだろうか？（私が知っているのは Sthephens & Rosenberg の "Extreme Programming Refactored" ぐらいだ）そして，この実験を引き合いに出している人々は，本当にこの論文を読んで，その実験の方法を把握しているのだろうか？科学系のコミュニティにおいては，このような「擬似実験」は嘲笑の対象となる。しかし我々は，このことを気に留めることさえもできていないようだ。

このポストに見られるような「切れ味の鋭さ」が， Mr Ed 氏の持ち味であると感じる。「論証の殆どが，経験の曖昧な分析によって築かれている」という指摘には，個人的に目の覚める思いがした。時折この手の話に見え隠れする「胡散臭さ」は，恐らくはこれに起因するものであったのだろうと，今になって思う。

噂に聞いていた通り Ver.1 はバランスが悪いようだ。米軍の機関銃 (M60) が理不尽に強くて，まともな打ち合いになるとまず勝てない。僕はもっぱらベトコン側でプレイしているから，米軍兵を倒しては M60 を奪うことに勤しんでいる。このように倒した兵士の武器を奪うことができるのは， Battlefield に見られる何気ない発明のひとつであると思う（これ以前に敵の武器を拾える FPS ってあったっけ？）。決して派手な要素ではないけれど，このような端々の要素においてリアリズムよりも「遊び」を優先する選択を行っていることが Battlefield の面白さを形作っているように思える。

グラフィックに関しては，結局は "Battlefield 1942" の続編ということで，あまり期待していなかったのだけれど，これが意外と健闘しているように思える。特筆するほどのレベルではないものの，ちゃんと森は森に見えるし，茂みは茂みらしく見える。 BFV はベトナム戦が題材となっており，そこはやはり森林や茂みに身を隠してのゲリラ戦が主体となってくる。森林や茂みの視界の悪さはかなり本格的なもので，茂みの中に身を隠せば本当に姿が見えなくなってしまう。そこで上手くゲリラ戦法を展開すれば，敵の不意を突くことがいくらでもできるというわけだ。

ゲリラ戦をやっていて感じたのは，視界の悪さに反比例して音が重要な要素になるということだ。茂みの中に身を隠し，敵兵の足音に耳を傾け，足音が聴こえなくなったところで前進を開始する。この間，視界はまったく当てにならないし，首の動きを感知されるのが嫌だから周囲を見回すことさえもできない。頼りになるのは音だけだ。

市街戦をやるにしても，瓦礫の向こうから足音が聴こえてきたならば，そちらにむかって手榴弾を投げつけてみるのがいい。対空ミサイルでヘリ殺しをやるにしても，最も頼りになるのは音だ……ヘリは地形を無視して全方位から接近してくるから，狭い視界で無理に対応するよりも，音を当てにした方が素早く感知できるわけだ。

ここまで音が重要になってくると，本格的なオーディオシステムが欲しくなってくる。通常の 2D オーディオシステムでは，音源の方向がいまいち把握しにくい。ちゃんとしたサラウンドシステムがあれば，後ろからの音は本当に後ろから聴こえてくるわけで，空間の把握がかなりやりやすくなることだろうと思う。

一応 BFV には Creative 社の EAX システムが搭載されている。一度，試しにこれを有効にしてみたのだけれど，いまいち効果が分からなかった。

なんとなく頭の内側から音が聴こえてくるような感覚があるのだけれど，正直なところあまり嬉しくない。音源の前後については差異があまり感じられない。しかも，困ったことに効果音がたまに鳴らなくなってしまっているように思える。だめだなあ，こりゃ……。

このマシンの扱い方も，だいぶ心得てきたような気がする。アルペジエータは非常に強力な機能だけれど，使いすぎると雑な印象になってしまう。シンセパート５音は少ないようで多いから，だいたい２音で構成を作ってしまうぐらいの心構えでいると楽しみやすい。パターンは基本的に１つだけ作って，あとはミキシングとエフェクトの妙で楽しむのが気楽でいい。フィルターはちょっとキツめにかけた方が良い。ヘッドフォン出力は音域に偏りがあるので，最終調整は出力後に行った方が良い。等々……。

EMX-1 に積まれているマルチエフェクタの中でも，特に面白いなと感じるのが "decimator" エフェクトだ。これは，単にサンプリングレートと量子化ビット数を操作するだけのエフェクトだ。信号処理的な観点で言えば，単に情報を劣化させているだけに過ぎないのだけれど，意図的にエイリアシングを発生させることによって，元音には存在しなかった高音成分を生み出すことができる。

このようなオーディオエフェクトの存在は，視覚的な表現で言うことろの「モザイク」や「ドット絵」に相当するものだと考えることができると思う。ダウンサンプリング自体は単なる情報の劣化だけれど，そこから再構成を行う際に失われた情報が補完される。その補完の手段によって，ジャギーが生まれたり，ブラーが生まれたり，ノイズが生まれたりするわけだけれど，その「補完」に表現としての意図が存在するならば，それはひとつの手法として認められうるものであると思う。

僕は知らなかったのだけれど，この "decimator" はオーディオエフェクトの一種として以前から存在するものであるようだ。下の Frostwave 社の "Sonic Alienator" などは， decimator エフェクトを軸とする「汚し系」エフェクタの一例として挙げられるものだ。

decimator を通すと，音を曇らせながらもキレのあるローファイ感を生み出すことができる。そういえば，こんな表現は幾つかの曲で聴いたことがあるような気がする。なるほど，あれは decimator だったわけね……。

余談だけれど，記憶が正しければ，僕の思い出のマシン FM-TOWNS では， PCM 音源の出力にローパスフィルタがかけられていた。恐らくは，エイリアシングによって発生するシャリシャリ感を防いであげようという親切心によって組み込まれたものなのだろうけども，僕はこれが非常に気に入らなかったという記憶がある。せっかくの「味のある高音成分」を削り取ってしまうなんて！

このページには， "Rock Paper Scissors" －つまり「じゃんけん」の，ゲームシステムや戦略，起源や亜流の存在などについて，かなり詳しくまとめられている。最近の Wikipedia の充実ぶりには驚かされることが度々あるけれど，このようにマニアックな項目についてもやたら深く掘り下げられていることがあったりして，妙な面白さを感じる。

理屈を言えば，「じゃんけん」における最も有利な戦略は，すべての手を完全なランダムによって選ぶことだ。しかし，人間同士の対戦においては，そう単純な話に終わらない。相手に対して心理的な揺さぶりをかけ，ミスリーディングを誘発させることによって，己に有利な状況を作り出すことができる。ゲームのシステムが単純になればなるほど，個々の手の選択の意味は失われていき，純粋に心理的な攻防が戦略の核になるという点では，ポーカーに似ている面があると思う。

2001 年に開催された「全世界じゃんけんトーナメント」 (Roshambo World Championship) の優勝者である Perry Friedman 氏は，その準々決勝の様子を次のように伝えている。ちなみに，ここで対戦相手となったのは，世界的に有名なポーカープレイヤーである Phil Hellmuth jr. 氏であり， Friedman 氏自身はスタンフォード大出身の技術者であるという背景が存在している。

じゃんけんトーナメントの対戦は，舌戦の応酬や，心理的な裏読み，言葉での誘導など，様々な戦略に満ち溢れている。先のポーカー世界チャンピオンである Phil Hellmuth jr. にとって，このような環境はお手の物であるはずであったが，次の準々決勝には Tiltboy チームの Perry Friedman が控えているのであった。

Hellmuth は自信たっぷりにリングへと歩み寄ると，彼の２メートル近くある巨体で Friedman に迫り，彼を威圧し始めた。いつもポーカーの対戦相手に対してやっているように，「お前の魂を見抜いてやる」と睨みをきかせる。

序盤はどちらもグーを出して引き分けた後， Friedman は裏読みでチョキを出し， Hellmuth のパーを打ち破った。すると Friedman は馬鹿にした態度で「グー，グー，ときて，次はパーですか！？」と叫び，それが素人の戦略であることをほのめかした。

残りの勝負は， Friedman が Hellmuth を巧みにしゃべり負かして９対６にまで持ち込んだ。最後に Friedman が Scotty Nguyen の物まねで「次にグーを出せば，お前の負けだ！ベイビー！」と高らかに宣言すると， Hellmuth はこの挑発に対して堪えることができなくなってしまい，グーを出して Friedman のパーに負けることとなってしまった。

最後に Friedman はにこやかに笑うと，観衆に向かって「実は，僕は魂を持っていないんだ」と打ち明けた。

このように，人間同士の対戦においては心理的な駆け引きが重要な戦略となるものの，これは逆に言えば，心理的な駆け引きの存在しない対コンピュータ戦においては，まともな戦略が存在しないということを意味するものでもある。

例えば，上の話に登場する Perry Friedman 氏が作成した「じゃんけんプログラム」こと "Roshambot" と対戦してみれば，これに対して 50% 以上の勝率を得ることは非常に難しいことが分かると思う。

もし仮に，完全にランダムな手を出すことができるとすれば，少なくとも５分の勝率にまで持っていくことができるはずなのだけれど，実際にはなかなかそうならない。人間の行う選択がいかにランダムでないかを示す一例となっているのではないかと思う。

これは，じゃんけんの「手」を５つにまで拡張した「拡張版じゃんけん」のルールだ。「石」，「紙」，「はさみ」，「スポック」，「トカゲ」の５つの手が，じゃんけんと同じく非推移的な関係を築いている。 "The Game Journals" の Ron Hale Evans 氏の解説によれば，これらの５つの手は次のような関係によって結ばれている。

1. 「石」は「はさみ」を壊す
2. 「はさみ」は「紙」を切り裂く
3. 「紙」は「石」を包む
4. 「石」は「トカゲ」を潰す
5. 「とかげ」は「スポック」に毒を与える
6. 「スポック」は「はさみ」を粉砕する（恐らくあの髪型が気に入らないのだろう）
7. 「はさみ」は「トカゲ」を切断する
8. 「トカゲ」は「紙」を喰う
9. 「紙」は「スポック」を理論責めにする
10. 「スポック」は「石」を気化させる

「スポック」がアクセントになっていて良いと思う……しかし，どうしてこういうのが思いつくのだか。

David Lovelace 氏による "RPS-7" は，手を７種類にまで拡張した「超拡張版じゃんけん」だ。

なんて言うか……もう，ここまでくると完全にネタだ。実用性は薄いだろうと思う。

世界規模の「じゃんけん選手権」としては，前出の "Roshambo World Championship" の他に， "World RPS Society" が存在する。

2002 年から毎年カナダのトロントにおいて開催されているとのことだ。しかしまあ，「世界選手権」とはいっても，ジョーク半分，言ったもん勝ちの世界だ。

コンピュータ同士による「じゃんけん対決」については，カナダはアルバータ大学の Darse Billings 氏らによって行われた "International RoShamBo Programming Competition" が存在する。

2001 年に行われたコンペでは Greenberg と呼ばれるプログラムが２位以下に大差をつけて優勝している。じゃんけんプログラムなんて，ほとんどランダムが支配する世界かと思っていたのだけれど，頑張ればアルゴリズムによって差をつけることも可能なようだ。ちょっと興味の湧くネタではある。

氏は他にもポーカーの数学的モデルによる最適戦略の導出なども行っている。

この実験では，様々なレベルのオンラインポーカープレイヤーに集まってもらい，氏らの作成した「最適ポーカープログラム」と実際に対戦を行ってもらっている。結果としては，全体的にかなりの好成績を収めているようだ。心理的な状態の上下によって勝率に揺らぎが出てしまう人間に対して，コンピュータは常に一定の「強さ」を保ち続ける。したがって，たとえ調子の良い人間に対しては五分以下の強さだとしても，長く対戦を続けるうちに「調子の悪いとき」の負けが累積していき，最終的にはコンピュータが好成績を収めることになる。コンピュータには「調子」や「運気」の要素が存在しないというのが，ある面において強さに結びついているということだ。

氏はこの記事において，過去の Game Developer Magazine に掲載された postmortem 記事の数々を分析し，その中に見られる定型的なパターンを探ろうとしている。

余談だけれど，以前は Gamasutra の方にも転載されることの多かった postmortem が，最近はめっきり転載されなくなってしまった。既に Game Developer Magazine の方では "Jak II" や "Prince of Persia: The Sands of Time" の postmortem も掲載済みとのことで，ずいぶんと重要なものを読み逃してしまっているような気がする。やはり GDM は定期購読しておかないとだめだ……。

閑話休題…… Llopis 氏の分析は，実のところ，かなり「予想通り」の部分が多く，個人的にはあまり興味のそそられるものではなかった。どのゲームも大抵，コンテントを作成する過程に最大のボトルネックを抱えている。その効率の悪さを改善しようと四苦八苦しているものの，これという絶対的な解決手法を編み出したところは（少なくとも僕の知る限りでは）存在しない。

ちょっと面白かったのは，これらの postmortem の全体を通して「何故か触れられていない要素」に関しても考えをめぐらせていることだ。中でも最も顕著なのは，「チームの問題」について触れられていないことではないかと思う。

※ チームの問題
これは，公な postmortem においては触れることのできないタブーなんだろうか……うん，たぶんそうなんだろう。たったひとつの事例 ("No One Lives Forever2") だけが，この問題に触れているのだけれど，それも，単に誤った雇用を行ってしまったと述べているだけに過ぎない。たぶん，他のみんなはパーフェクトなチームばかりで，みんな仲良く完全な協調の下に働いているのだろう。きっとそうに違いないんだぁ……。まあしかし，一般性のある問題ならば認めることに支障は無いだろうけども，例えば「上司の奥さんがブスだった」とか，そんなことを書くわけにはいかないということなのだ。

これは面白い指摘だと思う。実のところ，こういった postmortem 記事において触れられているのは，基本的に何らかの一般性を持つ話題ばかりであり，チーム内の人間関係のような踏み込んだ話題にまで触れられているものはほとんど存在しない。

例えば，「パブリッシャーのやり方が悪かった」とか，「プロデューサの理解力が欠如していた」とか，「ディレクターの指揮に問題があった」とか，「リードプログラマの人間性に問題があった」とか……そのような，特定の個人に対して責任を負わせるような発言を公の場において展開するわけにはいかない。しかしその一方で，これらの「人とチームの関係」に依存する問題は，制作の現場において最も重要な部類に入る問題だ。集団で制作を行っている以上，人間関係の状況次第でプロジェクトの行く末はいくらでも変化してしまう。また，どのようなプロジェクトも必ず人間関係上の問題を抱えているはずであり，時にはそれが原因となって（あるいは，それによって他の問題の進行が加速されて），プロジェクト自体をも沈没させてしまうことがある……というか，そんなプロジェクトをいくつも見たことがあるような気がする……。

このような問題が発生した場合に，自分はいったいどのような対処をとるべきなのか，僕にはよく分からない。この手の問題に関して postmortem は何も教えてくれない。それはある意味において，この問題が最も触れることの難しい問題であることを裏付けているようにも思える。

これはなかなか面白い……何気ない旅行写真も，広角になるだけでずいぶんと迫力が出てくるものだなと思う。

氏によると，どうやらこれらのパノラマ写真は "Autopano" というツールで作成されたもののようだ。

Autopano は Alexandre Jenny 氏によって開発された自動パノラマ画像生成ソフトウェアだ。特殊な機器や撮影技法などを必要とすることなく，適当に撮影された数枚の画像からパノラマ画像を自動的に生成することができる。画像の結合に関して手作業を全く必要としないというのが素晴らしいところだ。

ちなみに，同様の機能は Photoshop Elements にも搭載されているようだから，手っ取り早く使うにはこちらの方が良いだろうと思う。 Autopano ならばタダだけれど，実際に画像を生成するには "hugin" と "Panorama Tools" というツールを別途に利用する必要があり（基本的に Autopano は hugin 用のプロジェクトファイルを生成する），少し扱いに面倒な所がある。

Autopano の動作原理については，前述のページの中に簡単な解説がなされている。どうやらそれによると，このツールはカナダはブリティッシュ・コロンビア大学に所属の Matthew Brown 氏によって開発された技術を実装したものであるようだ。

Brown 氏のページには，この自動パノラマ生成の技術に関して詳細な解説がある。

この技術における画像認識処理には SIFT (Scale Invariant Feature Transformation) と呼ばれる概念が導入されている。 SIFT 自体は，同じくブリティッシュ・コロンビア大学の David Lowe 氏によって開発されたものであり，画像認識の分野では比較的有名な技術であるようだ。この SIFT を導入することによって，アフィン変換に対して耐性のある類似性 (similarity) の検出が行えるようになるとされている。そして，その SIFT 群同士のフィッティングを RANSAC (random Sample Consensus) と呼ばれる確率的なアルゴリズムによって処理する。そうして画像同士の位置関係が判明した後は，回転と歪みを考慮しつつ，従来のパノラマ合成技術を利用して結合するだけでよい。

……と言うような感じで，ざっと見渡してみただけでも僕の知らない概念が数多く含まれている。論文を読んでいる途中で，内容を理解するには決定的に前知識が足りていないことが分かってきたので，とりあえず書かれていることを文字通りに受け入れてみたところ，このような結果になったということだ。はっきり言って，何がなんだか全くわけが分からない……種々の画像認識研究の産物であるということだけは，よく分かった。

試しに Autopano を利用したパノラマ画像の作成を実際に行ってみたのだけれど，意外と結合のプロセスに時間がかかるというのが感想だ。自動認識と最適化・結合の全てを合わせて５分程度は必要とされる（画像の枚数によってはもっとかかるだろうと思う）。あとは，画像の種類によっては誤差が発生してしまうことがある。あらぬ部分が結合されてしまったり，奇妙な歪みが生じてしまったりという現象だ。特に，ゲームのスクリーンショット機能を利用したパノラマ画像の生成を試みたところ，自然画よりも誤差の部分が目立ってしまい，あまり見栄えのしない結果となってしまった。

まあ，それにしても，面倒な手作業を一切必要とせず，適当にデジカメでパシャパシャと撮影した画像からパノラマを作成することができるというのは面白いことだと思う。いくらデジカメが進化したとしても， FOV には物理的な制約が伴うから，この種の技術には依然としてニーズがあることだろうと思う。どうやら Matthew Brown 氏は Microsoft においてパノラマ画像生成ツールの開発に係っていたということだから（インターンとして参加していたらしい），今後同社から出るソフトウェアには同様の技術が利用されているものとみてよいかもしれない。

この Musik Messe は，北米最大の見本市 "NAMM" と並ぶ規模のものであり，楽器屋さん的にはかなり重要なイベントであるようだ。僕はシンセ関連のニュースサイトである "Sonic State" や "Harmony Central" などでその様子をチェックしていたのだけれど，最近は各社ブースのデモの様子を撮影したムービーなどもふんだんに上げられており，何気なく目を通しているだけでも面白いものとなっている。

色々と興味を引かれる製品もあったのだけれど，中でも特に異彩を放っていたのは， Roland の "V-Accordion" こと "FR-5" と "FR-7" だ。

これは，最初に報じられたのが４月１日であったために，てっきりエイプリルフールのジョークかと思っていたのだけれど，実は本気だったようだ。 roland.com では既に "V-Accordion" シリーズの製品紹介ページが用意されている。

この "V-Accordion" シリーズは，同社が新たに開発した物理挙動モデリング (Physical Behavior Modeling) 技術を利用して作られた「仮想アコーディオン」だ。ぱっと見た目は普通のアコーディオンだけれど，内部には物理的に音を発声する機構がまったく搭載されていない……純粋に電子技術によってのみ音を発生する「シンセサイザ」であるわけだ。

アコーディオンを電子化するメリットは，幾つか挙げることができる。最も大きなものとしては，ヘッドフォンを使えば外に音を漏らさずに練習ができるというものがある。あとは， MIDI インタフェースを持っていることから，通常の MIDI 入力機器としての利用が可能である（演奏の電子化が可能である）ことや，外部からの MIDI 経由での制御が可能となることが挙げられる。また，アコーディオンの他に合計３０個の音色が搭載されていることから，例えば「アコーディオンを利用してバイオリンの演奏を行う」なんて奇妙な技も可能となるようだ。

まあ，僕はアコーディオンなぞ弾いたこともないので，これ以上言うことは何も無いのだけれど……随分と面白い製品を投入してきたものだなと思う。アコーディオンは，欧州などでは庶民の楽器としてありふれた存在であるらしいから，その辺りへの売り込みを狙ったものなのかもしれない（現在，日本の Roland のサイトには，この製品の情報は存在しない）。

キワモノはさておき……シンセ趣味人的には Roland の SP-606 辺りが注目の製品となっているようだ。

なんかもう， AKAI の MPC シリーズのフォロワーであることは隠しようもないのだけれど…… "D BEAM" センサーのようにキャッチーな機能が色々と搭載されている所が面白いとは思う。あとは値段次第って感じだろうか……。

DoCoMo の P252iS の異様な小ささにも惹かれるものがあったのだけれど，発売されたばかりということで値が下がっておらず，見送ることにした。ちなみに Infobar は既に￥3,800 まで値下げされていた……。

家に帰ってから購入した携帯をいじりまわしてみて，その性能の充実振りにしばしの間驚いていた。僕が以前携帯を持っていたのは，まだ DoCoMo が i-mode サービスを始めたばかりの頃で，モノトーンのディスプレイに少ない文字量でせこせこと頑張っていたものなのだけれど……それがいまや，このレベルだからなあ。

まだあまり試してみてはいないのだけれど， Infobar では BREW アプリケーションを動かすことができる。現在 KDDI は BREW をアプリケーション動作環境として採用・推進する路線に走っているようだ。 Java とは違ってネイティブコードを動かすことのできる環境ということで，なかなか面白い差別化になっていると思う。

素人的な印象では，アプリケーションを Java ベースで作成するのとネイティブコードベースで作成するのとでは，パフォーマンスや応用の幅という点で随分と差が出そうな気がするのだけれど，実際のところどうなのだろうかと思う。 TCP に直に触ることができるというのも，応用の幅を広げる要素としては重要そうなところだ。ただ，いわゆる「勝手アプリ」が作れないというのは，少し寂しいところか……。

携帯を買うついでに，ジャンク屋や同人ショップの類に立ち寄り， Campanella の "SoulS" と，日本竜太の "Robin Trip The Album" と，あとは適当に目に付いた CD を数枚買い込んできた。

何と言うか，この辺りの「インディーズＣＤ」と「同人ＣＤ」の間の境界線上の世界が放っている独特の雰囲気が楽しくて，一定の距離を保ちつつも緩いウォッチングを続けている。結局の所，これはカウンターカルチャー的な世界であるので，ここから独自の流れが生まれることは極めて珍しいのだけれど，メインストリームにおいては受け入れられにくい要素や，大衆との迎合を果たせずに淘汰されてしまう流れにある要素などが，この世界においては「個人の趣味」という極めて純粋なモチベーションのもとに作品として昇華されていく。それは文化として未成熟なものではあるかもしれないけれど，作り手の存在感を確かに感じることができるという点において，その欠点を補うほどの魅力が存在すると，個人的には考えている。

まったくノーマークの作品だったのだけれど，見た目の奇麗さに惹かれてプレイしてみた次第だ。

このゲーム "Painkiller" は，ポーランドの新興企業 People Can Fly によって開発されたオーソドックスな FPS ゲームだ。

ゲームを起動すると，タイトル画面の下に Havok と Lua のロゴが堂々と表示される……なるほど，たしかに箱は物理っぽく壊れるし，敵キャラはラグドールっぽく跳ね回る。あまり派手な使い方ではないけれど，ゲームの要素には絡まない範囲で無難に使ってみている感じがする。 Lua に関しては，まあ， mod 対応などを考えて導入してあるということだろうと思う。

デモ版のステージを通してプレイしてみた印象では，それほど新しい要素のあるゲームであるとも感じられなかった。いかにも残忍な格好の武器を駆使して，うようよと湧いて出てくる敵を殺戮し，先に進んでは殺し，先に進んでは殺し……こんなにもシンプルに「殺し」を求めるゲームは久しぶりのように感じられる。そういった点では，どこか "Serious Sam" を彷彿とさせるところもある。

でも，決してそれが悪いわけじゃなくて，むしろ僕はこの「殺し」を純粋に楽しむことができた。特に近接武器 "Pain" を振りかざしながら敵に突進していくのは実に爽快だ。敵の銃火を巧みに潜り抜けながら間合いを詰めていき，隙を見て一気に Pain で切り刻む。血飛沫を上げながら（物理挙動で）悶え苦しむ敵を払いのけつつも，他の敵を次々に残忍な凶器の餌食にしていく……この緊張感と残酷さのバランスが「非常にいい具合」にまとまっていると感じた（ここで残忍さを強調するあまりに緊張感を崩してしまったゲームは過去に多く存在する）。

言うなれば，「最新のテクノロジとノウハウを応用して作られた "Quake"」と言ったところではないかと思う。恐らく， FPS に興味の無い人にとっては魅力の無いゲームであろうし， FPS が好きでも単純なゲームに食傷気味の人にとっては，やはり依然として魅力の無いゲームかもしれない。しかし， "Half-Life" 以降に続いている「ドラマチックな FPS ゲーム」の流れに何か違和感を覚えていた人にとっては，いつかの懐かしい「イドの疼き」を思い出すことのできるゲームとなっているのではないかと思う。

細かなところだけど，何気に奇麗だなと思ったのは，海面の表現だ。恐らく Tessendorf 方式の応用ではないかと思う。

他にも，フィードバック系のエフェクトを効果的に利用するなど，視覚面において非常に洗練された内容となっている。革新的な技術が利用されているわけではないのだけれど，運用のレベルにおいて非常に上手い仕事がなされているというのが，全体的な印象だ。

ともあれ，個人的に色々と魅力を感じるゲームであることには違いない。機会があれば実際に製品版もプレイしてみたいと思う。ちょっとした憂さ晴らしなるかもしれないし，ね……。

この本は，アジャイル開発プロセスの一種であるところのスクラム (Scrum) に関して解説を行った書籍だ。 170 ページほどの薄めの本なので，あまり気張らずとも気軽に読み始めることができると思う。

開発手法としてのスクラムの特徴は，まず軽量であることが挙げられると思う。スクラムは， XP のように極端かつ厳格な約束事の数々によってエンジニアリングの方法を「矯正」してしまうのではなく，プロジェクトの管理に関して非常にシンプルな幾つかの方針を提示するに留めている。それゆえに，既に何らかの方法論を持っている・いないにかかわらず，比較的抵抗無く受け入れられる可能性を持っているのではないかと思う。

スクラムのコンセプトについては， Developers Summit 2003 における山田正樹氏の公演資料の中に簡潔にまとめられている。

スクラムの基本的な仕組み自体は，１枚の紙によって説明できるほどシンプルなものだ。「バックログ」と呼ばれる作業リストを常に管理し，「スプリント」と呼ばれる１ヶ月のイテレーションによって作業を進行させ，「デイリースクラム」と呼ばれる簡単なミーティングを毎日行い続ける。そのような枠組みによって，変化し続ける状況への柔軟な対応と，確実に結果を出し続ける集中力の維持を両立し，かつ，自己組織化された強力なチームワークを作り上げることを目標にしている。

スクラムの特徴として挙げられることのひとつに，チームメンバのプロジェクトに対するコミットメント (commitment) を重視するというコンセプトが存在する。この「コミットメント」あるいは「コミット」という語の持つニュアンスには非常に難しいものがあるようで，ゆえにカタカナで表記されることが多いのだけれど，極力簡潔な訳を与えるならば「身を捧げる」とするのが良いのではないかと思う。

これに対応して用いられる語が "involve" であり，こちらは「巻き込まれる」とか「関与させられる」とか，比較的受身的なニュアンスを持っている。この "commit" と "involve" の違いに関して，スクラムでは「ニワトリとブタの逸話」がよく持ち出される。

ニワトリとブタがレストランを開くことにしました。
ブタは言いました。「名前はなんにしようか？」
ニワトリは言いました。「『ハム＆エッグス』なんてのはどう？」
するとブタは言いました。
「やめようよ。きみは巻き込まれる (involved) だけだけど，ぼくは身を捧げなきゃ (committed) なんないんだぜ」

スクラムにおいては，スクラムチームを構成するメンバー全員が「ブタ」となり，自らのコミットした仕事を達成するために全力を尽くすことが要求させられる。その目標を達成する上で障害となる要素を早期に発見したり，あるいは，その目標から集中を逸らしてしまうような要素に対しての耐性を高めるために，前述のような枠組みが用意されているというわけだ。

スクラムにおいては，この「スプリントバックログ」がスケジュール管理の要となる。ここには，ガントチャートや PERT 図のような管理表は存在しない。スプリントバックログを毎日更新し，絶え間ない追跡を行い続けることが，スケジュールの管理と分析に結びついている。また，バックログを消化する目的であれば，どのような順序や方法によって作業を進めることも許されている。その部分を予測によって定義することは，プロセスに対するカオスの混入を意味するとスクラムは主張する。そこをあくまでも「アジャイル的に」解決するのがスクラムのスタイルであり，それに必要とされる情報の収集量を高めるために，デイリースクラム（日次ミーティング）のような要素の導入が義務付けられているということだ。

このような管理手法は，既に何らかの方法論を確立している人々にとっては，いまさら何でもないことかもしれない。スクラムの提示する方法論には，むしろ原始的な側面が存在する。予測の難しい要素を深くまで追うのではなく，予測の可能な単位への限定と分割を行うことによって，プロセスを管理可能なものへと変質させる。すなわち，原理的なことを言うならば，これは管理の精度を上げるものではなく，むしろ，予測の難しい部分を切り捨てることによって，プロセスに対するカオスの混入を防ぎ，結果的に信頼性を高める働きを持つものであると�

Physical Structure (2)

Software Engineering Roundtable

GUIdebook

Happy Mac

Jacques Carelman

The Google File System

Memory resident

String Matching Algorithms

ES-1 mkII

Casshern

Lost in Translation (1)

Lost in Translation (2)

Lost in Translation (3)

Deductive Error (1)

Deductive Error (2)

Deductive Error (3)

BFV

Decimator

Rock Paper Scissors (1)

Rock Paper Scissors (2)

Postmortem

Autopano

V-Accordion

Infobar

Painkiller

Scrum (1)

Scrum (2)