2004-08-06
マイルストーンが達成された。一時期は余裕を見せていたにもかかわらず，結局，締め切り間際は非常に厳しい進行となってしまった。最終的には相応に良い結果を収めることができたので良しとしたい。障壁として非常に取り組みがいのあるものであったと感じられる。
３０時間以上の継続勤務を終え，家に帰ってから１２時間以上の睡眠をとった。明けてからは世間よりも一足早い夏休みに突入し，一路実家へと帰ることになった。実家の方では，いつも通りの食っては寝るだけの生活だった。
マイルストーンの締め切りの前日，非常に忙しく働いていたことを記憶しているのだけれど，実のところ，一体何をしていたのだろうかと思い出してみる。前日に指摘された実装漏れへの対処，それから，自分の担当範囲に関連するバグの修正。担当範囲外のバグ修正にも取り組んでみたものの，今回はあまりうまくいかなかった。
それ以外に行っていた作業としては，後まわしにしていた効果音の組み込み作業などがあげられる。効果音の組み込みは比較的手軽に行うことのできる作業であるため，締め切り間際まで先送りにしてしまうことが多い。しかし，そこで要らぬバグを混入させてしまうこともあるので注意が必要だ。今回はその点に関してちょっとした教訓を得ることができたと思う。
ビルド（ＲＯＭの作成）に関しては，自分はスケジューリングを行っただけであり，実作業にはほとんど絡んでいない。テストプレイにもほとんど参加することができなかった。実作業を多く抱えていると，作業を打ち切ってテストに移行するタイミングを見極めることが難しい。担当者でなければ確認することの難しい要素というものも存在するのだから，やはりどこかで作業を打ち切らなければならない。専属のテスト担当者が居るならばまだしも，内部向けのマイルストーンでは，各々が自主的にテストを行うぐらいしかできない。
この辺りの問題に関しては，ルーズに対処していることが裏目に出てしまっている印象もあるため，もう少し厳しくルールを定めた方が良いのかもしれないと感じる。マイルストーンとは言っても，一定の品質は保証されなければ……。
全体の進行に係わることとしては，作業進行の確認や未完成項目の追跡，修正担当者の割り当て，他セクションとのやりとり等が挙げられる。実のところ，締め切り間際の時期において多くの時間はこれらの作業に費やされており，創造的な作業はほとんど行っていないというのが実状だと言える。
今回のマイルストーンを経て気がついたのは，この時期になると直接的なコミュ二ケーションが激増するという事実だ。そして，その対象は，残りの作業を多く抱えている人に限って集中してしまう。
ここには負のスパイラルが存在する。残りの作業を効率良く消化するには精神集中を得る必要があるにも係わらず，その集中を分断しつつコミュニケーションにも対応しなければならない。そうして質問に答えたり，ミーティングに出席などしているうちに貴重な時間は過ぎ去り，残り作業量は相対的に増化してしまう。残り作業量が増えれば，コミュニケーションの発生量はますます増加してしまう。
このジレンマを解消するためには，そもそも作業量に偏りが出ることを避けるというのも重要であるのだけれど，できる限り直接のコミュニケーションを避けるという周囲の配慮も重要だ。
作業進行の原則として「全てはボトルネックを中心として考えるべきである」というルールがある。たとえ返答がすぐに得られなければ先に進むことができないというような場面に遭遇したとしても，安直に直接のコミュニケーションを用いることは避け，過去の文書を参照するか，あるいはメールを用いるなどの配慮が必要であると感じた。
2004-08-07
ソフトウェア産業におけるデスマーチ現象をテーマとして扱った著作で知られる Edward Yourdon 氏は，デスマーチの持つ性質を測る尺度として「成功の可能性」と「幸福度」のふたつの軸を導入し，それぞれの大小によって次の４種への分類を行っている。
http://mcpmag.com/columns/rss.asp?editorialsid=661
成功の可能性が高く，また幸福度も高い状態を「ミッション・インポッシブル」とするたとえは面白い。このようなプロジェクトにおいてはチームの戦意は高く保たれ，辛い労働をもいとわずに成功へと猛進を続けることになる。その見返りが本当に相応のものであれば，不満を少なく保つことができるだろうと思う。しかしそれでも，本質的にデスマーチであることには違いが無いから，人材の喪失の可能性が高いことには変わりが無いと言える。
自分は未だ本当のデスマーチと呼べるような状況を体験したことが無い。そこそこに厳しい状況は毎度のごとく経ているものの，それらはどれも終わりの見えている一過的なもの（いわゆる「修羅場」）であり，デスマーチと呼ぶに相応しいケースであるとは思えない。途中で開発の中止されたプロジェクトに係った経験はあるが，それは少し特殊な経緯によって引き起こされたものであり，デスマーチとはほど遠い状況下における出来事だった。
「デスマーチ」という単語は，ソフトウェア産業における惨状を表す以外にも用いられることがある。最も有名かつ悪名高く知られるのは，旧日本軍の行った蛮行のひとつである「バターンの死の行軍」だ。
http://www.mainichi.co.jp/life/family/syuppan/chronicle/1937...
http://history.acusd.edu/gen/st/~ehimchak/death_march.html
http://en.wikipedia.org/wiki/Bataan_Death_March
http://en.wikipedia.org/wiki/Bataan
当時，軍の司令官であった本間中将は，バターン半島の陥落によって得られた５万人余りの米兵およびフィリピン兵の捕虜を，内陸にあるオードネル収容所まで輸送する作戦を実行に移した。出発地であるバターン半島はマリヴェレスからオードネル収容所までの道程は 100 マイル (160km) 以上あり，その約半分を徒歩で移動し，残りを貨車によって輸送する算段だった。捕虜たちは篭城戦によって限界まで疲弊していたにもかかわらず，十分な食糧が与えられることは無かった。行軍から脱落する者はただちに殺され，あるいはさしたる理由も無く殺されることもあったという。
また，国内の出来事としては，八甲田山の雪中行軍が有名ではないかと思う。これも非常に陰惨な「死の行軍」のひとつだ。
http://www.mainichi.co.jp/life/family/syuppan/chronicle/1900...
これらの「死の行軍」に共通しているのは，元から無理のある計画を達成するために限りなく高い代償が払われ，行軍に参加した者は何処までも続く苦しみを味わされるという状況だ。時にはその目標は終ぞ達成されることなく，兵士達は己の死によって行軍から開放された。
ソフトウェア産業における「デスマーチ」との決定的な違いは，我々は自らの意志によって行軍から外れることが可能であるという点だ。 Yourdon 氏や DeMarco 氏をはじめとする専門家達は，「あるいは履歴書の準備をすベきである」というような言いまわしをよく用いる。ひとつのプロジェクトを完遂させるために要される時間は決して短くなく，エンジニア達は自らの人生における貴重な年月をそのプロジェクトと共にしなければならない。それが，辛くとも刺激と成功の予感に満ちた「ミッション・インポッシブル」なのか，それとも，ただ理不尽に苦しみが続くだけの「デスマーチ」なのか，それを早期において見極め，己の歩むべき道を決めることが肝要であるということだ。
2004-08-08
夏休みの間は，実家に帰省したほか，家の掃除や日用品の買い出しなど，仕事に追われてほったらかしになっていた雑務をゆっくりとこなしていた。久々に緩やかな日常を送ったことで，だいぶ精神的なリフレッシュになったと思う。
休みの間，ずっと階下から音楽のようなものが聞こえてくる。同じフレーズが繰り返し聞えてくることから察するに，どうやら作曲を行っているようだ。先ほどから曲の展開を何度も練り直しているのが判る。オーソドックスなポップス曲のようだけれど……一体何のための曲を作っているんだろう。
階下の作曲家はどうやらかなりの勤勉家のようだ。僕が起きるよりも前から活動を始め，夜を徹して朝まで作業を続けている。夜が明ける頃になるとカブ（単車）の音と共にどこかへと消え（恐らく新聞配達のバイトでもしているのだろう），戻ってくるとまた活動を開始する。しかし，何と言うか……夜の間ぐらいはへッドフォンを使った方がいい。気持ちは分らないでもないけれど，これでは隣の部屋の人は堪らんだろうと思う。
曲の展開が固まると，次はオケの強化を行う作業に入ったようだ。伴奏にピアノが追化され，ギターが追加され，その他の細かなウワモノが追加され……次第に曲の体裁が整っていく。その工程には，あたかも画家がキャンバスの上に絵の具をのせていくような自由さが感じられる。気になるフレーズを好きな所から自由に再生し，そこに思いついた音を自由にのせ，その作業を自分が満足するまで繰り返す。ＤＴＭ環境をマスターすると，こんな作業風景になるんだということが分かる。なかなか興味深い。
そして今日，晩飯を食ベに出かける際に気が付いたのだけれど，昨日から作り続けていたらしき曲に，女性ボー力ルによる仮歌がのせられていた。いやはや，そんなものをいつの間に収録したんだろう。ネット上でコラボレーションでも行っているんだろうか……いや，まさかね。
仮歌がのり，オケも整理され，だいぶ曲としての体裁が固まってきたようだ。結局，階下の作曲家の正体は分らずじまいなのだけれど，この曲が一体何に使われるのだろうかと想像してみるのも面白い。本来は迷惑な住宅騒音であるのだから，そのくらい勝手に楽しんだってバチは当たらないだろうと思う。
2004-08-09
夏休みの間に HP の iPAQ h1937 を購入した。
http://www1.jpn.hp.com/products/handhelds/pocketpc/h1937/
以前から携帯の可能な機器が欲しいと考えていたのだけれど，その結論として購入したのがこの iPAQ だ。秋葉原はソフマップの中古モバイル館で 18,800 円だった。考え抜いた末の結論にしては随分と安っぽい買い物になったものだなと思う。
携帯機器が欲しいと考えるようになった主な理由は，通勤中に読むための文書を紙に印刷しているのが面到になったためだ。そもそも紙はかさばるし，読み終わったらゴミとして捨ててしまうので資源の無駄使いでもある。それに，会社の資源を私用に費やしているという負い目もあった。
そのような理由なので，機器に求めるスペックはそれほど高くなかった。ただ HTML と PDF がまともに閲覧できれば，それだけで基本的な要求を満たすことができる。あとは PC との連携が手軽であればそれに越したことは無い。また，職場の LAN は私物の接続が禁止されているので，できれば自力で通信を行う機能を有しているものが好ましい。
個人的に OneNote を愛用していることから Tablet PC にも興味があったのだけれど，どうも時代の趨勢をみるに Tablet PC の春は当分やってこないだろうという気がしてきていた。 Microsoft を中心とした派閥が奮闘してはいるのだけれど，いかんせん内容の割には値段が高いという印象が拭い切れない。
http://www.instat.com/press.asp?ID=994&sku=IN0401152ID
http://www.microsoft.com/japan/windowsxp/tabletpc/default.as...
http://www1.jpn.hp.com/products/tabletpc/tc1100/
そんな状況下において， VAIO type U の登場は一筋の光明のように思えた。
http://www.vaio.sony.co.jp/Products/VGN-U50/
しかし冷静になって考えてみると，たかが通勤中の文書の閲覧のために２０万円近くの出費をするというのも，少し大袈裟な話のようにも感じられる。それに，長めに見積もっても２時間程度しか動かないというのは，いくら通勤中のみの利用と言えども少し短過ぎるのではないかと感じた。
それで結局，白羽の失が立ったのが ipaq であったということだ。Pocket PC ベースであるがゆえに Acrobat Reader for Pocket PC や Pocket IE 等の信頼あるソフトウェア群が動くという点が選出の理由だ。
http://www.adobe.co.jp/products/acrobat/readerforppc.html
http://www.microsoft.com/japan/users/mobile/007/default.aspx
それでいて，余計な機能は殆ど何も積んでいないという潔さも気に入った。実際間題として，既に本格的な衰退の始まっている PDA 市場においては，そもそも店頭で購入することのできる機種が CLIE と iPAQ 程度しか存在しないというのが実情でもある。
2004-08-10
以前 PDA を利用していた頃の経験から， PC - PDA 間の連携の面到臭さを知っていたので， iPAQ の購入と同時に AirH" の導入も行ってみることにした。単体でのネットワーク接続機能を持たせることによって， PC との連携を行わなくとも済ますことはできないだろうか……という魂胆だ。
自分が購入した h1397 には，外部拡張インタフェースが SD カードスロットしか搭載されていないので，当初から候補は SDIO 対応の AH-S101S に絞られていた。
http://www.ddipocket.co.jp/p_s/products/content/ah_s101s.htm...
こんなに小さなカードの中に必要な通信機能が全て詰め込まれているというのも驚きだ。 128k パケット通信に非対応という制限はあるものの，それでも十分なインパクトがあると思う。
しかし実際に AirH" を利用してみると，これが思ったよりもレスポンスに劣っていることが分った。最初の接続の確立までにかなりの時間が要されるし，接続後の通信速度も近頃の基準からすればかなり低速な部類に入る。地下鉄の駅に入った瞬間にウェブページを開いても，駅を出るまでにページを開き終わらないことがある。やはり 32k パケット通信ではその程度の速度しか出ないのだろうか。 iPAQ 側の制限ということも考えられなくはないのだけれど……。
逆に PC との連携に関しては全く間題が感じられない。 Microsoft 製の標準ツールである ActiveSync を使えば， PC との間のファイルの転送と同期，それにネットワークへの接続を簡単に実現することができる。特に， PC との接続を行うだけでネットワークへの接続も同時に確立されるという点が，非常に手軽で使いやすい。
iPAQ 上でブログの閲覧を行うツールとして，試しに PocketRSS を入れてみている。
http://www.happyjackroad.com/AtomicDB/pocketpc/pocketRSS/poc...
iPAQ を USB 経由で PC に接続してから， PocketRSS のリロードボタンを押すだけで，すべての購読記事を読み込むことができる。あとは，オフラインで好きなだけ閲覧すれば良い。全文を RSS で配信しているブログならば，これだけで購読を行うことができる。
2004-08-11
一般的なオフィスにおいて日常的に用いられている文房具の中でも，ステープラー（ホッチキス）やパンチ（穴あけ）などのような穴を開ける系の道具には，手に伝わってくる感触に独特の魅力がある。ステープラー愛好家のウェブサイト VirtualStapler.com のトップページに飾られている「バーチャルステープラー」は，その感触を上手く表現することができていると思う。ガチガチと叩いているだけでも面白い。
http://www.virtualstapler.com/
VirtualStapler.com のギャラリーページには，同サイトの主催者が集めたステープラーのコレクションの数々が飾られている。
http://www.virtualstapler.com/gallery.asp
針を使わない「ペーパーステープラー」のギミックを解説したページなど秀逸だ。
http://www.virtualstapler.com/gallery/paperstapler.asp
ステープラーの歴史に関しては，ウェブサイト "The Stapler Database" が参考になる。
http://www.calcampus.com/stapler/index.htm
また， Wikipedia の方にもステープラーの起源に関する記述がある。
http://en.wikipedia.org/wiki/Stapler
ホッチキスという名称の元となった「ホッチキス氏」がステープラーの発明者である……という話をどこかで聞いたことがあるような気がするのだけれど，上記の資料を参考にする限りでは，ステープラーの「発明者」を個人として特定することは難しそうだ。「紙を綴じる装置」自体は 19 世紀以前から存在しており，そこから様々な改良を経て現在のステープラーの姿に至っている。 The Stapler Database の記述によれば，ステープラー製造メーカーとしての "Hotchkiss Sales Co." は 20 世紀初頭に有名なブランドであったものの， 1950 年頃には既に存在しなくなってしまっている。
http://24.97.84.9/stapler/hotch.htm
国内最大手であるマックス社のサイトにも，「ホッチキス」の歴史について触れているページがあるものの，結論は曖昧にぼかされている。
http://wis.max-ltd.co.jp/op/h_story2.php?h_story=1
そもそも VirtualStapler.com のページに辿り着いたのは，Clive Thompson 氏のブログサイト "collision detection" において紹介されていた Swingline 社の真っ赤なステープラーの記事が元だった。
http://www.collisiondetection.net/mt/archives/000927.html
http://www.swingline.com/html/1695.html
これは，映画 "Office Space" に登場する真っ赤なステープラーを商品化したものだ。
http://www.virtualstapler.com/office_space/
性能にあまり差が出ないものであるからこそ，どうせなら映画に登場したあの印象的なステープラーを……という気持ちは分からないでもない。その需要を見越して，もともと存在していなかった製品を製品化した Swingline 社も，ユーモアの分かる企業であると思う。
2004-08-12
ゲーム制作の現場においてプログラマに求められる作業として，かなり大きな比重を占めているのが，コンテントパイプラインの構築だ。ゲームのコンテントは様々な種類のデータから構成されている。モデルデータにアニメーションデータ，テクスチャデータ，動画データ，サウンドデータ，テキストデータ，スクリプトデータ，等々。それらのデータをいかにして作成し，変換し，利用し，そして管理するのか ― そのパイプラインの設計と実装は，基本的に全てプログラマに任されている。
先日， Noel Llopis 氏のウェブサイト Games from Within に転載された記事 "Optimizing the Content Pipeline" （初出は Game Developer 誌）は，この「コンテントパイプラインの構築」という話題に関して触れた記事だ。
http://www.convexhull.com/articles/gdmag_content_pipeline.pd...
http://www.gamesfromwithin.com/articles/0408/000027.html
ごく基本的な内容で構成されているものの，パイプラインを構築する際の要点が丁寧にまとめられている。入門編として非常に参考になるのではないかと思う。
コンテントパイプラインの構築は，実際には非常に泥臭い仕事になることが多いと感じている。コンテントパイプラインとは，言わば，制作に関連する様々な環境を１つの流れの中に結合させる仕組みのことだ。ゆえに，各環境において生じる様々な問題が，このパイプラインの中に流れ込んでくる。ツールの問題や，ネットワークの問題，ファイルサーバの問題，ＰＣの問題，デバッグマシンの問題，ＯＳの問題，セキュリティの問題，データ保護の問題，それから，それから……こうして考えてみると，シスアド色の強い仕事であると感じる。ゆえに，シスアド兼ツール職人的なタレントを持った人が居れば都合良いに違いないと，昔から考えている。
コンテントパイプラインと関連のある話題として，コンテントの制作に利用するインハウスツールの問題がある。これに関しては GDC 2004 における Don Moar 氏の講演 "Growing Dedicated Tools Programming Team: From Baldur's Gate To Star Wars: Knights of the Old Republic" が興味深い。
http://www.gdconf.com/archives/2004/moar_don.doc
http://www.gamasutra.com/gdc2004/features/20040324/moar_01.s...
Bioware 社においてツール開発チームのマネジメント役を務める Moar 氏は，この講演において，ツールの開発を専門に扱うチームを構成することの有効性を説いている。同社は "Baldur's Gate" や "Neverwinter Nights" を始めとするコンテントリッチな RPG 作品で広く知られている。同社のツール専門チームは，それらのコンテントの作成工程を支えるバックボーン的な存在だ。このチームの構成人数は今年中に 22 人にまで増える予定であり，これは同社におけるプログラマー人口の 1/3 を占めるに至っている。
件の記事において興味深いのは，社内におけるツール専門チームのあり方や，その運営方針にまで詳しく触れていることだ。特に，メンバーのモチベーションの問題や，キャリアの育て方の問題にまで触れている点がユニークで面白い。
そして Moar 氏は，これらのチームのメンバーが，実際のゲームの制作を担当しているチームと密接な係わり合いを持つことが重要であると説く。ツールプログラマにとっての至上の目標とは，決してツールを完成させることではない。それはゲームを完成させることにあるはずだ。最終的な成果に対する責任を共有し，制作の現場に深く係わっていくことが，ツールの品質と信頼性を向上させることに繋がり，延いてはツールプログラマの達成感の獲得に繋がるということだ。
2004-08-13
最近，何故か無性に iPod が欲しくなった。
シリコンオーデイオの類は以前からたまに欲しくなることがあるのだけれど，その度に，家の押入れの中にある MD ウォークマンの事を思い出して，意気消沈してしまう。この手のデバイスは，取り扱いに色々と面倒なところがあって，じきに使うのをやめてしまうのだ。
しかし iPod を始めとする HDD 搭載のデバイスには，従来のポータブルオーデオデバイスとは少し異なった性質が備わっている。自分の持っている CD のコレクションが全てデバイスの中に入ってしまうのだ（よほどの音楽好きにもなると「全て」は難しいかもしれないけれど，それでも「最近買った CD がほぼ全て」なら入るだろうと思う）。アルバム毎にメディアを入れ換えたり， PC から転送し直したりする必要は無い。膨大な品揃えを誇る iTunes Music Store から好きな曲をダウンロードしたならば，あとは面到なことは一切無しに，いつでもどこでもその曲を楽しむことができる。この「大容量化」と「配信サービス」の２つの要素に，これまでのデバイスには無かった新たな魅力を感じた。
欲しくなる所までは勢いが良かったのだけれど，そこから先にいくつかの問題があって，未だに購入するには至っていない。購入を思いとどまらせている理由のひとつは iPod mini の登場であり，もうひとつの理由は国内における iTunes Music Store の不在にある。
iPod mini の登場は各種メディアでも大きく取り上げられており，現在も入手不可能な状態が続いている。
http://www.nikkei.co.jp/news/main/20040724AT1D2306R24072004....
http://www.amazon.co.jp/exec/obidos/tg/detail/glance/-/elect...
この品薄状態は， iPod mini の HDD として利用されている日立製のマイクロドライブの供給不足にあると報じられている。
http://macobserver.com/article/2004/03/25.14.shtml
http://www.itmedia.co.jp/news/articles/0403/26/news012.html
http://www.itmedia.co.jp/news/articles/0405/17/news027.html
iPod mini は元祖 iPod と比較して容量が減らされているものの，それでも十分な容量を持っているし，より小さく持ち歩きやすくなったボディは，容量の減少を補うだけの魅力を持っていると感じる。また，さりげなく重要なポイントとして，価格もリーズナブルな設定に抑えられている。ここまで要素が揃っていると，もはや元祖 iPod は買う気がしないというのが個人的な感想だ。
単純に品薄であるという以外に iPod の購入を思いとどまらせる理由として，国内における iTunes Music Store の不在がある。欧米圏における iPod の成功を考えるうえで iTunes Music Store の存在を無視することはできない。その片腕的存在が欠けてしまっているというのだから，その時点で iPod の魅力は半減してしまっていると言っても過言では無いと考えている。
http://www.itmedia.co.jp/news/articles/0404/30/news038.html
先月に発表された四半期決算の報告によれば， iTunes Music Store の売り上げを含めた iPod 関連製品の売り上げは合計で 3 億 2200 万ドルに達しており，これは Apple 社全体の売り上げの 16% を占めるに至っている。 iPod 自体の売り上げは前四半期の異様な盛り上がりから下降に転じているものの， iTunes Music Store の売り上げは依然 20% 以上の成長を保っている。
http://www.apple.com/pr/library/2004/jul/14results.html
http://hotwired.goo.ne.jp/news/news/business/story/200407151...
iTunes Music Store のサービスが国内において開始されそうな気配は，今のところあまり感じられない。 Apple 社外の動きとして幾つかの音楽配信サービスが開始されているものの，いずれも品揃えの面で未だ実用には遠い段階にあると感じる。この辺りの事情に関しては山崎潤一郎氏のコラムに詳しい。
http://arena.nikkeibp.co.jp/col/20030507/104559/
http://arena.nikkeibp.co.jp/col/20031021/106302/
そうこうしている間に第４世代 iPod なるものも登場してしまい，わけの分からない状態になってしまった。
http://www.watch.impress.co.jp/av/docs/20040720/apple.htm
今は取り敢えず iPAQ に 64MB の SD カードを挿すことによって，ポータブルオーディオプレイヤーの代用としている。 Pocket PC 上で Windows Media Player 9 が動くので，容量に制限があることを除けば，それなりに使うことができる。しばらくの間はこれでしのいで，今後の動向を見守りたいと考えている。
2004-08-16
最近の iPod 周辺の動きとして挙げられるのが，今月の初めに行われた PortalPlayer 社の株式公開 (IPO) だ。
http://japan.cnet.com/news/biz/story/0,2000050156,20070388,0...
http://www.siliconstrategies.com/article/printableArticle.jh...
http://www.business2.com/b2/web/articles/0,17863,679399-1,00...
PortalPlayer 社は， iPod の中枢を構成するチップ PP5000 シリーズの設計を担当している会社だ。 iPod の誕生と PortalPlayer 社の関係については Wired の記事に詳しい。
http://hotwired.goo.ne.jp/news/news/business/story/200407221...
同社の IPO 申請は，世間での iPod の人気から考えて十分に注目を集めそうな話題であるようにも感じられるのだけれど，実際には投資対象としてはかなりリスキーな存在であるというのが投資家の評価であるようだ。上に挙げた記事においても，競合他社と比較して規模が小さめであることや，未だ黒字体制に転じることができていないことなどを含め，様々なリスクが指摘されている。
iPod シリーズの最新機種である iPod mini および第４世代 iPod には，同社製のチップである PP5020 が使用されている。
http://apple-history.rhapsody.com.hk/ipod_mini.html
http://apple-history.rhapsody.com.hk/ipod_4g.html
同社のウェブサイトでは PP5000 シリーズの概要書が配布されている。この資料から PP5020 の仕様を知ることができる。
http://www.portalplayer.com/products/publications.html
実際にこれらの概要書に目を通してみると，これが予想よりも機能豊富なチップであることが分かる。 CPU は最速 80 MHz 駆動の ARM7TDMI （GBA 等に利用されている ARM 社の CPU）を２基搭載しており，そこに SDRAM コントローラ，オーディオインタフェース， LCD コントローラ（640x480x18bit まで対応可能）， NTSC/PAL 出力に対応した CCIR 601/656 インタフェース， USB 2.0 コントローラ， FireWire コントローラ， ATA インタフェース， CompactFlash インタフェース，ボタン入力マトリクス，等々の機能が詰め込まれている。
ここで少し興味を引かれることがある。このチップには映像出力の機能をはじめとして， iPod では全く使用されていない機能がいくつか搭載されている。概要書の記述によれば，このチップはリアルタイムに MJPEG (Motion JPEG) を再生することが可能であるとされている。 LCD 出力の仕様も iPod の質素な操作パネルのためにしてはやけに充実しているし，実のところ家庭用 TV に出力する機能まで有している。映像以外の部分では ATA インタフェースの存在が意味深長だ。 ATA インタフェースを利用すれば CD-ROM ドライブや CD-R ドライブ等に直結することも可能となる。
これらの機能の存在を「マルチメディア版 iPod」の伏線であると解釈するのは面白い想像ではあるものの，あまり現実味のある話であるとは言えない。スティーブ・ジョブス氏は以前からポータブルビデオ分野への参入には興味が無いことを示唆している。
http://www.engadget.com/entry/6189743542028408/
http://www.ehomeupgrade.com/archives/000415.php
個人的には，ジョブス氏がここまで断言を行ってしまっていることに対して興味が湧く。一般には多様化の方向に進むことによって新製品の展開を維持し続けているポータブルデバイスの世界において，敢えて音楽のみに注力していこうというのは，相当な自信の表れであると感じられる。
2004-08-17
先月末， Office 2003 の Service Pack 1 の提供が開始された。
http://www.microsoft.com/japan/office/system/2003sp1/default...
お馴染みの Office スイートに関してはともかくとして， OneNote と InfoPath に関しては，まだ登場してから間もないソフトであることから，顕著に改良の感じられるサービスパックとなっている。個人的には OneNote に関して細かな使い勝手の向上が図られている点が嬉しかった。「ここがこうなればなあ……」とか「ここがなんでこうなんだろうなあ……」などと感じていた点がほとんど改良されていることには，驚きさえ感じる。
携帯機器（Pocket PC ないしは Smartphone）との連携が行われるようになった点も嬉しい。会議中や通勤中などに書き溜めておいたメモが， PC に繋ぐだけで自動的に OneNote 上のページとして取り込まれるようになっている。あまり派手な改良ではないけれど，なかなか便利な機能ではあると思う。
OneNote 2003 SP1 の内容に関しては，以前から Chris Pratley 氏が自身のブログにおいて触れていた。
http://weblogs.asp.net/chris_pratley/archive/2004/06/25/1656...
http://weblogs.asp.net/chris_pratley/archive/2004/07/27/1989...
興味深いのは，手書き機能の改良や，ビデオノート機能の追加など，タブレットＰＣ向けフィーチャーの増強に力が入れられている点だ。もともとタブレットＰＣで利用することを意識したソフトウェアではあるものの，実際にタブレットＰＣ上において OneNote を利用しているユーザはごく少数であろうと思う。この辺りに見られるような Microsoft のタブレットＰＣにかける情熱には，少し異様なものを感じることがある。企業内で業務用ＰＣとしてタブレットＰＣを導入するケースというのは，それほどまでに多いものなのだろうか？ 市場の動向はさておくとしても，この路線はゲイツ氏の肝いりであるということであるおから，まだしばらくの間は粘り続けることだろうと思う。
もう１つ興味があるのは，コラボレーション関連の機能が強化されている点だ。もともと OneNote にはノートを他人と共有する機能が備えられていたものの，これは単純に文書をネットワーク上で共有するというだけの機能であったと聞いている。これが SP1 においては，複数人がリアルタイムに同一のノートを編集することのできる「共有セッション」と呼ばれる機能に進化している。 Pratley 氏自身も，この「共有セッション」機能を利用して会議を行っているとのことだ。
http://www.itmedia.co.jp/news/articles/0407/01/news057.html
自分の周囲には OneNote ユーザが居ないため，この機能を試す機会は未だ無いのだけれど，非常に面白そうな機能ではあると思う。
Office 2003 SP1 の提供開始と同じぐらいのタイミングで，ひっそりと "PowerToys for Microsoft Office OneNote 2003" の提供も開始されている。
http://office.microsoft.com/assistance/preview.aspx?AssetID=...
IE や Outlook のツールバーに「OneNote に送る」ボタンを追加するという，非常にささやかな小ネタ的ツールだ。今後も恐らくこのように，マニアックな機能は PowerToys でサポートするという住み分けを行っていくのだろうと思う。
また，全くの余談になるのだけれど， PowerToys と言えば， PowerToys for Windows XP 含まれる "Power Calculator" が，なにげに便利だ。
http://www.microsoft.com/windowsxp/downloads/powertoys/xppow...
http://www.atmarkit.co.jp/fwin2k/win2ktips/160ptoys/ptoys006...
各種の数学関数をサポートしているほか，基数の変更や単位の変換，グラフのプロッティングなどもサポートしている多機能な関数電卓だ。少し複雑な数式の演算や，曲線の形状の確認などを行いたい場合に役立つことがある。
2004-08-18
自分は，仕事中に音楽を聴くことがある。集中を必要とされない作業をする場合や，調子が出にくい場合などに音楽を流すことが多い。また，周囲の雑音を遮断する目的で音楽を流す（ヘッドフォンで耳を塞ぐ）場合もある。
職場によっては仕事中の音楽が容認されないこともあるかもしれない。とりあえず自分の職場においては，仕事中の音楽が問題視されることは今までに一度も無かった。その辺りの判断は自己裁量に委ねられている。
以前から，仕事中に音楽を聴くという行為が生産性に対して与える影響に関して，しばしば考えることがあった。まず明らかな欠点として周囲とのコミュニケーションが行われにくくなるという問題があるのだけれど，これに関してはひとまず置いておきたい。論点は，仕事中の音楽が作業効率に対してどのような影響を与えるのだろうかという問題だ。
この問題に少し関連のある話題が Peopleware の中に登場する。当該の箇所において著者は，「音楽を流せば騒音をかき消すことができる」という言説に対する反論として，コーネル大学の研究者が 80 年代に行った実験の内容を引用している。その実験とは，「音楽を聴きながら派」と「静寂派」の２種類の学生を集め，それぞれ半数づつを無音室とオーディオ装置付室に入れて，ある仕様に沿った Fortran のプログラムを作成させるというものだった。
これは一見，音楽と生産性の間には関連が無いことを表しているように思える。しかしその一方で著者は，与えられた仕様から高速化の余地を見つけて実装することができた人々の多くは無音室側にいたという事実を提示している。その結果から著者は，右脳の働きとエンジニア的インスピレーションとの間に，何らかの関係があることを示唆している。
ちょっとトンデモ臭のする言説ではあるものの，それなりに筋の通った理屈ではあると思う。
右脳・左脳の話はさておくとして，自分は音楽を流すことによって集中力の低下を自覚することがある。自分が数分前に思いついたことを忘れてしまったり，複雑な設計をまとめることができなくなってしまったりする。また，音楽を聴きながら文章を書くのも苦手な行為だ。下書き程度ならばまったく問題無いのだけれど，推敲は無音に近い状態でなければ行うことができない。
音楽を好きで流しているならばまだ良いとして，周囲の雑音をかき消すために音楽を流しているのだとしたら，それは不幸な状況だ。音楽が作業効率に対して与える影響は，人や作業内容によって異なってくるものの，少なくとも何らかの影響を与えることには違いない。ゆえに，純粋に雑音を遮断して静寂を作り出すのが真っ当な手段であると言うことができる。 Peopleware において著者が主張しようとしているのは，まさにそのことだ。
2004-08-19
作業中の集中力を左右する重要な要素として，プライバシーの存在がある。人を雑音から隔絶し，不用意な割り込みを無くすことが，作業効率や士気を高く保つうえで非常に重要な要素であるということは， Peopleware の中でも繰り返し述べられている。
しかし，プライバシーと相反する要素としてコラボレーションの存在がある。個人のプライバシーが強化されればされるほど，メンバー間における直接のコミュニケーションは行われにくくなり，偶発的な相互作用も発生しにくくなってしまう。
知的労働を目的とするチームにとって，コラボレーションはプライバシーと同じぐらい重要な要素として考えることができる。コラボレーションによって各々が持つ技術や知識を補い合うことが，様々な障壁を乗り越えるための手段となり，直接のコミュニケーションを頻繁に行って互いのビジョンを共有し合うことが，チームの意思統一を図るための媒体となる。また，コラボレーションによってもたらされる学習効果にも注目することができる。
個人的な経験を言えば，プロジェクトの立ち上げ前後は最も強力なコラボレーションが必要とされる。これは，この時期においては何か生産的な作業を行う（手を動かす）よりも，様々な要素の方向性を決定すべく模索を行うことの方が重要であるためだ。ここでは，チーム全体の知的リソースを最大限に活かすことが重要視される。
その後は，プロジェクトが進行するに従って生産作業の方が増えていき，それに反比例してコラボレーションの必要性は下がっていく。プロジェクトに不確定要素がほぼ無くなり，コンテントの生産と不具合修正を行うのみという段階に入ると，今後は最も強力なプライバシーが必要とされるようになる。作業中の不用意な割り込みを防ぎ，できるだけ高度な集中力を保てるよう配慮することが，最終的な品質を向上させるための鍵となる。
結論として，プライバシーとコラボレーションの間のバランスは，プロジェクトの状況によって絶え間なく変化するものであると言うことができる。そして，そのバランスを適切に変化させることのできる環境こそが，理想のオフィス環境として求められるものであると思う。
例えば，プライバシーとコラボレーションのバランスに関して調査した次のようなケーススタディがある。
http://www.interiorworkplace.com/knowledge/privacy_balance.h...
ここに登場する Steelcase 社はオフィス設計の分野において有名な企業だ。
http://www.steelcase.co.jp/jp/
オフィス設計に関して様々な先進的なアイデアを打ち出しているほか，ケーススタディの類も充実しており，サイトを眺めているだけでも結構面白い。
http://www.steelcase.co.jp/jp/knowhow/understanding.asp
http://www.steelcase.co.jp/jp/knowhow/planning.asp
http://www.steelcase.com/servlet/ToolsInsightsServlet
特に面白かったのは， IBM と共同プロジェクトによって開発された未来的オフィス "Bluespace" の記事だ。
http://www.steelcase.co.jp/newsletter/no.1/j/general02.html
http://www.itmedia.co.jp/news/0206/17/cead_schonfeld.html
http://www.steelcase.com/servlet/ToolsInsightsServlet?ACTION...
個人的に興味を引かれたのは，シチュエーションに合わせて機能を変化させることができるという特徴だ。個人作業に適応させることもできれば，コラボレーションに適応させることもできる。プライバシーを強化することもできれば，開放性を強めることもできる。ライトの色によって状況を示すことができる（「邪魔しないでください」等）というのも面白いアイデアであると思う。
このような「未来的オフィス」はともかくとして，プライバシーの度合いを任意に変化させることができるようにするには，例えば可動式のついたてなどを利用するのが，最も手軽な解決法ではないかと思う。
http://www.steelcase.com/servlet/ProductServlet?ACTION=4&CAT...
http://www.steelcase.com/servlet/ProductServlet?ACTION=5&CAT...
また， Peopleware に登場する「赤いバンダナ」のアイデアも面白い。
この問題に対する解決法は，簡単なもの（赤いバンダナ）から高度なもの (Bluespace) まで様々にあるものの，要点となるのは，「プライバシー」と「コラボレーション」という相反する要素が存在するという認識だ。その理解に欠けている限り，どのような高価な解決法も無駄に終わってしまう可能性が残される。
2004-08-20
仕事の方が忙しくて気付くのに遅れてしまったのだけれど， MD5 の衝突が発見されたことが各所で話題になっている。
http://japan.cnet.com/news/sec/story/0,2000050480,20070525,0...
http://slashdot.jp/article.pl?sid=04/08/18/0257220
http://slashdot.org/article.pl?sid=04/08/17/0030243
話題の焦点となっているのは Crypto 2004 における Xiaoyun Wang 氏らの発表であるようだ。この件に関してはすずきひろのぶ氏の slashdot への投稿が参考になる。
http://www.iacr.org/conferences/crypto2004/
http://slashdot.jp/comments.pl?sid=203703&cid=607130
Xiaoyun Wang （王小云）氏は，中国は山東大学の副教授（日本で言うところの助教授？）だ。すずき氏によれば世界的には無名の研究者とのことであり，この辺りにはなかなか面白そうなドラマが隠されていそうな匂いがする。
http://www.prime.sdu.edu.cn/third/05wangxiaoyun.html
http://mathserver.sdu.edu.cn/html/professor/gehai/wangxiaoyu...
分散コンピューティングによる MD5 のクラックプロジェクトとして有名な MD5CRK は， Wang 氏らの論文が発表された直後にプロジェクトの終結を宣言している。アルゴリズム的に衝突を発見する手法が発見された以上，ブルートフォースに頼るこのプロジェクトの存在意義は失われるためだ。
最初に MD5 の衝突を発見した人物に１万ドルの賞金を与えるとした CertainKey 社のサイトには，まだ何の動きも現れていない。現時点の状況では Wang 氏らに賞金が渡されることはほぼ確実であるから，じきに何らかの発表がなされるはずだろうと思う。
http://www.certainkey.com/md5challenge/
話題となっている Wang 氏らの論文は以下のサイトから入手することができる。
http://eprint.iacr.org/2004/199/
今回の発見は，ハッシュが衝突するメッセージの組合せを求める手法の開発であって，任意のメッセージに対して衝突する別のメッセージを求める手法や，任意のハッシュを生成するメッセージを求める手法ではないようだ。
論文によれば， IBM の pSeries 690 サーバを利用して１時間程度で組合せを発見することが可能であるとされている。同サーバはハイスペックながらもそれほど特殊なハードウェアではないことから（少なくともスパコンではない），安物の PC クラスタを利用したとしても，恐らく１日もかからずに同様の処理を行うことが可能なのではないかと思う。
http://www-6.ibm.com/jp/servers/eserver/pseries/hardware/hig...
論文の中には，実際に衝突の発生するメッセージの組合せが載せられている。 Python を利用してこの二つのメッセージを実際に md5 に与えてみた。
結果は以下のようになる。
元となる二つのメッセージ（上の x1 と x2）は，非常に似通ったもののように見える。実際に比較してみると，たった６バイトの違いしか存在しない。
以前から信頼性に揺らぎの生じていた MD5 はともかくとして，代替として支持されていた SHA-1 に関してまで疑いが持たれ始めているというのは，重大な動きであると見ることができる。また MD5 に関しても「とどめ」が刺されたことによって，認識に大きな変化が生まれることは確実だ。何にしろ，この発見が情報セキュリティ分野において非常に重要な意味を持つ事件であることには間違いない。
2004-08-23
ある日，ふとしたきっかけから現行プロジェクトの総コード行数を計測してみたところ，これが予想以上の行数に達していることに気が付いた。このままのペースで増加が続けば，これまでに係わったプロジェクトの中でも最大の規模のコードベースに成長することは間違いないだろうと思う。
何故，このような勢いで行数が増え続けているのかは分からない。実のところ，実感もあまりない。ただ，コード群の中に自分の関知していない領域が増え続けているという感覚は以前から存在する。高まりつつあるリスクに気付きながらも，差し迫るスケジュールの前に何も行動を起こすことのできない状況がそこにある。
Jason Marshall 氏は，ソースコードの行数には指数関数的な性質が備わっていると説く。
http://jroller.com/comments/jdmarshall/Weblog/the_exponentia...
Marshall 氏がコード肥大化の要因のひとつとして指摘しているのは，逼迫した状況に対するパニック反応だ。期日に間に合わせるがために，問題を根底まで追究しないまま作業に着手し，似たようなコードの量産を行ってしまう。いわゆる「やっつけ仕事」の類だ。
コードの共通化を試みずに，安直に「コピペ」で解決してしまうことの問題点は，メンテナンスのコストを倍増させてしまうことにある。１０個の潜在的なバグを含むコードを複写すれば，単純にバグは２０個に増える。増加したバグを修正するには相応の時間が必要とされるうえ（バグの個数は簡単に増加させられるのに対して，バグの修正コストは単純に人月換算できないことに注意），バグによって全体的な制作効率が悪化する可能性もある（バグによって作業が停止させられるのはプログラマだけではない）。
逼迫した状況から引き起こされるパニックが，設計を劣化させる原因であるという指摘は面白い。自分は切迫感に追われやすい性分であることから，近々にこなさなければならない仕事の量が増えてくると目の前が見えなくなってしまい，「本当に必要であること」と「本当は必要でないこと」の区別が付かなくなってしまう傾向がある。その心理的な混乱が，種々の判断を曇らせてしまっているという自覚は，以前から存在する。
今から無理にでも片付けてしまおうとしている仕事は，仕様や設計を崩してまで優先的に片付けなければならないものなのか……あるいは，他人に依頼を行うことはできないのだろうか……本当に自分が処理すべき仕事なのだろうか……本当に自分が判断すべき事項なのだろうか……そのような判断が正しく行えなくなってしまったがばかりに，周囲に迷惑をかけてしまったり，最終的な製品の品質に悪影響を与えてしまうような結論を導き出してしまうことがあると感じる。
2004-08-24
少し前の話になるのだけれど，夏休みの間に Novalogic の最新作 "Joint Operations: Typhoon Rising" を購入して遊んでいた。今でも週末などに暇を見つけてはプレイしている。
http://www.4gamer.net/store/review/jointops/jointops.html
http://www.watch.impress.co.jp/game/docs/20040723/jointops.h...
4Gamer からダウンロードした体験版が思いのほか面白かったので，製品も買ってみたという次第だ。
http://www.4gamer.net/patch/demo/jo/jo.html
このゲームの内容を一言で表すなら，「Battlefield のエッセンスを取り入れた Delta Force」というのが適当かもしれない。大人数でガヤガヤと撃ち合うのが楽しいゲームだ。 100 人あまりのプレイヤーがフィールド上に入り乱れてドンパチやらかすのだから，賑やかなことこの上ない。
アクション性は BattleField よりもやや高めにまとめられている。連射系の銃器が充実していることや，備え付けの銃器に弾数制限が無いことなどが，シューティング色を強める方向へと働いている。一発毎のダメージ量も比較的大きめに設定されているため，慣れるまでは少し辛めのバランス設定であると感じられるかもしれない。何も考えずに前線へ突入すれば，あっと言う間に蜂の巣にされてしまう。
対専用のゲームルールとしては，前線に最も近い陣地を互いに取り合う AAS (Advance and Secure) や，特定の領域を一定時間確保することを目的とする TKOH (Team King of Hill) などが用意されている。どちらのルールも一箇所に火線が形成されるため，フィールドの広さや参加人数とは関係無しにプレイヤーが集中する傾向にある。また，これらの対戦ルールの仕様上，相手の裏をかくような戦略は成り立ち難いため，普通に正面から銃撃戦を展開するのが主な戦略となる。このことは，このゲームのシューティング色を一層強める方向へと働いていると感じる。
このゲームもやはり，草叢や木々の中に身を隠すことが戦闘上の重要なテクニックとなる。鬱蒼と茂る草叢の中に上手く身を隠せば，遠目にはプレイヤーの存在は殆ど分からなくなる。ただし，隠れている本人からも周囲は見え難くなるため，やたらと伏せれば良いというわけでもない。ともかく，このような「カモフラージュ」ネタは，最近になって様々なゲームで見かけられるようになったと思う。
2004-08-25
なんだかんだ言っておいて，結局未だに iPod には手をつけずにいる。その代わりに，件の iPAQ に 64MB の SD カードを挿して PDA 兼ポータブルオーディオデバイスとして利用している。 SD カードを利用するのはこれが初めてだったのだけれど，店頭で品揃えを調べる際に，意外なコストパフォーマンスの良さに驚かされた。今時の SD カードやコンパクトフラッシュなどは， 256MB のモデルでも１万円を切る価格で売られている。製品のバリエーションも充実しているし，いつの間にか廃れてしまったスマートメディアなどと比較すると非常に賑わっている市場であると感じられる。
http://www.amazon.co.jp/exec/obidos/tg/browse/-/3482011
http://www.amazon.co.jp/exec/obidos/tg/browse/-/3481991
個人的な印象として，フラッシュメモリメディアは耐久性に劣っているのではないかという先入観があったのだけれど，実はこれは全くの誤解で，フラッシュメモリメディアは非常に耐久性に優れたメディアであるということが度々言われている。例えば，ガジェット系ニュースサイト Engadget に投稿されていたニュース記事 "Blast Destroys Camera, Flash Card Survives" では，爆破解体工事の爆風に吹き飛ばされながらも無事に生還したコンパクトフラッシュの話が取り上げられている。
http://www.engadget.com/entry/3868866098708521/
http://news.designtechnica.com/article5140.html
新聞カメラマンの Don Franzier 氏は，ミシシッピ川のとある橋の爆破解体を撮影しようと，橋脚から 80m ほどの位置に３台のカメラを設置した。ところが，爆風が予想よりも強力なものであったため，これらのカメラはその爆風の中に飲み込まれてしまった。爆風にさらされたカメラは粉々に砕けてしまったものの，カメラの中に格納されていた SanDisk 社の 256MB コンパクトフラッシュは，衝撃に耐えて生き残ることができた。回収されたコンパクトフラッシュの中には，カメラ自身が破壊される寸前の画像や，砕け散るカメラを捉えた迫力の映像などが収められている。このアクシデントによって Frazier 氏が失った装備は１００万円を下らないものの，カメラが破壊される瞬間の「いい絵」が撮れたことと，コンパクトフラッシュが生還したという奇跡だけで満足だと述べている。
フラッシュメモリメディアの耐久性の高さに関しては， BBC News の記事 "Digital memories survive extremes" が面白い。
http://news.bbc.co.uk/2/hi/technology/3939333.stm
この記事によれば， Digital Camera Shopper 誌がメジャーな５種類のフラッシュメモリメディアに関して耐久実験を行ってみたところ，その全てのメディアが実験を無事にクリアすることができたとされている。その実験とは ― 「コーラを垂らす」 「洗濯機で洗う」 「コーヒーに浸す」 「スケボーで踏みつける」 「オモチャの車で轢く」 「６歳児に壊させる」 ― の６種類だ。ただし，最後に行われた２つの追加実験「スレッジハンマーで砕く」と「釘で木に打ち付ける」だけは，ほとんどのメディアが耐えることができなかったとされている。
実験の結果を総括して，同誌の編集員である Geoff Harris 氏は次のように述べている。
今回の事故は，まさにこの総括を反映していると言うことができる。
余談なのだけれど，同じような耐久テストの話題として，次の記事が連想させられる。
http://www.thisislondon.com/lifeandstyle/articles/11183864
iPod, 携帯電話，デジカメ，ノートＰＣ， GameBoy 等の携帯製品を耐久実験にかけてみたところ， GameBoy だけが最後まで生き残ることができたという記事だ。ただ，その耐久実験の内容が壮絶で，泥沼に突っ込んだり，オフロードカーに積み込んで悪路を走り回ったり，挙句の果てにはクレー射撃の的にまでしてしまっている。しかし，クレー射撃を耐えることができたのも，実は単に GameBoy が小さすぎて散弾が当たらなかっただけだというところが脱力感に溢れている。
2004-08-26
業界にしばらく身を置いていると，様々な噂話や伝説の類を耳にすることがある。仕事を苦に自殺したプログラマーがいるらしいとか，恐ろしい量の仕事を楽々とこなす超天才クリエイターがどこかにいるらしいとか，某作品で有名な某氏は年収Ｘ千万円を超えるらしいとか……そうした噂話の中に幾分の真実はあれど，ほとんどは伝言ゲームの中で尾ひれを付けられた架空の話であり，飲みの席以外では役に立つことの無い与太話の類であると考えることができる。
そうした話の中でも特に一般性を持つものは，いわゆる「都市伝説」として世間に流布されることがある。出所の怪しげな情報でも，話題としての面白味さえあれば，人々はそれを真実として受け取り，周囲にその話を伝えようとする。それが更に，事実として納得することのできる「もっともらしさ」を備えたものであれば，一種の常識として認知されてしまうことまである。
こうした都市伝説の類を集めた有名なサイトに snopes.com - Urban Legends Reference Pages がある。
このサイトでは，各種の都市伝説を収集しているほか，その真贋の判定を行っている。事実を証明できるだけの情報源が存在すれば「真実」とされ，逆に反証を可能とする情報源が存在すれば「虚偽」とされる。記事の総数は既に二千を超えており，ざっと流して読むだけでも非常に読み応えのあるサイトとなっている。いわゆる雑学の類ではあるけれど，目を通してみると意外な事実と出くわすこともあり非常に面白い。
自分が最近読んだ中で特に面白かったのは，「サブリミナル効果」が実はペテンであったという話だ。
http://www.snopes.com/business/hidden/popcorn.asp
この件に関しては CSICOP の以下の記事も参考になる。
http://www.csicop.org/si/9204/subliminal-persuasion.html
「サブリミナル効果（広告）」という用語は，マーケット調査の専門家である James Vicary 氏が 1957 年に行った実験によって世間に広められた。映画館で流す映像の中に瞬間的なメッセージを織り込むことによって，売店のポップコーンやコーラの売り上げが増加したという有名な実験だ。しかしこの実験に用いられた手法と得られた効果には疑わしい点があることや，再度実験を行ってみても同様の効果が得られないことが，他の研究家によって後に指摘されている。
そしてついには， 1962 年に行われた Advertising Ages 誌によるインタビューの中で， Vicary 氏はこの「ポップコーンとコーラ」の実験が捏造であったことを告白している。氏はこの実験が，彼の失敗しつつあったビジネスに対する世間の関心を喚起するために捏造されたものであり，また，特許を申請するために必要であった最低限の調査以外は一切行われていないと述べている。
この捏造疑惑を巡る話の中でも特に面白いのは，カナダ放送協会が 1958 年に行った実験の話だ。同協会はサブリミナル効果の実験を行うために，日曜夜の人気番組 "Close-up" の中で 352 回もの「電話をしよう」 ("Phone Now") というメッセージを織り込んで放映を行った。しかしその結果として，電話の使用量が増えることはまったく無かった。その後，視聴者対してメッセージ内容の予想を募集してみたところ，送られてきた 500 通あまりの返答の中に正解を当てたものは一通も存在しなかった。そして驚くべきことに，その半数余りが，番組を見ている間に空腹と喉の渇きを覚えたと訴えていた。これは，文字を利用したサブリミナル・メッセージの手法には実際には効果が無く，視聴者は単に Vicary 氏の有名な実験を連想したに過ぎなかったという事実を如実に表す結果となっている。
こうした経緯もあり，現在ではサブリミナル・メッセージの手法は実際の効果を伴わないばかりか，広告手法としては逆効果になりうる存在として認識されている。しかしこの手法に関しては，単に効果の有無の問題だけではなく，メディアとしてのモラルの問題を含んでいるため，効果が無さそうだからといって野放しにするわけにはいかないというのが実情のようだ。国や地域によってはサブリミナル・メッセージの手法を禁じる法令などが敷かれることもあるほか，各種のレーティング機構によって自主規制の対象とされることも多くなっている。
http://en.wikipedia.org/wiki/Subliminal_messages
2004-08-27
もうひとつ，個人的に面白かった話として，「レミングの集団自殺はディズニーの捏造だった」という話がある。
http://www.snopes.com/disney/films/lemmings.htm
http://www.hatena.ne.jp/1085989972
自分がレミングの集団自殺の話を初めて目にしたのは，ゲーム "Lemmings" を紹介した雑誌記事の中のことであったと思う。子供向けの学習マンガの類で同じような記述を見た記憶もある。
http://en.wikipedia.org/wiki/Lemmings_%28computer_game%29
ディズニーが制作した動物・自然系のドキュメンタリー映画 "White Wilderness" において，レミングは海に飛び込んで自殺する習性を持つ珍しい動物として描かれている。しかし実際には，レミングにそのような習性は存在しない。同映画に登場するレミングはイヌイット族の子供から撮影のために購入されたものであり，撮影地であるカナダのアルバータにレミングは生息していないし，飛び込むための海も実は存在しない。映画の中に描かれているレミングの集団行動はすべて捏造であり，実は十数匹以上のレミングが同時に画面に現れることは一度もないと指摘されている。そして，実際にはありもしない自殺行動を見せるために，崖の上に運ばれた哀れなレミング達は，次々に川の中に飛び込まされたということだ。
レミングの実際の生態に関しては Wikipedia に詳しい記述がある。
http://en.wikipedia.org/wiki/Lemming
この記述によれば，短めの冬と長めの夏という好条件が揃ったときに，レミングの生息数は爆発的に増加する。そして生息地の密度が高まってくると，強い力を持つレミングは，食料不足が発生する前に弱いレミングや若いレミングを生息地から追い出そうとする。追い出されたレミングは新たな生息地を求めてランダムな方向に移動を開始するものの，生息地にみられる地形的な特徴から，その道筋は比較的狭い経路に制限されてしまう傾向にある。そのようにして自然発生した「集団移住行動」の中から，個体同士の衝突や集団性のパニックなどが生じることはあるものの，ディズニーが映画の中で描写したような「崖から集団で飛び降りる」という行動を自ら起こすことは無いとされている。
最後にもう１つ，興味を誘われたのは，「鍋の中のカエル」の話が，実は「伝説」（虚偽）であるという話だ。
http://www.snopes.com/critters/wild/frogboil.htm
「鍋の中のカエル」の話は，緩やかな変化によって感覚を麻痺させられた状態を表現するために用いられることがある。鍋の中にいるカエルは，周囲の温度を緩やかに上げていけばその変化に気付くことがなく，最後には煮えたカエルが出来上がってしまうという話だ。しかし，オクラホマ大学で動物学の研究を行っている Victor Hutchison 名誉教授によれば，実際に同じことを行ってみれば「普通にカエルは逃げ出す」と指摘している。
http://www.uga.edu/srel/ecoview11-18-02.htm
では何故，このような話がもののたとえとして用いられるようになったのだろうか。その由来に関しては，上の資料では何も触れられていない。恐らくは「犬猿の仲」のたとえと同じように，由来や事実関係が定かでなくても，表現として用いられるうちに文化に固着したという例なのだろうと思う。
http://www.google.co.jp/search?lr=lang_ja&q=%E7%8A%AC%E7%8C%...
2004-08-30
先日のこと，ガジェット系ブログサイト "near near future" において "22 POP" と呼ばれる作品が紹介されていた。
http://www.we-make-money-not-art.com/archives/002535.php
http://people.interaction-ivrea.it/a.rao/22pop_1_insp.html
この "22 POP" は，イタリアは Interaction Design Institute Ivrea に籍を置く学生 Aparna Rao 氏と Mathias Dahlstrom 氏によって制作された「タイプライター型メール端末」だ。見た目はごく普通のタイプライターでありながらも，内部には氏らが独自に開発したハードウェアが内蔵されている。これを通常のタイプライターの要領で操作すれば，その文章を電子メールとして任意のアドレスに送信することができるようになっている。
この作品は，単なるアンティーク趣味のために作成されたものではない。 PC の操作が不得手な Rao 氏の母のために設計されたものだ。このようなタイプライターの形態をとることによって，電子メールを書くことは実はタイプライターで手紙を書くことと同じぐらい簡単なことなのだということを伝えようとしている。
http://people.interaction-ivrea.it/a.rao/22pop_2_diagrams.ht...
この作品のタイプライター部分は，イタリアの伝統的なタイプライターメーカーであるオリベッティ社の "Lettera 22" を基にしている。
http://www.museum.vic.gov.au/design/exhibition/lettera.asp
たた残念なことに，この "22 POP" は，現時点ではまだメールの送信を行うのみで，受信を行うことができない。当初のコンセプトを具現するにあたっては，メールの受信機能を追加することは避けられない仕事であると Rao 氏はまとめている。
Rao 氏は，人や物の間に存在する「見えざる関係」を観察することをテーマとして，様々な作品を作り出している。その「見えざる関係」に新たなインタラクションの形態を与えることによって，目に見える形へと変化させようという試みだ。例えば，氏の別の作品 "The Uncle Phone" は，機器を操作するのに何でも人の手を借りようとする氏の叔父に対してのメッセージを含んだ作品となっている。
http://people.interaction-ivrea.it/a.rao/phone_1_insp.html
この全長 2m の電話機は，２人の人間が居なければ操作することができない。元々１人で操作するものであるはずの電話機をこのような形に変え，わざわざ２人で操作しなければならないようにするのは滑稽だ。しかし Rao 氏は，その滑稽さによって，電話をかけるのに人の手を借りようとする行為のおかしさを伝えようとしている。
氏が籍を置く学校 Interaction Design Institute Ivrea は，テレコムイタリア社とオリベッティ社の共同出資によって設立されたインタラクション・デザイン専門の大学院だ。同ウェブページのギャラリーのコーナーには，生徒の手による様々な作品が展示されており，眺めているだけでも面白い。
http://www.interaction-ivrea.it/en/gallery/whenlightningstri...
以前から時折，現状におけるデバイスとユーザーとの間の接点の小ささに疑問を感じることがある。何でも新しくすれば良いというものでもないのだけれど，もう少し人々のライフスタイルに合わせた歩み寄りを行うことで，楽しさにたどり着くまでの障壁を低くすることができるのではないかと考えている。
2004-08-31
いつの間にか，普通のミドルレンジクラスのＰＣにもギガバイト単位の RAM が搭載されるような世の中になってしまった。 RAM をギガバイトで数えるようになるのはいつのことだろうかと予想していた頃が懐かしい。今となっては， IA-32 の持つ 4GB の仮想アドレス空間もやや心許ないものと感じられるようになってきた。物理アドレス空間の方は 64GB まで利用可能であるものの，この制限が深刻な問題となるのももはや時間の問題だろうと思う。それに，この 64GB という物理アドレス空間にしても， Pentium Pro の時代に PAE (Physical Address Extension) を導入することによって得られたものであり（それまでは 4GB が限界だった），短期的な延命措置に過ぎないというのが実情であると思う。
http://www.microsoft.com/whdc/system/platform/server/PAE/def...
アプリケーションの種類によっては，仮想アドレス空間の 4GB の壁も，既に窮屈なものになっているだろうと思う。これらの問題を根本的に解決するには，やはり 64-bit アーキテクチャへの移行を実現させなければならない。汎用ポインタと 32-bit int 値の間に互換性の無い時代がやってくるわけだ。
http://msdn.microsoft.com/library/default.asp?url=/library/e...
先日， Raymond Chen 氏が自身のブログにおいて， Windows の /3GB スイッチに関する話題を繰り広げていた。
http://weblogs.asp.net/oldnewthing/archive/2004/08/22/218527...
この /3GB スイッチとは， Windows における仮想アドレス空間の配分を変化させるスイッチだ。通常はユーザ領域とカーネル領域がそれぞれ 2GB づつに配分されているのが， /3GB スイッチを適用することによって，ユーザ領域を 3GB にまで広げることができる（カーネル領域は 1GB に縮小される）。
http://www.dotfoward.jp/OS/W2K/Memory/4GT/4GT.html
Chen 氏は，この /3GB スイッチにまつわる世間の勘違いや，物理アドレス空間と仮想アドレス空間の違いを見落としていることから生じる誤解などに関して，誤りの指摘と事実の提示を行っている。サーバ環境等では日常的に用いられているオプションであることから，誤解なども生じやすくなっているようだ。
面白いのは，この /3GB スイッチを適用しても，全てのアプリケーションに対して 3GB の仮想アドレス空間が明け渡されるわけではないということだ。実際には，該当するアプリケーションの /LARGEADDRESSAWARE オプションを有効にしたときに，初めて後半の 1GB のメモリ空間が利用されるようになる。
このように特殊な仕様が用意されているのは，整数値オーバーフローによって発生するバグを回避するためだ。整数値オーバーフローは，特に意識していなければ容易に盲点となってしまう「落とし穴」のひとつであり，それによって引き起こされる不具合を回避するためのフェイルセーフとしてこのオプションが用意されている。ちゃんと対策が行われている場合のみこのオプションを有効にして欲しいと念を押しているわけだ。
整数値オーバーフローが問題となるようなケースに関しては， Chen 氏の挙げている例題が分かりやすい。例えば，バイナリソートを行うために，２つのポインタ (low, high) の中間を指すポインタ (mid) を求めるコードを書くとする。恐らく，最も単純なのは以下のようなコードであるはずなのだけれど，実は，このコードには整数値オーバーフローによるバグが隠されている。
ここで，対象となるメモリブロックが 2GB 以降のアドレス空間に存在した場合， low + high の値は 2^32 を超えてオーバーフローを起こしてしまい，最終的に mid の指し示す位置はとんでもないアドレスになってしまう。
この問題を解決するには，以下のような記述を行わなくてはならない。
また同様に，以下のコードにも整数値オーバーフローによるバグが潜んでいる。今度は，任意のポインタ p が特定のバッファ領域に含まれるかどうかを判定する関数だ。
ここで，ポインタの差 (p - buffer) の結果は ptrdiff_t 型として算出されるのだけれど， ANSI C では ptrdiff_t は符号付き整数型 (int) として定義されているため，差分が 2^31 を超えていた場合に負の値となってしまう。この場合は，単純に以下のように記述するのが正解だ。
自分は，このような整数値オーバーフローの問題に関して，今まで全く考えたことが無かった。コンシューマゲーム機の分野においては，当分の間は関係の無い話題であろうけども，意外な所にバグの可能性が潜んでいるという事実は知っておいても損は無いだろうと思う。