Rebuild A Podcast by Tatsuhiko Miyagawa. Talking about Tech, Software Development and Gadgets.

0:00

miyagawa: 昨日、堀江さんに会ったんですよ。

naoya: おお。いつ以来ですか。

miyagawa: 会社やめてからなので、8年ぶりぐらい。っていうのを Twitter と Facebook に書いたら、いいね！がいっぱい来たから今日の Podcast は堀江さんだと思ってた人もいると思うんですけど(笑)

高林さんはこの前の回、言い残したこととかありますか？

satoru: いや、もう何喋ったかけっこう忘れてるので(笑)

miyagawa: ぼくはなんか、日本とアメリカのエンジニアリングで違うところありますか？ みたいな質問があったときに、あまり思いつかなかったので「ないです」って言ってたんですけど、でもけっこう違うかもと思ったのは、キャリアパスみたいな話で。アメリカだと、CTO がいつまで経っても一番コード書くじゃないですか。

satoru: ああ、会社によっては。

miyagawa: 本当に大きな会社はわからないけど、20人ぐらいの規模から100人ぐらいの会社になっても。でも日本だとその辺が、CTO って言ってるけどじつはそんなにコード書かないっていう人もけっこういるし、マネージメント層と、CTO に行くアーキテクト層がモワっとしてる感じがあるんですよね。

この間、日本からサンフランシスコに来た会社の人とちょっと話してて、求人広告で CTO または VP of Engineering 募集って出したんだけど、全然来ないんですよって言ってて。いや CTO と執行役員は全然違う職業だからねって言って。

satoru: エンジニアのままキャリアパスが続くみたいのが、シリコンバレーの方があると。

miyagawa: そうじゃないですか。

satoru: まあそうでしょうね。

naoya: 逆にそういう、日本の CTO 的な意思決定っていうか、たとえば技術ベース的な意思決定をするときに技術的な素養が必要になるっていうのは、向こうだと VP of Engineering がやる、ということですか。

miyagawa: いや、VP of Engineering は、ぼくが何人か一緒に仕事した範囲で言うと、超スーパーマネージャーみたいな感じで、技術に関する決定はしないですね。技術に関する決定は CTO がする。

naoya: フレームワークは何を使うとか、開発プロセスを標準化するような音頭を取ったりするのは CTO で。

miyagwa: 今の話で言うと、フレームワークがどうとかいうのが CTO で、プロセスの話になるとちょっとマネージメントというか VP of Engineering が入ってくるっていう。

naoya: 面接とかは？

miyagawa: そう、日米の会社で一番違うのは面接が違って。日本の会社はあんまりコードを書かせないことが多くて。あと面接も一回とかなんですよ。だけど、大体向こうの会社って、一日で朝から順番に5人とか4人とか。

naoya: え、じゃあ何、5時間とか。

miyagawa: そうですよね、大体。

satoru: まあ、1時間の面接を五つみたいな。

miyagawa: 順番にやっていくんですよ、一人ずつ。

naoya: 大変だな、それ。途中で帰ってください、みたいなことはないんですか。

miyagawa: 途中で帰ってくださいはないよね。

satoru: どうかな……。

naoya: よっぽどだとある？

satoru: かも。会社によるんじゃないですかね。

miyagawa: あとは何人か一緒にやるんじゃなくて、一人ずつやるから。で、インタビューする側も、一人ひとりが合間に情報を交換しないようにしてて。それをすると、先入観が入ってくるじゃないですか。あいつは駄目だったよ、とか言うと先入観で見ちゃうから、基本は最初にインタビューする方も前日とか朝に役割分担をしておくんですよ。そうしないと、5人来て5人に同じ話をされたら疲れるじゃないですか。

naoya: じゃあ、ぼくはアルゴリズムの話聞くね、とか。Webアプリの話聞くね、みたいな。

miyagawa: そうそう。そういう感じで分けて、それで終わった日とか次の日にフィードバックを出して、この人は OK、とか良くないとか。そういう感じだから。

