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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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