祈祷連歌

「まるで神が降りてきたかのように」（行動記録／日記）

◇ ◀ ▲ ▶

この１週間ほどは異常に集中して仕事していた。 ここしばらくはここまでテンションが上がったことはなかったように思う。 とくにこの金曜の夜から火曜の明け方までの３日間半で、 途中半日程用があって中座したのだが、 ふつうだったら３週間分ぐらい捗ったのではないだろうか。

別に納期が迫っているとかいうことではなかった。 なにかわからないけど異様に調子が乗ってしまったのだ。 そのかわり身体中のエネルギーをすべて絞りだした感じ。 さすがに昨日の晩は墜落型の睡眠だった。 今日は夜からOOEnkaiなのでタイミング的にはちょうどよかった。 このモードを維持する条件に変なふうに中断しないというのがあるからだ。

２０代のころはけっこうしばしばこういう状況になれたものだが、 ３０代に入ってからはだんだんそういうのが減り、 ４０に手が届きそうないまでは半年に１度あるかどうかという感じである。

あまりからだに無理をかけすぎのも考えものではあるが、 こういう状況を意図してつくる方法というのはないものだろうか。 多少は怪しいのでもかまわないのだが、なにかスイッチを入れたように そういうハイコンセントレーションモードに入れるようになる良いのだけど…。

「宴会『カサベリア・隠れ家』」（OO百韻）

◇ ◀ ▲ ▶

今回のオフは新宿歌舞伎町のスペイン料理屋カサベリアで１９時から。

前々回これなかったJunさんが、はるばるボストンから来日して参加。 来日の目的は表向きはビザの更新、実は学生の勧誘と日本酒の密輸。 以前から学生に誘われてはいたのですが、詳しく話を聞くたびに心が動く。

今回はちょっと飲み過ぎてしまって二日酔い状態。だけどみなさんは飲み過ぎ。 いかすみのお焦げご飯が美味しかった。

２３時ごろ石井さんがダウン。脈が弱くなって脂汗を流していてちょっと心配でしたが、店長曰く全然大丈夫とのこと。 看病役組と２次会組に分かれて、２次会組は隠れ家へ。 後に呼び出されたいるかさんが合流した看病役組は石井さんをタクシー送りにして 隠れ家へ。

ひがさんが２ちゃんねるで悪口を書かれて落ち込んでしまったが、 原因はどうやらいるかさんに怨みをもつ人間がやつあたりをしているのではという話とか、 木村さんはもうちょっと腹に力をこめて声をださないといけない話とか。

途中抜けた人がいるも、ほとんどは始発まで粘りました。 そういえば、FPROG時代のOOOFFでは、Junさん、小林さん、へげもんさんの３人のうち２人が揃ったときはいつも朝までやりましたね。 そのパワーはいまだ健在。

「身体検査」（行動記録／日記）

◇ ◀ ▲ ▶

昨日のOOEnkaiに行く途中、新宿のサブナードを歩いていたら、 突然後ろから肩をたたく人が。

もしかしてOOEnkaiに行く途中の人かなと思って振り返ると、お巡りさんでした。

曰く、刃物を持っている人を警戒中なので身体検査させてくれ、とのこと。

素直に応じたら、どこからかもう一人のお巡りさんがいつのまにかでてきて、 二人にはさまれて、ボケットの中身をはじめとして、 腰にぶら下げている鞄みたいなやつの中身まで全部だしたりして、 かなり徹底的に調べられてしまいました。

１５センチのアクリル製の物差しをみて、これはなにに使うのかとか、 えらく間抜けなことを聞くし(あれが刃物に見えるのか？)、 しゃちはたの認め印は蓋を開けて本当にしゃちはたかどうか試してみるし(もしかして護身スプレーかなにかだと思った？)、 鞄のポケットをなかをほじって 隠しポケットはないかとか１０分ぐらい調べられてしまいました。

あの界隈なら、お巡りさんが警戒してくれるのは大歓迎なのですが、 公衆の面前で突然刃物を振る回すような危険な人物にみえてしまったの だろうかと思うとちょっとめげる。

「ネット不通と接触不良」（行動記録／日記）

◇ ◀ ▲ ▶

今日の１０時ごろの話。 これから客先へ出かけようというのに、インターネットがダウンしてしまってメールチェックができない。 しょうがないのでそのままほっておいて出かけたのだが、帰ってきたら直っていた。

プロバイダーの障害情報をみるとどうやらＮＴＴのせいである、と。 で、ＮＴＴのサイトをみてみたら、Ｂフレッツとフレッツ・ＡＤＳＬは９時半ごろから １１時過ぎまで不通であった、と。 うちのルーターのログをみると“Session Table Full.”だそうで、これが１秒間に ２０～３０回ぐらい発生していた。どういうことだったのだろうか。ちょっと興味がある。

出先では打合せなどをしてそのあと、 ちょっと高速度カメラの様子がおかしいのでみてくれとのこと。

データのプレビューはできるのだが、保存ができない。 カメラのソフト側の設定を見直してみたり、 いろいろ調べてみるが全く解決の糸口が掴めない。

