2003年10月の技術日記

最近、口内炎が頻発して痛い。ポテトチップスを食べると口が切れる。知り合いの歯医者さんに相談すると、「今健康を犠牲にしても、あとで健康を取り戻すにはその数倍のお金と苦労がかかるから、身を削っても無駄だ。ちゃんと寝て3食食べるべきだ。」と言われた。今年から、健康に気をつけようとキーボードや毎日使うものに多少お金をかけてみたのだけれども、そういうことではないらしい。

ALAN-K (Advanced Learning Network in Kyoto) の講演会に潜入。前からあったアイデアが、なんとなく形になってきたような気がする。

よく言われるのは、何処の職場でも何かしら人間関係のトラブルはあるということ。
例えばある保育園を仮定した、以下のような典型的な上司とのトラブルを考える（もちろんフィクション）。

ケーススタディ

• 上司とA氏の2人クラス
• 上司は約10歳上の自称ベテランで、自分には間違いがひとつもなく、最高に仕事ができると思っている。
• A氏は入社４年目、一通り仕事できるけど周りからはまだ新米扱い。
• 上司は担当の子ども（約２歳）をいつも怒鳴る。子どもが泣き出して逃げようとしても、拾い上げて無理やり泣き止まそうとする。まだ小さいというのに、とても子どもを大事にしているように思えない。
• かわいそうなので逃げてくる子どもをあやしていると、「そんなことをしたら、全体が乱れる。ちゃんと考えろ。」と言われた。「貴様の存在自体が邪魔だ。」という発言もあった。
• つまり、子どもが懐かないのはA氏が甘やかすからだと思っているらしい。ちなみに、2歳児はそんなに叱って厳しくしつけるような年齢ではないという考え方が一般で、むしろそういう行為は虐待に近い影響が後に残るのではないかという研究結果があるらしい。
• 意見を言っても聞いてもらえない。どんなに非効率でも、自分が最初に思いついた方法を固持しようとする。
• しかも、その仕事は必ず人任せ。どんなに大変でも手伝おうとしない。「自分には責任という大変な重荷があるから」と、さっさと家に帰る。
• さらに、言っていることが時間ともにどんどん変わる。言われた通りに非効率な作業をやっていると、「おそい、違う」と叱責された上に訂正される。
• 「さっき〜と言いましたよね」と言い返すと、「よく考えろ。臨機応変だ。」と一蹴される。
• それではと、自分なりの方法で仕事をすると、「余計なことはするな。どうせ出来ないのだから、言われたとおりにやっていればいい。」とまた叱責される。
• 矛盾を指摘すると「屁理屈を言うな。貴様は保育に向いてない。」のようなことを言われる。
• 保育日誌等の文書を提出すると、漢字を平仮名に直せといわれる。
• 簡潔に書けといわれたので、保育者なら当然知っているだろうと思われる専門用語を多用したら理解してもらえないうえに、「分かりやすく書け」と言われる。
• どうすればいいのかと聞くと「自分で考えろ。臨機応変だ。」と言われる。
• それではと、自分で考えて企画してみると「それはダメだ。どうせ一人では何も出来ないんだから何でも聞け。」と言われる。
• 上司の書いた文書の、自明な間違いを指摘したら何故か怒鳴られた。
• 就業時間後、自分の仕事が終了したので早く帰ろうとすると嫌味を言われる。もちろん手伝えそうな仕事は既に無く、上司は単に無駄な時間を過ごしているように見える。
• どうも言葉の節々から「残業する人＝できる人間」という思い込みが感じられる。
• その割に、子どものお迎えが遅いと文句を言う。「貴様の会社は5時に会社終わるんだから、5時10分には迎えに来い。」早く仕事を終えたいらしい。
• イベントの為の大道具を作れと上司が言い出した。上のようなこともあったので、図面に寸法も書いて確認した。忙しい中、家に持ち帰って丸2日かけて完成。上司に見せるなり「違う」。どうも思い描いたものと違っていたらしい。「これでは使えない。ちゃんと考えろ。臨機応変だ。」結局さらに3日かかって修正した。もちろん上司は手伝ってくれない。
• 職場はこのような上司が複数いて、しかも多数派である。
• 以下際限なく続く・・・

あからさまに自分の失敗なのに「よく考えろ、臨機応変だ。」と簡単に責任転嫁してしまう辺り、さすが自称ベテランだけのことはある。こういう上司は何処にでも出没するらしいので、この文章の単語を適当に入れ替えることで汎用的に利用することが出来そうだ。もう一度繰り返すが、これはフィクションである。

