Randomwalk

かつて書籍や雑誌の出版は、編集者とデザイナーと印刷所がそれぞれの専門性を活かした分業制でした。編集者が仕上げた原稿に対してデザイナーがレイアウト指定を行い、印刷所がそれに従って版を作成して印刷していました。

ところが1990年代後半から急速に普及したDTPの出現は、この分業制を変えていきます。DTPを使えばレイアウト作業もゲラの印刷も手元のPCで簡単にできるようになったため、コストや納期の圧縮といった事情もあって、デザイナーは最初にテンプレートを作る程度で、DTPを使って編集者が一人でほとんどすべての作業を行う現場が多くなりました。

カメラマンの世界でも、デジタルカメラの登場によって似たようなことが起きています。フィルムカメラの時代には、カメラマンが撮影したフィルムはプロ用の現像所で現像され、印刷所で見栄えの加工や調整が行われていました。

しかしデジタルカメラと高度なグラフィックソフトの登場により、すべての処理がカメラマンの一人の仕事になりました。カメラマンは撮影後に自分でデジタルデータを展開、見栄えの加工を行って、データ納品することがいまや普通になっています（実はそれどころではなく、デジタルカメラの登場によって撮影まで編集者の仕事になりつつあります）。

ITの世界でも変わっていく分業制

僕はITでも似たようなことが起きるのではないか、と思っています。これまでアプリケーションの多くはパッケージソフトとして販売されていました。パッケージソフトでは、開発を担当するプログラマと、それをサーバやPCにインストールして運営するエンドユーザーはそれぞれ別の組織に属しており、分業が成立していました。

しかしクラウドの登場が、この分業制を終わらせることになりそうです。業務システムはパッケージとして販売される時代から、開発した人（もしくは組織）がそれをクラウドに乗せて運用しユーザーに使ってもらう時代になろうとしています。

クラウドは、編集者にとってのDTP、カメラマンにとってのデジタルカメラのような存在になるのではないでしょうか。

DTPやデジタルカメラの登場は、「優秀さ」の定義も変えました。DTP登場後の優秀な編集者とは、原稿編集能力だけでなくDTPを扱える能力も含めた総合力での評価に変わりました。デジタルカメラ後のカメラマンは、よい撮影ができるかどうかだけでなく、データ加工したあとの画像がきれいかどうかで判断されるようになりました。

その一方で、やるべき仕事の種類が増えたからといって、編集者の給料も、カメラマンのギャラも増えていません。また、これらの変化に対応せず従来の専門能力だけで勝負する人たちももちろんいます。しかし、そのマーケットは明らかに縮小しています。

開発と運用の総合力で評価される

これをクラウド時代のITエンジニアやその組織に置き換えてみてると、これからは「優れた開発能力」だけでは優秀とはいえず、それを優れた運用によってサービスとして提供できてはじめて顧客に評価される、ということになるのでしょう。しかし一方で、それを理由とした高い料金を設定することはできない、ともいえそうです。

パッケージソフトの時代のチャンピオンであるマイクロソフトは、製品の開発力が強さの源泉でした。しかし現在、時代のチャンピオンとみなされるのは開発だけでなく運用においても圧倒的な存在となっているグーグルです。すでにITの世界でも、先端部分は総合力の勝負にさしかかっていると見るべきです。

これからやってくる「IT総合力の時代」。もちろん編集やカメラマンとは違い、企業などの組織の総合力が問われるとすれば、開発と運用が積極的に協力し情報を共有できるような組織作りと、両方を理解したうえで専門性を発揮できるエンジニアが必要になってくるのではないでしょうか。

本エントリはBlog on Publickeyからの転載です。

サン・マイクロシステムズはコード名"Vector"として進めてきたJava版のAppStore、Javaアプリケーションのオンラインマーケットの詳細を、6月1日にサンフランシスコで開催されるJavaOneで説明する予定です。正式名称は"Java Store"になるとのこと。

サン・マイクロシステムズ社長のジョナサン・シュワルツ氏が5月18日付けのエントリ「Jonathan Schwartz's Blog: Will the Java Platform Create The World's Largest App Store?」で明らかにしました。

