IT業界の最近のブログ記事

エンジニアの未来サミットに聴衆の一人として参加した。

　エンジニアの未来サミット
　　http://gihyo.jp/event/2008/engineer

第一部は、アルファギーク vs 学生
第二部は、20代〜30前半の技術者による、30代をどう生きるか

とても刺激になった。
35才以上は9%。そこに入っている私は超ベテランということになる。
プログラミングを引退する気はさらさらない。

- - -

懇親会で、吉岡弘隆さんと小飼弾さんの前に座った。
横はフリーランスのプログラマーのショータローさん（DesignIT!の懇親会で知り合った）。

吉岡さんと小飼さんの話は、吉岡さんより「ぜひブログにアップを」と言われましたので、
記憶を頼りに断片的なメモを作りました。

吉岡さん: 　コンピュータは、ムーアの法則の呪縛から逃れられていない。

　近年のマルチコア、マルチプロセッサの流れも、元をたどれば、80年代には
　その源流となる考え方があったし、論文も出ている。

小飼さん:
　いやしかし、安価にそういった技術を利用できるようになって始めて、
　実際につかえる発明がなされている。
　論文だけで終わるのと、実際に使えるものが創られるのは大きな違いがある。
　たしかに基本となるアイデアは提示されていたのかもしれないが、
　それを言ってしまうと、すべてフォンノイマンのころに考えられていた、
　といえなくもなくなってしまう。それは違うのではないか。

　まず○○（忘れた。プログラマブルなスケジューラのことだったと思います）の
　発明は大きい。

吉岡さん:
　コンピュータの真価は、仮想化の歴史。
　確かにマルチCPUが研究者の手元で使えるようになったのは90年代だが、
　60-70年代にも、今はできないが将来リッチなCPUリソースが使えるようになったら、
　どういうことが実現できるか、についてのアイデアが論文になっている。

小飼さん:
　しかし、Googleは予想できなかった。インターネットがこんな風に普及して、
　スパムがこんなに問題になるなんて予想は出来なかったはずだ。

吉岡さん:
　Googleなんて誰も予想できなかった。
　たぶん創業者のページとブリンも予想できなかっただろう。
　そういう意味ではMicrosoftだって同じ。
　ビルゲイツが始める前はソフトウェアが商売になるなんて、誰も予想していなかった。

小飼さん:
　IBMがCP/M を買っていたら、どうなっていたかわからない。

吉岡さん:
　CD-ROMをパッケージして売るのがパッケージソフトウェアの商売。
　それが、ネットワークがこれだけ大きくなって、サーバに置いておけば、
　ソフトウェアが配布できる時代になった。

　- - -

小飼さん:
　SMTPにかわるプロトコルが必要。
　技術的に代替できるもの、たとえばATOM/PPなど、候補はあるが、
　どうやって普及させるかが問題。
　FTPは、HTTPにだいぶ置き換わった。
　FTPはセッションがあった（ログインと送信が別電文）。
　SMTPも１メール送るのに4回もやりとりがある。
　たしかに、セッションを使うと作る方は楽が出来るけれど。

　- - -

小飼さん:
　Macintosh SE/30 の メモリを増やして fj を読んでいた。
　あのころはメガでメモリを数えていたよね。

　私はUnixを使ったのは、大学のエッセイ(レポート/小論文)を提出するために、
　使える環境がUnix上のgroffしかないといわれたから。
　私はエッセイを書きたいだけなのに。
　
吉岡さん:
　小飼さんは、UCバークレー以外にどこを受験したの?

小飼さん:
　アメリカの大学はほとんど書類選考なので10校くらい送ったけど、
　落ちたのは一つだけ。
　
吉岡さん:
　受かったのは？

小飼さん:
　○○○、○○○、○○○、（超難関校の名前がならぶ。おおお。）
　奨学金をもっと出してくれる学校もあったが、バランスを考えて、
　UCバークレーにした。

　・・・以上、内容不正確ですみません。ご指摘あれば訂正致します。
　　　コメントか、kawaguti at twitter まで。

追記: 写真アップします。

PCの税務上の耐用年数は4年だったとおもう。
もっと早く使えなくなることも、もっと長く使えることもあるだろうけど、
4年を基準に考えれば、毎年25%分は最低でも更新できる予算を組むべき、
・・・ということか。

職場で話題になった。
基本情報処理(以前の第２種情報処理)を受ける若い人がいて、
「CASLで受けようと思います。簡単だと聞いたので。」
なんていうものだから、話題沸騰。

同世代の人たちは、以外とCOBOLで受けた人が多く、
私のようなC言語は少数派らしい（だって他の言語知らんかったし）。
最近はJavaで受ける人が多いらしいが、ライブラリの挙動をたくさん覚えなきゃいけなさそうで、大変そうな匂いがするのは私だけだろうか。