普通に読むと、吐き気を催すほどの最低な上司ではあるが、果たして一体どう対応すればいいのか。とりあえず、理系的な解を考察してみた。

守破離

学問や技を習う道理に「守破離」というものがある。少林寺拳法などでは拳の三訓として知られている。「守」は先生の言われたとおりに基本を学ぶ。「破」はその基本を自分に合うように最適化させる。「離」はその基本を元に自分独自の理論を発展させる。というものである。

この道理に従えば、不満や疑問は置いておいて、まずは上司の言う通りにやってみよということになる。確かに、出来もしないうちに、あれこれ不平不満を並べたり、独自の解釈をするのは良くない。基本が身に付いて自分のものになって初めて一人前であり、発言や批判に意味が出てくるのである。また、一見上司はめちゃくちゃなことを言っているように見えるかもしれないが、しばらくして新人を教えるような立場に立ったときに、初めて上司の言わんとしていたことに気が付く、という「親の心、子知らず」ということもあるかもしれない。

つまり、上司は最初から的を得たことを言っていて、上司の説明かA氏の解釈の仕方が悪いために、A氏は「とんでもない上司だ」と誤解してしまった可能性がある。もし真実はこうだとすると、今回のケースの表現は甚だ不公平であり、A氏に非常に偏りすぎた表現であるといえる。A氏に対するアドバイスとしては「世の中最初は誰でも理不尽だと感じるものである。今はとりあえず我慢しておけば、後できっと分かる時が来る。」が適当であろう。

しかし、果たして単にA氏の誤解でしかないのか。A氏の視点からとはいえ、上のケースでは明らかな矛盾もいくつかあるし、責任転嫁、無責任な言動に加え、保育の哲学も怪しい。

改革

上のケースにおいて、深刻な問題は上司よりも職場全体である。本当にダメな上司であれば、トップや組織の評価でふるい落とされることが期待される。そのため、ダメな上司がずっと居座れるような集団は組織自体が腐っている可能性が高い。

一般の企業は業績などで定量的に人を評価することができるが、教育分野では人の評価は非常に難しい。自分は教育現場で一番重要なのは子どもたちに何を伝えたいかという哲学であると考えている。定量的評価が難しい教育現場では、トップの人間や組織全体が何を目指し、どんな哲学に従って動くが唯一の拠り所である。哲学も競争も議論も無いような組織は、何が良くて何が悪いのかが定義できないため、将来腐っていくことは明らかである。

では、そのような腐りかけている組織にいると気がついた場合、どうすればよいか。上から変わることが一番近道であるが、そんなことはめったに起きない。「世の中に不満があるなら自分を変えろ。それが嫌なら耳と目を閉じ、口を噤んで孤独に暮らせ。それも嫌なら・・・」（攻殻SAC01より）と言われているように、おとなしく不条理を受け入れるか、沈黙するか、それとも自ら立ち上がって組織改革への議論を巻き起こすか。

自ら先陣を切って立ち上がるのは非常に難しい。おそらく処方箋は無く、下手に戦いを挑めば大抵の場合は村八分にされて終了しそうである。しかし立ち上がらなければ始まらない。いつも楽しく読んでいるIBMの developerWorks に興味深い内容がある。次の引用は非人間的な職場にXPを導入し、生産性を上げようというもの。XPを導入するには、一見非効率と思える仕事の仕方を職場（顧客を含めたチーム）全体で導入しなければならないため、組織の変革が必要になる。このXP導入の状況は腐りかけの組織の変革の状況と多少似ている。

こうした変化が最上部から始まると言いたいところですが、多くの場合、
そうはいきません。下からの変化が必要な場合もあります。変化を開始させる
方法は、人々が、短期的な圧力から逃れるために上司にうそをつくのをやめる
ことです。
：
物事が変化しない理由はただ1つ、私たちが変更を拒んでいるためです。

エクストリーム・プログラミングの神秘を解く: 考え方を変える(IBM developerWorks)より

さらに以下のように続いている。

Martin Fowlerはこう言っています。「組織を変えることができないなら、
組織を替えなさい。」ほかに、現実的な居場所を見付けてください。

「エクストリーム・プログラミングの神秘を解く: 考え方を変える」(IBM developerWorks)より

ということで、変革の敵は自分自身にもいることを指摘している。しかし、つくづくIBMって夢のような職場なんだろうなあと思う。また、別の記事にも面白い文がある。

