祈祷連歌

「データベースをMySqlに移行」（MT導入と改造）

◇ ◀ ▲ ▶

たいして量があるわけではないのに、リビルドがずいぶん遅くなってしまっていた。 全体リビルドをするとなんかのタイムアウトでエラーになるという、 なんだかトホホな状況に陥ってしまっていた。 それに、アクセス記録が予想以上に増加していて、perlだけで統計情報を計算するのには そろそろ限界に来ていたというのもあるので、データベースをBerkeleyDBからDBI::mysqlに 移行することにした。

MySqlインストール

インストール自体はWindows Installerで行えることもあり、すんなり終わった。

しかし、サンプルのperlスクリプトでテストしてみるとconnectができない。

どうやらパスワードがあるとだめであることがわかったのでパスワードなし。 これはあんまり気持ちがよくないので、なるべくはやく解決する事にして、次へ。

MTデータベース移行

使っているMTは2.6なのだが、MT3.0用のmt-db2sql.cgiで簡単にデータベースの引越しができる、はず。 しかし、そうは問屋が卸してくれない。 まずここで使っているMTはデータベースのスキーマに手を加えてあるので、ここを変更して あげないといけない。 みようみまねでスキーマをいじってとりあえずはスキーマの変更は終了。

しかしmt-db2sql.cgiを動かすと「DBIにconnectなんかないよ」といって怒られてしまう。 これにはかなり手間取ったが、どうやらトップレベルのモジュールで「use DBI;」がないために ライブラリーのスコープがMT内部にあるMT::DBIモジュールと混乱してしまっているようである ことがわかった。よってトップレベルのモジュールには件のuseを入れてやることで解決。

これがわかるまでにCPANでDBIを何度インストールしなおしたことか…。

文字セットの怪

ここのMTはutf8を文字セットに使っているのだが、どうやらこれがデータベースに入る時に 化けてしまう。データベースの設定ではちゃんとutf8にしているのになぜだ？

MySqlのマニュアルをみてテーブルごとにデフォルト文字セットをutf8にするとか、 カラムごとにやってみるとかいろいろやったが、どうもうまくいかない。

結局ワークアラウンドとしてMT側のDBIのオブジェクトドライバーのmysqlのやつに、 クラスにドライバーをセットしたときに"SET NAMES 'utf8'"を実行してやることで解決。

日付の怪

MT内部では日付はYYYYMMDDHHMMSSのフォーマットになっている。 一方、データベース側ではYYYY-MM-DD HH:MM:SSなので、MT内部のmysqlのオブジェクトドライバーでこの違いを吸収するようにしてある。 しかし、この機構が働いていない。もしかするとトップレベルモジュールで強引にuse DBIを してしまったことが原因なのだろうか…。 いずれにせよ、リビルドができないのは困るので、オブジェクトドライバーの各DBの共通コード側で 「tr/\- ://d」してしまうことにした。 せっかく汎用に作られているのに、ここで使う特定環境下でのmysqlの都合を押し付けてしまうのは非常に心苦しいのだが、しょうがない。

MySqlの効果は？

リビルドの速度はどの程度はやくなっただろうか？

気持ちはやくなったのかも知れないという程度かもしれない。 なので、あんまりご利益はないかなぁ…。

次はアクセス記録の部分をMySql対応にする。 現在ページを表示する時間の大部分はここで費やされているので、こっちは効果があるだろう。あるはずだ。

追記:

何回かリビルドした感じでは明らかに早くなっている。 エントリーやコメントの単体リビルドだとあまり違いがわからないが、 全体リビルドだと違いは明確だ。 データベースを移行したかいがあった。

今後の改造

• 禁止IPリストをレンジで指定できるようにする。
• アクセスログのデータもMySqlに移行する
• MT3.1へ移行

「メタモデルの線形性」（OO百韻）

◇ ◀ ▲ ▶

メタモデルを考えるとき、さらにメタレベルでひとつ抽象度が上がったモデルとして メタメタモデルなるものを考えることがある。 UMLではユーザーオブジェクトのレベル(M0)とモデルのレベル(M1)、メタモデルのレベル(M2)、メタメタモデルのレベル(M3)の４階層からなる４階層メタモデル体系(Four Leyer Metamodel Architecture、FLMMA)が考えられている。 UMLでも４階層メタモデル体系が提唱され始めたころは、ごく一部のコミュニティではM4だのM5だのといった霞か雲を掴むような議論がなされていた。 最近では表だったところでは４階層メタモデル体系以外のものをあまり、 というか、ほとんど目にしない。 しかし、UMLから離れてメタモデリングそのものを議論したり、あるいはUMLのメタモデリングの問題点について議論する場合には、非常にマイナーなトピックではあるものの、そのかぎりではない。

ここに、厳密メタモデリング(strict metamodeling)という考え方がある。 この考え方に照らし合わせると、UMLに関してなにか知見が得られるかもしれない。 前半はUMLのメタモデルの線形性についての既知の問題点を説明する。 UML2.0ではその問題点を解決するためにかなり大胆な改良が加えられているが、なぜかその問題点をあまり宣伝していないために複雑怪奇な面ばかりが目立ってしまっている。 後半ではアスペクトに関するアイディアのひとつをとり上げる。

厳密メタモデリングの定義

まず、この厳密メタモデリングとは次のように定義される。

簡単にいうと、厳密メタモデリングとは、あるレベルの要素は必ずひとつ上のレベルで対応するあるひとつ要素のインスタンスになっていなくてはならない、ということである。 そして、厳密メタモデリングに基づいたメタモデルを線形メタモデルという。

モデルケース

抽象的な議論だけだと分かりにくいので、モデルケースとなるような例題を考えてみる。 線形メタモデルの説明でしばしば引合いにだされる非常に単純な例題があるので、 ここではその例題から一部を取り上げてみよう。

• あるビデオショップで商品管理を行なっている。
• ビデオを販売している。
• ビデオの『2001年宇宙の旅』が在庫にある。

次の図はこの例題のもっとも単純なモデルをUMLの４階層メタモデル体系に当てはめたものである。

UMLに関連した書籍などではよくおなじみの図である。 各レベルの要素は一つ上位のレベルの要素のインスタンスになっている。 M0からM3の階層は背景の色が緑色(M0)、明るい水色(M1)、暗い水色(M2)、そして青色(M3)で表している。

一見して、線形メタモデルになっているように見える。

しかし、M2レベルに「オブジェクト」というメタクラスのモデル要素を追加すると、 とたんにその線形性は破綻する。

UMLのメタモデルでは、オブジェクトとはクラスのインスタンス、言い換えると、 クラスの実体もしくは実例であると定義されている。 図はモデル層にある(商品としての)ビデオクラスのインスタンスとして、 (在庫のひとつとしての)『2001年』がユーザーオブジェクト層にあることを示している。 一方、『2001年』はオブジェクトなのだから、当然メタモデル層におけるオブジェクトのインスタンスでもあるはずである。 しかしこのインスタンス関係を認めてしまうと、 このメタモデリングは線形ではなくなってしまう。

なぜなら、第一にインスタンス関係は一つの階層しかまたげないはずであり、 第二にモデリングの要素は必ず一つ上の階層の一つの要素のインスタンスでなければならないという、二つが厳密メタモデリングが要請することだからである。

「よって、UMLのメタモデルは線形ではない。証明終わり。」とやってしまっても 実用上はいっこうにかまわないのだが、ここではそれではおもしろくないので、 なにがなぜUMLを非線形たらしめるのかを考えてみたい。

仮説その１：メタモデルは複数階層にまたがる

あくまでも仮説の一つとして、UMLのメタモデルは４階層メタモデル体系を 提唱しながらも、一部メタモデルの階層(M2)にない要素がメタモデルとして 定義されていると考えることができるかもしれない。

この図は、UMLが実際にはM1にある要素をメタモデルとして定義していることを表している。 図中M1’とあるところがそれで、メタモデルで定義されている「オブジェクト」は 実際には線形メタモデル中のM1にある。 つまり、UMLのメタモデルは本来M2にあるべき要素とM1にあるべき要素をいっしょくたにして定義しているということである。

この仮説は、ステレオタイプなど、モデル拡張のために用意された仕組みを説明する場合にも、似たような考えを適用できる。

ところでこの仮説によるメタモデリング体系は、線形だろうか、それとも非線形だろうか？

