カテゴリーの階層をたどるUIを考える

バイオの買物.comでもうじき公開予定の「まとめてカタログ」に関連して、最近は分類分けやアノテーション、そしてそれを閲覧するUIが非常に気になっています。多数の製品を多数のカテゴリーに分類分けし、いかに閲覧しやすくするかという課題が結構難しいからです。

生命科学は非常に多量の情報を扱うため、その分類・整理が大きな課題になります。この試みとして代表的なのは Gene Ontology (GO) だと思います。Gene Ontologyでは各遺伝子の特徴を生物学的プロセス、細胞の構成要素、分子機能の視点から分類分けをして、整理しています。そしてDNAアレイなどの網羅的な解析結果を大局的に理解する上では、GOは必要不可欠な情報になっています。

さてこのときに課題の一つは、この分類のツリーを閲覧するユーザインタフェース(UI)です。GOではAmiGOというツールを使って閲覧できるようにしています。このツールはWindowsのExplorerのフォルダービューを模したようなデザインで以下の図のような感じになります。

AmiGO

残念ながらこのAmiGOは閲覧性という視点からすると、あまり熟慮されていないように思います。本当はAJAXなどをうまく使えばもうちょっとさくさくと動きそうなのですが、AmiGOのブラウザはノードを展開するたびに全画面を再描写していますので、遅いです。その上、ページを再描写したときにスクロール位置を復帰させる工夫がされていませんので、いちいちスクロール位置がずれてしまいます。ちょっと我慢を強いられる使用感になってしまっています。

AJAXの話を別としても、Windows Explorerのツリー型のUIが本当に適切なのかどうか、ちょっと疑問を感じてしまいます。例えば Windows XPとWindows Vistaの比較をしたこのウェブページは、ツリー構造が深くなってしまったとき、いかに訳が分からなくなるかを良く示していると思います。ツリー構造の場合は、常にルートの階層が表示されてしまい、しかも以前に開けたノードが開きっ放しになります。結果としてもう不要になってしまった情報が画面のスペースを多く取ってしまい、閲覧性を損ないます。

さてもうじき公開するバイオの買物.comの新しいサービス「まとめてカタログ」では、15万ほどの研究用製品を1500のカテゴリーに分類し、整理します。Gene Ontologyは40万弱の遺伝子を3万弱のカテゴリーに分類しているということですので、それに比べれば「まとめてカタログ」のスコープはまだ大したことはありません。しかし多数の製品とカテゴリーをうまく整理しなければならないのは同じだと思います。どういうUIにすれば良いかかなり悩みました。その結果、最終的にベストと判断したUIのスクリーンショットを以下に掲載しました。ご覧のように「まとめてカタログ」ではWindows Explorerのツリービューではなく、Mac OS XのFinderのカラム表示にインスピレーションを得ています。

まとめてカタログ

カラム表示の特徴は、過去にたどったノードが次から次へと左端に消えていくということです。そのため、どんなに階層が深くなってしまっても画面表示が見づらくなることがありません。また過去の階層に戻るのも非常に簡単で、左にスクロールするだけで済みます(ツリー表示だと上と左に同時に移動しつつ、行き過ぎてしまわないように気をつけないといけません)。この左スクロールはスクロールバーを使っても良いのですが、マルチタッチで360°にスクロールできる製品、例えばAppleのラップトップのトラックパッドやMagic Mouseなどを使うと非常に快適です。

今回はまだ「まとめてカタログ」を公開できていないので深い話はできないのですが、ちょっとだけ事前紹介として話しました。

多数の製品をカテゴリーに分類して表示するという課題は、生命科学に限らず、多くの分野でも問題になっていると思います。しかしそれをウェブブラウザーを使ってどうやったらうまく閲覧してもらえるかについては、いろいろなウェブサイトを見ても残念ながらあまり工夫が見られません。どちらかというと、閲覧性の向上はあきらめて検索機能に頼っているように感じられます。GOの功績からも分かりますように、少なくても生命科学分野では検索だけでは不十分です。この分野でいろいろなユーザインタフェースが試行されるのを期待していますし、私もやろうと思います。

バイオの買物.comの役割再考〜上田泰己さんのプロの仕事の流儀 NHK を見て

録画してあった上田泰己さんの「プロフェッショナル:仕事の流儀」を先ほど見ました。とても面白かったです。いつも場違いの「脳では〜」コメントを連発する、僕の恥ずかしい高校の先輩、茂木さんも、真の研究者の前では黙ってしまうのだなというのも面白かったのですが、それよりも何よりも、データを前に考え込み、頭の中で理論を構築している上田さんの姿が良かったです。

実際の研究現場で実験を繰り返している人にとって、データの解釈を真剣にゼロから考えるなんてまさにあこがれではないでしょうか。みんな研究者を志したのは、雑然としたデータの山の中から宝石を見つけ出し、そして生命の新しい理論を導きたい、あるいは疾患の治療法を見いだしたいからではないでしょうか。そういう意味で上田さんの志は確かにとても格好いいのですが、現場の研究者全員に共通しているものでもあると思います。

僕はもう不惑を過ぎて研究の現場から離れているのですが、どうして自分も上田さんのようになれなかったのだろうって常々考えています。どうしてデータを出して、その解釈を考え、理論を構築し、新しい実験に取りかかるという当たり前のサイクルを繰り返し、そしてわくわくいっぱいの研究生活が過ごせなかったのだろうか。もちろん上田さんのように飛び抜けた頭脳がある訳でもないし、若い頃から自分で飛び出していく勇気もありませんでした。だから彼ほどになれなかったのは当たり前です。でも真実に迫っていくという体験、研究の醍醐味を味わうことは、上田さんほどの人物じゃなくてもできたはずです。自分にはそれができなかったのはとても残念に思っています。

恐らく僕だけではなく、大学などの研究室で実験を繰り返している多くの人も、自分たちが一歩一歩真実に迫っているという実感なしに日々を過ごしているのではないでしょうか。それよりも重箱の隅を突っつくような論文を出そうとか、とりあえず実験のプラットフォームを作ろう(ノックアウトマウス作りとかタンパク質発現とか結晶作りとか)とかに心がほとんど奪われてしまっているのではないでしょうか。

ちょっと大げさではあるのですが、バイオの買物.comは、より多くの人が上田さんのような魅力的な研究生活を送れる手助けをしたいと思っています。

科学が大きく発展するためには、研究者がデータ解釈と理論構築、そして新しい実験計画に時間を割かないといけません。遺伝子を切り貼りしたり、大腸菌を振ったり、カラムにバッファーを通したり、結晶化用のバッファーを作ったりする時間はもちろん大切ではあるのですが、短くできるものならばどんどん短縮したいものです。必要な作業ではあるのですが、でもそこにかけた時間と最終的な理論のできばえは比例しないのです。それに対してデータの解釈と仮説構築、読んだ論文の数、緻密に組んだ実験計画は最終的な理論のできばえに比例します。

