実装が難しすぎたOSI
及川卓也氏：インターネットのスタートについてですが、各自独特のベンダーネットワークで相互運用もできてないというところに対して今のインターネット、つまりARPANETの発想とは別に、きちっとした標準を作ろうという動きが出てきます。
それがOSI、Open Systems Interconnectionというものです。今でもOSIというのはネットワークを説明するときの7階層モデルというところで使われるものです。逆に言うと、今ではそれくらいしか出てこなくなってしまったものなんです。
要は、実際に電気信号を行う物理的なところをデータのかたちにし、さらにそれをどう表現するか、アプリケーションではどう見えるかというところを、各レイヤーごとにプロトコルを決めることできちんと会話できるようにしましょうという、その標準を考えたわけですね。
しかし問題がありました。このOSIというのは複雑すぎたんです。（スライドを指して）このように電話帳みたいな厚さの仕様書があって、それを実装しなきゃいけなかったんです。と言っても、若い人に電話帳って言っても、「電話帳って見たことないです」っていう人が増えてきて……。
（会場笑）
「じゃあほら、カラオケボックスに曲目の書いてある本ってあったでしょ！」って言っても、最近はタブレットになってるから「それも知りません」って言われちゃうんですが（笑）。とにかく分厚いです。そんな仕様書を実装しましょうということになってたんですね。
TCP／IP 対 OSI、勝利の行方は？
そこで「これは本当にオープンか？」ということを考えなきゃいけなくて。実際にはISOという国際標準団体のオープンなプロトコルのやり方を取っていたんですけれども。必ずしもうまくいかなかった。
そこでなにが起きたかというと、インターネットが使っていたTCP／IPというプロトコルと、先ほどの電話帳みたいに分厚いOSIのどっちが使えますかっていう論争が起きてしまって。結果的にはTCP／IP、インターネットが勝ったんです。
OSIの敗因というのは日本語のウィキペディアにも書いてあるんですけれども、「プロトコルシートが複雑すぎて、実装が非常に困難だった」というところで、要は実際には作れないということです。まず電話帳みたいな分厚い本に書かれたことを実装するために、各国から代表の人たちが出てきて、その標準化を進めるわけです。できたはいいけれども作るのは面倒くさかったし、すごく難しかった。実際にはワークしなかったんですね。
インターネットの成功には、「TCP／IPだったからちゃんと実装できた」っていうところに秘密があります。IETF、Internet Engineering Task Forceという団体が、インターネットに使われているいろんなプロトコルの標準化を行っているんですが、ここのコンセプトがこの言葉なんですね。
「Rough consensus and Running code」。つまり、大まかな合意形成ができたのなら、動くコードのほうが大事であると。標準化をしっかりやって、あとからそれを実装しましょうということです。「この標準に沿えば絶対につながるはずだ！」という考えではなく、実際動いちゃったものを一緒に作っていきましょうっていう考え方ですね。これがIETFの考え方になっています。
Webはなぜ流行ったのか？
インターネットの技術の1つであるWebについて見ていきましょう。（スライドを指して）大昔のWebってこんな感じだったんですね。Googleのホームページもこんな感じ。まあ、Googleのホームページはほとんど変わってないというところがGoogleらしいんですけれども。
Webってどんなものかというと、いろんな情報を発信するサーバーからクライアント側がリソースをダウンロードしてきて、それを再現するというだけの単純なものなんですね。プロトコルとしてはHTTPと呼ばれているものがあります。「このリソースをくれ」ってリクエストしたら、それをダウンロードしてきて再現するというものです。
一番最初にダウンロードしてくれるものがHTMLで、その中にほかのリソースのロケーションが書いてあるので、それを順次ダウンロードして実行したり再現したりするという、非常にシンプルなものです。
もともとは情報の取得と表示だけをやっていたんですけれども、考えてみるとメインフレームと同じなんですね。
じゃあ、なんでこんなにWebが流行ったかについて考えてみます。（スライドを指して）今言ったようにWebサーバーとブラウザというものがあって、それはこういった単純なものになってるんですけれども。これが横連携できるようになっているというところが、単なるメインフレームとの違いなんですね。
マッシュアップ技術の発展系がクラウドとなる
横連携といっても実際には、例えばあるところで別のJavaScriptのウィジェットを持ってきて「実行してください」とやっていたりして、ブラウザ中心にはなっていたんですけれど、こういった連携ができるようになりました。これが俗に言うマッシュアップという技術であり、最近はあんまり言わないかもしれないですけど。
（スライドを指して）例えばこれは、スイスの国営鉄道がやっているすごく単純な例です。日本でもやってる人はいると思うんですけど、実際のスイスの鉄道が今どこを走っているかをGoogleマップの上に載っけるという、単純なジオ系の地理情報系マッシュアップなんです。
Googleマップの上にオープンデータとして提供されているデータを持ってきて、それを載せるということですね。でもこれって、Webじゃなかったならこんな簡単にはできないことなんですね。
このマッシュアップの技術があったことで、Webが単なる情報の発信と取得ではなく、アプリケーションとしてのプラットフォームとして使われるという発展もしていくようになったと。この発展形がいわゆるクラウドで、いつでもどこでもどんな場所でもアプリケーションを利用できるっていうところに発展していくわけです。
先ほどブラウザを中心にマッシュアップが行われていたと言いましたが、成熟していくと実際にサーバー間との連携も行われるようになってくるし、いろんなベンダーも出てくるわけですね。
次の技術戦争は、XML Web Services 対 REST
（スライドを指して）これがWebサービス、もっと正確に言うとXML Web Servicesと言われているものです。2000年初頭に起きていますね。ここにvs RESTって書いてあるんですけど、要はインターネットの技術が現在のように社会インフラとして使われるようになるまでに、いくつもの技術戦争があったということです。
最初がOSI vs TCP／IPだったんですけれども、次のWeb時代の戦場がXML Web ServicesとRESTなんですね。XML Web Servicesって、2000年前半から技術者だった方は覚えてらっしゃるかと思うんですけれども、めっちゃ難しいんですよ。
SOAPって言われているものがあり、UDDIというものもあって……。絵に描いたとおりに動いたならば、確かにすばらしいエンタープライズ連携ができますねって感じなんですが、それができなかった。あんまり細かいことは言わないですけど、例えばSOAPのフォーマットには、そんなに簡単ではないところがあったわけです。
一方で、今多くのWeb連携で使われているのはRESTというプロトコルで、これはめちゃくちゃ簡単なんですね。みなさんお馴染みの、ブラウザのアドレスバーを叩くのと同じフォーマットで、後ろに命令と引数を書く。それだけでデータが返ってくるという、非常に単純なパターンだったんです。
実際に、RESTで用いられるHTTPのメソッドにはGET・PUT・POST・DELETEの4つがあります。それを、それぞれのアクションに結びつけて、引数をつければいいだけという非常に明確なものであったと。こちらのほうが最終的には勝った。XML Web Servicesというのは、コンセプトは一部残ってるところはあるんですが、主力にはならなかったという現状があります。
エレガントさよりもシンプルさが世界を制する
同じようなことは、ほかにも起きてるんですね。例えば、今出てきたXML Web Servicesで使っていたXMLとJSONというフォーマット、つまりデータの形式の戦いですね。
XMLのほうがエレガントではあるんです。いろいろな名前空間のところは定義もできたりします。だけれども、プログラマーフレンドリーじゃなかった。
（スライドを指して）左側のJSONのほうが反応しやすかった。いろんなプログラミング言語でも、そのためのフレームワークやライブラリが用意されていたこともあり、これはJSONが勝ったと。ここで大事なのは、どれだけエレガントかということよりもSimplicity、単純であることが大事であるということです。
それはなぜか。世の中は、特にインターネットに代表されるように相互運用性が非常に大事になってきます。1ベンダーですべてをコントロールする時代であったならば、エレガントなものを作って完全に自分たちだけでコントロールすることで、複雑なものも生き残る可能性はありました。
でも実際は、実装してつながってなんぼです。このデータがここからあそこまで行くということが大事な世界においては、シンプルから始めていくということが大事になるわけです。
メールのプロトコルをのぞいてみると
メールのプロトコルを見てみましょう。私はOSIのプロトコルも見ていたんですけれど、インターネットのSMTPと呼ばれるものは、簡単さがぜんぜん違うんですね。最近はテルネットってあんまり使わないと思うんですけれど、サーバーとの通信をするときにコマンドでいろいろ命令が打てるんですね。それでメールが送れたり読めちゃったりするのって「なんだそれ!?」って感じなんですね。
そもそもメールのボディのところとかを、そのままのシンプルなテキストでやりとりするなんてことは考えられなかった時代があった。でも、こちらのほうがどんなシステムともつながるんです。そして、そのあとに複雑化していくんですね。メールの規格を拡張するMIMEというものを使って、マルチメディアもボディも入れられるようにしましょうってなっていったり、暗号化も走っていったりすると。
それはHTTPも一緒なんですね。これもテルネットとかで中を全部見ることができたりする。そういったSimplicity、単純さというものが、普及していくときの1つの鍵であったと言えるわけです。
何度も言いますけど、技術戦争的なところにはもう1つありまして。私はXMLに恨みがあるわけじゃないんですけれども（笑）。XMLを担ぎたかった人っていうのは、世の中にたくさんいます。
XHTMLというものがあって、これはExtensibleマークアップのHTMLですが、あろうことかこれは、マークアップランゲージと呼ばれるものが進化したカタチを取っているんですね。XMLはやっぱり素性がいいから、これをHTMLの後継にしようということで、Webの標準化団体の人たちが考えました。
「どれだけ開発しやすいか」が注目される時代のプロトコル
そもそもWebを一番最初に考えたティム・バーナーズ＝リーが、Semantic Webという情報を正しく送るために一つひとつの意味付けを行うという、とてもこだわる人だったんですね。そんな彼の思惑もあり、Semantic Webを普及させようとした。
ただ世の中は、情報の受発信だけじゃなくなってきていた。もはやYouTubeも出ていたし、ほかにもWebを使ったいろんなものが出ていたので、「アプリケーションとしてどれだけ開発しやすいか」に興味を持つ人たちが増えていた時代だったんです。
そんなときに、このままWebの標準化団体に任せていちゃ危ないと。今はもう普通になっているHTML5は、自分たちだけで別の標準を作ろうとしたWHATWGという団体から生まれ、この団体がどんどん独自に標準化を進めていったんですね。
この分岐していったものが、そのままじゃいけないということになって、最終的にはXHTMLというものは諦めてHTMLでシンプルに進め、かつアプリケーションのプラットフォームとしての機能をちゃんと拡充していこうという方向性になったと。つまりここでもHTMLというものが勝ったんです。
このWebの成功の秘密も、先ほどのインターネットの秘密と同じようなところがあります。一旦Semantic WebでXHTMLにいっちゃいましたけど、基本的にこの新しい団体（W3C）の人たちが、標準化のいろんなコンセプトや哲学を持っている人たちです。
Webブラウザを作る団体が減っている理由
（スライドを指して）ここにはWorking Groupというところの「どうやったら標準化になるか」が書いてあるんですが、さっきのIETFのインターネットの標準化と同じようなことが書かれているんですね。
Working Groupは「demonstrate two interoperable implementations of each feature」、要は機能の提案をしたとするならば、少なくとも2つ以上の実装があって、それがinteroperableであること。相互運用が可能であることを証明しない限りは標準にしないよって言ってるんですね。
ちょっと脱線すると、最近Webブラウザを作る団体がどんどん減っていっています。それは、この2つ以上の実装というのが難しくなっちゃってるからです。MicrosoftのEdgeっていう新しいブラウザも、今後はChromeのエンジンを使うと発表しているので、さらに難しくなっているんです。ただ、それでもやはり標準化というところで相互運用が大事だと考えると、この2つ以上の実装が非常に大事であると思います。
IETFおよびW3C、IETFの「Rough consensus and Running code」というものと、W3Cの「2つ以上のinteroperableな実装があること」を考えてみると、「標準ができて完成したものを、みなさん実装してください。そうしたなら、それらは絶対つながるはずです」という考え方ではなく、標準と実装を何度も何度も繰り返しながら、標準自身がきちんと使えるものにしていくという育て方をしていくのがインターネット、Webの精神になってるわけです。
言うならばこれは、走りながら考えましょうという世界なんですね。ちょっとこじつけに近いところもあるんですけれども、TCP／IPのコアのプロトコルの考え方が、それに非常に近いです。
