_ 土曜日はロッテ祭だった (10:51)

ロッテ祭というのは、武蔵浦和ローカルなロッテの工場主催の祭。毎年夏にやるんだけど、いつやるのか事前に大々的に知らせたりしないので、毎年気がつくとやっている（た）といった感じになる。ヒーローショーとアイスの激安箱売りとお菓子のただ配り（人数限定）があるのが（子供にとって）魅力。

今年は事前にいつやるか知ることができたんで、準備万端最初から行くことができた。けど、面倒くさいんでお菓子のために並ぶのはパス。アイスは3箱買った。1箱500円均一で売ってるんで冷凍庫に入るだけ買ってしまう。っつーか、このために冷凍庫を買いたくなるくらい。アイスは並ばなくても買えるみたいなんで、来年はもっとのんびり買いに行こう。

_ 絢爛舞踏祭 特典 ブックレット付きはじめた (10:58)

久しぶりのゲームだ。PS2のメモリカードを子供がどこかにやってしまったんで、新しいメモリカードを買ってきてスタート。ガンパレードマーチの進化形だけど、あれのエンターテインメント性を削って、その分シミュレーション性を増した感じだ。とっつきの悪さはあれ以上。それでもマシンパワーと容量が増えている分、そういう作りでもそれなりに良くできている。

ただ、あまり真面目に世界設定とかを把握する気がない人間にとっては、情報をきちんと解釈して楽しむのはかなり難しそう。ストーリー仕立ての部分は読解する気になるけど、世界情勢図とかを都市ごとの政治状況とかを理解する気になれねーもん。

でもまあだらだら戦闘員モードでやっていてもそこそこ面白いし、やりこめば面白くなる気配は見えているから、できるだけ隙間を見つけてやろう。でもやる時間って睡眠時間を削る以外はないんだよなー。しかもこれからしばらくは削る睡眠時間もそれほど確保できない気がするんだが。しかも、子供に適当にいじらせていたPS2の内部時計が腐った時間になっていて、それがセーブ時間とかに反映されてしまうのがうざいんで、もう一度初めからやり直したい気分。

_ ひとまずいろんな動詞に「全米が」をつけていこう (15:37)

全米が泣いた。全米が笑った。全米が走った。全米が飛んだ。全米が飲んだ。全米が食べた。全米が困った。全米が喜んだ。全米が……。

そうしているうちに、目をつぶるとまぶたの裏に擬人化された「全米」の姿が浮かんでくるようになる。なんかアメコミ調だ。

_ 今日のスポクラ (11:17)

土日月と3日空けると、かなりブランクが体に来るな。なんか何をやるのも体が重い。でもまあ基本ペースは火水木金とやって、土日月と休むパターンになるはずだから、これで体を慣らさないと。ひとまず月曜日はいつもよりもさらに軽めくらいの気持ちでやろう。

_ やり直し (13:01)

やっぱりシステム時間が腐った状態で続けるのが気持ち悪いんで、6時間くらいプレイしたデータを消して、最初からやり直し。でも平日は1日30分くらいずつしかできない予感。で、来週は夏休みだしなー。休み中は車に積んで車の中でもやったるか。でもあの読みにくいフォントは、車のテレビじゃほとんど読めねーだろうなー。

_ 高負荷中です (13:09)

なんか先月末から急激に1470.netへのアクセス数が増え始めており（昨日は先月平均の倍くらいあった）、ときどき高負荷で調子が悪くなっているときがあるようです。DB周りとかはそれなりに大丈夫にしておいたのに、なぜかhttpdが応答しなくなる（プロセスがリミットになったとかじゃないのに）ことがある模様（多分今日昼の12時あたりにそうなっていたっぽい）。いまいち理由が分かっていないのですが、ひとまずApacheのパラメータをいじってみてます。MySQLに振っていたメモリを削って、Apacheのプロセス数をめいっぱいあげておくか。

_ set_error_handlerと@エラー抑止との関係 (22:01)

マニュアルを良く読めば書いてあったのだけど、気づかずしばらくはまっていたので、覚え書き。

set_error_handlerを使って独自のエラーハンドリングをする場合、@でエラー抑止している部分からも指定したエラーハンドラが呼ばれる。その場合、errer_reporting()でカレントのエラーレベルを取得し、それが0だった場合は、@でエラー抑止している部分からの呼び出しだということで、returnしてしまえばいい。

error_reporting(E_ALL);
set_error_handler('myhandler');
echo @$undefined; // このエラーは無視して欲しい
echo $undefined;

function myhandler($errno, $errstr, $errfile, $errline)
{
  if (error_reporting() == 0) {return;} // ←ここがポイント
  echo "$errno, $errstr, $errfile, $errline\n";
  die;
}

なんて感じ。

_ 今日のスポクラ (11:25)

いつもよりも5分早めに行って、その分バイクを20分にのばしてきた。これが一番いいパターンかもしれない。

そういやなんか左の肩がおかしい。左肩を回すと関節がばきばき鳴るし、肩の後ろ側から前方向に力を入れようとすると、関節が後ろ側から前側に切り替わるときに痛みが走る。スポクラに通い始めた最初からおかしかったんだけど、いまだに同じ調子ってことは、やっぱり根本的におかしいのかな。どこかずれてる？　整体に行ったら直るかな？

_ 膨大な情報を整理せずに保存するためのタグ (15:17)

あるものを見たときに、人はそれについて雑多な考えを思い浮かべる。その雑多な考えは、文章化するには曖昧で、また情報量が多すぎて、どれだけ言葉を尽くしても、正確に記述することはできない。

そこで、その雑多な考えを、そこから連想したいくつかの文字列に代表させて表現してみる。それがタグだ。

タグは雑多な考えとイコールではない。タグは、その対象となるものと合わせて見直したときに、そのタグを記録したときに思い浮かんでいた雑多な考えを復元するための、手がかりである。

どれだけ言葉を尽くしても表現できないような膨大な情報を、いくつかの文字列という手がかりに代表させることによって、その情報量のままに保存する試み。それがタグだ。

という捉え方も面白いと思う。これはタグを付ける人とそれを解釈する人が同一人物である場合の話だけど、複数人でタグを共有する仕組みの場合にこのような考え方を適用してみても面白そう（続けて書こうと思ったけど、発散してまとめきれなかった）。

_ ナビのモニター故障 (09:09)

うちのカーナビ（Pioneer DR-2500）のインダッシュモニターが故障した。開け閉めするときに、前後移動はちゃんと動くんだけど、モニター部の角度変更がなめらかに動かず（途中でギアが抜けたように戻ってしまう）、結果として自動開閉が途中で終わってしまう。オクサンが車用品店で診てもらったら、メーカー送りの部品交換で3万円くらいかかると言われたそうな。

ただ、動きがおかしい部分をよく見てみたら、単に右手前のモニター部を開閉させる歯車が摩耗して、歯車同士のかみ合わせが甘くなっているだけに見える。その部品を交換できればいいけど、一般的なサイズかどうかよく分からないし、しかもぱっと見その部品だけを簡単にはずせるようにはできていない（というか、その周辺にネジとかが見あたらないんで、全体をばらしてからその部品だけを入れ替える必要がありそうだ）。

で、ひとまず応急処置的に、歯車の山の補強剤みたいなものがあればいいなーと思ったんだけど、そういうのって売ってないんだろうか？　なめちゃったネジ山用の補強剤とかで代用できないかな。あるいは木工用ボンドとか接着剤系で山をちょっとだけ盛ってやるとか。

_ 今日のスポクラは休み (12:49)

ふらふらと二度寝してしまい行く時間がなくなったので一回休み。これで明日休むと悪い癖がつくから、明日は必ず行こう。

_ iTunes Music Store Japanオープン (13:16)

やっぱりあらかじめオープン予定日を公表しておくと、最後にトラブルが出たときなんかにぐだぐだになって、ぐだぐだのままにオープンするかそれとも延期するか、みたいな展開になりがちだから、オープン日は噂レベルで流しつつも公表はせず、実際にオープンしてから公表するのが正解だよなー。

で、使ってみたけど良くできてるなー。値段ももうちょい安ければ全部こっちで買うって感じだけど、現状だと物理媒体が欲しい場合はCDを買おうと思う程度に棲み分けができそうな感じ。

この値段（1曲150円〜）って、各国で売られているCDの値段との比率で決めているのかな。単にデジタルデータはいくらで売買されるのが妥当か、で決めるのではなく、既存のCD屋にトドメを刺さない程度に市場を奪う（移行する）のに妥当な値段、って値付けな気がする。

ただ、良くできてはいるけど、曲数少なすぎ。こういうのって手放しちゃった旧譜とか、いわゆるロングテール的なものが欲しいときに使いたいのに、なんかトップページに載っているような売れ筋の曲しかまだ登録されていないんじゃ？　単に登録作業がはかどっていないってだけだといいけど、いつまで経ってもこんな感じ（新譜しか登録されていかない）だったら嫌だなー。

_ サーバー死亡中 (08:02)

メインの新しい方のサーバーにディスク障害発生。現在状況確認中。データ自体は別サーバーにもあるんで生きているけど、新サーバーの方はドライブ交換になりそうな予感。ただサーバー屋が夏休み中なんで、応答が遅そうだ……。

