（もくじ。）

ウェブ標準の仕事について。

あのプロジェクトは失敗したと言って良いと思う。出荷はしたし使われている部分もあるので全体として完全な失敗ではないにせよ、長い時間がかかったし評判も期待したほどではなかった。自分が担当した部分については完全な失敗で、誰も使ってない。仕様は deprecate され実装も消されることが決まっている。

なんで失敗したのか、どうすればうまくできたかと繰り返し考えた。自分にとっての結論はあるようなないような状態。もう情報が増えることもないし、いい機会だから書き出しておきたい。

端的には：野心的な目標に対してチームが実力不足だった。いうまでもなく自分もだいぶ実力が足りてなかった。

なんでそんな野心的な目標を持ってしまったのかというと、時代の空気かなと思う。勤務先、および該当製品は、世の中からも割と愛され当事者は調子に乗っていた、と書くとかんじわるいけど、勢いがあって強気だった。

一方、ウェブテクノロジは行き詰まっているように感じられた。Node.js を中心とした JS のエコシステムは盛り上がりはじめていたが、まだ中心が定まっていなかった。たとえば ES6 Modules はまだなくて、複数のモジュール化標準が入り乱れていた。ウェブフロントエンドのフレームワークについてもかなり混沌としており、ぜんぶぱっとしなかった。（まだ React はなかった。）ので調子に乗っていた我々は、ウェブ標準の力でこれを解決したいと考えた。

どのへんが実力不足だったか。DOM のようなコアのウェブ標準をいじる経験は誰にもなかった。それまで同ブラウザが足した API はデスクトップ OS の機能を expose するようなものばかりだったから（データベースとか。）実装の側もようやくフォーク差分を upstream しおえたくらいの時期で、まんなかの方をがちがち触れる人間は限られていた。

野心的なプロジェクトに挑戦して失敗した。それは仕方ない。挑戦しない方がよかったとも思わない。こうすればうまくいったかもという反省は、色々考えたけれどもう一回やる機会もないし、だんだんと忘れてしまった。

勤務先はさておき、自分がやるべき仕事だったのかについてもよく考える。

自分は標準化というアイデアがそんなに好きでない。必要性は理解しているが、あまりお近づきになりたいとは思っていなかった。この感覚がプロジェクトを通じて強まったのは事実だが、標準化というのは根本的に design by committee. 自分が好きでないのは当たり前。

ついでに自分はプラットホームとかフレームワークとかがあまり好きでない。「ウェブプラットフォーム」に「フレームワークとしての API」を足すプロジェクトを仕事でやる。きびしい。特に自分はウェブ開発者としての専門性がまるでない。そんな人間がフレームワーク API とか設計してもいいものができるわけない。設計は他の人がやってくれるという期待があったけれど、やはり自分の肌感覚がないものを作るのは落ち着かないものだった。設計も、細かいところは結局自分で決めないといけないし、大きな変更をする必要だってあるかもしれない。けれど直感が働かないからそれができなかった。

標準化にブロックされ、オープンソースにブロックされ、チーム内の終わり無い議論にブロックされ、コードを書けない時間がとても長かった。この非生産的で無力な自分にはもっと自覚的になり、なんらかのアクションをとって解決すべきだった。プロジェクトを変えるべきかもしれなかった。

でも総体として同じプロジェクトに stick した自分の判断が間違っていたとは思っていない。自分はそれまで job hopper だったし仕事はしょぼいものばかりだった。このときは難しい、価値のある問題を放り出さず向き合いたいと思っていた。だから自分にとっても難しいことに挑戦して失敗したプロジェクトだった。難しさの種類がチームにとってと自分とでは少し違ったというだけで。そこに学びはあった。だいぶ高くついたが仕方ない。

自分にとっての学びはなんだったか。

まず、価値判断が自分でできる仕事をするのが重要ということ。ウェブの API の良し悪しは自分にはまったくわからない。そういうのを仕事にするのはよくなかった。標準化みたいのも好きでも得意でもないから、やはりいまいちだった。価値判断の重要性は、受託開発で働いてきた自分が自社製品開発をする身として学ぶ必要のあることだった。受託開発だと、価値判断はしばしば麻痺された方がよいからね。いつもそうだとはいわないけれど。