そういえば、開発中何度か熱暴走してたな、などと思いだす。 最大性能だと１秒間に１万枚の画像がとれるやつなのだが、 １万枚のスピードにするときには２０分以上連続して使ってはいけないと注意書きにあった。 あまり早くするとＣＣＤのスキャンラインが熱で飽和して画が飛んでしまうので、 連続使用ができないわけだ。 現場では実際には数百枚のスピードでしかとらないので、 スペック上はいけるはずなのだが、開発中の経験則では実際には１ヶ月の間に １０～１５回ぐらいは熱暴走していた。

今回も熱暴走だとやだなと思って、おかしくなりはじめた状況を聞いてみると、 別にそんなに長い間使っていたわけではない。 今日も同じ障害は発生しているのだが、１０分ぐらい前に起動したばかりだ。 １時間ばかりいじってもらちがあかず、 こりゃなにか新たに熱対策をしないとダメかなぁ、などと思い始めたのだが、 基本に戻って電源周りから順番に調べなおした。

するとカメラのコネクターがぐらぐらじゃないですか！！！

螺がちゃんと締まってない。３５０万円もする高速度カメラになんてことを！！！

これって年間の生産量はたかが知れてるんですよ？　壊したらしばらく実験はお預けに なっちゃうんですよ？

結局、なんか移動かなにかをしたときにはずして、ちゃんともとに戻さなかったみたい。 コネクターが半分抜けていて接触抵抗が大きくなってしまっていたのでしょう。 プレビューはフレームを間引いてせいぜい１０ｆｐｓぐらいでしか撮ってないので影響が なかったけど、ちゃんと撮る時は同期信号かなにかのインピダンスが高くてデータがとれなかったというあたりが原因のようでした。

患者のデータは１セット失ってしまったが、 治療のためではなく研究材料のデータだったのでとりあえずはお咎めなし。 解決してよかった。

今日はハードのトラブルの日なのだろうか。もうなにもありませんように。

「MIMEヘッダーにあるX-IPとは何？」（行動記録／日記）

◇ ◀ ▲ ▶

とくに１０月に入ってからスパムが激増している。 PerlのスクリプトでReceivedフィールドをみて、 ブラックリストと合致したメールはヘッダー部分だけ記録して 問答無用でメールボックスから削除しているのだが、 はっきりいっていたちごっごできりがない。

ここ１ヶ月では毎日平均して１６通がこれで削除されていて、 明らかにこの半年ぐらいでは徐々に増加傾向にある。 そして３日に１度くらいのペースで新たに数個のエントリーが、 １０月に入ってからは毎回１０個づつぐらいのエントリーが追加されている。 ただ、追加したエントリーの個数と削除する個数の増加を考え合わせると、 実態としてつぎからつぎへと新たなIPが追加されているだけで、 ブラックリスト方式でやるのは無理がある。 当初はIPアドレス単品の登録だったが、最近ではwhoisで調べて２～３回同じレンジの IPから受け取った場合はそのレンジ全体を登録しているが、 毎日律義に数通つづ送ってくる一部の常連以外は、 あまり効果はでていないようだ。

で、なにか共通点はないものかとみていて気がついたのがX-IPフィールドであった。最近のスパムのヘッダーによくみるX-IPフィールドとはいったい何なんだろうか？

Xで始まっているので、基本的に勝手につけていいフィールドであるはず。 フィールド名はIPとあるし値ももろIPアドレスなので、 そういった意味なんだろうが、 いまいちどういう意図のフィールドなのか判断に苦しむ。 whoisで引いても存在しないはずのレンジのアドレスだったりして、 どういう規則によってつけられているのかがわからない。

いまのところ、受け取ったメールのなかではスパムにしかこのフィールドはないようだ。 当面の間は、このフィールドを持つメールはとりあえず候補として記録して メールボックスからは削除してしまう設定にしてみようと思う。 だけど大事なメールを削除してしまうのはこわいなぁ…。

「あがる」（OO百韻）

◇ ◀ ▲ ▶

ライトニングトークが終わった。 人前で話すのが久しぶりだったためか、 あがりまくって５分のタイムオーバーになり、かなりぶざまな感じ。 マイクを奪われて最後の１ページができませんでした。

人に助言されて背広を着ていったのが敗因だったか？

お題目「ソフトウェアパターンと形式化」の資料はhttp://www.mediaware.jp/yuntanach/cs/archive/SoftwarePatternAndFormalization.pptにあります。べしゃり５分で１１ページ程なので内容はほとんど無いに等しいかもしれませんが、興味のある人はご自由に。

「My Definition of 生産性」（OO百韻）

◇ ◀ ▲ ▶

他の人の日記とかメーリングリストなどで生産性の定義がしばしば議論されている。 というわけでここでもやってみようと思う。

生産性を定義することの意味とか有用性についてはとりあえず棚上げにし、 数学的にどうなっているかを考えてみる。