残念ながら非線形である。 なぜなら、『２００１年』ユーザーオブジェクトは、「ビデオ」クラスのインスタンスであると同時に「オブジェクト」メタクラスのインスタンスであり、二つの要素のインスタンスになっているために厳密メタモデリングの定義から外れてしまうからである。

まぁ、そう堅いこと言わずに、例えば「やや厳密メタモデリング」というようなものを定義すれば良いのかもしれない。 しかし、こうやって基礎となる概念を必要だからといってポンポンつくり出していてはきりがないし、こういうご都合主義は最後の手段にとっておきたい。 よって、この仮説その１は却下もしくはいまのところ保留としたい。

仮説の２:instanceOfには何種類かある

そもそも、UMLのメタモデルが非線形であることの原因のひとつに、 ユーザーレベルのオブジェクトが、モデルのインスタンスであると同時に メタモデルのインスタンスであるという具合いに二通りのインスタンス関係を 持つことがある。 ならば、つぎなる仮説としてインスタンス関係には実は複数の種類があるのだと考えるのはどうであろうか。

インスタンス関係がこれまでの図だと上下にしかないのに対して、 この図では上下のインスタンス関係と左右のインスタンス関係の ２通りが表されている。 上下方向のインスタンス関係は論理的なものとして、L0、L1、L2となっており、 左右関係のインスタンス関係は物理的なものとして、P0、P1となっている。 従来のM0からM3の階層は背景の色が緑色(M0)、明るい水色(M1)、暗い水色(M2)、そして青色(M3)で表している。

つまり、従来のインスタンス関係を更に細分化して、論理インスタンス関係と物理インスタンス関係に分けたのである。メタモデル階層の直積分解である。

インスタンス関係を２次元に拡張することで、物理インスタンス関係と論理インスタンス関係はそれぞれ必ず一つの上位要素とのインスタンス関係を表すことができる。 物理的なものと論理的なものとを別個に考えるかぎりにおいては、 どの要素も必ずひとつ上位のひとつの要素のインスタンスであると言える。 よって、この仮説のメタモデリングは線形である(と、こじつけることができる)。

それに、従来のUMLのメタモデル階層M2は、この多次元メタモデル階層の (P0、L1)と(P1、L0)、(P1、L1)にきれいに収まる。 仮説その１のように「メタモデルの要素の一部が、実はM1にもあったのだ」と いった無理を通す必要がない。

この仮説においても、メタモデリング階層の直積分解などという新たな概念を 都合よく導入してしまっている点で仮説その１と大差はない。 が、仮説その１のようにアドホックに特定の概念を追加するのよりは、 より一般的な原理として直積分解という概念に還元できるので、 (あくまで個人的な好み、および独断と偏見により)こちらのほうが優れている。

よって、この仮説その２をソフトウェア祈祷師の多次元メタモデル体系(Multi-Dimensional Metamodel Architecture、MDMMA)として採用したい。

ひとつ断わっておくが、この多次元メタモデル体系はソフトウェア祈祷師の 完全なるオリジナルというわけではない。 いろいろな説を自分なりに消化したものがこれである。 ACMのDigital Libraryあたりで"metamodeling"などのキーワードで 検索すればいくらでもみつかると思うが、 類似のものがはるか昔からいろいろな人によっていろいろな形で 提案されている。 これはブログなので出典を明確にするようなめんどうなことはしない。 あしからず。 だから、メールなどで類似性の指摘をして強談したり、リファレンスの 明記を強要するようなことは、できれば遠慮してもらえるとありがたい。

UMLのメタモデルが非線形である理由

現状のUMLのメタモデルでは、 すべてのインスタンス関係をたった一種類のinstanceOfで 済ませてしまうために、 モデル階層をひとつ飛び越したインスタンス関係を考えたり、 ユーザーオブジェクトがM1のモデル階層にある要素のインスタンスで あると同時にM2のメタモデル階層にある要素のインスタンスであるといった 必要性がでてしまっていた。 これがUMLのメタモデルが非線形である理由のひとつである。

もちろん、UMLのメタモデルが非線形であってもとりあえずのところは いっこうに困らない。 しかし、ステレオタイプやモデル拡張、パターン、アスペクト、さらには オントロジーなどの絡みを考えるにあたっていろいろと 「あっちをたたせば、こっちがたたず」のことができてしまい、 そもそも土台から改良する必要があると考える人も少なくない。

次の機会には、モデル階層の直積分解とアスペクトの関係や、 MDAのモデルウィーバーなどに触れてみたいと思う。

つづく。

追記:

追加補足

これまでで表示してきた図ですが、モデル要素間の関係は実線で表してあり、 とくにインスタンス関係については矢印で表してあります。 UMLに準拠するなら、インスタンス関係は実線の矢印ではなく、破線の矢印にすべきものだったかもしれません。 だから、例えば最後の図だと、クラスとオブジェクトの間にある線は実線で インスタンス関係は表していませんが、ビデオとクラスの間にあるのは矢印で インスタンス関係を表しています。

さらに、つづきで書こうと思ってましたが、最後の図の物理レベルP1においては論理レベルはなくなってしまい。この部分だけ先取りすると次の図にようになります。

物理レベルP1以上のどこかではメタクラス、クラス、オブジェクトを別々にする必要性はなくなってしまうところがあり、結局右側には「モデル要素」ひとつだけがあり、左側のタイプ、ビデオ、「２００１年」などのモデル要素は右側では一つの物理的モデル要素のインスタンスでかまわないということになります。 そして、おそらく今現在オントロジーの主流を締めている派の意見を反映させれば、メタクラスはクラスを特化したもの、クラスはオブジェクトを特化したものいう具合いに下向きの汎化特化関係がつくことになります。この件に関しては、サブタイピングとサブクラッシングの反変性の一面が絡んでくるものと思われ、おそらく汎化特化関係についても今回の議論と同様に何種類か考える必要がでてくるのだろうと考えています。

「ビデオ配信できたらいいのに」（行動記録／日記）

◇ ◀ ▲ ▶

いるかさんのところでやっているからさわぎってインターネット上のストリーミング技術を使ったビデオ配達できないんだろうか。需要はありそうな気はするが、セミナーは無料だそうだからむずかしいだろうなぁ。

時間があればいってみようと思っていて締め切りになってしまったので今回はパスするのだけど、三つのトラック全てをみてみたいと思った。 そう思うのは、おそらく私が全然畑違いの人間で同じソフト業界でもJ2EEとは無縁な領域で仕事しているからというのもあるのだろうと思う。

婚約者が映像業界の人間だし、自分もちょっとだけカメアシのまねごとみたいなことした経験からすると、１トラック１日あたりカメラ１～２台で１人で撮るとするとどんなに安く見積もってもプロにお願いすればお友達価格だとしても機器のレンタル料を含めて８万はかかる。おそらく撮影会社に発注すれば劇安で１０～１５ぐらいするだろう。そもそもこの手の仕事だと撮影会社はグロスで頼まないといやがるだろう。３トラックだと３０万からということになる。どういう規模でやっているセミナーなのかよく判らないが、独立したプロジェクトだとして単品ベースで２００人を集めるようなものだと、このコストは道楽の範疇に入ってしまうのではないかと思う。

このあたりうまくできるようになれば事業としてなりたちそうなトピックなので この２～３年なんか良いアイディアはないかと思いながら結局なにもしていないだが、 ボトルネックは映像業界の金銭感覚が他の業界と１桁ずれている点で、これがもっとも厄介だ。

いやというほど実感したのだが、映像は撮影にしろ編集にしろ、それなりに経験をつんだ人間でないとダメだ。 こういう話をすると必ず「自分は映像の撮影はなかなかうまい」という人がいるが、 やはりプロとアマの能力の差は歴然としている。 どの分野でも同じだけど、中身がわかるようになればなるほど、そういう差を認識できるようになる。 逆にいえば、本業でない人が自らを「うまく撮れる」なんていうこと自体が、 その人が素人であることを暴露していることになる。

映像には、素材を撮影する段階で、その素材中にどういう意図で編集されるかが織り込まれてしまう。 だから、そこには一種の文法のようなものがある。映像の文法だ。 編集するヒトがその意図を読まなければ、良い映像がつくれない。 逆に撮影する人や監督とか撮影させる人は、どういう意図があるのかを 編集する人が理解できる形で映像中に織り込まなければならない。 映像の言語だ。 で、問題となるのはその映像の文法なり言語なりは経験を積まなければ 絶対に身につけることができないことなのである。 英文法の教科書だけでは英会話できるようにならないのと同じ。 素人とプロの差というのはそういう部分に現れる。