たしかにアセンブリは勉強になると思うけど、
CASLが役に立つと思えない。そもそも勉強のための処理系ってあるの？

・・・・なーんて話の数週間後、
「C言語で受けることにしました」
と。

ええー、あと約２週間しかないのに、冒険家だなぁ。

前半は Life is beautiful読者でない人のための特別講義。
後半は対談です。（対談の方がページ数が多い。）

特に後半。ひろゆき、古川さん、梅田さんという３人との対談が秀逸です。
まずキャスティング勝ち。そして話の振り方が見事。

おもてなしの経営学 アップルがソニーを超えた理由 (アスキー新書 55)

posted with amazlet on 08.03.13

中島 聡
アスキー (2008/03/10)
売り上げランキング: 40

Amazon.co.jp で詳細を見る

読め。

優れた理論は、明確な反証可能性を持っているのに、反証できないもの。
優れた組織は、環境の変化を認識し、自らが効率的でなくなったことを認識し、適応して変化する。
優れたソフトウェア開発プロセスは、意図しない動作があれば確実にそれとわかるようにテストが組まれ、環境の変化があれば適切に変化することができる。

そんなソフトウェアの作り方を学んでいきたい。

＃なお、「なんとなくまだ信頼できないんだよな」とか「実績がない」とかは反証可能性が低い。

buchi氏がウェブ進化論を読んだそうな。

　W.B.W | ウェブ進化論 本当の大変化はこれから始まる
　　http://blog.buchi.tv/?eid=736203

正直なところGoogleのような優秀なプログラマが企画者でありビジネスマンでありプログラマでもあるといった形態を構築することが我々日本の企業には非常に困難であるように思える。

ああそうか、そうかもね。
まず日本に「優秀なプログラマが企画者でありビジネスマンでありプログラマでもある」という人がいるのかどうかがよくわからない。そのように職人を逸脱し、レッテルを越え、ある意味オリジナルであろうとする探求者が十分にいるのかどうかわからない。また、そういう探求者をまともに評価できる人がいるのかどうかが怪しい。もし、スティーブ・ジョブズが現代の日本人だったら、上場企業の社長になっていたかどうか？

まあ、こうやって思い込むのは簡単だ。
しかし、本当かどうかは検証のしようがない。
なのにそういう自虐的な事を考えてしまう「奥ゆかしさ」が日本社会の欠点かもしれない。

まず自分がそういう人になってみればいいんじゃないか。

- - -

石井裕さんが言っていた。
日本にも素晴らしい技術がある。
「アメリカでやっていないじゃないか。」で評価されない事が多い。
しかし、オリジナルなものには前例なんてないわけで。
オリジナルなものを評価できる人を日本にもっとたくさん作らなければ。

- - -

ところで、アメリカで「ウェブ進化論」が出版されたとき、日本で売れたほど、売れるのだろうか？

現在の主流のコンピュータ(OS)は、イベント駆動である。

1. イベント駆動OS
CPUなどの処理リソース全体のうち、管理用をのぞいた残りの部分を浮動票として、
みんな（プロセス）で仲良く使う。
一般道路のようなものだ。
なかには救急車などの緊急車両もあるので、先に通さなければならない。というルールもある。

共有すれば共有するほど効率は高まりやすい。
しかし、一方で、処理が溜りすぎれば、渋滞などを引き起こす。
横転トラックが道路を封鎖したり。みんなが同じリソースを食い合ってしまう。

2. 時分割(TSS)OS
初期のOS(大型汎用機)は、時分割(TSS)であったときく。
（私自身は、TSS自体には数時間しか触ったことがないので、あんまし実感がない。）

また、ロボットなどのリアルタイムOSも、時分割にちかい処理をしているはずだ。
（これもよく知りません。）

横転トラックが道路を封鎖しても、電気や水道が止まらないように、
役割分担をはっきりすることで、全体の最低限のスループットを維持する仕組みである。
(だんだん、メタファーが苦しくなってきました。)

あらかじめ処理を割り振るので、実際は行わない/必要がない時間というのが発生しやすいが、必要な時に必要なリソースが待機しているため、全体としての危機を引き起こさない。

3. イベント駆動OSの安全策としての分散処理
従来、イベント駆動のOSで、安全性を確保するためには、マシンをわけ、負荷を分散してきた。
一台がこけても他のマシンはこけないような配慮を行う。
そのために各マシンの装置の独立性を確保し、配分装置には精度の高いものをつかう。
そのためには、多くのマシンが必要になる。ネットワーク機器や負荷分散装置も高速で精度の高いものが必要だし、ネットワークも冗長化するためケーブルがたくさん必要になる。

しかし、資源枯渇が深刻になってきたため、マシンをホイホイと増やすわけにもいかなくなってきた。マシンの処理能力もフツーには伸びなくなってきた。

