好きな仕事を、やり遂げること。（2）

W3CのPrincipalエンジニアとして働くマイケル・スミスさん。前半では、技術的な仕事にどのように取り組んでいるか、取り組む中でハマってしまうYak Shaving（ヤクの毛刈り）についてなど、興味深い話をお聞きしました。

前半の記事はこちら

後半では、人間のフラストレーションが実装の原動力になること、本当の課題解決とは、これまでの経歴、そして今の働き方について話が続きます。

フラストレーションゆえに、自分でツールを作る

Mike: 実際、日本にいると、他の国の人には理解されないフラストレーションがあります。たとえば、Webフォームで「半角カタカナで」入力してくださいと言われること。今も存在しますよね。あれを設計した人に会えるとしたら、ホントに問い詰めたい‥！フロントエンド開発の目的は、複雑さをユーザーから隠すことのはずなんです。データベースに半角カタカナで入れる必要がある、というのはまだ理解できます。でもだからといってユーザーに入力させる必要はないでしょう？、と。

日本固有のUX問題は他にもたくさんあります。私がOperaにいた頃、Webには縦書きがありませんでした。本を読み慣れた人がWebページを見ると、まったく本のように見えなかった。今は改善されていて、子どもたちがiPadで読む縦書きのテキストは本当に美しい。でもずっとそうだったわけじゃありません。

ルビもそうですよね。世界中で必要としているのは日本だけですが、うちの子どもたちはルビがないと読めないものも多い。そういう世界の他の地域が抱えていない次元のUXのニーズを、私たちは抱えています。

ヤクスタックの話に戻りますね。

自分のフラストレーションゆえに、私は自分でツールを作ることになるのですが、最近はGoで書いています。CharmというGo言語でCLIを作成できるフレームワークがあって、コンポーネントが充実していてすごくいいんです。Goは書いていて気持ちいい言語なので、そこに時間を使って、それからパッチのレビューをさばく作業に戻る。

でも結局、これだけ時間がかかるせいで、私も機械と同じ間違いを犯してしまうんです。実装しようとしたとき、「これ、仕様のほうが不十分だ」となる。これは例外じゃなくて、むしろ普通です。

そこで選択が迫られる。正しいのは、仕様のIssueトラッカーにバグを上げて「この書き方では実装できない。変更が必要だ！」と言うことです。でも、相手は人間です。機械と違って、完全に合理的にやり取りできない。人間は自分の書いたものを批判されると、防御的になります。「いや、仕様は間違ってない！」と反応されてしまう。でもこちらは「間違ってる。実装しようとしたら絶対にできない。」とわかっている。それで何日も押し問答になります。

だから結局「わかったもういいよ、みんながやってるのと同じにすればいいんだろ」ってなるんです。みんな、つまりWebKitがどうやったか、ChromeやGeckoがどうやったかを見て、同じ仮定をコードに落とし込む。

これがWebプラットフォームにこれほど技術的負債と混沌が積み重なっている理由です。お互いの間違いと仮定をコピーし続けている。悪意があってのことじゃないんです。時間に限りがある中で、パッチをレビューしてもらいマージしてリリースする、それが目標だから。

Studio: 壊れた仕様を実装した結果として、「ほら動かない」と見せることが、修正を求める証拠になる、ということですよね。

Mike: そう、それが唯一の証明の仕方だし、それで初めて「直してくれ」と言えるんです。

ブラウザエンジニアリングの現実はそういうものです。Chromeチームは、まあ彼らはお金をもらってやっているので、エンジニアリングマネジメントもあるし、規律もある。だからよりきれいに仕事を進められる。それでもミスはします。人間ですから。

仕様によって品質にはかなり差があって、HTMLの仕様はとても良い。DOMの仕様も良い。でもCSSの仕様は‥実装通りに書かれていない。それはもうみんな知ってることで、しょうがないからみんな‥。

Studio: どうするんですか？

Mike: 他の人がやったことを見て、なんとかあわせる。それ以外にも、テストスイートがありますよね。テストをパスさせることだけに集中する、というのもひとつの手です。皆さんもそういう経験があると思いますが、テストがあって、他の実装がそれをパスしている場合、仕様がおかしいとわかっていても、仕様通りに動かせるかどうかわからなくても、テストだけを見る。これは一種の信仰みたいな行為で、そのテストがちゃんとあるべきことをテストしているという信頼が前提にある。でも結局、私たちにあるのはそれだけです。