_ 暫定サーバーに移動 (09:37)

主要な機能をもう一個のサーバーで稼働させました。が、DNS情報の伝搬まで時間がかかりそう。重そうな機能（主に検索系）をカットしているんで、これでなんとかメインサーバーの復旧までもたせられないかなー。

_ サーバー屋の夏休みはまだだった (09:48)

うまくいけば今日中に復旧するかなー。まだ連絡はつかないけど。でもサーバーが復旧（というかディスク交換）しても、DBの復旧（というかネットワークコピー）にうんざりするくらい時間が必要そうだなー。

_ バックアップデータを最新にしておきました (11:16)

MM/Memoのメモバックアップ用（RSS）データを、最新の状態に更新しておきました。現在稼働中のサーバーが見える方は、念のため手元にダウンロードしておいた方がいいと思います。現在1470.net関連のDBはバックアップなしで動作しているんで、現在稼働中のサーバーが死んだらデータが失われてしまいます。

_ くそー (11:21)

こんなんで今日もスポクラにいけなかった。

なんて文脈依存の記述は、blog形式で前後のエントリーが見えないシステムだと書けないんだよね。blog形式でも強制的に前後のエントリーの要約とか、前後数件分のタイトルを表示させたりすれば、それなりに文脈が見えるようになるかな。

_ hostsで指定する方法 (12:53)

だいぶDNS情報も行き渡ったみたいですが、まだ接続できない場合は、hostsファイルに、

202.181.96.63       1470.net

なんて書いておくと、暫定サーバーの方に接続できるようになります。緊急回避的な対処としてご利用ください。

_ jsコードをバックアップしてねー (13:07)

適当に埋めて動くようにしてみたけど、こんなんだったかなー。実は結構バックアップ漏れがあったりして。結構直接サーバーのファイルをいじっている部分もあったからなー。commit漏れがあったかもしれない。

_ やっぱりディスクが死んでいた (17:51)

ディスク交換＆OS再インストールを依頼した。3営業日以内でハードウェア的には復活するらしいけど、中身も復活させるのには時間がかかりそうだなー。どうせなら、これを機にシステム設計からやり直しちゃおう。なんて全部作り直したりしたくなるのは負け犬のやることだ！　でもblogmapなんてセカンドシステムどころかフォースシステムくらいゼロから作り直しているけどなー。

_ 復帰？ (09:05)

何度やっても起動しなかったサーバーが、なぜか正常起動したという連絡が来て（理由不明）、実際にアクセスしてみたら、特に問題なく動いているっぽかったんで、ひとまずディスク交換等もなく復旧作業中。

でもさすがに一度死にかけたディスクは信用できないんで、データはすべてセカンダリーディスク（ディスク2台構成なのよ）に移動して、そっちで動作するように変更。で、DNSを再び従来のサーバーに振っておいたんだけど、そろそろDNS情報が回り始めたかな。MRTGのloadaverageグラフをながめていると、だいぶ負荷は移動してきているみたいだけど。

_ 来週あたりには何とかしたいです（「安西先生、バスケがしたいです」のように←あまり関係ない） (17:36)

いろいろ面倒くさいことになってるんですが、現在いる場所のネットワーク環境が貧弱、かつ、その他いろいろ派生した問題がありすぎて、復旧作業が進みません。来週あたりには何とかしたいと思いますが、それまではだましだまし使っておいてください。

_ Re: 米国著作権法とsb : highbiscus -北国tv (18:07)

テンプレート技術とテンプレート仕様とテンプレートデータとコンテンツ（エントリー）データの区別をつけてから出直してきなさい。

• テンプレート技術はblogツール、Webアプリケーションに限らず、プログラミングで非常に一般的なテクニック。領収書の宛名を書く部分は「$NAME$様」としておいて、実際にコンテンツが決まった時に「highbiscus様」に差し替える、という技術。
• テンプレート仕様は、テンプレート変数（名）とコンテンツの対応付け。上で言うところの「$NAME$」は「宛名」である、というような決まり*1。
• テンプレートデータは、テンプレート仕様に基づいて作成されたデザインデータ。「宛名: $NAME$様」みたいなデータ。
• コンテンツデータは、テンプレートにはめ込まれるコンテンツの内容。「$customer = 'highbiscus';」とか。

sbがJUGEMと互換性をもっているのは、テンプレート仕様。ユーザーインターフェースなどの外見的な特徴を表現しているのは、テンプレートデータの方。テンプレートデータによってユーザーインターフェースが同じになったとしても、それはテンプレートデータの著作権の問題であって、それを読み込むツールの問題ではない。sbがtDiaryやMTのデータをインポートできるというのは、コンテンツデータのこと。sbとsb2で互換性がないというのも同じ。これは今回の件とは関係ない。

テンプレート技術、テンプレート仕様、テンプレートデータ、コンテンツデータの関係を簡単な式で表現すると、以下のようになる。

テンプレートデータ＋コンテンツデータ＝ブラウザに表示される画面

テンプレート技術とテンプレート仕様は、上記の式で言うところの「＋」の部分になる。テンプレートデータとコンテンツデータを結合する処理を行うために利用される技術と仕様。

テンプレート展開の実装方法としては、

• 正規表現を使ってテンプレート変数を置換
• DOMツリーに展開して該当のオブジェクトのinnerTextに代入
• いったんネイティブプログラムコードに変換してからeval

など、いろいろな書き方がある。というのが表現の違いの話。

JUGEMはソースが公開されていないので、sbはJUGEMの著作権に触れることなく、互換性のある実装を行っている。もし偶然JUGEMとsbのテンプレート展開の処理が似たようなコードで記述されていたとしても、sbの実装はJUGEMのソースを元にした（由来した）ものではないので、著作権的には問題ない。というのが著作権における由来性の例外事項（同じ表現でも由来していなければ著作権には触れない）の意味。

ところで結局、テンプレート仕様（タグ）の互換性以外には問題がない、ということでいいのかな？

_ 経過と状況 (23:33)

ざっとした経過と現在の状況を書いておく。

• メインのサーバーのプライマリディスクが死んで起動しなくなった
• 予備（DB＆裏タスクメイン）サーバーにWebアプリ側も移動して暫定復活
• サーバーのディスク交換を依頼。セカンダリーディスクもダメなら丸ごと交換するよう付記
• メインのサーバーが復活したとの連絡。プライマリー、セカンダリー共にふつうにアクセスできた。
• メインのサーバーのセカンダリディスクにすべてのアプリケーションデータを移動して通常復活（のつもりだった）。そのまま旅行に出かける。車でさいたまから北九州まで夜を徹して1000km一気に移動。その後ぐったり。
• 数日後、ディスク交換完了の連絡（まだその依頼が生きていると思っていなかった）。しかし長期旅行先でネット環境がなく、連絡に気づかないままに半日以上放置。
• 連絡に気づき、あわてて素のFedora Core 3にセットアップされたサーバーにログインしようとするが、連絡されたアカウントではログインできない。結局rootのパスワードとログイン用アカウントのパスワードが逆に通知されているのが原因だった。
• ログインしてみたら、問題なさそうだったセカンダリーディスクまで交換されていて愕然とする。DBデータとかも全部別サーバーからコピーし直しかよ。セカンダリーディスクにコピーした段階で油断して、別サーバーへのバックアップを完全にしていなかったことに思い当たり、作業の手間にうんざりする。
• 素の状態にセットアップされたサーバーに、京ポンPC接続経由で最低限のWeb環境をインストール。京ポンが128k接続非対応端末であることにそのとき気づく。遅い。
• 1470.netのサーバーはいろいろなツールを組み合わせて動かしているんで、関連ツールのインストールが結構面倒。しかも今回のFC3は従来といろいろ変わっているらしく、RH系のTIPSを使っても素直にインストールされてくれないものが多い。
• さらにちょうどそのタイミングでChasenの配布サーバーが落ちていたらしく（あるいはAirEdge経由での経路が死んでいただけかもしれない）、Chasen関連のデータもダウンロードできない。別サーバーにあったアーカイブを使ってインストールしようとしてもmakeでこける（これはgccの互換性の問題らしかったけど、ネット環境が遅すぎて探せなかった）
• あまりにネットワークが遅くて作業がはかどらないんで、ある程度主要な機能が動き始めたところで、外出先での作業をあきらめる。
• 金曜日の夕方に再び車で北九州からさいたままで1000km移動。今回は途中で力尽きて滋賀のSA（ホテル）で一泊。名古屋と都内で渋滞にはまり、家に帰り着いたときにはぐったり。
• 日曜日の朝早めに目が覚めたんで、いろいろ残っていたセットアップを行う。さらにDBサーバーのプライマリーとレプリケーションの関係を変更したり。DBデータが3.5Gくらいあるんでネットワーク越しの移行作業はそれなりに時間がかかる。3時間ほどサーバーを止めて作業完了。
• その他気がついたところをなおしながら現在に至る。ひとまずだいたいの機能は動かしたはずだけど、まだおかしいところがあるかもしれない。
• あとどうも今回のFC3は、思ったように動かないところが多すぎる。前回FC3を素からセットアップしたときには、FC2までと大して変わっていなかったのに。今回のセットアップ（作業をした人？）に問題があったのか、それともFC3の標準状態が変化したのか、なんなんだろう？　selinuxは外してあるんだけど。
• というわけで表向きの機能はだいたい復活しているけど、裏側はまだかなりぐちゃぐちゃ。かなり根本的なところから手をかける必要がありそうだ。