一応、映像の文法を解説した教科書はある。 とくにアメリカの映像業界では大学での教育分野としてなりたっている。 だからそういう本を何冊かよんでみたが、当然ながらそんな具合いに教科書を読んだぐらいでは現場で使えるようにはならない。 コンピューターの世界でも同じだが、最低でも５年、１０年ぐらい下働きで やっと半人前というところが普通の人だろう。 才能のある人で３０代ぐらいから芽がではじめる。

そういうわけで、はやりちゃんと人に見せられるようなものをつくるにはプロに手を貸してもらう必要がある。 ところが、この人たちは人件費が高い。 人件費が高いだけの仕事はしてくれるのだが、 それだと頼む側が、とくに拡販に関係した内容だったりすると、 ペイしないケースが多い。 いままで３つの仕事が結局立ち消えになってしまっている。

セミナーの撮影なんて、最初の挨拶が終わったらスクリーンにカメラ固定でやるだろうからあまり関係はないだろうとは思う。 資料なんてパワポかなにかを別途ダウンロードすれば良いので、 むしろ音声が重要になる。 こういう対象なら、カメラ数台に二人で撮影で十分いけるんじゃないかとも思ったりする。

こんな具合いに、ソフト屋のサイドビジネスとしてけっこう真面目に事業化を 考えたりしたこともあったのだが、損益分岐点がいまいちはっきりしないので 未だ継続的な事業としては実現していない。 この手の決断力と行動力の違いが、経営できる人とできない人の違いなのだろうか。

「映画『アイ、ロボット』」（行動記録／日記）

◇ ◀ ▲ ▶

実時間も脳内時間も余裕がないのだが、煮詰まっていてもなんなので、気分転換もかねて観にいってきた。

ストーリーがちゃちすぎ。あれじゃあ、アシモフも草葉の陰で泣いている。

アシモフのエピソードをいくつか都合よく合成しただけという感じで、練りがたりない。 しょっぱなからつぎはぎ部分がみえてしまって興がそがれた。

まず第一に三原則を破る事ができるロボットをどうやって作れたのかについて、 まったく説明らしい説明がない。 原作では、最後の謎解きで三原則にまつわる緻密なロジック展開があっぱれなのに、 映画ではそういうところがない。

映画のなかのエピソードに、事故にあった被害者を助けるロボットが、 救助の成功確率４５％の刑事を救い、１１％の子供を見捨てると いうのがある。が、アシモフだったらそういう話の展開にはしないだろう。 １１％にしろ人間に危害が加わる可能性がある以上、 ロボットは第一原則に束縛されてそこを離れることができずに、 なんらかの機能障害を起こすとか、だれもが予想していなかった 行動をとるとするのがアシモフ流だと思う。

次に第ゼロ原則の成立過程をあっさりスルーしすぎ。 上位の原則を自ら作り出せるということは、そこにはなんらかのブレークスルーなり パラダイムシフトなりがあったわけで、それがいかにすごい事なのかが表現されないと 「あ、そう」って感じで終わってしまうだけになる。 あれじゃあヴィッキーは権力欲に目がくらんだどこかの自意識過剰な 偽善者と変らないような極めて人間的な悪人でしかない。

そして、三番目で最後で最悪のは、ロボットを悪者に描いているところ。 いくら操られているからといっても、あるいは第ゼロ原則があるからといっても、 やはり積極的に意図して人間に危害をくわえてしまってはいけない。 アシモフの世界では、三原則があるがために ロボットはとことんまで善でなければ、 それはアシモフのロボットでないと、そう思う。

これではアシモフが好きな人は納得できないだろうなぁ。

もっとも、さすがウィル・スミスのアクション映画だけあって、 SFX満載の映像の迫力はスピード感の相乗効果もあって、 充分見ものであったと思う。 ただ、ちょっと奥行きがたりなかったかな、と。 すぐに思いつくのではスターウォーズのエピソード１がそうだったが、 ああいうふうにロボットがずらっと並ぶようなシーンでは、 引いた画で奥行きがあるからこそ迫力がでるのだ。 他に街中の雑踏なども、もうちょっと引いた画で近未来的なところと 現代的なところが交じり合っている部分を 俯瞰するようなものがあったほうが臨場感がでただろうと思う。

夢を見る能力が心につながるというのには、その世界観にちょっと安心。 サニーは兄弟たちをどこに導くのだろうか。

「我はソフト開発者」（OO百韻）

◇ ◀ ▲ ▶

ロボット工学の三原則とは次のようなもので、アイザック・アシモフのＳＦ小説“I, Robot(邦訳：我はロボット)”で提唱され、彼の後の作品群で基礎的な役割を担っているだけでなく、この分野のＳＦ小説に絶大な影響を与えた。

また、彼は後にこの三原則のさらに上位に位置するものを考案した。

三原則の中ののロボットという言葉は、ツールとかエージェント(執行者)という言葉で置き換えても十分通用する。 例えば、ロボットを家電製品とか人間で置換えたらどうなるであろうか。 文言は文意に合わせて多少変えてある。

要するに家電製品の安全性、利便性、耐久性、そして社会に対する貢献性を表しているにすぎない。

「危害や損害を加えないこと」を「幸福を追及すること」とか「社会に貢献すること」と意訳してある。 法治国家においては、建前に過ぎないにしても、どこもがこれら原則と意味として同等なものを掲げているだろう。

語句の組み合わせによっては無理があるケースも少なからずあるが、 うまく用語を選べばだいたいにおいてどんな場合にでも通用する概念で、 しかもこの原則に乗っ取って構築された社会は一種のユートピアといっても良いだろうと思う。

ただし、人間がユートピアを追及するとどうなってしまうかについては、 ２０世紀の社会主義国家がその一例を示してしまっていると思う。 あの社会体制はそこに属する全ての人間が完全な善人でなければ なりたたない。 人類がユートピアを実現するにはまだまだ未熟であることの好例であろう。

話がきなくさくなるので、強引にソフト開発に結びつけて考えてみる。

はたしてこの原則はソフト産業にも通用するものなのだろうか。 最近はやりの一部のコミュニティにどっぷりはまっているひとたちには熱烈歓迎されるスローガンなのではないだろうかと想像する。 一般論としては、第０条は別にして、どのソフト開発者も少なくとも目指していることはたしかだろう。 なぜなら、次の「三原則の否定」を全面的に認める人はまずいないだろうからである。

ほとんど例外なく、この「三原則の否定」は表向きはアンチテーゼとしてとらえられる。 しかしよくよく注意して聞いていると、部分的にはこの「三原則の否定」を主張している場合も少なからずあり、そんなときはなんとなく、経営者対労働者とか資本主義対共産主義の戦いをまのあたりにした気分になる。

しかし、個人的にはナッシュ均衡解の考え方のほうが現実的で好きだ。 これは自分が善人でないことの証拠なのかもしれないが。

果して、ソフト産業はユートピアに到達できるのだろうか。

「デスクトップ緑化計画」（行動記録／日記）

◇ ◀ ▲ ▶

最近異様に目が疲れる。 目の裏側あたりと首の後ろのほうとかが、すぐ痛くなる。

そしたら、ディスプレイを暗くしたり、画面のデザインで色設定を緑色ベースにすれば、目に負担がかからないので良いと話を聞いたので、さっそくやってみた。 ディスプレイのブライトネスとコントラストはすでにもうかなり弱く設定してあるので、今以上に暗くするのはちょっとためらう。 となれば、あとは画面のデザインの調節だ。 タイトルバーとか背景とか、とにかく色を指定できるところは全て緑色ベースに変更してみた。 ついでにエディターなども背景を緑ベースにして画面が極力緑色になるようにしてみた。

で、設定していて思いだしたのが、自分は色盲であること。 色が全く分からないのではない。 というより、自分では分かっているつもりなのだが、 検査すると色弱ではなく色盲と判定されてしまう。 いままでこれで困ったことや不便だったこともないし、 これを理由に進路が閉ざされたとかいうこともない。 自分が色盲であることを認識するような場面にでくわしたことも 生まれてからいままでで数回しかない。

第二色盲なので、緑色の認識が不完全かなにかで、 そのところで見えかたがふつうではないはず。 一応、RGBの値で設定しているので緑色になっているはずではあるが。 正しく緑色ベースのデスクトップになっているものなのか、 本当のところは自分では自信をもって判定できないというのがちょっと難だ。