ビジネスなどを勉強してもそういう概念に出会います。どこで読んだかもう忘れてしまいましたが、顧客満足のために絶対に必要なコストと、満足度に影響しないコストを明確に分ける考え方があります。前者の例としては例えば製品の使い勝手の向上につながるもの、後者は上司に提出する報告者など。研究生活の中でも、全くやらなくて良いもの、どこかのメーカーから買えばすむもの、外注すればすむもの、より詳しい人にお願いできるものなどなどいろいろあるはずです。この部分がコスト削減対象です。それ以外の絶対的に必要なコストはむしろ増やさなければいけないのです。

僕がテレビに映し出された上田さんの姿を見て格好いいと思ったのはデータの解釈と仮説構築に時間をかけられているから、そしてそのために時間を惜しんでいないからでした。逆に遺伝子の切り貼りとか大腸菌を振ったりとか、そういうことばかりに時間を費やしてしまった自分の研究者生活を残念に思う訳です。

もしメーカーと研究者をうまくつなぐことができて、そして退屈な実験の時間を減らし、研究者が理論構築に費やす時間を増やすことができればどんなに素晴らしいことか。これがバイオの買物.comの原点です。

バイオの買物.comを作るためにプログラミングをしていると、ソフトウェアでは部分的にこの世界ができているのを実感します。オープンソースと呼ばれるソフトウェアは、それが全く無料であるのはもちろんのこと、中身まですべて公開されています。そしてオープンソースソフトウェアは非常に数が多く、高度に発達しているおかげで、自分の作業を大幅に軽減してくれるソフトがたいていはどこかにあります。またプログラミングしているときにちょっとわからないことがあれば、Google検索でだいたい分かります。多くのプログラマーがブログで自分のトラブルシューティング体験を公開しているからです。

仮説構築とデータ解釈、理論構築と実験計画を繰り返す醍醐味は10年の研究生活ではあまり味わえませんでしたが、数年の短いプログラミング人生の方がむしろ多く味わえています。自分の適正の問題だけではないと思います。むしろオープンソースソフトウェアとGoogleのおかげで、つまらない時間を割かなくて済んでいるからだと思います。

結論として言いたいことはこれ

上田さんはめちゃくちゃ格好いいけど、本来なら研究を志したすべての人間がああなりたいはずです。

どうやったら一人でも多くの研究者が上田さんのようになれるか、そのためにはどのようなプラットフォームが必要か、どのようなサービスが提供されなければいけないか、そしてどのような心がけを一人一人の研究者は持つべきか、それを真剣に考えなければいけません。憧れているだけじゃダメです。

そして、その答えのヒントはオープンソースソフトウェアの盛り上がりにあると僕は信じています。

Really, really simple way to use the back button on AJAX websites


Update
In the example code, I used an input type=”text” to store the state value. In order to hide this control, you should set the style to “display:none” instead of using an input type=”hidden” form control. Browser implementations are more likely to ensure that input type=”text” values are restored, and Safari 5 for example, decided that type=”hidden” values should not necessarily be preserved (Webkit Bugzilla). Using input type=”text” with style=”display:none” will work more reliably across browsers.

I was searching the web for techniques enabling the “back” button on my AJAX web site. Unfortunately, the only ones that I could find were really “hacky”. There are a couple libraries in active development like Really Simple History (RSH)YUI History by Yahoo! However, contrary to the name “Really Simple”, RSH appears to be a huge polling hack behind the scenes, running a Javascript every 0.5 seconds even if the user is doing absolutely nothing (This polling should become unnecessary with the HTML5 “window.onchangehash” event, that is currently supported in the most recent IE and FF versions, and Webkit nightlies). As far as I can tell, YUI History is doing more or less the same thing. Since you should be designing your site to be non-reliant on the forward and back buttons anyway, it is hard to justify intrusive polling in return for this hopefully rare functionality. The idea made me very uncomfortable.

On the other hand, if the “back” and “forward” buttons do not work as expected, you are surely going to make more than a few users quite infuriated. The typical AJAX application behavior when you push the “back” button is to completely erase everything that the user did, and send them to the fresh page as it was when they first visited it. Essentially, you are sending the users back to the entrance door. Sounds like you won’t be seeing them again any time soon.

Luckily, I managed to come up with a solution that works with browsers as erratic as IE6, does not require loading a library, and should only require a small amount of additional code. Although it only solves a small part of the browser history and “back” button problem, I think it solve the most irritating issues quite sufficiently, such that the user won’t feel one bit the urge to slam shut his laptop and pour himself a strong cup of coffee.

What is the “Back” button problem?

I probably don’t have to teach this to people who have done a fair amount of AJAX programming, but I will discuss it to clarify what my solution does and doesn’t solve.

AJAX is a technique that enables the browser to update only a part of a page, and is very useful for improving the perceived responsiveness of your web site. However, AJAX updates generally do not rewrite the location in the browser location bar. Since it is this location value that the browsers use to maintain their histories and to enable the back and forward buttons, AJAX renders these buttons useless. These buttons will typically send you to the first state that you saw when you first visited the web page, before any of the AJAX updates took place. In effect, all the work that you did since you visited the page will be lost (unless of course, the AJAX updates themselves rewrote the information on the server).

For example, imagine that you are visiting a web catalog site that lists electronic products, and uses AJAX to make browsing the product categories nice and quick. Imagine that the the user decided to do a text search after reaching a category deep in the hierarchy (“mac” in the illustration below). Also let’s assume that this product search fires a regular HTTP request (non-AJAX). Now after viewing the results, what would the user do if he decides to take another look at the “mac” category? Instinctively, he would push the “back” button on his browser, sending him unwittingly to the root category of the product catalog. You can almost see the cold sweat on his face as he realizes that he might have lost any way to get back to the “mac” category, save for going through the whole product hierarchy again. Pushing the “forward” button wouldn’t help either, since he would be taken straight to the search results page, right where his woes began.

Ajax javascript back button.jpg

We can easily see why the AJAX “back” button issue can cause such anger and frustration. Despite all your AJAX efforts to make navigation and data entry nice and quick, the “back” button issue will strip you of all the goodwill that was earned. Most likely, the users will even leave with a worse feeling than before they first visited.

The normal solution