_ Re: はい、いしなおさんの負け。 : highbiscus -北国tv (12:35)

結局JUGEMとsbの著作権の問題については、「JUGEM独自タグ一覧」にあるようなテンプレート変数名とそれが意味するコンテンツの内容の対応付け、という仕様に関しての問題であるってことでいいんですね。見た目がなんとなく似ているから合わせ技一本、とかいう言いがかりレベルの話は本論ではないんですよね。

確かに、{blog_name}は「ブログの名前」に置換される、みたいな変数名とコンテンツの対応仕様は、JUGEM独自の創造物ではあるでしょう。それが、著作権法によって守られるべき著作物であるという考え方もゼロでなくはありません。

highbiscusさんは上記のようなテンプレート仕様というものは、判例によって*1著作権で守られないという見解が一般的なデータフォーマット仕様の領域ではなく、「独占的な権利を与えられるべき著作物（思想又は感情を創作的に表現したものであつて、文芸、学術、美術又は音楽の範囲に属するもの、もしくは、電子計算機を機能させて一の結果を得ることができるようにこれに対する指令を組み合わせたものとして表現したもの）」であると確信しており、それについて簡単な許諾を得た上で作成されたsbは、JUGEMの著作権を侵していると考えているわけですね。

私の負けですか、それは良かったですね。highbiscusさんの主張を支持する人がほとんどいないようならば、highbiscusさんがそう主張しても全然問題ありません。

ちなみに

highbiscusさんのサイボウズ裁判の解釈（画面表示の設計に関する判例が、プログラムの（データ仕様等を含めた）設計一般に適用される）について、私はそれを認めていませんよ。

なんで

テンプレートデータをインポート（変換）して使うツールはOKで、直接使うツールはダメと切り分けているんだろう？　事前に解釈するか利用時に解釈するか（処理の実行タイミング）の違いだけなのに。インポート型ツールだって、元のツールのテンプレート仕様をそのまま利用していることには変わりないのになー。

そういや

実装という言葉の意味もよくわかっていないっぽいなー。「テンプレート仕様はツールの実装だ」ってわけわかんねー。

最大の問題点はここか

テンプレート使用　＝　JUGEMの独自タグを中心にした、スキン切り替え型ツールの実装

「使用」は「仕様」の誤字だとして、「仕様は実装である」なんてバカな文章は、「仕様」と「実装」という言葉の意味をきちんと理解していれば、絶対に書くはずがないよな（仕様が決まっていないのにコードを書かなきゃいけない状況を自虐的に言うのならともかく）。っつーか、自分でJUGEMテンプレート互換のツールを設計（仕様を作成）して、実装してみれば、その区別が明確になるから、やってみるといい。正規表現が使える言語なら（テンプレート互換部分だけなら）、1日もあれば書けるだろう。

_ highbiscusさん以外向けに、私の解釈の全体像を解説 (18:33)

highbiscusさんとのやりとりだと、私がどういう解釈を主張しているのか全体像がわかりにくいだろうから、ここで基本的な主張をまとめておく（highbiscusさんと、解釈をすりあわせるための文章ではない）。

著作権法が「プログラムの著作物」として認めているのは、「電子計算機を機能させて一の結果を得ることができるようにこれに対する指令を組み合わせたものとして表現したもの」つまりはソースコード（＝表現）。

ただし、プログラムの実行時の画面表現などが「思想又は感情を創作的に表現したもの」という要件を満たしていれば、それは「美術」や「音楽」表現の著作物として著作権を持つ。

表現以外を模倣することは著作権法違反ではない。仕様（決めごと）は表現ではなくアイディア。仕様を構成する名前定義（テンプレート変数名）などは表現と言えるが、それが著作物として認められるには「思想又は感情を創作的に表現したもの」である（＝著作物性がある）と認められる必要がある。

「変数にその内容に応じた名前を付ける」という表現が「思想又は感情を創作的に表現したもの」と認められる可能性は非常に低いと考えるので、私は仕様を構成する表現は、一般的に著作権による保護の対象外であると考える（もちろんその表現がとても創作的だったら、著作物性を認めるが）。

仕様は規則と読み替えたら、非プログラマにもわかりやすいかも

仕様ってのは、結局のところ規則の集合なんで。

「{BLOG_NAME}はブログの名前を表す」みたいな規則は、その内容自体は単なるアイディアであって表現ではないので、著作権法で守られる対象ではない。アイディアを独占したければ特許権等を取得する必要がある。

ただし「{BLOG_NAME}はブログの名前を表す」という文章自体は表現なので、それが「思想又は感情を創作的に表現したもの」と認められれば、その著作権を認められる。

文章表現の著作権は認められやすいけど、名前（ここでいう{BLOG_NAME}）とかにはふつう著作権は認められないので、名前を独占したければ、商標権とかを取得する必要がある。

あと、アイディアの表現（仕様書とか）は著作権を持つけれども、それはあくまでも文章の著作権であって、アイディアの内容の著作権ではない。仕様書は著作権で守ることができるけど、仕様を著作権で守ることは難しい。

ちなみに権利が実際にあろうがなかろうが、当事者ならば主張するだけならばできる。無断リンク禁止議論とかと一緒だね。

_ 今日のスポクラ (13:05)

一週間以上間をあけてしまったなー。というわけで、今日から復帰。マシンで今まで肩を中心に（ピッチング用）やっていたんだけど、腕関係もちょっとだけ増やしてみた。バイクは軽めに20分コース。

_ で、地震 (13:05)

で、いったん家に戻ってから会社に行こうとしたら地震があった。震度4で1分くらい横揺れが続いていた。実家の方は震度5弱か。まあ地震慣れしているから大丈夫だと思うけど、後で電話してみるか。

_ モヒカンの血とウォッチャーの血 (14:49)

俺の中ではどちらが濃いのだろう。ウォッチャーの血が騒いでしまい、余計なことを書きたくなってしまう。釣り上げた獲物は、師匠以来の大物だった。

_ はてなの投げ銭関連の話って (16:14)

全然追っていないんだけど、やっぱり投げ銭ってシステムはいまいちだよなー。人と人が直接的に小銭をやりとりするってのは、どうも気色が悪い。っつーか、いい大人が小銭のやりとりに気を回さなければならない状態ってのは、なんかあほらしい（コストパフォーマンスが悪い）よね。

投げ銭ってのは人に対してではなく、コンテンツに対して行う方がスマートだと思う。で、コンテンツに対して行われた投げ銭は、そのまま作者にポイントとして渡されるのではなく、コンテンツに対する評価＋はてなシステムで管理する投げ銭貯金箱に収まる。で、いったんシステムでプールした投げ銭を、何らかの形でコンテンツ作者に還元する、みたいな方がよくないかな。

単にコンテンツ評価の割合で分配してもいいし、ポイント受け取りがいやな人にはサービスとかで還元したり、あるいは希望者分をまとめて何らかの義捐金とかに回してもいいし。

あと投げ銭を投げる方も、いちいちnポイント投げ銭するとか決めるのではなく、「今月は500ポイント投げ銭する」とか設定しておいて、それぞれの投げ銭を行うタイミングでは「★〜★★★」程度の評価として簡単に投げられるようにした方が楽。で、月末にその月評価したコンテンツに対して、設定した500ポイントを（評価の重み付きで）配分したりとか。

ともかくそんな感じで、いちいち人と人の小銭のやりとりであることを意識しないで済むような仕組みになると、ずいぶん使い勝手が向上するんじゃないでしょうか。と思いつきを書いておく。

_ highbiscusさん側に立った論を組んでみる (09:53)

前回まとめた私の主張は、あくまでもhighbiscusさんの主張に対しての対論であって、別にその論だけが正しいと思っているわけではない。highbiscusさんの主張から理がありそうな点だけを抜き出して、前回の自分の主張に対する論を組んでみることにする。

JUGEMのテンプレート仕様は、JUGEMの創作物であることは明白だ。テンプレート変数名個々の表現については、それに著作物性があると言えるものではないが、仕様全体としては十分に著作物性を感得することができ、その仕様は著作権によって保護されると言えるだろう。だから、JUGEMのテンプレート仕様と互換性を持つsbは、JUGEMが著作権を持つ著作物を利用していると考える。簡単な使用許諾を得てはいるようだが、著作権法によってJUGEMが持つ権利全体を考えれば、正式な許諾を得た上で商用配布しているという情報が公開されない限りは、sbは著作権的にグレイな存在なのではないかという疑問を持たざるをえない。

なんて感じだろうか。もちろん基本的に私は「仕様全体としては十分に著作物性を感得することができ」という点に反対の立場を取るわけだし、その程度の著作権侵害の可能性をクリアにするためには「簡単な許諾」で十分だとも思っているわけだけど。あと最終的な結論としても「著作権を侵害している！」ではなくて「グレイだよね」程度しか言えないよなー。