こういう人間の場合に、緑色ベースのデスクトップにして、 果して疲れ目への効果はあるだろうか。

「MySQL移行で表面化したバグ」（MT導入と改造）

◇ ◀ ▲ ▶

データベースをMySQLに移行して以来、サイドバーにある“Recent Updates”が正しく表示されていなかった。

Wiki部分の改良によって正しく表示されていなかったエントリーの一部を修正した。 そういうエントリーは昔に書いたものであっても“Recent Updates”のリストのトップにきてもらわなくては困る。 ところがある程度以前のものはリストにでてこない。

Template\Context.pmのコードを追ったり、 デバッグ出力をだしたりして試行錯誤してみた結果、 どうやらこういうことらしい。

• まずcreated_onにしたがって、とりあえずエントリーのリストを作成
• MTEntryタグのlastnで指定された順番でリストを足きり
• MTEntryタグにsort_byがある場合はソートしなおし

現在“Recent Updates”はlastn=20で上位２０エントリーに制限してあるので、 ２０エントリー以前のエントリーは、そもそもsort_byで指定したソートの 対象になっていなかったというのが、事の真相のようである。

最初は、以前のperlのリスト処理だと全エントリーがソートの対象になるが、 データベース移行後はMySQL固有部分のコードがSELECT文発行の段階で LIMITとかをかけているのかとかデータベースがらみだろう と思っていたが、そうではなかったらしい。

とりあえずcreated_onでソートしたリストを作成している部分を、 ちゃんとsort_byの内容にしたがってソートするようにして問題は解決。

今回オブジェクトストアの部分をみていて分かったのだが、 MT2.6のコードはあまりデータベースを意識した作りにはなってないなぁ。 単純にデータの保存以外にはDBMSを使っていないので、 データへのアクセス速度の面以外ではあまりDBMSを有効活用していない感じ。

「御見積書」（行動記録／日記）

◇ ◀ ▲ ▶

１０年来のお付き合いのあるところが、見積り書をだしてくれというようになった。 何年か前から、外注には見積り書を要求していたそうだが、 私のところはそういうシステムになる以前からのつき合いであったので、 先方で代りにやってくれていたそうである。

昔は仕事が終わったあたりでお金が振り込まれていて、 請求書をだしてといわれてそれですんでいた。 請求書をださないままに入金があったりして、 双方で忘れていたもんだから売上から洩れてしまい、 後に税務調査が入ったときに追徴されたりもした。 さすがに青色にしてからはそういうことはないが。

永年フリーでやってきて、延べだったら１０社は越えていると思うが、 現在は４社が継続的に仕事上のおつきあいがあるが、 実は見積り書を要求されたのは今回が初めてである。

で、見積り書に何を書いたらよいものやら困った。

見積りといっても、こちらが金額を提示したわけではない。 「いつごろまでに、こんなことを、いくらぐらいでやってほしい」というので、 「やりましょう」となっただけ。 永年のつきあいがあるところだと「できません」とはなかなか言えない。 今回はずいぶん働かせてしまったから、次回はちょっと色を付けますとか、 その逆とかでお互いに融通しあってきた面もちょっとはある。 もちろん、相手もとんでもない無茶や、実現可能性の低いことは頼んでこない。

だから見積りも相手の言い値がこちらの見積り額になる。

私の仕事のようにニッチなところにどっぷりはまっている場合、 見積りというのはどういうふうにしたら良いのだろうか。 わからない。

だいたいから、仕事が始まる当初のうちは、アバウトかつ詳細不明な話がほとんどである。 ４次元のベクトルを画面に３Ｄ表示するソフトとか、 携帯カメラの画像から背景画像をとり除くソフトとか、 OpenSSLとコンパチだがウィンドウズのセキュリティ機能だけで実現するスタックとか、 最近のものでもそんなのばっかりだ。 かつてやった仕事でも、戦闘機とか原子力プラントのＸ線写真の自動解析技術の確立の ための試験研究とかで、研究の結果ボツになり、結局ソフトとしては世にでなかったもの とかもある。

結局、最初に仕事の打診があったときの「いつまで、いくらぐらい」だけが 確定した要素で、あとは全てそれにあわせていくことになる。

こういう具合いに、やってみてその結果で次がきまるような仕事の場合、 見積りというのはどうあるべきなのだろうか。 こういった仕事であらかじめ工数が見積もれるのなら、 その方法を是非知りたい。 果たして人月計算から解放される日はくるのか。

「ニフティのフォーラムが消える…」（OO百韻）

◇ ◀ ▲ ▶

ニフティサーブのフォーラムがなくなるそうだ。

ここ２～３年は全然ごぶさたしているのだが、 無くなってしまうと聞くとなんだか感慨深いものがある。

ニフティに入会したのは９１年からだから、かれこれ１３年たつわけだ。 ずっとむかしにCompuServeもMIXもなくなってしまったし、 通信環境もずいぶんさまがわりした。

昔はニフティだとケチアクセスとか課金をいかに減らすかにない知恵を搾ったものだが、 それでもなんにもしてないような月でも最低でも２～３万は通信にかかっていたなぁ。 MIXのtelnetがポート指定で接続できたからhttpとかgopherとかは 通信ソフトに手を加えてMIXのパソコン通信の接続を経由するような 涙ぐましいことをやっていたことを思いだす。 そのMIXも無くなって久しい。

当時は常時接続なんて夢のまた夢だったなぁ。

「e－文書法」（行動記録／日記）

◇ ◀ ▲ ▶

e－文書法が１９日国会で成立したとのこと。

いわゆる電子ファイリングシステムに関連したソフトの開発にかかわったことがあるので、 eJapan戦略などちょっとは気になっていた。 この法律は他の法律の上位に位置するので、一挙に文書の電子保存ができるようになるらしいので、 政府にしてはめずらしく気配りがなされているように感じた。 実際どうなるかは乞うご期待というところか。 現場では抵抗するところも多いのではないだろうか。

自分に直接かかわってくる税務に関しては３万円未満が電子保存できるようになるらしい。 だが、証明方法をどうするのか具体的な話が見えてこないから、今後注意してみていきたい。

文書をスキャナーなどにとりこんで電子的にためこむだけなら、 医療画像のように大量の巨大データでなければ、 それはいたって簡単な話である。 問題となるのは、電子化したデータの証明の部分で、データが同じかどうかとか 改竄がないかどうかとか、そして、そういったことをだれがどうやって証明するかという 部分がキーポイントとなる。 だから認証サーバーの提供などもちゃんと考えられてなければ意味がない。 しかし、領収書をスキャナーで取り込むたびに証明のためにどこかにお金を払うのも嫌だ。 できれば政府主導でやってもらいたいもんだ。 住基ネットなんかよりよっぽど社会に密接にかかわってくるはずだと思う。

また、例えば税務関係とかなら、領収書など個々にしろ総量にしろデータ量はたいしたことないが、 検索とかについてもけっこう重要な要素になるだろうと思う。 ソフトの開発側としても利用側としても、そんな場合にはDBMSの利用が前提になるだろうが、 例えば税務調査で５年前のデータを見たいとか突然いわれて閲覧環境の不備などで慌てるのもこまる。 そういうわけでXMLなんかは、データの扱いの面でトレードオフとして最適解の一つとなるだろう。 昨今のDBMSはXMLの外部データをそのままデータベースとして利用するにはどの程度の手間を 必要とするのだろうか。 ワードとエクセルを触った事あるていどの事務のおやじとかでも 簡単に扱えるようなものであれば良いのだが。

今回の動きは、とりあえず法律面での外堀が埋まるメドがついたというところだろう。 天守閣まではまだ遠そうだ。

参考：

• 内閣官房　国会提出法案

「ホイール付き光学式マウス」（行動記録／日記）

◇ ◀ ▲ ▶

何年か使っていたホイール付き光学式マウスが壊れてしまった。 ホイールが空回りしてしまうのだ。 かなりフラストレーションがたまる。

マウスは、まったく使わないか、そればかり使うかのどちらかである。 仕事上、ソースコードをいじる時間がほとんどなのだが、 エディターにはviを使っている。 viがデスクトップ上にでている間はほとんどマウスは使わず、 マウスを使っている間はviがでていないといった状況になっている。

