この文書の所在
Junkieta.netFragment → Notes, 2009-02

2009年02月の雑記

2009-02-03, 二月

いよいよ二月なのか。二月だなんて、どうやったって納得はできない。他人だったらきっととっくにあきれてるのに、いや他人じゃなくても呆れてるのに、こればっかりは慣れない。二月、本当の二月、慣れるわけがない。遊んで、話して、歩いて、イライラして、怒って、絶望して、諦めて。でもそれは無くしたんじゃなくて、積み上げてきたもののはずだった。だから二月のことなんて長いこと忘れてたのに。…そうだ、忘れてたんだ、忘れていたよ、僕はずっと、忘れていたんだよ。

なのに、二月かよ。ここで二月だって言うのかよ。

二月以前に、僕には見えなくなっているものが多すぎるのかな。僕は実際のところアレだから、二月はしょうがないと、どっかでは思ってた。だけど、だけどさ、まだ二月は決まったわけじゃない。だってほら、たしかにそうだけど、ほんとにそうなんだけど、でもそれは"予感"みたいなものだ。別に無くたってかまわないはずのものだ。そうだろ? 二月はもう確実にそこにあるように思うかもしれないけど、でも、二月はまだ二月じゃない。そして、もしかしたら、いや、きっと、二月なんて所詮そんなもんなんだって言える、言えるはずなんだよ。

でも、二月は言える言えないって話じゃすまないのもわかってる。正直に言えば、二月自体のことは想定できないわけじゃない。ただね、二月の後が、想定できないんだ。なんでこうなっちゃったのかって、思うこともある。仮に二月は実際にあるんだと認めたとしても、決して二月だけを問題にしてはいられないはずなんだ。頭では、そう、頭ではそう思っているんだ。おそらく、周り中の誰よりも、僕自身が、確信を持って、この結論を理解している。今まさに理解が進んでいる。二月を超えていく日が、たぶんその先にある。

だっていうのに。なんで二月なの。なんで、なんでもう二月なの。

二月の後も前も変わらないかもしれない。なんにも、なんにも変わらないかもしれない。それで本当に、本当にこれを認めることを考えただけでも立っていられなくなるんだけれど、僕はもうとっくの昔に二月に飛び込んでいたということがはっきりするのかもしれない。僕は二月を前にして、変わることも変わらないことも見ることができない。ミタナクイと思いすぎて脳味噌がちぎれて鼻からコボレ出そうなことなんて伝わらないだろうけど、ミタクナイ。怖いよ、眠るどころの話じゃないよ。もういっそのこと二月は運命だと、本当にそうなんだと、信じられたら、…二月を知らずにいた僕も、ありえたのかもしれない。でもそれは結局、僕ではない、誰かの話でしかないんだ。

受け入れることも、見てみぬふりをすることもできない、でもけっして手は届かないし、拒絶には意味すらない。二月は、やっぱり納得できない。

「鬱だ氏のう」で済む話なんてないよ。済ませるつもりもない。どこかの誰かに対してとかじゃなく。済まない話からは逃げたくない。

2009-02-05, 「うみねこ」考察その2を公開開始

体裁ばかり調整しても仕方がないので、右代宮家を解剖する / 「うみねこのなく頃に」考察を公開した。まだ書き足したいことは色々あるが、どうもどうでもいい部分の調整に時間ばかりとられてしまうので踏み切る。「右代宮家」という単位を中心にして思考を整理していく形にした。やってない人間には意味不明な文章で恐縮だけど。

2009-02-06

体調も気分も不良。色々調べてるだけで時間が過ぎてしまった。晩飯はインスタントラーメン。生野菜が腐っちゃう。でも今日は食わせる相手もいないし、重い体を引きずって調理する気になれない。死にたいは 生きたいだは今でも真実だと思ってるけど。けど。くど。くど。

雑記と銘打っておきながら、本当に単なる雑記を書いたときは、ひどく自分のことがイヤになる。この自己嫌悪は何。

2009-02-09

有機野菜の余りモノをいただいたので、まるごと鍋にして友人を呼び、食べた。出汁が好評だったけど、聞くとあまりにひどい鍋をちょっと前に食べたばかりで、それと比較されたゆえだった様子。まあ理由がどんなものであれ、ウマイと言ってくれる相手がいるのはいいもんだ。一応、僕の調理は食える代物を生み出すらしい。鍋一つでこういう感覚を得られることとか、食ってくれる友人がいるってのは、きっと大事なことだ。