それ以外の「画面表示が似ているし、sbはJUGEMを参考にしているという雰囲気もあったし、合わせ技一本で著作権侵害だ」なんて主張は論外だから、仮定の反対論としても不採用。具体的な侵害の証拠を出さない限りは、ただの言いがかりだ。あと「表示画面が同一だ」と何度も主張しているのは、どう見ても「テンプレート仕様」と「テンプレートデータ」の区別ができていないとしか思えない。

_ 今日のスポクラ (14:20)

今日は、ウォームアップのウォーキングをスポクラまで走っていくことで代用した以外は、いつも通りのメニュー。ただ、毎日同じペースでやると飽きそうだから、マシントレーニングメインの日と持久力強化メインの日に分けようかなー。と思いつつある。マシントレーニングは、負荷に対応した筋肉が育っていくのを見ていると結構楽しい。

_ 今日のスポクラ (13:21)

マシントレーニングメインにしようと思ったけど、2周目に入ろうと思ったら結構きつそうだったんでやめて、やっぱりいつものメニュー。バイクは90Wを20分やるのがなかなかいい感じ。ただ気を抜くと（特に呼吸をきちんとしていないと）脈拍数が警告レベル（175回/分）を越えてしまうんで、ピーピー警告音がうるさいなー。この辺は毎日続けていくと下がるんだろうか。

_ だいぶ論点がまとまってきたな (13:27)

まず簡単なところから。

いしなおさんがトーンダウン : highbiscus -北国tvより、

あと「表示画面が同一だ」と何度も主張しているのは、どう見ても「テンプレート仕様」と「テンプレートデータ」の区別ができていないとしか思えない。

に対して、