■変えるための勇気

すなわち、会社での毎日がひどいもので、いくら努力してもそれを改善できない
場合、会社を去るときかもしれません。しかし、最初の抵抗の兆候が見えただけ
で逃げ出していては、解決にはなりません。それでは、決して逃げられないもの
から逃げようとしているだけです。別の場所に行ってもまた同じような問題に
遭遇し、その新しい場所からも逃げ出すことになります。

必要なのは、... 伝統と習慣に縛られた環境に入ったときでも立ち上がって
真実を訴えることができるリーダーです。

「ソフトウェア・プロジェクトを主導することの意味」(IBM developerWorks)より

問題に気付いているのなら、逃げることは解決にならないと指摘。結局、

最終的に1つの結論に至ります。つまり、給与をもらいながら人生をうまく
切り抜けるか、世界を変えたいと思うかです。

「ソフトウェア・プロジェクトを主導することの意味」(IBM developerWorks)より

分かってはいるんだけども、前者の中で閉じた世界でしか物が考えられない人が多いようだ。

別のIBMの記事。「不真面目な良い社員」という概念がトップや組織で一般的になれば、議論や提案をやりやすくなるのかもしれない。

「不まじめな社員が会社を救う」IBM コンサルタントの眼（google cache）
http://www-6.ibm.com/jp/domino02/bis/ContDB.nsf/2002/06121

知り合いの学校の先生は、以下のような戦略をとって成功しているらしい。

• しばらくおとなしく言うことを聞いておいて、飼いならされたふりをする
• その間、敵をしっかり分析して、改革の戦略を練る
• 人の2倍働いて、文句を言わせないようにする
• ある程度信頼され、一目置かれたところで、反撃を開始する

見るからに大変そうであり、万人にお勧めできそうな方法でもないみたい。

最後に、何度も繰り返すが最初に取り上げたケースはフィクションである。分かりやすく平仮名で書き直すと「つくりばなし」である。

つくづく自分は恵まれた環境に居るのなあと実感する。忙しいけど。

プログラムを初心者に教えるというのは非常に難しい。

開発環境

開発環境のインストールや使い方を教えるのに時間を取りたくなかったので、Eclipse、JBuilderは使わないことにしていた（後で参考程度に教えるつもり）。しかし、WindowsにJ2SDKを入れてエディタで作業というのも非常に難しいことが分かった。

• J2SDKのインストールは簡単に終わる。しかし、何処にインストールされるかが分かりにくい。
• パスを通す方法が大変（口頭や文字で伝えるには複雑すぎる操作が必要）
• コマンドプロンプトでエクスプローラーのディレクトリの対応を理解させるのが難しい（デスクトップが変なディレクトリ階層にある）
• デフォルトで拡張子が表示されない。そのままでは 〜.java というファイルを作れない。（拡張子を表示させるか、いちいちコマンドプロンプトで操作しなければならない。）

分かっている人には何でも無い事にみえる。しかしこれらの作業は、インストーラーの仕事だったり、やOSの特殊な仕掛けによって意図的にユーザーに意識させてこなかったことなので、教える方も聞いている方も非常に違和感を感じてしまう。やっぱりWindowsはプログラムを作る環境には全然向いていないと思った。少なくとも、Windowsが目指しているユーザーに優しい環境と、現在のプログラミングに必要な環境はあまりにもかけ離れている。また、IDEを使うということも解決にならなくて、いつまでもIDEの上でしかプログラムできなくなってしまう。そんな香具師プログラマは要らない。

一方、Linuxのシェル上の操作は一見分かりにくいので大変かと思っていたのだけども、すんなり理解してもらえた。変な情報隠蔽などをしていないので単純だからだと思う。

結局、LinuxにJ2SDKを入れて、puttyでログインしてもらい、シェル操作・コンパイル・実行をターミナル上で行い、sambaでファイル共有することでWindowsのエディタを使うという、両方のいいところを組み合わせた。もっといい方法もあったのかもしれないが、低級な多少使いにくい環境から始めて、自分で環境を工夫して使いやすく努力してもらうということも期待したつもり。

変数

途中までは箱モデルで上手くいっているよう思った。でも箱の比喩ではコレクションクラスが上手く説明できないというか、ややこしいことに気が付いた。配列は「たくさん入れれる箱だ」でとりあえず説明できた。でもListなんかは「箱の中にListのインスタンスがいて、そいつがインスタンスを出したり入れたり・・・」。上手く説明できるようになるのが先か、聞いているほうが変数の概念をマスターするのが先か。