2009-02-10, ウェブに文書は全然足りてない

最近は「サイドバー」から大幅にでしゃばってくる「ブログパーツ」というヤツをよくみる。本文を半分くらい隠してることもしばしば。そんなに文章を読ませたくないのかと。なんでもかんでもウェブサービスが連結可能で、どのドメインのリソースも呼び出し可能で、それがそんなおもしろいのか。いや、やってみること自体は楽しいのかもしれんけど、個々のURIの示すリソースがおそろしく首尾一貫しないものになってる。スタイルシートを切ると十数行の本文に対してナビゲーションやらパーツやらが何十行も続くってのはもう、HTMLがValidかどうかとかいう以前の問題。文書として破綻してる。

一方、学校とか研究所とか役場とか、情報を公開してくんないと困るようなとこが旧態以前とした固定幅デザイン + でこぼこHTMLのまんまだったりする。オープンにすべき情報の一番肝心なとこが(テキスト選択不可な)PDFバージョンしかないとかさ。そういや最近、突然金かけてリニューアルとか言い出して、Flash依存になっただけのしょーもない大学サイトもあったな。情報アクセスの重要性をよくわかってるはずの機関が、閲覧には不便なだけのアニメーション広告にばかり金を放り込んでばかりの現状は異常。そこはスマートに、提供すべき情報とプレゼンのための表現を切り分けてほしいところ。

「ブログ」やらなにやらが遊びの対象だったりコミュニケーションツールだったり、それはそれでありだろう。でも、ウェブはもっと「活字メディア」として真剣に検討されていい。ビジネスにしにくいってのは儲け話にとっては欠点かもしれないが、ビジネス以外にも目的を持つ機関にとっては手を出さない理由がない。なにせ非営利個人サイトが存在できるという事実がここにあるように、公開にはコストがほとんどかからないんだから。語ろうとしない「知」なんて欺瞞だ。匿名性だの信憑性だのに文句つけて、媒体として未熟だとかどうとか遠巻きにウェブをながめてるだけじゃなくて、そんなルサンチマンの渦より何倍も価値のある情報が生み出せるってとこをこの媒体でも見せてくれよ。それが伴わないんじゃ、多くの媒体が「実学」気取りの言説に支配されるのは当然ってことになっちゃうよ。

ウェブで有名になる研究者って「ブログ」でぽいぽい記事を放り込む人ばかりな印象だが、大学はじめ研究会・研究所がウェブでももっと「出版」する機関としてしっかり位置づいていけば、状況はかなり変わると思う。今は各大学の教員紹介ページとかほとんどお話にならない情報量でも、公開可能な紀要を(X)HTMLでまとめる程度で全然変わる。なにせたとえ全文読めても、印刷前提のPDFと多様なフォーマットに変換可能な(X)HTMLじゃ閲覧の容易さに雲泥の差がある。その上さらに発展して、参考文献情報をRDFで参照できるようになったりした日には、情報の再利用性も跳ね上がる。はたして、研究機関はウェブというメディアでも価値の高いリソースを生み出し続けるという実績と信用を獲得した…なんてシナリオを描くとこはないのかな。

2009-02-12, りふぁら

HM Weblogのリファラ、http://192.168.1.3/fragment/、おそらくというか確実に犯人は僕です。自宅PC以外アク禁設定のローカル鯖でリンク含む記事を書いてた時にぽちっとした結果だと思う。今までにも色々なサイトに飛ばしてる気がする。紛らわしいもの見て混乱したならごめんなさい。

2009-02-14, ローカルネットのリファラカットスクリプト

先日のリファラの話から。

もしローカルネットからのリファラを飛ばしたくない場合は、RefControl :: Firefox Add-onsとかAdaptive Referer Remover :: Firefox Add-onsあたりが御勧め。後者Adaptive Referer Removerはdeny from式のブラックリスト方式。一部のサイトからのリファラだけをブロックし、他は普通に送信したいといふ場合に有效。僕は今こっちを使ってゐます。

