圏外からのWeb未来観測、2回目のゲストは『Webを支える技術』( 注1 )の著者の山本陽平さんです。山本さんは、クールでロジカルな話し方をする人で、一見、典型的な理系の技術者という印象なのですが、実は、すごく激しいパッションを秘めた人でした。技術的に正しい選択を通すためには会社を辞める覚悟までしていたそうです。現代に生きる侍の一人ではないかと思います。
(撮影:平野正樹)
『Webを支える技術』に入れなかったもの
中島: 『Webを支える技術』は、もう定番の教科書としての評価が定まってますね。
山本: essaさんにもレビューしていただいて(【1】 、【2】 )ありがとうございます。
中島: 何よりこの本は、話題の絞り込みが適切だと思うのですが、意識してカットしたところとかはあるのでしょうか?
山本: まず、プログラミング言語に依存したくなかったので、具体的な言語のコードはほとんど入っていません。その代わりHTTPの生々しいリクエストメッセージをそのまま入れる形になっています。
中島: なるほど。会社で若い人に紹介したりしているのですが、経験の浅い人にも非常に入りやすい本であるように感じます。そのあたりの配慮が良かったのかもしれませんね。
山本: 長く使える定番の教科書を作ろうという狙いがありました。
中島: 最初からそこは狙ってたんだ(笑) 。
山本: はい、息の長い本を作ろうという狙いがあったので、数年で変わってしまいそうなものは省いています。HTML5もコラムで少し書いただけにしました。ほかにも、たとえばURI Templates[2] っていう仕様を最初は入れる予定だったのですが、仕様がころころ変わって結局落ち着かないから削ったりしました。
あとはセキュリティとか、ほかにちゃんといい本があるところは、そういう本を読んでくださいと。自分がそんなに詳しくもないっていうのもありますが。
中島: 教科書でありながらポリシーが明確っていうところがおもしろいですよね。教科書を目指すとしたら、好き嫌い抜きでまんべんなく入れる必要があると思うんですが、そういう無理をしているような部分がなくて、全体的にすっきりしていると思いました。
山本: もう一つ言えば、僕が好きじゃないものは入れてないです。Webサービスの話をするんだったら本当はSOAPやWS-*[3] を詳しく書くべきかもしれないですが、一切そういうことは書いていない(笑) 。
RESTとの出会い
中島: 山本さんといえば「RESTの人」というイメージがあるのですが、お仕事の中でもずっとRESTを意識していらっしゃるんですか。
山本: いやそれが、会社に入って最初にやっていたのはSOAPの仕事なんです。WS-I(Web Services Interoperability Organization )という、SOAPの仕様が各社ばらばらだからみんなで集まって共通化する組織があって、そこで活動したりしていました。
そんな中、2004年頃にRESTを知って、これはすごくいいなと思ったんですけど、会社では全然相手にされませんでした。
中島: それはわかるような気がします。コンピュータの歴史から言ったらSOAPのほうが素直な発展だと思うんですよね。ソケットがあって、RPC(Remote Procedure Call 、リモート呼び出し)になって、オブジェクト指向のMicrosoftのCOM(Component Object Model )とかああいう方向になって、それをそのままWebに載せたらSOAPになります。過去との連続性はありますから、SOAPのほうが古い人間にはまともな仕様に見えるんですよね。
山本: まずそもそもRESTは仕様じゃないので、論文だけ見てもWebサービスは作れないんですよ。対してSOAPは仕様なのでSOAPを使えばWebサービスは作れたんですよ。
Webは疎結合分散処理でできている
中島: RESTってやっぱり、メソッドが8つしかないとか、ちょっと異常ですよね。実際にやってみればRESTのほうがいいってわかると思うんですけど、論文を読んだ時点では「ええ!?」と思っちゃうところはあると思う。
最近流行りのNoSQLも同じようなところがありますね。やっぱりリレーショナルデータベースをやってきた人間からすると、まともな分散処理は2層コミットで密結合のプロトコルですよね。それと比べるとNoSQLはちょっとふざけてるのかっていう(笑) 。Eventual Consistencyってすごい言葉だと思います。機嫌がいいと一致してることもあるけど、あまり頼りにしてはいけないっていうことでしょ(笑) 。
山本: DNS(Domain Name System )も昔からそうだし。
中島: そうか。DNSもそうですね。
山本: あとはMy SQLのレプリケーションも基本そうなんです。レプリケーション先に結果が行くかどうかはリクエストを発行した時点ではわからない。それでもなんとかWebは動いてるんだからそれでいいんじゃないの? っていう割り切りですよね。
中島: 私はもともとは汎用機のCOBOLの世界で育った人間なので、そういうRESTとかNoSQLとか気持ち悪くてしょうがないっていう感性はどこか残っているんですよね。そういう疎結合の分散処理っていうのを見ると、蕁麻疹(じんましん)出そうな人の気持ちもわかります。一方で今やっていることはWebにベッタリですから、分裂しているようなところがありますね。
山本: でも二面性があると、どっちの気持ちがつつかれたかで技術が成功するかどうかわかったりするんじゃないですか?
中島: ああ、それは確かにそうかもしれません。センサーが2つあるからわかるっていうのはありますね。
山本: 絶対こっちが筋がいいって思うんですね。
中島: RESTは、「 これはいい」っていうセンサーと「気持ち悪い」っていうセンサーが両方反応したので、これはいけるんじゃないかという気がしました。ブログにもいくつか記事を書いています[4] 。
山本: 2005年ごろですよね。そのころはRESTというキーワードがあれば何でも読んでましたので、essaさんのエントリも熟読していました。今の言葉で言い直すとURIのアドレス可能性について書かれていたと思います。Web上にあるものは何でも同定できて参照できると。Googleなどの検索サービスもこの前提で作られています。
中島: そうですね。URIをコピー&ペーストできるっていうのがとても重要なんですよね。
山本: 基幹系のシステムだったら何月何日のイベントの売上のここの部分っていうのをURIでがっちり指定できると後から拡張できるシステムを作るときにすごく作りやすくなっているはずなんですよ。
中島: Application state…なんでしたっけ?
山本: Hypermedia as the engine of application state。アプリケーションエンジンとしてのハイパーメディアですね。
技術的な正論を貫き通すということ
中島: RESTの良さを訴えても、最初はなかなか理解されなかったんですか?
山本: そうです。そうなんですけど、技術者として技術を評価すると、どうしてもRESTのほうがいいと確信して、会社を辞めるくらいの覚悟でブログ を書き始めました。
中島: そこまで強い想いがあったんですか。それで、そこからどんなふうになっていったんですかね。会社の中である程度強引に推し進めたようなところが?
山本陽平氏
山本: 新しい技術のマーケティングについては僕の独自の手法がありまして。アルファギークにアプローチするのが一番効率的だと思います。RESTの場合は、はてなの伊藤直也さん(編注 )が反応してくれたので、結構よかったんですよね。会社の中のようなローカルなところで広めるよりも、ネット上の感度の高い人たちに訴えかけていくほうが効率的だったと思います。
おかげさまでこうやって本を書くまでになって、一応日本でもRESTがちゃんと認識されて、世の中的にもちゃんと決着がついたという話で、僕としてはよかったなと思ってます。
中島: それにしても、技術的に正しいと思える選択を貫き通すというのはたいへんなことだったと思うのですが。
山本: それは、村田真さん[5] のお手伝いをしていて、影響を受けた部分があるかもしれません。村田さんが開発されたRELAX NGは、競合するW3C(World Wide Web Consortium )のXML Schemaより使いやすいものであることは、技術的には、はっきりしているのですが、当初、標準はXML Schemaのほうだったんですね。それをひっくり返してRELAX NGも標準とするために、大活躍されたのを近くで見ていました。
ISO(International Organization for Standardization 、国際標準化機構)の標準にするには普通は数年以上かかるたいへんなプロセスなんですが、JISになっちゃうと日本の標準ということなので、結構プロセスをすっとばせるんですよ。それで、まずJISの標準にしてしまった。そして、その次のISOのSC34という委員会をあえて日本の佐渡という不便なところでやり、参加者をできるだけ減らすっていう(笑) 、すごい裏技まで使われたんです。
中島: 技術的に正しいものを通すためには、表裏あらゆることをする。
山本: エンジニアとは言っても、普段の会社での付き合いとかを考えると、大勢側にいっちゃってなかなか強引なことはできないじゃないですか。そうじゃなくて技術的に正しい方向に持っていくんだっていうポリシーがしっかりしていて、すごいなあっていうのがそのときありましたね。
中島: もし村田さんがこのとき行動を起こさなかったらどうなっていたんでしょうか。
山本: RELAX NGじゃないと表現できないスキーマっていうのがあって、XHTMLの仕様とかはそうですね。だから、標準のスキーマ言語がXML Schemaだと、標準の範囲だけだと実用性が欠けているという事態になって、大袈裟に言えば世界中のプログラマが苦労することになっていたと思います。
中島: 村田さんのそういうやり方を見ていて、それを見習って覚悟を決めてRESTを通したという。
山本: 振り返ってみるとそうかもしれないですね。
中島: 同じようなジレンマの中で悩んでいる人は多いかもしれませんね。
標準策定プロセスのオープン化
山本: 特に今は、標準の決定プロセスがオープンになっています。昔は大企業の代表のような限られた人しか参加できない委員会で標準化が行われていましたが、現在は誰でも標準化に参加できて、本当に実力のある人が意見を言ってそのとおりになるっていう世界になっていると思います。W3Cもあまり機能しなくなってきているし。そのへんはこの10年でかなり変わったところだと思います。
オープンなところで標準が決まっていく流れだと、普通のエンジニアが簡単に参加できるわけじゃないですか。普通のエンジニアたちが標準化の行方を左右する。そのエンジニアの判断がこのあとの世界にすごい影響を与える可能性があります。そういう重要性を意識して判断できる人はいいのですが、意識できない人はどうするのかなっていうのが気になっています。
たとえば、AtomPubのSlugヘッダの仕様はマルチバイトはうまく使えない仕様になってたんですね。NTTコミュニケーションズの朝倉浩志さんという人が本家のメーリングリストで、いろいろうるさいドイツ人とかと議論しながらなんとかいいほうに持っていったっていう経緯があって、そのときの草の根の活動がなかったら、今ごろAtomPubは日本語でまともに使えない仕様になっていたかもしれない。
OpenIDなんかもそうですが、作って公開しちゃってみんなに意見を求めるっていう形で、仕様策定のスピードがかなり早くなっています。だから感度のいい人がみんなで見てないと、どんどん文字コードの話とかは日本人の知らない間に決まっちゃう可能性もあるんですよね。
中島: よくあるパターンとしては日本語が扱いにくい仕様になったものをバッドノウハウで処理して、そのバッドノウハウを自慢するみたいな傾向がありますね。そうあってはいけないということですよね。
山本: 仕様策定のときから誰でも関われるんだからちゃんと関わって、いい方向に持っていくことが重要ですよね。
別の例を挙げると、ODF(OpenDocument Format )というOpenOffice.orgが採用しているデータフォーマットにも大きな問題がありました。ODFはXMLベースのフォーマットなんですけど、メタデータにふりがながふれないという問題があって、これも10年くらいやってるはずなのに、そんなことに誰も気づかなかったのかというのがあって。
中島: 気づいた人がいるかもしれないですよね、気づいて黙っていた人が。もしいたとしたら、その人は知らず知らず国益をしょっている立場になっていたわけですね。ミニ国益(笑) 。
山本: かもしれないですね。実はそういう人が自分がミニ国益をしょっていたことを意識できていたのだろうかと。あるいは意識してたとしてなぜ黙ってしまったのかと。
中島: 「武士道と云ふは死ぬ事と見付けたり」の「葉隠(はがくれ) 」 ( 注6 )みたいな話ですよね。いつでも死ぬ覚悟ができているかみたいな(笑) 。
山本: 明治維新の時代の人なんかはそういう覚悟があったんでしょうね。今のエンジニアに死ぬ覚悟が必要とは言わないですけど、国益に関わる判断を迫られたときの判断材料はあったほうがいいよな、と。
「ミニ国益」をしょってしまったとき
山本: たぶん日本人のソフトウェアエンジニアで一番国益をしょっているのはまつもとさん[7] だと思いますが、まつもとさんにはちゃんと宗教があるじゃないですか(編注 ) 。頼りどころがあるというか。心の支えがあるというか。どんなにひどいことを言われようがちゃんと自分のポリシーを貫けそうな気がします。でも、普通の日本人はあまり宗教に馴染みがないですし、心が折れちゃう人は折れちゃう気がします。
中島: そうか、期せずして国益をしょってしまったとき、支えになるものが何なのかというのは、大きな問題ですね。
山本: 思想までいくと僕には無理なのですが、どういう価値基準で行動すべきかという点については、自分なりに考えていることがあります。浅羽道明さんの『昭和三十年代主義』( 注8 )という本や、そこで紹介されている「明日があるさ THE MOVIE」っていうダウンタウンの浜ちゃんが主演している映画から考えたことなんですが。
簡単に言うと、確固たる個を持ったプロフェッショナルが必要に応じてある目的のもとに集まって、目的を達成したら潔く解散して、それぞれの日常に戻っていく、というような感じで、全然知らない人たちが集まって同じ1つの目的でプロジェクトをやって、成功したらまた散っていく。自分の日常に帰っていくっていう世界がなんとなく理想なんじゃないかなって思ってます。
中島: コミュニティを作るということとは違うんですね。
山本: 僕は半永久的に続くみんなで集まるコミュニティみたいなのが基本的に好きじゃなくて。どっちかっていうと必要があれば集まるほうが好きなんですね。
中島: 用を果たしたら散ったほうがいい。
山本: コミュニティっていうのは自分の場合で言うと、たとえば家族とか親戚づきあいとか地域のコミュニティとか、もちろん会社というのもあって、それで十分かなという気がします。ネットでもつながりばかり求めてしまうのは個人的には合わない。だからネットの上ではしがらみとかではなく、みんなでわーっと集まって祝祭をやって潔く散るほうがいいなと思います。
中島: なるほどね。
一期一会、祝祭、そしてREST
中島: そのパッと散るというところに美学が。
山本: そうですね。そうしないと新しいものが生まれない気がするんですよね。どうせネットをやるならそっちじゃないかと。
中島: 私はRESTの説明をするとき、「 笑っていいとも!」のテレフォンショッキングの例を使うんですね。あれで次に回す人に電話をかけるとき、アナウンサーとマネージャーが最初に会話して、ネゴシエーションが終わってからタレントが喋り出しますよね。あれはSOAP的だと。
RESTは、用がある人の携帯に本人が直接電話をかけて、ステートレスでいきなり要件を言う。だからこれは、知らない人同士が一期一会でつながるためのアーキテクテャだと。
山本: なんでもかんでも一意に指し示されちゃうことに嫌悪感を感じる人もいますから、そこの難しさはあると思うのですが。
中島: そうですね。ネゴシエーションなり紹介や仲立ちという手順を省略して、自分の身分などを明らかにしないで、いきなり批判されると違和感を覚える人もいます。でも、Webのアーキテクチャ的には、やはりRESTでいきなり要件から入り、終わったら散るが本当だと思います。
山本: オープンソースとかでもそうですけど、だらだらと同じところで回ったりしているよりは、プロフェッショナルの人がみんなで結束して何かプロジェクトをやったら解散するみたいな世界のほうが好きなんですね。梅田望夫さんが残念発言をして[9] 炎上しましたが、僕は、梅田さんがおっしゃっていたのは、そういうことじゃないかなと思っていて、それにすごく共感します。
中島: なるほど。専門性をホームグラウンドとして、祝祭としてプロジェクトに随時参加していくというイメージですね。
山本氏と2人で歩く
あとがき
「技術者はミニ国益を背中にしょっている覚悟が必要」という視点は新鮮でした。山本さんは、普通に「国益」という言葉を使いますが、技術とかけ離れた別の分野の知識を無理矢理仕事に持ち込んでいるわけではありません。そうではなく、長期的な視点から、冷静かつ客観的に自分の置かれた環境を見て、そのうえで技術者として何をすべきかということを、普通の人より真剣に考えているだけです。技術者も、背中に大きなものを背負うことで、大きく成長できるのかもしれません。