変数の箱モデル

• 変数の宣言はメモリを確保すること
• 変数へ代入されるデータのサイズが、型によって異なる

でもこれらは、「箱」より「メモリ」の方が初心者に対する説明で優れているという根拠にならない。オブジェクトのリファレンスも「インスタンスの先頭アドレス」と説明しているので、実質的に箱モデルで問題なく表現できるはずだと思う。メモリの確保は「箱の用意」、データのサイズは「箱のサイズ」で十分だと思うし、それでいけない理由も示されていない。

結局、箱モデルが分かりにくい理由は以下らしい。

私には、変数の説明をするのに、なぜ「箱」が出てきてしまうのかよく分かりません。新しい概念を身に付けるのは大変なことですので、「箱」という「例え話」を使うという発想は分かるのですが、「変数」はプログラム言語特有の概念でしょうか？ 義務教育を終えた方ならだれでも理解できるはずのことを、「変数＝箱」という例え話がかえって分かりにくくしてしまっているように思えます。

いまから始めるJava　第2回「Javaの変数の本質を知る」(@IT)

つまり、小中学校で「変数」を習っているのだから、わざわざ箱を持ち出すのは話を難しくしているだけだということらしい。しかし、学校で習った変数では「x=x+1」が理解できない。だから数学的な変数ではなくて、単なる数値の入れ物として「箱」が出てきたはずだと思う。Rubyだったら「値に名前を付ける」ことでかっこよく変数を理解できるらしい(from Matzにっき 箱モデル, 箱モデルの逆襲, 箱モデルの再逆襲)のだけども、Javaはやっぱり箱しかないのかな。

たぶん、上の記事を書いた人にとってはメモリモデルがわかりやすかったのかもしれない。一方、今回の対象者のように初めてプログラミングを始めるような人に、

「int a;」という文の本当の意味は、コンピュータ内のメモリのうち、4bytes分を確保し、以後ソースコード中で「a」と呼ぶことにするとコンパイラに対して宣言することです。

いまから始めるJava　第2回「Javaの変数の本質を知る」(@IT)

ということを説明するはとてもコストがかかりそうだと思った。

オブジェクト指向

しかし、Javaはそこで終わると意味が無いので、継承やポルモリフィズムの例をさせてみる。すると、簡単な例では実用的でなくて面白くないばかりか、処理の流れが激しく飛び回ってしまうのでソースを読むのがめんどくさくなり、多少やる気が落ちてしまう。コンストラクタの初期化順序は分かりにくいし、ポルモリフィズムなんかは簡単なプログラムでは自作自演になってしまうので、存在意義を説明するのも大変。

でも、GUIやオブジェクト指向の面白いところはそのあたりが肝心なので、ペース配分とか、上手い例を探すのが重要なのかなという気がした。

次はやっとGUI周りに行けそう。

C++のfriendについて、oosquare-mlで議論が行われている。

friendが無ければ、オブジェクト指向の情報隠蔽で重要なアクセスの制限が細かく出来ないから、JavaはC++よりオブジェクト指向的とはいえない という意見が出た。オブジェクト指向らしさの定義は専門家ではないからよく分からないのだけども、個人的にはfriend指定がクラス間の結び付きをだらしなくさせてしまう弊害があるように思う。また、friendしなくては困るような設計やパッケージ区切りはそもそも問題があるような気もする。

とりあえず議論が落ち着くまで静観してみる。

議論が別の方向に向かって白熱し、Java vs C++ 、ポインタ論争などの話題でついに1日50件の流量に。不毛な議論で終わるのはもったいなかったので控えめに参加。いくつかの質問をすることで、新しい知見を得た。

• C++ では情報隠蔽はヘッダファイルの制限でも行うことができる（なので、friend指示でしか選択的隠蔽が出来ないわけではない）
• インスタンスの内容保証というカプセル化の原則に従えば、アクセスの細かな制御はカプセル化に有効に働く。そういう意味で、細かなアクセス制御ができる言語はオブジェクト指向度が高いといえる。（ただし、C++とJavaの比較については自明ではない）

議論ままだ続いている。

オブジェクト指向に限らず、プログラミングで扱う目に見えない抽象的な概念を教えようとするときに、現実世界のモノを比喩に出すことが良くある。つまり、身近な具体例で理解を助けようというもので、変数には「箱」、継承では「動物」や「社員」などが良く用いられる。