最初は導入しようかと思ったものの、アドオンはできるかぎり削る方針を今はとってるゆえ、見送ろうかと。しかし辿ってもアクセスできないリファラをあちこちに送りまくるのもなんだかなので、ユーザースクリプトで対処。まあ僕は内部実装よくわかってないから、ひょっとするとアドオンの方が軽いというばかばかしいコードを書いてる可能性もあるんだけれども。

userChrome.jsによるリファラ消去

リファラがローカルホストと一致したら消す。でもhttp-on-modify-requestを常時監視することになっちゃうので気に入らない。

Components.classes["@mozilla.org/observer-service;1"].getService(Components.interfaces.nsIObserverService).addObserver({
  observe: function(subject, topic, data) {
    var http = subject.QueryInterface(Components.interfaces.nsIHttpChannel);
    if(http.referrer && "localhost" == http.referrer.host)
      http.setRequestHeader("Referer", "", false);
  }
}, "http-on-modify-request", false);
Greasemonkeyによるリファラ消去

dataスキームで新規ドキュメントを生成してmetarefreshを使う。強引。href属性の書き換えはステータスバーが気持ち悪くなるからしてない。

// ==UserScript==
// @name           kill referer
// @include        http://localhost/
// @include        http://localhost/*
// ==/UserScript==

(function(refCtrl) {
  function __listener(e) { if(e.target.nodeName == "A" && refCtrl[e.type](e)) e.preventDefault(); }
  window.addEventListener("keydown", __listener, false);
  window.addEventListener("click", __listener, false);
})({
  domainRe: RegExp("^" + location.protocol + "//" + location.hostname + "/"),
  jump: function(ref, useblank) {
    if(this.domainRe.test(ref)) return false;
    ref = 'data:text/html, <meta http-equiv="refresh" content="0;url=' + ref + '">';
    window.open(ref, useblank ? "_blank" : "_self");
    return true;
  },
  keydown: function(e) {
    var ref = e.target.href;
    return ref && (e.keyCode == 32 || e.keyCode == 13) && this.jump(ref, e.ctrlKey);
  },
  click: function(e) {
    var n = e.target, ref = n.href;
    return e.button != 2 && this.jump(ref, e.ctrlKey || e.button == 1);
  }
});
2009-02-15, リンク切れ

はてなブックマークでCafe in the Junkyard内の新着ブックマークを確認してみたら数件ついていた。URLをもたせるためだけにniftyにお金払いつつ注意書き載せておいたんだけど、やっぱり駄目か。サイト閉鎖後もfaviconとかサムネールが残ってるのを見ると切なくなる。想像していたことではあったが、僕はクールなURLは変わらないに呪われていた。見知らぬ誰かにデッドリンクという失望を味あわせることになるという想像は、頭にキリキリキリキリ穴を開けていくような痛みになった。プロバイダ解約を決めてからドメインを取得するまで、この自傷にも似た痛みはずっと続いた。我ながら、異常だ。

またHM weblogからリファレンスを頂いていた。

さういふときは「Cafe in the Junkyardの新着ブックマーク」ではなく「Cafe in the Junkyardの新着エントリー」(すごくまぎらはしい名前…)のはうが一覽しやすいと思ふ。もちろん意圖的にそっち(「新着ブックマーク」)を選んでゐるといふ事であるなら特に云ふこともないし拘りませんが。

「新着ブックマーク」は、どちらかといふと「コメントのエゴサーチ用」だと僕は理解してゐる。さういふマイナな用途が主だから、だから<http://b.hatena.ne.jp/>から「新着ブックマーク」へのリンクは用意されてゐないのではないか、とか。

意圖的というわけではないです。ユーザー別ブックマークページからリンクされていた「新着ブックマーク」のURLを書き換えて確認してみただけなので。もし今後機会があった時は、「新着エントリ」の方にリンクすることにします。


僕は「はてな」のサービスに対して、なにをどうすればどうなるのかが予測できないという恐怖心がある。「junkieta」アカウントを取得した際、「設定」の項目をなにかいじっているうちにいつの間にか「はてなダイアリー」のドメインにURLが生成されていた。それに気付いて「ダイアリー」を利用するつもりはないから「公開設定」を「プライベート」にしてみると、今度は「プライベートで使用されています」というだけのページが「公開」されてしまった。しょうがないから今は言い訳だけのページをでっちあげてある。たぶん他にも色々わかってない使い方をしてるんだろうなぁと思いつつも、うかつに操作しないほうがいい、と縮こまっている。

