また、スキャンダル的な部分を除けば、いろんなプロジェクトに共通することなので、一つの「寓話」として読んでもらうといいかも知れない。

特許庁のプロジェクトがコケたって話はあちこちで語られ、いい話のネタになっているようなんだけど、私が知っている範囲では、そういった綺麗な失敗ではない。

くどいようだが、話の断片を憶測でつないだことだから、その辺は用心して読むように。実はfacebookにちょろっと書いたんだけど、もうちょっと整理して書いておく。

「特許庁」のプロジェクトは、実は始まった時くらいに誘われていた。そういった話を持って来た人がいたからだ。あれだけの大プロジェクトに「その人」がなんで関わっていたかは知らない。まぁ当時は「その人」はそれなりに信用していた部分もあったので、「デカいコンサルもやってるんだな」と思っていた。

当初は

君はSIerを指揮するだけでいいよ

という話だった。コピーはダメってことだったのでプロジェクトの概要は見ただけなんだけど、「特許システムのあるべき姿を追求した」という話で、途方もなくデカい話だった。金額は「だいたい50億くらい」って言ってたように思う。当然、そんなプロジェクトは顧客の協力が大事だから、回せるのかと聞くわけだけど、「日本の特許政策の未来がかかっているプロジェクトだから、特許庁はそーゆーシフトを敷いてやる」という話だった。

その後に会った時には、「SE 50人くらいいない？」って話が出た。当時はまだ某社に勤めていた頃で、某社にはそんなにSEはいないから、「無理」と言って断わった。私が某社を辞めたこともあり、そこで話は終わっている。

ここからしばらくは、「その人」と私との間にあった話だ。「特許庁」の話そのものではない。

後に「その人」は結構厄介な人になる。仕事は時々くれるのだけど、くれる仕事は無茶な仕事ばかりだった。共通するのは、

話がやたらにデカくなってる

ことだ。あまり具体的なことは書かない方がいいと思うけど、その一つは

デスマ？ いいえ時間が浪費されただけです

に書いた。これは私の認識ではまだデスマではないが、話はこじれにこじれていた。

もう終わったことなので、件のプロジェクトのことをもうちょっと書くと、どうもそのプロジェクトは何年か越しのものだったらしい。私の手に渡るまでに、3代くらい開発者が変わっている。それぞれの事情は知らないが、結局のところ「その人」の言ったことがあまりにデカ過ぎる上に、開発者の力量(能力×パワー)が不足していて、マトモな仕様になってなかった。

私が引きついだ時に膨大にあるかのように見えたドキュメント類は、実質的に

紙屑

も同然だった。複雑な計算があるものなのに、現状の計算書がバインダに止めてるだけとか、そういったのばかりだった。何も咀嚼されてないのだ。「DB設計書」もいにしえのCOBOLerが愛用していたタイプの、カラムの書いてある「ファイル設計書」の形式だったし、内容も滅茶苦茶だった。さらに「だいたい出来ている」とか言っていたシステムは、

HTMLで書かれた紙芝居

に過ぎなかった。そして、その「紙芝居」も顧客の要望を反映してないばかりか、私がいろいろ書いている最中に、どんどん増えて行く始末。

当初は私は打合せに出なくていい、開発だけしてくれればいいという話だったのだけど、いつの間にか開発会議に出ることになって、そこで唖然とする。手元にある「紙屑」に書かれたものよりも、はるかに高いレベルの要求を顧客は要求していたのだ。そして、その「要求」の元は「その人」のデカい話だった。それでいて「顧客が本当に必要だったもの」についての、詳細の打合せや実現可能性については、ほとんど出来ていなかった。ところが、工期的には末期だったので、私が打合せに出て資料を求めたり、詳細を詰める話をしようとすると、

何を今頃になって

的な態度を取られた。そりゃまーそうだろう。タイミング的に出来てて当然なんだから。

普通はまぁそれは「デスマ」になってしまうのだけど、「デカい話」の部分はバサバサ切って、どうしても稼動に必要な部分だけに絞って話を進めるようにした。幸い顧客はある種の「諦め」があったから、無理やり納得させられ、最終的には「一次開発」については仕様を絞っただけの話に落ちつかせることが出来た。まぁ、結局のところ一応納めたけど流れてしまったようだ(よく知らない)。

ここからは特許庁の話を混ぜつつ一般論。その話の「構造」をもうちょっと書く。

まず顧客には「本当に必要なもの」がある。金出してやるプロジェクトなんだから当然のことだ。ところが、そこにコンサルが入って

次期システムのあるべき姿

という「素晴しい夢」を説く。「夢」の話は楽しいし前向きだから、みんなそれに夢中になる。いつの間にか、「本当に必要なもの」は実現されて当然ということで、話から消えてしまい、「夢」の方ばかりになる。

もちろん冷静な人達は、そういった「夢」はあくまでも「夢」だと思う。それでも「現場」の多くはその「夢」が忘れられない。「夢」をベースとした要求が起きる。

プロジェクトが遅滞してヤバくなって来ると、「夢」を見ていた人達も冷静になって来る。それでもやっぱり「夢」は忘れられない。また、「夢」で浪費してしまった時間は取り返せない。

ところで、普通のシステム屋には、「普通のシステム」の規模感というものがある。それは、自分ところの能力がベースなのか、普段付き合っている顧客の資金力がベースなのか、そういったことはそれぞれだと思うのだけど、漠然と

こういったシステムはこれくらい