「動物」の比喩はオブジェクト指向の継承やポルモリフィズムを説明する時に用いられ、大抵「動物」クラスを「犬」「猫」が継承して、ポルモリフィズムで「わん」と「にゃー」と表示させるものである。かなり多くの入門書で見られ、実際に自分もこういう説明で勉強した記憶がある。そして、今回教える時にも使った。

しかし、このような比喩に対して痛い批判をする人が少なくない。口頭で何度か聞いた記憶もある。例えばWebで適当に検索するといくつが出てくるが、痛そうなところを引用してみる。

どうしてこういう例え話が出てきてしまうのか、私にはさっぱり分かりません。クラスの概念を哲学用語か何かのように説明するのはいいかげんやめにしてほしいものです。

いまから始めるJava　第4回「クラスの継承の本質を知る」 (by @IT)

「現実世界のモノをオブジェクトとする」なんて言われても何がなんだかわかりませんし、「哺乳類を継承して犬と猫を作り、『鳴く』というメッセージを送ると犬なら『わん』、猫なら『にゃあ』と鳴く」なんて 謎のたとえ話をされても困ります。

疑りぶかいあなたのためのオブジェクト指向再入門（はじめに） (by 前橋和弥氏)

どちらのサイトも、単なる批判ではなくて、別の方法で分かりやすく説明しようという努力を行っている。それだけに、嫌悪感を抱かせるようなこのような表現は残念だと思う。

「いまから始めるJava」では「動物」ではなくて「テレビ」を槍玉にあげているが、現実世界を比喩に持ち出すのはダメだという点で本質的に同じである。以下の点でテレビの比喩は我慢ならないらしい。

• テレビ型やカラーテレビ型クラスを作るJavaプログラマなどいない（プログラミングに関係ない話は用いるべきでない）
• プログラムがどのようにメモリを使うのかという視点が抜け落ちる

「箱モデル」でも出てきたけれども、確かにメモリまで意識できれば理解は深まるとは思うが、必須な知識ではないし、後で知ればいい概念だと思う。さらに、「疑りぶかいあなたのためのオブジェクト指向再入門」では以下のよう。

• プログラミングとかけ離れた比喩を用いた説明は、分かっている人にしか分からない（にちがいない）
• 現実世界をそのままモデリングすればよいという誤解を生む

現実世界とオブジェクトの世界のギャップは確かに重要で、初心者にとってこの微妙なずれがクラス設計をする時の壁になっていることは良く知られている。

上の主張にもあるように、大抵このような主張はプログラミングと関係ない話は、プログラミングの話に戻ってくるときに混乱するので分かりにくいとなっている場合が多い。

これらの主張は教える相手が技術者の場合は正しいと思う。実際に、「いまから始めるJava」では継承がメモリの確保で説明されているし、「疑りぶかいあなたのためのオブジェクト指向再入門」ではC言語の延長としてどう理解するかを述べていることから、どちらもある程度の技術者を対象にしている。自分も、FortranやCをやったことのある人に教えたときには、変数や構造体の説明から始めたことがある。コンピューターの中で何が行われているかが既にイメージできている場合は、この方法で教えるとプログラムを作れるところまで素早く理解するようだ。むしろ、「動物」だけで教えようとすると、上で指摘されているように、「比喩のイメージ」と「既に技術者の頭の中に構築されているコンピューターの動作イメージ」の間にギャップが生じて混乱が生じる場合がある。

しかし、この方法の場合、オブジェクト指向言語でプログラムを作る方法が理解できただけなのに、全てを理解したと勘違いしてしまう場合がある。誰にでも始まりはあるので、最初はオブジェクト指向らしいプログラムが出来なくても仕方がないけども、そこで学習が終了している人が数多くいるかなと感じる時がある。（もちろん、自分もまだ修行が足りないので、自分が何でも理解しているというつもりはない。）

一方、相手がプログラミングの全くの初心者で、いきなりオブジェクト指向を教える場合は「動物」や「テレビ」の方が有効であると思う。プログラミングの初心者にメモリやC言語の話をすることは難しいし、それこそ教えたいことと直接関係ない話を長々としなければならない。むしろ、初心者にはまだコンピューターの動作イメージが形成されてないので、分かった人がイメージしているようなオブジェクト指向動作イメージを直接植え付ける方が自然であると思う。

