++
2008年9月2日（日本時間9月3日）、ChromeのWindows向けβ版が公開された。
当時、Googleが独自ブラウザを開発していることはトップシークレットだった。取るに足らない小さなリーク記事を除いて、当日まで完全にこの事実は社外には伏せられていた。
Chromeの公開はサプライズの形で行われる予定だったが、Chromeの開発経緯や技術を解説したコミックが誤って一日早く送付されてしまったため、慌てて一日前倒しでアナウンスをした。私を含む日本側スタッフも慌ただしく対応したことを思い出す。
Googleはどうやら本気だ。独自のChromeブラウザをマンガ付きで発表 | TechCrunch Japan
Googleはその時のことをブログで次のように書いている。
At Google, we have a saying: “launch early and iterate.” While this approach is usually limited to our engineers, it apparently applies to our mailroom as well!
いわく、「Googleにおいて、"launch early and iterate"（早くローンチして、反復して改良する）という格言がある。通常はこのアプローチはエンジニアにのみ限定されるが、我々のメールルームにも適用されてしまったようだ」
周到に準備されたはずのものが、ふとした手違いで予定より早く公開されてしまう。
そんなことは人生で一度くらいだろうと思っていた。
ゲーム
人生ゲームというゲームがあるくらい、人生をゲームに例えられることは多い。
「おはよう」さあ始めようか
ゲーム開始のファンファーレ
(PLAY / SEKAI NO OWARI)
まだ今と比べると小さかったGoogleに入社したのが9年前の2006年。検索やマップなどですでにネットユーザーには欠かせないサービスとなっていたが、会社そのものは外からは良く分からない。その得体のしれない会社が気になって気になって仕方なかった。
幸運なことにそのGoogleに入社して、いろいろなことを経験した。ここ7年ほどChromeの開発を担当。
Chromeを発表したときには、何故いまさらGoogleがブラウザを開発するのかと聞かれていたほどだったが、その後、ウェブ技術は息を吹き返し、アプリケーションプラットフォーム技術としてさらなる発展を遂げている。このような技術の新しい流れを作るチームで働けたことは本当に幸運だった。
ゲームで言えば、1つのステージをクリアしたか、もしくは1つの隠し部屋の中は探し尽くしたくらいは出来ただろうか。
999
さあ行くんだ その顔をあげて
新しい風に 心を洗おう
偶然なのだが、私は9年ごとにキャリアチェンジをしている。社会人として最初に勤めた会社*1に9年、そして次のMicrosoftに9年。Googleに勤め始めたころは9年も勤めることは考えていなかった。もっと早く辞めることを考えていたわけではないのだが、自分がちゃんと務まるかもわからない状態で9年という長期間を考えられるわけもない。
ただ、去年くらいからだろうか。そろそろ9年になるなと気づいた。プロジェクトになんら不満もない。だが、自分のキャリアを考えなおすには良いタイミングとなった。
いろいろと考え、多くの人に相談した結果、退職し、新しい道に進むことになった。目の前には多くのチャレンジがあるだろうが、不安よりも新しいことを始められることにワクワクしている。
++
先ほど引用したSEKAI NO OWARIのPLAYでは、少し変なゲームで失敗を繰り返し、魔法の呪文は無いかと探す主人公に、次のように書かれた呪文の書が渡される。
「冒険の始まりは君の中の
ここじゃないどこかへと行ってみたい気持ちだから
どんなに険しい道に阻まれようと
その気持こそが君の使える魔法だよ」
(PLAY / SEKAI NO OWARI)>
「ここじゃないどこか」は私にとってまったく新しい環境です。
Incrementsに入社しました。これからもよろしくお願い致します。
経緯などについては、Techcrunchに記事にしていただいたので、そちらをご覧ください。
なお、この記事を「未来日記」の形ですでに見てしまっていた人もいるかもしれません（なので冒頭のエピソードを紹介しました）。私としては、二度あったので、三度目もまたいつかあるのかなと思っています ;)
話が見えない人は気にしないで大丈夫です ;)
あと、会社からのブログもあります。
- provided courtesy of iTunes
- provided courtesy of iTunes
社会システムや業務の改善にソフトウェア開発的思考を用いる
ソフトウェア開発、すなわち、アジャイル開発プロセスやアーキテクチャ設計、UXデザインなど、における発想をソフトウェア開発以外に用いても役立つことは多い。
少し前になるが、ある事業の相談を受けたことがある。ここではそれを架空のコンビニ事業に置き換えて説明しよう。架空なので、現実的ではない部分も多いが容赦願いたい。
コンビニ各社は店舗で買い物するのが出来なかったり、店舗を訪れるのが面倒に感じる顧客のためのデリバリーサービスを持っている。このデリバリーは実際はいわゆる通販であり、宅配ピザのように短時間で配達されるものではない。だが、ここでは例として、コンビニがある特定の商品に限っては極めて短時間で配達するというサービスを展開していると仮定する。また、（出来るだけソフトウェアとは遠い処理の例にするため）注文はコールセンターで電話で受けるものとする。
この短時間での配達を約束している特定商品を「アルコール飲料A」とし、配達サービスエリア内であれば5分で配達することをコミットしているとする。5分でなくても、3分でも10分でも良いのだが、普通に考えると実現が難しいような時間を想像して欲しい。
おそらく普通のオペレーションはこうだ。
- 顧客がコールセンターに電話をかける。
- コールセンターのオペレーターが電話を受ける。ここから5分以内に配達を完了させるというタイマーがスタート。
- オペレーターはコンビニデリバリーのコールセンターであることを伝え、顧客の住所や氏名を確認する。
- オペレーターは顧客からの注文を受ける。
- オペレーターは顧客に注文を再確認する。
- オペレーターは顧客との電話を終了し、注文をシステムに入力する。
- 注文に「アルコール飲料A」が含まれていた場合は、その商品だけを別便で至急届けるように、店舗または配達員に通達する。
- 配達員により顧客宅へ配達される。
わざと少し冗長にしたが、まったく最適化をしていない場合はこのようなオペレーションになっていてもおかしくない。
このコールセンターと顧客との対話やコールセンターからシステムへの入力、さらにはシステムから配達員に連絡され、配達が完了するまでの流れは、ウェブシステムにおけるブラウザとサーバー、そしてバックエンドからDBにデータがエントリーされ、処理が完了するまでと極めて類似性が高い。
処理速度が最優先されるシステムであれば、多少のコストは許容される。となると、少なくとも次のような最適化は考えられる。
オペレーターは顧客の住所を確認するのと同時に、「アルコール飲料A」が含まれているかどうかを確認する。ここで、もし含まれていた場合には、それをシステムに入力し、その地域の配達員に短時間配達のリクエストが入ったことを伝える。配達員はその商品の手配と顧客宅までの最短ルート確認、場合によっては実際に移動を始められる。その後に、オペレーターは氏名や他の注文を確認すれば良い*1。もしかしたら、その後の顧客とオペレーターとの対話で注文が取り消されるかもしれないが、処理速度を最優先する場合にはこのくらいの無駄は許容する*2。
この高速化技法はブラウザのプリフェッチの処理と同じだ。見ているウェブページにURIが埋め込まれていたら、それらをバックグラウンドでDNSプリフェッチ*3し、ユーザーがクリックする前に名前解決は済ませておく。Chromeでは検索結果からの表示の場合にはバックグラウンドでレンダリングまで済ませておくこともある*4。もしユーザーがそれをクリックしなかったならば無題になる処理であるが、高速化がそのコストよりも優先される場合にはこのような選択がされるのだ。
配達がどのように行われるかは、在庫をどこに置くかと、配達員がどのように配置されているかに関係する。簡略化のために、配送センター → 店舗 → 配送車または配送バイクという流れで商品は流れていくものとする。配送車が担当エリアを常に回遊し、必要な在庫を常に積んでいることがもっとも速く配達を完了することに繋がるが、この設計はキャッシュヒット率を高め、ディスクのシーク時間を短くすることと同じだ。配送車の配置と店舗により在庫を補充するタイミングが鍵となるだろう*5。
このような最適化は机上でシミュレーションすることも可能だ。その結果を見て、さらに最適化の余地が無いかを考えると良い。実際、GoogleはChrome OS/Chromebookを発表した際に、蓋を開けてから10秒でインターネットにアクセスできるようにすることを宣言したが、そのためにはファームウェアからChromeの起動プロセスに至るまで多くのところでマイクロ秒の最適化を積み上げて、その10秒を実現した。
社会システムや業務においてもこのようにソフトウェア開発的思考が活かされることは多い。ソフトウェア開発経験のある人は、開発以外の身の回りのオペレーションもソフトウェア開発的視点で見直してみよう。もっと最適化できるところもあるだろう。
*1:間に合えば、他の商品の配送も配達員に伝えれば良いし、そうでなかったら別便とする
*2:投機的実行
*4:インスタントページ - Google Japan Blog: 検索をもっと便利に、もっと速く
*5:ここには宅配業者にすでに確立されたノウハウもある
エクスビジョンに遊びに行ってきた
今日はマイクロソフト時代の上司である加治佐さんにお会いしてきた。現在はエクスビジョンの取締役をされている。
無職になったので遊びに行って良いですか*1との依頼を快く聞いていただいた。
まずはオフィス見学。普通のマンションの部屋と言ってもおかしくないような部屋を2つ借りている。とてもハングリー感あふれていて、気持ち良い。近いうちに引っ越して1つにまとまるとおっしゃっていた。
エクスビジョンの代表取締役がマイクロソフトディベロップメントの代表取締役をされていた藤井さんだということは事前に知っていたが、他にもマイクロソフト時代に見た顔や元同僚が何名かいた。日本のマイクロソフト出身者でスタートアップに行く人は少ないかなと思っていたが、最近はそうでもないようだ。良いことだ。
さて、このエクスビジョンは東京大学石川渡辺研究室で開発された超高速ビジョン技術を応用した製品を開発している。ジェスチャーシステムをデモして頂いたが、Kinectなどでは不可能な高分解能により両手でのツーフィンガーUIを実現していた。
このデモ動画でもわかるように、右手と左手がそれぞれ2つの指となる。まず、顔が認識され、その状態で手を顔の横に挙げることで、手も認識される。手を閉じる（軽くつまむような）動作でタップに相当するイベントが発生する。手の移動はそのまま指の移動となり、スマートフォンではスワイプに相当する動作となる。
現在のシステムはCMOSカメラですべて処理しているため、Windowsやスマートフォンなどに接続した場合はただのHID（Human Interface Device）となり、ホスト側の負荷はまったく無い。また、手での動作はツーフィンガーとしての動作に置き換えられるので、アプリケーションなどに手直しは必要ない。また、100〜120fpsという高分解能を実現しているため、細かな動作も認識される。
デモでは、Windows 10とAndroid*2での操作を見せて頂いた。自分でも試させてもらったが、少しコツがいるものの、操作は極めて直感的だ。緊張してしまったため、空中で手を動かすのに疲れてしまったが、慣れると多少長時間でも特に問題ないとのこと。
今年のゲームショーにも出展されていたようで、その時の記事がいくつかサイトからリンクされていた（以下参照）。確かにゲーム分野での利用はすぐに思いつく。後は、サイネージか。
SXSWにも出展していたようで、その時の様子のビデオを見せてもらったが、米国人の子どもたちにも評判は良かったようだ。
この超高速ビジョン技術をさらに進めると、人間の目では判断できないような素早い動きも認識できるようになり、工場や社会システムなどでの応用も可能だろう。期待したい。
スタートアップの脅威の一つは感染症
最近、東京をベースにしたスタートアップのオフィスに遊びに行くことが増えている。
会社によっては、広々としたオフィスにゆったりと席を配置しているところが無くも無いが、多くは人口密度が極めて高い。財政的なゆとりがない（あっても、オフィススペースに資金を回さない）かオフィススペースの拡張が人員増加のスピードに追いつかないのだろう。
このような環境だと、一番怖いのはインフルエンザとかの感染症だよね、と一緒に訪れた友人と話した。確かに少数精鋭で事業を進めるスタートアップにとっては、人材が一番の重要だ。数人の社員がしばらく稼働できないだけでも大変な事態になりかねない。
感染症が怖いのはスタートアップに限らないが、スタートアップで特に心配なのは、人口密度が高いところが多いのと、業務に対するモチベーションが高いのが逆効果となり無理に出社してしまうことが多そうだからだ。
インフルエンザやノロ、O157などの感染症の初期症状を社員全員に理解させ、少しでも疑われる場合には自宅待機。リモートワークを認めておくことがここでも役に立つだろう。罹患していた場合には医者から出社して良いとの許可が出るまでは出社を許さないくらいの強いルールが必要だろう。
何よりも、自分1人の感染が、無理な出社によって会社全体に広がる可能性があることを徹底する必要がある。
そのあなたの行為はバイオテロだから。
これを標語にしても良いくらい。
寒くなってきました。インフルエンザの予防接種はもう済ませましたか？
参考：感染症だけでなく、社員の健康管理が企業の経営の根幹にもなってきているようです。
Twitterの★が♥に
Twitterの★が♥に変わった。「お気に入り」という機能が「いいね」に変更されたわけだ。
すでに巷ではいろいろと騒がれているので、何か書くには出遅れ感があるが、少し思うところを書いておきたい。
私は以前、以下のようなブログ記事を書いていた。
これは「お気に入り」という曖昧な名前と機能について考察した記事だった。当時は、ツイートを（ブックマーク的に）記録するという用途のために「お気に入り」捉えており、永続的か一時的かという記録期間で使い分けがまだ定まっていないと書いていた。
それからしばらくして、今回、公式にこの機能は「いいね」であると決められ、名称もアイコンも変更されたわけだ。私の考察とは異なり、単なる感情を表す機能と再定義された。正直、「お気に入り」という名前はブラウザのそれを想起させ、ブックマークとして利用していた人も多かったのではないかと思う。
提供側の意図はわかるが、この変更は結構悩ましい。
一度、曖昧な形で提供し、利用者にその意味合いや使い方を委ねていたものを、今になって用途を明確にしても、それは支持されるだろうか。関連サービスなどもあったろう。
支持されるも何も変更されたので、感情を表現する機能として使われていくようになるのだろうが、一度提供した機能を再定義することの難しさと是非を考えさせられる。