Java Storeは、Javaプラットフォームが備えるソフトウェアのアップデート機能を用いてアプリケーションの配布を行う仕組みになる、と説明されています。現在のところ、このアップデート機能はJava本体のバージョンアップなどに用いられている機能。

How will it work? Candidate applications will be submitted via a simple web site, evaluated by Sun for safety and content, then presented under free or fee terms to the broad Java audience via our update mechanism.

またサンは、アプリケーションデベロッパーから配布料を徴収する予定です。

Java Storeで扱うアプリケーションはJavaで作られたものだけでなく、それ以外の種類アプリケーションもJavaのアップデート機能で配布可能なようです。

This creates opportunity for everyone in the developer community - and specifically, for any developer (even those not using Java/JavaFX) seeking to reach beyond the browser to create a durable relationship with their customers

Java Storeの詳細やリリース日程、アプリケーションの登録方法などはまだ発表されておらず、6月1日から開催されるJavaOneで発表されるとシュルツ氏はブログで説明しています。

本エントリはBlog on Publickeyからの転載です。

「マイクロソフト、サポートセンターです」と名乗った電話がかかってきました。はて、なぜマイクロソフトから？ と思って聞いてみると、Microsoft Online Services/BPOSに僕が登録した際の登録内容を確認するために連絡した、とのこと。

Microsoft Online Services/BPOSはマイクロソフト初のSaaS型サービスで、2009年3月にβ版が公開されるとすぐに僕はレビュー記事を執筆しました。その際に、氏名や電話番号などを登録をしていたのでした。

電話で聞かれたのは、漢字での名前（僕が登録したときは漢字で名前を登録する欄がなかった）と、入力済みだった住所の確認、それに登録の目的など。そして今後も情報をお送りしていいか？ と聞かれたので「メールでなら」と答えておきました。

実は、SaaSの雄であるセールスフォース・ドットコムのSalesforce CRMのレビュー記事を書くために登録をしたときにも、翌朝にはセールスフォース・ドットコムから電話がかかってきました。

「ご登録ありがとうございます」
「どういたしまして」
「なにかご質問などございますでしょうか？」

こんな感じです。どちらのサービスも、トライアルであっても氏名や電話番号の記入は必須です。

そういえば、SaaS型のCRMとERPを提供しているNetSuiteも機会をみてレビュー記事を書きたいと思っているのですが、ここもトライアル版に申し込むためには氏名や電話番号が必須です。やはり電話がかかってくるのでしょうか。

SaaSといえば、ネットから申し込んですぐに利用開始できるスマートなイメージがあります。しかしいくつかの製品を評価した経験からいうと、実際に業務に取り入れるには過去のデータのインポート、組織に合わせたアドレス帳の作成、画面や機能のカスタマイズなどの利用者側で発生する作業があります。

好意的に考えれば、こうした作業で顧客が立ち往生しないように、ベンダーが積極的にサポートする姿勢はSaaSの販売上必要なものなのかもしれません。

しかしそれなら必ずしも電話でなくともメールや、希望した顧客にのみ連絡をするだけでいいはず。電話での連絡には、ベンダー側が積極的に営業をかけたいという希望が多分に含まれているのでしょう。

SaaSのように進化したテクノロジーを使ってすべてがネットで完結するように見えたとしても、セールスの現場ではやはり日々地道な努力と顧客へのアタックが繰り返されているのだなと感じさせる出来事でした。

本エントリはBlog on Publickeyからの転載です。

アジャイル開発手法としてよく知られるのは、XP（エクストリーム・プログラミング）とScrum（スクラム）の2つでしょう。

どちらも反復型の開発手法で、XPはペアプログラミングやリファクタリング、テスト駆動型開発などが、スクラムでは原則1カ月のスプリント、毎日のスクラムミーティング、スプリントレビューなどが代表的なプラクティスです。

XPには活動の中心となるような公式な団体はないようですが、スクラムには普及やスクラムマスター認定のためのNPO法人としてScrum Allianceが活動しています。