まず最初に考えつくのは、生産性とはもっとも単純なところで、 利益、コスト、時間、人数の４つのパラメーターをもつ関数として 表されるだろうということである。 これはおそらく製造業における生産性の定義になっているのではないかと想像するが、 同じ人数の作業者が、同じ時間をかけ、 同じコストで同じ収益をあげた場合は、 同じ生産性であったと考えるのはそれほどおかしな話ではない。 ただし前提としてだれがやっても同じ結果が出るというものがある。 だから同じ手法でというのも上記に加えて前提になっているはずである。

ただ、利益とか収益、コストといった用語を使うと、 どうしてもお金の勘定に発想が固定されてしまう傾向にあると思うし、 商売上の儲けの多少を考えるのではなく、 ソフトウェアの開発や生産において生産性がどういうものかを考えたいので、 以下利益とコストはゲインとロスと言い換える。 つまりこの生産性関数は、ゲイン、ロス、時間、人数の４つのパラメターで表されるとする。

この関数は具体的にはどのような形をしているのだろうか。 他の条件が変わらない場合のことを考えることから始めてみよう。

まず、他の条件が変わらない場合にゲインが大きくなった場合、 生産性はどうなっているだろうか。 なぜ他の条件が変わらないのに、突然ゲインが増えるのかといったことは問わない。 何故かというと、ゲインの増減が生産性の定義においてどのような位置付けをされて いるのかを吟味したいからである。 当然、ゲインが増えたのだからそこから計算される生産性は上がったと考えるべきだろう。

次にゲインがどこまでも増えれば、生産性も増えるだろうか。 それともあるところで生産性は減少に転じるだろうか。 ゲインの増加に伴って、あるところから生産性が減少するということはないだろう。

このように考えると、ゲインに対しては生産性は単調増加であると言える。 ここで注意すべきは、別に比例するとは言えないことである。 もしかしたら、生産性には上限があり、だんだんある値に漸近するものなのかもしれない。 この段階で言えるのは、ゲインが増えれば生産性も増えるということだけである。

次に、ロスについてはどうであろうか。 ロスが増えれば生産性は下がる。考え方はゲインの逆である。 よって、ロスについてはゲインと全く逆になり、単調減少になるだろう。

時間についてはどうか。例えば時間が倍になったのに、ゲインが同じ場合、 その生産性は高いとは言えない。逆にゲインが同じ仕事を半分の時間でこなしたと したら、その生産性は高かったと言える。よって時間に対しては単調減少になる。

人数については、生産性における位置付けを考えるのは少し難しい。 人数を増やしたら生産性は上がるかといえば、経験上そうとは言えそうにはないからだ。 ただ、人手が足りないがために、同じ仕事でも時間がかかってしまうということは よくありがちな話だ。上でみた通り、時間がかかったということは生産性は低かったということになる。 いっぽう、ソフト業界は慢性的な「人手余りの人材不足」ということを 考えると、生産性に関与するのは単純な頭数ではなく、なにか人材関数とでもいう ようなものがあり、それを通した上での人数であるのではないだろうか。 つまり、生産性に関与する人数とは、単純な作業者数のことではなく、 人材関数に作業者数を与えた結果の人数ということにする。 この人材関数はおそらく人数から単純に計算できるものではなく、 方法論やプロジェクトの状態にも影響を受けるはずである。 とりあえず人数を人材関数に通したことを表すため、これを人材数と呼ぶことにする。

それでは、この人材数は生産性にどのように影響するかであるが、 安直に人材数が増えれば生産性は単調増加するということにする。 同じ条件で人数が増えれば一般に生産性は下がったと判断される。 一方、人材数はこの逆数のようなもので、 例えば頭数を減らしたのに最終的な生産性が同じなら、 それはより良い人材を得たと言える。 人材数とは人数に依存して生産性を上げる要素ということなのである。

これで、四つのパラメーターがそれぞれ生産性を単調増加させるか、あるいは 単調減少させるかがはっきりした。まとめると次の通りである。

ゲイン	単調増加
ロス	単調減少
時間	単調減少
人材数	単調増加

しかし、これだけではまだ生産性の姿は みえてこない。四つのパラメーターを組み合わせて考える必要がある。

まず、ゲインとロスの関係について考えてみよう。 ゲインが増えてもロスが増えてしまえば、生産性が上がったとは言いにくい。 つまりゲインとロスは互いに打ち消しあうと考えてもよさそうである。

ただここで、単に打ち消しあうといっても、差があるのか、比率なのか、 つまり、ゲイン－ロスなのかゲイン／ロスなのか、 あるいはもっと別の関係にあるのかという問題を解決しなければならない。 もう少し突っ込んで考えてみる必要があるが、これもなかなか悩ましい。

時間や人材数に関しては、これは明らかに比率である。 というのも、ゲインやロスと時間や人材数との差というのは、 単位が違うわけで、そのままでは差を考えることができないからだ。

難しいものをいつまでも難しく考えていてもしょうがないので、 いっそこのこと当面不都合がでるまではゲインとロスはまとめて 考えてしまうことにする。 ちょうど良いことに、ゲインという言葉には増加分という意味の他に 増加の比率という意味もある。 むしろこっちのほうが一般的かもしれない。