viを使うのは昔Unix上で仕事していたときの名残なのだが、 一時期Emacsに転んだことがあった。 しばらくのあいだは、かなりはまり込んで「Emacsサイコー」状態で、 会う人会う人にすすめたりもしていた。 当時はサラリーマンだったのだが、上司がちょっとアレな人間で 彼曰く「emacs使えなければ技術者にあらず」とおっしゃる。 それに反発してemacsを使うのは止めた。

後にもっぱらDOS上で作業するようになるのだが、 自分の指にあうエディターがなくてしばらくは不自由な思いをした。 結局UnixのフリーのviクローンをDOSに移植して使うようになった。 DOS上に移植したEmacsなど使うわけもない。 というのも、当時、仕事で組んだやつがこれまたアレなやつだったのだが、 そいつが「Demacs万歳」のやつだったからだ。 若い頃は元気があった。 結局当時のviクローンをWin32用に移植したものを今でも使っている。

そういうわけで、キャラ端ベースの作業が中心になり、 ソースも自分で持ってるわけなので、 キーボードからマウスに手を動かさずにすむようにviが改造されていく。 かくしてviで作業している間はほとんどマウスに手を触れなくても すむようになった。

逆に、ウェブの閲覧などではほとんどマウスしか使わないような感じになり、 ページを前後させる場合にはホイールに頼る事になる。 するとホイールが壊れるとすごく不便でしょうがない。 ホイールの重要性を実感してしまった。

とりあえず昔使っていた機械式マウスでホイール付きのやつを発掘して それを使っているのだが、こんどはローラーにゴミを巻き込んでポインターが滑るので困る。 やっぱり機械式の稼動部分のあるものはメンテの面で弱いなぁなどとしみじみ感じてしまった。 昔Sunのマシンのマウスは専用のマウスパッドを使った光学式だったのだが、 これはこれで使いにくかった記憶がある。

今の方式の光学式マウスを考案した人と、それを可能にしたハードウェアによる画像処理技術の進歩に感謝。

「デスクトップ緑化計画存亡の危機」（行動記録／日記）

◇ ◀ ▲ ▶

デスクトップ緑化計画 を実行して一週間経過した。効果はあったのだろうか。

おそらく一週間程度の期間ではなにか目に付くような効果は でないものなのだろう。 なにか目に見えて大きく変ったということはない。 ただ、気分的に目の裏の痛みがなくなったか減ったような気がする。 単なるプラセボ効果なのかもしれないが。

画面のデザインを変えるなどというのは、おそらく１０年以上ぶりぐらいだと思う。 昔Unixで作業していたときはMotifのデザインを自分流にするのにかなりな 労力をつぎ込んでいたのだが、Windowsになってからは しょっちゅうOSをインストしたりするので、そういうことはしない癖がついて しまっていた。インストするたびに設定するのはすごく面倒くさいわけで、 いつしかインストされた状態そのままで使い続けるようになってしまうわけだ。

それより困ったのが自己流改造viの画面だった。

このviは数あるviクローンの一つをWin32のコンソールアプリとして自分で移植したものだ。 コンソールアプリなので、カーソルの色は画面の背景色から自動的に決まってしまう。 デスクトップは緑色にしたので、カーソルは赤色になる。

なんてアクセシビリティの悪い仕様なんだ！！！　

緑色と赤色の組み合わせしか選択肢がないなんて、 「見えにくくてもなくても構わない」といっているようなものだ。

結果としてカーソルがどこにあるかがすぐにわからなくなってしまって、 ちかちかブリンクするのをたよりに画面中を探し回る羽目になってしまった。 それも、ページ移動するたびに、毎回毎回！！

これじゃあ使えない。 １日目でviの画面色の設定を変えたのはいうまでもない。 ところが、その部分ってソース中にハードコードされてるんだな。 色を変えて試してみるたびに再コンパイルだ。 色の設定はレジストリあたりからひっぱってくるようにすべきなのだが、 それにはまず画面が見え易いようにしなくてはならない。

結局、緑色系列を含む色で、もう少しましな色として水色を背景にしてみたが、 多少はましになったのだろうか？　わからない。 水色だと緑が入っているので、結局同じ事になるかもしれず、 あるいは青が入っているので目が疲れることになってしまうかもしれない。 あと、カーソルが文字の下側２０％のサイズにしていたのを ３０％のサイズに増やしてブリンクしているのをもう少し見つけ易いようにした。 これも効果があるのやらもうしばらく使いつづけてみないことには なんともいえない。

デスクトップ緑化計画は、ひょんなところで挫折しかかっている。

「読書『数学は科学の女王にして奴隷Ⅰ・Ⅱ』」（行動記録／日記）

◇ ◀ ▲ ▶

これからは読んだ本も日記ネタにしよう。

この本は実は１週間以上前に読み終わったのだが、遡って日記にしてみたい。

面白い本である。そして、広範囲に渡る人に対して役にたつ本だと思う。 いわゆる文系の人でも理系の人でも(こういう区分けが許されるとして)、 ふだん数学と全く無縁であったとしても、 一種の一般教養の延長にある読み物として充分価値のあるものであると思う。 そして多少とも数学になじみがある人には知識の偏りを見直す良い機会になる。

数学の本といってもむずかしい数式などは全くでてこない。 とり上げる内容もかなり古く、最近の話題とはかけ離れている。 その分、むしろ数学の各分野の背景に横たわる数学的な考え方を著者なりに わかりやすく説明している点で読む価値があるといえる。 多くの人がもつ誤解と裏腹に、数学とは数字だけで構成される無味乾燥で 冷血な別世界のできごとではなく、非常に身近な「考え方の学問」である ことが多少とも理解できるならば、著者も大よろこびだろう。

多少癖がないこともない。著者独特の暴言も散見される。 暴言といっても全く害のないものなので、それがかえって面白い。 おそらく著者の数学を通した世界観がとても平和なものであるからだと思う。

「index.rdfのアクセスログ大爆発の兆し」（MT導入と改造）

◇ ◀ ▲ ▶

なんか、５分ないし１０分に一度index.rdfを読み込んでくるところが ２～３日前から目立ちはじめた。１日に少なくとも２００はアクセスしてくる。

自分の書いたものを読んでくれる人がいるというのは、 なんとなく気恥しい面もありはするが、 それなりに気合いが入ろうというものでもある。 そういう意味で、悪意があるのでない限りは、 アクセスがあるのは大歓迎である。

だけど５分に一回おなじファイルをダウンロードするというのはちょっとやりすぎではないか。 ２～３日で一挙にアクセスランキング上位におどりでてしまった。 うちのindex.rdfはそんなに頻繁にみても内容は変わっていない。 そもそもHTTPのGETで見にくる前にHEADをとるなどやっても よさそうなのだが、それもやっていない。 このようなアクセスは、無駄に帯域を消費しているように感じる。

USER_AGENTをみてみたらMagpieRSSというやつだ。 インターネットで検索してみたらオープンソースのRSSリーダーらしい。 ブログ集約サイトなどから更新データを引っ張ってくることを前提にしているのだろう。 ならばなおさら帯域には気を払うべきだと思うが、 ツールが悪いのではなく使い方がタコなんだろうと思っている。 中身はみてないけど、オープンソースのRSSリーダーともあろうものが、 ５分に１回無条件にrdfをダウンロードするなどという、 そんなタコな仕様でつくられているはずはないと信じたい。

一瞬、いっそのことIPでみきわめて、 そのホストからのアクセスをはねてやろうとも思ったが、 とりあえずはそこまでするのは止めた。 ファイルの性質上アクセス制御しなくてはならないもの以外は、 できるかぎり差別なくアクセス可能なものでありたいと思っている。 そういうわけでindex.rdfはアクセスログの候補から外した。 データベースのほうも該当するレコードは削除した。 こういうときファイルベースではなくDBMSだと楽だ。 早くも、データベースを移行したメリットがでた。

「クレーム」（行動記録／日記）

◇ ◀ ▲ ▶

来年結婚式を行なうのだが、だれを呼ぶかで本家からクレームが入ってしまった。

本当はごく近しい親戚だけで最小限のささやかなものにしたかったのだが、 そうはいかずだんだん話が大きくなってくる。 だいたいから本家分家なんていつの時代の話だよと思うし、 そんなことにこだわるほど由緒がある家柄でもないだろうに。