naoya: そのときは CTO は面接するんですか？

miyagawa: それも規模次第だけど、どうかな。ぼくのときは、小さいときはしてた。大きくなってからはしてないかな。

naoya: なんか自分が過去にいた会社……っていうとどこだかわかっちゃうけど(笑)、CTO がけっこう採用に時間を使っていて。そういうのもあってあんまりコードが書けなくなっていった、みたいなことが背景としてありましたね。

miyagawa: そうなってくると、もうマネージメントになっちゃうもんね。

naoya: たしかに。

5:00

miyagawa: さっき直也さんが Twitter で書いてたんですけど、スクリーンキャストがけっこう最近……最近でもないけど、すごくいいなと思って。

naoya: 宮川さんよくやってますよね、cpanfile とか。

miyagawa: そう、ぼく最近たまに始めてて。まあ Podcast と同じ要領で録るんですけど。喋る代わりに、画面を出しながら喋るっていう感じで。とくに Rails をここ1年ぐらいやってたときに、「RailsCasts」っていうスクリーンキャスト番組があって、それがすごいんですよね。それを見ると大体わかるようになってて。その人がすごいのは、もう何年もやってるんだけど古いやつを定期的にアップデートしてるんですよ。アップデートしたやつを見るのは有料なんですけど。

だから、コードを本で読むのもいいんですけど、試しながら読みたいじゃないですか。だけど試しながら読むのはやりづらい。っていうときに、スクリーンキャストすごい良いなって思うんですけど。

satoru: ぼくは見たことないんですけど、そのスクリーンキャストっていうのは、映ってるテキストとかはコピペできるの？

miyagawa: ちゃんとしたやつ、その RailsCasts とかは、今回使用したコマンドとかいって、テキストがペーストできるようになってるんですよ。そうじゃないやつは、ただ画面に映ってるのを見て、ああこんな感じかなっていうだけなんですけど。

satoru: 昔、ぼく「ttyrec」っていう小さいツールを書いたんですけど。UNIX の端末で、ssh とかで入ってるやつをテキストとして録画できるみたいな。ほんとに一瞬だけ、小さな世界で盛り上がったんですけど、あれで田中哲さんっていう Ruby とかで開発している人が、何か送ってきてくれたんですよね、自分の録画している様子を。それはたしか ttyrec を OpenBSD か何かに移植してるっていう作業なんですけど、めちゃめちゃ速いんですよ。 Vi を立ち上げてタカタカタカって打って、ちょっとコンパイルして、みたいなのを、ものの1分とかなんだけど、なんか直しちゃってるんですよね。 OpenBSD で動くように。これはすごいと思って。で、後で本人に「これ何回も練習したんでしょ」って聞いたんだけど(笑)いや、そうじゃないって言ってたから。そういうの見ると、やっぱりびっくりしますね。

naoya: 昔 Ruby on Rails が出たときに、10分で Rails アプリケーションを作るっていう、それもスクリーンキャストだったかもしれないけど、そういうデモンストレーションが流行ったときに、なんか日本でもそれ Sledge で出来るよとか言って、livedoor の人がすごい頑張って10分に収めるっていう動画を作ってて(笑)めちゃめちゃ練習したとか言って。

miyagawa: あったあった。

naoya: あれすごい面白かったけど。でもそういう頃からね、動画でデモンストレーションするっていうのはけっこう見るようになりましたね。

miyagawa: ttyrec って、撮った後にチートできないんですか。ファイルをいじって、とか。

satoru: まあ頑張ればできますけど、そういう編集とかもできるようなツールはないから。

miyagawa: バイナリを頑張ってやるしかない。

satoru: そうそう。

naoya: あの宮川さんの動画って、撮る前にやっぱり練習するんですか。