そういうわけで、以後ゲインとはマイナス分を打ち消しあった残りという 意味に変更する。それが差なのか比なのかはとりあえず保留するが、 収益とかコストとという文脈では差になるだろうと思う。

次のようにまとめの表を更新する。

ゲイン	単調増加
時間	単調減少
人材数	単調増加

この三つのパラメーターは、とりあえず一番単純なところで考え、 互いに比率でもって作用しあうと考えて良いだろう。 すると、結局ここで得られた生産性の定義式はもっとも単純に考えた場合には、次の通りになる。

、、をそれぞれゲイン、経過時間、方法論による係数とし、
をある状況における人数の人材数とすると、
生産性は次の式で定義される。

あくまでこれはもっとも単純に考えた場合の話であり、 今後この式をたたき台にしていろいろと改良していく必要があるのは いうまでもない。が、とりあえずはこれを「ソフトウェア祈祷師が提唱する 生産性の定義式」としたい。

この式の意味するのは、すなわち次のようになる。

なるべく人材数の高い少数精鋭メンバーを集め、
より高い係数を持つ方法論を採用し、
より少ない時間で、
より多くのゲインを求めれば、
さらに高い生産性が得られる。

極めて当たり前の話ではある。しかし、なんとなく馬鹿にされているような気もする。たかが数式の分際でここまで人間様を小ばかにしてくれるとは、どうしてくれようか。

ちなみに、方法論係数kと人材数rを無単位数とし、 ゲインgは利益を金額で表しているとすると、 pは「時間当たりの利益」になる。 これは平たくいえば時給みたいなものである。 人材数が無単位ではなくに人数分の１(ゲインを頭数で均等に分けるという意味？)だとして、 pは「技術者一人が１ヶ月にあげる生産量」と解釈すれば、 つまり人月で考える工数と考えられなくもない。 なんだかやっと古典と同じスタートラインに立っただけという感じで、 これだとゴールが全く見えない。

う～む。まじめに研究している人が見たら憤死してしまいそうな結論だなぁ…。

「体調不良」（行動記録／日記）

◇ ◀ ▲ ▶

朝起きてなんか身体全体がだるくて身体中の関節がなんとなく痛い。

たぶんこれは風邪のひき始めだ。

というわけで今日は一日中寝て過ごした。 というか、寝なおして目が覚めたら昼で、さらに寝なおしたらもう夜だった。 とりあえずは復活したっぽい。 調子がよくないときは、無理にでも詰め込んで食べて、そして寝る。 これに限る。 おかげでこの１０年まったく医者いらず。薬もほとんど飲まない。

今日は幸いな事に外に出る用事がなかったからというのもあるが、 平日に一日中寝ていられるのも、自営業の利点のひとつであろう。

今週の金曜日はやっつけ仕事の話も舞い込んでこなかったので、 明日も少なくとも気分的にはゆっくりできる。 実は金曜日の夜というのはたまに戦々恐々とすることがたまにある。 金曜日になってから「来週の週明けまで…」みたいな話がダブることがよくあるのだ。 そういうのって要するに「世間様のいう週末に働けってことですか？」ということなのだが、 こればっかりはそういう商売なのだからどうしようもない。 １０年以上もやってると平日週末の感覚は薄れてくる。

そろそろ紅葉の時期なので秩父あたりにトレッキングがてら札所巡りにでも行きたいなぁ。

「mimeTeX 1.50」（MT導入と改造）

◇ ◀ ▲ ▶

mimeTeXの新しいバージョンが出ていた。

早速インストールしてみる。どうやら以前のバージョンとコンパチでない部分があるようなので、WikiのTeX拡張にも手を加えて以前のバージョンも使えるようにしてみた。

新しいバージョンでは、\arrayのサポートがかなり豊富になった。 以前のものだと数式が複数行になるとき＝をそろえるがめんどうだったりしたが、ずいぶんと楽になった。他に色などもつけられるようになった。

なによりいいのはキャッシュ機能が追加されたことだ。 もともとウィンドウズのアプリにしては軽く動くものだったが、 無駄が省かれるような気がする分だけ嬉しい。

ただ、\atopなど一部のコマンドでTeXに準拠していないやつがこんどはTeXに準拠するようになり、結果として一部のコマンドがコンパチでなくなってしまったようだ。

さっそく試してみよう。

コンパチでない部分のテスト。

　以前の書式のものを新しいmimeTeXで試したもの。予想どおり発狂。

　以前の書式のものを以前のmimeTeXでだせるようにWikiのTeX拡張に手を加えたもの。大丈夫そう。

そういえば、UMLの図形が書けるように拡張しようとしていたっけ。 すっかり忘れていた。

「My Definition of 生産性(2)」（OO百韻）

◇ ◀ ▲ ▶

前回のMy Definition of 生産性(1)では、生産性に影響を与えると考えられるパラメーターとして、 ゲイン()、経過時間()、人材数()の三つの変数と、 方法論の選択の仕方によって生産性にインパクトを 与える係数()を一つ考えた。 とりあえず第一歩として作り出した生産性()の定義式は次のようであった。

今後、この式をたたき台としてさらなる改良を加えていきたいわけだが、 その前にこの式を吟味することから始めたい。