何年か前に本家の総領がいとこに代替りしたので、 叔父叔母の世代ではなくいとこの世代を中心に呼ぶことにしたのだが、 それがまずかったらしい。 しかも呼ぶ面子も全員ではなく家から一人を基本にした。 父親とはそういうところで了解をとっていたのだが、 田舎にそれは通用しなかった。 しかも事前にお窺いしなかったあたりが引っかかってしまったようだ。 私なんか家系からすればアウトサイダーみたいなものなんだから 細かいことはいいじゃないかとも思うのだが、そうはいかないらしい。 分家というのはどこまででも本家に従うものということのようだ。

急きょ追加で招待状をだすことになり、予算オーバーだ。

来年はマシンを１台新調しようと思ってたんだけどなぁ…。

「読書『すべてのまぼろしはキンタナ・ローの海に消えた』」（行動記録／日記）

◇ ◀ ▲ ▶

ティプトリーというと、CIA創設時のメンバーだったとか、 あらかじめの取り決めで寝たきりになった配偶者を銃で撃ち殺して自分も自殺したとか、 生前は「フェミニズム小説を書く唯一の男性作家」と評されながら後になって実は女性だったことが発覚したとか、 その過激さからプロフィールのほうばかりが注目されてしまうのかもしれない。

が、そんなことはどうでもいいはなしである。 彼女の作品はどれも、その読後感が長く尾を引くあたりで、 自分としてはいつも気になってしまう。 ただ、今回のは感情移入するにはちょっとパワー不足な感が否めない。 ティプトリー唯一のファンタジーというのもあるかもしれないが、 それよりも字が大きすぎとかうすっぺらすぎとか 出版社の最近のあざといやり方が勝ってしまってそう感じさせるのかもしれない。

読後感が長く尾を引くといっても、うまく言葉に表すのは難しい。 彼女の書く作品中の人や物が、 なんらかの意味で周囲から隔絶されているのに、 当人たちが表向きはそれに全く無頓着で何も意識して いないようなところがあって、それがなんとなく引っかかるのだろうか。 なんとなくスクリーンかガラス越しにそれをみせつけられているようで それが気になるのだろうか。

今回の作品もやはり周囲からある意味で疎外された人が主人公だ。 その主人公からまた聞きの形で聞かされる(こわくない)オカルトと いうのがこの作品。 世捨て人のホラ話ともとれる内容ばかりだが、 どの話も時空に透明感と奥行きがあってさらりと聞いていられる。

ティプトリーにしては異色だが、根底にあるものには同じものを 感じとれる気がして安心した。

「防災訓練」（行動記録／日記）

◇ ◀ ▲ ▶

今日、朝の９時ごろ突然マンションの構内放送がなって 大音量で「防災訓練するから、とっとと非常階段でおりてこい」とのこと。 一応は起きてたんだけど、まだ半分眠った状態だったので、 思わず指示通りに動いてしまった。

で、この寒空の下、はだしにサンダル、ジーンズ、Tシャツの上に フリースのジャンバーといういでたちで３０分も消防車を眺める羽目に。 すっかり体が冷え切ってしまった。 冷え性の気があるので、１時間してもまだ手先足先が氷のようになってしまって戻らなくて、 昔切断した右手の筋も痛んでキーボード打つのもままならない。

こういうのはもうちょっと暖かい時期時間にやってほしいなぁ。 そろそろ暖房を出す季節なのかもしれない。

「欠点克服停滞率」（OO百韻）

◇ ◀ ▲ ▶

「Ryo.Matsudaのほろ酔い徒然」の１１月２４日の日記「人のアサイン」に面白い話があった。

第一印象で答えれば、Ａさんのスキルの合計点は２００点なのに対して Ｂさんのスキルは高々３０点なので、Ａさんがすごすぎだとしても Ｂさんは明らかに半人前に見受けられる。 半人前の人間はベテランの下に付けるのが無難だろうということで、 Ｂさんを単独で仕事にはアサインしないというのが考えられると思う。 するとＡの仕事もＣの仕事も両方とも、Ａさん中心＋Ｂさん補佐と いうアサインメントはありがちなやり方ではないかと思う。

Ｃの仕事はどちらにアサインしても２０点とか３０点とか しかできないのだから、そういう仕事は受注しないという選択子も 十分考慮にいれるべきなのかもしれない。 実際問題としてはこれが正解だろう。 そうやってたらいまわしにされた仕事は私のようなところにまわってくるのだが。

上の答は、どちらかをどちらかに割り当てるといったデジタルな ものではなく、アサインメントが按分できることを前提にしている。 それではどのような比率に按分するのが最適解なのだろうか。

ＡさんをスキルＡを必要とする仕事に比率ｒで割り当て残りはＢさんにやらせるとし、 同時にＡさんとＢさんの余力をスキルＣを必要とする仕事に割り当てるとする。 すると、

となるから、二つの仕事の合計は単純に足してとなる。 rは０以上１以下なのだから、この合計を最大にするのはのときである。 つまり、ＡさんをスキルＡを必要とする仕事に全力投球させ、 Ｂさんにはなにもさせない(いずれは首にする)という解釈になる。

しかし、人間というものは向上するものである(逆もあるが)。 よって、各人とも仕事が終わるとスキルが上がるとしよう。 テレビゲームでいえば戦闘が終わると経験値をゲットするようなものだ。 ただＡさんのスキルＡがすでに１００点なので、 スキルが青天井だと面白くないからちょっと凝ったシステムを考えてみる。 仕事が終わって向上するスキルは１００点までの足りない分が 仕事の点数に比例して減るとしてみよう。 例えば、ＡさんをスキルＣを必要とする仕事に按分率５０％でアサインした場合、 その仕事の点数は１０点なのだから、ＡさんスキルＣの１００点までの 残り８０点のうち１０／１００が減って７２点になり、つまりＡさんの スキル２０点が２８点に向上するとする。 こうやって何回か仕事をこなしていけば、 最初は会社にとってリスクではあるが、 メンバーのスキルがだんだんと向上していくのでうれしいという ことにはならないだろうか。検証してみよう。

しかしながら、このモデルには致命的な欠陥があって、 ＢさんはいつまでたってもスキルＣを向上させることができない。 その理由は、初期条件のＢさんのスキルＣが０点であることに起因する。 よって、かなりインチキではあるが、 ＢさんのスキルＣは最初は例えば１点とか１０点とか、０点以外の 点数をもっていたのであると設問を変更させてもらおう。

まずはこのモデルのアイディアをグラフの形にしてみた。 話を単純化して、単独で仕事をしたと限定して考えた時の スキルＣの点数が向上していく様子がプロットされている。 グラフは縦軸がスキルの点数、横軸が仕事の反復回数で、上側の折れ線から順に、90、50、30、10、5、1、0.1の初期値で始まっているものである。 Ｂさんは最初スキルＣの点数が30(上から3番目の折れ線)であるが、 仕事をこなす事７回目にはほぼパーフェクトなスキルを身につけていることがわかる。 また、同様に初期値が1のほとんど素人同然の人の場合(下から2番目)だとパーフェクトなスキルを身につけるまで １０回以上の仕事をこなす必要があることがわかる。 この場合、３～４ヶ月かかる仕事なら一人前になるまで実に３年の年月が必要ということになる。 私の見聞きした範囲でほぼ素人同然の人でも１年後にはいっぱしのプロジェクトメンバーとしてそれなりの仕事を任されてしまっている現状を考えるに、 ３ヶ月で終わるような小さな仕事だと、この３年という年月はちょっと長いかもしれない。 このような極端な例はおいていくにしても、 自分を振り返って新技術には日頃から唾をつけておいていざというときのために 最低でも初期値0.5はクリアしたいところである。

ここで、人物を表すＡ、Ｂとスキルや仕事を表すＡ、Ｂ、Ｃが紛らわしいので、 人物はa、b、スキルをu、v、wと表すことにす。 またスキルと仕事はとりあえず同一視して、スキルuを必要とする仕事も 仕事uと表すことにする(実際には仕事は複数のスキルを必要とするだろう)。 まだ、n回目の仕事が終わったときのaさんのスキルuの点数をと表すことにしよう。 初期値n=0の場合がもともとの設問となる。

すると、n回目の仕事uとwの点数とは、aさんを仕事uにアサインする按分率をr(n)と すると次のようになる。