そんな説明では一生プログラムが作れないという主張もあるが、広く動物が比喩として用いられているのは、全く的外れなことではないからではないだろうか。初心者はすぐに動くプログラムを作るのは難しいかもしれないけども、「ゼロからのC言語学習時間」＋「C++への移行時間」は、「ゼロからのC++学習時間」とそんなに変わらないのではないかと思う。つまり、C言語の学習時間やC++への移行時間程度で、動き出すプログラムがすぐに作れるようにならないからといって、あせらなくてもいいのではないかと。

また、動物の比喩だけに留まらず、実際に動物クラスのプログラムを作ってしまうことは全く無駄ではないと思う。無駄だと思っているのは、動物クラスで示そうとしている以下の目的を忘れているからだと思われる。

• 動物の比喩を具体的にコードで示すことで、頭の中のクラスのイメージをコードに落とし込むひとつの方法を示す（一般的な方法ではなく、あくまで最初の例として）
• 身近で理解しやすい概念を用いて、プログラムがちゃんと動いたかどうかを直感的に理解させる

これらの目的は自分が考えているものなので一般的ではないかもしれないが、少なくとも自分はこのような目的で例題をプログラムさせている。動物クラスは十分目的を果たしていると思うけども、もっといい例があればそれを採用したいと思う。

ということで、動物が嫌なら別のものを示し、目的に合わなければ身近なモノを使った説明を採用しなければいいだけのことである。教育に唯一絶対の解は無いし、よりよい方法を求めて問題提起や議論を行うことは重要なことである。にもかかわらず、

こんな説明を読んで、なんだかわかったような気分になれる人は、どっちかというと思考力に欠ける人なんじゃないかと思います。「わけわからん」という反応のほうが技術屋としては正常でしょう。
いい加減、こういうわけのわからないたとえ話はやめたらどうかと。

疑りぶかいあなたのためのオブジェクト指向再入門（いい加減、わけのわからない「たとえ話」はやめよう）

のように、一方的にそのような説明をする人の人格まで否定するような表現は乱暴すぎるではないだろうか。と思うのだけども、経験が少ないので説得力がないのかもしれない。

先日、無線LANのカードを抜くのが面倒くさかったので、そのまま出かけてタクシーに乗った。タクシーで仕事をしている最中に、ふと war driving のことを思い出してメルコのクライアントマネージャーで受信可能なアクセスポイントを表示させてみた。結果は驚くべきものだった。福岡の某中心街を抜ける間の15分間に、暗号化無しのアクセスポイントが数十個表示された。しかもそのほとんどがデフォルトのESS-IDだった。多いというのは聞いていたが、こんなに多いとは思っていなかった。以下の参考サイトはもっとすごいことになっている。

※参考：Network Stumblerで無線LANを探そう

最近良く議論される、著作権や特許等のメモ。

著作権

ソフトウエアも紙に印刷すれば表現とみなすことができることから著作権で保護される。

参考：社団法人著作権情報センター

自分の知っている範囲で、話題や議論が起こっているのは以下の辺り。

• 音楽・映像業界の海賊版・コピー、ファイル共有等による損害と反撃
• アメリカのDMCAという、何にでも攻撃できそうな著作権保護法
• 著作権保護期間の延長（ディズニー）
• リンク・ロボット検索・機械的要約等による、Web上の技術と現行法のギャップ
• クリエイティブ・コモンズ周辺の人々による、デジタル技術を念頭においた著作物利用ライセンスの提案

上のトピックが示しているのは、デジタル技術の進歩と浸透によって今までの著作権の法律が想定していなかった事態が起きているということ。とりあえず、法律による悪人取締り的な対処療法は問題が多いため、根本的な問題の縮小の為にはやはり一般市民への著作権に対するモラルの向上を目指す方がいいらしい。

「人の物を勝手に取ってはいけない」と同じくらいに、「人の表現を勝手に使ってはいけない」ということが感覚的に分かるようになれば、法律でがちがちに固めずにもっと自由に創造を行うことができる世界になるのかな。

特許

特許の主な目的は以下のよう。

• 権利保護して発明を奨励する
• 発明の技術を公開して、社会全体の技術向上を目指す

つまり、金儲けをエサに発明を奨励させ、科学技術の向上をめざそうというもの。

「科学的に一見思える」と書いたのは、お茶の水大の天羽氏のサイト水を理解するためにの科学知識の情報源について考える・特許 に書いてあるようなことから。

ソフトウエアは、不可欠な装置の一部としてや、記録媒体に書き込んだ装置として、特許が認められている。参考サイト：ソフトウエアと特許 (by 弁理士 古谷氏)