ゲインの具体例

まず、ゲイン()であるが、そのままではかなり抽象的な要素である。 しかしこの抽象化は意図したことであり、 一言で生産性といってもかなり意味が広いため、 あえて具体性のないものを定義に使用したのである。 それでは、具体的にはどんなものをゲインに当てはめることができるだろうか。

売上や利益

売上と利益とでは意味が違うが、どちらも商売上得た金額に関係する点で同じである。これらに関してゲインがどのように定義されるか表にしてみた。

売上／費用	投入した費用に対する売上
売上－費用	最終的に得た利益
(売上－固定費用)／可変費用	上記二つを合わせたもの

製造業や経済学などでは一般に生産量や設備投資、原価計算などから計算する産出量／投入量を生産性としているようである。対投資効果とでもいうことなのだろうか。また、売上－費用、つまり利益のことでありあまり一般的ではないが、これでもってゲインとする考え方もある。これは設備投資や固定費など生産量に比例しない値を単純に投入量に含めて考えてしまうと、それで計算される生産性が感覚に一致しなくなってくるという欠点を補うため、単純に比率で考えることができないものはまずは引いてしまえという考えからくる。

機能

ソフトウェア開発においては最終成果物の機能(の数)をベースにして生産性を考えることが非常に多いようである。 しかし、しっかりと原価計算をしたうえで生産性を割だす製造業と、仕入れの概念が全く異なるサービス業としてのソフトウェア開発とでは当然ながら同じ指標を全く同じように使えるわけがない。 機能の数と金額はあまり関係ないことの方が多くためか、この違いからくるすれ違いが「ソフト開発における生産性の議論」において多くの混乱を招きよせているように見受けられる。

品質

ソフトウェア開発において、はっきりと明言しているわけではないが、要約すると品質の向上でもって生産性の向上とするケースが最近増えているように見受けられる。

前提として要求や仕様の機能を全て実現するのは当然であるとする立場をとると仮定する。その仮定において、投入する人員や時間によってそれ以上の生産性を上げるのには限界があるような場合、開発現場においてそこで比較されるものがあるとすればその筆頭には品質が挙げられる。機能は同様、納期も同様、そして開発メンバーも同様であるなら、それらは成果物のでき、つまり品質で比べられるというのはおかしな話ではない。 また、経営の観点からみても限られた資源でよりよい品質を求めるというのは競走力の確保のためにはごく当たりまえの話でもある。しかし、品質についても直接的には金額の多少に関係していないことはままあり、単純に金額ベースで考える生産量とてんびんにかけてしまうと混乱のもととなる。

品質を生産性とみなす場合には、前述の機能の数に着目するのとは対称的に、成果物の質やその機能がどれだけ高度なレベルであるかということを指して品質としている。 しかし、量を表すものと質を表すものを、それらの関連性に関する議論抜きでそのままで同じ土俵に乗せて議論することは危険である。

システムの規模

いまだLOC、ステップ数、もしくはそれらバリエーションによるシステムの比較は健在である。 OSや何かの業務システムでも、新しいバージョンが発表されると、そのニュース記事中に何百万行のコードであったかという話が載り、だれもがその数値を聞き流す。 本気で生産性の判定にLOCをを使う人間はいないはずだと皆が信じながら、 それでも記事にはなり、その数値でシステムの規模を想像する。 また、組み込み機器の開発などではもっと積極的にコードのステップ数が議論され、その結論が仕様になる。

よって、甚だ不本意ながらもLOCなどの統計情報をシステムの規模を比較する要素として認めなければならず、また生産性の議論から外すこともできない。 しかし、LOCなどからさらに踏み込んでメトリックスを考えた場合、 統計量と品質を結びつける橋渡しとして重要な役割を演じる可能性もあり、 なんらかの利用ができるかもしれない。

障害

システムの保守で生じた障害のうち回復したものをベースに考えると保守の生産性ということになる。 MTTRの合計に対して、復旧した障害の数が多くなるほど、「保守の生産性」が上がったのだと考えることは可能だろう。 また、障害発生当たりの時間間隔であるMTBFは、その値が小さければ頻繁に障害を起こしていることになり、つまりそのシステムの品質は低いことを表していると考えられなくもない。 このことから、MTBFも何らかの形でシステムの品質に関係しており、よって生産性とも関係がある。 この様に考えれば、障害の回数やその回復などは保守における生産性と密接に関係していると言える。

定数

ゲインについては考慮せず敢えて定数として扱ったり、時間や人数を機能当たりに換算して考え、単純に経過時間や人員数のみで比較するという意見もあるようである。 これは、実態としてソフトウェア開発における生産性というものが非常に漠然としており客観的な経営判断に利用するには無理がある場合が多いということが背景にあるのだと思われる。 ゲインがなにであるかはっきりしていなかったり、感覚に合わないケースが多いならば、そのような場合にはいっそのこと時間と人数だけで判断してしまったほうが合理的である。 また、このような場合には、生産性の定義式の方法論係数が重要な意味をもってくるものと思われる。

ゲインの例のまとめ