2009-02-15, Wikipediaキモチワルイ

日本語版Wikipediaの児童・生徒の方々へという記事について。

ウィキペディアについて、世の中では「だれでも自由に書ける百科事典」と説明されることが多いようです。しかしこれはまちがっています。ウィキペディアは、「基本方針に同意していただけるひとだけが、記事を編集したり新しく作ったりできる百科事典」です。基本方針に同意していないひとが書くことは認められていません。そして内容についても、自由に、思いのままにではなく、一定以上の質が求められます。良質な記事を作ることは、大人でも大変なことですから、まして子どもだったら、それ以上の努力をしなければならないでしょう。

ウィキペディアに参加するのならば、「百科事典を作るために、わたしたちはここに集まっているのだ」ということを、絶対に忘れないように活動してください。

若年者向けに脅し文句を掲載すれば、意味不明な編集が減っていく気がするのかな。ばかばかしい。

Wikipediaは百科事典として信頼性を得るために(主語不明ではあるものの)努力をしているんだろうよ。でも記事の出来栄えを向上するために特定年齢層を排除したいとかぬかすのなら、最初から専門家だけ集めればいい。そうでなくても、アカウントの取得を単純な機械処理で済ますんじゃなくて、どういう記事をどう編集したいのかをプレゼンさせて通らないと書けないとか、それくらいのチェックをすればいい。ただただ良質な記事が欲しいんだったらね。どれくらいの人が協力する気になれるか知らんけど、つまらないこと書く人間が減った方がいいならそうすべき。

でも「ゲーム」だろ、Wikipediaってのは。少なくともいわゆる「仕事」じゃない(「仕事」でやってるヤツは「荒らし」に近い)。間違ってたら指摘しましょう、みんなで「正確な」知識を集めましょう、というルールで運営される、レベルの高い落書きを作ろうという遊び。誰でも書き足せる落書きは、出来が良かろうが悪かろうが消されるときは消されるもの。ただしいい記事を書くプレイヤーは尊敬され、つまらない記事を書いたプレイヤーは笑われる、それが楽しい。それでいいじゃねぇか。ルールブレーキング(編集合戦やら事実無根の記述やら)だって発生するだろうけど、それを真面目な顔して参加するか否か考えろなんて言い出したら、もう「ゲーム」の空気としては破綻してるわな。「さあ、気持ちよく書きましょう」とか言っても白けるばかり。

善意でとれば、基本的な前提(ルール)を共有してから遊ぼうよ、って話なんだろうけどさ。「ゲーム」の参加者間で調整するんじゃなく、児童・生徒の方々とかいうレッテルを貼った相手に「わたしたち立派なことをやってるんです」「勉強してきてね!」とかぬかすのって、絶対わかりあえない感性。それなら最初から機械的に排除する努力くらいしなければ、相手に失礼。つーか、 うぃきぺでぃあ って えらく なっちゃったんだね。

大人という項目の記述がひたすらに浅い現状だと、良質な記事を作ることは、大人でも大変というのが実にもっともなのだとよくわかる。書いた人、リンクしたらどうですか。

2009-02-16, CSSコードのマークアップとスタイル
2008-12-10, はてなアンテナのユーザースタイル - Junkieta Fragment

一見CSSのコードに見えるものが、實は定義リストで、波括弧やコンマやコロンはCSSによる生成内容。Geckoでは選擇できない。仕方がないのでOperaを起動してコピペした。機械處理されるコード、一文字一文字が重要な内容を、さういふ風に「CSS化」するのはどうかと思ふ。

コピペに不都合があるという利便性の問題と、波括弧やコンマやコロン一文字一文字が重要な内容であり、それらがCSSによる自動生成に依存すべきでない内容であるという指摘には頷いてしまったので、内容生成に頼っていた部分を修正しました&お手数かけました。

ただ一見CSSのコードに見えるものが実は定義リストなのは、「CSSのコードを定義リストとして意味づけするのは妥当」と判断した結果です。コードに本文で言及するのだから、それが単なる整形済みテキストであるよりも、より個々のセレクタやプロパティの対応関係が意味として明確になる定義リストを使いたいと思ったわけです。

