略歴
大学卒業後、スクウェア（現 株式会社スクウェア・エニクッス）でWebアプリケーション系の技術調査に携わる。その後、株式会社オレガ（コンシューマー・ゲーム会社）、アトランティス株式会社を経て、株式会社Ｇｕｎｏｓｙに参画。取締役ＣＴＯに就任。
Q. 学生時代から技術の勉強をされていたのですか？
大学は文学部の言語学科でした。少しマニアックな一般言語学という分野で、言語の研究、言語の歴史、言語とはなんぞや、といったものをひたすら勉強していました。もともと中学の頃から英語が大好きで、高校の時にはフランス語を勉強し始めて、それから言語の世界にどんどんはまっていって、もう自分は大学では言語学を勉強するしかないな、と。大学入ってからも、外国語を三外、四外、五外、六外ぐらいまで。思いつくとマニアックにどんどん行ってしまうタイプでしたね。
プログラミングは、10 歳の時に富士通のFM-77AV というパソコンが家にあって、BASICをやりましたが、そこから先は難しくて分かりませんでした。大学に入った頃に、コンパイルする環境がほぼ無料になったこともあって、もう1 回プログラミングをやってみようかと思い立ち、2、3 年のときはプログラミングばかりやっていました。
Q. 卒業後に入社された会社は、開発者として入社されたのですか？
スクウェア（現 株式会社スクウェア・エニックス）というコンシューマゲーム会社に入ったのですが、そこでは開発職ではなく、主に技術調査の仕事をしていましたが、技術オタクの自分にはたまらない職場でしたね。勿論開発も開発で好きだったので、家でPerl を書いてみたりしてました。当時はホームページサービス的なもので動的なものがやりたかったらPerlのCGI 一択でしたね。で、CGIを色々と書いているうちに、Webの世界にとても興味が沸きました。僕らが最初に見ていた、それこそMozaicやNetscapeのようなものの中でアプリケーションが動くという感覚がこれからはごく普通のことになるんだなと思ったときに、これはすごく面白いなと。次はWebでアプリを提供している会社で働こうと決めていました。
2 社目は友人がやっていたオレガという会社に混ぜてもらいました、当時はエンタープライズ向けのメッセージングツールを作っており、自分はWeb アプリケーションに関する技術調査とパイロット版作りなどをやりました。ハイパフォーマンスI/O や、PKI などのセキュリティー関連の技術と、ゲーム会社のときのベースが役に立った画像処理などをやっていましたね。新技術の採用可否調査みたいなのは大体任されていたのでこの職場もものすごく楽しくまた勉強になりました。ただ所謂大規模Web サービスと異なって単位時間あたりのリクエスト等の性能はそこまで要求されることが少なくて、ネットで見るパフォーマンス・チューニングみたいな激しいやつがやりたいなーと思っていました。
その後ですが知り合いのつてでアトランティス（アトランティス株式会社・今はGREE 子会社）に入社しました。アドサーバというシビアな性能要件の塊みたいなものを作る作業は激しいパフォーマンス・チューニングを望んでいた自分にはまたとても刺激的で、ここもまた人生渡りに船であるなぁと振り返っても思いますね。
そこ（アトランティス）で知り合った木村氏とのご縁と、集合知プログラミングにすごく興味があったのもあり、その後、Gunosyにジョインすることになりました。オレガの退職時でしたが全社にオライリーの「集合知プログラミング」を配って回りましたね。なんで辞める奴が餞別配ってんのか意味わかんないですけど、これからはこうゆうのだよなーっ
て感じて思わず配っちゃいましたね。今でもあの行動は謎です。
Q. キュレーションサイトが最近いくつもできていますが、その中でGunosy さんはどのような方向性でキュレーションサイトを進めていこうとされていますか？
必要とされている問題は「ニュースに接触する瞬間をいかによい体験にしていくか」だと捉えています。
一般的なニュースも、自分が興味のある分野のニュースも、どういう理由で届いているとかは意識しないで読めるぐらい、キュレーション技術自体が溶けこんでしまっているのがいい状態なのかも知れません。「私はオススメされたニュースが見たい」みたいな需要というかそこに向けた意識のようなものはキュレーション環境が発達すれば発達するほど実は死んでいくのかなあと。
今だとトピックとマイニュースって、片一方は露骨にオススメ情報なのですが、別にそこはユーザの意図としてそんなに入口が違うのかなというと、実はそんなに違わないのかもしれないなという気がしています。キュレーションというのは、ユーザに良いニュースを見せるための一個の武器ではありますし、勿論われわれにとっては超重要な武器ではありますけれども、そこをあまり意識させるところとは逆に行くのかなというようなイメージではありますね。
Q. 技術的にはずいぶん難しそうですが･･･
技術的な難しさももちろんあります。でも、今はどういうのが楽しまれているかといった、割と実直なデータ分析をたくさんやって、次のアプローチを考えることに注力しています。計算は非常に潤沢にやっていますが、クラウド等のおかげでいくら回しても知れたコストです。だから、コストの心配をあまりしないで、好きなだけ、少しでも精度がよくなるようによいデータの洗練を続けていこうとしていますね。
だから、Gunosyは、アカデミックな集団がコンピューターでかっこよくやっている会社だというイメージがあるかも知れないですが、やっていることはもう泥臭い作業ばかりです。
でも、結局その面倒な積み重ねこそが参入障壁だろうと僕は思っていますね。より早くちゃんとユーザーに触れてもらうことと、あとは、たくさんのスタッフできちんと積み重ねをいくことで、データを取って分析していくことが今はすごく重要です。
Q. マネジメント側の仕事が増えると、プログラミングする時間が減ってきて技術者としては･･･というお話をよく聞きますが、石橋さんはいかがですか？
それはありません。コードも書いてますし、技術の勉強は夜、家に帰ってからすればいいですし、それは常にやっていないとスピードが追求できないと思っていますから。僕は「素振り」と言っているのですが、早い球が来たときに準備ができていないと、ヒットさせられないですよね。この新しい技術を使って作りたいと言ったときに、「これを使いたいと思います」ではなくて「これを使って作っちゃいました」くらいのスピード感が欲しいです。
そのためには、今どういう技術があって、何はどれをどういう風に使ったらできる、といった整理は基本的には終わらせておく必要があるんです。あとは、タイミングが来たらバーンと行く、という感じでしょうか。
ただ、そのインデックスは定期的に流行りが変っていくんです。常に流行りを追うこと自体は大して重要ではないのですが、エンジニアのモチベーションとのバランスを考えると、そこのインデックスは常に更新していかないといけないですよね。だから、速いサーバーを書きましょうと言ったら、タイミングによってNode.js だったり、Golang だったりと。
今はこれさえ押さえていればOK だという技術があるわけではないので、常にどういう技術が今あるかなどの情報をバランスよく取りながら、かつ、そこそこ手も動かせるような感じのトレーニング、基礎体力作りみたいなことは今でもやっています。
Q. そこまでスピードを重視するようになったのはいつ頃からですか？
どの会社でもスピードは大事でしたが、文字だけで説明するより絵があったほうがはやいし、絵があるより動くアプリを触ってもらうほうがはやいですよね。割とこれ使おうぜみたいな話を進めるときには特に稟議とかから真面目に入ると長かったり必要ないじゃん、みたいな話になりがちなので、既成事実的に「なんかへんなのが動いててべんり」みたいなものを晒しちゃうのが好きでした。（できちゃったプロダクトって呼んでます）
あとプロジェクト型のものは長期間かけて頑張って作っても、勿論うまくいったりうまくいかなかったりあるし、それは開発したもののせいだけではない要素が多いですよね。
しかも、ベンチャーの場合は、本当にもう手の数が尽きたら終わりだなみたいなイメージがありますよね。だから、何かしらの要因で数字が悪くなってくるかも知れないと予測したときとか、さらなる攻めのアプローチをとるムードになった時に、奥にいくつ飛び道具と近接武器とを持っているかというのはすごく重要だと思っています。
そのために必要なのが「その時点で」「何をつかえば」「何が」最速で実現できるみたいな知識のインデックスと、あと実際にそれをつかって作れる腕、ですね。この仕事をする上で必須のものだと思っています。
Q.社内のツールはどんなものを使っていらっしゃるんですか。
コミュニケーションツールとしては、Yammer とHipChat を使っています。GitHub は、今、割ともういいリポジトリ数になっていますね。あとQiita:Teamでエンジニアは情報交換しながらストックを溜めてます。うちは社内サーバーと呼べるものが殆どないんです。開発者が少し自由にいじくるMac mini が1 台あるくらいで、そいつは最近はHipChatに寿司画像を流すのが主務ですね。たまにテストビルドもしてくれるけど。社内サーバがない分、外部サービスは試験利用したり乗り換えたりいろいろ試します。
Q. クラウド上に置いて、どこからでもつなげて仕事できちゃうんですね。
そうですね。セキュリティーの観点から、できることに限りはあるようにはしていますけれども。
ただ僕が素振り好きなので基本エンジニアは早く帰ってもっともっと勉強して欲しいですね。なので自宅で仕事はしてほしくはないです。ただサービスやってるといろいろあるので、会社に来ないといけないみたいな状態にはしたくないなと思ってこのような感じに落ち着いています。
Q. 朝の8 時頃にアクセスが集中したりして、サーバーサイド側は大変ではないですか？
最初は大変でしたね。すごく大変でしたけど、一定のボリュームを超えてからはこちらも慣れてきたものなので。当初はAWSのプレウォーミングが足りてないのではとか諸々悩んでおりましたけど最近はもう自動的にスパイクする時間にアマゾンのインスタンスがぽこぽこ立ち上がって、スパイクが終わったらぽこぽこ落ちていくみたいな。それこそEC2っぽい使い方みたいなのをするようになって、特にピーク帯に苦しむみたいなことは減りましたね。
あとは、設計の方も割と大事で、基本的に何も書かないことにしています。データベースに書き込むのは非常に負荷の高い操作なので基本は読むだけ。あとは、ログだけ残して、そのログからフィードバック作るような処理の部分は、それこそアトランティスでサーバーをやっていたときのことがすごく勉強になりましたね。だから、最初アクセスが急激に増えてきたときに、取りあえずみんな書くのをやめよう、と。いかに書かないで情報提供できるかという部分を徹底してみましょう、と。それをやって、今はだいぶ快適になりました。
Q. シンプルさを大切にしようということなんですか。
そうですね。シンプルなのと、パーツが別になっていることですね。サーバーと、ログと、あとログを読むものというので。どこがどう不具合になるか分からないので、さまざまなデータに中間地点的なデータを保有することを許容しているというか、むしろ、好きなところでダンプが取れるような状態の方がいいなと思ってはいますね。効果的な側面ですが、一個のパーツだけある日突然、「きょうからScala 使いたいんだけど」と言ったら、じゃあ、ここのパーツ、ちょっとScala で書き直してみるとかできるじゃないですか。そういうのも好きです。
Q. 技術者の方々も、新しい技術が入ってきたときにすぐに実践できる環境があって面白いでしょうね。
面白いと思いますよ。僕のキャリアでは、使いたくても使えない環境は無くもなかったので、そういう制限がかかるのがすごく嫌だなと思っていたので、エンジニアからこれの技術を使ってみたいと言って来れば、二つ返事でやらせてあげています。その分、素振りしてなかったら鬼詰めしますけどね（笑）。
これは単なる僕の美学かも知れませんが･･･、このライブラリーって何だっけ、なんて、業務時間を使ってガイドから何時間も読んだりするのは、なんかイケてないなと思っています。もちろん、スタックオーバーフローで調べることはあるかも知れませんが、基本的には理解しているものとして、業務の時間最大限インプリとテストに活かしていくべきだと思っているので。この技術なんぞやみたいなことを調べている時間は無駄といえば言い過ぎですが、ピッチの上でやることではないなーと。僕は少なくともやりたくないですね。
Q. そこでもやっぱりスピードなんですね。
よくも悪くも、誰よりも早くそういう技術を使いたいエンジニアは、作り終わる前に次の技術を好きになっちゃったりもするんですが、それも多分スピードがあれば回るんですよ。その技術を選択したことはベストな解ではなかったかも知れないけれど、飽き切る前に作り終わってしまえばいいんです。
僕自身も、使えない技術などは特にないようにしていますし、あとは、ぶっ壊すのがすごく好きなんですよ。あまり深く深く作るの好きではなくて、新しい人が来たらその人向けにぶっ壊して作り直します、というくらいの浅さで作れる部分もあるぐらい健全だと思っています。
勿論ステージに依りますが、社内フレームワークで重厚長大にガシガシと作って文書化していくより、今あるよいものを集めてきて、割と薄めに作っておいて、個別に強結合にしない、というイメージです。そこはすごく大事だと思っています。
Q. 一流の技術者を目指す方々ににアドバイスはありますか？
やっぱりとにかく勉強することと、勉強したもので書いて作ることですかね。それを繰り返せば、割と何でもできるようになるし、本当に何でもできるようになると、そこからはエンジニアは超楽しいですよ。
採用する側からの意見としては、問題解決が得意なエンジニアも好きですが、問題領域を見つけるのがうまいエンジニアは僕はすごく好きですね。予め決められた境界線の中で最大のパフォーマンスを出してくれる人ももちろん嬉しい
のですが。そもそもどこのどの範囲に問題を設定して、その中で最適解を出していこうかといった、その外枠を引くのはなかなかできることではないと思うので。いろんな多くの次元にわたる問題を理解していないと、多分そこの線はきれいに引けないと思うので、そういう意味で観察力に優れていることが大事なポイントですね。素質としては多少はあまのじゃくなところとかがあるといいですかね。何か問題が出たときに、問題を真面目に解こうとする人と、この問題、なんか変じゃないかと思う人といるので。後者のイメージ。ここもバランスの問題であまのじゃく過ぎても微妙なんですけど、定律としてなんでも受け止めないで、多少の疑いはあるといいかも知れないですね。あとは、何度も言いますが、スピードですね。
Q. 石橋さんのエンジニアとしての一番の楽しさや醍醐味は何ですか。
達成感と、あと、昨日までなかったユーザー経験が作っていけるところです。例えばGunosyに関して言えば、「ニュースチェックなんてこれぐらいの時間で十分だろう」といった、ユーザーに時間の圧縮を提供できているわけで、これは多分それまでになかった新しい経験ですよね。経験を提案できるプロダクトが本来あるべきであって、使いたい技術を使うというよりは、実際に人間の一日をどう変えていくのか、という提案の部分の方が僕は面白いなと思っているので、それができた時が一番嬉しいです。僕らのミッションは「世界中の人に情報を効率的に届ける」ことだと思っているので、ユーザーの方から
この機能をこんな風に使っていますよ、とかこの機能でこんな面白いものを見つけられた、すごく楽にチェックできるようになった、と聞けるのはとても励みになります。
Q. 石橋さんにとってGunosyとはどんな会社ですか。また、今後どのような会社にしたいですか。
例えて言うなら「超巨大な遊び場」です。大好きな遊具があちらこちらにあって、砂場でも遊べるし、ブランコでも遊べるし。あ、技術が好きな人間なら、ですけど（笑）
これからも、エンジニアをいっぱい集めたいですし、彼らにとっても楽しい場所であって欲しいですね。僕らがお山の大将で、自分らは超楽しい遊び場だと思っていても、「あいつの島でつまらないな」みたいなのはやっぱりイケてないので。そうならないように、ミッションの共有とフェアなゲームのルールは必ず定めます。ありったけの技術を注いで、コンテンツを持っているメディアとそれを使うユーザーをいかにハッピーにするか。そのためなら技術は試し放題の使い放題ですからね。いかにエンジニアが自由に遊びまくるか、いかにスピードを出せるか、が常に最重要課題ですね。