ソフトウェア開発を基点に考え、すぐに思いつくゲインの具体例はだいたいこれぐらいであろうか。 だいたいにおいて、ゲインには量的なものと質的なものの二つの要素が複雑に絡みあっていそうだということが窺える。 よってこの二つの側面の間の相互関連性、 言い換えれば全単射を見い出すことができれば、 ゲインがなにであるかということに関してかなりすっきりしたものが 得られるのではないだろうかと期待したい。 他に、開発が始まる以前から序盤にかけては量的な面が注目され、 中盤から終盤で質的な面、そして終盤以降は両方が重視されるのでは ないかと考えているが、現時点でははっきりとした根拠があるわけではない。

以上、ゲインの具体例について少し掘り下げてみた。 次回以降(続きがあれば)、ゲインの量的な側面と質的な側面の数学的なモデリングや、他の要素の具体例などについて扱ってみたい。

「オブジェクト vs インスタンス」（OO百韻）

◇ ◀ ▲ ▶

あるメーリングリストでオブジェクトとインスタンスの定義について議論されていた。 要するに「オブジェクト⊂インスタンス」なのか「インスタンス⊂オブジェクト」なのかという見解の相違が焦点だったようだ。 メーリングリストでの議論はすでに収束したようだが、この件について自分なりに考えてみた。

まず、ソフトウェアの分野では、用語としてのオブジェクトとインスタンスは、 それぞれかなり広い意味をもっているように思う。 だからどの定義によるものなのかがはっきりしていないと議論にならない。

今ここで「以後、オブジェクトとは次の文献にある定義に準拠する。」とやっても 良いのだが、そうすると議論はそこで終わってしまう。 あとはその定義をいかに上手に説明できるかどうかになってしまうだろう。 その上、その文献なり書籍なりをとり上げるのが妥当かどうかが問題になってしまい、 「オブジェクトとインスタンスの意味はなにか」という本来議論にしたかった 部分以前のところで、また新たな見解の相違が発生する。

だからここでは特定の定義を引用したりはしない。 あくまで個人の考えにおけるオブジェクトとインスタンスの関係について述べてみたい。

オブジェクト指向を、モデリングの手法のひとつとしての側面から考えてみる。 そこでは、まず第一に「分類」が重要な位置を占めている。 モデリングの対象のそれぞれを、どれとどれが同種であるか、 同種でなければどこが違うのか、といった分類作業がまず最初にあるはずだ。 これは無意識で行なわれるものから、なにか特定の方法論や決まりごとに よって行なわれるかなり幅がある。 また、どこまで細かく分類するのかもいろいろあるだろう。 が、なにをさしおいても分類されていなければ話は進まない。 そういう意味でもまず第一にあるのが分類であろうと思う。

この段階で「オブジェクトとはモデリングの対象のことである」と 定義してしまうことは可能かもしれない。 この見解を持つ人も少なからずいるであろう。 また、それは間違いではないだろうとも思う。 しかし、この段階で早合点はぜず、ここではまだオブジェクトは定義しない。

分類という作業は、表向きはグループ分けのことである。 どういう観点でグループ分けしたのかが 分類を執行する上では外せない重要なことがらある。 が、表面上は単なるグループ分けが行なわれたにすぎない。 モデリングの対象をグループ分けしたということは、 それはある種の抽象化が行なわれたということである。 グループ分けするにあたってなんらかの分類の観点にしたがって 個々の具体性を捨てさり、一つのグループとして認識するようになったわけである。 逆にそれぞれのグループは個々の具体例によって構成されているとも言える。

このように、ある観点に従ってモデリングの対象がグループ分けされると、 それは「概念」を構成しているのだ、とする立場がある。 概念などという言葉を使うと話が大げさになりすぎるような気もなきにしもあらずだが、 あまり深くは考えずにここまで述べたグループ分けのことを以後は一言で「概念」と 呼ぶことにする。

この概念だが、つぎのことがらが関係してくる。

1. その概念を識別し、他の概念から区別する手段。名前など。
2. その概念がどのような観点でできたものかを表す手段。定義など。内包。
3. その概念を構成する具体例の集まり。実例。外延。

「概念」という概念には必ずこの三つがつきまとう。 概念についてさらに語り始めると必要以上に話が大きくなっていってしまうし、 ここまでくればオブジェクトとインスタンスはなにかということを はっきりさせる材料が揃ったと思うので止めておく。

ここまでの話で、すでに「対象」とか「ことがら」といった言葉がでてきている。 これを「オブジェクト」としてしまうまえに、まずは概念の三つ目にある 具体例から考えてみる。

「具体例」は英単語に訳すと“instance”になるが、 インスタンスの正体はずばりこれである。 「インスタンスとはある概念の実例／具体例」のことでそれ以上の意味はない。 概念になにをもってくるかで、モデリングの対象が「それが何のインスタンスである」かが決まる。

次に「オブジェクト」であるが、具体的にははっきりいって定義による。 抽象的にいってよければ、 強いていえば「ある特定の概念のインスタンスがオブジェクト」であるということになるかもしれない。 定義によると言ってしまっては身もふたもないが、 そこで扱うその「ある特定の概念」をどういう範囲に制限するかで、 あるいは、特定の種類の概念(概念の概念！！)を特に強調しているか、 なにに注目しているのかなどで、 オブジェクトがどのように定義されるかが非常に違ってくるので仕方がない。