そのScrum Alliance公認のスクラムマスター研修会が6月に秋葉原で実施されるとのことです。

6月に秋葉原で行われるCertified ScrumMasterセミナーの案内ページ

講師は外国の方ですが同時通訳が入り、受講料は2日間で20万円。スクラムマスターまたはスクラムチームの一員としての基礎知識を学べるそうです。

参加者はスクラムの基礎知識をもちおよびスクラム経験を前提とするそうですが、主催者の一人であるエマーソン・ミルズ氏によると「私の知っている限り、国内唯一の公認認定研修、世界唯一の日本語同時通訳公認認定研修です」とのことで、貴重な機会のようです。

先日は日本でのアジャイル開発手法の普及を目指したイベント「Agile Japan 2009」も開催されたばかりですし、コスト削減や短納期実現のための手法としてアジャイル開発手法が再び盛り上がっているらしい、という声も聞こえてきています（参考：「「Agile Japan 2009」開催！ どうすればアジャイルが日本で普及するのか？」）。

あるセミナーで聞いた話ですが、アジャイル開発手法の普及率は、米国では約25％、日本では5％程度なのだそうです。日本でもこれから米国並みにアジャイル手法が広まれば、ソフトウェアエンジニアがもっと創造的に活躍できるのではないかと期待しています。

本エントリはBlog on Publickeyからの転載です。

いままで日本には、グーグル、アマゾン、マイクロソフトといったメジャーなクラウドベンダーのデータセンターは存在しませんでした。しかし、日経コンピュータ4月29日号が報じたところによると、マイクロソフトのクラウド用データセンターが日本に設置されたそうです。メジャーベンダーによる初めてのデータセンター設置でしょう。

データセンターはWindows Live用で、Hotmailのデータを保存するほか、今後はSkyDriveのデータも保存されるとのこと。

建屋は日本の大手通信事業者が東京近郊に保有する設備を利用。マイクロソフト日本法人がデータセンター運営に必要な免許を取得した。

運用は4月から開始されているとのことです。

マイクロソフトにとって、クラウド戦略の中心にはWindows Azureがあるはず。コンシューマ向けのサービスから始めて、今後はよりサービスレベルの高い企業向けのサービスへとレベルアップしていくのではないでしょうか。

アマゾンやグーグルはコンシューマ向けビジネスでは国内でも強力なプレイヤーですが、企業向けクラウドサービスのベンダとして見た場合にどうでしょうか。何かトラブルが発生した場合に、企業ユーザーが納得するような十分な対応ができる体制があるとは思えません。それに比べると、マイクロソフトの日本法人は企業向けビジネスへの実績がある分、選択肢として優位にあるでしょう。

いままでクラウドは新しいテクノロジとして、トラブルなどがあっても自力で対応できる企業がチャレンジしてきた側面が強かったといえますが、今後多くのエンドユーザーが検討するようになってくると、こうした体制面での差が表面化してくるように思います。そして、規模の経済が利いてくるデータセンターの運営では、このボリュームゾーンにあるエンドユーザーをいかに取り込むかが重要になるはずです。

とはいえ、マイクロソフトのWindows Azureはまだ正式サービスを開始していません。最後発である分、国内にデータセンターを設置するなどの差別化の施策をしなければならないと考えているのかもしれません。

本エントリはBlog on Publickeyからの転載です。

サン・マイクロシステムズを買収したのはIBMではなくてオラクルでした。米オラクルは、サン・マイクロシステムズをおよそ7300億円（74億ドル）で買収すると発表しました。

この買収でSparc、Solaris、Java、MySQLなどのサン・マイクロシステムズの製品群はどうなるのでしょうか？ オラクルは、買収の発表と同時にいくつかの製品について今後どうするかについてFAQとして明らかにしています（Overview and Frequently Asked Questions(pdf)）。

まず、サンを買収した理由。

オラクルはこの買収で、オープンでかつ統合された完全なシステムを提供することを目指しています。オラクルはストレージからアプリケーションまですべての部品が統合され緊密に動作するシステムを提供することを計画しており、顧客は自分でそうした作業をする必要がなくなります。