miyagawa: 最初は、何回も撮り直したんですよ。どうしても途中で、ああ順序間違えたとか、コマンドをタイポして変なふうになったとかいうのを隠したいじゃないですか。だけど最近は、Podcast と一緒で、撮ってから後でカットすればいいやって思うようにして。本当に破壊的なコマンドを打っちゃったとき以外は、大体端末をクリアしてもう一回打ち直せば、間違えたところは適当に Video ソフトでカットすればいいから。っていう風に考えたら、あんまりミスを気にしないで打てるようになって。

naoya: この間面白かったのは、cpanfile か何かのスクリーンキャストで、モジュールをインストールしてたらけっこう時間がかかるから、途中で飛んで、これで終わりましたとか言って、料理番組みたいな(笑)もう出来たの用意しておきました、みたいになってて。ちゃんと編集してるんだなって。

miyagawa: あれ実際にインストールしたら5分ぐらいかかって。しかも PC がめっちゃうるさくなったんですよ。コンパイルしまくって(笑)その音も全部拾っちゃって。

naoya: けっこうあれですよね、打鍵音が聞こえますよね。

miyagawa: そう、あれはプロの人は、たぶん後からボイスオーバーしてるんだよね。でもそれだと、すごくやりづらかった。後で何言ってたか忘れちゃうし、タイミングが合わないから。本当はキーボードとマイクをちゃんと離してやるべきなんだろうけど、まあそこまではやらなくてもいいかなと思って。

naoya: ぼく最近、ドットインストールっていう田口元さんがやってるやつをこの間たまたま見たんですけど、それがスクリーンキャストでそういう、プログラミング入門みたいなことをやってるんですけど、よくこれ手順を間違えないで、最初からここにモデルを書いてビューを書いて、とかできるなって。

ぼくは普段プログラミングするときって、もっと試行錯誤がたくさんあって、ああこうじゃなかった、とかいって壊したりするんだけど、一切そういうことも無くやっていくから、かなり練習してるのか、田口さんがものすごく詳しいかどっちかだなと思って。

miyagawa: たしかに不自然ではあるよね。編集するファイルがどれとどれってわかって書いてるから。まあでも、悩んでる様子をスクリーンキャストするのも面白そうではあるけど、見てる方からすれば正解を早く知りたいっていうのもあるからね。

naoya: で、けっこうタイポするんですよ。とくに JavaScript なんかだと末尾のカンマを付け間違えたりとか、セミコロンのままにして、気づかないっていうのがひとつの動画の中で大体2, 3回やるんだけど、戻して、すぐ気づくんですよ。ああ、ここ、とか。だからだんだん見てるうちに、これももしかしたら芝居なんじゃないかって(笑)雰囲気出すために。

ぼくはもっとタイポすると、気づくまでに普通時間かかって。最近だともうそういうの面倒くさいから、Flymake とかに任せて頑張るようにはしてるんだけど。

11:30

satoru: 他人が作業している様子を、スクリーンキャストじゃなくても、リアルタイムとかでもペアプロミングみたいなので見てるとけっこう面白いですよね。

naoya: ペアプロだと、相手のタイポにすごい気づきますよね。自分も指摘されるんだけど、自分じゃ全然気づかないのであれは不思議だなと思って見てるんですけど。

miyagawa: あとペアプロとかやると、単純に知らなかったツールとかコマンドとかをすぐ学べる。なにそれ、みたいな。今何やったの、みたいな。

naoya: ぼく昔あれですよ、『Blog Hacks』書いたときに、宮川さんの画面見たら、なんか Windows なのに Emacs みたいな操作してて、何ですかそれって聞いたら、Keymacs っていう。まあちょっと古い話ですけど、教えてもらって。それを自分も入れたらそれまでのストレスが嘘のように解消して。こういうのってやっぱり、見て盗まないと絶対わからなかったなってそのときに思ったんですけど。

satoru: ぼくは逆の、逆というか、経験がありますね。ものすごい生産性が高いというか、非常に優れたプログラマーの作業している様子をしばらく見る機会があって。見ると、本当に普通のことしかしないんですよ。なんだけど、無駄がないから速い。

naoya: あるある。