途中、テンプレの自由度を忘れてただけです(笑　うかつだった！

ということは、「表示画面が同一だからデッドコピーであり、著作権侵害である」という主張に関しては、勘違いによるものとして全面的に撤回するわけですね。

また、それ以外の画面表示の類似に関しても、

で、合わせ技一本は、HTMLソースレベルでの類似は徳保さんが言ってましたが、まあこればっかは印象だろうね。

程度の、具体的な侵害の証拠が提出できないレベルの印象論なんですね。少なくともデッドコピーレベルではあり得ませんよね*1。デッドコピーレベルではないとしたら、サイボウズ裁判の判例を敷衍すると、著作権侵害ではない程度の画面の類似である、という結論になりますね。

上記を認めてもらえれば、あとはJUGEMのテンプレート仕様が、著作権によって保護されるべき表現であるかどうか、という論点だけが残ります。

まずは、なんかねちねちしたチイセェ反論が(笑 : highbiscus -北国tvより、

AppleのROMを巡る裁判等でOSは共有されるべきシステムであるから模倣OK論を言った互換機側主張ははねのけられております

に関してですが、この裁判（1983年）は、OSバイナリが焼き付けられたROMの複製（デッドコピー）に関する判例です。ソースコードおよびバイナリの複製に関してはそれが著作権法違反であることを私は一度も否定しておらず、今回のsbとJUGEMの件（ソースコードは複製ではない）とは関係ありません。

あと同エントリーでは、Whelan判決（の中で過去のBaker v. Selden判決の解釈を述べている部分）を根拠に、アイディアが著作権によって保護されるという判断を支持しているようですが、highbiscusさんは1986年のWhelanデンタ・ラボ事件の判例が、現在もプログラムの著作権解釈に関して主流であると考えているわけですね。

この判例が、現在プログラムの著作権解釈として、どのようなものと位置づけられているのかを語らずに、この判例を根拠として持ち出すのは、かなり問題があるでしょう。

だいたいこの判決文を引用している元ページ自体ですら、

これはアメリカにおいて大きな議論を呼び、しかし大勢は、これに否定的であった。そして、これは後に Computer Associates v. Altai判決において判例上も否定されたと考えられている（次回において掲載予定）。従って、以下のWhelan判決は既に乗り越えられてしまった判決ではあるのだが

という意味合いで紹介されている判例なんですよ。

ちなみにこの判例を含めた、プログラムの著作権解釈の歴史的な流れについては、「21世紀へ向けて」が参考になります（Whelan判決は、ここではウェラン判決と表記されています）。

歴史の流れを簡単にまとめると、コンピュータ黎明期である〜1970年代まで、プログラムの権利をどう扱うべきかの指針が明確でなかった時代が続くが、1980年代には特許権ではなく著作権での保護が主流となる（ソースコードやバイナリが著作権で保護されることが明確になる）。その中でソフトウェアの著作権が拡大解釈（仕様の範囲まで）されていき、そのピークといえるのが、highbiscusさんが根拠として提示したWhelan判決。その後1990年以降の判例によって、ソフトウェアの著作権による保護範囲は狭くなり、仕様やインターフェースに関する著作権を（基本的には）認めない判例が続き、Whelan判決は否定される。代わりにプログラムの仕様などは特許権（権利を認められるためには審査に通る必要がある）によって保護される方向になっていく。

ただ、どうもhighbiscusさんがこだわっているのは、私の「仕様に関しては著作権は認められない」という主張のような気がしてきたので、その点については過去に「仕様に関して全面的に著作権は認められない」という表現をしている文章があった場合、それについては撤回します。

正しくは、「近年のプログラム著作権に関する判例や、互換プログラムが一般的に流通している実情を鑑みると、プログラムの仕様については、たいていの場合著作権は認められない」です。

そしてhighbiscusさんの「プログラムの仕様は、それが独自のものであり、かつ、公共的なもの（ってなんだろう？）でなければ、自動的に著作権が認められる」という解釈は支持しません。

ところで、ソースコードおよびバイナリが複製ではなく、仕様がクローンであるOSやさまざまなエミュレータや、データフォーマット互換のプログラムの存在については、どう考えているんでしょう？

なんかねちねちしたチイセェ反論が(笑 : highbiscus -北国tvにある、

あと、インポートならOKですが、これは要するにAppleIIの裁判でも述べられているAppleII用のソフトウェアの実行にAppleIIのROMをパクらねば実現できないというような融合法理は成り立たないという判例に対応した話でしょう。

あたりがその件に関するhighbiscusさんの解釈っぽいですが、上記の文章が具体的に何を言っているのかわからないので、もうちょっとわかりやすく解説して欲しいところです。

あと、私が「highbiscusさんのサイボウズ判決の解釈を認めていません」という件について、

まだ「ソースのみ保護するのだ！」と古臭い認識引っ張って主張したのを引きずってるなら、ここは改めてください。明らかに間違いです。認める認めないの話ではありませんし、間違ってるというならその論拠をお願いします。

私が、「サイボウズ判決は認めている」が「それをhighbiscusさんが独自に解釈した結果、他の事例に当てはめて根拠とすることを認めていない」という意味だとわかりますよね？　「プログラムの実行によって表示される画面の設計が、著作権による保護を受けうる（その条件は限定されている）」というサイボウズ判決の趣旨は認めているが、「だから、JUGEMのテンプレート仕様は著作権による保護を受ける」というhighbiscusさんの解釈は受け入れられない、ということです。

それにしても、highbiscusさんの東大レベルの国語能力は、

(1)ア　一般に，電子計算機に対する指令（コマンド）により画面（ディスプレイ）上に表現される影像についても，それが「思想又は感情を創作的に表現したもの」（著作権法２条１項１号）である場合には，著作物として著作権法による保護の対象となるものというべきである。

という文章を、

サイボウズ裁判の判決文では判決冒頭で明確にソフトウェアの外観面でのデザインも、著作権の「思想又は感情を創作的に表現したもの」（著作権法２条１項１号）であると断じています。

と解釈するんですか？　「「思想又は感情を創作的に表現したもの」（著作権法２条１項１号）である場合」という条件を満たした場合のみ、「著作権法による保護の対象」になる。すなわち、ソフトウエアの画面が著作権法による保護を受けるための条件を述べた文章である、という解釈しかできないと思うんですが。

まさか、

本件において，原告は，原告ソフトは，個々の表示画面がそれぞれ著作物であることに加えて，相互に牽連関係にある各表示画面の集合体としての全画面も全体として一つの著作物であると，主張している。

の部分ではないですよね。これは原告の主張を述べた文章であって、裁判所の判断を述べた文章ではありませんよ。どうもhighbiscusさんが判例を根拠にする場合、原告の主張を裁判所の判断と混ぜて語ることが多いようですが、特にその判決が敗訴であった場合に、原告の主張は何の根拠にもなりませんよ。判決で否定されているんだから。

_ プログラムの画面表示の著作権 (19:49)

ああ、サイボウズ裁判の解釈は、応用以前の段階から違っているんですね。こっちにも答えておいた方がいいんでしょう。

いしなおさんのオレオレ著作権を突く : highbiscus -北国tvで、

(1)ア　一般に，電子計算機に対する指令（コマンド）により画面（ディスプレイ）上に表現される影像についても，それが「思想又は感情を創作的に表現したもの」（著作権法２条１項１号）である場合には，著作物として著作権法による保護の対象となるものというべきである。すなわち，美術的要素や学術的要素を備える場合には，美術の著作物（著作権法１０条１項４号）や図形の著作物（同項６号）に該当することがあり得るものであり，いわゆるコンピュータゲームにおいて画面上に表示される影像などには美術の著作物に該当するものも少なくないが，この点は，いわゆるビジネスソフトウェアについても同様に当てはまるものということができる。

の解釈として、

著作物とはなにか？法律には「思想又は感情を創作的に表現したもの」とあります。それに当たる場合は画面の表示も該当すると述べている部分です。

その上で、美術的要素の場合にはさらに「美術の著作物」(著作権法１０条１項４号)に当たると考えられる旨を書いているのであって、いしなおさんの書き方では、あたかも美術の著作物でなければ著作権性は成り立たないといった文脈ですが、大嘘です。

とhighbiscusさんは読解していますが、highbiscusさんの読解の方が正しくありません。その二つの文章は、「すなわち」という（説明の）接続詞で接続されているんですよ。

「著作物として著作権法による保護の対象となるものというべきである」という文章を受けて、「すなわち」（つまり、言い換えれば）と続けているのですから、前段の文章をより具体的に（何の著作権を持つのか）説明しているのが「美術的要素や学術的要素を備える場合には，美術の著作物や図形の著作物に該当することがあり得る」になります。

highbiscusさんの解釈（「その上で」という意味合い）で読むためには、ここの接続詞が「さらに」とか「また」とか「あるいは」などの添加や並列、選択の接続詞でないといけません。「すなわち」は、前段の表現を詳しく説明するための接続詞です。

_ 今日のスポクラ (11:19)

いつものメニューだったんだけど、1人マシンを占有している人がいて、マシンが一つできなかった。いやまあ本格的に（何セットも）やっている人だったから正しい使い方なんだろうし、インターバルの時にちょっと割り込ませてもらうこともできただろうけど、そこまでしてやらなくてもいいしなー。そういや今日もバイクは90W20分やったんだけど、今日は1度も脈拍数の警告範囲に（というか170回/分すら）入らなかった。もう体が慣れたのか？　人間の体の順応性はすごいなー。

_ 今まで何度かやったのに (15:42)

またやって、しかもしばらく気がつかなかったから、ここに書いておこう。

メール関連をインストールする前に、PHPをインストールしてしまうと、メール関連の関数は使えなくなりますよーーー。

メール周りは面倒くさいから、後回しにしがちなんだよなー。

_ 「文脈を読む」と「こじつけ」の境界 (09:24)

この話題は本筋じゃないだろうけど、プロレス的にはやっておいた方がいいんだろうから続けます。

「文脈を読む」と「自分の解釈を前提に文章を読む」とは違います。自分の解釈を当てはめるために、実際にそこに書かれている文章や言葉の意味を改変するのは、「文脈を読む」と言う範囲を超えた「こじつけ」です。

元気ないしなおさんに - その４　すなわちより、

一般に，電子計算機に対する指令（コマンド）により画面（ディスプレイ）上に表現される影像についても，それが「思想又は感情を創作的に表現したもの」（著作権法２条１項１号）である場合には，著作物として著作権法による保護の対象となるものというべきである。

が、

著作性のある表現はソフトウェア表示画面においても保護されるべきである（I）

という意味を持ち、それはさらに、

ソフトウェアの外観面でのデザインも、著作権の「思想又は感情を創作的に表現したもの」（著作権法２条１項１号）である（II）

になるとするのは、あまりにも飛躍が大きすぎます。元文章→(I)は確かに元文章を要約したと言えますが、（I）→（II）は同じ文章ではありません。「著作性のある表現（である場合に）は」がもつ「限定」の意味が抜け落ちています。

この「すなわち」は、前半のソフトウェアも著作権の範疇であるという論旨を受け、さらに、であるからして、著作権に定められたように、美術的要素や学術的要素なら、美術の著作物にあたるし、図形に著作物にあたるであろうってこと。

に関しても同様です。自分の解釈は正しいから、この文章における「すなわち」は、「さらに、であるからして」という意味を持つ、という読み方は正しくありません。もしそう読みたい（「さらに」という添加の意味を持つとしたい）ならば、判決文の「すなわち」という言葉の選択は、間違っていると主張するべきでしょう。

※ちなみに私は、この「電子計算機に対する指令（コマンド）により画面（ディスプレイ）上に表現される影像についても」における「も」は、「電子計算機の指令」を差すにかかると考えている。指令自体（ソースコード）が著作物の要件を満たすことによって著作権で守られるのと同様に、「それによって表示される画面も」という解釈だ。その場合「すなわち」以降の文章が「プログラムの著作物」との差異を具体的に説明する文章となる。おそらくhighbiscusさんは、この「も」が「その他一般の著作物」を差すにかかるのだから、「当たり前の前提を提示しているにすぎない」という解釈なのだろうが、その場合は「すなわち」の意味に矛盾が生じる。

_ 著作物性と言う要件 (09:29)

ところでhighbiscusさんと私の間での著作権に関する認識で、もっとも大きな相違点を見つけた気がするんですが、元気ないしなおさんに - その３ : highbiscus -北国tvにおいて、

一般に，音楽ついても，それが「思想又は感情を創作的に表現したもの」（著作権法２条１項１号）である場合には，著作物として著作権法による保護の対象となるものというべきである。

という自ら挙げた例文に対して、

これらがこの文脈で書いてあって、「音楽は思想又は感情を創作的に表現したものの場合のみ著作権を持つ」とか(偶発の音じゃあかんのだろうな)、「絵は思想又は感情を創作的に表現したものの場合のみ著作権を持つ」って制限を言った意味合いの文章と訳するのは文脈的に無理あるでしょう。

「音楽も著作権の対象物」と言った文章ですよ。

と評価しているということは、（フェアユースおよび融合法理による例外を除き、）音楽はそれが独自の創造物である限り（偶発の音であっても）、著作権を持つと考えるわけですか？

「思想又は感情を創作的に」という要件を十分に満たしているかどうかで、著作権が認められるかどうかは変わってくる、という（私の）見解は間違いであるという主張でしょうか？

_ GTD本ようやく読み終わった (12:05)

仕事を成し遂げる技術―ストレスなく生産性を発揮する方法(森平 慶司/デビッド・アレン)をようやく読み終わった。

書いてある内容はとてもいいんだけど、文章とか構成にかなり問題があって、八割方読んだところでしばらく放り出してしまった。これだけ内容がいいのに、本自体の評価は低いってのは珍しい。翻訳のせいなのか原文からこうなのかは不明。でも翻訳も悪いことは確かだな。修正したくなる部分や原文を参照したくなる（翻訳だけでは意図がつかめない）部分がいくつもあったし。

で、この間試してみて、GTD的なやり方というのは確かにとても有用だということはよく分かっていたし、「Getting Things Done (a.k.a. GTD) (1) (2) (3) (4)」のまとめを読めば十分にその骨子はつかめることは確かなんだけど、せっかくだから自分なりにGTDのポイントをまとめてみることにする。

ただ、本家GTDのやり方であまり好みじゃなかったり、自分には関係なさそうな（使わなそうなシチュエーション向けの方法論とか）ところは、かなり自分流に曲げて解釈しているんで、正確にはGTDのポイントのまとめというよりは、GTDを自分で採用するならばこんな感じにしようといった指針に近いかな。理論的なバックボーンはGTDのものをそのまま借りる。

1. 脳の中にだけある雑多な情報を、脳から外部メディアに出力することで、脳の能力の無駄遣いを解消する
2. 出力した情報を整理整頓し、不要なものは捨て、必要なものはきちんとリスト化する
3. ToDoリストを、具体的な行動レベルに展開してしまう
4. 時間軸でToDoリストを整理する
5. 状況でToDoリストを整理する
6. 「依頼」と「待機」によってToDoリストを整理する

注意！

ここでまとめているGTD関連の話は、GTD本に書かれている内容をそのまままとめたものではありません。ここに書かれているのは、私がGTD本を読んで得た知識を元に、その骨子を応用した仕事管理ツール（プログラム）の仕様を考える試行錯誤の過程です。そこにはGTD本に書かれている内容とは異なる部分も含まれており、ここの文章を元に本家GTDを理解しようとすることはお薦めしません。

_ 脳の中にだけある雑多な情報を、脳から外部メディアに出力することで、脳の能力の無駄遣いを解消する (12:15)

まず最初のポイントとしては、「人間の脳を効率よく使おう」というところ。人間の脳のキャパシティは限られている。その脳のキャパシティを「雑多な物事を脳にのみ記憶しておき、それを適切な時に思い出すために使う」というのは、実は大変な無駄遣いだ。

たとえば「そろそろ塩が切れるから買わなきゃ」みたいなことを脳のみに記憶し、適切なとき（買い物に行ったとき）にそれを思い出すというような日常的な行為は、脳の能力をかなり消費している（そのことを必要なときに思い出せるようにするために、定期的に記憶をリフレッシュしたりとか）。

また脳のみに記憶している場合は、「何か買わなければいけないものがあること」は覚えているのに、実際に店に行ってからそれが何だったのかを思い出せなかったりして、買い損ねたりした経験がみなさんにもあるだろう。

そういうことが積み重なると、脳の一部は常にそういう「必要なときに思い出さないと」という雑多な情報（を覚えておかなければならないというストレス）に汚染されてしまい、目の前の仕事に対して脳の能力をフルに利用することができなくなってしまう。

そこでGTDでは、「気にかかったこと」はすべて脳から何らかの外部記録に出力してしまうことを、最初のステップとする。出力する記録媒体は、紙でもコンピュータでもかまわない。ただし、後から検索・参照しやすいものである必要がある。ともかく、脳の中にだけその情報が保存されている（思い出すためには、脳の能力のみを使って検索しなければならない）ことを回避する。

そうすることで、必要なことを思い出す際に、脳だけではなく外部に参照しやすい形で出力した記録を使って、検索することができるようになる。また中途半端に気にかけておかなければならないことを脳から削除する（外部媒体に移動することによって、常に気にかけるのをやめる）ことで、目の前の目的に脳の能力をめいっぱい使えるようにする。

_ 夏風邪ひきかけ (14:46)

昨日あたりから喉に違和感がある状態が続いていたんだけど、そんなときに扇風機をつけっぱなしで寝て、さらに喉の症状が悪化した。今のところは、うっすらと喉が痛くて、やたらと痰が絡む程度の症状だけど、これ以上悪化するのは避けたいなー。それにしても、一昨日あたりから夏のくそ暑さがちょっと和らいだ感じ？

_ 出力した情報を整理整頓し、不要なものは捨て、必要なものはきちんとリスト化する (13:04)

「GTD本ようやく読み終わった」、「脳の中にだけある雑多な情報を、脳から外部メディアに出力することで、脳の能力の無駄遣いを解消する」の続き。

脳の中にだけある雑多な「気にかかったこと」をすべて外部メディアに吐き出してしまったら、続いては、出力した「気にかかったこと」をきちんと整理する。特に重要なのは、「気にかかったこと」の中でも「何かしなければならないこと」だ。

その多くはいわゆるToDo的な物事になるが、あまり具体的ではない将来的な目標なども、そこには含まれるだろう。「すぐにすること」「そのうちすること」「いつかしたいこと」などの「何かしなければならないこと」を抽出し、その意味づけと共にリスト化していく（簡単な方法としては、上記三つのフォルダを作って、そこに入れていく）。

「気にかかったこと」の中には、「何かしなければならないこと」以外の物事も含まれているだろう。それらについては、それが確実に必要なものならば「資料」という分類でリスト化する。しかしそれが不要であると判断できた場合は、どんどん捨てていく。この「不要なものは捨ててしまう」という点はとても重要。

「何となく気になる」けれども、「それが不要かどうかわからない（判断を後回しにしている）」ために取っておいてあるものが積み重なることでも、脳の効率的な利用は妨げられる。「気にかかったこと」ということで一度整理の俎上に挙げた上で、それが不要だと判断できたならば、きちんと捨ててしまうことにより、脳の無駄遣いはさらに解消される。

ちなみに後で具体的な方法論も紹介するが、先ほど整理した「何かしなければならないこと」に関しても、その処理が完了したらどんどん捨てていくことになる。

つまり、脳の中に曖昧にため込まれている雑多な物事を、一度すべて外部にわかりやすい形で出力し、それらを判断の俎上に載せて具体的に整理整頓していき、不要品は捨て、必要なものはその意味付けとともに明快にリスト化していくことになる。

※と書いている内容は、ずいぶん本家GTDのやり方と違ってきているなーと思ったりもするんだけど、まあ俺の場合は全部コンピュータ上で処理することを前提に、具体的なやり方を構築し直しているから、しょうがないよね。

_ ToDoリストを、具体的な行動レベルに展開してしまう (13:20)

その仕事を実現するためには、具体的にどのような作業が必要なのかが明確ではないような表現を、ToDoリストの項目として採用する人は多いだろう。

たとえば、「Aの会議に出る」とか「Bの追加機能仕様書を書く」などはずいぶん具体的な表現に見えるが、実際にはそれに付随したさまざまな行動に分解できる。そこで、GTDではリストの項目を具体的な行動のレベルに展開することを求める。

たとえば「Aの会議に出る」に関しては、実際に会議に出る前に「Aの資料を読む」「出席するXさんと情報交換（電話 or メール）する」そして「○日×時に△でAの会議」となる。あるいは「Bの追加機能仕様書を書く」の場合は、「Bの最新のソースコードをSVNからCOする」「テスト環境を構築する」「追加機能の概要を書く」……、などの関連した具体的な行動に展開することができるはずだ。

そのように具体的な行動まで展開したリストを作ってしまえば、あとはそこに書かれている行動をこなすだけでどんどん仕事が進んでいく。

通常のやり方では、具体性のない仕事項目をToDoリストから引っ張り出し、それについていったい何をするべきかを考え、その場で思いついたことから作業をしていくことになるだろう。その場合、目先の仕事を越えて、自分がやらなければならないこと全体を俯瞰するということが、かなり難しい。

特に作業単位での、「今できること」「今はできないこと」の違いや、「すぐにできる作業」「時間がかかる作業」の違いが、ToDoリストレベルから見えてこないため、たとえばちょっとした空き時間に何ができるのか、などはToDoリストをながめても判断がつかない。

一方GTDによって具体的な行動レベルまで展開されたToDoリストにおいては、特定の仕事の垣根を越え、自分がやらなければならないことの全貌を、具体的な作業レベルで見渡すことができる。そのため、ある時点での自分の能力（時間ややる気や状況など）に応じた仕事をこなしやすくなる*1。

_ 今日のスポクラ (15:39)

いつものメニュー。土日月と空けたにもかかわらず、90W20分のバイクでは脈拍がほとんど160回/分台にも乗らないようになった。心肺機能の慣れっぷりはすごいなー。そういやジムの端にピッチング筋肉強化に良さそうなゴムチューブがおいてあったんだけど、あれってどうやって使うんだろう？　足で踏んで固定したりしていいんだろうか。今度聞いてみないと。

_ 時間軸でToDoリストを整理する (12:49)

具体的な行動レベルまで展開したToDoリストの各項目には、時間に依存した内容が存在するだろう。たとえば、「○日までにやらなければならない」あるいは「○日にやらなければならない」あるいは「○日○時にやらなければならない」あるいは「来月以降にやらなければならない」など。

そのような時間に依存した内容は、その日、その時間にきちんと思い出すことができれば、それまでは忘れておいてもかまわないものが多い。たとえば、「来週の火曜日に歯医者に行く」のような項目は、その当日になるまで忘れておいてもかまわないだろう。また「来月になったらAさんに電話する」のような項目も、来月になるまでは忘れておいてかまわない。

そのように、時間に依存しており、現在は覚えておく必要がない項目は、その特定の時間にきちんと思い出せるような仕組みを用意しておけば、目の前のToDoリストからは削除してしまってかまわない。これもまた「不要なものは捨てる」の一種だ。

GTDでは、直近の一ヶ月（3031日）分は日付ごとの、それ以降の1年（12ヶ月）分は月ごとのフォルダを用意しておき、時間に依存する項目は、その中の該当の日付・月のフォルダに収納（移動）してしまう方法を提案している。

そして、時間に依存した項目は必ずそれらのフォルダの中にあるものとして、毎日該当の日付のフォルダを、月が変わったときには該当の月のフォルダの内容をチェックするよう習慣づける。それによって、時間に依存した項目は、該当の時間には必ずその存在を思い出せることになり、それまでの間は頭の中からすっかり忘れてしまっておいてもかまわないことになる。

ちなみに、おそらく本家GTDの紙＋ファイリングをベースにしたやり方では、物理的なスペース等の兼ね合いもあって、この43（3031日＋12ヶ月＋現在）という分類の詳細度が提案されているものだと思われる。実際、人間が手軽に管理できる分類の詳細度も、この程度でちょうどいいような気もするが、コンピュータベースで管理する場合には、もうちょっと詳細度を細かくした管理ができるようにしていいように思う。

あと、この時間軸ベースの分類は、「ある特定の日時に行動する必要があること」の処理にはとても向いているが、「ある特定の日時までに（締め切り）行動する必要があること」をうまく管理することが難しいように思う。コンピュータデータの場合は、「特定のフォルダに入れる」のような単純な分類だけでなく、「ある期間すべてのフォルダで見える」ような分類も表現できるので、締め切りのある行動に関してはそのようなアプローチで表現するといいかもしれない。

_ 腹をこわした (13:27)

なんか昨日は朝方までげりぴー状態で寝られなかった。特に変なものを食った記憶がないんだけど、単純に夏風邪の症状なのかなー。喉の調子も相変わらずで、さらに痰のからみっぷりはひどくなりつつあるかも。

_ 今日のスポクラ (13:27)

なんて体調の中でも一応行っておいた。動いて汗をかいた方が逆に治りが早いかもしれないとか思って。で、今日はいつもよりもマシンメニューの回数を減らし、その分タオルを使ったシャドーピッチング100回を追加した。8割の力で連続100回って結構来るものがあるな。でも、この間久しぶりに軟球を投げたら、いまいち肩の回りがスムーズじゃなかったんで、単純なマシントレーニングだけでなく、もうちょっと実践的な筋肉の鍛え方が必要な気がするってことで。バイク90W20分はさらに心拍数は落ちて、基本が150回/分台の前半になった。これってどこまで落ちるんだろうなー。

_ すみません、ツッコミが受信できていないみたいです (14:03)

τさんからツッコミをもらい、サイドバーの「最近のコメント」には表示されているし、メール確認等はきちんと届いているのですが、なぜか該当の日付（18日と20日）にその内容が表示されません。理由がよく分からないのですが、ひとまずメールで受け取ったツッコミをこっちに転載しておきます。

ようやくhighbiscusさんが何を言おうとしているのかわかった気がします。

おそらく彼は、「音楽の著作物」「美術の著作物」「プログラムの著作物」などに並んで、「ソフトウェアの外観デザインの著作物」というものを裁判所が認定した、と思っているのでしょう。

と思ったら

3度目の投稿は無事20日のところに表示された模様。何が原因だったんだろうなー。投稿の際に何か設定とか変えました？＞τさん

_ 今日はスポクラお休み (13:28)

つばを飲んでも喉が痛い状態になり、さらにちょっと寝違えて（あるいは昨日のシャドーピッチングのせいで？）持病の背筋痛が出かかっているんで、今日はスポクラはパス。台風が近づいていて雨の中スポクラに行くのもだるかったし。

_ 今日は (13:32)

JR東日本：列車運行情報 関東エリアをながめながら、やばそうだったら早めに帰らないとな。

_ 状況でToDoリストを整理する (13:33)

時間軸での分類とは別に、状況によってもリストを整理することができる。ToDoリストにまとめられた各項目には、特定の状況でしか実行できないものが存在するはずだ。たとえば、「寝室の収納の掃除をする」のような項目は、家にいるときにしか実行できないだろう。また、「営業のAさんと打ち合わせ」のような項目は、会社にいるときにしか実行できない。

そのような項目は、その実行可能な「状況」という軸で整理してしまう。たとえば、現在「家にいる」という状況で何らかの仕事をこなそうと考えた場合には、「家にいる」という状況のリストを見れば、今実行可能な項目が見つかるだろう。逆にその状況では「会社にいる」という状況のリストを見る必要はない。

というのが「状況」という軸での整理なのだが、本家GTD本ではこの「状況」ベースの整理の具体的な方法は、いまひとつ明快に書かれていなかった気がする。その理由としてはおそらく以下の2点が挙げられるだろう。

まず、この「状況」という分類方法は人によって大きく分け方が異なる。会社勤めしている人しか「会社にいる」という状況はないだろうし、また複数のオフィスを持っている人ならば、単純に「会社にいる」とひとくくりで表現することはできない。そのため、「状況」という軸における分類では、誰にとっても明快なサンプルが出せないというのが一点。

もう一点は、本家GTDでは基本的に通常の紙＋ファイリングベースでの分類を前提と（というか、そのようなやり方でも実現できるように）している。そういう物理的な分類方法では、先に書いたような時間軸での分類という明快なやり方を先に採用してしまっている関係上、それとは異なる「状況」という軸を使った分類を、どう実現するかが難しい。物理的な紙とファイルでは、一つの紙は一つのファイルにしか挟めないのだ。

ちなみに具体的な分類例として、私は以前「家にいる」「会社にいる」「出かけている」という三つの状況の分類を試してみた。それはそれで有用な分類方法ではあったのだが、時間軸の分類のような明快さはなく、気持ちよく整理していくという気分とはほど遠かった。この「状況」を切り口に分類するというアプローチ自体は悪くないと思うのだが、整理の明快さを実現するためには、もう一工夫が必要なように思う。

すでに時間軸で分類されたものに対しての「2軸目の分類の表現が難しい」という点に関しては、コンピュータで分類する限りは、リンクによってn軸の関係性は簡単に表現できるので、GTDに向いたn軸の分類が使いやすいプログラムを用意すればそれで解決できるだろう。

自分なりにGTD的なやり方をコンピュータ上で実現するにあたっては、この「状況」という分類方法の実装は検討するべき点が多いが、逆に言うとこの部分で新しいうまいやり方を思いつけば、GTD的なやり方の生産性はさらに高くなりそうでもある。

_ 客観的な判定基準 (13:51)

自分の方の話は、（分かってはいたけど）その不毛さにちょっと疲れてきたので、GTDネタとかで脳みそがリフレッシュされるまで中断することにして、highbiscusさんとτさんの間でやりとりしている、井上雅夫さんの手による「米国著作権法102条（b）項の解説文」の読解について、取り上げてみます。

ポイントは、元の井上さんの文章の、

プログラムは何らかの機能を有しているのであり、ソースコードあるいはオブジェクトコードの表現の複製、翻案を行えば、それに伴って、その機能もコピーされる

における「ソースコードあるいはオブジェクトコードの表現」の解釈でしょう。

τさんはblog@なゆきすと : 「プログラムの表現」とは何かにおいて、

井上氏の解説内で使われている「プログラムの表現」という言葉は、「メディアの上に表現されているプログラムコードそのもの」を指すと考えるのが妥当であろう。

というように、その「ソースコードあるいはオブジェクトコードの表現」とは、ソースコードあるいはコンパイルされたバイナリコード自体を指す（その実行された画面表示などは含めない）と解釈しています。もちろん私もそう解釈します。著作権に関する文章における「表現」という言葉の意味を理解していれば、そう読むのが当たり前です。

一方highbiscusさんは、単に102条bの表現侵害規制の判例を語ってるだけでしょ : highbiscus -北国tvによれば、

プログラムとはなんらかの機能を有しているのはあたりまえであるが、ソースや表示をコピーして、これは機能(アイディア)のコピーであるからいいのだ！って論理は間違いで、それは著作権侵害です、と述べている。

のように、コンパイルされたバイナリコード自体だけではなく、それを実行した際の表示なども含めて、「ソースコードあるいはオブジェクトコードの表現」であると解釈しています。この文章は、Whelan判決における「アイディアのコピーも著作権侵害だ」を表現している文章だ、という主張らしいです。

さてどちらが正しいのでしょう。この件については、客観的な判断基準が存在するので、いつもの不毛な言い合いを続ける必要がありません。実際に元の文章を書いた人に、どちらが正しいのかを聞いてみればいいわけですから。

そこで、「プログラム関連米国判決集ホームページ」の井上雅夫さんに、米国著作権法102条（b）項の注釈文における「ソースコードあるいはオブジェクトコードの表現」の解釈についてメールで尋ねたところ、それは単に「ソースコードとそれをコンパイルしたバイナリコード自体」を意味しており、そこにおける「表現」という言葉には「オブジェクトコードを実行した際の表現（画面表示など）」という意味合いまでは持たせていない旨、ご返答をいただきました。

というわけですので、少なくともその注釈文において、井上さんが「オブジェクトコードを実行した際の表現」について語っているわけではないことになります。

※上記2段落の文章は、井上さんにその内容に間違いがないか確認していただいた上で、そのまま*1掲載しています。

こうやっていつも客観的な判断基準があるといいんですけどね。

_ mb_convert_variables (17:00)

今までその存在に気づかず、自前で再帰関数を書いて使っていたよorz...。

_ 病院に行った (11:17)

喉の痛みが悪化して、常時喉の奥に異物感があり、そのせいで吐き気がして昨日はろくに眠れなかったんで、朝一で病院に行った。内科と耳鼻咽喉科のどちらがいいか迷いつつ、結局耳鼻咽喉科の方を選択。で、診てもらったんだけど、昔ひどかった時みたいに、巨大な膿が溜まっていたりすることはなく、単にちょっと腫れているだけだったんで、ふつうに抗生剤と炎症止めとうがい薬をもらってきた。また喉の奥を針でつついて皮膚を破り、膿を吸引するという地獄のような目に遭う覚悟をしていたのに。でまあ帰って薬を飲んだら、つばを飲み込むだけで激痛が走っていたのが治まり、つばを飲むとちょっと痛いかな、程度になった。即効性があるなー。今度からは同じ症状になったら我慢せずにすぐに病院に行こう。

_ 今日のスポクラ (11:18)

で、まだ背筋痛は残っているんだけど、ここで休むとずるずる行きそうな気がしてきたんで、逆療法で行くことにした。ウォームアップとストレッチをジムでやるのは時間がもったいないんで、家でストレッチまでしてからスポクラへ。黙っていると背筋痛が結構きつかったんだけど、マシンをはじめたらそんなに気にならなくなった。で、最後にまたシャドーピッチング（今日は50回）をやったんだけど、軽めにやっているうちにずいぶん背筋もほぐれた気がする。で、最後のバイクは前半10分を90W、後半10分を100Wにチャレンジしたら、後半ちょっとだけ脈拍の警告（175回/分）を越えてしまった。10Wの違いって結構あるんだな。でもやっているうちに160回/分程度に落ち着いてきたんで、これも何日か続ければすぐに体が慣れるでしょう。

_ DBが落ちていました (16:25)

DBサーバーがおそらく1時間ほど落ちていたようです。16時過ぎに気付き復旧（再起動）しました。原因は調査中です。というかログに何も残ってないなー。なんだろう？

_ 今日のスポ (22:55)

スポクラには土日は行かないことにしているんだけど、シャドーピッチングくらいは家でやってもいいよなということで、左右100球ずつ。左は一時期右肘が痛かった頃には結構練習したんだけど、その後肘が治ってから全然やってなかったんで、肩の回転がものすごく不自然だ。でもまあ遅いストレートくらいは投げられる程度にやっておいた方が、体の左右のバランスが取れていい気がする。

_ 「依頼」と「待機」によってToDoリストを整理する (13:49)

GTDでは、ToDoリストを整理するにあたって、その仕事は自分以外の誰かが処理をした方が適切であると判断できた場合は、その項目を適切な誰かに任せてしまうことになる。

当たり前と言えば当たり前だが、自分で仕事を完了させることだけが仕事をこなす手段なのではなく、自分以外の適切な誰かにその仕事を任せてしまうことも、仕事の処理方法の一つであることを、きちんと認識・区別して扱うことが重要なのだろう。

ただし、自分のToDoリストから発生した仕事に関しては、他人にそれを任せてしまってそれで終わりというわけではない。

たとえば、あるプログラムを作っていて、それで使うアイコン画像が必要になった場合、そのデザイン作業はデザイナーに任せることになる。しかし、それで自分の仕事は完了するのかというとそうではなく、その次には「できあがったアイコンをプログラムに組み込む」という自分の作業が待っている。

デザイン作業の完了を時間で特定できるのならば、次に自分が行うべき「アイコンをプログラムに組み込む」という項目を、時間軸で整理しておけばいい。しかし、人に任せた作業の完了時間を特定することは難しく、デザイナーからの作業完了報告（コールバック）を待って、次の作業にかかるといった進行が現実にはよくある。

また、そのように人に任せた仕事では、適切な期間内にコールバックが返ってこない可能性もあり、そのような場合はこちらから作業状況を確認するなどといった行動を取る必要が出てくる。

そこでGTDでは、自分以外の他人の行動によって、自分の仕事が動くような項目は、「待ち」という分類によってカバーする。そして、この「待ち」と分類された項目リストを、自分の仕事を管理するためのToDoリストと同様に定期的にチェックすることにより、他人に任せた仕事の進行状況をまとめて管理する。

本家GTDでは、この「依頼」と「待機」による処理や分類に関しては、以上のような概要の説明にとどまり、あまり具体的な話は語られていなかったように思う。しかし実際に仕事をする際には、「依頼」と「待機」という要素はかなり重要だ。特に複数人で協調して動くプロジェクト的な仕事を管理する際には、この「依頼」と「待機」こそが仕事管理の肝となる。

仕様が複雑になることを厭わないのならば、「依頼」と「待機」の管理のために、それとリンクさせて使うための「人」という情報を持たせるべきだろう。ただし、いわゆるプロジェクト管理ツールのように複数の「人」の視点で仕事を管理することができるようにする必要はなく、あくまでも「自分」が仕事を依頼した第三者としての「人」が管理できればそれでいい。

また、「依頼」や「待機」での分類に対しても、「時間」や「状況」での分類は有効だと思うが、その扱いは自分の仕事における「時間」や「状況」の分類とは多少違ったものにした方がわかりやすくなるような気がする。

私の理想の仕事管理ツールを作るにあたっては、この「依頼」や「待機」を具体的にどのような仕様で取り込むべきかという点において、まだまだ検討事項が多い。懲りすぎると使いにくくなることは分かっているので、シンプルさを保ちながらどれだけ有用な機能を実現できるかが鍵になるだろう。

_ 負荷分散 (21:37)

なんか最近アクセス数の増加が激しく（サーバー死亡前はデイリー10万hit（5万ページ）程度だったのに、現在50万hit（30万ページ）くらいになっている）、せっかく気合いの入ったスペックのサーバーに移動したのに、またも負荷的に辛くなってきたので、DB回りを負荷分散してみました。重い検索系を別サーバーにレプリケーションしたDBに回すようにして、メインDBの性能の安定化を図ってみたんだけど、これでいつまで持つかなー。またサーバー増やすのは嫌だなー。

_ 今日のスポクラ (13:16)

家でストレッチとシャドーピッチング左右までやってからスポクラへ。あとはいつのもメニュー。バイクは100W20分にチャレンジしてみたところ、特になんということもなかった。脈拍も140回/分台前半を最後までキープしていたし。次は110Wにチャレンジしてみるべきか。

_ ハードウエア故障？ (17:56)

昨日負荷を分散した先のサーバーが、ハードウエア故障らしい。まだ原因が不明なんだけど、ハードディスク以外の部分が怪しい挙動をしているとか。で、16:00過ぎくらいから1時間ほど死んでいた。再起動を何度かトライしたところ何とか立ち上がって、現在は正常に動いているみたいだけど。

依頼すればハードウエア交換（ハードディスク以外を交換）してくれるらしいけど、念のためバックアップとかを考えなければならないんで、ひとまずは現状で運用しつつ、また同じことが起こったら交換してもらうことにした。

っつーか最近サーバートラブルが多いのは、夏のせいかなー、それともアクセス増大のせいかなー。他のサーバーには特にトラブルが起きていないから、アクセス増大が主原因＋夏だからが副原因って感じだろうか。

ひとまずそういう状況なんで、分散した負荷を再び元のサーバーに戻して様子見中。早く夏が終わらないかなー。

_ 記事の関係性ではなく、人間関係を表現するためのサイトトラックバック (09:13)

トラックバックは、記事間の言及関係を表現するために作られたものだ。いわゆる議論的な文章の関係性を表したい場合は、それで十分だとは思うが、実際にWebサイトを運営していると、議論的な関係性だけではなく、単なる人間関係を表現したい場合も多い。

つまり、ある人の特定の記事に対して言及するのではなく、単にある人に対して言及していることを表現したいことがよくある。テキストサイト系でいうところのなれ合いリンク、はてなダイアリーで言うところのreferred的なものだ*1。

しかしよく考えてみると、実際にトラックバックという規格を使って、人間関係を表現することは簡単だ。現状では記事単位でしか用意されていないトラックバックping URL（受信用URL）に追加して、Webサイト全体（＝Webサイト運営者）に対応するトラックバックping URLを用意すればいい。そこに送られたトラックバックは、特定の記事に対する言及ではなく、そのWebサイト（＝Web運営者）に対する言及として扱う。

トラックバックping URLは多くの場合、

http://example.com/blog/trackback/[entry id]

のような形式をしているが、[entry id]としてサイト全体を表すIDを新しく振るだけで、たいていのシステムでは対応できるだろう。わかりやすさでいえば、[entry id]が空の場合はサイト自体への言及として扱うといいかもしれない。

trackback auto-discoveryへの対応も、特に何ということはなく、Webサイト（blog）のトップページに、各エントリーに埋め込んであるRDFと同様のものを（トップページに関する情報として）埋め込んでおけばそれでいい。トラックバックping URLの人間向けの表示は、タイトル部にでもそれなりのスペースを確保するのが現実的だろう。

技術的には何も難しいところはない。送信側は、基本的なトラックバック送信機能さえ持っていれば、特に新しい仕組みを用意する必要はない。受信側は上記のようなちょっとした工夫程度の機能拡張で対応ができる。それだけで、記事単位ではなくサイト単位での関係性を簡単に表現できる。

ひとまずこのような機能を「サイトトラックバック」と名づけてみたが、いろいろなblogツールで対応すると、記事単位でのコミュニケーションよりも、サイト同士のコミュニケーションの方を好むコミュニティにおいては、便利に活用されるようになるのではないか。ひとまず今自分で作っているblogツールには上記のような機能を搭載する予定。

_ 今日のスポクラ (14:54)

マシンの負荷＋回数をちょっとずつ増やし中。今までは後に残らないように標準負荷設定×10回×1〜2セット（持ち手が2パターンあるマシンは両方やる）でやっていたんだけど、それだと楽すぎるものは負荷を＋1するか、回数を20回に増やすかしてみた。でもやっぱりそうすると結構後まで残るなー。筋肉の量ではなく速度が欲しい場合は、負荷軽めで回数を多くした方がいいんだっけ？　バイクは100W20分。本を読みながらやると時間が経つのが早いな。今までは考え事時間にしていたんだけど、バイクをこぎながらだといまいち脳みその回りがよくないから、本を読んで時間をつぶした方がよさげ。

_ Smartyのエスケープ (15:07)

「[PHP] Smartyとサニタイズ」で、なんかデジャブのような展開を見かけたんで、結局俺はどう対処することにしたのかを書いておく。なんか不便なことが多すぎるんで、default_modifiersを使うのはあきらめ、modifier.h.phpという以下の内容のプラグインを追加して、それでエスケープするようにしている。

function smarty_modifier_h($string)
{
    return htmlspecialchars($string);
}

このプラグインを用意しておけば、{$foo|escape}を{$foo|h}と書ける。このくらいならばそんなに面倒じゃないから、書き忘れも減るんじゃなかろうか。modifier.h.phpの内容はもともとのescapeをコピーして使ってもいいけど、実用上はこれで十分。シングルクォーテーションもエスケープしたい人は、ENT_QUOTESをつけておけばいい。