ここでオラクルが言っているように、サンの買収によって、以下のパーツがすべて揃うことになります。

• ストレージ（StorageTek）
• CPU（Sparc）
• サーバ（Sun Fire）
• 仮想化（VirtualBox/Oracle VM）
• OS（Solaris/Linux）
• Java
• ミドルウェア（Oracle Fusion Middleware/GlassFish）
• データベース（Oracle/MySQL）
• アプリケーション（Oracle Applications）

1社でこれらを統合して完全に動作する形で顧客にシステムを提供するのが、同社の狙いとのことです。

続いて、製品計画に関するQ&Aの部分を要約してみましょう。

オラクルはサンのハードウェアビジネスをどうする予定ですか？

オラクルはサンのハードウェアビジネスをさらに成長させるつもりです。企業向けにはサーバやストレージのビジネスへとさらにフォーカスします。この戦略の鍵となるのは、ソフトウェア向けに最適化されたハードウェアを、技術的に統合した形で提供できる唯一の企業にオラクルがなるということです。

総論としてはハードウェアビジネスの継続がされるようですね。ただ、SunRayなどサーバ以外製品がどうなるかはかなり不透明なところです。

オラクルがSolarisを保有することで、Linuxに対するスタンスに変化はありますか？

ありません。オラクルは今後もいままでと同じようにLinuxやそのほかのプラットフォームにコミットしていく予定です。

MySQLはどうなりますか？

MySQLはオラクルの既存のデータベース製品群に加えられます。既存の製品群には、Oracle11g、TimesTen、Bekeley DBなどがあります。

ここでもNetBeansやGlassFish、OpenOfficeなどのサーバ以外のソフトウェアについては触れていませんね。

企業買収のときには、買収される側の企業の社員やその顧客が逃げないように安心させるコメントが出るのはある意味当然のことですので、そういう視点でこのコメントを受け取っておくべきでしょう。

本エントリはBlog on Publickeyからの転載です。

月曜日に自分のブログで公開した記事「SIerとパッケージベンダはどちらが高給？ IT系上場企業の平均給与を業種別にみてみた」は、スラッシュドットやはてなブックマークなどで取り上げてもらったおかげで、たくさんの人に読まれた記事になりました。現時点で約1万8000ページビューにもなりました。

さて、あの記事を書くに当たっていちばん手間がかかったのは、文章をまとめるところではなくて情報を集めるためにプログラムを書く部分でした。

というのも、記事で対象にした企業は載せなかったものも含めると全部で700社以上ありました。もしも情報収集をプログラムで自動化せず、マウスで1つ1つクリックして集めていたら、その作業だけで丸一日以上かかっていてもおかしくありません。情報収集をプログラムで自動化できなかったら記事を書くことはあきらめていたでしょう。

参考までに書くと、プログラミングとしてはwgetでWebページをまとめてダウンロードするためのバッチファイル1本と、ダウンロードしたHTML文書から情報を抜粋してCSVにするVBScriptのプログラムを1本書きました。プログラミングに費やした時間はデバッグなどを含めてもだいたい3～4時間程度です。

世の中のデータはどんどんデジタル化していますし、ビジネスの分野で見ても、多くのデータがネットに載るようになり、社内のコミュニケーションも顧客とのコミュニケーションもネットで行われていますから、プログラムで操作可能な情報は明らかに広がっているわけです。

これらのデータをなにか新しい付加価値を持った形で抽出、活用するためには、人と同じやり方ではなく、ツールをうまくカスタマイズして使ったり、独自のツールを編み出すことが重要な手段になっていくるかもしれません。

もちろん現在でも、多くの企業では経理の人が自分でExcelのマクロを組んで処理を行っていたり、営業も独自の処理方法を編み出して売上げを集計してたりしていますよね？ メールの振り分け機能を使いこなしたり、グループウェアのワークフロー定義を書いたり、アプリケーションの画面をカスタマイズする人たち、すなわち仕事の一部がプログラマー化していたホワイトカラーはこれまでも数多くいたわけです。

これからはその流れがさらに強まるように思います。