4. サーバ統合
そこで、一台のマシンを、時分割(TSS)で分割し、その中をイベント駆動で処理したい。
CPUがマルチコア化するにあたり、各コアを仮想のマシンとしてとらえれば、これまでマシンを複数にわけてきたケースでも、マシン一台ですむ（サーバ統合という）。
仮想マシン間の通信は共有メモリで代替できるので、そのぶんの、物理的なネットワーク機器やケーブルも削減できる。物理障害の影響が減り、待機電源も少なくてすむ。

VM(仮想化)はそういうニーズ(資源枯渇)と技術動向(マルチコア化)にマッチしていると考えられる。

5. イベント駆動と時分割(TSS)の組み合わせ
VMM(仮想化管理機能)自体がイベント駆動のOS上で動いていると、時分割(TSS)が正確にできないので、これまでマシンをわけてきたようには、安全でない。
そのためVMM自体が、時分割(TSS)を行えるOSであるほうがより安全であると考えられる。

ベアメタル型VMM(VMwareでいえばESXサーバ)はこの方向である。
VMM自体が極めて小規模なリアルタイムOSカーネルになっている（らしい）。

イベント駆動と時分割(TSS)を組み合わせる、ひとつの方法、トレンドである。

・・・そして、信じるか信じないかは、あなた次第、である（かもしれない）。