要件があって、テストがある。要件について議論し直すのにどれだけ時間を使うか、それともとにかく動くものを出すことに集中するか、それは判断の問題です。

解決策はまだいらない。課題を教えてほしい。

Studio: HTMLやDOMはしっかりしていて、CSSはごちゃっとしているというお話でしたが、その違いはどこから来るんでしょう？

Mike: 人によって意見は違いますが、私の見方では、仕様を書く人の課題解決へのアプローチの違いだと思います。

よくあるのはこういうパターンです。誰かが「Webプラットフォームに新機能を追加したい」という良いアイデアを持ってくる。何週間も何ヶ月も一人でこもって考えて、「新しい要素を作った」「新しいAPIを全部設計した」と言ってやってくる。

それを見て私たちが言うのは、「解決策はまだいらない。あなたが解決しようとしている課題を教えてほしい。」ということです。まず課題について合意する必要がある。そして多くの場合、課題は彼らが思っているものと違う。間違った課題を解こうとしていて、本当の課題はもっと根本的なところにあります。

症状を直すことに時間を使いすぎてはいけない、もっと本当の課題を直しましょう、と言いたい。

クライアントワークをしていれば同じことを経験しますよね。「これが必要だ、こう動かないといけない」と言ってくる。でも話し込んでいくと、「それは本当に欲しいものじゃないよね」となる。それを上手く伝えて、「お金をもらうなら言われた通りやりますが、それはあなたが本当に欲しいものではないと思います」と言わないといけない。

クライアントワークだと最終的にはお金を払う人の言う通りになりますが、仕様の世界では単純に「No」と言えます。「これが必要だ」と言われても、たいていの場合「それはやらない」と答える。「今はJavaScriptで全部書かないといけないから不便だ」と言われても、「あなたはJavaScriptエンジニアでしょう、自分でやって。それを便利にすることは、それほど重要じゃない」と。

たとえば、ずっと「脚注要素が必要だ」という声があります。Webで脚注を表現する方法が欲しい、と。でもそれは重要じゃない。重要だと思うすべてのことをやろうとしたら、仕様は今の100倍の大きさになる‥言ってみれば、CSSの仕様はそうなってしまっています。

CSSグループの課題は、「No」と言う頻度が足りないことだと思っています。私たちも同じ間違いを犯したことがある。App Cacheというものを作ったことがあって、あれは大きな失敗でした。

問題は、一度作ったものは消せないということです。CSSは同じことをする方法を複数作ってしまっています。CSS GridとCSS Flexbox‥なぜ2つあるんでしょうね（笑）？

1つのメカニズムじゃダメなんでしょうか。結果として、CSSのAPIは巨大になりました。「こんなにたくさんある、すごい」と喜ぶ人もいますが、普通に何かを作りたい人からすれば、APIは小さいほうがいい。

だから私たちがやることは、まず「No」と言うこと。APIインターフェースをできるだけ小さく保つ。そして正しい課題を解く。それだけです。

Studio: 実際にすべてのCSSの仕様を見たことはないんですが、どのくらいのボリュームなんですか？

Mike: どこかに全部まとめたサイトがあるんですが‥正確な数は覚えていないけど、アクティブなCSS仕様だけで160あります。それ以外のすべてを合わせたのと同じくらい、あるいはそれ以上。半分以上はCSSです。

テストスイートの話でも同じことが言えて、テストのパス率を上げようとすると、結局ほとんどがCSSの実装に行き着く。

もうひとつ言うと、CSSはモジュール化されているんですが‥理論上はモジュール化は良いことで、「全部分割しよう」となる。でも実装しようとすると、分割できないんです。Webエンジンはモノリシックで、分けられない。中国でも似たような議論をしました。モバイル向けに「使わない機能は省いていい」という話になって、理屈はわかるんですが、実際にはできない。

Studio: 大きな塊がひとつある、ということですね。

Mike: そう。小さくして出す、というのは無理なんです。

Studio: 全部つながっているから。

Mike: そうです。そしてCSSの仕様のもうひとつの問題は、ある仕様を担当する人と別の仕様を担当する人が、互いに話していないこと。自分の担当範囲のことは誇りを持って取り組んでいる。でも「他の部分とどう連携するか」を仕様に書いていない。