例えば以前のエントリ「Google、Twitter、Yahoo Pipes、Netvibesを華麗に使いこなす英国政府」では、英国政府がデータマッシュアップを使って情報提供を行う事例を紹介しましたが、これは広い意味でコミュニケーションを上手にプログラミングした例ではないでしょうか。

企業内で使うビジネス向けのマッシュアップツールも登場しています。IBMはエンドユーザー向けのマッシュアップツール「IBM Mashup Center 」を発表、「Excelより簡単」と説明しています。

先日レビューしたSalesforce CRMでは、営業レポートを利用者自身が柔軟にカスタマイズする機能が搭載されており、利用者自身でさまざまな分析を行うことが可能でした。

いままでデータ統合やレポート作成は、基本的には本職のプログラマーに発注すべき仕事でしたが、それを現場のホワイトカラーが構築するための環境が整ってきているわけです。

こうしてホワイトカラーの仕事の一部は広い意味で「情報を処理するためのプログラムを書くこと（マッシュアップを構築することetc...）」にどんどん置き換わっていっても不思議ではありません。

だとしたら、どれだけ便利にプログラミングやマッシュアップを実現できるかで、情報収集能力や情報分析能力に差が出てくるのではないだろうか、まさにホワイトカラーもプログラミング能力で勝負する時代になろうとしているのではないだろうか。

とまあそんなことを、記事を書くためにプログラムを書く、という作業を通して僕は思ったのでした。

本エントリはBlog on Publickeyからの転載です。

グーグルという会社は、例えばマイクロソフトやオラクルやアップルと比べると「戦略」といったものを積極的にはアピールしない会社です。

マイクロソフトやオラクルやアップルのような企業は、年に何度か大規模なイベントを開催し、現在の戦略や今後のロードマップを示します。しかしグーグルはそういった方法で将来像やスケジュールを明らかにすることはあまりなく、社内でこっそりと開発を続けて、ある日突然「こんなものができました」と発表する方を好むようです。

かつてGMailが登場したときも、そして先日Google App Engine for Javaが登場したときもそうでした。

そのためグーグルのクラウド戦略はどの方向に向かっているのか？ ターゲットとするデベロッパー層や、想定しているアプリケーションの姿といったものがどういったものなのか、次にどんな施策を打ってくるのか、といったことは想像するしかありません。

グーグルはいま同社のクラウド戦略をどう考えているのでしょうか。いくつかの手がかりを基に考えてみましょう。

Javaはビジネスアプリケーション対応の第一歩

Google App Engineが昨年登場したとき、サポートした言語はPythonのみでした。しかしPythonはPerlやPHPやRubyやJavaやBasicやCといった言語と比べて、明らかにマイナーな言語だったため、必然的に「Google App Engineで次にサポートする言語は何か？」に注目が集まりました。

グーグルがGoogle App EngineでJava対応を発表したときのブログ

そして、グーグルは途中でその答えを一切明らかにすることなく、「Java」という回答をある日突然に示しました。

なぜJavaだったのでしょうか。Google App EngineでJavaをサポートすると発表したブログ「Google App Engine Blog: Seriously this time, the new language on App Engine:Java™」では、その理由をこう書いています。

Java language support was both the first and the most popular request filed in the Issue Tracker.

Java対応は最も多く寄せられたリクエストだったため、ということです。また、技術的に考えても、PerlやPHPを移植するよりもJava、つまりJavaVMを移植する方が、JRubyやGroovyなどJavaVM上で稼働する言語にも対応できるため一石二鳥だったことも挙げられるでしょう。

しかしJavaの用途の大半はビジネスアプリケーションを構築するために使われているという点も見逃せません。Google App EngineがJavaをサポートしたことで、グーグルは少しずつGoogle App Engineをビジネスアプリケーションのプラットフォームとして使えるように進化させているようにみえます。

そして新たな企業向けツールも

グーグルはGoogle App EngineのJava対応を発表したときに、実はさりげなく企業向けツールの発表も行っています。それは、セキュアデータコネクター、データアップローダ、そしてクーロン（cron）対応です。

