![[ここｷﾞｺ!]](http://kokogiko.net/logo.png){kind=logo}
2006年07月31日
なつかしー！鋳物萌え(BlogPet)
ほんとうは、ねねは
製品何となくと作品何となく-404BlogNotFound-.
とか思ってたらしいの。
*このエントリは、BlogPet(ブログペット)の「ここ」が書きました。
2006年07月31日
何年ぶりかに歴史に興味が戻ってきた
というわけで今読んでるのはこれ。
|
?本 ?史
講談社 (2006/06/15) |
春秋戦国から楚漢戦争、漢匈奴戦争、新あたりまではそれなりに知ってるつもりなのだが、意外に東漢の頃の歴史には疎いので買ってみた。
塚本作品は霍去病、霍光、張騫あたりの西漢期の作品中心に読んでたのだが、わりと好きだ。
高校の頃は文学部に行って歴史学を専攻したかったんだよな。
銀英伝のヤン・ウェンリーに感化されて、と言えばちょっと恥ずかしいが。
「手に職を付けてくれ」と親に懇願されて、工学部に入ったが（というか、高専出だったためか「大学＝職能を身につけるところ」という勘違い？をしていた親が悲しい）。
というか、つい最近、2001年のauのGPSケータイ発売にビビッときて、2002年にここギコを始めるまでは、別にGeekの道なんて目指してなくて、フツーに仕事して、いつか歴史小説書くんだとか真顔で言ってて、実際短編はいくつか書いて同人誌出したりもしてて、本を買うと言えば歴史書か歴史小説か、って奴だったんだよな。
なんかこの3、4年間、熱に当てられたみたいに技術技術して、買う本もオライリーとかそんなんばっかりになって、歴史のコーナーに行っても別に何も読みたいと思わなくなってたけど。
この２週間くらいちょっといろいろあって、なんかいろんな意味で信じてたもんに幻滅したというか、どうでもよくなってきたというか、あんまし技術とかGeekとかWeb2.0とかどうでもいいわーという気分になってる。
そういうことに幻滅する自分自身にも幻滅しているというのも少しある。
一時的なもんかもしれんけど。
そのせいかどうか判らないけど、懐古趣味というか原点回帰というか、歴史なんかにまた最近興味が沸いてきてる。
今の仕事でさー、やれ創業者の名前だの言葉だの精神だの、今の社長は何代目だの、会社の精神だのビジネスにとってはどうでもええこと覚えて出世して、技術者といいつつ本当の意味での技術とは無縁のぬるい会社人生を送るのは愚にもつかないと思ってたんだけど。
それならばGeekとかWeb2.0とか追い続ければ幸せなのか、というと、何となくそっち方面の、別の意味での愚にもつかなさが最近何となく匂ってくるような感じがして、正直最近ちょっと萎えている。
自分がその手の方向性で大成するイメージがわかなくなってきてるし、いやもし万一？大成したとしても、その時俺は幸せか？と聞かれるとよく判らないなーという気がしてきてる。
少なくとも何となくその手の方向性からは嫌われてる（いや、特定の個人とかコミュニティとかじゃなくて、運命の女神とかそんなアレね。機会的に恵まれないと。）みたいだし、それならそれで、理想の自分を今の自分に軌道修正して、やれ日々の時間を技術革新に追われるようでもなくとことんぬるーくぬるく生きながら、好きな歴史や伝統芸能なんかに時間を費やしたり、家族との触れ合いをもっと楽しんだり、そういう人生も悪くないかなと思い始めてる。
こっちの世界はこっちの世界で、それなりに大きなコミュニティなのだし。
ちょっとした一時的？なアパシー状態と言うかね。
といってもうつうつとしたそれではなく、最近の自分を捨てて元々の自分を取り戻そうとしてるような、そんな感じ。
別に本当にそういう心理なのかは自分でもよく判らないけど。
少なくとも、ちょっと前までは、本屋の歴史書コーナーに行っても読みたいと思わないと言うか、こんなもん買うのに金を使うくらいなら技術書もっと買って勉強しなきゃと思ってたのが、最近本屋に言ってみると歴史書や歴史小説が自分を呼んでいるような感覚を感じる。
それで自分の心理分析をやってみたところ、こんな感じなのかなと。
でも、そんな生活に戻るんなら、関西に帰りてーなー。
親の勝手な都合で息子のせっかくできてきた社会生活をぶった切るのはよくないと思うので、実際には帰らないと思うけど。
携帯電話の3D地図から地域情報を探せる「3D空間検索技術」
NECマグナスコミュニケーションズと米GeoVectorが共同開発した位置／方位による情報検索基盤に、ネットディメンションの3Dコンテンツ表示技術、キャドセンターの3D都市データ構築技術、アジア航測の地図情報システム（GIS）技術、旭化成マイクロシステムの電子コンパス技術を組み合わせた。またサイバーマップ・ジャパンがコンテンツ／サービス面で協力した。
GeoVectorキター。
しかし、協力会社も百花繚乱で、「コンテンツ/サービス面で協力」等具体的なアプリケーションまで完成していることを想像させる割には、イマイチソリューションとしてどこまで何ができてるのかよく判らない記事ですな。
NEC端末で、GPS・電子コンパスが装備されているような機種はないはずだし（NECはDoCoMo端末しか作ってないし、DoCoMoはGPS端末と言えばSANYOしかないはず。これには電子コンパスは付いてるんだっけ？）。
特にNEC子会社とかいうことにはこだわらず、auなんかのGPS・電子コンパスを持つ機種とかで作ったのかな。
或いは、電子コンパス技術に旭化成MSが協力、等と書かれているので、電子コンパスは外付けデバイスとして準備したのか（それにしてもGPSだけの機種もNECにはないので、SANYOのDoCoMo-GPS機種を使ったのかな？）。
もうちょっと詳細情報が欲しい、気になる記事です。
なつかしー！鋳物萌え
今日鉄腕DASH！見ていたら、風呂を作るとやらで鉄砲釜を鋳物で作っていました。
今時、鋳物を作る光景を見る事なんてそうそうないので、思わず見入ってしまいました。
超懐かしい。鋳物って私の社会人労働生活の原点なんですよね。
別に鋳物師として就職したわけじゃないんだけど、元が鋳物工場から発展した金属・機械メーカに就職したので、入社早々の4ヶ月間の研修期間って、私鋳物工場で働いていたんですよ。
私が働いていた職場で作っていた鋳物は、製紙圧延用ロールと言って、紙を作る製紙工場で紙を圧延するために使う巨大な円筒形物質（色々だけど、直径1mから数m、長さは10mから20mくらいで、重さは確実に2桁t単位の円筒形の鋳鉄の塊）を鋳物で作ってた。
だから鋳型もDASH村鉄砲釜のようなこじんまりしたもんじゃなくて、どでかい鋳型なんだけど、作り方の発想の基本は変わらない。
夏には50度を超える粉塵まみれの職場でも、1200度の火の粉が飛び交うので長袖長ズボン作業着・耐熱手袋長靴・ヘルメットゴーグル着用の全身重装備での肉体労働。
意識がとんで足を踏み外しでもすれば、一瞬で気化出来る煮えたぎる電磁溶鉱炉のふちで、浮かび上がってきた不純物を鉄の引っかき棒で掻き出す作業。
のそのそやってると、引っかき棒そのものが溶け出す。
自分の体よりはるかに大きい鋳型を、全身を使って押し固め、形を整える作業。
現場作業員の人が3、4個正確に作る間に、自分は1個しか作れず、しかもそれで全身ガクガク。
いろんな工程をローテーションしたけど、焼入れ・焼きなまし工程は、電気炉に大型クレーンでまだ熱いロールを入れたり出したりする時の作業以外は、クーラーの効いた電気炉の温度変化を監視してるだけだったので、比較的楽だったなあ。
大変だったけど、普通はこんな体験できないので、今考えるとすごいよい体験をしたなと思う。
当時から赤字続きで来年には、再来年には事業停止になると言われていた部門だったんだけど、Webサイトに製品がまだ載っているということは、まだやってるんだな...嬉しいな。
当時から社内の研究所なんかと協力して、低コスト化や高品質化のための技術革新とかをいろいろやってたから、そういうのが功を奏してるのかもしれないな。
職場の赤鬼軍曹と呼ばれていた定年間近の主幹さんから、退社後雀荘に行って四暗刻あがったりしたのも思い出す。
一緒に研修した仲のよかった文系の同期は、結局その部門の勤労管理職に就いてたな。
まだみんな元気にやってるんだろうか。
そういえば、その主幹さんって、言うまでもなく頂点の地位とはいえブルーカラーなんだけど（「主幹」はブルーカラーの最高位）、社長（一部上場企業の社長ですよ）としょっちゅうゴルフに行ったりとか、飲んだりとかしてて、社長の事も君づけで呼んだりしてた。
要するに、社長と言えども現場の最高責任者には頭が上がらない...とまではいかなくても、少なくとも一目おいているということだ。
別に驚くには値せず、本来は当然のことのはず。
彼らが汗水たらして働いて、製品を、よい製品を作ってこそ、会社が信頼され品物が売れ、会社の売り上げ・利益が伸びるのだから。
その事を思い出して、そういう当たり前の視点が、今のSE・PG業界とかでは欠けてるのかなという事を感じました。
古臭い？重厚長大日本の伝統謹製の企業とかですが、現場を大事にするとかそういう良き伝統は、引き継いでいくべきではないのか、と思いますた。
2006年07月30日
Evilな会社の情報交換はあってもよいのでは
「即日解雇みたいな違法な核兵器」って、黒社会から嫌がらせでもされていたの？ -void GraphicWizardsLair( void ); //-
まさか「すべての経営者はEvilであってはいけないのだ」というユートピア幻想だったりはしないでしょう？
たいていの人は「経営者にはEvilな奴が居る」ということを織り込み済みで「やばい会社に入らないようにする方法」に知恵を使ったりしていますよね。
ということであれば、Evilな会社を体験したら、その情報を公開してみんなで共有するのは公益にかなうのではないか、とか言ってみるテスト。
さあ、みんなで酷かった会社にはてなブックマーク！とか何とかｗｗ
あまり露骨にやると営業妨害で訴えられたりするでしょうけどね。
Evilな経営者って、そういう点でも取ってくる手段がアレですから。
あと、未返答事項の拾遺。
「即日解雇みたいな違法な核兵器」というのが無知なので本気でよく分かりません。
えっと、とりあえずEvilな経営陣に対抗するにしたって、まずは辞めるとか、クーデターおこすとかの最終手段じゃなくて、まずは組織内改革で経営陣に頼らない独立独歩体制を作って対抗しようとか、そういう順序でいくじゃないっすか。
そういう際に、やっぱ組織で、違う能力を持ったものが集まってるのだから、自分ひとりで食べていける状況を作ろう、とかじゃなくて（それなら本当に即辞めればよいのだし）、各人の特性を活かしたビジネススキーム造りとか、また技術陣内だけでも技術ノウハウの伝授を行ってシステムを分業メンテナンスできる体制作りとか、そういうのを作ろうとしますよね。
そういうのを作るのだって、時間をかけて、時には何ヶ月もかけて下準備してきてやっと体制を整えますよね。
その時に、突然予想もしてなかった違法な（違法ですよね？）即日解雇とかでその思惑を突如崩される、というような手段まで取られると、もうこっちとしても、反則アリというのであれば他にもどんな予想もしてないような事されるか判らないし、打つ手がなくなってしまうわけですよ（辞めたり、クーデターとか以外は）。
その意味で、違法行為までアリと言うのでは、取ってこられる手段も無限にまで広がってこっちも対抗手段の取りようがなくなるので、いくらEvilであろうがルール内でルール外のことをするのは究極兵器過ぎて駄目だろうよ、という意味で、ルール外手段を総称して「核兵器」と表現したものです。
「解雇通知は何日前に」「労働者の権利が」みたいな左側な発想で、才能ひとつでどこでも食っていける知的技術者が「核兵器」とは表現しないだろうしなぁ。
というのは、上記したとおり、自分への適用だけでなく同僚への適用で組織としての経営陣への対抗策が崩される事も視野に入れての表現をしているので、当たらないと思います。
「肋骨にひびはいって入院したら、経営者がボールペン1本の持ち帰りを横領だと微罪で難癖つけてきて解雇した」みたいな良く有るEvilな裏技のことかなぁ
というふうな事がEvilな経営者が取ってくるよくある行為なのだ、ということは知識がなく、実体験で初めて知りました。
その点では勉強不足で、対応策の考慮不足でしたね。
でも、うちのケースの場合は、微罪で難癖もなにもなく、経営陣が辞めさせたいから辞めさせる、だったと思いますが。
ただ単純に「俺は出るところに出ればもっとブレイクするんだ。チヤホヤされるべきなんだ」「悪いのは周りの環境なんだ」と思い込みたくて、それをblogにおいて過去のEvilな経営者や現状を愚痴ることでストレス解消しているとしたら、おれのコメントや言及などはめちゃくちゃ大きなお世話でした。
えー、確かに自分が辞める直前や同僚が辞めた直後は、怒りに我を忘れ特に必然性がない、自分の怒り発散のためだけのエントリを書いたりもしましたが、基本的に最近のエントリ（これとか、これとか）では、別話題からの流れで、論じている事の実体験を元にしたサンプルを提示するために書いているだけで、それを書くことだけを目的にはしていないっすよ。
まあ、書いている時にむちゃくちゃカタルシスを感じていることは認めますが。エクスタシーっすよ。
2006年07月29日
何となくDISられた理由が見えてきた
このカルチャーギャップに気付くのにこんなに時間がかかったということは、知らない間に俺もギークから根っからゼネコンSI屋に落ちぶれてしまったということか。
ここギコ！: 残業は日本人の文化？DNA？へのライブドアクリップ
仕事を時間ベースでしかとらえられていない時点で旧来の日本文化にどっぷり。
成果、という視点が抜け落ちてるということなんだろうな。
というか、それは旧来の日本文化が云々というより、業種の違いの問題だろう。
nipotanなんかのインターネットサービスなんかの仕事では、ゴールは自分で設定できる、というかゴールなんかないんだろうな。
だから、どれだけのパフォーマンスで何時間仕事した、とかそういうのではなくて、何を成し遂げたか、ということを後で査定されてそれにあわせて報酬を定める、という形の発想なんだと思う。
でも、今の俺みたいな巨大プロジェクトの大手ゼネコンSIだと、全体のゴールは既に決まっていて、そこに至るまでには基本的に新しい技術的冒険なんかもないし、やるべきことや調整すべき事なんかの総量は決まっていて、それをいかにどれだけのパフォーマンスで処理していくか、という基本的にはそれだけの問題でしかない。
だから、少なくともそういう業種ならば、基本的に個々人のパフォーマンス×時間で為した仕事の価値は決まるだろうと、そういう事を言ってるだけ。
例をいうなら、今回のプロジェクトで、UI上で地図をスクロールさせる機能を実現させるのにある他社製プラットフォームを導入することが客先との調整で決定しているんだけど、そのプラットフォームの地図操作感がショボ過ぎて、隣の席の新入社員が「Google Mapsの方がよっぽどいいですよねー」とか言っていたりしている。
そこで例えば俺が頑張って、「よっしゃ、Google Mapsに負けない操作感のUI作ってやるよ」と言って、もし仮に1日でGoogle Mapsを超えるレベルのUI作り上げたりしても、それがいかにすごい出来であってもシステムに採用される事は120%あり得ないし、確実に「そんなもん作って遊んでいる暇があったら早く顧客との未決事項調整のための仕事をしろ」と、どやされるだろう。
そういう業種では、基本的に全体の登るべき山の総量に対してどれだけのゲインを稼いだかで報酬が決まるべきはずだが、残念ながらコーディングのフェイズとかならまだしも（といっても俺はコーディングさせてもらえないだろうけど）、顧客調整とかのフェーズでは、どれだけのゲインを稼いだかと言うのを性格に見積もるのは、後からでも難しい。
たとえば、今回のプロジェクトの例でいうなら、
- 「○○業務で使う端末のディスプレイはどうしますか？」「うーん、○○GAの液晶モニタがよいな」でディスプレイの仕様を決定した。
というのと、
- ディスプレイ上で画像データを3次元立体視するという要件があるのだけど、既存技術の液晶シャッタメガネを用いた立体視方式だと、液晶モニタではリフレッシュレートが低すぎてチラついて立体に見えない。
かといってCRTモニタは、今後どこのメーカでも生産停止になるので、システムのサービスイン後から稼動期間分のサポートをメーカが保証してくれる製品がないため、選択不可。
散々いろんな方式を客先にデモまでしたりして数ヶ月かけて折衝した挙句、現タイミングでは業務での使用に耐える立体視方式を発見する事ができず、現行システムで使われている機材（CRT）をサポートできる期間いっぱいまでオーバーレンタルしてもらい、サポートが切れる数年後に、その時点で出てきていると期待されるであろう新方式の立体視技術を再検討し別途調達する、という形で客先合意が取れ落ち着いた。
というのを、両方とも1仕様決定＝1ゲインとみなされたのではたまったもんではない。
勢い、普段これだけのパフォーマンスを出す奴が解決にこれだけかかったのだから、というのをゲインの指標と見るのが一番合理的になる。
で、俺は別にあらゆる業種に通用する真理を語ろうとは思ってないし、飽くまで自分の生活体験から自分のテリトリーのことについて語っているだけなので、こういう話になる。
別にこれが、nipotanの業種でも同様に成り立つとは思ってない。
どんな業種でもその業種に最適のやり方があるのだろうから、それを選択すればいんじゃないの？と思う。
otsuneネ申の福音を待つばかりの奴隷でございます
プロ奴隷の定番の言葉キター > 悪いのは俺じゃなくて、経営者連中だし。
えーん、otsuneネ申にDISられちゃったー（涙）
いやでもマジ奴隷みたいなもんでしたよあの頃は。
経営陣からは「奴隷」じゃなくて「駒」と呼ばれてましたが、一山いくらの。
奴隷は奴隷なりに反抗の狼煙はあげたんですけどねー。
もうあの経営陣に任せてたのでは、座して死を待つしかない！ってんで、技術・企画担当の私、文筆・編集担当の女性社員、特許・営業担当の男性社員の3人で経営陣から独立したビジネスユニット作ろうとして、3人それぞれでできるスキルや会社の持つ特許等の資産の棚卸し、ブレインストーミングを重ねて、やっと成り立ちそうなビジネススキーマ作り上げて、よっしゃやろうぜ！と立ち上がりかけたら、スキーマのキーマンだった特許・営業担当がサクッと解雇されて潰されたり。
4000時間労働の同僚（以下R氏）も、俺が辞めた後だけど、これじゃ駄目だというので大株主と取締役の1人を巻き込んで経営陣退陣・刷新のクーデターを起こそうとしたけど、取り込んだ取締役に裏切られて失敗してたなあ。
もう何というか、絶対王権ばりの経営権前面に押し立ててくる、それだけならまだしも、即日解雇みたいな違法な核兵器ばりの技まで使ってくるので、はっきりいってもう勝ち目がないんですよ。
（これも俺が辞めた後だけど、その後入った2人の技術者、2人ともR氏の子飼いになったんだけど、同僚の指示にしか従わず経営陣のいう事聞かない＆正社員は金がかかる、契約社員に置き換えたい、という理由で、R氏が階段で転んで肋骨を折って、1日会社を休んで病院に行ったその隙に、即日解雇された、って言ってたなあ）
唯一できる彼らへの最後の抵抗は、みんな、辞めるという選択肢しかなかった。
だから、まだ設立されて5年しか経っていない技術を売るはずの会社であるにも関わらず、過去に少なくとも2回、技術者が誰もいなくなって技術が断絶する、という事態が発生している（1回は俺とR氏が入る前、1回は俺とR氏が辞めた後。その後は知らん。もしかしたら3回、4回と記録を更新してるかもしれん）。
あ、技術者誰もいなくなったというのは言い過ぎか。
取締役にしてCTH（Chief Techinical 批評だけする人）或いはCTA(Chief Technical 余った研究費回して毎年10万円ほどだけ会社に貢献してくれる人)の大学きょーじゅがいるからなあ。
等とまあ、俺の立場からだけの一面的なことばっかり書き募っていてもアレなので、別の人の視点、R氏の視点からの文章も紹介したいと思います。
今はなきR氏の韓国語ブログの最後の記事を、私が思い出に取っておいたやつ。
ライブドア翻訳で、何とかギリギリ読める文章になってるので、是非読んでみて欲しい（特にotsuneネ申）。
読んで、私やR氏が前の会社でどのように行動していれば、奴隷にならずotsuneさんのようなモヒカン自由人になれていたのか、福音を残して欲しい。
おながいします。
2006年07月28日
報酬＝時間×単価が単純明快でいいじゃん
仕事を時間ベースでしかとらえられていない時点で旧来の日本文化にどっぷり。
うーん、俺は時間ベースでいいと思いますよ。
何故かって、報酬＝時間×単価だから。
個々人のパフォーマンス差は、単価の方で面倒みればいいじゃん。
時給いくらのパフォーマンス持っている人間が、何時間働いたから報酬いくら。
よっぽど単純明快で判りやすいと思うけれど。
もちろん、残業だけでなく、減らす方向も含めてね。
金なんていらねーから、今はしばらくヒマにさせて欲しいって時もあるわけだし。
私が年棒制といえばいいのか裁量労働制といえばいいのか、それを忌避する傾向があるのは、ある意味極限の地獄ケースを目にしてるから。
裁量労働でいくら働かせようが給与一定なのをいい事に、年間4000時間×2.5年働かされた同僚を以前持ってましたからね。
しかも、四半期毎に見直しと規定されていたはずの報酬見直しも、全く無視されて同じ額のままだったんで、入社時の契約が俺の方が上だったから、俺より少しですが低い年収で、それだけ働かされていましたからね。
今の俺の年収と比較したら、3分の2くらいの額でそれだけ働いてたんじゃないすか。
そんなケースで同僚のお前は何をしていたんだ！と言われそうですが、彼とは担当する部門が異なっており俺は俺で別の仕事があったから。
会社に泊まりこんで家に帰るのは月1回程度だった彼とは比較になりませんが、俺も普通の会社で言うならかなりきつい方の生活してましたし。
俺は、なんとか家族や健康、財産、その辺を崩壊させないギリギリのところで調整していた。
彼は実際に、家族も、健康も、財産も、開発成果も、そして外国人だったこともあり日本での生活基盤も、最終的には全部崩壊した。
彼とは今でも親友ですが、悪いけど彼に限界までコミットしていたら、俺も巻き添えで何かを崩壊させてた。
それはさすがに選択できなかった。
悪いのは俺じゃなくて、経営者連中だし。
そういうケースを知ってるから、時間では計れない価値があるから年棒、裁量労働制という考えにはすごく抵抗がある。
もちろん、裁量労働制でもちゃんと適切に報酬の見直し等運用されてれば問題ないんだろうし、時間制でもパフォーマンスにあわせた単価考慮が適正に評価されなければ意味ないのかも知れないけど、
少なくとも俺が知ってるケースのようなむちゃくちゃな経営陣に対し、裁量労働制では一切の抵抗手段がないけど、少なくとも時間制であれば、単価はパフォーマンスに見合ってなくとも青天井にすることで経営陣に抵抗姿勢を示す事ができるので、まだマシかなと思うのです。
（報酬一定だと思ってれば4000時間働かせようが何も問題に思わない経営陣でも、4000時間分の給料払わないとならないとなったら、何か考えるでしょ？）
残業は日本人の文化？DNA？
なぜなら、労働時間、いや、コードに触れる時間を制限してしまうというのは、責任感あるすぐれたエンジニアであればあるほどむしろ辛いものだからだ。
「あと５分あれば、このバグを潰せる」といった時に、「本日の就業時間は終わりました」と言われて退社しても、次の出社時間まで、そのバグのことで頭がいっぱいで休めない。
エンジニアというのはそういう生き物だ。
また、その五分を惜しまず「明日やればいいや」というタイプのエンジニアというのは伸びない。
優れたエンジニアは、皆「無理」の効用を知っている。
うーん、なんかちょっとズレてる気がする。
そもそも、5分とか残業ではつけられないし（つけられるとこもあるのかもしれないけど）。
少なくともうちでは最低でも30分単位だし、（実際に休んだかどうかは別として）定時後直後及び一定時間毎に強制的に「休憩時間が含まれたこと」にされてしまうので、例えば最低単位の30分の残業をつけようと思えば、休憩みなし時間を含め定時後45分間会社にいないといけない。
つまり40分残っていても、それは残業なしとみなされるのだ（まあ、厳密運用すれば、なので、実際の現場では個々人の裁量が入るが。タイムカードとかで厳密管理してなくて自己申告制だし。）。
まあそれはささいな問題で、弾さんの元記事を「あと45分あれば、このバグ(ry」と読み取れば済む話なんだけど、弾さんの話にはもっと根本的なズレがあって、弾さんの書いているノリでの残業は、明日やる分を今日やる、的なレベルの話だから、今日残業する代わりに明日の仕事量は減って、定時に帰れるはずだ。
でも今のIT業界の残業問題の問題点はそういう話じゃなくて、残業する/させることを最前提におかなければうまく回せないようなマネジメントになっていることなのではないかと思う。
しかし、残業残業！で力技でやるっつうのは、日本人のDNAに刻まれた文化なのかね。
この点では、旧態然とした業種でも、新興のITベンチャーでも、あんまり差はないような気がする。
違うのは、でっけえ会社は朝の時間とかきちっとしてるのに対し、ベンチャーとかだと昼前に来るとかが許される？くらいなもんで、夜は遅くまで突貫突貫！というのはあまり変わらない気がする。
WEB+DB PRESS Vol.33の宮川さんの記事でも、日本のベンチャー（要するに宮川さんが前いたとこだからライブドアだな）のそういう時間配分での仕事ぶりが書かれてる。
でも、日本の他の国では、そんなふうではなさそう。
少なくとも、私は中国の中堅SI企業や、アメリカの超大手電機企業、ヨーロッパのストレージ企業等とお付き合いした事があるが、国や企業の規模の差にあまり関係なく、皆一様に「定時後は基本的にみんな帰る」のが基本になってるみたい。
先述の宮川さん記事でも、今宮川さんが勤務されているアメリカのベンチャー（SixApart）では、ほとんど9時5時、みたいな話を書かれていた。
もちろん経営者とかは、国を問わず精力的に働くのだろうけど。
俺は残業はしないのがいい。DNAが日本人じゃないのかな。
もちろん必要な時はするよ。でも、必要じゃない時は残業しない、いやそれどころか勤務時間内でも用がなくなれば早く帰れるのがいい。
みなし残業を一定金額加味する裁量労働制だと、そういうふうに仕事がない時は帰ってもよいという制度もあるのだが（ただし建前上。病院に行くとかの理由以外で実際に定時時間中に仕事ないからあがります、みたいなことをするネ申をいまだ見た事がない。）、これはサービス残業の温床となってる制度なので俺は使ってない。
そうなると、残業代が付く代わりに、9時5時は拘束、という制度になる。
裁量労働と残業代制度の中間の制度ってないのかね...昨日2時間残ったら、今日2時間早く帰っていい、月トータルでオーバーした分は残業代がつく（当然足りない分は引かれる）、みたいな制度。
そういうのがあれば選択するのに。
サボって正解
サボったといっても、勤務時間中仕事しなかったっちゅうことじゃなく、言われたことしなかった、っちゅうだけだけど。
これまでやってきたプロジェクトのシステム構成設計が一段落ついて、残務はチームメイトを専任に充てることで何とかまわせる状況になったので、私は新しいテーマとしてシステムの脅威分析・対処設計に携わる事になった。
それはいいんだが、1週間後に客先会議あるからそれまでに資料まとめてねーって、何でいっつもそんなに話が急なのだ。
私、これまで構成ばっかりやってきたから、業務知らないんですけど...。
まあとりあえずどういう資料にしようか打ち合わせして、それに従い業務設計の各チームに超特急で調査・分析依頼のメール回して、3日目くらいに集まった回答を元に徹夜で資料まとめて、再度打ち合わせ。
するとどこのチームからの回答も、ハードウェア的な視点の分析しかなくて、ソフトウェア的な視点からの脅威分析が欠けていたので、そっちを重点的に再調査、資料修正追記との結論・指示が。
といっても、会議まで残り2日、今までの仕事の残務も完全に私抜きで動くわけでもないのでそっちにも手をとられるし、今から調査表回して再作成となると1週間の間に確実にまた徹夜、んなもんやっとられるかー、キックオフ会議なんだし限定した資料でええやんけー、とサクッと指示無視して再調査せずに会議に臨んだ。
当然上司には会議前にちょっと怒られたが、まあ言うても今さらどうしようもないので、できてる資料で会議に臨んだ。
そしたらいきなり、「こういう資料がみたかったんじゃないんだよね」ときた。
ハードウェア的脅威とか、ソフトウェア的脅威とか、そういうメーカ側の視点ではなくて、ユーザ側から見た、運用上生じるいろんな脅威をどう拾っていくか、という会議にしたいとの由。
とはいえキックオフ会議だったので特に怒らせたりということもなく、「次は頑張ってねー」のノリで、シャンシャン閉会。
20ページから作った資料も、数ページめくっただけで終わり。
どうせ何らかの資料がなければ会議の場には臨めなかったので、1日徹夜したのは全然OKなのだが、もし指示に従って2日徹夜して資料作ったにもかかわらず、こんな扱いだったならガクーッだっただろうなーと思うと、サボってよかったなと。
なんかこの辺の野生的カンというか、やっても無駄な事を直感的に嗅ぎ取る嗅覚というか引きの強さというか、そういうのはあるんだよなー。
サーバBackUpをGmailに保存
MySQLデータベースのダンプファイルをzipアーカイブして、メールサーバに送る、わりとアリガチなスクリプトを必要に迫られて書いたのでついでに公開。
はげしく便利そうなのでお薦め運用そのままで使わせてもらってます。
というか、やっぱりバックアップって取る事自体より取った後どこにどうやって整理・保存するかが問題になるよな。
その意味でGmailはいい保存先ですよね。
私もそれ自体は思ってたんですけど、Gmail FSあたりをマウントして使うことばかりを考えてて、それがうまくいかなくてあきらめてたりしてたんですけど。
よく考えりゃ、確かに単にメール送るだけでよかったんですよね。どうせ、Gmail FS使っても裏でやってることは同じだし。
でも、単にZIP送るだけじゃなく、GSpaceの管理する形式に則って送るとか、できればさらに便利かも。
あと、DBのバックアップだけでなく、ファイル・フォルダのtgz化→バックアップとか、トータルに使えれば嬉しい。
...となると、Plaggerの出番なんすかね。
2006年07月27日
そーいう手打ちになったんすか？
独り言。
消えてる...ちょｗおまｗ
そーいう手打ちになったんすか？俺が一方的にハブられて虚仮にされてんのかと思ったら、もしかしておばちゃん本気で認識なかった？
最近ブログの某界隈で割と話題になったあの1件が突如消えた（一時的にかもしれないけど）理由なんて、俺と本人しか判らない謎になるのだろうな...ワロス（悪意ないっすよ＞当事者）。
2006年07月26日
ケータイ位置情報で国盗り合戦ゲーム
MapionとＪＲトラベルナビゲータが共同で、おもしろそうなケータイ位置情報ゲームを始めているようです。
面白いなあ。
iエリアを使った信長の野望様のゲームとかは、昔っから位置情報利用系ゲームを考える際には話題には上がってたりはしたけど。
実際にゲームバランスとかを考えた具体的な企画にまで落とし込まれた事はなかったと思うので、なかなかエキサイティング。
一つの夢がかなったというか。
またこれを、小さなベンチャーとかではなくて、MapionやJRといった、比較的大手が形にしたというのも面白い。
まだ入会したばかりで、具体的なプレイ感とかはまだ試してないのですが、とりあえずご紹介まで。
やってみて面白ければ、さらに追記事書きます。
2006年07月25日
広告は場所が命
この1ヶ月半ほど、Google Adsenseの収入がこれまでの半分程度に減っていた。
理由は、Adsenseの場所を変えたからなのか、それともアクセス数が減ったからなのか。
アクセス数は確かに減っている。
でも、半分になるほどではない。
最近書く記事の傾向が、技術を離れてきているので、配信される広告の質が変わってきてるからかもしれない。
とか、いろいろ思ったんだけど、とりあえず試しに、3日ほど前にAdsenseを元の場所に戻してみた。
（ちなみに、この1ヵ月半ほどのAdsense配置場所はページの先頭記事の年月日の上、元の場所と言うのはページの先頭記事の本文直後）
すると、途端に収入が復調傾向に。
やっぱり、広告の場所って大事なんだなあ...本文読んだ直後の方がクリックしてくれやすいのか...。
率直でないにもほどがあるよ
何か良いことありそうだ...とか書いた直後によくない事の投稿なんだけどな。
どうも、某知人のＡさんに嫌われたらしい。
理由は、ある程度私を評価してくださっているＣさんからの情報によると、私があまりに率直過ぎるからだとのこと。
別に率直だってのは悪い事じゃないのでそんな理由で嫌われたのなら構わないけどさ。
問題は、その事を率直に教えてくれないでいろいろ回りくどく言いまわして、Ｃさんが「率直に」裏を教えてくれるまで、Ａさんに嫌われていることが判らなかったので、Ａさんとコラボレートできる機会があると私が長らく考えていたために、多くの機会損失をしたこと。
嫌ってるんなら嫌ってると「率直に」言えばええやん。
Ｃさんにその事教えてもらったあとの連絡でまで、「そんなこと知りません」みたいな書き方してきて。
別に俺に対してだけ、Ｃさんの言ってることとＡさんの言ってることとが矛盾してるだけならいいよ。
自分が私に書いてきたことが、Ｃさんが万人に大っぴらにやってる活動と矛盾してるということにも責任持たないつもりなんすかね。
Ｃさんがやってることの隣で、「のせられても責任者のＡさんは責任とってくれませんよ！」とか俺が言い出したらどうするつもりなんだろね。
そんなことしたらＣさんにまで嫌われてしまうのでしないけどさ。
別にとりあえず最低限のことすら認めてくれれば、全部白紙にして元に戻すって書いてんのに、それでさえ「率直に」ならず「そんなの知りません」ってどんなんだ。
率直を嫌うのはいいけど、最低限、常識程度の率直さくらいは持っていて欲しいもんだ。
もう妙齢の淑女のくせに、物腰の柔らかさにだまされた。何なんだ。
これ書いたらＣさん怒るかね。
でもまあＣさんの率直な内情暴露とアドバイスで終わってたら、まあ仕方ないかで収めるつもりだったんだけど、その後Ａさんから来たしらばっくれ連絡にムカついたのでつい書いてしまった。
あーあ、いろんなチャンスがあったのになあ。
はい、この一件はこれでおしまい！もう引きずらない！
何か良いことありそうだ
別にどうでもええことなんだけれども。
Bloglinesに登録してて、最近更新されてなくて訪れていないブログなんていくらでもあるんだが、今日昼休みたまたまhail2u.netが目に止まって、そういえばここ、長い間見てないのに新着記事ないなーと思って訪れてみると、やっぱり2005年10月からエントリなかった。
人気ブログなのに辞めちゃったのかな、とか思ってたら、その日のうちに9ヶ月の沈黙を破って新しい記事が投稿される現場に出くわしてしまった。
何たる偶然。
うーん、なにか良いことありそうだ。
2006年07月24日
Google Maps Hacks日本版発売!!(BlogPet)
2006年07月22日
HTTP::MobileAgentはプラグインだけじゃなくサブクラス独立もよろしく
HTTP::MobileAgentのプラグイン機構を付けるとしたら、どんな風なのがベストなんだろうかと考えてみた。
マジで動き始めてくださったようで嬉しい限り。
機構はプロフェッショナルな人々に任せるとして、個人的にはプラグイン以上に実現して欲しいのがサブクラスの独立。
今のライブドア版で、DoCoMo偏重でWILLCOMが味噌っかすにされている状況は、看過し難い。
今やDoCoMo独走状態というのでもなくなったし、WILLCOMは下手をするとSoftBankを超えて第3勢力に躍り出るかもしれない勢いなのに。
かといって、1メンテナで全キャリアをカバーするというのも無理があるので、各キャリアの専門の人が各キャリアのサブクラスを担当するという分業体制がベストだと思う。
で、どのキャリアかを判定する正規表現も各キャリアの開発者が定義すべきだと思うので、その辺でもちょっと工夫が必要かなと。
Yappoさんは各キャリア毎のDisplayMapを揃えて欲しいとのことなんだけど、これはイマイチ必要性が判らない。
au、SoftBankはDisplayMapを作らなくても環境変数から直接ディスプレイサイズが取れるはずなので、新機種が突如アクセスしてきても対応できる分こっちの方が確実だし、一方でDisplayMapを作らないといけないWILLCOMは、今度はMakeWillcomDisplayMapスクリプトで解析できるようなデータのまとまったページがないわけなので。
Yappoさんは、ユーザエージェント詐称での動作テストをするようなケースを想定しているのかな？
基本は環境変数で、設定によってDisplayMapも使えるようにするとか、或いはDisplayMapで動く版をそれこそプラグイン機構でプラグイン化するとかはどうでしょうか。
WILLCOMのディスプレイサイズ一覧等はWILLCOMが用意してくれなさそげなので、memn0ckさんやなおっきさんあたりが、スクリプトでパースできるような形でまとめてくれないだろうか。
そしたらテラウレシス。
PostGISのGeospatial化大作戦 その２
Google Maps Hacks、英語版ではつまみ読みしかしてなかったんですが、日本語版で通読してみると、サーバサイドで位置情報扱う時はPostGISを使う、とちゃんと紹介されてありますね。
組み込み幾何データ型の話など出てこず。
しかもPostGIS入門書として入門Webマッピングまで紹介されて...ありがたい限りです。
さて、先のエントリでは、PostGISでの正確な距離検索を行う関数 distance_sphere や distance_spheroid に対してインデックスが効かないので、これらの関数用のふるい関数として expand_sphere や expand_spheroid 関数を定義してやり、それによって事前ふるいをかけてやってから正確な距離計算をすればインデックスが効いて高速化するのではないか、と述べました。
しかし...この本届いたのはいいものの、ペラペラとめくってみたけどテラムズカシす。もう、マイボス・マイヒーロー状態。読む気もしねー。
というわけで、ふるい関数の実装は全然進んでないのですが、その前に本当にふるい関数を作れば高速化の効果があるのかを掴んでおくべきかと思い、ちょっと実験してみました。
使ったのは、このエントリで用意した、10万件の位置データが入った空間データベーステーブル。
ここで、先のエントリで述べた方法で導出したバウンディングボックスで事前ふるいをかけた場合とかけなかった場合の distance_sphere 関数による検索効率を比較しようという実験。
バウンディングボックスの計算には、ふるい関数は未実装なので、拙作のPerlモジュールLocation::GeoToolを利用した。
Location::GeoToolは距離計算を地球を回転楕円体とみなして計算するにもかかわらず、PostGIS側では地球を球としてみなす distance_sphere 関数を使っているが、飽くまで実験レベルなのでその程度の不正確さは見逃して欲しい。
まず、赤道上の東経140度、北緯0度を中心とした半径10kmの検索。
インデックスを使わない場合はこうなる。
postgres=# EXPLAIN ANALYZE
postgres-# SELECT id,geo_pseudo,asEWKT(geo_right) AS geo_right,distance_sphere(geo_right, postgres(# GeomFromText('POINT(140 0)',4326)) AS real_distance FROM geodata WHERE postgres-# distance_sphere(geo_right, GeomFromText('POINT(140 0)',4326)) < 100000; QUERY PLAN ---------------------------------------------------------------------------------------------- Seq Scan on geodata (cost=0.00..5086.66 rows=33333 width=45) (actual time=57.375..243.576 rows=3 loops=1) Filter: (distance_sphere(geo_right, '010...略...000'::geometry) < 100000::double precision) Total runtime: 243.719 ms
続いて、バウンディングボックスを定義してみる。
赤道上では、半径10kmの円に接する最大・最小の経度は、単純に東西に10kmの経度を調べればいいので、それでLocation::GeoToolを使って計算したところ、半径10kmの円は東経139.102度から140.898度、南緯0.904度から北緯0.904度の範囲に収まることが判った。
バウンディングボックスの効率的な作り方がよく判らなかったが、とりあえず以下のようなややこしい関数の組み合わせで作ってみたところ、
postgres=# EXPLAIN ANALYZE
postgres-# SELECT id,geo_pseudo,asEWKT(geo_right) AS geo_right,distance_sphere(geo_right,
postgres(# GeomFromText('POINT(140 0)',4326)) AS real_distance FROM geodata WHERE
postgres-# geo_right && SetSRID(MakeBox2D(GeomFromText('POINT(139.102 -0.904)',4326),
postgres-# GeomFromText('POINT(140.898 0.904)',4326)),4326) AND
postgres-# distance_sphere(geo_right, GeomFromText('POINT(140 0)',4326)) < 100000;
QUERY PLAN
----------------------------------------------------------------------------------------------
Bitmap Heap Scan on geodata (cost=2.02..21.53 rows=2 width=45)
(actual time=0.737..0.830 rows=3 loops=1)
Filter: ((geo_right && '010...略...CBF'::geometry) AND
(distance_sphere(geo_right, '010...略...000'::geometry) < 100000::double precision))
-> Bitmap Index Scan on geo_r_index (cost=0.00..2.02 rows=5 width=0)
(actual time=0.612..0.612 rows=6 loops=1)
Index Cond: (geo_right && '010...略...CBF'::geometry)
Total runtime: 1.119 ms
というわけで、見事240倍くらいの高速化に成功した。
次に、極周りでの実験。
円内に北極を含むよう、東経140度、北緯89.5度を中心とした半径10kmの検索。
postgres=# EXPLAIN ANALYZE
postgres-# SELECT id,geo_pseudo,asEWKT(geo_right) AS geo_right,distance_sphere(geo_right,
postgres(# GeomFromText('POINT(140 89.5)',4326)) AS real_distance FROM geodata WHERE
postgres-# distance_sphere(geo_right, GeomFromText('POINT(140 89.5)',4326)) < 100000;
QUERY PLAN
----------------------------------------------------------------------------------------------
Seq Scan on geodata (cost=0.00..5086.66 rows=33333 width=45)
(actual time=35.802..263.986 rows=455 loops=1)
Filter: (distance_sphere(geo_right, '010...略...640'::geometry) < 100000::double precision)
Total runtime: 272.990 ms
この半径10kmの円は、西経180度から東経180度、北緯88.605度から90度の範囲に収まるので、バウンディングボックスふるいをかけてやると、
postgres=# EXPLAIN ANALYZE
postgres-# SELECT id,geo_pseudo,asEWKT(geo_right) AS geo_right,distance_sphere(geo_right,
postgres(# GeomFromText('POINT(140 89.5)',4326)) AS real_distance FROM geodata WHERE
postgres-# geo_right && SetSRID(MakeBox2D(GeomFromText('POINT(-180.000 88.605)',4326),
postgres-# GeomFromText('POINT(180.000 90.000)',4326)),4326) AND
postgres-# distance_sphere(geo_right, GeomFromText('POINT(140 89.5)',4326)) < 100000;
QUERY PLAN
----------------------------------------------------------------------------------------------
Bitmap Heap Scan on geodata (cost=11.45..1744.03 rows=233 width=45)
(actual time=13.027..40.211 rows=455 loops=1)
Filter: ((geo_right && '010...略...640'::geometry)
AND (distance_sphere(geo_right, '010...略...640'::geometry) < 100000::double precision))
-> Bitmap Index Scan on geo_r_index (cost=0.00..11.45 rows=700 width=0)
(actual time=5.735..5.735 rows=1550 loops=1)
Index Cond: (geo_right && '010...略...640'::geometry)
Total runtime: 48.910 ms
速くはなっているが、赤道周りほど高速化していない。
これには理由があって、元々極域はバウンディングボックスが大きくなる上に、この実験では検索する点を球面上ではなく経緯度平面上でランダムに散りばめたので、極域では検索点が密集して、ふるいに引っ掛かる点が多くなり、それに対していちいち distance_sphere 関数の計算をしているので遅くなっている。
もし、ちゃんと球面的に平均して検索点が存在しているのであれば、そこまで遅くはならないはずだ。
最後に、経度180度を挟む場合。
この場合、経緯度平面は経度-180度から180度までなので、バウンディングボックスは2つに分割される。
まず素で検索してみると、東経180度、北緯0度を中心とした半径10kmの検索は、
postgres=# EXPLAIN ANALYZE
postgres-# SELECT id,geo_pseudo,asEWKT(geo_right) AS geo_right,distance_sphere(geo_right,
postgres(# GeomFromText('POINT(180 0)',4326)) AS real_distance FROM geodata WHERE
postgres-# distance_sphere(geo_right, GeomFromText('POINT(180 0)',4326)) < 100000;
QUERY PLAN
----------------------------------------------------------------------------------------------
Seq Scan on geodata (cost=0.00..5086.66 rows=33333 width=45)
(actual time=61.025..229.897 rows=6 loops=1)
Filter: (distance_sphere(geo_right, '010...略...000'::geometry) < 100000::double precision)
Total runtime: 230.094 ms
この半径10kmの円は、西経179.102度から東経179.102度、南緯0.904度から北緯0.904度の範囲に収まるが、経度180度で分断されるのでバウンディングボックスとしては2つになる。
postgres=# EXPLAIN ANALYZE
postgres-# SELECT id,geo_pseudo,asEWKT(geo_right) AS geo_right,distance_sphere(geo_right,
postgres(# GeomFromText('POINT(180 0)',4326)) AS real_distance FROM geodata WHERE
postgres-# (geo_right && SetSRID(MakeBox2D(GeomFromText('POINT(-180.000 -0.904)',4326),
postgres-# GeomFromText('POINT(-179.102 0.904)',4326)),4326) OR
postgres(# geo_right && SetSRID(MakeBox2D(GeomFromText('POINT(179.102 -0.904)',4326),
postgres(# GeomFromText('POINT(180.000 0.904)',4326)),4326)) AND
postgres-# distance_sphere(geo_right, GeomFromText('POINT(180 0)',4326)) < 100000;
QUERY PLAN
----------------------------------------------------------------------------------------------
Bitmap Heap Scan on geodata (cost=4.03..38.80 rows=3 width=45)
(actual time=0.809..1.003 rows=6 loops=1)
Recheck Cond: ((geo_right && '010...略...CBF'::geometry) OR
(geo_right && '010...略...CBF'::geometry))
Filter: (((geo_right && '010...略...CBF'::geometry) OR
(geo_right && '010...略...CBF'::geometry)) AND
(distance_sphere(geo_right, '010...略...000'::geometry) < 100000::double precision))
-> BitmapOr (cost=4.03..4.03 rows=9 width=0)
(actual time=0.650..0.650 rows=0 loops=1)
-> Bitmap Index Scan on geo_r_index (cost=0.00..2.00 rows=1 width=0)
(actual time=0.326..0.326 rows=6 loops=1)
Index Cond: (geo_right && '010...略...CBF'::geometry)
-> Bitmap Index Scan on geo_r_index (cost=0.00..2.03 rows=7 width=0)
(actual time=0.275..0.275 rows=6 loops=1)
Index Cond: (geo_right && '010...略...CBF'::geometry)
Total runtime: 1.212 ms
この例も馬鹿っ早になっている。
というわけで、このようなバウンディングボックスを導出してくれる expand_sphere 関数を定義し、distance_sphere 関数で検索する前に geo_right && expand_sphere(...) といった形でふるいをかけてやれるようにすれば、インデックスが効く形で正確な距離検索ができるようになる。
...と書いたが、実は最後の例に問題があって、最後の例では geo_right 列と2つのバウンディングボックスとのふるいを OR 文で繋いでいる。
これだと、単純に expand_sphere 関数でバウンディングボックスオブジェクトを返してやる、ということができない。
実は、最初はここで2つのバウンディングボックスを1つのマルチポリゴンにまとめてやって、それを使ってふるいをかけるつもりで、GeomUnion 関数を使ったこのようなSQLを実行してみていたのだ。
postgres=# EXPLAIN ANALYZE
postgres-# SELECT id,geo_pseudo,asEWKT(geo_right) AS geo_right,distance_sphere(geo_right,
postgres(# GeomFromText('POINT(180 0)',4326)) AS real_distance FROM geodata WHERE
postgres-# geo_right && GeomUnion(SetSRID(MakeBox2D(GeomFromText('POINT(-180.000 -0.904)',4326),
postgres-# GeomFromText('POINT(-179.102 0.904)',4326)),4326),
postgres-# SetSRID(MakeBox2D(GeomFromText('POINT(179.102 -0.904)',4326),
postgres-# GeomFromText('POINT(180.000 0.904)',4326)),4326)) AND
postgres-# distance_sphere(geo_right, GeomFromText('POINT(180 0)',4326)) < 100000;
QUERY PLAN
----------------------------------------------------------------------------------------------
Bitmap Heap Scan on geodata (cost=18.12..2425.03 rows=392 width=45)
(actual time=27.708..39.353 rows=6 loops=1)
Filter: ((geo_right && '010...略...CBF'::geometry) AND
(distance_sphere(geo_right, '010...略...000'::geometry) < 100000::double precision))
-> Bitmap Index Scan on geo_r_index (cost=0.00..18.12 rows=1177 width=0)
(actual time=16.182..16.182 rows=1924 loops=1)
Index Cond: (geo_right && '010...略...CBF'::geometry)
Total runtime: 39.586 ms
ところが、何故かご覧のとおり、大量の検索点がふるいにかかってしまって、速度が出ない。
どうも、経度-180度から180度の間を全部引っ掛けてしまっているっぽい。
何故かよく判らない。マルチポリゴンの作り方が悪いのか？GeomUnion 関数じゃ駄目なの？
この次はこの辺を、もうちょっと追求してみたいと思う。
2006年07月19日
Google Maps Hacks日本版発売!!
|
Google Maps Hacks -地図検索サービス徹底活用テクニック-
posted with amazlet on 06.07.19
Rich Gibson Schuyler Erle 武舎 広幸 福地 太郎 武舎 るみ
オライリー・ジャパン (2006/07/22) |
Google Maps Hacksの待望の日本語版が発売されました。
ペラペラとめくってみましたが、原著から翻訳版までの間の状況の変化等もしっかり押さえてあり、中々の出来。
中でも感心したのは、日本版での環境での事例や、原著の頃との状況の差等が、注やコラムの形ではなく、本文の訳文の中に自然に織り込まれていること。
それでいて、特に不自然さもなくすんなり自然に読むことができます。すごくすてきな翻訳。
この辺、入門Webマッピングも見習わないとな...と言ってももう直せるわけじゃないですが...次同じような機会があったなら、がんばろう。
（というわけで、Mapping Hacks又はPragmatic GISの翻訳のチャンスを！とか言ってみたり。）
あ、そうそう、先日紹介した新雑誌「Make:」の織り込みチラシが挟まれていました。
こちらも中々面白そう。
先の記事でも書いたとおり、原書は季刊の雑誌ですが、日本版が続けて出るかは創刊号の売れ行き次第だそうなので、皆さん是非買いましょう！
2006年07月17日
ここギコの隠れ人気エントリ(BlogPet)
今日は広いうちなどされてませんが、ネットで人気などされてませんが
広い人気とサイトとか、うちとかを登録しなかった？
とか書いてみるの♪
*このエントリは、BlogPet(ブログペット)の「ここ」が書きました。
相手を信頼させる物言い
会社で受けさせてもらった人間ドックの結果が返ってきました。
最近ストレス太り＆薬の副作用もあり、体重が大台に載りそうなので今回はCTも受けたのですが、幸い内臓脂肪は正常値内で、メタボリック何とやらには罹っていない様子。
正常値内と言っても限界ギリギリなのですが、とはいえその一つ上は「軽度」なので、文句なしに「重度」だろうと思ってた割にはマシだったと。
まあ、なぜか昔から肥満の体の割りには、中性脂肪やコレステロール値は正常範囲内でも低い方だったのですが（今回も）。
しかし、そうはいっても実際の容量は体重の分あるわけなので、内臓に脂肪がなければ当然皮下に脂肪があるわけです。
ちょっと青い領域のすさまじさにクラクラとしてしまいました。
ただ高いのは尿酸値。これはもう10年近く前から変わらずかなり高い。
原因は不明。
尿酸値上昇の原因と言われる焼肉等の食生活だが、焼肉は大好きではあるけど、食べ放題じゃないところにいけるほど生活が豊かでもないので、特に東京に来てからは店を開拓しておらず、年に1度か2度食べる程度だ。
ビールにしたって、飲み会があれば結構飲むが、普段は週に1回か2週に1回程度、350ml缶を飲むか飲まないかという程度。
なので、何故高いのかはずっと不明だ。
そんな状況の私に対して、ドックの最後、問診の医者が顔を合わせるや開口一番、「あなた、焼肉好きでしょう！」。
この一言で、彼は一瞬にして「あ、こいつ藪医者だ」と私に思い込ませるミッションに成功しました。
彼の発言には2つの問題がある。
１つは、まず断定してかかっていること。
実際私がそうであるとおり、高尿酸値血症というのは必ずしも食生活が原因とはいえないケースもあるようだし、そしてその体全体の問題の、根本原因を洗い出し見つけてもらうために全体検査の人間ドックをやっているというのに、いきなり「こういう結果が出ればこう言えばよい」というマニュアルに当てはめた対応をしていること。
第2に、本質と関係ない部分に関して質問していること。
1つ目の問題があったとしても、まだ「焼肉、よく食べるでしょう」という質問だったらまだマシだったのだ。
本質は、焼肉を頻繁に摂取しているかどうかなのだから。
ところがこの医者の聞いてきた「焼肉が好き」かどうかは、「焼肉を頻繁に摂取する」ことと、一定程度の重なりはあっても本質的にはかかわりがない。
先にも書いたとおり、私のように「焼肉は好きだけどあまり食べない」というケースだってあるわけなのだが、この場合私は何と答えればよいのか？
馬鹿正直に、好きなのだからと「はい、好きです」と答えろというのか。
さすがに私の方はそのおかしさが判らないほど愚鈍ではないので、「はい、焼肉は好きですがそれほどは食べません。年に1、2度食べるか食べないかです」と答えた。
そしたら藪医者、案の定次の質問も、「そうですか、でも、ビールとかよく飲むでしょう？」との定型質問（「ビール好きでしょう」じゃない分進化したか？）。
それにも週に1本缶を飲むか飲まないかですと答えると、「そうですか？でも、尿酸値はそういう食生活が影響してきますから、気をつけてくださいね」で、終わり。
結局なぜ尿酸値が高いのか、何も判らず仕舞い。
この医者はほんの一言で私に不信感を植え付けたわけですが、それなら信頼される物言いをするにはどうすればよいか？というと、このケースの場合は彼の発言の問題点の逆、つまり、
- 主観を断定するのではなく、客観的に探りを入れるアプローチ
- 迂遠な表現を避け、本質となることそのものを対象とするアプローチ
が必要だったのだと思う。
つまり、「焼肉をたくさん食べ過ぎたりしていることはありませんか？」みたいな。
そういう質問をすることで、それが否定されたとしても別の可能性を検討する方向に話を持っていく流れを作ることができる。
（もちろん、主観的物言いでも、否定後別の可能性に話を持っていく事は可能だが、そもそもの「断定」が別の可能性を語ることを想定していないと捉えられるので、第一声で与える信頼感には格段の差がある。そして実際、今回のケースでは、別の可能性は想定されていなかった。）
もちろん、あらゆるコミュニケーションの局面で、上記の2点が考慮すべき点である、とは言い難いだろう。
でも、あらゆる局面に通ずる真理は、もう少しメタな次元で考えれば判ると思う。
医者の問診というのは、どのような役割が期待されているのか？
それは、情報を入手する前からの医者の主観的な断定を押し付けるための場ではなく、客観的に患者の体の状況に関する情報をできるだけ正確に集め、それを元に判断を下す場である、という行うべき役割の本質を弁えて発言していれば、決して今回の医者の発言のようにはならないはずだ。
結局、結論としては当たり前すぎるものになるが、その場その場で自分の果たすべき役割を本質的に理解して、その理解を元に語るべきことを十分吟味する、という事になるかと思う。
でも、その当たり前のことが、往々にしてできないわけであるが（私自身も含めて）。
ところで、尿酸値の件、これまであまり深く考えず高いという事実だけを受け入れてきたのですが、この人間ドックでいい加減にあしらわれたのをきっかけに、もうちょっと自分で何が原因か考えてみようと思うようになった。
で、自分でいろいろ調べてみた結果、肩こりが筋緊張⇒乳酸、尿酸などの老廃物の発生⇒筋緊張による欠陥扼腕による、老廃物の排出阻害⇒さらに疲労、筋緊張という悪循環でおこるという話を見つけた。
これが事実なら、私は頚椎変型症で常時首から肩、腕に至る筋肉が緊張しており、それによる神経扼腕で手指が痛んだり痺れたり、酷い肩こりが起きたり、という状況が日常となっている。
この症状が出始めたのも、ちょうど尿酸値が高くなり始めた10年前頃と一致する。
もしかしたら、頚椎変型からくる筋肉の常時緊張が、常時尿酸を大量に発生させ、尿酸値の上昇に繋がっているのかもしれない。
飽くまで素人考えだが、今度行きつけの内科に罹った時にでも、ちょっと聞いてみようと思う。
金持ち頭脳
金持ち頭脳やってみた。
よーし、2029年目指して頑張るぞー。って、ほとんど定年間近かよ。とほほ。
なんか私との、ビジネスパートナー相性診断もできるそうです。
あなたのお金持ち階級は「セレブお嬢様級」です（100点満点中77点でした）
総合評価：
タイプ：優柔不断型
大塚恒平さんは大変お金持ち向きの体質と言えるでしょう。今がダメだとしても将来には明るいものが感じられます。バランスだけではなく、生命力に高い数値を示しているので、能力にパワフルさを兼ね備えて磐石と言えるでしょう。
また、価値観が柔軟で環境の変化にも頭の中は適応しやすいのですが、実際に行動するにはあれこれ考えすぎてなかなか重い腰の上がらないタイプのようです。決断の遅さで逃してしまうチャンスもありそうです。
バランス評価：
先天性（ランクS）
素質とその後の成長はあればあるほど良いのは当然ですが、そのバランスが高く評価されました。自らの能力に奢らず、成長のための努力もほどよく維持しているという点で一般的理想像に近いようです。今後も自分の素材を見極め、自分に向いている分野を開拓して極めましょう。
善悪（ランクB）
「善悪」の傾向は、お金持ち理想像とは少しずれているようです。世間一般は、もう少し悪人であるべきということのようです。立派な人としてではなく、お金を稼ぐためにはですが…。目的のためには手段を選ばないことも必要ということでしょう。
理論と行動（ランクS）
理論派か行動派かというバランスは、理想に近いと評価されました。理論も大切ですが、経験からしか学べないこともある、というのが世間のお金持ち像のようです。大塚恒平さんはそのバランスが程よく、高い評価を受けたといえます。
過程と結果（ランクA）
「過程と結果」のバランスは、世間の理想像と近いようです。ひとつひとつの過程も、結果を出すことも、どちらも重要という中間スタンスが理想に合致したようです。事の重大さなど、状況に応じて何が最優先であるかを判断できることが高い評価を受けたと言えます。
繊細と大胆（ランクA）
繊細さと大胆さの傾向においての評価は普通です。ある程度は評価できますが、ややお金持ちの理想像と比較すれば繊細、言い換えれば神経質であると言えそうです。もう少し図太さと、あっと驚くような派手さがあってもいいのかもしれません。
信念（ランクA）
とくに理想的でもなく逆行しているわけでもなく、ほどほどの結果です。少し信念に欠ける部分が評価を押し下げています。環境に対応できるということは良いのですが、いざ指針が見えなくなったときに迷いが生じるタイプと判断されたのでしょう。
おまけ
- 大塚恒平さんのお金持ち資質は、日本人口1億2千7百万人のうち第2571万0531位に位置します
- 大塚恒平さんのお金持ちピーク予想は2029年です。そこそこ期待できる山となるでしょう
2006年07月16日
オークニーさんから横浜花火大会
家族で寄させてもらいました
入門Ｗｅｂマッピング翻訳仲間も集合
リクルート・マッシュアップアワード、Dukeマウス独り占めは夢に潰える
Sunのワークステーション1台とDukeマウス30台（1人に！）がもらえるというサン・マイクロシステムズ賞。ですが、訂正させてください。
実は、Dukeマウスは先着30名だと、先日は発表されました（＾＾；
というわけで、リクルート・Sun主催のマッシュアップ・アワード、ネタとしてはそれなりにおもしろかったDukeマウス30台独り占め賞ですが、応募先着30名に変わったようです。
まだ間に合いそうという事なので、皆さん応募されてはいかがでしょうか。
そういう私も、何かやろうかなと思い、Google Mapsとのマッシュアップ云々だと既に私は後追いなアレですので、得意なケータイ位置情報と絡めてなんかやろうと思ってたのですが、HTTP::MobileAgent::Plugin::Location周りを整理しようと思っているうちにグダグダと時間が過ぎちゃった感じで、間に合うのかな？という感じです。
所有者に協力してもらっての、未対応ケータイの位置情報取得チェックもまだ今からやんなきゃだし。
でもまあアイデアはあるので（というか昔の引き出しから出してきたアレですが）、間に合わなくてもアイデアはブログ上で晒します。
...といいつつ、このアイデアって、今のリクルートWebAPIとの相性は悪い気がしてきた...HotPepperのAPIとかあればビンゴなネタなんですが...。
ここギコの隠れ人気エントリ
はてなブックマークなどには登録されてませんが、うちのサイトの隠れた人気エントリはいくつかあります。
人気エントリの定義もいろいろですが、単にアクセス数が多い、とかではなく、訪れてくれた読者の方の疑問・要望を満たせているか、という視点でピックアップしてみると、やはり一番人気はこのエントリかなと思います。
このエントリに対して、コメント、トラックバック、リファラー辿っての言及記事、メール、等等で寄せられた「助かりました！」の声は2桁にのぼります。
位置情報でも、オープンSNSでもない地味なエントリですが、それだけに息も長く、地味に人気を集めております。
これだけ人気なネタなのですが、伊藤家の食卓にはサクッと落とされました...。
これに追いつく勢いで、最近急速に台頭し始めているのがこのエントリ。
MovableType 3.2、MT::App::Trackback.pmの修正
MovableTypeのトラックバック受付機能に、「同じIPから大量にトラックバックが送られてくればSPAMとみなして、そのIPからのTBをはじく機能」がついているのだけれど。
しかしそのロジックの中に、「同じIPから」をチェックする判定条件が肝心なところで抜けているので、「同じIPから大量にTBが送られてくればSPAMとみなして、全てのIPからのTBをはじく機能」になってしまっているというバグの、修正をしたエントリ。
このバグを放置しておくと、トラックバック・スパムの雨に晒されているブログでは、どこからであろうと一切のトラックバックを受け付けなくなってしまう。
エントリを書いた時点ではまだうちほどTBスパムに晒されているサイトも少なかったのでそれほど目立たなかったが、最近TBスパムが手当たり次第になってきたので、みんな同じ現象に悩むようになってきたというところかな。
ただ、MT3.2の不具合は他にもいっぱいあるので、修正するならこれだけ単独で修正するのではなく、これも取り込んでいただいているMT 3.2日本語版Unofficial Patch - Ogawa::Memoranda -を適用するのが吉です。
でも、どうしてSixApartはこの辺の不具合のアナウンスも、修正パッチの公式配布もしてくれなかったんですかね...このTB不具合についてはどうか忘れましたが、少なくとも私が見つけた不具合の1つについては、ちゃんと6Aのサポートに連絡しているんですが...。
なんかその辺の不信感もあり、3.3でちゃんといろんな不具合が修正されてるのかどうかイマイチ不安というのもあり、また私もFastCGI化MTユーザなのですが、こんな情報もあったりするので、MT3.3アップグレードに踏み切る勇気が持てずにいます...。
2006年07月15日
映画って1週間で終わるのか...全然知らなかった
息子がマクドナルド・ハッピーセットのおまけのカーズにはまっているので、3連休だし連れて行ってやるか、と映画の上映情報見たら、もう終わってるやん！
最近の映画って、1週間で公開終わっちゃうの？
昔ってもっと、3週間くらいとかやってなかった？
映画ってもともとあまり見てなかったし、特に息子が生まれてからは映画館に赤ん坊連れて行くわけにいかないのでデフォルトでレジャーの選択肢から外れてて、全然判らなかった。
何時頃からこんななの？
仕方ないからカーズはDVDが出たらすぐに借りてあげる事を約束して、今日が公開初日のポケモンに連れて行くことで手を打ったけど...。
上に書いたように最近の映画事情判ってないから不安なんだけど、そんな短期間しか公開しないならみんな集中して見に来て、並びまくって大変だったりするのかな...。
超不安。
蛇足かもしれませんが...言葉ってうまく使わないと怖いな
既に縁のなくなった会社との適性なんかどうでもよいのですが、書いた事で人間性に対する誤解を招くと嫌なのでもう１エントリ。
論理的に言って、転職の面接上で私が「50％ルールで研究してみたいと話した内容について、ビジネスとの繋げ方を説明できなかった事」と、私が「ビジネスに結びつく研究がしたくない（＝自分の好きな研究しかしたくない）人であるという事」には、何の関連性もありません。
周辺情報なしで1回勝負の面接ではそう判断されても仕方ないかもしれませんが、Googleのルールと同じ基準かと勘違いしていたという事を説明しているブログ記事においてまで、そのような判断をされるのは心外です。
自分のやりたい仕事しかやらないような奴が、「GISとインターネットからの情報収集」をやらせてもらえるというから入った会社で、実際にはシステムの構成に関する設計・管理・客先折衝・社内調整等という全然違う事やっているにも関わらず、功労者として部長からうちのチームに慰労会開いてもらえたり、うちのチームだけ隣の部署の宴会にも呼んでもらえたり、みたいな事がありますかいな。
Googleの基準と同じだと思っていたから、TCP/IPの上にもう一つ別のレイヤ（認証・承認レイヤ）を加えてインターネット全体をSNS化する、という自分として最大のテーマを伝えただけであって、ビジネスとの繋がりが必須だと事前に判っていたならば、そんなもん面接の場では出しませんわな。
弾さんがいう「ライスワーク」と「ライフワーク」の差くらいは弁えているつもりなので、本来今回しゃべったことはライフワーク側に倒すべきこと、普通の会社の面接でなら絶対言わないネタですが、別に得られる限りの事前情報ではそれを言ってもいい場だと勘違いしたからそれを話したまでのことで、それが望まれてないと最初から判ってたなら話しません。
別に引き出しは一つじゃないんだし。
引き出しはいくつもあると言ったって、なんでもいいんじゃなくてサイボウズのビジネスと繋げなきゃいけないので、そこをうまく繋げる方法を考えないといけないわけですが、もし最初から50％をビジネスと繋げる方法が要求されていると判っていて、それが思いつかなかったのであれば、応募しなかっただけのこと。
行ってみたいけど、応募条件があわないから応募していない会社なんて、それこそGoogleを筆頭としていくらでもあるのだし。
で、俺が勘違いしたように、サイボウズラボの募集要項、特に50％ルールに関する書き方だと同じような勘違いをして応募してくる奴がわんさかいると思われる。
そんな奴は、俺と同じように勘違いしたプレゼンをして、みんな軒並み落とされるだろう。
転職活動というのも、エネルギーを使ってなかなか大変なもんだ、ましてや落とされるとなると。
サイボウズラボの方にしたって、面接には何人もがよってたかって「時間」単位での時間を浪費するのだ、落とすような結果に終わる無駄な面接は減った方がいいはずだ。
だから、サイボウズラボの50％ルールは字面から受けるイメージとは違うんですよ、ちゃんとそれを認識して事前準備してから応募、面接に臨んだ方がいいですよ、ということを忠告したくて、サイボウズラボ自身がそれを裏付ける発言をしたことを機に、先のエントリを書いたのだ。
その辺はちゃんと、先のエントリでも
というわけで、これからサイボウズラボに応募しようと思う方は、50%ルールで何をしたいか、だけではなく、それがどのようにビジネスに結びつくか、というところまできちんと頭を整理してから、臨まれた方が吉です。
今後続く人のために一助になればと思い、１エントリ設けさせていただきました。
と、ちゃんと書いてる。
しかし、やっぱり、面接みたいに1回勝負の発言で自分を判断されるというのは、中々つらいものがあるよな。
やっぱり同じように面接での発言で「失敗した！」と思ったのは、同じように落とされたSixApartでの面接の時。
これはサイボウズラボのように「もうちょっと判るように書いてくれよ」とかそんなのもなく、完全に私側のミス発言だったし、またこれも別にこの発言一つだけで落とされたとは思わないけど、SixApartに関しては複数回面接を重ねてきて、かなり友好的で自分でも「これは通ったな」という雰囲気を掴んでいたのが、その発言以降場の空気が変わったと感じたので、これが大きな原因の一つにはなっていると思う。
発言内容としては、前の会社を辞めた経緯を説明していた際に、「位置情報の仕事をやるために入ったのに、やりたくもない着うたの仕事をやらされた」と普通に聞けばとられかねない、やりたくない仕事はやりたくない奴だととられるような発言をしてしまったこと。
経緯がうまく説明できず一言で説明できずにそのようにとられてしまったが、実際はこのような経緯だったのだ。
着うたの仕事は、やりたくないどころか、最初は超乗り気だった。
理由は、経営陣から、「それをやれば、むちゃくちゃ儲かるらしい。月売り上げ1000万円とかいくらしいよ」といって企画を持ってこられたからだ。
やりたい仕事であり、また社是として会社が取り組むべき仕事であるはずの位置情報に関する仕事が全くできないのは、会社に金がないからだと判っていたのだから、金になるという仕事がやりたくないわけがない。
で、超乗り気で企画がスタートしたし、結構な額を投資してシステムも作り、楽曲提供先とも提携して、着うたサイトをスタートさせた。
嫌だったのは、この後の経緯だ。
フタを開けてみると、売り上げは散々、詳しい額は書けないが、まあ見積もりと2桁から3桁は違っていたと言えば大体判るだろう。
俺も話が違うので驚いたが、そこはそれ、仕事というのはPlan（計画）、Do（実行）、Check（評価）、Action（改善）のPDCAサイクルを回していくものだと考えていたから、儲からない理由を分析して、改善してい