エンジニアには一般的に、過剰設計に向かう傾向がある人がいます。どんな課題を前にしても「フレームワークを作ろう」となる。だからフレームワークがこんなに増えるわけですが‥。目の前の課題を解きながら、将来の課題も想定して設計しようとする。それ自体は悪くない。でも想定上の課題を解くのに使う時間が、目の前の課題を解く時間より長くなってしまう。

過剰設計の傾向が強いと、どうしてもそうなってしまう。全体をどうつなぎ合わせるかを誰も見ないまま、モジュールに分割し続けることになります。

APIの場合はこれがより深刻で、実際の現場でのバグは、ひとつのAPIやひとつのコードパスに起因するものじゃなくて、複数のAPIの相互作用から生まれることが多い。「これをリリースしたとき、あれとどう絡むか」を誰かが見ていないと、問題になる。

Studio: そのまま下流に流れていく感じで‥。

Mike: デバッグも難しくなるし、本当に大変です。

こういうことは、生まれながらに知っているものじゃなくて、経験から学ぶものです。書いたコードがリリースされて、ユーザーがバグを踏む。それが最大の学びです。二度と同じことはしない、ということを学ぶ。

ブラウザエンジンに関わっている人たちの多くは、20年、25年やっている人たちです。彼らが仕事ができるのは特別な天才だからじゃなくて、それだけたくさん間違いを犯して、バグを入れて、直してきたから。だからたとえば「これはセキュリティ上まずいかも」という感覚が鋭くなります。

もういちどまとめると、仕様の品質の違いを生むのは、シンプルに保つこと。他の部分との相互作用を考えること。セキュリティリスクを考えること。APIのインターフェースを小さく保つこと。こういった原則を持っているかどうかだと思います。

これまでの人生と生活

Mike: ちなみに少し私の背景を話すと、私は大学で正式にコンピュータサイエンスを学んでいないんです。専攻は文学でした。

Studio: 文学ですか！へえ‥！意外でした。

Mike: ブラウザエンジンに関わる人の中には、CSを専攻していない優れたエンジニアが意外と多いんです。Eric Carlsonという人がいて、WebKitにvideoタグが初めて入ったとき、彼がメディア周りの実装を一人でやりきったんですが、専攻は音楽でした。彼は自分でやりたいことがあって、それを誰かに作ってもらえなくて、仕方なく自分でコードを書き始めたら面白くなった、というこの世界への入り方をしています。「この機械に問題を解かせられる」という気づきが入口になったという人は多いと思います。

もちろんChromeチームのように、StanfordのCS卒のような修士や博士がたくさんいて、アルゴリズムも完璧に知っている、というカルチャーもある。でも問題を解きたくて入ってきた、という人たちも大勢います。

私が最初に日本に来たのは2001年です。当時、日本以外の国にもモバイルフォンはありましたが、ボタンのついたポケベルのようなもので。ガラケー以前ですが、日本の技術は世界より圧倒的に進んでいた。来てすぐに驚きました。

当時Openwaveという会社にいて、WAPブラウザを作っていました。WMLというマークアップ言語で、ページサイズは20KBとか。制約の中での開発が楽しかったです。

最初に関わったプロジェクトがいわゆる「写メ」で、端末の写真をどうやってシェアするかという課題に取り組んでいました。SMSじゃなくてメールを使う、というアプローチでした。

ただ、大変だったのがシステムインテグレーターとの関係です。当時の日本の通信事業者は、既存のビジネス関係のある会社としか取引しない。大会社の事業部がシステムインテグレーターで、私たちはそこからサブコントラクトをもらう形でした。問題は、そのシステムインテグレーターたちが何をすべきかをわかっていなかったこと。ミスも多かったです。

Studio: 典型的な日本型の階層構造ですね。

Mike: そうなんです。そして私が知らなかったのは‥システムインテグレーターがミスをしても、責任は私たちに来る、ということでした。

だから謝罪会議に何度も出席しました。大きなテーブルが並んでいるあの形式の。前日に「マイク、明日はスーツ着てきて」と言われて‥。

本当に何度もそういう会議に出て、当時冗談で「Professional Apologist（謝罪のプロ）」という雑誌を作ろうかと思ったくらいです（笑）。

面白いのは、まったく関係のないプロジェクトの謝罪会議に呼ばれることもあって。「人数が必要だから来てくれ」というだけで、何も質問されないし、ただそこにいて、ちゃんとした格好をしているだけでいい。

Studio: 役職があるから、そこに立っているだけでいい、みたいな感じですかね。ここにいるメンバーの幾人かも、過去にそういう経験があるのでわかります。