というイメージを持っている。それはまぁ「勘」に属することではあるけれど、影も形もないシステムの規模を見積る時には、わりと大事なものだ。もちろん精度が必要にならば、いろいろ具体的なもので埋めて行くわけだけど、それも詳細の設計に入るまでは「規模感」をベースにする。また、それが「常識の範囲」の「普通のシステム」であれば、そうそう大きく外れるものでもない。おそらく「特許庁のシステム」もそういったあたりでの入札だったんだろう。「その人」は多分入札仕様書を作る時に関わっていだんじゃないかと思う。だいたいその辺をウロウロしてる人だったから。

ところが、そこに「夢」が入ると話が難しくなって行く。「普通」とか「常識」を越えたものが入っていることが多くなっている。「だいたいこんなもんだ」と思っていたものをはるかに越えてしまうことが起きる。上に書いたシステムでは、どうも顧客は私が受けた額の20倍くらいの金を払っていたらしい。そりゃ「夢のシステム」ならそれくらい払うさ。

その次の仕事を「その人」から振られた時も、やはり同じだった。顧客の意思決定的立場の人は、完全に「夢」に乗せされていた。幸い、そこはSIerだったので、現場レベルでは納得してなかった上に、「その人」はへまをして飛んでしまった。顧客はそれで途方に暮れてしまうわけだけど、お陰で一気に舵を切り直してそれなりのところに戻せた。まぁ私は途中で離れたので、最終的にどうなったか知らないけれど、当時作っていたシステムが動いているところを見ると、いいところに落ちついたのだろう。後で話を聞いたら、そのシステムが元でいろいろ受注力がついたということなので、一応丸くおさまったようだから、まぁ結果オーライなんだけど。

「その人」が絡んだシステムで私がやったプロジェクトはだいたいそんな感じだ。話がデカくなり過ぎて、落とし前がつけられなくなったあたりに火消しで呼ばれる。

特許庁のシスウテムは、プロジェクトの体制がどーだとか、見通しはつかなかったのかとゆーいかにも失敗プロジェクトについて回るアンチパターンを元にいろいろ分析されているようだけど、もうちょっと常識的に考えてみた方がいい。

「50億」なんて巨大システム、しかも特許システムの経験がないとは言え、一流ベンダーであるはずのTSOL。しかも、天下の特許庁のシステム。もちろんそんなものが揃ったところで、コケるものはコケるのだけど、そうそう馬鹿なこともしてないはずだ。「常識」の範囲で、あんなに無様なコケ方をするとは思えない。少なくとも、何らかの収拾がついたり、片肺であっても「動かないコンピュータ」になっても、無理やりカットオーバーまでするだろう。ところがこれに関しては、「動かないコンピュータ」どころか、

動きようがないコンピュータ

だ。常識的に起こりえないことが常識的に起きない形で起きたってことは、つまり、常識の範囲の外のことが起きていたはずだってことだ。

思うに、あまりにデカい「夢」を見て(見されられて)しまい、その「夢」がいつまでも捨て切れず、その「夢」の実現迫り続けた。見た「夢」があまりに素敵だったものだから、「夢」は捨てられない。いや、多分、その「夢」がまさに「次期システムのあるべき姿」だと思っていたから、「夢」を捨てることとプロジェクトを捨てることはイコールだった。

「次期システムのあるべき姿」を夢見ることは、何も悪いことじゃない。てか、それがなかったら現用システムを使い続ければいい。SIerは「夢をカタチに」するものだ。富士通でなくても。

でも、「特許庁の次期システム」では、「夢」を見た方も、実は単なる「夢」で、具体的なものになってなかった。だから、作るべきものを具体的に説明が出来なかった。ベンダーとしては「説明されない夢」なんて仕様に出来ない。それでも多分、「こんな感じですか？」っていっぱい持って行ったんだと思う。でも、顧客の方は「いや、私の見た夢はこれではありません」と言うだけだった。何しろ「夢」を吹き込んだ人がいないんだから、方針も満足にない。あるのは、「とっても素敵な夢だった」という記憶だけ。

「その人」が特許庁のプロジェクトにどの程度コミットしていたかは、実のところよく知らない。だから、実は無関係だったかも知れない。でも、関係していたとすると、いろいろツジツマが合うし、そのツジツマを合わせて行くと、多分その辺でコケたんだろうなとゆーことで、ツジツマが合う。

PS.

「自分の話」と「特許庁」の話がごちゃ混ぜに見えると言われたんで、ちょっと区切りを入れてみました。

PS2.

「自称事情通の話か」って、まさしくそうなんだがｗ

そーゆーレベルの話をわざわざエントリにしたのは、「特許庁」の話というよりは、「座礁するプロジェクト」の陰にはこういった話があるよってケーススタディ足りうるから… ってのは冒頭に書いてる。実際に「その人」は私にとっては前科2犯。ケースとして十分だろう。

10の能力を持つ物を10人集めて出来ることは
1の能力を持つ物100人集めて出来ない

的なことを言う。表現とか数値はいろいろだけど、かけ算して同じ結果になっても、同じものにはならないよ的な。

でも

AKB48

ってその反例になってないか？

別にまぁこれは「AKB48」に限らず、古くは「おにゃん子」もそうだし、「モー娘」でもそうなんだけど、「大勢のユニット」ってみんな同じだ。興味のない人にとっては誰が誰だか… んで、一人一人を見ても、「普通の女の子じゃん」としか言いようがない。まぁファンにとっては違うんだろうけど。

そーゆー一人一人はどうってことないものを大勢集めても、凄いスターをどーんと置いたのには到底叶わないよ… ってのが人月disの1つの言い方だったはず。でも、「AKB48」はちゃんと

みんな揃ってスター

になった。個々の魅力は低くても、いっぱい集めたら立派にスターだ。

理由はまぁいろいろあるんだろうけど、

• プロディーサが偉い
• 実は数人のスターで持っている
• 実は表に出ないのも含めると48人よりも大勢いる