satoru: デスクトップもキーボードも一切カスタマイズしてなくて、コントロールキーの位置とかもそのままで作業してて、全然速く見えないんですね。だけど的確に、ああここにブレイクポイントしてちょっと見てみよう、とか言って見るとたしかにそこでおかしなことが起きてて、じゃあちょっと直してみようか、みたいな感じで。本当に30分ぐらいでけっこう、ぼくが何時間もハマっていたような問題が解決しちゃったりして。まあ当然、その人もコード知ってるからっていうのもあるんだけど、無駄がない動きってすごいなと思って。

最近ちょっと聞いた言葉で、スポーツの世界ではベテランムーブっていう言葉があると。引退間近なんだけど頑張ってるスポーツ選手とかが見せる、無駄のない動きみたいな。それはそれでけっこう面白いなと思いました。

naoya: ぼく昔、剣道やってたんですけど、剣道って8段とかになると、みんなおじいちゃんなんですよ。で、そのおじいちゃんにピチピチの若者の十代のぼくが稽古つけてもらうんですけど、なんか全然相手動けないのに、いいようにいなされて、もうクタクタになるんですよ。だからその人もベテランムーブで(笑)、より最小の動きで最大の効果を引き出すみたいな感じで。

その話はでも、ぼくも感じたことがあって、昔はてなにいるときに Preferred Infrastructure の会社の人たちと一緒に仕事をしたんだけど、あの会社は競技プログラミング、ICFP とかに出て、世界大会に出たみたいな人たちがたくさんいて、その人たちがコードを書いてるのを裏で見たんですけど、すごい正確なんですよ。境界条件とか一切間違えないでバーってコードを書いていって。しかも打つのがめちゃくちゃ速くて。あと変数とかも、これはどうかと思うんだけど全部1文字なんですよ(笑)。だからいかに最小の打鍵で正解のプログラムを書くかっていうのを中高生のときから訓練してるからむちゃくちゃ速くて。

でもぼくは Emacs にいろんな拡張とか入れて、auto-complete とか Flymake とかやってるのに、その人たちよりずっと書くのが遅いんですよ。だからこれはどうしたものかなと思ったんですけど。まあ彼らの方は筋トレのたまものなので、ぼくはその道具を使ってドーピングするしかないのかな、みたいなことは思いました。

satoru: 直也さん最近、環境設定系のブログをたまに書いてますよね。

naoya: 書いてますね。

satoru: なんかああいうのを見て、中年の危機みたいなことを思い出して。

naoya: なんですか、それ(笑)

satoru: 中年になって俺もちょっと、若返らなきゃみたいな。スポーツカーをちょっと買ってみて、とか。オープンカーを買ってみるみたいな。そういうのにちょっと似てるのかなっていう印象を持ちましたけど。

naoya: それは何、ディスられてるの？ ぼくは今(笑)

satoru: いや、非常に素晴らしいことだと思いますけど(笑)

naoya: そうですねえ。大体ああいうのをやると、時間の投資に対して、最後に残るのはたぶん20%ぐらいなんですよね。いろいろ新しいツールに手をつけてみるんだけど、使い始めた当時は「おお、これ便利」とか言ってすごい頑張ってキーバインドとかも覚えるんだけど、3日、4日するうちにそもそもそれを入れたことすらも忘れて。でも、それでも使い続けてるツールっていうのも時々あるんですよ。そういうのを積み重ねて、老いと戦うっていうのがこれからの人生ですかね。

miyagawa: たしかにずっと使い続けたものを抜けるのは難しいですからね。 Emacs とか、捨てたいと思ってもう5年、6年ぐらい経ってるけど捨ててないですからね。

naoya: Emacs ね……いつまで使うんでしょうね。って、この話題定期的にこの Podcast で出るんだけど(笑)

satoru: ぼく昔、「デフォルト教への道のり」っていうのをどこかで書いたんですよ。ブログかな。カスタマイズにすごい時間食っちゃって、肝心の作業が全然進んでないとか、現実逃避みたいな感じで一生懸命環境整備やっちゃったりとか。環境を一生懸命整えたんだけど、結局次の日になると使ってないみたいな。