Mike: そうですそうです。それを2006年くらいまで続けました。

2006年に転機があって、「PC Site Viewer」というものが出てきたんです。ある1機種だけに入ってきた、フルのOperaブラウザを搭載した端末でした。タッチスクリーンはなくてDパッド（十字キー）だけ、でも本物のブラウザでWebが全部見られる。私は「どうやってこれを実現したんだ」と本当に驚いた。当時のデバイスのRAMとCPUがどれほど制約されているか知っていたので。

Open Waveを辞めてOperaに移った友人が日本にいて、彼に「一体何をやってるんだ、すごすぎる」と言ったら、「来てよ」と言われて。それでOperaに入って、デバイス向けハンドセットの仕事をたくさんやりました。

ある仕事でよく覚えているのが、バグトラッカーの話です。優先度1〜4のうち、全部「優先度1」にする。他は使わない。結果、優先度1のバグが何百個もたまって、そのうち「優先度1より重要なものがある」となって、「優先度0」を作る羽目になりました（笑）。担当者がいつも言っていたのが、「このバグを直さなければ次の案件はない」という言葉です。毎回それを言われ続けていました。でも結局、次の案件もちゃんと来ましたけど。

Operaで働く中で、仕様や標準を作っている人たちの存在を知って、それがW3Cへの入口になりました。最初は「2年くらい経験してOperaに戻る」くらいの気持ちでした。本当の仕事ではなくて、一時的な寄り道くらいに思っていた。でもOperaの状況も変わったし、私自身も変わって‥気づいたら19年です。

「柔軟性」をとにかく大切にする

Mike: 日本に来たのも、実はそんなに計画的なことじゃなくて。最初の妻が日本人で、娘が産まれて、私はオースティンに住んでいたんですが、娘が2,3歳のときに別れることになって。彼女は横浜に戻って、娘を連れて行った。それで私も、娘が日本にいるなら日本に行くしかないと思って。仕事を変えて、交渉して、来られるようにするのに1年かかりました。その経緯でOpen Waveに入ったんです。時が経って、その娘も成人し、さらに時間が経ってすっかり大人になりました。

その後、今の妻と出会って結婚して、息子が生まれ、娘が生まれ、さらにもうひとり生まれて、いま家には子どもが3人います。

この生活が私に与えた影響は、「柔軟性」をとにかく大切にするようになったことです。子どもたちは午後2時頃に帰ってくる。家の隣に公園がある。仕事と子どもと遊ぶことを選ぶなら、ほぼ間違いなく公園に行きます。だから実質的に働ける時間は、子どもたちが学校にいる9時半から2時と、子どもたちが寝たあとの10時以降です。うちの子たちは夜ふかしなので、10時から深夜まで働く感じです。

収入はもっと稼ごうと思えば稼げるかもしれない。でもオフィスに行かないといけなくなるし、柔軟性が失われる。私は子どもたちや妻と過ごす時間のために、自分の生活を「設計」してきた。それが今の私には一番大事なことです。

Studio: 柔軟性を優先して生活を設計する。大事なことですね‥。これまでの経歴やご家族のことも含め、貴重なお話をありがとうございます。時間も残り少ないので、わたしたちの今取り組んでいる課題についても紹介させてもらっていいでしょうか？

Mike: ぜひ聞かせてください。できることは喜んで手伝いますよ。私はなぜかいろんなところへのアクセス権を持っていて、基本的に「後で謝る」哲学でやっています（笑）。怒られても「すみません」と言って、2週間後にまた同じことをする。

まあ怒られるようなことをしたいわけじゃないんですが、でも本当に、みなさんの仕事を進めたいし、ユーザーのためになることをしたい。みなさんは実際のユーザーの問題に直接向き合っている。私はプロダクトを直接触ってユーザーの問題を解けるわけじゃないから、そういうチームから話を聞けるのは本当に大切なんです。

（このあと、社内の課題についてディスカッションが続きました）

エンジニアとして大先輩であり、いまも現役でコードに向き合うマイクさんに、エンジニアリングや経歴について屈託なく話していただき、とても有意義な時間でした。好きな仕事だからこそ、安易な解決策に逃げず課題を見極めること。ヤクの毛刈りを楽しむこと。解決するために諦めないこと。家族や生活も大切にすること。そういう仕事をこれからも続けたいと思いました。
マイクさん、ありがとうございました！（エンジニア・マネージャー 中神）