今のところ、ソフトウエアの特許は絶対悪だという風潮がフリーソフトウエア勢力の中で大勢を占めていたが、最近はより現実的に現行特許制度の中でどう戦うべきかという声も広まってきている。参考サイト：ソフトウェア特許について考える(by 高林氏)

以下は自分がちょっと考えてみたメモ。

一概に悪いかどうかは分からないが、「存在しない方が良い」＝「悪」と定義してみて、特許の目的を出発点にして考えてみる。参考情報：エリック・レイモンド　オープンソースの解剖学四部作(by 山形浩生氏訳)

特許の目的の考察

独占的権利による発明の奨励

・特許による独占的権利は、企業にとっては重要

・一方で、フリーソフトウエア界では、無償でソフトウエアを配布していることから、そんなにお金儲けは重要ではない

・ハッカーの発明（開発）に必要なことは、他人からの評判と、実世界でのある程度の生活の保証

・全ての技術が企業によってもたらされているのなら、企業が特許の独占的権利を振り回していても誰も文句をいわないと思われる。

・しかし、多くのソフトウエア技術革新はフリーソフトウエアによってもたらされており、またハッカー達は今後も技術の利用は自由であって欲しいと願っている。よって、企業の独占的権利によって自由な開発が出来なくなるとしたら、フリーソフトウエア界の反発は必至。このまま資金を持つ企業側に一方的に有利な特許の制度が続けば、フリーソフトウエアによる技術革新は減少していくと思われる。

→結局、企業とフリーソフトウエア界のどちらがより効率的に技術革新を行えるかという問題に帰着する

発明の技術公開について

・インターネットの歴史から、ソフトウエアの技術は自由に公開・利用することで急速な発展を遂げた

・ソフトウエアは社会全体の財産であり、自由に使えるべきであるという文化が根付いている

・このフリーソフトウエア文化が続く限り、特許にしなければ技術が広まらないということはないと思われ、技術公開の目的の為には特許は必要ない。

・むしろ近年はソフトウエアの特許が標準技術を脅かしたり、トラブルの元になっていることが多い

→ソフトウエアの特許は、今のところ社会全体の技術向上という目的に必要ない

特許流通付近での産業育成

・マテリアル的な産業とソフトウエア産業の相違点を考える

・【相異点1】ソフトウェアは複製コストがゼロ、ネットワークを使えば流通コストも限りなくゼロなので、マテリアル産業ほど大きな投資が必要ない

・【相異点2】低コスト、自由参加の分散協調体制で高性能なソフトウェアの開発が可能

・【相違点3】ソフトウエアは社会全体の財産であるという文化がある

・以上から、企業の開発したパッケージソフトと競合するフリーソフトが生まれ易く、またインターネットを介して簡単に流通させることができる

・特許は投資であり高額な資金が必要である。資金を持つ企業にとっては何も問題はない。資金を持たないフリーソフトウエア開発者は、特許を取得することがほとんど出来ないばかりか特許をめぐって法廷で戦うことも出来ない。そもそも、フリーソフトウエア開発者には特許を取って金儲けをしようという意思はほとんどない。お金が無ければ発明をしても無駄であるという状況は著しく不平等であるといえる。

→今までの特許制度は、あんまりソフトウエアの流通付近での産業の創造・育成に与しないよう。逆に資金の少ない人の参入が難しくなる。

以上から、フリーソフトウエア界の開発能力が企業のものより優れているならば、ソフトウエア特許は無くても特許の目的は達成できるのではないかと思われる。こう考えると、フリーソフトウエア界から悪だと言う声が上がるのは当然のことといえる。

企業とフリーソフト開発の違い

＊企業

• マーケティングに基づき製品企画
• 先行技術、特許を調べる
• 必要な技術開発を行う→特許申請
• 必要な特許ライセンスを取得する
• 販売

＊フリーソフトウエア開発者

• 何か必要に迫られる
• 解決できそうなソフトを捜す
• 無い、足りない、高い場合は開発
• 少しでも他人の役にたちそうなら公開
• 特許について徹底的に調べる人もいるが努力は不充分

つまり、フリーソフトウエア開発者による、他社の権利を侵害するような安易な公開がトラブルの原因である。

しかし、大きな投資を行わなければ流通させることが難しかった昔と違い、ソフトウエア（や音楽・映像などのデジタルコンテンツ）は簡単に公開して世界中の人々と共有することが可能である。むしろ、この利点を生かしたビジネスのあり方を考えるべきではないかと思う。