そういうことを踏まえて、投資効果の高いものを見分けるのが重要というか。ほとんどのことが投資効果は低いので、非常に慎重に選ぶのがよい、みたいなことを昔書いた気がしますね。でも、相変わらず自分の zsh の設定とか見ると100行ぐらいあったりして、あんまり説得力がないみたいな。

naoya: でも大体ああいうのは、ブログとかで他の人が使ってるのを読んでも、便利かどうか今いちよくわからないんですよね。

miyagawa: わからないですね。

naoya: で、実際に使ってみたら、これものすごく便利、みたいなものも時々あるので。そういう魅力というか、なんか捨てきれないというのが「デフォルトじゃない教」の悪いところだと思うんですよね。

satoru: 宝くじみたいな感じですかね。

18:45

miyagawa: じゃあ、ちょっとここでスポンサーを紹介したいんですけど。この番組にもスポンサーがつきまして。 iOS のアプリの『Listen-IT』っていうソフトなんですけど。この Podcast を聴いてる人は技術系の話とか、こういう Podcast とか興味あると思うんですけど、一回目に直也さんともちょっと話したことで、日本だと最近 Podcast とか廃れてるからあんまりないんですけど、海外だと英語の Podcast はけっこうあって。でも英語の Podcast を聞こうっていっても、聞くのはちょっと大変かなっていうのがあるんですけど。

日本人はけっこう英語を中学・高校・大学で学んでいるので、読み書きはけっこうできるというか、エンジニアの人でも、情報収集はけっこう英語のマニュアルとかあるからできると思うんですけど、海外に出張に行ったときとか、海外から来たエンジニアと話すときとか、なかなか英語を聞き取るのが難しいっていう人は多いと思うんですけども、この Listen-IT というアプリは音にフォーカスしたアプリなので、発音を聴いて、母音編と子音編と文章編っていう三つあるんですけど、それぞれ20個ずつぐらいレッスンが入ってて、音を聴いて、これはどっちの音か、みたいなのを当てていくクイズというかゲーム系の感じでなってて。

たとえば……(実演)こういう a と u の発音とか。日本人にはすごく難しいと思うんですけど。こういうのを聴いて当てていくっていう。

satoru: a と e が合体してるみたいなやつ。

miyagawa: そうですね。ただそれだと、学校で教えられることと変わらないじゃん、って思うかもしれないんだけど、これを作っているのはシリコンバレーで働いている日本人と、元々ネイティブで ESL (English as a Second Language)の教材とか作ってる人が作ってるから、学校と教わるのとは違う感じになってて。

あと面白かったのは、リンキングっていうのかな。ある単語が子音で終わって、次の単語が母音で始まると、繋がるじゃないですか。英語で普通に話してると。そういうのってただ読んでるだけじゃどうなってるかわからなくて、話されると全然わからないとかあると思うんですけど、そういうのもあるし。

ぼくが昔、出張で初めてアメリカに行ったときに、ミーティングみたいなのがあって。それはプロダクトのミーティングだったので、コンテキストはわかってるから大体単語はわかるんだけど、一箇所わからないのがあって。「ダラーバックス」って言ってるんですよ。で、アメリカ人はドルのことをバックスって言うって聞いてたから、ダラーバックスってお金の話かなと思ったんだけど、全然話とは違うんですよ。ダラーバックスのレイアウトが、とか言ってるから。それが後から聞いたら、「ダイアログ・ボックス」だったんですよ。

satoru: ああ。わからない。

miyagawa: 何でこういうことが起こるかっていうと、これのレッスンに入ってるんですけど、英単語にいくつも母音があるときに、メインじゃないところは全然発音しなくなるんですよ。とくにアメリカ英語の場合は。そういうのが、自分の勉強する教材の中ではなかなかないので、面白いなと思って。