とかあるみたい。ひっくり返せば、そういったものがしっかりしていれば、元々低い能力であっても、数を集めて何とか出来るってことかも。

まぁAKB48云々はネタだけど、「人数分の能力」って、出す方法がないわけじゃないってこと。計算通りに行かないのは、能力を引き出す力がないってだけだってこと。まぁ、実はそれが大変なんだけどね。

PS.

書いた後で思ったんだけど、今時の「人月dis」する人達って、「人月の神話」

くらい読んでるよね？

IT系人材ブローカー

なんでも空気読めないしつこい人に会うのはお気の毒だよねーと思うけど、これはこれで別に悪いことでも何でもないと思うのだが。

この話、主催者目線で見れば、「勉強会開いて目ぼしい奴をスカウトしよう」とゆー話だろう。元々勉強会に来る奴ってのは、その分野に興味のある「意識の高い」奴なんだから、不特定多数を相手に「就活パーティー」やるよりも、ずっといい人材に会う確率は上がるはずだ。

仮に転職する気がない奴であっても、「面白い事例」を見て、その面白いことをやっている会社に興味を持って転職をしようかと思う… ということも十分ありうるだろう。

実際に「××勉強会で会った縁で、この度○○に転職しました」ってのは、テンプレにしたいくらいあちこちで聞く話だ。そういった話をブログで見た人材屋が、「勉強会開いてスカウト」ってことを考えたとすれば、そいつはかなり優秀だし、わかってる奴だ。

そういった意味で、この話はむしろ「いい話」の部類かも知れない。

まぁ問題があるのは、「うるせー」と言わなきゃいけないくらいしつこくアプローチして来た担当者だろうけど、それもまぁ仕事だしねぇ。

「無料です」

ってのはウラがあるんだよと。

別に「人材屋」でなくても、企業が場所をタダで貸してくれるとかって、この手のことがなかったら

やる意味がない

と言ってもいい。「開きたいです」って言って来た担当は、そういった意識はないかも知れないけど、「上司」あたりは絶対にそう思ってる。ってゆーか、そうでないと開かれるわけがないと思っていい。「部屋を貸す」ってのは、それなりにコストとリスクがあるんだから。まぁ、中には道楽や社会貢献欲で開く人もいるんだけど、それはむしろ例外だと思うべきだ。「行く側の立場としては」だけどね。てーか、増田の奴、絶対「無料ですには裏があるんだよとか、ドヤ顔して言ってただろ？[要出展]

でも、世の中この手の意識のアンマッチなものはたくさんある。「遊びの合コン」かと思って出掛けたら、女の方は婚活のつもりだったとか、「ただ部屋で飲んで遊んでるだけでいいんだよ」とか言われて誘われたら、出会い系喫茶だとか。就活の学生が来たんで喜んでいたら、単なる腕試しだったとか。つまり、こーゆー「出会い」が絡むもの、人が出会いそうな場所ってのは、そーゆー意識のズレってのは、

あって当然

だと思わなきゃいけない。だから、いくら合コンだからと言って、その気のない相手をストークするようなことをしちゃいけないとか、おいしいところだけ取ってデカい顔するとか、そういった類のことはしちゃダメとゆー

出会いの基本

を身につけておきましょうよ… って教訓じゃないかなと思うわけ。

むしろこういった人材のスカウトって、これからはアリではないかな。

「藁の一本」は、

「OpenCOBOL活用セミナー」

でハブにされたとゆーことなのだけど、それは「藁の一本」でしかない。

「藁の一本」と言えども根拠がなくブー垂れてるわけでもないのだけど。

元々、私が情報処理学会のCOBOLの委員会に招聘されたのは、当時の委員会の主査の今城先生からでした。ちょうどISO COBOLの2002が決まり、JIS化をするという時に人手が足りなかったと言うこと、私がCOBOL 40周年イベントの時に呼ばれて、FLOSS COBOLの可能性について話をしたということ、FLOSSのCOBOLについていろいろやっているということ等の背景があるということを氏がご存知だったということで、誘われてのことでした。FLOSSやっててCOBOLがわかって、いわゆるCOBOLerでない人ってのは、かなりレアな存在だということで、規格調査会の賛助員とかと関係なく入ることになりました。まぁそういった経緯で委員になったので、「Open COBOLからハブにされたら、委員である根拠がない」わけです。またお誘い戴いた今城先生もお亡くなりになってしまったので、その辺の経緯を説明出来る人ももはやいないし。まぁシレっとそのまま続けていれば、そのまま続けられたと思うのだけど、やっぱりケジメは大事だし。

というのが「藁の一本」の話なんだけど、それは結局「藁の一本」でしかない。

個人的には、COBOLをバリバリ使うなんてことは、おそらく今後もないだろうし、そういったプロジェクトをやることも多分ない。また仮に使う側になったとしても、便利に使うのはCOBOL 85(92)の範囲を出ることはまずない。2002や次期規格(2002の改訂として今年出るはず)のような「凄い言語仕様」をバリバリ使うということは、「COBOLを使う」という場面と整合しづらい。ということで、新しい規格を作ることにあまりモチベーションがなかった。「オブジェクト指向を取り入れたんだから、そーゆーのは標準クラスライブラリを定義しようよ」的なものをどんどん言語仕様として入れようとする某海外ベンダーさんとか、頭おかしいんじゃねーのとかｗ

また、結構時間の取られる作業があったりして、マジメにやると相当時間が取られる。本業がそんなに上手く行ってないところにそういった時間を取られるのは、なかなかに厳しいものだった。かと言って国際規格を検討する委員でもあるので、「本業が忙しいので」とかサボるのも申し訳ないし、逆にそういった作業があるからと言って本業をサボるわけにも行かない。本当は標準クラスライブラリとか提案したらいいなとか思ってたのだけど(途中までやりかけた)、それをやるにはあまりに物事が大袈裟過ぎて、次期大改訂の時にとかゆー話になりかねないし、それいったいいつよとか、そこまで行くのにどんだけの「敵」を倒さなきゃいけないのよとか、そこまでやっても俺使わねーよとか、そーゆーこともあった。