Secure Data Connector Developer's Guide

セキュアデータコネクター（Secure Data Connector）は、Google App Engineから企業内にあるサーバルームのサーバへ暗号化通信を提供するツールです。企業内でセキュアデータコネクターを稼働させると、グーグルのクラウド内で稼働しているトンネルサーバと暗号化通信が行えます。これにより、Google App Engine上のアプリケーションが企業内にあるサーバに認証を要求してシングルサインオンを実現したり、データ連係をすることができるようになります。

また、セキュアデータコネクターの機能はGoogle App Engineだけでなく、Google Appsのスプレッドシートなどからも利用できます（Premier EditionとEducation Editionのみ）。

データアップローダは、大量のデータをGoogle App Engineへと流し込むためのツール。Pythonで書かれたアプリケーションで、企業内のCSVデータをバッチでGoogle App Engineへとロードします。

cron対応はその名の通り、Google App Engine上のアプリケーションを、外部からの命令なしにいつも決まった時間に、あるいは定期的に実行する機能です。

最後のピースはリレーショナルデータベース

3つの機能の中で最も重要なのは最初のセキュアデータコネクターでしょう。これでオンプレミスのアプリケーションとGoogle App Engine上のアプリケーションが連携できるようになるからです。

Java対応とセキュアデータコネクターで、Googleのクラウドは企業内で稼働しているビジネスアプリケーションとの連携、クラウドへの移行への環境を着々と整えつつあるようにみえます。しかしビジネスアプリケーションにとっては、重要な最後のピースが足りません。

その最後のピースがリレーショナルデータベースであることは明らかです。果たしてグーグルはビジネスアプリケーションを本気でクラウドに乗せようとしているのか？ ならばリレーショナルデータベースが必要です。それとも、強引に現在のキーバリュー型のデータベースのままで押し通すのでしょうか？

グーグルの戦略がまったく聞こえてこない以上、推測するしかありませんが、僕はグーグルがクラウド対応のリレーショナルベースを内部で開発していると考えています。クラウドは規模のビジネスである以上、より多くのアプリケーションを動かして規模を拡大する方が有利です。

Windows AzureでSQLサポートを発表したブログ

アプリケーションのボリュームゾーンがビジネスアプリケーションである以上、ここを取りに行かない戦略はありえません。そしてリレーショナルデータベースがなければそこを攻略できないのであれば、やるしかないわけです。

マイクロソフトはすでに、Windows Azureでリレーショナルデータベース対応を明言し、実際に動き始めています。グーグルはどうするのか、正面から対抗するのか、それともなにかアクロバティックなことを考えているのか、みなさんはどう思われるでしょうか。

先週、グーグルの開発者向けクラウド「Google App Engine」がJavaのサポートを開始するという大きなニュースがありました。しかし、サン・マイクロシステムズでChief Open Source OfficerをしているSimon Phipps氏は自分のブログ「SunMink」で、Javaの互換性を軽視したグーグルの実装を批判しています。Computerworldが「Sun exec slams Google over App Engine's Java support」で伝えています（日本語記事）。

グーグルを批判するPhipps氏のエントリ

Phipps氏はグーグルに対してどんな批判をしているのでしょうか？ 彼のエントリ「Lump of Links for April 11 [on Simon Phipps, SunMink]」から、その部分を引用してみましょう。

Whether you agree with Sun policing it or not, Java compatibility has served us all very well for over a decade. That includes being sure as a developer that all core classes are present on all platforms. Creating sub-sets of the core classes in the Java platform was forbidden for a really good reason, and it's wanton and irresponsible to casually flaunt the rules.

要するに、「Javaがこれまで互換性を維持してきたのは、コアクラスのサブセットを作るようなことを禁止していたからなのに、グーグルはそれを守らず無責任だ」と彼は言っているのです。

グーグルがApp Engine上で実装したJavaに非互換性があるため、それを非難しているのです。

僕が想像するに、クラウド上で分散処理に対応したJavaVMを従来のJavaVMと完全に互換で作るのは相当に困難な作業で、公開したばかりの現時点で多少の問題が生じるのは仕方のないことではないかと思います。