Although there are many posts on the web and several libraries to solve the “back” button problem, all of the solutions that I could find on Google were basically variations of the methods used in RSH and YUI History. Namely, to use the hash (“#”) at the end of the location to store the state information in the browser’s history.

With AJAX, the URL can not be changed since this would fire a reload of the whole page. However, the portion after the hash (“#”) is handled differently. Changing this portion (with the Javascript “document.location.hash” property) will not fire a reload, but will cause the whole location to be stored in the browser’s history (at least for non-IE browsers). Therefore, if you store the current AJAX state in the hash portion, you would be able to resolve the “back” button issue. At least in theory.

However, since this is not the intended usage of the hash, browsers deviate in how this is handled. Changing the location does not trigger IE browsers to store the changed location in the browser’s history, and early versions of Safari did not provide a way to read the hash portion after it was changed. To support IE, both RSH and YUI store browser history in an iframe and send an otherwise unnecessary request to the server, an unfortunate hack. An even more troublesome hack is that RSH and YUI use polling to read the hash portion, even with the more recent browsers. Polling is the action of executing a method in regular intervals, even when the user is not interacting with the browser. With RSH, the polling frequency is an alarming 0.5 seconds. This can cause the whole computer to slow down and will cause laptops to consume more battery charge. Polling is generally a despised hack that most programmers try hard to avoid. (As mentioned above, HTML5 provides the window.onhashchange event so that you don’t have to rely on polling, but this is only supported on the most recent of browsers.)

Going through all these loops and potentially causing a slow down on the user’s computer sounds simply too much to solve the “back” button problem. HTML5 will hopefully make things much easier, but as things stand today, I think we need a different solution.

A solution using form elements

The issue with the “back” button boils down to how we can store AJAX state information. As described above, I think that using the hash (“#”) in the location is much too troublesome. In the method below, I used regular form elements.

Form elements do preserve their contents between “back” button clicks. Remember when you were editing a form on a web site, and you realized that you had made a mistake after hitting the submit button. If you go back to the data entry page by clicking the “back” button, you will see all the form elements containing the same information they had just before you submitted it. Most browsers (even the older ones), automatically restore this information, even if they are different from the default values in the HTML. In my method, I use this feature to store the AJAX state. (better description here)

Browsers store this information inside their caches. If this solution doesn’t work on your web app, try adding the HTTP header “Cache-control: private” in your response, which should tell browsers that they can cache content locally.

I’m not sure if the above behavior is dictated by a standard, or is just how the browsers have opted to behave. I do think that this feature is central to the end-users’ browsing experience, and this is probably why this solution seems to work on all browsers without any hacking.

With the form solution, we do not create a history entry, and as a result, we can only solve a small portion of what RSH and YUI History provides. This small part however, is in my opinion, the most frequent source of end-user headaches, and is by far the most important problem. Being able to solve this with a simple solution should really help.

The Code

The code below is all that I need to run a demo and illustrate the method. I am using Prototype.js to manipulate the DOM, but it should be possible to write it just as easily with raw JavaScript (I’m just too lazy to do it). I also have a demo site to make it easier to follow my explanations.

 1  <html>
 2  <head>
 3    <script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/prototype/1.6.1/prototype.js"></script>
 4    <script>
 5      function setColor() {
 6        $('field').setStyle('background-color:' + $F('field'));
 7      }
 8    </script>
 9  </head>  
 10 <body>
 11   <form>
 12     <input type="text" id="field" value="red"/>
 13   </form>
 14   <a href="Javascript:void()" onclick="$('field').setValue('blue');setColor();">blue</a>
 15   <a href="http://google.com">go to Google</a>
 16   <script>
 17     setTimeout("setColor();", 0);
 18   </script>
 19 </body>
 20 </html>

This demo works as follows.

  1. When you click the link “blue”, the content of the text field and its background color are changed to blue.
  2. Then go to another web site by clicking on the “go to Google” link that I provided.
  3. When you return to the demo web page by clicking the “back” button, the text field will contain the word “blue” and the background-color will also be blue. Just the way it was before going to Google. Compare this to another demo page with the 17th line commented out.

A description of the source follows.

  1. Lines 11-13 are a form to preserve the state (the state form). When the “back” button on the browser is pressed, the state values are restored from the browser cache.
  2. Line 14 is the link “blue”. When this is clicked, the value of “blue” is written to the state form with “$(‘field’).setValue(‘blue’)”. The next “setColor();” command changes the background color to synchronize with the value in the state form.
  3. Lines 17 is executed when the page is first loaded, and after the page is redrawn after coming back with the “back” button. The “setColor();” command will ensure that the background color is synchronized with the value in the state form. Safari and FF work fine without the setTimeout wrapper, but I found that it is necessary to get it working on IE when you come back with the “back” button.
  4. I have checked that this demo works on FireFox3.6, Safari 4 and IE6-8.

In this simple example, I only changed the background color. With an AJAX web app, you would save the AJAX request parameters in the state form, either before or after you made the AJAX request. You would also provide a command that sends the AJAX request after coming back with the “back” button, so that the DOM state will be synchronized with the state form values, which have been automatically restored from the browser hash.

What you can and what you cannot do with this method.

With this method, you can use the “back” button to return to your prior state after being sent to a new URL. You will be returned to the very last state. You cannot return to any intermediate AJAX state.

Ajax javascript back button 2.jpg

Of course, this is not a 100% solution covering bookmarking and stuff. I do believe that it does however cover more than 80% of the end-user needs. With a regular AJAX page, the end-user will lose all of their efforts; every click and every form entry. You are essentially showing the end-user the exit, and telling him that he doesn’t have to bother coming back. With the method that I described, the end-user will be sent back to his final state and he can simply modify things without going through the same procedure from the start. The equivalent of politely asking “Pardon. Could you please repeat that final request, Sir?”.

AJAXで書き換えたウェブページでバックボタンを使う


アップデート
下記のコード例では状態を保存するために input type=”text” を使いました。この値を表示したくない場合は、input type=”hidden” を使わずに style=”display:none” とした方が良いようです。ブラウザによっては(例えばSafariの5以降) type=”hidden”の値が保存されるとは限りません(Webkit Bugzilla)。input type=”text”とstyle=”display:none”の組み合わせに方が、異なるブラウザ間で確実に動作してくれそうです。

AJAXをたくさん使ったページでバックボタンを使えるようにしたいと思って、ウェブでいろいろ探しました。見つかったのは例えば Really Simple History (RSH)YUI Historyなどで、以下に述べるようにかなり怖いぐらいのハックをしているものでした。とても手軽に使う気にはなれません。(どれも結構歴史のあるものですが、最新バージョンでも同じハックを使い続けていると思います)

とは言うものの、バックボタンやフォワードボタンがうまく使えないと、ウェブサイトの利用者を非常に不満を与えてしまうことがあります。なんとか解決策は無いかと考えていたところ、非常にコードが少なく、なおかつ古いブラウザでもそのまま使える簡易的な方法が見つかりましたので以下に紹介します。

バックボタンの問題とは?

AJAXをたくさん使ってプログラミングしている人には紹介するまでもないのですが、今回の解決策の範囲を示すためにバックボタンの問題を簡単に紹介します。

AJAXはページ全体を再描写しないで済むので、レスポンス間の良いウェブサイトを作るのに非常に適しています。しかしAJAXでページを細かく書き換えても、ブラウザが指しているURL(ロケーションバーのURL)を全く書き換えられません。バックボタンはロケーションバーのURLに連動して動作しますので、結果として思い通りの動作をしてくれません。

例えば製品カタログのウェブサイトを作っているとします。カタログの中を調べていくとき、AJAXで画面を再描写するようにしてレスポンスを向上させていたとします。そしてある程度深い階層(ここでは「マック」)にユーザが入ったところで、検索を行ったとします。この検索はAJAXではなく、普通のHTTPでページを切り替えたとします。さて問題となるのは、検索を行ったユーザがバックボタンを押したときです。ユーザとしては「マック」の階層に戻ることを期待しています。しかしAJAXを使った場合はURLは最初のページのままなので、実際には「製品カタログ」のトップページに戻ってしまいます。ユーザが苦労してやっと「マック」のカテゴリーにたどり着いたのに、もう一度最初からやり直さなければならないのです。フォワードボタンを押そうが何をしようが無駄です。今までの作業は永遠に消えてしまうのです。

AJAX_back_button.jpg

このようにAJAXのバックボタン問題は、ユーザに大きな不快感を与えます。せっかくAJAXで使いやすいサイトに作ったとしても、バックボタン問題でそのすべてが吹っ飛んでしまいます。逆にネガティブになるリスクも高いと思います。

一般的な解決策

グーグルで調べた限り、ブラウザのロケーションのハッシュ部分にステートを保存する解決策やライブラリーが多く作られているようです。上述のRSHやYUI Historyと同じやり方です。

AJAXでは基本的にはURLは変わらない(変えられない)のですが、URLの”#”の後ろの部分(ハッシュ)だけは違います。この部分はブラウザの履歴に保存されますので、バックボタンを押したときにも残っています。そこでAJAXページの最後の状態(ステート)をハッシュ部分に保存すれば、原理的にはバックボタン問題を解決できます。

しかしロケーションのハッシュ部分にステートを保存するというのはかなり特殊な使い方で、ブラウザによってはよっぽど変わったことをやらないとうまく動作しないようです。例えばRSHとYUIのライブラリーではIEをサポートするために新たにiframeを作成し、本来必要の無いリクエストをサーバに送っているようです。YUIは古いSafariのバージョンではもっと訳の分からないことをやっています。またSafari 3 4やFireFoxなどの最新のブラウザでもpollingという禁断の技法を使っています。Pollingというのは例えば0.5秒おきにプログラムがロケーションを確認するというもので、ユーザがブラウザを全く触っていないときでも動作させるやり方です。パソコンの動作を無駄に遅くさせ、電池を消耗させることから、非常に嫌われている方法です。

バックボタンという比較的シンプルな機能を実現するためにこんなに無理をし、ユーザのパソコン全体の動作を重くさせていいのでしょうか。僕は絶対にこれはやりたくないので、この方法は使えません。ただHTML5ではdocumentwindow.onhashchangeというハンドルが加わり、将来的にはpollingは不要になりそうです。またブラウザの履歴をより直接的に操作できるようにもなるらしいですので、そのときはもうちょっとマシな方法が一般的になっていくでしょう。でも今はとにかくダメなので、別の方法を探りました。

フォームを使った解決策

バックボタンの問題を解決するためには、ブラウザのステートを保存しなければなりません。それを上述のようにロケーションバーに保存するのは現時点では無理があります。ここで紹介する方法ではフォームの中に保存しています。

例えばブラウザでフォームを編集して、それを送信した後、間違いに気づいたとします。通常バックボタンを押せば、送信する直前の状態、つまり各フィールドに情報を入力した状態に戻ります。このように、大部分のブラウザではフォームの内容を保持していて、バックボタンを押したときにそれが復活するようになっているのです。今回はこれを利用します。

フォームの内容を保持することは、ブラウザを使っているすべての利用者の利便性に直接関わります。ですから古いブラウザでも新しいブラウザでも同じ動作をしてくれますし、パソコン全体の動作を重くしてしまう心配もありません。その代わり、RSHやYUIと比べると実現できる機能はごく一部になってしまいます。しかしフォームを使って実現できるわずかな機能が、最も重要な機能だと思います。具体的には以下に紹介していきます。

コード

以下に示したのが、今回の方法を説明するのに必要なコードのすべてです。DOMを操るためにPrototype.jsを使っていますが、非常に簡単なことしかしていませんのでJQueryや生のJavaScriptしか使っていない人でも分かりやすいと思います。このコードを載せたデモサイトも用意しました。

 1  <html>
 2  <head>
 3    <script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/prototype/1.6.1/prototype.js"></script>
 4    <script>
 5      function setColor() {
 6        $('field').setStyle('background-color:' + $F('field'));
 7      }
 8    </script>
 9  </head>  
 10 <body>
 11   <form>
 12     <input type="text" id="field" value="red"/>
 13   </form>
 14   <a href="Javascript:void()" onclick="$('field').setValue('blue');setColor();">blue</a>
 15   <a href="http://google.com">go to Google</a>
 16   <script>
 17     setTimeout("setColor();", 0);
 18   </script>
 19 </body>
 20 </html>

このデモの動作は以下のようになります。

  1. “blue”のリンクをクリックすると、Javascriptを使ってテキストフィールとのバックグラウンドカラー(background-color)を変えます。
  2. そのあと”go to Google”のリンクをクリックして、google.comのページに移動します。
  3. ブラウザのバックボタンを押してこのデモのページに戻ったとき、テキストフィールドは最後の”blue”のままです。何もしていない普通のページであれば、テキストフィールドのバックグラウンドカラーは”blue”のリンクをクリックする前の色であったはずです。17行目をコメントアウトしたデモサイトも用意しましたので、動作を見比べてください。

プログラムを解説します。

  1. 11-13行目はステートを保持するためのフォームです。ブラウザのバックボタンを押すとこのフォームの内容は直前の状態になります。
  2. 14行目が”blue”のリンクです。これをクリックすると”$(‘field’).setValue(‘blue’)”でステート保持フォームに”blue”が書き込まれます。次に”setColor();”を呼んで、ステート保持フォームの内容がバックグラウンドカラーに反映されるようにしています。
  3. 16-17行目はページが最初に読み込まれたり、バックボタンで再表示されたときに実行されるJavascriptです。”setColor();”を読んで、ステート保持フォームの内容がバックグラウンドカラーに反映されるようにしています。なおSafariやFFではsetTimeoutで囲まなくてもうまく動作してくれたのですが、IEの場合はsetTimeoutで囲まないと、バックボタンを押したときに動作してくれませんでした。
  4. 動作確認はFireFox3.6, Safari 3 4, IE6-8で行いました。確認した限り、どれも同じように動作しました。

今回はバックグラウンドカラーを変えるという簡単なデモでしたが、AJAXを使ったウェブページであればAJAXのパラメータをステート保持フォームに保存することになるでしょう(AJAX呼び出し直前もしくは直後にJavascriptでこのフォームにパラメータを保存します)。バックボタンを押してこのページが再読み込みされたときは、まずステート保持フォームが空かどうかを確認し、空でなければそのパラメータでAJAX呼び出し行います。空であればAJAX呼び出しを行いません。

この方法でできること、できないこと

この方法でできるのは、新しいURLに移動した後、バックボタン(もしくはフォワードボタン)で戻る動作です。そしてAJAXを使ったページの一番最後の状態に戻ります。AJAXページの途中の状態に戻ることはできません。フォワードボタンでも同様です。

Ajax javascript back button 2.jpg

もちろんこれで100%十分という訳ではないのですが、恐らく80%近くは行けてると思います。単なるAJAXのページではバックボタンで今までの作業がすべて白紙に戻されるため、非常に頭にきます。しかし今回の方法を使えば、最後の状態に戻せます。逆に言うと、最後の状態にしか戻せません。新たな利便性を提供できないのは残念ですけど、少なくとも作業は失わないで済むのです。これは非常に大きな違いだと思います。

オープンであることの意味 : “The Meaning of Open”の和訳

2009年末、”The Official Google Blog”に掲載された Jonathan Rosenberg, Senior Vice President, Product Managementの記事、“The meaning of open”を和訳しましたので、以下に紹介いたします。

この内容に賛同するかしないかは別として(私も部分的には賛同していません)、非常に示唆に富んだ文章であることは間違いないと思います。

もし何かに利用したいということであれば、引用、転載、修正は全く自由ですので、よろしくお使い下さい。

なお、この翻訳はGoogle翻訳者ツールキット (http://translate.google.com/toolkit)を使って行いました。

—– 以下翻訳 —-

オープンであることの意味

2009年12月21日3時17分00秒午後

インターネット、グーグル社、そして我々の利用者にとって「オープン」であること意味について、先週、社内にメールを送りました。オープンの精神に則り、グーグル社外にもこの考えを共有したいと思いました。

グーグル社では、オープンシステムが勝つと信じています。オープンシステムはより多くのイノベーションを生み、価値を創造し、消費者の選択の自由を拡大します。そしてより活発でより収益性があり、より競争が行われるビジネス環境を作り出します。他の多くの会社も似たようなことを言っています。自社もオープンだと宣言することがブランドの向上に貢献し、同時にリスクがないことを知っているからです。そもそも我々の業界にはオープンであることの意味が明確に定義されていません。これはいってみれば「羅生門」的な言葉です。非常に主観的でありながら、極めて重要なのです。

グーグル社内でオープンが話題になることが最近多くなっているようです。製品の議論をしているミーティングに参加しているときなどにも、我々はもっとオープンであるべきだという意見が出ます。しかしそのあと議論を続けていると、会議室のほとんどの人はオープンが良いと信じてはいるものの、具体的にそれが何を意味しているかについては必ずしも意見を共有していないことが分かります。

このような議論はかなり頻繁になってきています。そこでそろそろ全員が理解し、支持できるような形でオープンを明確に定義しなければいけないと私は思います。以下に紹介するのは私自身の経験と数人の同僚の意見を元に作成した、そのような定義です。私たちが会社を運営し、製品の判断を行う際は、ここに紹介する原則に従っています。ですからこの文章を注意深く読み、振り返り、そして議論してほしいと思います。そしてこの定義を自分のものとし、自分の仕事に活かしてください。これは複雑なトピックなので必ず議論があるはずです。議論はオープンで行ってください!自由にコメントをしてください。

我々のオープンの定義は2つの要素からなっています。それはオープンな技術とオープンな情報です。オープンな技術というのはオープンソースソフトウェアとオープンスタンダードを含みます。オープンソースを含むという意味は、我々はインターネットを成長させるソフトウェアを公開し、積極的にサポートしますということです。オープンスタンダードを含むという意味は、我々は公認のスタンダードに従い、スタンダードがない場合は(グーグル社だけでなく)インターネット全体の利益となるようなスタンダードを作り出すということです。オープンな情報というのは、我々がユーザに関する情報を持っているときは、これを利用者に有用な価値を創造するために使用し、どのような個人情報を持っているかについて透明性を持たせ、かつその情報をコントロールする権限を利用者に全面的に与えるということです。我々がやらなければならないのはこの2つのことです。多くの場合、我々はまだこれが達成できていません。しかしこのメールを出発点に、現実と理想のギャップを埋め始められることを期待しています。

我々がオープンを一貫して実践できれば(そしてできると信じています)、我々は行動を通して模範を示すことになります。そして他の会社や産業が同じくオープンを実践することを奨励できるでしょう。他の会社や産業もオープンになれば、世の中はより良くなります。

オープンシステムは勝利します
我々の立場をより詳細に説明するために、オープンシステムが勝利するということをまず強調したいと思います。伝統的な訓練を受けたMBAは、クローズドなシステムを作り、それを普及させることによって持続可能な競争的優位を築き、そしてプロダクトライフサイクルに沿って利益を搾り取ることを教育されています。したがって彼らにとっては、オープンシステムが勝利するというのは直感に反します。伝統的な考え方では、会社は顧客を囲い込むことによって競合他社を閉め出すべきです。戦術的にはいくつかの異なるアプローチがあります。カミソリの会社はカミソリのホルダーを安く売り、刃は高く売ります。昔のIBMはメインフレームを高くし、ソフトウェアも…高くしていました。いずれにしても正しく運営されたクローズドシステムは多くの利益をもたらします。また短期的には良くデザインされた製品を生み出しますが(誰でも分かる例としてはiPodとiPhone)、クローズドシステムにおけるイノベーションはいずれ小さな前進しか生まなくなります(4つ刃のあるカミソリは3つ刃のカミソリよりそんなに良くなっていますか?)。なぜなら現状を維持することが目的だからです。クローズドシステムは常に慢心を生みます。顧客の維持が楽にできるようになってしまえば、楽をしてしまうのです。

オープンシステムはこの逆です。競争が激しく、もっと変化が早いです。オープンシステムでの競合優位は顧客の囲い込みから生まれるのではありません。変化の激しいシステムを誰よりもよく理解し、より良い、よりイノベーティブな製品をつくることによって競合優位が生まれるのです。オープンシステムで成功する会社はイノベーションが早く、同時に思想面でもリーダーです。これは簡単なことではありません。とても大変なことです。しかし行動の素早い会社は何も恐れることはありません。そして成功すれば、大きな株主価値を生むことができます。

オープンシステムは新しい産業を生み出すことができます。オープンシステムでは一般大衆の知性がときはな、各会社はビジネス戦術だけでなく製品の優劣に基づいて競争し、イノベーションし、勝敗を付けるようにしむけられます。ヒトゲノムの解読はその一例です。

Wikinomicsという本でDon TapscottとAnthony Williamsは1990年代の半ばに私企業がDNA配列データをたくさん発見しては特許出願し、その情報を誰がいくら払ってアクセスできるかをコントロールしていたことを紹介しています。ゲノム情報を私企業が所有することによってコストがかさみ、創薬の効率が落ちました。そして1995年にはメルク社とワシントン大学のゲノムシーケンスセンターはMerck Gene Indexというオープンなイニシアティブを作り、ゲームのルールそのものを変えました。わずか3年間で800,000の遺伝子がパブリックドメインに公開され、まもなく同様な行動的なイニシアティブが生まれました。この業界では初期のR&Dはクローズドな研究室で行うのが伝統的であり、メルク社のオープンなアプローチは業界全体のカルチャーを変えただけでなく、医薬開発のスピードを速めました。この成果により世界のどこの研究者であっても、オープンな遺伝情報に制限なくアクセスできるようになりました。

またオープンシステムはすべてのレベル(OSレベルからアプリケーションレベルまで)でのイノベーションを可能にします。それに対してクローズドシステムでは一番上のレベルでしかイノベーションできません。ですからある会社が製品を出荷する際、もう一つ別の会社の善意に頼る必要がないのです。例えば私が使用しているGNU Cコンパイラにバグがあれば、オープンソースなので自分で修正することができます。バグレポートを送って、修正がタイムリーに行われることを祈らなくていいのです。

したがって、可能な限り産業を大きくしたいのであれば、オープンシステムはクローズドシステムに勝ります。我々がインターネットでやろうとしているのはまさにこれです。我々がオープンシステムにコミットするのは、利他主義だからではないのです。ビジネス上、オープンシステムの方が賢明だからです。オープンなインターネットは安定してイノベーションを生み出し、ユーザの増大とユーザの活発な利用を促し、産業全体を成長させるからです。Hal Varianの"Information Rules"という著書には、これに当てはまる数式があります:

報酬 = (市場に提供されるすべての付加価値) * (我社の付加価値のシェア)

他の条件を同一と見なしたとき、10%のシェア増大と10%の市場全体の拡大は同じ結果を生みます。しかし我々の市場では市場全体の10%の拡大の方がより多くの報酬を生みます。なぜなら産業全体にスケールメリットをもたらし、生産性を向上させ、すべての競争相手のコストを下げるからです。我々が安定してすばらしい製品を提供し続ける限り、我々は市場全体とともに繁栄します。シェアは小さくなるかもしれませんが、パイは大きくなるのです。

別の言い方をすれば、グーグル社の将来はインターネットがオープンであり続けることに依存しています。そして我々がオープンを推し進めることよって、グーグル社を含めたすべての人が恩恵を受ける形でウェブが拡大するでしょう。

オープンな技術
オープンの定義をするためには、インターネットの土台となった技術:オープンスタンダードとオープンソースソフトウェアの話から始めなければいけません。

オープンスタンダード
ネットワークが繁栄するためにはいつの時代もスタンダードが必要でした。19世紀の初めにアメリカに鉄道網が敷かれ始めたとき、線路幅の規格は異なるものが7つありました。当初はネットワークが繁栄することはありませんでした。それぞれ異なる鉄道会社が標準幅の4フィート8.5インチに同意して始めて、鉄道網が繁栄し西に拡大することができたのです。(この場合、規格戦争は本物の戦争でした:アメリカ内戦で南部連合国が合衆国に負けると、南部の鉄道会社は11,000マイルの鉄道を強制的に変更させられたのです)

1974年にVint Cerfと同僚らがアメリカ合衆国のいくつかのコンピュータネットワークを接続する際、(後にTCP/IPとなった)オープンスタンダードの使用を提案しましたが、これはこのような前例のあることでした。どれだけの数のネットワークが存在するかははっきり分からなかったので、"Internet"(これはVintが名付けたのもだが)はオープンでなければなりませんでした。どんなネットワークであってもTCP/IPを使って接続することができました。そしてその時の判断の結果、現在ではインターネット上に6億8100万ほどのホストが存在しています。

利用者の選択の自由を確保する上では相互互換性が必須ですので、開発社向け製品については我々はオープンスタンダードで作ります。したがって、グーグル社のプロダクトマネージャーと技術者は可能な限りオープンスタンダードを使用するべきです。オープンスタンダードがまだ無い分野に挑戦しているときは、オープンスタンダードを作りなさい。オープンスタンダードがまだ十分でない場合は、それを改善し、改善点をなるべくシンプルにし、ドキュメンテーションも可能な限り充実させなさい。我々のグーグル社だけでなく、利用者および産業全体を常に優先させるべきです。あなたたちはスタンダード策定団体と協力し、我々が行った改善点が公認スタンダードの一部となるように努力するべきです。

我々は以前からこれを実践しています。Google Data Protocol(XML/Atomに基づく我々の標準APIプロトコール)を作っていたころ、我々はIETF Atom Protocol Working Groupと協力し、Atomの仕様策定を共に行いました。また最近ではW3Cと協力して、ブラウザ上で位置情報を利用したアプリケーションが簡単に作れるように、標準の位置情報APIを作成しました。このスタンダードは我々だけでなく、すべての人の役に立ちます。そしてとても面白いアプリケーションが何千もの開発者によって作られ、利用者の手にわたることでしょう。

オープンソース
先に述べたアプリケーションの大部分はオープンソースソフトウェアで作られるでしょう。オープンソースソフトウェアはここ15年間のウェブの爆発的な成長の原動力です。ここにも前例はあります。「オープンソース」という言葉が生まれたのは1990年代の終わりですが、産業を活性化するために重要な情報を共有しようという発想はインターネットのずっと前から存在していました。1900年代の初め頃、アメリカ合衆国の自動車産業は特許のクロスライセンス協定を結び、メーカー間で特許がオープンにかつ自由に共有されました。この協定以前は、ツーサイクルガソリンエンジンの特許の保持者たちが産業全体を事実上閉じ込めてしまっていました。

今日のオープンソースは昔の自動車メーカーの「パテントプール」よりも大幅に発展し、グーグル社を支えているLinux, Apache, SSHなどの高度なソフトウェアコンポーネントの開発につながりました。実際、我々の製品を運用する上で、何千万行ものオープンソースコードが使用されています。また我々はオープンソースにこの恩を返しています。我々は世界最大のオープンソースソフトウェア提供者です。合計2000万行のコードに達する、800以上のプロジェクトを提供しています。Chrome, Android, Chrome OSとGoogle Web Toolkitの4つはそれぞれ100万行以上のコードです。またMozillaとApacheをサポートするチームもありますし、250,000以上のプロジェクトをホスティングしているプロジェクトホスティングサービスも提供しています(code.google.com/hosting)。これらの活動によって社外の人間が我々のプロジェクトに協力し、我々がより良い製品を提供できるだけではありません。もし我々が十分にイノベーションできなければ、社外の人間が我々のソフトウェアを土台に自らの製品を作ることもできるのです。

我々がコードをオープンソースするときはApache 2.0ライセンスを使用します。つまり我々はそのコードをコントロールしないということです。他人がそのオープンソースコードを入手し、修正し、閉じ込め、自分のものかのように出荷することもできます。Androidはこの典型例です。複数のOEMはこのコードを入手し、すばらしいものを作り上げています。このアプローチにはリスクもあります。ソフトがお互いに互換性の無い、複数の系統に分かれることがあるからです(ワークステーション用のUnixがApollo, Sun, HPなどに分岐したのを思い出してください)。Androidではこうならないように努力しています。

開発者用のツールをオープンソース化することには努力を惜しみませんが、すべてのグーグル製品がオープンソースだという訳ではありません。我々の目標はインターネットをオープンにしておくことです。これによって選択の自由と競争を奨励し、利用者や開発者が囲い込まれてしまうのを防ぎます。多くの場合、特に検索や広告関連製品などでは、オープンソース化はこの目標の実現に役立ちませんし、むしろ利用者に害をもたらします。検索と広告関連市場は既に競争が激しく、利用者も広告主も選択の幅が広いですし、囲い込まれてもいません。これらのシステムを公開してしまえば、アルゴリズムをだまし、検索結果や広告品質ランキングを人為的に操作することが可能になり、すべての人にとっての品質を低下させてしまうのは言うまでもありません。

ですからあなたたちが製品を作ったり新しい機能を付け足しているとき、いったん立ち止まって考えてみてください。「このコードをオープンソース化することによって、インターネットはよりオープンになるでしょうか。利用者、広告主および協力者の選択の自由を拡大してくれるでしょうか。競争やイノベーションの拡大に貢献するでしょうか。」そうであればオープンソース化するべきです。そしてオープンソース化するときはちゃんとやってください。単にそれを公にして、忘れてしまうということはしないでください。コードを管理して、他の開発者を取り込めるだけのリソースがあることも確認してください。我々がオープンに開発して、公開されたバグトラッカーとソース管理システムを使用したGoogle Web Toolkitはこの好例です。

オープンな情報
オープンスタンダードとオープンソースの基盤によって、今日のウェブ上には膨大な量の個人情報があふれています。写真、連絡先、近況アップデートなどが頻繁にアップロードされています。情報量が膨大であることおよびそれが永久に保存されうることによって、今まで考える必要も無かった課題が生じました。すなわち、この情報をどう扱えばいいのかということです。

歴史的に、新しい情報技術は新しい商売の形を可能にしてきました。地中海の商人が紀元前3千年頃に印鑑(bullae)を発明し、出荷した製品が途中で開けられることなく目的地まで届けられるように保証しました。この結果、商売はローカルなものから遠距離なものに変わりました。同様の革新は書き言葉の到来や最近ではコンピュータによってもたらされました。約束の遵守を保証する新しいタイプの情報野のおかげで、商取引のすべてのステップにおいて、トランザクション、すなわち関係各団体が何らかの価値を得る双方同意が促進されたのです。

ウェブ上では新しい商売の形というのは、何らかの価値と引き換えに個人情報を提供することです。この取引には毎日何百万人もの人が参加しています。そして潜在的には非常に大きなメリットがあります。数年前にはなかったGPS追跡技術から得られる情報により、自動車保険業者は顧客の運転技術をリアルタイムで確認し、安全運転に対しては割引(そしてスピードの出し過ぎには超過料金)を与えることができるかもしれません。これは比較的簡単な取引です。以下ではもっと注意を要するシナリオも考えます。

例えばあなたの子供がいくつかの薬に対してアレルギーがあるとします。コンピュータが埋め込まれた注射器がその子のカルテを自動的に読み取り、看護婦が誤って薬を投与してしまわないようなシステムをあなたは承認しますか。私なら承認しますが、手首に金属のブレスレットをつけるだけで十分とあなたは考えるかもしれません。それでいいのです。人はそれぞれ異なる判断をしますし、個人情報について言えば、我々はそれぞれの判断を同様に尊重しなければいけません。

より多くの個人情報をオンライン化するのはすべての人にとって有用ではあると思います。しかしその情報の利用に際しては、産業の変化とともに成長でき、責任ある、スケールアップできるような柔軟性をもった原則にしたがって、これを行わなければなりません。オープンな技術についての我々の目的はインターネットの生態系を拡大することでしたが、オープンな情報へのアプローチはこれと異なり、インターネット生態系と関わる個人(利用者、パートナーと顧客)との信頼関係を築くことが目的です。オンラインで最も重要な通貨は信頼であり、これを築くためにはオープンな情報の三原則に沿わないといけません。すなわち、価値と透明性とコントロールです。

価値
まず第一に、我々は利用者にとって価値のある製品を作る必要があります。多くの場合、利用者についての情報があればあるほど良い製品が作れます。しかし利用者が提供する情報の対価として、我々がどのような価値を提供するのかを理解してもらわないと、プライバシーの問題が生じます。そのような場合、その価値を説明してあげれば彼らは情報提供に同意してくれるでしょう。例えば、どのようなものを購入したかの履歴を何百万もの人がクレジットカード会社に提供していますが、これは現金を持ち歩く煩わしさから解放されるという利便性の対価として同意されたものです。

我々が3月に関心ベースの広告(IBA)を提供開始したとき、これはうまく出来ました。IBA広告によって、広告はより的確で有用なものになります。これは我々が収集する情報によって創造される付加価値です。また利用者のための設定管理ツールも含まれていまして、設定ツールの中では利用者にどのような価値が提供されるかが説明されています。また設定を変更したり利用を中止したりすることもできます。設定管理ツールを利用した大部分の人は、利用を中止せず、設定を変更しました。彼らは自分の興味に合わせてカスタマイズされた広告を受け取ることの価値を理解してくれたからです。

これが私たちのデフォルトのアプローチであるべきです:我々は利用者に対して、どのような情報を知り得たか、そして我々がそれを知っていることがどうして利用者にとっても有用かを、分かりやすい簡潔な言葉で説明しなければいけません。わざわざ利用者に説明するまでもなく、自分が作り上げた製品の価値は自明であるとお考えですか。それは多分間違っています。

透明性
次にすべての製品について、我々がどのような情報を収集し保存しているかを、利用者が簡単に調べられるようにしなければなりません。我々は最近、Googleダッシュボードでこれに向けて大きな前進をしました。Googleダッシュボードは、各Google製品(Gmail, YouTubeとSearchを含めた20以上の製品)にどのような個人情報が保管されているかを一カ所に集め、個人設定を変更できるものです。我々が知る限り、このようなサービスを提供しているインターネット企業は我々だけです。これが標準になることを期待しています。もう一つの良い例は当社のプライバシーポリシーです。弁護士だけでなく、一般の人間にも分かるように書いています。

これにとどまること無く、もっと透明性を高めるよう努力するべきです。あなたが個人向けの製品を管理していて、利用者の情報を集めているのであれば、その製品をGoogleダッシュボードに含めるべきです。すでにダッシュボードに掲載していたとしても、それで満足してはいけません。新しい機能を追加するたびに、バージョンを更新するたびに、ダッシュボードに追加できるような新しい情報(他のサイトに公開されている個人情報を含めて)があるかどうかを自分に問い直してください。

自分の製品の中での透明性を高められないかも考えてみてください。例えばAndroidのアプリケーションをダウンロードしたとします。そのアプリケーションがどのような個人情報もしくは携帯電話の情報にアクセスできるかをAndroidは教えてくれます。その情報を元にインストールを続けるか、中断するかを判断できます。あなたのどのような情報が暴露されるかを調べるのに探しまわる必要はありません。Androidはまず利用者にそのことを知らせ、判断を仰ぎます。あなたの製品もそうしていますか。どうやれば、透明性を高め、利用者をより魅了することができますか。

コントロール
最後に、私たちは常に利用者にコントロール権限を与えなければなりません。IBAの場合のように我々が利用者の情報を持っているのであれば、利用者自身がその情報を削除し、利用を中止することが簡単にできなければいけません。利用者が我々の製品を使い、我々のサーバにコンテンツを保管してくれている場合、それは利用者のコンテンツであって、我々のものではありません。利用者はいつ何時でもそのコンテンツをエキスポートしたり削除したりできなければいけません。それも無料で、なるべく簡単にです。Gmailは非常に良い例です。我々はどんなEmailアドレスへの転送も無料で提供しています。ブランドスイッチできるというのは必須の機能です。自分たちの製品の周りに壁を作るのではなく、橋を作りなさい。利用者には、真に意味のある選択肢を提供しなさい。

利用者のデータを取り扱うための既存のスタンダードがあれば、それに従いなさい。スタンダードが存在しない場合は、ウェブ全体の利益となるようなオープンスタンダードを作るように努めなさい。クローズドスタンダードの方が我々にとって利益があるように思えても、実際にはそうではないことを思い出しなさい。同時に、利用者がなるべく簡単にGoogle製品から離れられるよう、可能な手を尽くさなければなりません。GoogleはEaglesの歌の中のホテルカリフォルニアでは無いのです – いつでもチェックアウトできますし、ちゃんとその場を去ることができるのです!

Ericが2009年の戦略メモに記したように「我々は利用者を囲い込みません。簡単に競合にうつれるようにしてあげるのです。」この政策は、飛行機の非常口に似ています – パイロットでもあるCEOはこの比喩を喜んでくれるでしょう。それを使わなければならない日が決して来ないことを望んでいますが、それがあることで利用者は安心し、無ければ利用者は激怒します。

我々が – データ解放軍 (Data Liberation Front : dataliberation.org) – という、「チェックアウト」を簡単にすることが任務のチームを社内に持っているのは、このためです。データ解放軍の最近の仕事としてはBloggerとDocsがあげられます。Bloggerを去って他社のサービスを利用したい人は、自分のコンテンツを簡単に持っていくことができます。Docsの利用者は、自分の書類、プレゼンテーション、スプレッドシートをすべてZIPファイルに集めて、ダウンロードできます。データ解放軍が作業しやすいように、あなたたちの製品を作りなさい。一つの方法は利用者のデータをすべて解放する優れた公的APIを用意することです。バージョン2とかバージョン3まで待ってはいけません。製品計画会議の早い段階からこの議論をし、スタート時点からある機能にしなさい。

英国大手新聞のガーディアンデータ解放軍の仕事を取材したとき、「今までの企業間の戦いにおけるロックインという考え方に慣れた」人にとっては「直感に反する」と伝えました。確かにその通りです。古いMBA的な発想で凝り固まった人にとっては直感に反します。しかし我々がちゃんと仕事をやり遂げれば、直感に反しない日が来ます。私たちの目標は、オープンがデフォルトとなるようにすることです。人々はオープンに自然に引きつけられていくでしょう。そしてそれを期待し、要求し、手に入らないときは激怒するようになるでしょう。オープンが直感的になる日が、我々が成功を収めた日となるのです。

大きければ大きいほどよい理由
クローズドシステムは良く知られていて利益があがります。ただし、それをコントロールする人だけの利益です。オープンなシステムは混沌としていて利益があがります。ただし、そのシステムを理解し、誰よりも早く行動できる人だけの利益です。クローズドシステムは早く成長します。それに対してオープンシステムはゆっくり成長します。ですからオープンシステムに賭けるには、長期的展望に立つために必要な楽観的精神、意思、そして手段が必要です。幸いなことに、Googleではこの三つがそろっています。

我々にはリーチの広さ、技術のノウハウ、大規模プロジェクトへの渇望がありますので、大きな投資と必要とし、かつ短期的な明確なリターンが無いような大プロジェクトに挑戦できるのです。我々が世界中の道路を撮影しているおかげで、千マイル遠くは慣れた地点からでも、引っ越しを検討しているマンションの近隣を調べることができます。我々は何百万もの本をスキャンし、広くアクセスすることが可能にしています(出版社と著者の権利に配慮しながら)。他のサービスでは数百メガバイトしか提供していないのに、我々は1ギガバイト(今では7ギガバイト)の容量を無償で提供するメールシステムを作り上げることができます。我々は51の言語で書かれたウェブページを瞬時に翻訳することができます。我々は検索データを分析し、公的衛生機関がインフルエンザの発生をより早く探知できるのを手助けできます。我々はより高速ブラウザ(Chrome)、より優れたモバイルオペレーティングシステム(Android)、そして全く新しいコミュニケーションプラットフォーム(Wave)を作り上げ、そして世界の誰もがそれを土台とし、カスタマイズし、そして改良できるようにオープンにできるのです。

これらのことができるのは、それが情報についての課題であり、我々はその課題を解決するのに必要なコンピュータ科学者、技術、そして計算処理能力を持っているからです。そして我々がこれらの課題を解決すると、さまざまなプラットフォーム – ビデオ、地図、モバイル、PC、音声、エンタープライズ – がより良くなり、競争が激しくなり、イノベーティブになります。我々はしばしば大きすぎると非難されることがあります。しかし大きいからこそ、我々は不可能に挑戦することができるのです。

しかし我々がオープンであることに失敗すれば、すべてが無駄です。ですから、常にオープンになるように自分たちに言い聞かせなくてはなりません。我々は業界に役立つようなオープンスタンダードに貢献していますか。我々が自社のコードをオープンソース化できない理由は何ですか。我々は利用者に価値と透明性とコントロールを提供していますか。なるべく頻繁に、なるべく多くをオープンにしなさい。そしてその是非を問う者がいたら、オープンにすることのメリットを説明してあげるだけでなく、オープンにすることが最善であることを説明してあげなさい。オープンというのはまだ始まったばかりの21世紀のビジネスとコマースを変革するアプローチです。そして我々がオープンを広めることに成功すれば、これから数十年間のMBAのカリキュラムが書き直されるでしょう。

オープンなインターネットは世界中の人々の暮らしを変えます。すべての人の手元に世界中の情報を届け、すべての人に言論の自由を与える可能性を持っています。以前にインターネットの将来に関する私のビジョンをメールで送りましたが(そして後にブログにも掲載しました)、その中にもこの予想が含まれていました。しかし今はビジョンの話をしているのではありません。アクションについて話しています。オープンなインターネットを阻害する抵抗勢力を忘れてはいけません。アクセスを管理する政府、自分の利益のために現状を維持しようとする企業などです。彼らは強力です。もし彼らが勝ってしまえば、インターネットは断片化され、停滞し、価格は高く、そして競争が少なくなるでしょう。

我々のスキルとカルチャーを持ってすれば、こうなってしまうのを防ぐことができますし、防ぐ責任があります。技術は情報を提供する力があると信じています。情報は、善を施す力があると信じています。そしてこの善がなるべく多くの人の生活に影響を与えるためには、オープン以外に道はないと信じています。我々は技術の可能性を楽観視しており、オープンによって生じる混沌は、すべての人に利益をもたらすと信じています。そして機会があれば、オープンを押し進めるように戦います。

オープンは勝利します。まずインターネットで勝利し、次に生活の多くの方面に広がっていくでしょう。例えば政治の未来は透明性です。商取引の未来は情報の対称的な行き来です。文化の未来の自由さです。科学と医学の未来はコラボレーションです。エンターテイメントの未来は参画です。ここに紹介した未来の姿は、いずれもオープンなインターネットが前提です。

グーグル社のプロダクトマネージャーとして、我々が死んでも存続し続けるものをあなたたちは作っています。また我々の誰一人として、グーグル社がどれほどに成長し、人々の生活にどれだけ影響を与えるかを想像し尽くせる人はいません。そう考えると、どれだけのネットワークが「インターネット」に加わるかを正確に把握できず、デフォルトをオープンとした盟友、Vint Cerfと我々は同じです。Vintは誰が見ても正しかったのです。我々もきっと正しいと信じています。