もちろんコードを公開する以上、よければ試してもらえばいいと思うし、そのためにコピペも容易な方がいい。そして完結したコードの提示をCSSの内容生成にまかせるべきではないというのはまったくその通りですね。なので、DL要素を利用した記述自体は崩さず、ブラケットの類は自分で記入する形に変更。これでコピペ時に空白類文字が増減することはあっても、コード自体は壊れない状態でコピーできるはず。

CSSのコードを定義リストとして意味づけするのは妥当だとは思わないなあ。それ言ったらPythonの関数なんかも定義リストにできちゃうし、preformatted textのほうが適切なような。単なる空白類文字もコードの構成要素だと思うし、コードの提示としてはよろしくない。ECMA-262邦訳みたいに構文定義を表現するのにはいいだろうけど。

あれ、確かCSSの構文解釈においてはセレクタや宣言の周囲から空白類文字が増えても減っても問題なかったと思ったけど。まあそれはそれとして、単なる空白類文字もコードの構成要素と捉えるならpreformatted textのほうが適切なのはわかるし、なにより書く側としてもその方が。それにDL式CSSマークアップは@importとかの単一行の指定は難しいし、汎用性は高くない。だから今回の修正は公開コードとして利用可能にした、と述べた方が的確だったかも。

あと、Pythonの方の事情は全然わからないのでコメントできないけど、ここでの「妥当」という表現はセレクタを被定義語句、宣言を定義内容とすることに対する僕の認識。意図としては、グループ化した一連のスタイル指定が定義リストにしてあると文章にとっての意味が豊かになるんじゃないかってところ。だから例のマークアップは、コード「それ自体」の提示よりも「コードの内容と本文との関係」を優先している。曖昧な区分けではあるけど、コード自体を提示する内容とするならPRE、CSSについてあれこれ書くことがメインになるならDLという具合。文書から見た時のコードと本文の主従関係の問題になると思う。

そういえば、以前に「ソースコードをどうマークアップするか」という件についての一連の議論を読んだ覚えがあるけど、DL要素については誰か検討してたかどうだったか。よく思い出せない。

2009-02-16, マークアップを前提にものを書くのはやめる

いままでJunkieta Fragment向けに文章を書くときは、HTMLの構文を強調表示してくれるテキストエディタを利用してきた。公開まではおおよそ次のような流れ。

  1. ベタなテキストを打つ
  2. マークアップする
  3. Firefoxを起動、文章を確認しつつHtml Validatorによる文法のチェック
  4. 文章とマークアップの推敲

どうも最後の推敲部分が著しく効率性を欠いたものになっているんじゃないかと思い立った。なにせ推敲の段階でマークアップと文章の執筆が平行する形になってしまうから、文の消したり足したりに対していちいちHTMLの構造も合わせて考え直す形になる。しかも、そのたびにウェブブラウザでリロードしているわけだ。バカすぎる。

いやそれだけじゃなく、構文強調のテキストエディタを使うようになってから、どうもHTML・CSSと文章とを結びつけるのがさも当然という感覚ができてしまっている気がする。でも「強調したい部分はemstrong」とか、文章にとってはそんなのどうでもいい話なわけで。文章の吟味はあくまで文章だけの段階で行い、どういうマークアップが適切かについては文章が「推敲も含めて完成」してから考えるべきだろう。

よってこれからは、原文の記述はHTMLだのCSSだの関係ないエディタを用いることにする。文章の推敲作業にマークアップ作業を紛れ込ませるのはやめて、まず文章は文章としてHTML文書から独立したものを作る。それを公開するという段階になってはじめて、マークアップを開始する。この順序を守るようにしていく。

考えてみれば、今まではあまりにもおかしかった。そもそもHTML化は公開の一方法でしかない。たとえば書いている文章がリソースの要約で、それが大量になってしまったら単独のRSSにしてしまうということだってありうる。リソースの性質に対して適切なフォーマットを選択できるのが大事なのであって、最初からフォーマットにあわせた文章を書こうとしたってしょうがない。二度手間が増えていくだけだ。

書きたい文章を書き、もしもHTMLとして公開するのに適していたらマークアップする。こういう変更をいちいちエディタの使い分けとか儀式めいたことをしないと定着させられない気がするあたり、ぼやけた頭だと苦笑いするしかない。なんにせよ、文章を書くということとHTML文書を作るということの間に、僕はもっと明確な境界線を引くべきだと思った。

2009-02-19, 全国消費生活相談センター