例えば、多くの企業がLinux開発に資金や技術を提供しているし、多くのオープンソース周辺の企業はフリーソフトウエアを用いた「ソリューション」を提供するという方法でビジネスを行っている。また、アップルは音楽データをオンライン上で安価に販売することに成功している。

参考情報：

• 「『オープン』の正体 （上）（下）」 (by @IT)
• 末松千尋・オープンソース戦略を探る
• iTunes store: 1週間のダウンロードが100万曲を越える (CNET Japan)

どうするべきか

現在の雰囲気は「ソフトウエア特許は無くすべきだ」という意見が一般的であるけれども、やはり現実的にはすぐに法律を変えることは難しい。ということで、以下のようなところで議論が行われているように、やはり現行の法律の中でまずは素早く対策をとることが先決であろう。具体的には、要注意特許リストの作成、防衛特許の取得、何らかの情報公知システムの確立、特許版GPLなど。

議論など：

• irc にてなど (by 松田氏「汚し飯」)
• 特許と著作権など (by まつもと氏)
• Tea Room for Conference:1596など (by office氏)

個人的には両方の立場にいるので、なんとも微妙。Webで情報を公知したらそれでいいみたいな仕組みになってくれればありがたいかなと思う。

何を書きたいのかわからなくなってきた。メモなので、そのうち誰かが少しまとめてくれるといいかなと期待してみる。

無線LANアクセスポイントが不調。AirStation Q&Aによると、不良電源アダプタが原因らしい。とりあえず、交換の申し込みをする。買ったばかりのときにすぐ壊れたので交換してもらったのだけども、電源アダプタについては交換してもらってなかったのかな。

有線通信用にLANカードを入手。それにしても無線も有線もLANカードはとても安くなったものだなあと思う。

Mew でHTMLメールを表示させる時に使っていたけども、古かったのでバージョンアップ（emacs-w3m-1.3.6）。ついでに、namazuのインタフェースもできるように設定を修正。

参考：

• Emacs 上で w3m を動かそう
• テキストブラウザ ― emacs-w3m

他の機能も見てみると非常に便利だということも分かった。
M-x w3m-weather による天気は見難いけども情報量が多くて良い。

;;==================
;; W3M
(autoload 'w3m "w3m" "Interface for w3m on Emacs." t)
(autoload 'w3m-find-file "w3m" "w3m interface function for local file." t)
(autoload 'w3m-browse-url "w3m" "Ask a WWW browser to show a URL." t)
(autoload 'w3m-search "w3m-search" "Search QUERY using SEARCH-ENGINE." t)
(autoload 'w3m-weather "w3m-weather" "Display a weather report." t)
(autoload 'w3m-antenna "w3m-antenna" "Report changes of web sites." t)
(autoload 'w3m-namazu "w3m-namazu" "Search files with Namazu." t)
(setq w3m-namazu-index-alist
      '(("mail" "c:/..(namazuのインデックスへのパス)../")))
(setq w3m-weather-default-area "福岡県・福岡") ;福岡の天気
;(setq w3m-type "w3m") ;これが無いと上手く起動しなかった

コンピュータが2台以上ある場合、キーボードをずらずら並べるより1つのキーボードとマウスで全部操作できるとスペースが省略できてかなりうれしい。

右側のマシン：OSはWindows2000で、このマシンでUltr@VNC (日本語パッチ) を動かしてVNCサーバーにする。

左側のマシン：OSはLinuxで、このPCにマウスとキーボードがつながっている。このマシンで、 x2vnc を以下のコマンドで動かす。

% x2vnc -east -hotkey c-F8 -scrolllines 3 (target host)
  -east : 相手マシンは右側にいる
  -hotkey : 相手のマシンにマウスがいるときにCtrl+F8を押すと、こっちのマシンにフォーカスが戻ってくる
  -scrolllines : ホイールのスクロール量

左側のマシンがWindows系の場合は、Win2VNC (日本語パッチ) を使う。

この方法ではOSが違うのでもちろん画面間のウインドウの移動は出来ないが、クリップボードの共有はできる。OSも問わないし、置き場所が解決できればいくつでもつなげられそう。さらに、CPUがそれぞれ動いているので、一方で重いタスクを実行しながら、一方で別の仕事をするなどのスムーズな分業を行うことができる。使っているうちに、この2台が別のマシンであることを忘れてしまう。