もうひとつ、他人にブロックされることが多い仕事はよくないということ。ボトルネックは自分の側にあった方がよい。それはストレスでもあるが、自分ががんばっただけ進む仕事の方がよい。一見ブロックされているが努力によって unblock できる問題もあるから、この判断はそれほど自明でない。とはいえある程度の期間仕事をすれば gut feeling を通じて傾向は判断できると思う。

あとは、製品やプロジェクトの良さと自分との相性は必ずしも足並みを揃えないということ。仕事のウェブブラウザは製品としても良かったし、組織もよく回っていた。会社の調子もよかった。自分もブラウザというテクノロジは関心をもてた。ただ開発者体験を良くするための新しいウェブAPI の標準化という仕事は自分と合っていなかった。

トレードオフもある。オープンソースの仕事をするとかアメリカの会社で働いてみるというのは自分にとっては意味のあることだった。うまくいっている製品チームの一員として学ぶこともたくさんあった。だから負の要素に目をつぶるのは、ある程度は理にかなっている。程度の問題。

たとえば自分の今のアプリの仕事だと、本当にコアの部分・・・たとえば画質・・・みたいのは自分では価値判断できない。そこに後ろめたさはある。ただ画質以外の要素・・・たとえば速度・・・の良し悪しはわかるので、画質のような本道ではなく速度のような補助的な役割を担うことで妥協している。製品のコアな価値を担えたらかっこいいとおもうけど、そういう仕事はなかなかみつからないね。それは勤務先のせいではなく自分のしょぼさだと思っている。

他人によるブロックについても、大企業だったりチームがある程度でかかったりすると細々とブロックされるのは日常。そういうのは複数の作業を持つことで乗り切っている。今は以前とくらべだいぶブロックされることが減り、ボトルネックを自分の側に近付けられていると思う。これはチームやプロジェクト自体の性質もあるし、立ち位置選びがうまくなった面もあるし、チーム内での自分の tenure も関係ある。時間をかけて信頼を高めればそれだけ自律性が増すし、ブロックされにくい道もよく見えてくる。これだけだと 10 年前に戻っただけだけど、リーダーシップ的なのをほぼ完全に捨てることで組織オーバーヘッドを最小化できているのが進歩といえば進歩かもしれない。

話を少し戻して、件のウェブ標準プロジェクトはどうすればうまくいったのだろうか。

越権を承知で無責任かつ雑に書くと、たぶんレンダリングエンジンじゃなくて JS という言語の側に注力すべきだったんじゃないかな。JS は愛されているし人々は気にかけている。レンダリングエンジンは、そんなでもない。たいした根拠はないし、言語をいじったところでいいものができた保証もないけれど。あとは abstraction ではなく真の capability に的を絞ったほうが良かったとも思う。ユーザとプラットフォームの役割分担として。

プロジェクトの最初期は JS の拡張も含めた様々なアイデアが模索されていたけれど、結局レンダリングエンジンの側をなんかするところに収束した。なぜかはわからないけど、たぶん当事者の多数がレンダリングエンジン側の開発者だったから。手にある武器で殴りたくなるポップカルチャー的 conway's law の帰結、に思える。Abstraction に手を出したのは・・・立案者の趣味かな。たぶんね。

同じ人々はその後 service workers という capability focused でずっと広く使われる標準をずっと短い時間で出荷した。同世代の野心的失敗プロジェクトである Native Client も競合たる ASM.JS と手を組んで Web Assembly という広く使われそうな標準に至った。組織もまた学びを糧に前に進んでいる。もっと fail early しろと Eric Ries に怒られそうだけど、それは仕方なし。

自分は今の会社に入る前から何年も仕事をしていて失敗プロジェクトもいっぱいあったのに、あまりそれらに関する反省が思い出せない。あまり反省しなかったのだろうか・・・。とおもったが、昔のブログを見ると少しは反省しているね。メランコリックすぎてわかりにくいけど。

あと、プロジェクト自体がしょぼすぎて色々責任転嫁の余地があったのを言い訳に、自分の不足に目を向ける誠実さを欠いていたとも思う。自分のだめさに自覚的であるべきだったが、中二病ってのはそういうことしないんだよ。