財団法人 全国消費生活相談センターを名乗るところから、「消費料確認通知書」と題されたハガキが届いた。

この度、契約会社が貴方に対して行っている料金の未払いもしくは契約不履行に対して当該会社が管轄裁判所に訴状申請した事を通知致します。

訴訟内容、取り下げ最終期日につきましては担当職員にて受け賜りますが、当センターは原告側からの最終通告、また御本人様と訴訟内容の正当性を確認する機関であり、当センターが貴方に対して訴訟を起こしているのではありませんので、予めご了承下さい。

このまま連絡無き場合、管轄裁判所から裁判の日程を決定する呼出状送達後に出廷となります。尚も放置しておくと、相手方の言い分どおりの判決が出て、執行官立会いのもと、あなたの給料や財産の差し押さえ等をされてしまう事がありますので、ご注意ください。

※ 最近、悪質な架空請求業者や個人情報を悪用し民事裁判制度を利用する手口もみられます。

万が一、見に覚えがない場合早急にご連絡下さい。

個人情報保護法に基づき御本人様からのご連絡お願い致します。

まともな機関なら裁判所への出廷云々をインクジェット紙はがきで出すのは妙だし、契約会社とやらの情報がまったくないのも変。消費料確認通知書で検索したところ、「特定非営利活動法人全国消費生活保全協会」という名称を用いた架空請求についてのアナウンスが。例示されているPDFと先に引用したハガキの現物を見比べると、「特定非営利活動法人 全国消費生活保全協会」が「財団法人 全国消費生活相談センター」と置き換えられている以外にほとんど差異がない。文字装飾や、文字揃えといったパターンまで同一。おそらく同一業者が別名を名乗って同様の手口を繰り返しているんだろう。

当然ハガキに記された連絡先は無視するとして、こういうものが届いたら被害の有無に関わらず、最寄の消費者センターに連絡をしたほうがいいんだろうか。一応、ハガキ自体は捨てずにおいて、後で確認してみようかな。

2009-02-21, ゲームにおける履歴の扱い

僕は漫画や書籍なら途中まで読んだ状態で中断したストーリーでもだいたいは覚えておけるし、たとえ記憶があやふやでも読んでいくうちに思い出せることのほうが多い。だがゲームソフトになるとそれがかなりあやしい。最後までやりきった、一応エンディングまで到達したゲームの場合、その筋道はほとんど覚えているのだが、途中で中断して半年とか一年経ってしまったゲームは、セーブデータをロードしたところから何をすればいいかほとんどわからない状態になってしまう。対戦格闘やパズルなら感覚の鈍りを実感するくらいなのでスルーできる問題だけど、シミュレーションなどでは話の展開についていけなかったり、ロールプレイングゲームになると致命的に情報が欠落していて、話を進展させるための手順がまったく浮かばなかったりすることもしばしば。アドベンチャーやサウンドノベルといった一部ジャンルの作品では履歴参照がほぼ標準的なコマンドとして実装されているが、シーンの再読をサポートしないソフトの方が圧倒的に多い。

コンピュータゲームには、一度見た事柄に対する標準的なアクセス方法が定まっていない。ハードウェアではなく、個別の作品たるソフトウェア側にその制御をゆだねているのだから当然といえば当然だが、これは「表現の媒体」として考えるとかなり異質。小説や漫画は簡単に読み返すことができるし、映画はビデオ・DVDなら巻き戻し・早送りができ、そうでなくとも映画館で二時間使えばいい。だがゲームは? ケースによっては、何十時間という再プレイを強いられることになったり、技術や運の必要なシーンであれば二度と遭遇できないこともある。僕は修士論文執筆時、この問題によっていくつかのゲームソフトの参照を諦めたりもしている。

履歴を辿るという行為は研究目的でなくとも、たとえば読解という行為においても重要なものだ。ある一つの絵とか文とかがなぜそこに登場しなければならなかったか、それを疑問に思うとき、一番理解を助けるのは該当箇所以前の記述だ。この時書籍であれば、逆順にページをめくるという指の動きだけで履歴を参照できることがほぼ物理的に保障されている。しかしゲームではそれがバラバラだったり、そもそも存在していなかったりする。こうした進行の不可逆性は、読解を相当困難なものにする。「だからこそ一回一回のプレイが面白い」という側面があるので、一概に批判すべき点ではないと思うものの、ゲームソフトに対して研究だとか言及だとか、あるいは「読み直し」していく上で大きなデメリットとなるのは否めない。