そしてこの仕事をこなした後、各人のスキルは次のようになる。 ここで、式にいちいち満点を表す１００が入ってくるのがうっとうしいので、 またもや設問を変えて、点数は０点～１００点ではなく、０～１の値をとるとする。 すると、上記の各人のスキルの式は次のようになりすっきりする。 同様にメンバーa、b、スキルu、wのそれぞれについて点数値を 列挙すると次のようになる。 これらの式に仕事の点数Jを代入すると次の式が得られる。

ちょっとめんどうだが、これらの式は次のように変型できる。 ここで、式がごちゃごちゃしてきたので、 n-1で一回前のアサインメントを表すのではなく、 プライム＇をつけることで前回を表すようにした。

まだ、ごちゃごちゃしてみずらいので、をと置き換えてみよう。 かなりすっきりとしてずいぶんきれいな式になった。

このはなにを意味するのかというと、 １つまりスキルがパーフェクトな状態から現在のスキルを引いたわけだから、 自分のスキルで今後向上する余地、 言い換えると現在の自分の欠点を表していると考えることができる(前提として、だれもがパーフェクトな存在になることを目指しているとしている。 現実はそうではなく、自分は不完全なまま少ない労力で なるべく多くをゲットしようと腐心するのが大多数であるが)。

最終的には各DをJの式に代入して仕事の点数の合計を比べられるように なれば良いのだが、その前にこの式をもう少し掘り下げてみよう。 まず両辺をでわって、右辺から右側にあるを 取り除いてみる。 本当はこの漸化式をｎについて解きたかったのだが、 難しいので断念した。 で、急遽比率を調べてみることにしたわけである。

この式は、前回の欠点に対する今回の欠点の割合を示している。 この値が０に近付くほど多くの欠点が克服され、 １に近付くほど欠点の克服が停滞してそのままになっていることを表している。 もしかしたら１を越えてしまい、欠点が増えるようなこともあるかもしれない。 これを、ちょっと長いが、欠点克服停滞率と名付けよう。 ちなみに、 １からこれを引いてを計算したならば、 それは停滞しなかった分、つまり、前回の欠点に対する克服した欠点の比率を表すので、それは欠点克服率といってもいいだろう。

実はこの欠点克服率はだいたいスキルの曲線と同じような曲線を描くということがわかっている。 なぜなら、r=0のときを考えればとなるので、どういう初期値で始めようともＤが０以上１以下である限りはnが大きくなればなるほど０に近づくからである。 欠陥Ｄがそのように解けるなら、欠点克服率はとなる。 これと上のグラフを見比べてみて欲しい。 二乗がある分だけグラフが下側に歪むが 二乗の部分以外はほぼ同じような形をしたものになるはずだ。 本来なら一般のrについて論ずるべきだが、 それを説明するには漸化式を完全に解かねばならず、 いずれパワーのありあまっているときにでも再チャレンジしてここを埋める ことにして、今回はお茶を濁す(実はこの部分が重要だったりするのだが)。

この式は一見してちょっと常識からずれた変な部分があるように見える。 例えば、aさんならこう考えるであろう。 「自分の欠点の克服の度合が、なんであんな半人前のb君の欠点に依存するんだ？」

この疑問を追及するには、まず、rと欠点克服停滞率の関係をよくみきわめなければならない。一般性を失わない範囲で、仮定としてaさんのスキルuはb君のそれより高いとしてみる。はrについてまとめると次のようになる。

aさんのスキルuの欠点克服停滞率はrが小さいほど小さくなる。 aとbのスキルに差が大きいほど、スキルの低い方を比重を大きくして アサインしたほうが、最終的にメンバー全員のスキルの延びは停滞が 少ないことを表している。 逆にスキルの差があまりない場合は、rをどう調節しても大した違いは生じない。 また、b君のスキルuの欠点克服停滞率はaさんのそれと同じになる。 各人が別個にスキルを伸ばすのではなく、 チームとしていっしょに伸びることを示唆している。 aさんとb君はスキルの向上に関して運命共同体なのである。 運命共同体、これがaさんの疑問に対する答だ。

ひとつ残念なことに、このモデルではrの次数が１次なので、 r=0のときが最適解、r=1が最悪解ということになり、 当初前提にもってきたアサインメントを按分する意味が 失われてしまっている。

最後に、いよいよJに代入して会社としてトータルで何点の仕事をこなせる ようになるかを考えてみよう。とを足してDについて表したらどうなるかみてみよう。

式の最後では、仕事の点数の総合計は前回の仕事からの欠点克服率の合計になることが判る。 意外にも簡単な式になったので、当の本人もびっくりである。 下らない計算ミスなどしていなければいいのだが…。 この式の解釈は、最初はトータルの点数は悪かったとしても、 経験を積めば積むほどそれに応じて点数も上がるということになる。 上のグラフでは単独で一つの仕事をした場合の話だったが、 チーム全体でも同様のことが起こる。

要するに、

• 欠点の多い部分にこそ戦力を投入せよ
• 直近の利益より、長期的視点にたて
• 個々のスキルはみんなで一丸になって伸ばそう
• 何度でも反復して精進することが大事
• さすれば、いつかはパーフェクトな存在になれれる

ということだ。 学校などで、「苦手科目の克服こそが勉強の王道」などとできの悪い生徒に 渇を入れる熱血教師とかが言いそうな内容である。

rの按分については、Ryo.Matsuda氏の日記だと、r=0の場合とr=1の場合が 挙げられている。r=0の場合とは、ＡさんをスキルＣの仕事に割り当て、 ＢさんをスキルＡの仕事に割り当てた場合に相当し、r=1の場合とは、 ＡさんをスキルＡの仕事に割り当てもう一方の仕事は事実上断わる というものであった。 ちなみに、仕事の点数はそれぞれ合計５０点と合計１００点になる。 だから後者のr=1のケースを採用したほうが、 会社としてはトータルでは高い点数の仕事をしたことになる。 その場合、Ａさんはいつでも１００点の仕事をし、 会社としては二つの仕事で合わせて１００点平均して５０点の 仕事を延々と行ない、 おそらく首になったであろうＢさんはいつまでたっても３０点のスキルしかもてず、 自分よりスキルの低い人ばかりのところにたどりつくまではいつまでたっても日の目をみれず転職を繰り返すというのがこのケースの解釈である。

一方、r=0のケースでは、最初は二つの仕事で合わせて５０点 平均して２５点の結果しかだせなかったが、 同じ仕事を何回も行なううちにだんだんとちょっとづつ良い点数で行なえる ようになり、十分時間をかければ合わせて２００点平均して１００点の仕事を こなせるようになる。 メンバーにスキルが低い人がいて、 たとえ点数の低い仕事しかできなかったとしても、 しばらくの間はおたがい融通しあって辛抱強く仕事をこなしていきけば、 いつかは必ずむくわれるという非常にハッピーエンドな世界が このモデルの結論である。

このモデルでは、前提として仕事をするたびに欠点が克服されるという 非常に楽天的な仮定が根底にあった。 しかも、欠点が多い人ほど克服する分が多いというきわめて乱暴な 条件でつくられたモデルである。 しかも、最も奇妙キテレツなこととして、 チームのだれかがある割合で欠点を克服しスキルを向上させると、 他のメンバー全てが同じ克服率を達成できてしまうことだろう。 向上したスキルのレベルは人それぞれだが、 仕事が終わるたびに同じ割合だけ欠点が克服されていくのだ。 これはまったくもっておかしい話に聞こえる。 現実の世界はそういう具合いに簡単なものではないので、 そういう意味でここでの結論は数字遊び以外のなにものでもないだろう。

上で欠点克服率の漸化式は一般のrについては解かなかった。 もしかすると、漸化式を完全に解き、 毎回仕事をアサインするたびにｒを変えるなどすると、 より現実的な解が得られるのかもしれない。 こういうところにもモデルが現実的でないように感じる原因がある。 また、自分のスキルが相手の欠点克服に依存するのは、 仕事が終わってスキルの点数を増加させるときに、 r=0のときなど実質上自分が関与していない仕事の場合でも 自分の経験値に加えてしまうあたりが原因にあるのだろう。 このあたりは改良の余地がたくさんある。 しかし、この単純だがあまり現実的でないこのモデルが、 社会主義的な結論に導かれたのはある意味示唆的であるとも思う。

ちなみに、十分に検算をしているとはいい難いので、 どこかで下らない計算ミスをしていて、 そのため結論が全く間違ったものである可能性もかなりある。 その場合は悪しからずご了承願いたい。

「国営昭和記念公園」（行動記録／日記）

◇ ◀ ▲ ▶