また、外部から見ているとわからないと思うのだけど、こういった作業は

全て手弁当

なのだ。会議の日当どころか、足代すら出ない。だから、私みたいな身分だと、「一生懸命やればやる程自分の首を締める」ことになってしまう。それだけやって、何か「名誉」的なものがあるかと言えば、２ちゃんあたりで

「おごちゃんって誰？」
「COBOLer」

とか言われてしまう始末で、なーーーーーーーーんの得もない。それでも、「凄い人達」と一緒に仕事が出来るという機会だったので、頑張ってたのだけど。

そうそう。メーカからそういった場に出て来た人は凄い人達で、大学から出てる人もやっぱり凄い人達で、私みたいなチンピラがいると、申し訳ないくらいの人達ばかりで、最初の頃は小さくなっていたのではあるけれど、

JISらしくCOBOLらしく今風でもある訳語

の検討には、それなり貢献出来たかなーと思ったり、たいしたことしてないよなーと思ってもみたり。

そう言った「凄い人達」と一緒に働く権利を放棄してしまうのは、非常に残念なことではあるし、そういった人達に良くして戴いたことはとても感謝なのだけど、自分(自社)のモチベーションが切れている上に、背景もなくなっているし、規格調査会というシステムにも参っているので、中途半端に続けるよりは辞めた方がいいなと思って、辞任することにしました。良くして下さった皆様には本当に申し訳ないし、次期規格のことも気にならないわけではないのだけど。

8年半の間ありがとうございました。

ネタとしては

「食べログ」は恥を知るべき

と同じ。２ちゃんあたりでステマステマとうるさいけれど、そもそもステマに騙される奴って、情弱だろｗｗｗ

口コミがこういったものの温床になりやすいのは、「田代砲」の頃からの常識。

1位はなんと？TIME「PERSON OF THE YEAR」投票にネットの“力”

