Twitter開発のテストはローカルで
西村賢氏（以下、西村）：Twitterって巨大な世界的企業で、一般的な開発と全然かけ離れているイメージがあったんですね。今ちょっと驚いたのがRailsでローカル環境でまだやってるということで、ローカル環境、例えば蓑輪さんも入られて最初、Macかなんかで開発するわけですよね。その上に開発環境を整える。
具体的に、例えばデータベースのところはどうするとか、結構この環境構築は大変なんですか、最近、その開発環境とステージングとプロダクションをなるべく近づけろとか、ありますよね、そういうトレンドが。そういう意味で言うと、ローカルTwitterが再現できちゃうというのは、不思議な感じなんですけれども。
蓑輪太郎氏（以下、蓑輪）：そうですね。設定自体はそんなに難しくないです。ローカルで開発できるメリットってやっぱり、閉じているので安全じゃないですか。Twitterの本番のユーザさんのデータを壊す危険を冒すわけにはいかないので、まずローカルで閉じて開発して、という感じ。
それは、Railsで開発されてる方ならメリットをお分かりになるのですけれども、そういうのも事情もあってローカルで仕事しています。
西村：ローカルで、例えばダミーのBOTがいて、勝手にに発言したりとか。
蓑輪：そこまではやってくれないので、自分で何個かログインしてツイートしてみたりとか。テストの環境はいろいろ整っているので、何人かのユーザがツイートしてみたり、テストで確認しています。
西村：Railsだと最近、大きなエコシステムでいろんなプラクティスがライブラリ、Gemが共有されていて、だいたい皆似たようなことやっているというような。例えばFactoryGirlを使っているとか、CIだったらTravis使ってとか、最近よくあると思うんですけれども。それは、Twitterも同じものを使ってたりしますか。
蓑輪：そうですね。CIはまさに、名前変わる前のJenkins使ってたりしますし、その辺は例えばGemとかも……ちょっとテクニカルな話になりますけれど、マスターをgit pullした時に新しくこのGem使うようになったよ、みたいなことがあって、そのGemを勝手にインストールするような。
西村：じゃあ、Bundlerとか使って。
蓑輪：そうですね。
西村：本当に普通にRailsですね。
蓑輪：Railsですね。
西村：そういう意味でいうとRailsのビュー、コントローラーまでがご担当されていて、モデルの部分はかなりすごいインフラがその先にある、って感じですかね。
蓑輪：そうですね、例えばユーザというモデルがあるじゃないですか、ユーザさんをあらわす。その辺はもう本当に裏はすごいインフラに繋がってますけれども、モデル一切やらないというわけではなくて、例えば新しい機能を追加するためにテーブルが必要です。そのテーブルはモデルで表現されますね、という時は自分でモデルをつくることはあります。
西村：そういう意味でいうとあくまでも今でもMySQLが後ろにあって、そこのシャーリングみたいなところまでは意識しなくてもいいけれども。
蓑輪：そうですね、MySQLを実際にテーブル作って、設計してみてみたいことはいまでもやってます。
西村：ものすごい普通のRails。意外な感じがします。
蓑輪：そうですね。
17時台には退社のため皆そわそわしだす
西村：勤務のスケジュールはどういう感じですか？
蓑輪：朝何時にくるかというと、だいたい僕は9時ぐらいに来て……1日のスケジュールについてざっというと、朝9時に来て、まずはメールを読み始めます。時差があるので、サンフランシスコから大量のメールが届いていて、朝までに……
西村：朝来ときには、向こうはだいたいどれくらいですかね？
蓑輪：朝来た時は、向こうは夕方5時とか6時という感じですね。そろそろ帰ろうかな、というぐらいの時間。なので、もしちょっと困ってることがあって、質問したいみたいな状況のときは、ちょっと朝早く来て質問します。
メールを見て、時差の関係上今返したほうがいいメールは早めに返して、同僚が帰る前に見てもらう。それ以外はとりあえずメモだけして保留にしといて、そこからコーディングを開始して、ひたすらコーディングとかですかね。あとは、タスク管理のための仕組みみたいのがあって……ちょっとツール名は言っていいのかわからないので。
西村：オリジナルのツール。
蓑輪：ではないですね。
西村：世の中でわりとある。
蓑輪：はい。それを使っていて、そこで今日はこれやります、みたいな。“今日は”というのはないのですが、今週はこれをやります、という感じで、
西村：スタートボタンを押すと、その人がオーナーになって、チケットで管理されて。
蓑輪：そうですね。そういう感じです。
西村：Pivotal Trackerとか使ったり……そんなことないか。
蓑輪：ではないですね（笑）。
西村：ちょっとあてずっぽうで言ってみました（笑）。
蓑輪：で、何もミーティングがない日は、開発してテストして、もしリリースのサイクルにいれるのでれば、ステージングにいれたりとか。
それ以外に、僕は本当にミーティング少ないのですが、週1、2回マネージャーと最近やっていることを深化するためにやっているような、それは、Skypeだったり電話だったり、あとは大きなことがない場合はメールでのアップデートで済ませる場合もあります。
西村：今、エンジニアリングというかコードを書く、エンジニアにとってはすごく幸せな。
蓑輪：そうですね。
西村：なるほど。夜はどういう感じなんですかね。皆さん。
蓑輪：僕はだいたい18時に帰る。で、向こうの本社に行っている時もだいたいシャトルバスというのが出ていて、シャトルバスで南の方まで帰る人達がいるので、シャトルバスが来る時間が決まっているんですね。例えば17時半にバスが来るので、17時半の便で帰る人はその先に行かなきゃいけない。
だいたいエンジニアの人たちは早く帰ったりする。遅くまで残ってる人はほとんどいなくて、だいたい17時とか18時くらいになるとそわそわします。
西村：シャトルバスは1時間に1本ですか。
蓑輪：17時半の便の次は、たしか結構遅い便ですよね。
西村：今Twitter社は、サンフランシスコの市内のど真ん中の、テンダーロインでしたっけ、サンフランシスコの市役所の裏側くらいの大きな建物に新しく移転されて、サンフランシスコから南にといったのは、シリコンバレーに住んでる方が多いんですね。
蓑輪：マウンテンビューとか、もともと例えばGoogleで働いていて、その辺に家がある人も大量にいるので。
西村：日本にいるとちょっとわかりづらいですけれども、東京～横浜まではなくても、それぐらいの感じで。
蓑輪：なんか1時間ぐらいかかるって言ってましたね。
西村：逆に今、サンフランシスコとシリコンバレーにシャトルが行ったり来たりして、若い人は市内に住んで、シリコンバレーに行ったりという。
蓑輪：そうですね。本当に若い方は、市内に住んでる方が多いですね。
Twitter入社に求められるのは「なんでも出来る」スキル
西村：ちょっとこれは、先程おっしゃった開発されているところからすると、少しずれてしまうのですけれど、最近Twitterの大規模機能処理系もすごくブログを見ていると、いろんな情報を出されてるじゃないですか。すごいなと思うんですけれど、そのへんのビックデータとか、そういう事を今後ぜんぜんやっていこう、とかっていうのは。
蓑輪：私ですか。
西村：ええ。
蓑輪：ビッグデータの定義によると思うんですけれど、つい先日も、とあるツイートのデータを集める、みたいな仕事は実際にやっているので、その仕事に必要があればウェルカムですね。
西村：じゃあ例えば新しく機能とか、UIを変えるという時に、自分でちょっと実際どうなの、と検証するとかっていうことは全然ありえる。
蓑輪：それは本当に可能です。簡単にできます。
西村：なるほど。どうしてこういうことを聞いているのかというと、ご覧になっている方で今後そういう、Twitterじゃなくても大規模なところとか自分の企業でチャレンジしてみたいな、と思ってらっしゃる方たくさんいると思うんですけれども、どういうスキルが求められているのか。
そのエンジニア、Twitterでやっていくんだったら、こういうエンジニア像みたいなものを思い描いていたほうがいい、とかありますか。
蓑輪：僕がTwitterに入るときに今の上司というか、エンジニアリングマネージャーの上田にいわれたのは、Twitterは歌って踊れるエンジニアがいいと。その意味は、何でもできると。上から下までなんでもできるエンジニア。
つまり専門性もあるのですけれど、僕はRailsできません、とか僕はJavaScriptできません、みたいな感じでではなくて、どこも1人でできるようなエンジニアが求められている、と聞いていて入ったのですけれども、たしかに僕もそうだなと思って。
例えば、何かを開発している中で、こういうデータが必要だからクラスタから取らなきゃいけないんだ、ということが発生した時に、僕はできませんよ、じゃなくて、どっちかっていうとやり方を教わる、っていう感じなんですね。文化として。
誰かにやってもらうではなくて、やり方を教わって、やる。そうすると次から自分でできようになるし、新しく入ってきた同僚にもやったことあるから教えれるよ、という判断になります。
あとはその仕事を進める上でプロジェクトがあって、プロジェクトはどんどん前に進んでいって、リリースされるのが目標じゃないですか。だから、前に進めるための力っていうのがすごい必要で、その中には、だいたい何でもできるよ、というスキルがすごい重要です。
ここできないからプロジェクト止まっちゃいました、とか、他の人にお願いしてる間は止まってしまいます、みたいなのっていうのは、やっぱり不利だなというのは感じます。
トップエンジニアと凡人の差
西村：このへんなんか社内で、同僚と呼べる方かどうかわからないですけど、他のエンジニアを見てみて、こいつはスゴいなと思うような人っていますか。具体的に名前を出してほしいとかではなくて、社内でのスキル差……と言っちゃうとあれなんですけれども。
蓑輪：それはもうゴロゴロいますね。なんていうか、みんな打てば響くみたいな感じで、エンジニアとしてこれぐらいの事はやって欲しいなっていうこと以上なものを、皆さん返してくれる。例えばコードレビューにしろ、質問したときにしろ、お互い仕事したときにしろ、本当に期待した以上のものを返してきてくれる人が多い。
西村：そういうと、さっきおっしゃっていた上から下までと言ってましたけど、このあとちょっとお話をお伺いしますけれども、ヒゲポンさんは本当に一番下までもぐって見たという感じですよね。
というのも例えば、OSを書かれたときも一番下のアセンブラまで落ちてCPUの命令とか特権命令とか、どうでしょうね、最近のWebエンジニアの方々だと、名前は聞いたことがあっても自分ではさわったことがない人が多いみたいですけど。
蓑輪：そうですね。
西村：その辺のことって、やっぱりこう長い目で見ると、直接・間接的に役に立ったりするんですかね。
蓑輪：そうですね。アセンブラレベルだと役立ってるとはちょっと言えないと思うんですけど、システムをブラックボックスとして見るか、中が透けて見えるかの違いはやっぱり大きいと思っていて。
物を作る上で、ある程度頭の中で計画を立てるんですね。この辺はこれぐらいの時間がかかって、この辺はこれくらいの作業量で、みたいな計画を立てるんですけれども、そこにブラックボックスが現れると、一応見積もりは立てられるんだけれども、トラブルがあった場合に、どれぐらい大変かというのが想像できない。詳しい人に聞くしかない、となってしまう。
そうではなくて、ブラックボックスなんだけどちょっと透けて見えていて、これちょっと見たことあるよと言うくらいならば、トラブルの時はこうしてこうして、あの人にこれをやってもらえばできるかな、みたいな。ある程度見積もりができるので、その辺でやっぱり一番下までもぐるというか、ブラックボックスがない状態というのは良いと思います。
西村：これよく、Rubyを作られたまつもとさん（まつもとゆきひろ氏）がおっしゃってるんですけれども、言語処理系がおすすめだっていうんですね。皆さんが思ってるほど難しくないので、ぜひ作ってみるといいですよと。言語処理系を1回作ると、あらゆるコンピューターサイエンスに関係するスキルが要求されると。ハッシュテーブルも自分で一回作るし、ツリーをどうする、とかいう話もありますし。
それと同じでなんとなくOS、アセンブラまで落ちると、私はOSとか当然作ったことないですけど、CPUだとCASとか、例えばロック、読む書くときの整合性の話とか、実はWebでもデータベースでも同じ話があって、そういう知識の概念的のところの学習、という意味でも役に立ったりするんですかね。
蓑輪：そうですね。今おっしゃってくださったように、その同期とか排他の問題でありますとか、あとは面白いのが、時間に対する考え方が変わるっていうところ。
それはなにかというと、OSはスケジューラーというのが動いていて、今はこの仕事をしています、今はこのウィンドウを出しています、今はブラウザが動いてます、みたいなものをぐるぐる回しているんですね。
それが何ミリセックごとにコロコロ変わって、そういう時間間隔を一旦自分の中に持つと、例えばWebの画面がリクエストされて表示されるまでに、例えば300ミリセックぐらいかかってるけど、そのうちここはHTTPのリクエストを処理して部分だから20ミリセック、データベースは何ミリセックっていう数値の感覚がわかるので、明らかにおかしい部分がわかるんですね。
例えばおかしいところがあるときに、データベースにこんなに時間かかってるのおかしいよね、HTTPのリクエストにこんな時間かかっているのはおかしいよね、とかそういう時間感覚が一番下からわかっているので、みたいなこともありますね。
西村：なるほど。例えば普通に使っているiPadとか、人間の流れる時間だけユーザは感じているけれども、中の実際のOSは細切れの時間を使っていたりとか、そのへんのことも1回やってみると全然違う。
蓑輪：はい。
西村：なるほど。