今日は立川にある国営昭和記念公園にいってきました。

天気がいいなぁと思って、１０時すぎてから突然思い立って、１１時すぎには出発しました。 １２時ごろに西立川について、駅の南側の東急ストアで弁当を買い、北側にある西立川口から入園。入園料は大人一人４００円。ちょっと高い気も無きにしも非ず。

池を回りこんだあたりの芝生の斜面にシートを広げ、 弁当を食べ一休みしてると眼の前のサイクリングロードに 自転車が走っているのが見えます。 スイスイと楽しそうなので自転車を借りる事に。 自転車は３時間で４１０円。 １時過ぎから借りたので４時ぐらいまで乗れる。 大人用の自転車はママチャリなので最初はちょっと不満だったのだけど、 サイクリング専用道が整備されていてそんなこと気にならないほど 気持ちがいい。

園内はどこに行っても紅葉がきれいで、時期的には今がベストコンディションだったのではないかと思います。 日本庭園などを巡り子供の森のブルーベリーヨーグルト味のソフトクリームを 食べたりしました。全体を１周りしてから３時すぎまで のんびりとサイクリングして、 日が陰って風が冷たくなってきたのでもどることに。 ちょっと早めに４時前には自転車を返して公園をでました。

立川口のドッグランで犬が遊んでるのを眺めてから 立川駅まであるいて、それから帰途につきました。

こういうときにいつも持ち歩く行楽グッズにはバーナーと コップ、コーヒーとかの即席喫茶セットや キャッチボールの道具などがあるのだが、 今回はレンタル自転車があったためにまったく利用しなかった。 次回はもっと早くから行って公園を満喫しようと心に決めた。

タイムテーブル

11時過ぎ	出発
12時ごろ	西立川駅
12時半前	入園
1時過ぎ	自転車レンタル
4時前	退園
4時半前	立川駅
5時ごろ	帰宅

出費

往復交通費	760円
入園料	400円
飲食	約500円
自転車レンタル	410円
(合計)	約2000円

「欠点克服停滞率(改)」（OO百韻）

◇ ◀ ▲ ▶

前回の「欠点克服停滞率」では その時の都合で条件を限定したモデルを作った。 その結果は主観的に実状に即しているとは言いがたいようなものであった。 少なくとも自分的には。

そこでもう少し改良の余地はないものかと思い、 基本線は維持しながらこのモデルの前提を若干見直してみることにした。

• 人物の数は二人ではなく不特定多数に。a、bの二人からa、b、c、...へ拡張。
• 仕事の数も二人ではなく不特定多数に。u、wの二種類からu、v、w、...へ拡張。
• 一つの仕事が終わった後の経験値のフィードバックを定数ではなくす。

上記の条件で前回のモデルを一般化したらどうなるであろうか。 前回のモデルを拡張していく方向でやってみる。 まず仕事の点数であるが、仕事のアサインメントを前回のrから、 人物iを仕事jに割り当てたときの配分をとし、 人物iがもつ仕事jを必要とするスキルの点数をとすると、 次のようになる。 ちなみに、もも前回同様レンジは0から1の間である。

の合計が１なので、各仕事の点数はアサインメントの配分による 全メンバーの加重平均になっている。

を使ってもうちょっと簡略化する。

スキルは欠点の形の方が式が扱いやすいことは前回すでにわかっていたので、ついでに仕事JのDによる式の形も今のうちに計算しておこう。

同様に、スキルSは次のようになる。 ただし、前回の定数１と違い、 今回は人物iが仕事jを終えた時にそのスキルにフィードバックされる 係数としてを導入しよう。

これもDによる式に変形しておこう。 このDの式中のJに上で出しておいた式を代入する。 この漸化式を解くのが難しいのは相変わらずである。 ちなみに、この式からただちに次の欠点克服停滞率と欠点克服率が得られる。 この欠点克服停滞率を使って仕事の式を変形すると次のものが得られる。 ここで、人物を表す添え字が特定の人物aになっている。 これはある人物の欠点克服の度合いが他の人物の欠点と割り当て、 フィードバックの値などから算出され、 チーム全体で共通したものになるため このように特定の人物のデータのみから計算されるように見えるだけだからである。 要するに、仕事の評価というのはメンバーのだれの欠点をベースに算出するかによらないということである。

仕事全体では次のようになる。

前回はを1にしていたので、基本的に前回の結果と同じである。

結局、この程度の一般化ではたいした違いはないというだけのことのようだ。 rやfを工夫すればなにか出てきるかもしれないが、 どうやら欠点をと定義して、パーフェクトからのスキルの差としてしまう以上は似たり寄ったりの結果しか得られないような気がしてきた。 ちょっとがっくり。

ともあれ、これまでをまとめておこう。

最後の式は、適当に選んだある人物aについて、欠点克服率をフィードバック係数で割ったものを全てのスキルについて合計すると、それが仕事全体の評価になるという解釈ができる。

欠点が上記のように定義されていて、 スキルの向上が仕事の結果で決まるとしている限りは、 どのようにモデルを作っても、 個人のスキルの向上は他のメンバーのスキルの向上に依存してみんなでいっしょに向上して それが全員の仕事全ての評価になるということなのかもしれない。

このモデルを追求すれば、人のアサインメントに対する仕事の点数という ものから一般化して、リソースの配分における全体の評価の一般モデルに 関して漠然と何か知見が得られるかもしれないと期待していた。 しかし、具体的なrとfについて何か面白い結果がでるまではたいしたことは わからないということがわかった。 いつか気が向いたらさらに追求してみよう。

「読書『呪文の織り手 <デイルマーク王国史3>』」（行動記録／日記）

◇ ◀ ▲ ▶

宮崎駿効果とでもいうのだろうか。 デイルマーク王国史は長らく待ち続けていたのだが、 ここのところ毎月立て続けにでてきて、 ちょっと拍子抜けの感も無きにしもあらず。

四部作のうちの第三部なのでクライマックスはまだまだこれから。 というより、やっと駒がそろってこれから話が始まるというところだろう。 第一部と第二部では、時代背景や社会背景は同じくするものの、 描かれるエピソードにはあまり直接的なつながりは見えない。 第三部は、時代がまったく違うものではあるが、 物語全体の源流とでもいう位置づけになっている。

ここで描かれる子供たちはみなたくましい。 エネルギーがある。 周囲の大人たちに翻弄されながらも、 結局は自分自身で考え、答えを出し、道を切り開いていく。 といっても単に子供が独力で苦難の道を行くというわけではなく、 必ず味方になる大人が用意されていて読んでいて安心感がある。

この手の物語は得てして叙事的記録的なものになりがちだが、 この作者の話は生活感があって子供たち同士の悪ふざけなども ちゃんと描かれているし、登場人物のそれぞれ別個の個性が 書き分けられており臨場感があって良い。 これは翻訳者の能力にも負っているのだろうが。

最終章の第四部が楽しみである。

「メルマガもどきのスパム」（行動記録／日記）

◇ ◀ ▲ ▶

形式そのものは非常に一般的なメルマガの形式にのっとっていて 解除ページへのリンクなどもあるのだが、 内容は全くのアダルトコンテンツ以外のなにものでもないというメールが届くようになった。 登録した覚えもないいし、登録確認のメールもない メルマガがとつぜん届くようになるのが怪しい。

うっとうしいから配信を停止させたい。 しかし、下手にリンクにある解除ページにいくと フィッシングだったりするかもしれない。 あるいは、そうでなくても解除て手続きを行うこと自体が 自分のメールアドレスの生存確認を取ってあげることにもなりかねない。 かといって何もしなければ配信停止を望んでいないということで いつまでもスパムが届きかねない。

ちょっと悩んだ末にまずページが変なスクリプトや画像を含んでいないかチェックしてみる。

これは大丈夫そうだ。 フォームでメールアドレスを送るようになっている以外、画像もスクリプトもない、 ほとんど何でもないページだ。

次に、フォームの解除したい自分のメールアドレスを入力するところに、 でたらめなアドレスを入れてみる。

解除ボタンをクリックしたら瞬時に「解除ありがとうございます」とかでてきた。

これは危険だ。アドレス収集画面である可能性がある。 下手に自分のアドレスを入力するとそれをきっかけにして新たなスパムが届くようになってしまうかもしれない。

これはちょっと様子見だな。 またくるようだったら迷惑メール相談センターのアドレスで解除手続きをしてやろう。