また、そもそもクラウドのような分散環境のうえにJavaVMを実装することなど想定されていなかったはずなので、実装にあたっては何らかの制限なり変更がでてくるのも避けられないのではないでしょうか。

これを「無責任（irresponsible）」とまでいうのはちょっと言い過ぎのように思います。

グーグルも積極的にテストしてほしいと開発者に呼びかけているわけですし。

サン・マイクロシテムズも、Google App Engineとはかなりアプローチは異なりますが「Project Caroline」でJavaをクラウドに乗せようとしています。マイクロソフトでさえ、Windows AzureにJavaを乗せようと検討していると言われています。

この流れの中で、Javaがクラウド上にいろんな形で実装されるのは避けられないはずです。

だとすれば、クラウド上のJavaとはどうあるべきなのか、あるいは非互換が発生している原因は何なのか？ よりよいクラウド対応の言語として発展させる方向で両者が協力して正式なプロセスで標準化する、という動きになってくれると、Javaデベロッパーにとってはずっと建設的になるのではないでしょうか。

10年ぶりにJavaScriptがバージョンアップする見通しとなりました。JavaScript（正式名称はECMAScript）の標準化団体であるEcma Internationalが4月9日に「Ecma International finalises major revision of ECMAScript 」というリリースを発表しています。ファイナルドラフトとなるドキュメント「final draft ECMA-262 5th edition」も公開されました。

Ecma International finalises major revision of ECMAScript

新バージョンのECMAScriptはこれまでECMAScript 3.1と呼ばれていましたが、今後は名称が「ECMAScript 5th Edition」になるとのことです。そしてこれが一般的にはJavaScript 2.0と呼ばれることになるでしょう。

リリースからポイントを抜き出してみます。

The Candidate milestone designates that the authoring process is complete. This now begins a testing and validation phase of the project where TC39 members will create and test implementations of the candidate specification to verify its correctness and the feasibility of creating interoperable implementations.

今後のマイルストーンとしては、これで仕様を記述するプロセスは完了。これからテストと検証のフェーズにはいるとのこと。プロジェクトメンバーが仕様の最終候補版に沿ってテスト実装を行い、実際に問題がないかなどを確認することになります。

The test implementations will also be used for web compatibility testing to ensure that the revised specification remains compatible with existing web applications.

テスト実装では、今回のECMAScript新版が現在のWebアプリケーションとの互換性を備えているかどうかも確認する予定。

TC39 members Opera, Mozilla, and Microsoft have each committed to participating in this testing process.

このテストには仕様策定のプロジェクトメンバーである、オペラ、モジラ、そしてマイクロソフトが参加すると約束をしているそうです。

Testing is expected to be complete by mid-July 2009. It is anticipated that any technical errors and ambiguities will be resolved during this process, and that a final draft of the specification can be agreed upon in September for submission to the Ecma General Assembly for final approval in December 2009.

テストは2009年7月中旬に完了予定で、この期間中には発見された問題についても解決される予定。そして9月にはファイナルドラフトについての合意を経て、年内承認に向けて提出される見通しとのこと。

今回のバージョンアップでは、オペラ、モジラ、マイクロソフト、アップルといった主要なブラウザベンダーが仕様策定のプロジェクトに参加していますし、実装についてもこれから一斉にテストを行うとなれば、Webブラウザ間での互換性についてかなり改善されることを期待してもいいのかもしれません。

ECMAScript 5（旧ECMAScript 3.1）で何が変わるかについては、「次の JavaScript の仕様はこうなる！ ECMAScript 3.0 から 3.1 への変更点まとめ - IT戦記」で詳しく説明されています。

また、なぜECMAScript 3.1になったのかという経緯については、「JavaScript 2.0はECMAScript 3.1ベースに、ECMAScript 4は譲歩 | マイコミジャーナル」が参考になるでしょう。

HTML5、CSS3、そしてECMAScript5（JavaScript 2.0）と、今年から来年にかけてはWeb標準がまとめて進歩することになりそうですね。

本エントリはBlog on Publickeyからの転載です。