そもそも、objectという言葉は訳すとその意味の一つに「対象」というのがあり、 ソフトウェアやモデリングの文脈では「何」の対象かがはっきりしていないと、 意味が抽象的すぎているということもある。感覚的な表現だが、 オブジェクトとインスタンスは概念の概念における動と静の違いと でもいったら良いだろうか。

だから、まず、そこで扱う概念の範囲を限定しなくてはならない。 「ある特定の概念」とは何か？　 広くは「この世の全て」から、狭くは「C++のclass」までさまざま考えられる。

狭い場合から考えよう。StroustrupのC++では自己流に要約すると「C++言語で扱うもので、 ランタイムにメモリー上に領域をもったデータとして存在しうる」がオブジェクトであるとしている。 つまりこの「C++言語で扱うもので、ランタイムにメモリー上に領域をもったデータとして存在しうる」という概念の具体例がオブジェクト、 言い換えるとその概念のインスタンスがオブジェクトであると定義されている。 だから、C++のプログラミン上は「オブジェクトで表されるものの集合＝インスタンスで表されるものの集合」である。

「概念とそのインスタンス」と「特定の概念のインスタンスをオブジェクトと呼ぶ」と いうのでは、それぞれ抽象のレベルが違う。 だから上ではあえて「××で表されるものの集合」と表現した。 「××と△△」の比較と「××で表されるものの集合と△△で表されるものの集合」の比較とでは、微妙にニュアンスが違う事に注意してもらいたい。 概念そのものの比較と概念の外延の比較の違いである。 表現が長くなるので、以下「△△で表されるものの集合」を｛△△｝と表す事にする。 例えば、「オブジェクトで表されるものの集合＝インスタンスで表されるものの集合」は「｛オブジェクト｝＝｛インスタンス｝」となる。

UML1.xでは、クラシファイアが概念に相当していると思われる。 そして「クラスのインスタンス」がオブジェクトである。 つまり、クラシファイアのインスタンスのなかでも特に「クラス」の場合を強調してオブジェクトと呼んでいる。 他のクラシファイア、例えばアソシエーションのインスタンスはリンクである。 よって、UMLでは「｛オブジェクト｝⊂｛インスタンス｝」である。

一般にJavaScriptで知られるECMAScriptでは、このプログラミング言語で扱うものは すべてがオブジェクトである。 実際にはすべてがObjectというオブジェクトで、そのObjectをさらに 細かく分類したFunctionのオブジェクトが関数、という具合いになっている。 この例だと「｛オブジェクト｝⊃｛インスタンス｝」ということになるだろうか。 なんとなくオブジェクトとインスタンスの意味はこれまで述べてきたのはまったく逆になっているような気もしないではない。 また「new演算子でメモリ上に確保されたオブジェクトをインスタンスオブジェクトという」 というように、C++言語流で考えればオブジェクトへのポインターがインスタンスと いうことになっており、正式にはこれをインスタンスオブジェクトと呼んでいるようである。 ただECMA262では一般の英単語との“instance”は、 「××は△△のインスタンスである」という言い方もされており、そういう意味では、 「｛インスタンスオブジェクト｝⊂｛オブジェクト｝⊂｛インスタンス｝」ということなのかもしれない。

ここまでプログラミング言語を中心にみてきたが、概念とそのインスタンスのことを ひっくるめてオブジェクトとよび、逆にオブジェクトが概念とインスタンスに分けられる とする考え方もあるようだ。 これは「全てのものがオブジェクト」の極端なケースで、ある意味純粋オブジェクト指向 といえるだろうか。 全てのものがオブジェクトなので、そのなかにはクラスやインスタンスといったものも含まれる。 この場合だと明らかに「｛オブジェクト｝⊃｛インスタンス｝」であるだろう。

逆に、これが示唆するのは、この立場においては インスタンスになりえないなにかが存在する事を暗黙のうちに認めている。 つまり、「オブジェクト＝インスタンス＋インスタンスでないもの」であり、 ソフトウェア上はクラスがインスタンスでないものとして扱うということなのであろう。

こじつければ、これは「全てのもの」という概念を考え、よって その具体例であるオブジェクトは全てのものなのであると考えられなくもない。 しかし、その場合は「インスタンス」の意味が単なる英単語の“instance”ではなく、その分類作業で扱う概念に限定した特殊用途の“instance”であり、これまで述べてきたのとは若干違ってくる。

この件に関してはいずれ機会があったときには、メタモデルの階層とか メタモデルの線形性について書くときに少し触れるかもしれない。

