blog.ishinao.net

mb_convert_variables (17:00)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

今日は (13:32)

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

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

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