今日、Google で「Ruby」と「Python」で検索してインデックス数を比較してみました。

■ 日本語
Ruby　：2830000
Python：2580000

■ 全言語
Ruby　：97600000
Python：92400000

おお！　ついに Ruby が Python を超えた！とか思ったのですが、「Ruby Programming」「Python Programming」で検索してみたところ・・・。

Ruby　：32700000
Python：63300000

宝石の Ruby と蛇の Python じゃノイズの量が違うってことでしょうね。まだまだ Python の方が優勢ですねぇ・・・。

今日はオブジェクトの広場の有志（？）の方々と飲みに行ってきました。広場じゃない人も含まれていましたが。(^^;　朝にakapon さんが mixi で声をかけて召集した割りには、6 人集まって面白い飲み会になりました。私はというと、なんだかわけわからない話をしているうちに終了してしまいました。(^^; 最後なんだけどこんなんでいいのかな・・・？　ま、いっか。

S はシンプルの Sを読みました。面白いです。SOAP を取り巻く仕様の複雑さをうまく言い表しています。WS-* の調査に苦戦している後輩君もこの記事にはうなづけるんじゃないか？

S はシンプルの S より

SOAPの人 私が何て言ったかなんて忘れてください。 これからは大粒度メッセージをやりとりするんです。いいでしょ? 大粒度って言葉。メッセージは XML スキーマに従ったものです。この新しいスタイルは document/literal って言うんです。あ、古いのは RPC/encoded ね。

会社でも、これに似た話が出て、極力阻止しようとしたのですが・・・。大粒度。相互運用性とか非機能要求（パフォーマンスとかね）のことのことを考えたら・・・。

立石さんのブログに書かれた内容を受けて、もう少しホワイトカラー・エグゼンプションに関する話をしたいと思います。

立石さんのブログで以下のように書かれています。

したがって、同じ「プログラマ・ＳＥ」と言ったとしても、「求められる成果」によって ●「開発」型　●「生産」型　●「監視保守」型 の３つに分類して考えていかなければ、「働き方のあり方」を考えることは難しいのではないかと感じます。

この分類は大変良いようです。

「開発型」（研究・開発系）は賛成です。

「生産型」ですが、以前から立石さんがおっしゃっているとおり、上流に携わる人（私の中では PM や要求、基本設計などをする人）はホワイトカラー・エグゼンプションなどがふさわしいでしょう。製造工程の後半以降では、フレックスは良いのですが、裁量労働はあまり適切ではないと思います。往々にして、裁量労働を導入すると労働環境が悪くなるのもこの工程です。労働の時間帯は選べるべきですが、労働量は裁量しようがないでしょう。

ただ、問題があります。この記事を参照してください。

しかし間違いなく、年齢がプログラマの報酬の大部分を決定している。

このような状況では、裁量にした方が得かもしれません。たとえば、一日に 10 の仕事ができる人がいるとします。ある人は 8 で、 ある人は 12 です。（このように数値化することが難しいことは重々承知しています。）その人の生産能力に応じて給料（というか時給）が決まるのなら、裁量である必要はありませんが、残念ながら、IT 業界ではそういったもので給与が決まる傾向はありません。（基本は年齢。）この三者に同じ仕事させると、スキルの高い開発者ほど成果あたりの給与が下がってしまうことになります。（優秀な人にはたくさん仕事がいくので、残業代も多くなり、給料自体は高く支払われるとは思いますが。）

つまり、裁量労働にして、給料と成果に相関をつけるほうが時間毎の給料という観点では得ということになります。もっとも、こうした議論は本質的ではありません。なぜなら、このケースは「ちゃんと運用されているなら裁量を導入する必要がない」ためです。

「監視保守」型は、常時人を貼り付けておくことに意味があるわけですから、フレックスの対象にすらならないはずです。
# 夜間勤務が多かったりすると給料は良かったりするのかな・・・？
# そんなことない？？？

・・・で、私はここ 2 年位は研究開発型の仕事をしているので、ホワイトカラー・エグゼンプション歓迎なのです。（それ以前は保守開発プロジェクトなどに参加していましたが、裁量ではなく残業手当がちゃんとついていました。こうしためぐり合わせはたまたま以外の何者でもありませんが、結構幸せな働き方になっているのかも？？？）

ホワイトカラー・エグゼンプションについて でホワイトカラー・エグゼンプションについていくつかのブログを紹介させていただいたところ、立石さんからコメントをいただくことができました。あんなグダグダのエントリに非常に丁寧なコメントをいただき、ありがとうございます！

少しまじめに書きます。

立石さん wrote:

概ね「その人にとっては時間と生産量の相関」が認められることはご理解いただけるかと存じます。

なるほど。ここが意見の相違点のようです。ちょっと極端な例ですが、Joel 氏の例を挙げておきます。

Joel 氏 wrote:

私は最初の仕事以来、開発者としての自分が生産的にコーディングするのは平均して1日に2、3時間だということを認識していた。

Joel 氏 wrote:

ひとたびフロー状態になると、それを維持するのは難しくない。私の一日の多くはこんな感じだ:(1) 仕事にとりかかる。(2) emailをチェックしたり、Webを見たり、そのほかのことをする。(3) 仕事に取りかかる前にランチを取ったほうがいいと判断する。(4) ランチから戻る。(5) emailをチェックしたり、Webを見たり、そのほかのことをする。(6) いい加減はじめたほうがいいと心を決める。(7) emailをチェックしたり、Webを見たり、そのほかのことをする。(8) 本当に始めなきゃいけないと、再び決心する。(9) くそエディタを立ち上げる。(10) ノンストップでコードを書いていると、いつのまにか午後7:30になっている。

ここまで気まぐれな人は珍しいとは思いますが・・・。あるいは、ピープルウェアなどをお読みいただければよいかもしれませんが、生産性には投入時間だけではなくそのほかの要因も多く、それはわりと雇用形態を多様化することで、改善できるものでもあります。もっとも、ホワイトカラー・エグゼンプションですっかり改善するかどうかは別問題で、究極的には請負契約にでもするしかないのかもしれませんが。。。

立石さん wrote:

多くのプログラマやＳＥが自分で作業量を決められる立場になく、

ここが本質なのでしょう。「今日の午後はこれをやってください、明日の午前はこれ」というような仕事の進め方ならばそうでしょうが、ある程度の塊（一週間とか）で仕事をしている分には、「裁量できない」のではなく「裁量する権限がない」だけです。デスマーチに陥っていたらどうしようもありませんが。。。

立石さん wrote:

エントリ中にお気に障る部分があったかもしれませんが、ＩＴ業界やＩＴ業界に携わる皆様への「警鐘」としてご理解頂ければ幸いです。

ありがとうございます。本質的には、IT 業界自体が十分成熟しておらず、裁量労働とかホワイトカラー・エグゼンプションとか議論できるような状況になっていないことが問題なんですよね。

私は、本質的には SE/プログラマは成果で計るべきと考えているので、裁量労働やホワイトカラー・エグゼンプションの導入は賛成です。もっと雇用を多様化しても良いと考えています。仮に裁量労働制適用範囲外にしても、サービス残業になるだけなので、雇用を多様化して、成果とは何か、働き方をどうするか、議論する下地を作っていく必要があると考えています。

いい加減な元エントリに丁寧なコメントをいただいたことを、重ねて御礼申し上げます。m(_~_)m

すぐには実現されなさそうですけど、ホワイトカラー・エグゼンプションに関する議論が結構見られるので、あさってみました。

分裂勘違い君劇場 - 社員全員がホワイトカラーエグゼンプションの会社で働いてたことがあります

想像力はベッドルームと路上から - 「ホワイトカラー・エグゼンプション」の導入を阻害しているのは経営側である。

池田信夫 blog 労働は時間ではない

上記のエントリにはおおむね賛成。残業代ゼロ法案という表現は間違っていると思います。多様化した雇用形態への対応と考えるべきでしょう。

以下のエントリも基本的な議論は正しいと思いますが、一点。
コンサルタントのネタモト帳＋（プラス） 労働法務：「ホワイトカラー・エグゼンプション」の議論と労務コンプライアンス ～ ほぼ日刊で「経営の話題ネタ」を名古屋から発信！社労士・診断士のコンサルタント立石智工のビジネスヒント集

「ＳＥ／プログラマー」と呼ばれる方々には、「ホワイトカラー・エグゼンプション」を認めるべきではなく、本来であれば「裁量労働制」も認める対象ではないと私は考えます。なぜなら、彼らは「指示に基づいて指示された作業（設計書の作成、プログラマー）を行う」ことが本来的な使命であり、端的に言えば「ネクタイを締めたブルーカラー」に過ぎないためです。

「プログラマ 生産性」あたりでぐぐって欲しいものです。知的労働だから成果に関する個人差が激しい世界なのです。せっかく良いこと書いているのに。知らない業界のことは書かなければ良いと思うのですが。
# もっとも、「プログラマの生産性は時間で計れる」とした方が都合が良い側の人なのかもしれませんが。元業界の方だそうです。エントリの真意を見落としていたように思います。大変申し訳ありませんでした。（1/24 追記）
## あ、もしかしてこの業界は機械的に働いている人間が多いと指摘しているのかな？
## それならあたってないこともないか。。。

私は IT 業界の人間ですが、ホワイトカラー・エグゼンプションは賛成です。もともと残業代つかないし。改善活動のモチベーションがあがるでしょうし、働いていて楽しいのではないかと。難点は、成果を計ることが難しいことでしょうか。。。

「分裂勘違い君劇場 - 子供の「どうして勉強しなきゃいけないの？」→ 勉強することの具体的で直接的で切実なメリットを説明」を読みました。

で、ぼくが日々実感している、「勉強することによる具体的で直接的で切実なメリット」は次の4つ。 (1)もっと楽しく遊べる (2)もっと楽しく仕事ができる (3)もっとすばらしい友達をたくさんつれる (4)騙されてひどい目に合いにくくなる

説明は大人向けですね。でも、とてもわかりやすいです。子供のころにもっと勉強しておけば良かったと後悔しました。（笑）

そこで、これのピアノ版を考えてみました。ピアノといえば、「一日弾かないと三日分下手になる（二週間バージョンもあるらしい）」と言われ、毎日毎日根気よく練習することが求められます。子供のころは、これがいやでやめちゃった人もいるのでは？　大体、ピアノをやめる原因って、先生と合わないか、練習が詰まらないかですからね。

ピアノも勉強と同じで「たくさんやれ！」と言われるわりには、「ピアノを練習すると何がうれしいのか」は教えてもらえません。
「プロになるには練習が必要」 ← 別にプロになりたくありません
「何か一つくらい趣味を」 ← 別にピアノじゃなくてもいいじゃん
「なんでそんなことを思ったの？」と聞き返す ← 何にもモチベートされずに毎日ツェルニー弾いてられるかっての

えー、念のため言っておきますが、今は、私、たいへんピアノは好きで、練習も好きです。小さなころにちゃんと練習しておけば今頃はもうちょっとましにピアノが弾けたんだろうな～、と感じているわけでもあります。気が向いているときは、楽しく弾けるんですけどね～、毎日決まって練習というのはできませんでした。

そもそも、当時はピアノを上達しなくちゃいけない理由も良くわかりませんでした。習い事にはピアノに限らず級とかグレードとかがあるものが多かったように思います。上に上がっていかなくちゃいけないのに、私にとって大概の習い事には上に上がるモチベーションがなかったというわけです。
# 今はそういうのは嫌いじゃないけど。

というわけで、ピアノはなぜ上達した方がいいのか考えてみました。子供向けには説明できそうもないので、主に自分向けにしてみます。

「なぜピアノは上達しなければならないのか？」
(1) 楽しい
やはり好きな曲憧れの曲を弾けると楽しいものです。でもまぁ、好きになる曲がいつでも、自分の実力の範囲内で弾ける曲とは限らず・・・というか、たいていはその外にあるものです。だから、上達はした方がいいのです。弾けるかどうかは別として、せめて「チャレンジしてみようかな」と思うくらいの力が欲しいのです。

(2) かっこいい・・・気がする
確かに・・・オジサンがたどたどしくピアノを弾いている姿もアジがあって良いのですが、やはりバシッと弾けるオジサンになりたいものです。（注、私はまだ若いです！）

・・・う、もうネタ切れ。思いつかん。自分が何によってモチベートされているのかわからなくなってきた。ま、いっか。ピアノ弾こっと。

誰かがやるかな～、と思っていたらやはりやる人がいました。据え置き型のゲーム機である Wii をノート PC のように持ち運べるようにしてしまったようです。分厚い B5 か A4 ノート PC くらいのサイズですかね。

最近、未踏の開発のために開発に耐えるノート PC がほしいとか思ってたんですけど、これはいいかも！
# 多分、遊びすぎてプロジェクトが崩壊します。(^^;

mixi 内で「三国志時代の最強の五虎将はだれだ！？」というトピックがありました。趙雲、張遼あたりが人気のようです。まあ、使いやすそうですからね。

光栄のゲームでは、武将間に武力の違いを持たせているので、武将同士を一騎打ちさせるとある程度は強さの差が出ます。しかし、小説などを読むと、最強クラスの武将間に力があるようには見えません。劉備、関羽、張飛と互角に戦った呂布も、張飛や関羽との一騎打ちで互角だったりします。つまり、一騎打ちの強さでは、関羽、張飛、趙雲、呂布、許緒、張遼、典韋、甘寧、大史慈といったランクの武将はそれぞれ同等と見るべきでしょう。

※ ここでは、三国志演義をベースに話をしています。

それでも、三国志では武将の優劣を明らかにつけています。結論を言うと、関羽か趙雲あたりが最強でしょう。

理由を一言で言うと「見せ場のあるなし」です。残念ながら、呂布と張飛はこれといった見せ場がないんですよ。張飛は長坂橋がありますが、孔明が絡んでしまう（曹操は孔明に警戒したように見える）ので。関羽は千里行、趙雲は長坂坡です。凄まじさでいうと、趙雲の方がやや勝っているかなという気がします。正史を見る限りでは、趙雲はそれほどの武将とも思われないので、演義のひいきだと思いますが・・・。

とはいえ、このページを見る限り、やはり最強は張飛じゃ・・・とか思います。何せ、孔明に知恵比べで勝ってますからね。(^^;

Microsoft が Managed DirectX 2.0（.NET Framework 2.0 用の DirectX）の開発をやめてしまい、それに依存していた Rmake が動かなくなるという事件が発生しました。そこで、Managed DirectX 1.1 へ戻す作業を行っていた（メインは Dycoon 氏が作業していますが）関係で、久々に Visual Studio を触りました。

最近は Eclipse 上に載せた RAD Rails（Rails 開発用プラグイン）しか触っていなかったので、Subversion と統合していない（AnkhSVN とかありますが）から開発しにくいとか、ビルドしなきゃいけないからめんどくさいとかいろいろ違和感を感じていますが、どうにか作業を進めることはできました。

さて、今回は Managed DirectX のバージョンを戻す（2.0 -> 1.1）という悲しい作業を行ったのですが、本当は XNA（Windows でも XBox360 で動作するマネージドなゲーム開発用フレームワーク）を使いたかったわけです。しかし、既存の Window アプリとの親和性があまりよくないらしく、泣く泣く断念しました。

とはいえ、これは一時的な対処で、将来的には XNA かネイティブに乗り換える必要が出てくると思います。（大方の予想通り、Managed DirectX の未来は暗いのです。）あーあ、どうしたもんだろ。