だから、ネットで口コミを使う時、こういったことを考慮しつつ情報を集めるのは常識。対処してない奴が馬鹿。いや、対処したくなかったらしなくてもいい。その代わり「そーゆーもんだ」と思っておけばいい。昔から言うだろ、「嘘を嘘と(ry」と。別にそれは「匿名掲示板」に限った話じゃない。「不特定多数」ってのは、その人達のプロフィールを知らない限り、「匿名」と大差ない。違いがあるとすれば、直接メールとかで連絡が可能かも知れないということだけど、その行動は普通取らない。つまり、結局のところ

不特定多数のレビューというのは、「匿名掲示板」と同じ

と思っていい。そうなると、利用するには「嘘を嘘と(ry」というスキルが必要になる。そんなもの当たり前だろ。もっと簡単に言えば、

「食べログ」の情報信頼度は、２ちゃんと大差ない

ってことだ。それを前提に読まなければ、「情弱」の謗りは免れまい。

信頼のある情報を得るには、

• 信用出来る人から得る
• 裏の取れた情報を得る
• 自分で確かめる

ってのが基本だってことは、震災の後のデマ騒動で散々言われたことだったはずだ。あれだけデマに踊らされ、痛い思いや恥かしい思いをした人達は、

情報を吟味する

ことの重要性を感じたはずだ。まぁ、無邪気にデマを拡散したり、無責任に踊った人達は何ともなかったかも知れないけど。

確かに、もういい加減嘘を嘘と見分けるのには疲れた。でも、結局いまだにネットでは嘘を嘘と見分ける能力が必要だということは変わってない。少なくとも今は、

そーゆーもん

として扱うしかないのだ。

それをもうちょっと楽にしようと思えば、「信頼の出来る人からの情報」を信用する、つまり

ソーシャル

にやることだ。「友達」の評価が良ければ、多分自分も良い評価をするだろうと。まぁ「twitterのデマ」に踊らされた人達は否定的になるだろうが、あの時「どこからデマが来たか」をよく思い出せば、対処は出来る。

とか考えると、「ステマステマ」と連呼することは、あまり格好のいいことじゃない。

やった奴に罪がないわけじゃないが、やられた方が被害者面して良いってもんじゃないだろう。「twitterのデマ」に踊ったような恥だよ。

PS.

まさかこのエントリでもサーバコケたりしないよな。

「食べログ」やらせ騒動でランキング操作は確認できず–消費者庁も動く

この辺のニュース、読めば読むほど

馬鹿か？

としか思えん。

たいしたことを言うわけじゃないから、長々と書くことは控えるつもりだけど。一応、プロバイダ視点。

CGMの類、ユーザーレビューの類なんて、こーゆーことがあって当然なのは、「田代砲」の頃からの常識。

1位はなんと？TIME「PERSON OF THE YEAR」投票にネットの“力”

システム設計する時に、この手のことは対処するのが常識。対処してない奴が馬鹿。いや、対処したくなかったらしなくてもいい。その代わり「そーゆーもんです」と言っておけばいいだけ。それを、満足な対処もせず、そーゆー告知もせずにやってれば、こーゆーことが起きない方がおかしい。

「食べログ」だけではない　ネットでやらせがはびこる理由

システムデザインかサービスデザインに欠陥があるものに、一般人向けニュースだの「消費者庁」だのってのは、

恥の上塗り

ってもんだろ。業界内ニュースならいろいろ納得もするけど、それでもどっちかと言えば、「やられた方が恥ずかしい」の類だろう。

まぁこの業界にいる限り、いろいろな「大人の事情」ってのがあるのはわかるのだけど、その「大人の事情」が「セキュリティホール」になってしまっては、やっぱり「デザイン」に問題があったとしか言いようがないと思う。

やった奴に罪がないわけじゃないが、やられた方が被害者面して良いってもんじゃないだろう。「セキュリティの甘いサーバ」を放置してたような恥だよ。

PS.

しかし、この手のエントリを書くと決まってサーバがコケるのは、何かの呪いかねｗ

Q:大阪城を作った人は誰でしょう？

A1:豊臣秀吉

A2:大工さん

当然どっちも正しい。違いは視点であって、どっちがなくても成り立たない。ただし、豊臣秀吉は「作者」とは呼ばれない。「作者」は名もなき大工さん。

まぁそういった意味で、「OpenCOBOL」の「作者」は私ではないのだけど。

お知らせ : 【プレスリリース】OSS COBOL支援プロジェクト立ち上げ

作者じゃないから「仁義」とかいらないけど、「声」くらいはかけて欲しかった。

OpenCOBOLの開発の経緯は、以前に書いた。

ORCAのアーキテクチャ(言語とデータベース)

この中から来たもので、dot COBOLがオープンな処理系でなかったので、しょうがなく開発してもらったものだ。プロジェクトのために言語処理系を作るとか、正気の沙汰じゃないんだから。それもまぁ、西田君とゆースーパーハカーがいたから出来たものなんだけど。そう、「作者」は間違いなく西田君だ。

元々はORCAから始まったプロジェクトなんだけど、いろんな経緯から今は他の人達がやっている。それで続いているのだから、まさしくFLOSSのエコシステムの成功例だ。まぁ、COBOLなんで地味なんで、話題に上ることはないのだけど。

ってことで、開発の初期には私はタッチしているし、「やる」って意思決定したのも私なのだけど、今は赤の他人が続けているとゆーソフトウェアなのだ。

今となっては私自身COBOLでコードを書くことなんてないんで、本当に他人なんだけど、いろいろ因縁もあるので、それなりに思い入れもある。COBOLの規格に関わる「ボランティア」を甘んじで引き受けているのも、その「因縁」でもある。

とは言え、私が何らかの権利が主張出来るかと言えばそんな権利は全くないし、別にその権利が欲しいというわけでもない。てーか、そんな権利があっても何も価値がないってことはいろいろ経験済みだから、欲しがる価値もない(*1)。そういった意味では、

売ってしまった商品

と同じようなものだ。「売ってしまった商品」ってのは、もはや自分のものではない。買った人のものだ。いや、別に直接それで金もらったって訳じゃないよ。感覚的にそうだってこと。それもまぁ、かなり前に売ってしまって、売ったとゆーことはどうでも良くなってるくらいのものだ。

そーゆーわけで、私には何の権利もないし、そういったものを主張するわけでもないけど、いきなり知らないところで

お知らせ : 【プレスリリース】OSS COBOL支援プロジェクト立ち上げ

とかやられると、もにょもにょする。「仁義」とかいらないし、求められる立場ででもないし、いろんな意味で「今さら」でしかないから、そーゆーのはどうでもいいんだけど、「声」くらいはかけて欲しかったなと。「権利を持たない」ってことと「縁がない」ってとは別のことだからね。いくら「売ってしまった商品」だと言っても、それなりに思い入れがあるものだから、粗末にされると残念な気持ちになるよね。もう売ったこと自体忘れていたってね。そういった感情と同じだと言ったら、ちょっとはわかるかな？ まぁ、どこかの人達みたいに、著作が裁断されて心痛める程、豆腐メンタルじゃないけどさ。

ってこともあるけど、「WG」の面子に某社とか、某プロジェクトの関係者とか全くいない風味なのが、実は一番もにょもにょする。まぁコンソーシアムの「会員」じゃないからとか、お願いしたけど辞退されたとか、そんな事情もあるのかも知れないけど。さらに、

なんであんたらがおるの？

みたいな会社が並んでるのが不思議。そういったのを見ると、どうもこの組織の人達って、FLOSSに対して

作るよりも消費するもの

と思ってるんじゃないかと。だから、オリジネータとゆーかそのあたりにいた人達を軽視してるんだろうなと、納得してしまう。昨今のウェブサービス系の世界では、FLOSSに直接コミットするのがトレンドだと言うのに。

何をオープンソースにするべきか（1）

「井戸の水を飲む人は井戸を掘った人への感謝は忘れない」とか言うものけど、こと日本のFLOSS界隈の人達は、

ちょっとでも離れると過去の人にして忘れてしまう

ものなんだよなぁ。

まぁ、やるイベントが「勉強会」みたいなノリであるなら、どうでもいいし、大いに勝手にやればいいことだけどね。今回のはどうもそうではないようだ。

*1

何かと言うと権利を欲しがる人がいるけど、権利ってのはたいてい「責任」がついて回るので、無闇に権利など欲しがるもんじゃない。自分が主体的に行使する予定のある権利なら、持っておく価値があるのだけど、そうでない権利は「責任」とゆー面倒臭いものだけついて来て邪魔なだけだ。

PS.

誤解されぬように言っておけば、話を「通してくれ」と言いたいわけじゃない。そんなことされる立場じゃないし、されても何も出来んし。現実にされたとしても、「いや、それ私に言われても」とか言うしかないんので、あまりポジティブな反応も出来ない。でも「声」はかけて欲しかった。それなら、「勝手にすれば」から「何かあったら言って下さい」まで、いろんな反応が出来た。何もしなくても、ここで告知するとかくらいしたかも知れない。

今回は情報を知った時に(手違いとは言え)、参加が締め切られていたんで、コミットとかする余地すらなかったとゆーのが、まことに遺憾であった。まぁ、今さら何か言われても「知らん」って言うしかないけどね。

PS2.

ある筋からのタレコミによると、日立ソリューションズの担当者はこのエントリのことをご存知らしい。だったら何かアクションあってもいいと思うけど。完全スルーなんだな。まぁ、謝られるスジアイはないので謝られても困るし、勝手に怒ってるだけなんで、どうにかなるものでもないけど。

たださ。FLOSSつーかソフトウェア全般に言えることなのだけど、こういった「怒り」を持つことってのは、10年に一度出来ればラッキーな類の「怒り」なんだよ。たいていは、怒ることすら及びもつかないのが普通だ。消費者視点では「FLOSSはバザールモデルで選択肢豊富」ってのは真理だし良いことだし、生産者もそれで助かっている部分はあるんだけど、生産する側からすれば、

それなりに手間と時間をかけた一品

なのだよ。それはどんな「クソみたいなソフト」でも同じだ。

素人が手間かけて作ったラーメンより、インスタントラーメンの方が、たいてい旨い。食う方からしてみれば、インスタントラーメン食う方がマシなことはよくある(だから私はラーメンは作らない)。消費者視点で言えば、「インスタントラーメン」を選択するのは当然のこと。でも「手間かけて作ったラーメン」ってのは、作った人の思いがある。消費者にとってはそんなもんはどーでもいーし価値とは関係ないものだけど、「粗末」にされたら生産者は気分が悪い。そのことを謝られたところで、「至らぬ自分が悪い」ということがより明かになってしまって、ますます凹むだけ。

非常に運が良かったのは、1年くらい前に仮想ディスクを丸コピーしていたものがあったので、そっちから消えた分は戻すことが出来た。

つまり、1年分くらいは消えたってことになるんだけど、どれが消えたのかよくわからない。

なんで消えたかと言えば、Thunderbirdの「設定」の中にある「同期とディスク領域」の設定で、「ローカルのコピーとリモートサーバ上の古いメッセージを完全に削除してディスク領域を開放できます。」と書かれた設定を、「最近のメッセージを次の数だけ残して削除する」で「1通」にしてしまったから。私はてっきりこの設定は、Thunderbird上のキャッシュをサーバのフォルダに一致させる設定だと思ってしまったのだ。

元々、Thunderbirdのキャッシュの管理は、かなり「俺様一番」で、Thunderbirdで消したメールがすぐにサーバに反映しなかったり、サーバで振り分けたメールがThunderbird上にすぐ反映しなかったりしていたので、どうしたものかと思っていた。そこでふとこの設定を見た時に、「この数を限度にキャッシュを整合させるのだな」と勝手に納得したわけだ。imapの操作をキャッシュを少なくしたり、store(write) throughにすると、削除や振り分けに時間がかかるのは、自分でimapクライアント書いたり、ログ見ながらimapなクライアントを評価した人ならわかると思う。だから、「完全に一致」は無理でも、キャッシュ数を減らしてトレードオフを見つればいいやとか思ってやってしまったわけだ。

ところが件の設定はそうじゃなくって、この設定は「今起動しているThunderbirdが主体となって、古い(ここに指定した条件に合う)メールを完全に消してしまう」という設定なのだ。古いメールを消すとゆー習慣を持たない私にとっては意外としか思えない設定なんだけど、そーゆーことを忘れてしまえば、確かにそんな運用もあるし、そーゆー意味で書いてもおかしくないよなぁな設定だ。この設定は存在自体がおかしいと思うが、それについては後述。

まぁそんなわけで、この設定が発動して、メールをどんどん消し始めた。最初は気がつかなかったのだが、途中で気がついてあわてて止めた。消えたフォルダは「連絡用」「お友達」「MLメルマガ類」のもの。もちろんその下にサブフォルダはある。幸い「仕事」とか「メモ」とかは消える前に気がついた。subscribeしてないフォルダはスルーされてた。さてどうしたものか。

ふとサーバの仮想イメージを見ると、1年ちょっと前にバックアップを取ったものがある。多分、クラッシュから復元させる時に、–rebuild-treeかけるために取ったバックアップなんだろう。よく覚えてないけど、多分そうだｗ 1年も前だけど、「20年」に比べりゃ誤差なんで、こいつから戻すことを思いついて復元させた。適当にmountしてコピーすればいいので、間違えても平気。この辺がmhフォルダの気楽なところ。

確認で復元させたフォルダを見たんだが、違和感がないのだ。まぁ、直前のメールも残っているということもあるのだが、「消えたのどれだっけ？」という程度には復元されている。ってゆーか、「お友達」となんて、

この1年間ロクにメールしてない

のだ。

よく考えてみればこれは至極当然で、コミュニケーションの主体はtwitterやfacebookに移ってしまった。今時メールで来るのは、

• MLやメルマガ
• 仕事の一部
• spam

であって、友達との世間話とか、アポの連絡とかは、たいていメール以外だ。メールであっても携帯メールばかり。「携帯メール」は「今着いた」「わかりました」的なのばかりで、SMSと大差ない。つまり、今や普通のメールは

楽しいコミュニケーションのためのものではない

ということになってしまった。「楽しいコミュニケーション」は、他にいくらでもツールがある。

そんなわけで、消えたと気がついたのは定期発行のメルマガ類の途中がないということくらい。あとは、たいてい残っている。まー、どうせ古いメールなんて「老後の楽しみ」くらいしか価値がないので、消えたって困るわけではないし。

とゆーわけで、ますますメールっていらないなーと思う事件であった。

途中まで書いてたThunderbirdの仕様がおかしいと思うことについてなのだけど、これは複数のPCからThunderbirdを動かすとゆーシーンを想像したらわかると思う。居場所毎にデスクトップ機があって、そこでMUAを動かしているとか、そんなに変な想定ではなかろう。私がシクった設定にしてなくても、「俺様一番」なキャッシュ管理をしていると、複数のMUAが把握しているメールが矛盾してしまう。特にこの設定のように「勝手にサーバのメールをいじる」ようにしていると、その矛盾は問題になってしまう。もちろん、自分で意識して消したり移動させたりしたものはサーバに反映していて欲しいのだけど、「キャッシュ」の類は「サーバの状態」が反映されているべきだ。ところが、Thunderbirdはあまりサーバの状態を反映させようとしないので、わけのわからないことが起きてしまう。まぁこれはThunderbirdが悪いと言うよりは、キャッシュを持つimapなMUAに共通する問題ではあるのだけど、複数MUA間でキャッシュのコヒーレンシを保つなんて、imapには無理だし。

また、振り分けとかの類も、それぞれの設定が矛盾してたらわけのわからんことになる。spamの学習とか、それぞれ違ったりしてると、いろいろ面倒臭い。そういった意味では、MUAをfatにして行くこと自体が間違いだと言えなくもない。便利だし、たいていその方が良いんだけど、トラブルのような「外乱」には弱くなる。

Thunderbirdの私から見るとおかしな仕様と言うのも、こういったジレンマに対する開発者なりのケリのつけ方だと言われれば納得するしかない。「それは僕のケリのつけ方と違うね」ってだけで、

嫌なら使うな

で良いわけで。

これを抜本的に解決させるには、Gmailのような

サーバにあるMUAを使う

ことなんだろうけど、Gmailはちょっとなぁ… あと、多少遅くてもmhフォルダを直接いじれる方がいろいろ便利なのよね。

Intel® Server Board S1200BT Family

スペックの大略は、

-新製品- Intel S1200BTL

スペック的に大変良いのだが、なかなか簡単に動いてくれなかった。同じことにハマる人がいるかも知れないので、メモしとく。

このマザー、サーバ用で売ってるだけあって、スペック的にサーバに都合がいい。何が良いって、

• GPUなしSandy Bridge(Xeon)用
• GbEが2つ
• メモリ 4スロット
• 余分なものがついてない
• VGAがついている
• micro ATX

ということで、コンパクトにサーバを作りたい向きには願ったり適ったり。XeonだからメモリがECC付きになるのだけど、それでもフル増設して2万ちょいなので、言う程高くない。だいたい今時の8GBが3000円切れるとゆー方がおかしいんだってば。ちなみに買って来たのはセンチューリー様のメモリなので、ECCなしでもいい値段する。だから、そんなに凄く高いわけでもない。「ECC付き」が嫌でXeonに手を出さない理由はもはやない(キリッ

ということで大変良いのだけど、最大の問題が

Intel製

であるということ。もうこれは「iPhoneがSBM」というのと同じくらいがっかりで、個人的にここ10年くらいIntelマザーに良い思い出がない。そして、この板もしっかりそれにやられた。昔は鉄板だったのになぁ。

何がマズいって、

BIOS画面に入れない

のだ。OSはブートするのにBIOSに入れないとか、さっぱり意味がわからない。まー冷静にしばらく考えれば、わかるのだけど。

BIOSに入るにはF2を押すのだけど、そこでハングアップする。ビープも「ぴーぴーぴーぴーぴー」と5回鳴る。何かおかしいんだけど、ハングアップするので何も出来ない。Intelのサイトにもドキュメントにも「ビープ5回」は見つからない。しょうがないんで、購入したFreeTに持ち込むと、なぜだかあっさり動く。店員と「どこが違うんでしょうねぇ」って話してた時に、

キーボードが違う

ことに気がついた。

そう言えば、Intelのマザーってキーボードを選びますね。高いキーボードは軒並ダメとかよく聞きます。

とのこと。私も前のCore2Duo E6600でセット作った時に、キーボードでハマった。Real Forceのような高いキーボードでは動かなくって、安物のペチペチキーボードのだとちゃんとBIOSに入れていた。BIOSのアップグレードで少しはマシになったのだけど、「全く動かない」が「コツをつかめば動く」になった程度だった。今回テストに使ったのも、HHKだったので、「それかー」と思って、家で一番安いキーボードを探して試してみることにした。

でも、やっぱりハングアップ

するのだ。とっかえひっかえ試すのだけど、やっぱり動かない。そこで気がついたのは、うちにあるキーボードはみんなテンキーがないこと(だって机狭いもん)。しょうがないんで、ツクモでテンキー付きの思いっきし安いのを買って帰ることに。

それでもやっぱり動かない

のだ。さすがにこれはキーボードのせいではないなと思って、ふとディスプレイのことを思いついた。でも、D-SUBのコネクタだからアナログだろうし、大は小を兼んえるだろうし… と思いつつも、他のディスプレイをつないでみたら、

ちゃんとBIOSに入れた

のだ。つまり、何だか理由はわからないが、

ワイドディスプレイはダメ

というより好みをしているようだ。まー、わかってしまえば、アナログのスクエアタイプのディスプレイをつなげばいいだけなんだが。ちなみに、ちゃんと動くようになってBIOSを更新したのだけど、やっぱりワイドはダメらしい。ワイドでも見えるのはあるかも知れないのだが。なお、キーボードはHHKでも動いた。

しかしこの問題、ディスプレイが悪いのかIntelが悪いのか知らないのだけど、他のメーカのマザーではなかったことなんで、きっとIntelの頑張りが足りないのだろう。多分「Intel様」なので、仕様上に問題はないんだろうけど、他が頑張ってるからねぇ。

あと、ワイドが悪いのか、特定製品が悪いのかわからないけど、仮に前者であるとするなら、かなり致命的な問題ではある。だって、秋葉で安物のディスプレイ買おうと思ったら、今時は20″くらいのデジタル(優先)入力のワイドしかないと言ってもいいんだから。下手すると、中古の17″より安かったりする。

そんなわけで、Intelの板が動かない時には、

キーボードとディスプレイを疑え

ってことで。

いや、しょせんプログラム言語でしかないから書けないことはないし、必要なら書くのだけど、出来れば他人付き合いしたいと思っている。言語仕様あまり好きでないし。

とは言え、今時はそうも言ってられないので、jQueryなんぞを使いつつ書くわけだ。

Javascriptが嫌いだろうと、気に入らない言語仕様であろうと、ウェブ屋をやる限り、避けては通れない。てゆーか、今時だったらプログラム言語を1つだけ覚えるとしたら、Javascriptを置いて他はないと言っても過言じゃない。20数年前、Cが書けるようになったことで、世の中が大いに開けたような気がしたものだけど、今それを簡単に感じることが出来るのはJavascriptだろうと思う。「普通の人」が使う環境でJavascriptが使えない環境なんてないとゆー手軽さ、node.jsとか使えばサーバアプリだって書けるし、ウェブブラウザ以外でもJavascriptを埋め込み言語にしてるものは結構ある。iPhoneだってAndroidだってアプリらしきものが作れる。「1つだけ言語を覚えてゼニにしたい」って言う向きには、都合がいい言語だろう。そんなに難しい言語でもないし。

とは言え、ちょっと前まではJavascriptは「互換性」とゆー厄介な問題があった。言語仕様の互換性よりも、実行環境の互換性。もっと具体的に言えば、ブラウザ毎にオブジェクトの仕様が微妙に違う。ちょっと凝ったことをすると、

なんでIEとFirefoxは違う？

とか悩んだもんだ。幸い最近になっていろんなライブラリがその辺を吸収してくれるようになった。非互換の起きそうなものは、ライブラリが解決してくれる。

もう一つ面倒臭かったのが、ブラウザオブジェクトの指定だ。どの形式を使うにしても、長々と書くことになる。長いとtypoしがちなんだけど、走らせるまでそれはわからない。

こんなこともあって、Javascriptは苦手だったのだ。言語仕様が多少アレでも、慣れてしまえばどうにかなるものだけど、「互換性」だの「指定が面倒」だのってのが、学習コストを上げるだけじゃなくて億劫になる。「仕事だからしゃーない」とか思いつつ、渋々書いていたもんだ。

そこにjQueryが出て来てくれて、いろんな問題を一気に解決してくれた。Javascriptのダルいものが、ほぼ綺麗に解決されたのだ。個人的な苦手意識がほぼ全部解決してくれた。

って、前置きが長いな。

でまー、jQueryはありがたいものなんだけど、「今時」のFLOSSの御多分に漏れず、変化は激しいし成書が少ない。せっかく名著でも、微妙に古い版が元だったりする。出た時は最新だったものが、しばらく積ん読しておくと、ソフトウェアのバージョンが進んで残念なことになったりするので、この世界

新しいは正義

だったりする。

ということで、表題の本。

この本は献本で戴いたものであるし、訳者の吉川氏は古くからの友達であるとゆーことを割り引いても、

ちょうどいい本

としてお勧めだ。

この本は「読む本」だ。最初からゆっくり読めば、必要なことが身につく構成になっていて、私のような

プログラムはそれなりに経験があるし、Javascript知らないわけじゃないけど、面倒臭いしあまり使わないから、そんなにバリバリ書けるわけじゃない

という程度の人にとっては、退屈もしないし、チンプンカンプンということもない。そういった意味でちょうどいい。jQueryの解説にありがちな、デザインやエフェクトあたりのことが邪魔になるということもない。

訳は安心の「吉川品質」。彼の訳のいいのは、技術的な間違いがほぼないことと、日本語が綺麗なこと。私は彼がこの本を訳しているとゆーことを知らなかったのだけど、jQueryのことをtweetしてたんで「あら？ ウェブプログラマに転身したのか？」って思ってたけど、そうではなかったようだ。技術書の翻訳って、監訳は名ばかりで技術的にどーよとか、逆に技術的には正しいけど妙に技術屋っぽい日本語だったりするのだけど、さすがに彼の訳はそんなことはない。また、訳書にありがちの「原書では最新追従していたけど訳してる間に古くなった」ということも、彼自身の手で解決してある。原書では1.4系で書かれているのだが、

1.6.2までサンプルの確認

がしてあるようだ。その点でも、しばらくは安心して読める。

ただし、この本はリファレンスではないので、リファレンス的なものを求める人や、とにかく急いでるんだ的な人には向いてないんじゃないかと思う。そういった向きには、「jQueryクックブック」の方が向いてるような気がする。

「jQueryクックブック」もリファレンス本とは違うけど、「とにかく○○を××する方法が知りたい」な向きにはいい。jQuery UIの説明もあるしので、忙しい人が1冊だけ持つというのであれば、こっちかも知れない。

また、デザイン系の本ではないので、デザインやエフェクトに関する説明はあまり多くない。その代わりに表題にもあるように

jQuery UI

がしっかり説明してあって、ページにして1/3くらいがjQuery UIの解説だ。

そんなわけで、私のようなタイプの人が「jQueryちゃんと勉強しとこうかね」とか、

通勤電車の中で本読んで勉強しよう

的な用途には「ちょうどいい本」である。巻末にJavascriptのポイントが、本当にポイントだけ説明した20ページ足らずの章があるのもいい。まぁ、本当にディープなところの解説を「忙しい人」向けに書いただけなので、全くの初心者には意味をなさないのではあるけど、そーゆー切り捨て方も気持ちいい。