※ちなみにベアメタル型VMM(だけがイベント駆動と時分割(TSS)を組み合わせたわけではない。もともとOSはイベント駆動だが、各ハードウェアは時分割(TSS)だったりするわけだし。CPUクロックは完全に時分割(TSS)であると考えられる。時分割(TSS)は過去のモノ、なんていうのはナンセンス、ということである。

OracleがBEAを買収、の話は、旅行先で見ていたCNBCでいっていた。
SunがMySQLを買収・・・の方が個人的には大きな話題であったように思う。

MySQLがOracleの買収提案を断ったのが約一年前の話であるようだ。

ニッポンIT業界絶望論

この、やるべきと信じることをカチッ、カチッと片付けていく感覚、そしてその結果として他人から認定してもらえることの喜びが、幸せでないわけがない。

忙しくて忙しくて週に80時間以上働くような生活を何年もしていたけど、全然苦じゃなかったね。

それでもなお、いや、だからこそ、日本のIT業界は救いようがない。

うまいこと書くなぁ。

個人的には、そういう感性に付き合わないよう（そして、ほどほどには付き合うように）にやってきたつもりだけど、同じような焦燥感をひどく感じることはよくある。
（たとえば、石井裕さんの講演をきいたとき。）

じゃあどうするの、と考えるに、やはり江島さんが書く以下のような話にブチあたる。
私は江島さんほど顔は広くないし、たぶん技術力もないので、もっと閉塞的かもしれないけれど。

でも、日本にはそういうソフトウェア・プロダクトを製造する会社、ないんだよ、ほんとに。ちょっと前までは日本のネット業界で技術系のベンチャーなんてほとんど皆無に等しかったし、今でもそれほど状況が大きく変わったわけじゃない。

もはや借金してMITかStanfordにいくしか方法はないのではないかと、思うこともある（これは脱線だけど）。

ベンチャーであるかどうかが必要な要素かどうかはよくわからないけれど、チャレンジングな仕事も人材も少ないし、あまり求められてないのが日本の現状のように感じる。

これって、昔からそうだったわけじゃなかったと思う。
20世紀にはチャレンジなプロジェクトは、とくに研究開発分野では無数にあったように想像します（そのときにそこにはいなかったけれど）。2000年くらいまでのゲーム業界とかも勢いがあって、実験的な作品も多かった。

上のほうの世代のヒトが技術者現役だった頃は、もっと元気で、リスクテイカーだったんじゃないかと。
どこかで、日本のソフトウェア業界は守りに入ってしまったんじゃないか、と。

少子化で若いヒトの人口が減っているからかなぁ。
バブル期に少年時代を過ごし、バブル後に就職した団塊ジュニア（私たち）が弱いからかなぁ。

SIer と Rails とエンタープライズと - まちゅダイアリー (2007-11-10)

J2EE→Railsにスイッチするなら仕事のやり方も変えないと意味が無いというのが僕の意見。 とにかく頭数を揃えてガッチリしたものを作るやり方だと、前述の江島さんの指摘のようにいずれコスト面でパッケージに勝てなくなる。 なので、これからは、本当に必要な箇所だけを最小限の人数で作る手法が必要。 システムのコストは「開発」だけでなく「維持」でも発生するから、ちょっと拡張するのに費用がたくさん必要になるようじゃダメ。

しかも、だいたい初回の構築ではエンドユーザ（発注者ではなく、利用者）の満足のいくものは作れません。道具は、使っていかないと意見は出てこないので。その分、本来は、ある程度作り直しを前提でリリースをやらないといけないはず。昔の靴屋が足にあわせて靴を直すような感じで。ドイツのマイスターですね。

そういう手直しが工程に盛り込まれない。開発者は経験上そういうことがあるのはわかっているけど、見積りに盛り込みたくっても、根拠がないので、盛り込めない。しょうがないから、保守コストとかで見込んでいくのかもしれませんが、保守コストでは満足に開発者を維持できない。しかも設計にかかわるところは、あとから直せない。自動テストになっていないと、テスト工数も膨大。

この辺の問題をいくつかまとめてやっつける必要があり、
Railsのアプローチ（とかアジャイル）は、それをまとめてやっている感があります。

「それしか方法がない」なんていうのは証明できませんが、
日本語の障壁が破られ※つつある日本のSI業界としては、
オフショアにプログラミング職を奪われていった
米国の状況と似てきているわけで、
わりと有効なアプローチなんじゃないかと想像します。

※I18nのおかげで日本語専用のコーディングが必要なくなり、日本で日本人がプログラミングする必要がなくなってきたことを指しています。

Life is beautiful: 優秀なエンジニアは「入社時のスキルを問わない会社」には就職してはいけない

ちゃんと大学でコンピューター・サイエンスを学んだ学生は決して「入社時のスキルを問わない」ような企業には行くようなもったいないことをしては行けない。

ギクリ、確かにそうかも。
コンピュータ科学系を出て、プログラマーを募集していない※会社に入った半端モノである私の得た技は、（私的には）きわめて半端で、もどかしい限りですね。ううむ。

※そうでもないか。SEってことで開発者は募集してるし。

もっと余裕のない会社だったら、きつかったかもしれません。
私の勝手なリスクテイクを見逃してくれるフトコロのある会社だから、まあなんとか、やっていけてるのかな。

あ、そうそう、会社の方で人材募集中です。
AjaxとかRailsとかRubyとかErlangとか(C#とか)試しながら、足元からてっぺんまでやりたい人。ユーザビリティに熱意のある人、実装に熱意のある人、C++/Perl/Ruby/JavaScriptハッカー、テストの自動化に執念がある人、VMwareとかに心底ほれている人、「ナウなヤングはAirだろ」な人、shibuya.trac会員、右回りに見えてしょうがない変わった人などなど。

毎度、勇気づけられる、よしおか語録(敬称略)。
本にまとめていただきたい。

ユメのチカラ: 開発工程を別々に担当してはいけない

なんでこんなことを言うかというと、実装と設計は不可分で、実装をしてみて初めて気がつくこと、設計をしてみて初めて気がつくことなどがあり、実際の設計と実装というのはいきつもどりつのプロセスである。このいきつもどりつがない限り、いい実装などはできはしない。設計と実装を分断している限り、しょぼい設計としょぼい実装にしかならない。初めから完璧な設計などはないのである。完璧な設計でない以上、しょぼい実装しかうまれてこないのである。

- - -

１人で設計・実装できる範囲は知れている。というかもしれない。
その場合、より少ない実装ですむように設計を考え、現実的な要求仕様にすり合わせていくのも、必要な仕事のひとつではないか。とも思う。

OSS貢献者賞に奈良先端大の松本先生(茶筌 ChaSenの開発者)が選ばれたそうです。

2007年度OSS貢献者賞の受賞者が決定：ITpro

日本語形態素解析システム「茶筌（ChaSen）」を開発した松本裕治氏

RubyやSeaSerのブームに比べると地味かもしれませんが、形態素解析は検索や意味抽出になくてはならない技術なのです。

今年は、「ITmedia News：Yahoo！の日本語形態素解析エンジンAPIを公開」あんていう話もあり、注目が集まりましたか・・・。

イオンラウンジというのは、ジャスコの会員向け喫茶室。株主無料。

Web端末が置いてあって、キッズにやや人気っぽい感じ。端末はPCではなく、こういう奴だった。

Wyse Technology - Wyse Technology - 製品およびサービス

Wyseは、VMWareと提携して VDI(Virtual Desktop Infrastructure)を推進中の企業である。

[eWEEK] PCからデスクトップ環境を切り離したWyseとVMware − ＠IT

ポールグレアムの「マイクロソフトは死んだ」。
Microsoft is Dead 日本語訳

技術最先端企業としてはもう見られていないよ、という話である。4月公開らしいのでもう議論の旬はすぎているんじゃないかと想像するが、まだ読んでない人は一読をお薦めしたい。

イノベーションのジレンマ、に通じるこの文が面白いな、と思った。

驚くべき事実は、卓越したハッカー——危険なほど卓越したハッカー——は、マイクロソフトぐらいリッチな企業の基準にあてはめると非常にお安く雇えること。

優秀な１～２人の人間に起こせる程度のイノベーションに、何万人もの技術者を擁する巨大企業が挑む意味がどこにあるだろうか？逆に、何万人の技術者を動員して起こす巨大なイノベーションに立ち向かえる他の企業が地上のどこにあるというのだ？

・・・という話を、普通に会議で発言したら、だれもツッコまなさそうな気がする。「そうだそうだ」という人と「アホか」という人、どっちもツッコまない。

レガシーを問題にしても解決しない

レガシーでもしっかり動いてるシステムは一杯ある。 年金の背景にあるシステムについては NTTデータ がずっと取り扱っていて、かなりの予算も流れていたはずなのに、矛盾や問題点を解決できなかった経緯が何だったのか、それこそが最大の問題。

作った時点ではレガシーではないので、当初は「現実の問題を解決できるシステムになっているか？」を把握できていたかどうかが課題になる。そして年数が経って「現実の問題が既に解決できなくなっていることに気づけるか？」が課題になる。

いずれも結構難しい課題だと考えられる。

きっと、受注したシステム屋だけでも、発注した業務担当者（ユーザ）だけでも、単独では解決できない/理解できない/認識すらできない問題は多いはず。会話の中で、拾うべき問題を見つけ出して拾っていかないといけない。

問題を解決するのは検証済みの技術的スキルかもしれないが、
問題の発見と理解については、創発的な共同作業だったりする。

　- - -

日本の企業文化の深い根っこのところに、「分業->他業への無頓着」があるような気がしてならない。

業務を担当しながらプログラムも書いちゃうような人を「異端」「趣味の人」「なにやっているかわからない」と遠ざけてきた純血文化みたいなものが、もしかしたらあるんじゃないか。と疑っている。

「Javaに並列処理と関数型言語の要素を」、ティム・ブレイ氏 − ＠IT

　「Hadoopは外部ライブラリですが、Java言語自体で並列処理をサポートすることも必要」（ブレイ氏）といい、そのモデルとして2年ほど前から“Erlang”（アーラン）に注目しているという（参考記事：twitterブームの陰で注目を集める“Erlang”）。「Erlangはエリクソンが開発した古い言語ですが、とても興味深い特徴を持っています。きわめて効率的にプログラムの並列化ができ、ふつうのAMDやインテルのCPUを使って25万スレッドを動かすこともできます。ただErlangはオブジェクト指向言語ではなく、関数型言語です。つまり、一般的な言語になじんだ、ほとんどのプログラマには奇異に感じられるので、われわれとしてはErlangが持っているいいところを、もっと身近なRubyやJavaに入れていこうと考えています」。Java上で動くRubyの実装であるJRubyが、本家Rubyより先にこうした並列処理サポートを取り込む可能性もあるという。

Java上にJRubyと軽量プロセスが載ってきたりするのでしょうか。

ということにまず感動。
話題の道具は、すでに使える状態でそこにあった。

勘違いしていたのでかいておく。

  Microsoft        Adobe(Macromedia)
　Silverlight  <-> Flash
  ASP.NET      <-> Flex
  .NET exe     <-> Apollo

MSのSilverlightは、AdobeのApolloに対応するものではない。
リッチクライアントはすでにMSの得意とする分野。
逆にFlashの分野は弱いので、Silverlightで補強しよう、ということだと思われる。
だから、Silverlightはクロスプラットフォームで動く必要がある。

Javaはこの３分野をすべて扱える。
けどそれは、「C言語ならなんでも組める」というレベルの話かもしれない。
PerlScriptを使えば、Perlもこの３分野を網羅できそうだけど、
Perl/TkがDellのデスクトップにプレインストールされるってことも、
いまのところあまり想像できない。

勘違いに輪をかけそうだけど。

MS、「IE 8」の基本設計を示唆--セキュリティと使いやすさを追求 - ZDNet Japan

オブジェクトモデルもより使いやすさをめざすとのこと。
重畳。

死んでしまったら私のことなんか誰も話さない: GoogleのM&Aにみるハイテク業界の技術マーケティング戦略って

徳力さんのブログで、私も以前紹介したことがある韓国系ベンチャーのThinkFreeが、Googleに買収されるかも？という噂があることを知った。 それを知って、真っ先に浮かんだ感想は、「へぇ、GoogleもYahoo!と変わらなくなって来たなぁ」。

もしGoogleが、買収にあたって 「ソースコードと運用ノウハウを技術者ごと買う。そしてそういう技術者を環境ごと買う。」というポリシーだったら。。。

技術者を買う(既に優秀さを発揮した人を誘って、来てもらう)のは、単なるヘッドハンティング。
会社を買って、技術資産と技術者を継承するのは、企業買収。

いずれも獲得後のオペレーションがなかなか難しいんでしょうけれど、そのあたりをクリアして、Googleが「俺たちのほうがいいものをつくれる」から「あいつも俺たちの仲間になればもっといいものが作れる」に発展してたら、すごいかも。

買収した会社のソースコードは PerForce のディポ に突っ込んで共有する、とかいうルールがあるのかもしれない。。。

・・・あんまり深く考えてません。すみません。

おぉ。

三菱東京UFJ銀行，オープンソースのJava開発フレームワークSeasar2を大規模システムの構築に採用：ITpro

Seaserというのはひがやすお氏がプライベートで作りはずめたフレームワークで、だんだん有名になり、会社が認めて、という流れだった気がします。

IE7+ ・・・ Vista用のIE7。差別化のために+(プラス)をつけた
は やっぱり IE7に戻るそうです。

知らないと乗り遅れちゃうよ！(何に？)

IE7 - Windows Vista に含まれる IE7 の名前の変更

及川です。 「IE7+の発表」において、Windows Vista に含まれる IE7 を IE7+ と呼ぶことにすると書きました。しかし、IEBlogの「Revised IE7 Naming in Windows Vista」にありますように、皆様からの反対意見が多かったため、この方針を撤回し、Windows XP/Windows Server 2003 用の IE7 も Windows Vista 用の IE7 もどちらも単に IE7 と呼ぶこととしました。

※いろんな人の話の焼き直しですけれど、
　とりあえず適当な文書が見つからなかったので、書いておきます。
　間違いやおかしな点がありましたらぜひご指摘ください。
　出展やリンクがわかり次第、リンクしていきたいです。

- - -

今、私が使っているソフトウェアのほとんどは英語圏で書かれている。
OS, ブラウザ, データベース, プログラミング開発環境…。
例を挙げるまでもない。

それは昔から変わっていない。
しかし、ソフトウェア業界という観点でいえば、実は、大きく変わってきた。

英語で書かれたソフトウェアを日本語で動くようにするためには、

1:処理の修正
　日本語データが扱えない部位を特定し、扱えるように修正する。
　特に、英語を処理するためのソフトウェアは英語の文字コード(ASCII)を扱えればよいが、日本語は文字の数が多いため、英語をあらわす7bitのコード体系ではひらがなすら扱えない。8bit(1バイト)に増やせば、カタカナまでは入るが、漢字は無理なのでさらに拡張して2バイト分のコードで一文字をあらわす。つまり8bit対応に加えて2バイト対応が必要。

2:表現の修正
　英語が読めなくても操作がわかるように、メニューやヘルプの日本語化、つまり英語で書かれた文章の翻訳と埋め込みが必要。

この２点が必要である。

このなかで、1:処理の修正 は、英語と日本語のコンピュータ上での処理方法がわかり、ソフトウェアの内容自体も理解できるソフトウェア技術者が必要になる。全部できる人が必要。
しかし、2:表現の修正 は翻訳者さえいれば、埋め込みは英語だけわかればこなせる。なので、英語と日本語がわかる人と、英語でソフトウェアがわかる人が一人ずついればいい。ハードルは1よりずっと低い。

初期のソフトウェア製品は、日本市場を攻略するため、1:処理の修正 をこなせる人材を確保する必要があった。それは日本の中に多く存在した。なので、ローカライズ産業としてのソフトウェア産業は日本の中にあった。
英語圏で作られたソフトウェアのソースコードを日本に持ってきて、日本語処理のわかる日本人のソフトウェア技術者が日本語向けの修正に必要な点を抽出し、直す、ということをした。
日本語が処理できるソフトは日本国外にないから、その費用は価格に転嫁できた。
日本語版ソフトが50%高い値段で売られていたとしても、安いからといって英語版ソフトを買う人はいない。日本語が処理できないから。

しかし、２バイトを使う国は、日本だけではなかった。中国、韓国も２バイト必要であった。
日本、中国、韓国の市場を狙うならば、各国固有の２バイト処理を後から入れるより、２バイト処理そのものを、もともとのソフトウェアに埋め込んでおき、必要な点のみ各言語に翻訳すれば、手間が少ない。
なので、1:処理の修正 の作業が共通化できればコスト面でのメリットが大きい。

共通なのであれば、ソフトウェアを最初に作成する時点で２バイトを考慮するのもいいだろう。
そうすれば、英語圏でも日本語圏でも中国語圏でも、そのまま動くソフトウェアになる。

その方法を記した本が英語で出版され、英語圏の中で方法が確立していく…。
さらに、Unicode/UTF8という文字コード国際化の標準仕様ができ、その文字コードを扱えるようにソフトウェアを書けば目的を達することができるようになった。各国向けのローカライズではなくグローバライズだけを考えればいい、ということになった。
その結果、最近のソフトウェアは、ほとんどが国際化対応であり、そういったソフトウェアを作るためのソフトウェアも国際化対応である。

1:処理の修正 は、ほとんどが英語圏で完結するようになった。
英語圏でソフトウェアを開発して、英語圏以外でも動かしたいとしても、ソフトウェア自体の中身を詳しく理解している人は、英語圏にさえいればよい。

あとは2:表現の修正だけすれば、日本語圏でも中国語圏でも、多くの人が利用可能になる。最近は、翻訳はネット上でボランティアを募集してやってもらう、そういうWebアプリケーションもある。
オープンソースソフトウェアにいたってはすべてがボランティア（ないし寄付）だ。

一応、補足すると・・・、
世界中で動くソフトが作れるという恩恵は、日本語圏に対しても等しく降り注いでいる。
その点からすれば英語圏でも日本語圏でも条件は同じといえるかもしれない。
しかし、そこにはネットワーク外部性が働く。
ソフトウェアの多くが英語で生産され、作っている技術者の多くが英語でコミュニケーションをとっている以上、ソフトウェアの理論を学ぶ場としても、そういう人間が集まっている場所であることが、効率的になっていく。
現在、国際化したソフトウェアには、最低限、英語での説明がついている。それがノルウェーで作られようと、ハンガリーで作られようと、インドでつくられようと、日本で作られようと。

「このソフトウェアは世界の多くの人を便利にする力がある。」といっても、その言葉は日本人以外にはほとんど通じない。
"This software can help many people in the world." と、英語で書いてはじめて、国際化対応になる。文法がまちがっていたって、まだましである。「どんなひどい英語でも、日本語よりは通じる。」

英語で書かれた技術情報を、誰かが日本語に訳してくれるのを待つより、自分が英語を学ぶ方が早い、というケースもどんどん増えていくのではないか。
それは、完全な機械翻訳の実用化のスピードよりも、いまのところ早そうに感じる。

　企業のIT部門は縮小と変化を余儀なくされる──Gartnerが予測　　
　　http://www.itmedia.co.jp/enterprise/articles/0511/10/news019.html

　Gartner: IT groups shrinking, changing
　　http://www.computerworld.com.au/index.php/id;638983484;fp;16;fpid;0

　Versatilist
　　http://www.reference.com/browse/wiki/Versatilist

CNETでMSのAJAXアプリ開発用ツールの話がでていました。
マイクロソフト、AJAXアプリ開発用ツール「Atlas」を準備中 - CNET Japan

で、DonBoxのブログ経由で以下の説明にたどり着きました。
Atlas Project

クライアント側の仕組みは、ブラウザを問わないようです。

Atlas Client Script Framework
The Atlas Client Script Framework is an extensible, object-oriented 100% JavaScript client framework that allows you to easily build AJAX-style browser applications with rich UI and connectivity to web services. With Atlas, you can write web applications that use a lot of DHTML, Javascript, and XMLHTTP, without having to be an expert in any of these technologies.
The Atlas Client Script Framework will work on all modern browsers, and with any web server. It also won’t require any client installation at all – to use it, you can simply include references to the right script files in your page.

Atlasクライアントスクリプトフレームワーク

Atlasクライアントスクリプトフレームワークは、拡張可能な、オブジェクト指向の、100%JavaScriptで実装されたクライアントフレームワークで、AJAXスタイルのブラウザアプリケーション -- リッチUIとWebサービスへの接続性を持った -- を簡単に実装できるようにするものです。
Atlasがあれば、多くのDHTML,JAvaScript,XMLHTTPを持つアプリケーションを、それぞれのテクノロジについて専門家でなくとも、書くことができるようになります。
Atlasクライアントスクリプトフレームワークは多くの最近のブラウザとあらゆるWebサーバで動作するでしょう。そして、クライアントインストールは一切必要ないでしょう -- Atlasを使うには、あなたのページに正しいスクリプトファイルへの参照を含めるだけでよいのです。

唐突にNUnitをダウンロードして使ってみました。
.NET向けのユニットテストフレームワークです。Java向けだとJUnitですね。
ユニットテストのフレームワークというのに手を出す機会がなかったので、これがほぼ初体験です。

いや、まあ、なにをいまさら、なんですが。
Kent Beckの本を読んで eXtream Programingに共感していたものの、フレームワークは別かな、と。フレームワークなしでもユニットテストはできるわけですし。なんて調子で。

TopCoderに参加したときに、テスティングフレームワークにはじめて触れたのですが、おもしろいな、とは思ってました。
何より、他人のプログラムの誤りを自分のテストで論破した快感ったら。・・・動機が不純ナリ。

でまあ、前置きが長くなりましたが、ちょっと使ったんです。NUnit。

過去のテストをすべてためておいて、自動でデグレードチェックできるのは、便利だねぇ、と。
いやまあ、自分でログを出させて再現手順を記録する、なんてことはよくやるわけですが、そのまま再現動作可能な形式で残るっていうのは便利っぽいですね。途中で仕様が変わってきたときにテストツールもメンテするのは、ちょっと鬱になる作業ですが、見逃してデグレードが発生したときの鬱っていったら、ないですのでね。保険料としては、まあ納得できる額かもしれないなぁ、と。

しばらく使ってみます。

＠IT：.NET Tools ： NUnit入門　Test Firstのススメ ［NUnit 2.0対応版］

Cotton Bolls: NUnit Converter

- - -
(4/29追記)
うーん、このUIのウレシサがイマイチピンと来ない。
テスト用のコードを書く、という作業はいいし、
それでASSERTを入れてチェックするというのもわかる。
デバッグモードでコンパイル後のアセンブリを、NUnitのUIが
直接呼び出してテストできるのも嬉しいのかもしれない。
うーん、どうだろう。

コマンドラインでも呼び出せるみたいだから、むしろそっちの方が
テストを自動的・連続的に呼び出せてウレシイような気もする。

UIが課題のメインではないので、そんなものか。
はじめて動かしたときはちょっと感動したし、たぶん、ほかの人に
説明するときも、これで見せればわかりやすいだろう。
うん、そういうことはあるかもしれない。
ビジュアライゼーションによる、イメージの共有ってのかな。

そういうことで納得しよう。

Adobe の Flash になってしまった。
Adobe Reader上でFlashが動くようになったりするのだろうか。

＠IT：アドビがマクロメディアを34億ドルで買収

＃AdobeがAldusを買ったのを思い起こしつつ。
　ブランド戦略としても、うまいなぁ、と思われる。

AmazonのCTOのWernerVogels氏が、Blog上で "Job Opening"をやっています。

求めているのはスケーラブルな分散処理システムをきちんと設計できる実績＆能力のある人。
（でかつ、シアトルに行きたい人。）

All Things Distributed: Job Openings in my Group

-You know your distributed systems theory
-You have a good sense for distributed systems practice
-You have good common sense about scale and availability
-Some of your heroes have actually built real systems
-You have actually built some real systems yourself.

#個人的には、「いけるんならシアトルでもどこでも行きたいぞ」ってところは、合致。

ジャストシステムが地裁から一太郎の販売差し止めを受けた話。語りつくされていると思いますが、リンクを残します。

「一太郎」と「花子」が販売差し止め、ジャストシステムは控訴を表明

特許の開示資料を見ると、
「ヘルプアイコンから、対象の機能アイコンまでドラッグするとヘルプ表示」ってなことが書いてあるんですが、
"ドラッグ"ってこと自体は争点じゃなくて、ジャストシステムがつけた「マウス型アイコン」ははたして「アイコン」か？それとも記号か？("?"記号だけのアイコンは"記号"だという判例があるらしく・・・。)というのが主な争点だったとか(^^;)。

＃朝日は一面トップでしたね。日経は一面の真ん中の中見出し。

紹介元を忘れてしまいました※が、糸井重里氏インタビュー。

日経ビジネス　EXPRESS: 糸井重里氏の超ロングインタビュー

僕はこう考えています。1：新しいことは、不慮の事故から始まる。2：青写真を描いて設計したモノは、すでにある、だから2番手にしかならない。

＃梅田さんのブログでも今日、紹介されてました。
My Life Between Silicon Valley and Japan - 2/2 必読記事・論考(IT)

※2/3補足 ネタ元はここでした。
死んでしまったら私のことなんか誰も話さない: 変貌しつつあるメディア（糸井重里氏インタビュー）

なんかGoogleNewsがこのニュースばっかり。
作為はないのでしょうが・・・。

Googleが予想を上回る(この企業規模にしてはunusualな)好決算で株価がジャンプアップしたとのことで。

Forbes.com: Update 11: Google 4Q Profits Increase Sevenfold

でまあ、毎度ながら、ストックオプションの話がでます。

Google employees, hundreds of whom have become paper millionaires, will get another chance to cash in on the company's success Feb. 14 when IPO selling restrictions on 176.8 million shares of stock held by insiders are lifted. Analysts doubt the potential release of more shares into the market will depress the stock, based on how the price held up with the previous expiration of selling restrictions on 93.5 million shares between September and mid-January.

2月14日に株式公開(IPO)時の制限事項であるところの内部関係者が持つ176.8百万(株?)の売却制限が期限切れになることで、需給バランスが変わって株価に下向けの圧力がかかるだろうと。ちなみに、これまで9月から1月中旬にかけて93.5百万の制限が解かれてきたが、株価は維持されている。

depress:低下させる。弱める。

- - -

ストックオプション取得のタイミングによって持っている数や行使価格が違ったりして、社員間に軋轢を生んだりするのですが、Googleでもそういった格差は生まれているじゃないか、という話も。
富の重みにきしむグーグルの内情 - CNET Japan

今週の日経ビジネスに富士ソフトABCの「ハイエナ経営」の特集がありました。
東証コンピュータを買ったんですね。65%株主。

富士ソフトＡＢＣ

XP SP2は意外と静か
だったりしません？
みんな慎重になって、いきなり当てる人が少ない
というのがあるのかな。

ウチはどうしようかなぁ。