仮に履歴参照の困難さを打破しようとするなら、ハードウェアへのアプローチ、つまりソフトの個別性に左右されないセーブ機能が不可欠。ソフトの一本一本が提供する独自設計のセーブ機能では、ユーザー側の自由な履歴探索を保障することにはならない。ただセーブ機能はゲームのシステムや演出においてそれなりに重要な位置を占めるから、ハード側でその可能性を摘み取ってしまうのはどうか、とも思う。一番適した落としどころは、海賊版の温床としてでなく図書館等をベースに公共的な利用を視野に入れたエミュレータを開発していくこと、あたりか。

2009-02-27, 老女と幼女

うちのご近所では当番制でゴミ捨て場の掃除を行っている。昔からこの地区に住んでいる老人方は、普段の付き合いはそれほどないのに葬式とかの行事の際は律儀に手伝う習慣があるようで、掃除当番もそうした地域社会の名残として残っているようだ。近所に10数年ほど前建てられた、馬鹿でかい市営住宅の住民に関しては参加度がアヤシイけど、もともとの住民同士は今でもそういうつながりを保っている様子。その掃除当番だということで、祖母が出かけていった。

しばらくして、「どなたかいませんか」という小さい女の子の声が聞こえてきた。最初は友だちの家にでも声をかけているのかと思っていたが、だんだん声が近くなってくる。部屋の窓を開けてみると、小学生の女子数名がそろってこちらを見ていた。どうしたのかと尋ねると、「おばあさんが動けなくなってます」とのこと。え? おばあさんって、うちの? 

聞くと、どうもうちの祖母がゴミ捨て場に出かけて掃除を済ませたはいいのだけれど、いざ掃除を終えたら腰が痛くて動けなくなってしまったらしい。杖を所望しているらしいが僕にはどれがどれだかわからないので、自宅にある杖を何本か適当に持って、見知らぬ小学生に先導されながら歩きだす。すると確かにうちの祖母が、ゴミ捨て場の塀に寄りかかったままになっていた。腰がものすごく曲がっているので、ダルマが斜めに傾いたような姿だった。

女の子たちにお礼を言いつつ、祖母に杖を手渡して事情を尋ねる。普段なら家を離れるときは杖を持ち歩いているので、多少腰の痛みがあっても戻るのだけれど、このときは箒と塵取りで両手がふさがっていたため、忘れていたとか。それで近くをローラースケートで走り去ろうとした小学生に声をかけ、僕を呼ぶように頼んだそうな。出かけるつもりだったから若干危なかったな。まあ、お疲れ様。

帰り道にも、知らせてくれた女の子たちはついてきた。というか、ローラースケートで僕と祖母の周りをぐるぐる回っていた。見ていると目が回るけど、面白い女の子たちだ。車の気配がしたとき僕が止めるよりも先に祖母を歩道の内側に誘導したちっちゃい子、「車来るよー」と声をかけてくれている仕切りたがりっぽいけど面倒見のいい子、ずっとニコニコしながらグルグルその場で回っている妙な子。なんだかいいメンバーに見える。

途中、「車来るよー」の女の子が祖母に対して「スケートなら早いし疲れないよ!」と、ススメの言葉を放った。あのな、うちの祖母をターボばあちゃんにしたいのか君は。ナイスアイディアだが、転んだら文字通り再起不能だよそれ。一方、祖母は祖母で、話の文脈まったくおかまいなしに「うちの壁はチョコレート色だから覚えやすいだろう」などと妙なことを言い始めている。ばあちゃん、あれはベージュという色だ。世の中ホワイトチョコばっかりじゃないんだよ。チョコレート色って言われたら、たぶん小学生諸氏はとんでもない家を想像すると思うよ。

案の定、家に着くと彼女らは壁の色を確認し、「えー違うよー」と連呼する(まあ、そうだよねぇ)。しかし祖母もむきになって「チョコだろうに」とか連呼している(いや、だけどねぇ)。日も暮れかけている中で、壁がチョコなのかチョコがホワイトなのかと、わけのわからない会話を続ける彼女らをしばらく見守って、部屋に戻った。

関連リソース

前後の文書
webmaster@junkieta.net