そういうソフトなので、もし聴いてる方で興味のある方がいたら、アプリ自体は無料なんですけど、実際のレッスンは一個900円でトータル2700円なんですけど、今日この Podcast が配信されて皆さんが聴いている頃には40%オフで、全部セットで1200円で買えるようになってるので。一週間だけのキャンペーンらしいので、今すぐ買ったらいいんじゃないかなと(笑)

naoya: Listen-IT。

miyagawa: Webサイトは http://www.listen-it.com/

Podcast の Show Notes からもリンクしておくのでそれでもいいですし、iOS で「Listen-IT」って検索しても出てきます。スポンサーありがとうございました。

satoru: アメリカ人のエンジニアと喋って最初に気づいたのは、ハイフンって言わないんだなって。

miyagawa: ダッシュ。あとはシャープ(#)がパウンドとかハッシュとか。イギリスはパウンドで。ハッシュタグとかのハッシュですね。

……っていうことを、ブログでぼくが書いてたじゃないですか。

satoru: ああ、だから覚えてたんだ。

miyagawa: ソフトエンジニアリング英語とかいうので、ぼくが3回ぐらい書いて。高林さんが真似して始めた方が続いてたんですよ。

satoru: でもたぶん、4回ぐらいしか書いてないと思うんですけどね(笑)

miyagawa: けっこうね、ここ最近3, 4人ぐらいから、あれをまた再開してくださいよっていうのが来てて。Kindleとかで本になったら、買いますっていう人がけっこういて。

naoya: ああ、売れそう。

satoru: それでまたやる気が高まる、みたいな。書く気が。

miyagawa: あの時もブログに書いてたら、何社かから本にしませんかっていう話が来てたんですよ。そのときは仕事が忙しくてできなかったんですけど。

naoya: それにあれ付けてほしいですね。 ChangeLog のための、コミットログのための英語。なんか独特じゃないですか。

satoru: 人によってスタイルが違うというか、普通に命令形で Fix 何とかって書く人もいれば、Fixed っていう人もいて。

miyagawa: 命令形というか現在形ですね。主語省略の。

satoru: そうそう。Fixes っていう人もいるし。一貫性があまりないですね。

miyagawa: ぼくはコミットメッセージは過去形が好きだったんですけど、何かの記事で現在形にすべきだみたいなのがあって、ちょっと説得力があるなと思ったんですよ、そのときは。だから最近は現在形にするようにしている。

naoya: 現在形と過去形のそういう形式とか、いろいろあるんですけど、普通によくある言い回しってあるじゃないですか。バグを直したとか、バージョン上げたとか、タイポ直したとか。そういうののちょっと凝った版ってあるじゃないですか。あそこの処理がちょっと遅かったけど、この方が速くなると思ったからこうしてみた、とか。

satoru: たしかに。それが50パターンもあれば全部っていう。

naoya: そう、大体網羅できるみたいな。そういうポケット・ハンドブックみたいのがあったら、けっこうぼく買うかもね。

miyagawa: それいいですね。

satoru: じゃあ今日、ぼくが帰ってから(笑)

naoya: Web で探すんですけど、ちょっとしたのは見つかるんだけど、ある程度まとまったのがなくて。あったらいいなと思っているんですけど。

miyagawa: たしかに Fix a bug とか最低のメッセージですからね(笑)

satoru: え、なんの？ っていう。

miyagawa: 困ったときやっちゃうから。Fix, Fix, Fix って。

naoya: Update, Update とか。

satoru: ぼくは hoge っていうのを書いたんですよ。エンジニアリング英語だか、宮川さんに影響されて自分もちょっと書いたときに、hoge っていう言葉について書いて。hoge って日本人はよく使うけど、これは本当は英語では「捏造する」みたいな意味があって、間違って解釈されちゃうから気をつけましょうねって。そういうことをエイプリル・フールで書いたら、けっこうみんな騙されてました(笑)

---

Transcribed by Hiroaki Kadomatsu http://d.hatena.ne.jp/note103