これ以上は結論らしい結論にはたどりつけそうにない。 なぜならば、ここに挙げたわずかな例だけでもオブジェクトの定義はさまざまであり、それにオブジェクトとインスタンスは違う概念の概念に属し、同列に扱えるものではないからだ。 が、あえていえば 「ある概念の具体例を表すことばがインスタンス」にすぎないのであり、 「オブジェクトが何を意味するかは定義による」「ある特定の概念のインスタンスをオブジェクトと呼ぶ」ということしか言えない。 純粋オブジェクト指向の「すべてがオブジェクト。オブジェクト＝クラス＋インスタンス」という立場もいっそのことあっさりしていて魅力がある。 一方、UMLのメタモデルもクラシファイアを中心に据えた核心部分(≠表記法)では モデル要素がはっきりわかって個人的には非常に納得しやすいと思っている。

まとめると、

1. 分類という作業があり
2. 概念があり
3. 概念とは、名前、内包、外延からなり
4. 概念の具体例がインスタンスのことであり
5. オブジェクトはその定義(概念の選択にしかた)による
6. よって、ある特定の概念のインスタンスがオブジェクト

というところか。

他人とこの話題について話す場合には、オブジェクトの定義について相手の立場をちゃんと把握してから慎重いこうと思う。

「X-IPのその後」（行動記録／日記）

◇ ◀ ▲ ▶

「MIMEヘッダーにあるX-IPとは何？」で謎のMimeフィールドであるX-IPでスパムが区別できるかもしれないと書いた。

ほぼ２週間たって実際どうであったのだろうか。

次のグラフはこの10月11日から10月23日までの約12日半のスパムの状況である。

グラフの 下側の紫のラインは自動削除からもれたメールの数、 上側の青色のラインは自動削除ツールが削除したメールの数、 そして下側の緑色のラインは削除されたメールのうちX-IPを含んでいたために削除されたメールの数である。 この2週間自動削除からもれたものがあっても自動削除ツールに登録していない(普段はだいたい週に2回ほどやっている)。

過去１ヶ月とくらべるとやや自動削除されたメール数が増えたような感じがする。 一方、削除もれはその分だけ減ったという感じである。 というより、X-IPで自動削除された分のおかげで削除漏れが半減している。

自動削除の内訳は次の通りである。

X-IP	53	X-IP単独のものは約半数の26
常連	125	常連その1は111個、その2は14個
偽HELO	17	SMTPのHELOコマンドで自身を偽っている
RFC850違反	2	Message-IDが規約違反
その他	42
合計	230個	全652メール中230がスパム！(多すぎ！)

合計が合ってないのは、重複してカウントされているものがあるからである。 この半年で常連の数が徐々に増えているのが気になるところだが、それはちょっとおいておく。 X-IPで削除されたメールで、実際にスパムでないメールはゼロだった。

結論として、X-IPフィールドの有無でスパムかどうかを見分ける方法の効果はずいぶんとあるということである。 これまでスパムを受け取るたびにいちいち登録していたのだが、 新規登録かどうか調べwhoisでIPのレンジを調べ場合によっては 登録済みのエントリーのIPレンジを広げるといった、 その、きわめてかったる～い作業の手間がかなり省けた。

問題は依然としてX-IPの用途が不明であるということだろう。 いまのところは、スパム送信ツールかスパムを許容するISPのMTAがつけているのだろうと推測できることぐらいしかない。 検索してもX-IPの意味は調べる事ができなかった。 X-IPの存在に気付いたのはつい最近のことだが、 ログを調べて過去の削除状況をみてみるとこのフィールドが現れ始めたのはだいたい夏ごろからである。 おそらく最新のスパムツールが使うようになったフィールドであろう。

一番恐いのはX-IPフィールドの用途が極めて善良なもので、 あるときから突然自分宛のメールを軒並み削除してしまうことだ。 不気味な存在ではあるが、 いまのところはとりあえず実害がででないのでよしとしよう。

しかし、今回の調査で3人の人間からの合計６通がスパムでないのにスパムと判定されてしまっていることがわかった。 念のため過去のログも全てあさってみたが他にはなかったようだ。 ちょっと安心。

これらはどれもブラックリストにのったＩＰレンジから発信されており、X-IPフィールドがあるわけではない。 単純にかつて何度かスパムが発信されたIPのレンジと同じレンジから発信されたメールであるというだけだ。 ただ、どれもメーリングリストで送られてきたものであったのであまり実害はでていない。 ホワイトリストへのエントリーの追加方法を少し改良する必要がありそうだ。

追記:

月曜日になってから、この２週間で削除もれになっていたスパムを整理した。 X-IPのおかげで大方は半減しているはずなのに、 土曜日以降なぜか大量のスパムがたまっている。クソッ。

調べてみると、その増分のほぼ全部が同じところから来ている。 そんな一挙にまとめてスパムを送ることもないだろうに…。 スパムを送信すると小銭が稼げるという今の仕組みがあるかぎり亡くならないんだろうなぁ。 かんべんしてよ＞中国

IPレンジは61.191.0.0-61.191.255.255で、 NetNameがCHINANET-AHで Anhui province network China Telecom CN というところだ。 で、このレンジは、どうもnslookupとかwhoisとかで調べた内容がおかしい。 検索する内容によってはもしかしてDNSもおかしくないかい？ 思い違いだろうとは思うが、プロバイダーによる組織ぐるみの送信が行なわれているのではないかと疑いたくなってくる。