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

0:00

miyagawa: いやー、サンフランシスコ寒いんですよ、急に。今朝とか、マイナス3度くらいあって。

naoya: マイナス！？結構ですね。

miyagawa: 40年ぶりの最低気温記録を更新したらしいっすけどね。

naoya: へー、東京は逆に今年、夏が100年ぶりの暑さ。

miyagawa: 暑かったのがね。

naoya: まずは天気の話題から入る。

miyagawa: 雑談ポッドキャストですよ。

naoya: 雑談ポッドキャスト。今日はあれですよね、第1回みたいな感じで。

miyagawa: そうそうそう。特に「この話をしましょう」みたいな感じで、ゲスト2人とかでやる回とかもあっていいんですけど、そうじゃないのもいいかな、と思って。

naoya: ただダラダラしゃべる。

miyagawa: ダラダラっていうか（笑）

naoya: テーマ決めてね。

miyagawa: そうそう。

naoya: はい。

0:56

miyagawa: 今、ドラクエに忙しいんじゃないですか？

naoya: そう、昨日ね、ドラクエ10出てやってたんですけど。

miyagawa: あれってバージョンアップするってことなんすか？

naoya: 拡張ディスクが出て、ちょっとおっきめの変更が入るっていうんで。バージョン2が出て、忙しいっすね（笑）

miyagawa: （笑）

naoya: これあんまり言うと、ドラクエやるためにいくつか予定を「空いてません」とか言ってるんで。ばれちゃうんで（笑）

miyagawa: もう既にばれてると思うけどね。

naoya: 昨日もあんまり Tweet してなくて。「やってます」とか言うと、「なんだよあいつ、こないだ断ったくせにゲームかよ」みたいな。

miyagawa: それあるよね。先週ヨーロッパ行ってきたんすけど。デンマークとドイツとロンドンに行ってきて。ドイツでケルンとか、ハイデルベルクとか古城があるとこに行ってきて。もう完全に世界観がドラクエだったんで。

naoya: （笑）

miyagawa: とりあえず写真撮って「これ完全ドラクエだわ」って言ってて。それを Facebook とかにポストすると、「いや、ドラクエがそうじゃなくて、もともとドラクエが真似たんだから」って。

naoya: （笑）当たり前だけどね。

miyagawa: 結構面白かったですね。

naoya: なんでヨーロッパへ？

miyagawa: カンファレンスで。コペンハーゲンの Nordic Perl Workshop っていうカンファレンスと London Perl Workshop で。同じ Carton の話をしたんですけど。招待されたというよりは、ちょうど一週間おきにやってたから「ちょうどいいや」と思って参加して。一応スポンサーの人から宿泊費と飛行機代をちょっとだけ補助してもらったんすけど、それ以外は自腹で行った感じですね。

naoya: へー、すごいな。ついに世界を股にかける、ついにっていうか前からですね。

miyagawa: いや、結構ネタがあるとね。Carton とかのネタは日本とかではみんな結構知ってる人が多いと思うんすよね。Perl デベロッパー界隈では。でも、アメリカの小さい都市の Workshop、OSCON とか、ヨーロッパのそういうところで話すと、そこまでフォローしてる人も少ないんで。割とどんどん新しい人を拾えたりとか、逆に今まで使ってなかった人が発見があって色々フィードバックもらえたりするんで。1個のネタで何度もおいしいっていう。そういう使い回しが出来て結構いいですね。

naoya: なるほど、確かに。

miyagawa: そういえばどうでもいいんですけど、ドラクエの iPhone アプリが出てたじゃないですか。

naoya: あれでしょ、操作性が、って大激論になってたやつ。

miyagawa: そうそう。でも、ちょっと1時間くらいやったら割と慣れましたけどね。

naoya: そうそう。その「1時間やれば慣れるよ」派と、「FF とかで頑張ってスマホでもやりやすいように築きあげてきたのに」って怒ってる人たちと、ネット上で議論してましたけどね。今日もインターネットは平和だなぁ、と。

4:25

miyagawa: （笑）これ、基本的には有料でやるアプリなんだけど、最初に無料化してランキングをブーストさせるっていう今流行りのやり方なんすかね。

naoya: 今流行りというか、ソーシャルゲームとかがそういうのを当時からやってて。ちょうど僕が GREE にいたときにそういうのがすごい流行ってて、最初に無料でいろんなアプリをバンバン配ってトラフィックを貯めこんでおいて、本命を出すときにそっから一気に誘導かける、みたいな。

miyagawa: うーん。若干チートっぽい感じもありますけどね。

naoya: なんか、今度ドラクエの 8 が出るんですよ、スマホで。多分、それのための最初の人寄せじゃないかな、っていう。

miyagawa: しかもあれですよね、1個1個のタイトルが別アプリなんじゃなくて、1個のアプリのなかから In-App で買わせてローンチする。

naoya: そうそうそう。

miyagawa: ずっと残るんですよね。

naoya: なんかね、昔からその議論ずっとあって。個別にアプリを1個ずつ配布したほうがいいか、なかでアドオンみたいな感じかって。アドオンの方が当然、1回獲得したユーザーをそのまま流せるっていう利点はあるんだけど、結構難しい問題もあって。まず1つは App Store とか Google Play の規約に引っかからないようにするのに色々と小細工が必要なんすよね。ソフトウェアのなかで動的に全然違うものをダウンロードさせるのとかダメだったりするんで。

miyagawa: 基本的に、これってプラットフォームを販売してるようなもんっすもんね。

naoya: だから多分、今回は「ドラゴンクエストシリーズ」だからみたいなものだから、そういうのが通ってるのかもしれないけど。基本そういうことやると大体リジェクトされちゃうんすよね。あとは、容量の問題とかね、色々あるんですけど。

miyagawa: iOS7 になって In-App の容量とか結構緩和されたんじゃなかったですか、確か。

naoya: そうなんだ、そうかもしれない。

miyagawa: もしかしたら違うかもしれない。3G でのダウンロードの条件が緩和されたってのは読みました。

6:25

naoya: なるほど。最近あれなんですよね、新しい iPhone とか買うと全部 4G とかで回線も普通にブロードバンドみたいに速いから、気になんなくなってきちゃったんですよね、そういう話が。昔と違って。

miyagawa: あんまりね。

naoya: だから逆に、こないだ MBaaS、Parse.com の話をしてきたんですけど。その時のスライドで、Parse.com ってリージョンが東京にないからレイテンシーの問題があるんだけど、モバイルって別にレイテンシー気になんないよ、って話をしたんですけど。後日よくよく考えると、最近回線すごい速いから、そのうちモバイルでもちゃんと気にしないといけなくなるかもしれないなぁ、と思ったりとか。

miyagawa: その、naoya さんの言ってたのは、元々モバイルだから回線自体にレイテンシーがあるからサーバー側がどこにあろうとそこは誤差の範囲だよ、みたいな前提があったけど。

naoya: そうそうそう、段々ね。レイテンシーに関しては色々あるんだろうけど、なんにしてもそういうとこが改善されていくじゃないですか、今後。

miyagawa: うんうん。

naoya: だからそのうち、モバイルだからバックエンド遅くてもいいよ、っていうのはそうじゃなくなるんだろうな、と思って。

miyagawa: 確かにね。

naoya: ってぐらい速くなりましたね。

7:45

miyagawa: 確かにね。僕はその、ドラクエの話題引っ張りますけど、Android で Nexus5 でやろうとしたら、僕の持ってる Nexus5 にはインストールできなくて。

naoya: え、なんで？

miyagawa: なんでかっていうと、僕の SIM カードはアメリカの T-Mobile のが入ってるんですけど、Google Play Store のリージョンの分け方ってちょっとわけわかんなくて、アカウントに紐付いてるのか、SIM カードに紐付いてるのか、IP アドレスに紐付いてるのかってのが、ちょっと謎なんですよ。

naoya: うんうん。

miyagawa: 大昔は、入ってる SIM カードによってストアアプリを開いた時のデフォルトが変わってたので、日本に行った時に日本の SIM カード挿して開くとダウンロード出来たんですけど。最近は多分アクティベートされた瞬間にアカウントとデバイスに完全に情報が記録されちゃって。僕の Android では開けないっすね。Apple みたいに1アカウント1ストアっていう風に完全に別れてればいいんですけど、デバイスにその情報残っちゃってるんでダウンロード出来なくて。しょうがないと思って iPod touch でやってるんですけど。

naoya: （笑）そうなんだ。ドラクエの話題が。

miyagawa: なんか、ドラクエ1とかって完全に懐古ゲーだから、僕みたいなアクティブなゲームをやらなくなった人にはちょうどいいというか。昔やったゲームなので懐かしさっていうのはもちろんあるんですけど、何がいいかって「このゲームはこういうもんだ」っていう期待値が完全に自分のなかにあるんで。裏切られるってことはあんまないんですよね。

naoya: すげーわかる。

miyagawa: （笑）naoya さんみたいにアクティブにゲームしてる人はすごいと思うのが、最近のゲームって大作とかが多いから、買ってやり始めたらそれなりに時間食うわけじゃないですか。

naoya: そうなんすよね。

miyagawa: それ、投資に対しての見返りがあるかどうかが判断できないっていうか。

naoya: （笑）

miyagawa: それに対してコケたときの憤りがすごいおっきいだろうな、って。

naoya: いや、それあるある。すごいありますよ。なんだっけな、ちょっと作品名出すとあれだけど。最近それのためにゲーム機、パソコン買うみたいな感じくらい投資したんですけど、やったら2週間くらいで飽きちゃって。

miyagawa: それ多分ブログ見ればわかるんだよね（笑）

naoya: （笑）20万近い投資をして、2週間でゲームしないっていう酷いことがあって。

10:20

miyagawa: いやー、それ似てるなぁと思ったのは、新しい技術、テクノロジーとかでも、プログラミング言語とかに投資して見返りが得られるかどうかがわかんないのと似てるなぁ、と。

naoya: （笑）

miyagawa: 無理やり繋げてるわけじゃないんですけど。

naoya: そういうこと言い始めると「老害だ！」みたいな。

miyagawa: 「老害だ！」ってなるけどね。

naoya: 若い人は瞬発力でなんでもいじるけど、みたいな。

miyagawa: 前もこの話しましたけど、そういう意味ではスクリーンキャストとかは勉強するという意味でもそうなんですけど、15～20分とかの動画見て、この言語とか環境とかはこういう使い方するんだなっていうのが自分の手を動かさずにわかるっていうのは。

naoya: （笑）なるほどね。

miyagawa: だからゲームでいうところの実況プレイ動画みたいな感じですよね。こういうもんなんだ、面白そうだ、って言ってやってみる、みたいな感じかな、と思いましたけど。

naoya: なるほど。

miyagawa: 無理やり繋げてしまったけど。

naoya: 今日はこんな感じで最近話題になったことで面白いことを挙げていく、と。

11:30

miyagawa: なんか、こないだ2個前のエピソードで Immutable Infrastructure の話ししましたけど。これすげー噛みやすいんで注意して発音しなきゃいけないんだけど。

naoya: うんうん。

miyagawa: 多分、日本の DevOps 界隈っていうのがあるのかどうかわかんないっすけど、そういうとこで初めて話題に大きく上がったのがそれだったと思うので。多分この1ヶ月弱くらいで色んな人が Immutable Infrastructure について話したがっているっていう。

naoya: そうですね。

miyagawa: 現象が見受けられて。多分、一番面白いなと思ったのが、「Immutable Infrastructure とは何か」みたいな定義をみんなしたがるんですよね。これにはどういうメリットがあって、どういう問題点を解決するのかっていうのを、基本的にはみんな同じなんですけど。なんか、「それは Immutable のスコープではない」みたいなのをみんな定義しだして、それが面白いなぁ、と。

naoya: ちょっと突っ込みどころがある方がみんなが話題にしてバズりやすいっていうのは。「クラウド」とか「DevOps」とかもそうだけれど。

miyagawa: そうだね。

naoya: そういうとこちょっとありますよね。

miyagawa: あと、盛り上がってるところの原因の1つだと思うんですけど、デザインパターンとかと同じで今まであったものに名前をつけるとみんなそれが空気かのように扱い始めて。

naoya: そうそう。

miyagawa: それが当たり前のような空気が醸成されるっていうところが割と面白い感じかなって。なんか mirakui さんが Twitter に書いてたんですけど。

naoya: あ、そうそう。それ僕と mirakui さんでその話をしてたんですよ、ちょうど。

miyagawa: 実際に話した時に。

naoya: そうそう。

miyagawa: 「インフラ界隈のエンジニアは高齢化してきていて、抽象化や体系化はベテランの得意とするところ」（笑）

naoya: そうそう（笑）なんかね、前誰かがブログにそういうこと書いてたんだけど、要は若い人はおっさんのこと老害老害って言ってるけど、おっさんは脳がそういうハイレベル、抽象レイヤーの高いところで脳内で別の概念を結びつけて新しい体系を作るっていうのが若い人よりもすごい得意なんだ、みたいなことを。それは社会実験か何か、そういう論文があるらしいんですよね。っていうのもあって、「最近 Immutable Infrastructure っていうのをそういうおっさんたちが騒いでる」って。

で実際、mirakui さんは結構若いんだけど、それ以外の Immutable Infrastructure について熱く議論してるメンバーって、だいたい僕らと同じアラフォーかそれより上の人が多いんすよね。あと AWS のカンファレンスとか行くとやっぱり平均年齢高いんですよ。インフラとか昔からやってる人たちだから。だから逆に「これ触ってこれ面白かった」とかじゃなくて、いきなり概念レベル、抽象レイヤーから入って、みたいなのがちょっとあります。

miyagawa: （笑）その、ツッコミビリティが高いっていう意味で言うと、Immutable Infrastructure のブログポストとかも、「こういう新しい概念があるんだ！」っていう定義の仕方ではなくて、今まであったものに名前をつけただけなんだけどね、って書いてはあるんだけど。こうやって盛り上がってくると「いやそれ、今まで Heroku とかでずっとやってたし」とか「うちそれずっとやってるよ」とかツッコミをしたがる人が結構いて。

naoya: すごいわかる。僕自身そういう風に思いましたからね。Immutable Infrastructure て初めて聞いた時に、これ僕らがずっとやってたことに「俺たちがよく知ってるんだぜ」みたいな感じで言ってて、「おいおいちょっと待てよ。俺にも一言いわせろ」みたいな。

miyagawa: そうそうそう。結構こういうマーケティングの仕方ありかもしんないね。今までみんなが当たり前のようにやってきたことに大層な名前をつけてマーケティングするっていう。

naoya: でも、DevOps とかそうだったし。なんだろ、最近プルリクエストで GitHub 使って開発してテスト自動化して云々っていうベストプラクティスみたいなのあるじゃないですか、開発プロセスの。

miyagawa: うん。

naoya: あれ今は名前ついてないけど、あれも Web 開発やってきた人たちにとっては「あるある」みたいな。

miyagawa: 確かに。

naoya: リーンスタートアップ。

miyagawa: MVP とか。

naoya: そう、本読んだ時に、すごいふつうのコトしか書いてなくて。これ、今まで自分たちがやってきたこと単に本にしただけじゃん、みたいなことを思ったんだけど、それが多分重要なんすよね。

miyagawa: 重要ですね。

naoya: そうじゃない人たちにとっては。だから、そういうものが話題になったり流行りやすいっていうのはありますよね、特に最近。

miyagawa: 年取るとそういうのに名前付けたがるっていうのは、それがどんどん進化していくと若者のやってること理解できないからとりあえず。

naoya: （笑）

miyagawa: 現象に名前をつけてわかったつもりになるっていう裏返しなのかもしんないけどね。

naoya: あまり認めたくはない、とか。

16:55

miyagawa: あと、mirakui さんが Amazon の Re:Invent のイベント行ってきたっていうまとめみたいのもあって、そこで1個面白かったのは、"Stop Worrying about Prodweb001" っていうプレゼンがあって。要はサーバーに名前つけるのやめよう、みたいな話ですよね。

naoya: あれ面白かったですよね。タイトルが面白かった（笑）

miyagawa: そうそう。結構「わかるわかる」って話なんですけど、開発環境とかローカルの、会社に置いてあるマシーンとかはみんな名前つけるじゃないですか。通りの名前、星の名前、紅茶の名前とか。オフィスでいうところの会議室の名前とかとおんなじような感じで名前をつけていて。

naoya: miyagawa さんちなみにマシンなんて名前つけてます？

miyagawa: 僕はね、地名ですね。

naoya: 地名？

miyagawa: ラップトップとかの場合はそのマシンを買った時に務めていた会社のオフィスの場所とか、ハックしていた場所の名前とか。なんとかストリートとか。今は家に Mac Mini があるんですけど、それは Harrison っていう名前で、僕が昔住んでたストリートの名前なんですけど。今の会社支給のマシンは命名ルールがあってそれに従ってついてるんで味気ないんですけど。そういう感じで今はやっていて。昔 livedoor にいたときは、社内のマシンは剣の名前で、ブレードとか。SAKっていうのが一番強いマシンで、スイスアーミーナイフっていうマシンが。

naoya: （笑）全部入り？

miyagawa: 全部入りっていう意味。これは弾さん命名なんで。

naoya: そういうのありますね。

miyagawa: だけどね、プロダクションにはそんな個性的な名前はいらなくて、ロールというか app001 とか db002 とかつけるのが多いんだけど。この人の発表は「そういう名前はそもそもいらない」と。

naoya: それすらいらない、と。僕もはてなにいたときに、近藤さんたちがやってたときから峠の名前だったんっすよ。自転車好きだったから。

miyagawa: はいはい。

naoya: 僕全然わかんないけど、「なんとか峠」っていう峠がいっぱいあって。さっきのスイスアーミーナイフじゃないけど、峠マニアに置いては「この峠が一番重要」みたいなのがあって、僕が全然わかんないから適当に峠の名前からつけると、「いや、そのサーバーの役割上はその峠の名前じゃない」って。

miyagawa: （笑）

naoya: そんなの全然わかんないよ、ってのがあったんだけど。多分何百台とかになってきたときに、そろそろ峠の名前が足りなくなってきたのと、全然覚えらんないから意味ないよね、ってなって。仮想化したときにロールごとに web001 とか bookmark とか diary とかつけるようになったんすよね。でも、そういうことをしてもインフラごと捨てちゃうから、そんなことして管理するのはもう終わりだっていう話。

miyagawa: そうですね。基本的には EC2 とかでインスタンスにタグをつけられる機能があるので、DB のロールがあったら DB のタグをつけていて、ホスト名はなんでもいいじゃん、っていう感じですよね。

20:28

naoya: そうそう。ただそれ、普通に考えるとインフラすぐ廃棄しちゃうから、 Immutable とか Disposable だから、ホスト名にそんな重要な意味を持たせてもすぐ変わっちゃっうっていうのも1つはあるんだけど。もう1つの側面として、仮想化しててサーバーすごい沢山扱うじゃないですか。そうすると、サーバー一覧みたいなのを把握してカチッと情報を整理して管理してくっていうのだと、その情報を維持するコストが大変になっちゃうから、Google みたいなのって「何があるからわかんないから」って取り敢えず全部検索可能にしといて、ある程度カオスを管理するっていうんですかね、そういう風に変えていこうぜって話でもあると思ってて。

特に Facebook とかだとサーバー台数が10万台とか、もっとあんのかな。そうすると、どこにどういうサーバーがあって、どれが壊れててどれが動いててとかいう情報を誰か人間で把握しきるなんて絶対無理だから、DB 構築して検索して、「壊れてるの何台あるかわかんないけど、大体このくらい壊れてます」とか、そういうモヤっとした感じで生き物みたいに管理するっていう感じになるんだろうな、と思ってて。

miyagawa: こないだの mizzy さんの話に似てると思うんすけど、そういうサーバー一覧の情報とかってスタティックなデータではなくて、どんどんデプロイしてオートスケールとかで増やしたり減らしたりとダイナミックに変わっていくカオスなものなので、そこに番号が振ってあることに特に意味はないっていう。

naoya: そうそうそう。

miyagawa: そういうことですよね。

naoya: これ前に Chef の勉強会を日本でやった時の話で、Chef に Orchestration のところで Chef Server だと Chef Client がサーバーを自動的に見に行って、サーバーに上がってる Cookbook を自分で勝手に自分に適用する、みたいな機能があるんですよ。

miyagawa: うん。

naoya: その話をしたときに、「そんな、ある日突然、オペレーションしてる人たちが知らないのに、サーバーが自分自身で設定書き換えて動いてるなんて信じらんない」みたいな反応が結構あったんすよね。確かにそれはすごいわかるんだけど、それこそ Facebook みたいに10万台みたいなパラダイムを逆に想像すると、そうじゃないと多分やってらんないと思う。

miyagawa: やってらんないね。

naoya: 多分、そういう分界点がどっかにあって、規模的な。それこそオートスケールするとか。

miyagawa: やっぱり、これがクラウドのやり方というか。ハードウェアを自分で購入して、とか、サーバー管理台帳みたいなのがあってそこに稟議書発行してセットアップしてファックス送って、とかそういうことやってたら。

naoya: （笑）

miyagawa: ダメだよ、ってことですよね。

naoya: なので、どっかでパラダイムを変えましょう、って話かな、と。

23:33

miyagawa: で、Docker の話は引き続き盛り上がってるんですけど。Google Compute Engine っていうのが一般公開されて。

naoya: そうそう。

miyagawa: Google Compute Engine は Google App Engine とはレイヤーが違うというか、Google App Engine は PaaS、Platform as a Service なので、色々アプリをプッシュしたらそれを動かしてくれて。あとは Big Table みたいな API とかもあったりするんすけど。Compute Engine はもっと下というか、IaaS ってことでいいのかな？

naoya: うん。

miyagawa: EC2 みたいなものですよね。で、そこにサポートしてる OS が色々あるんですけど、CoreOS っていう Linux ディストリビューションがサポートされていて、CoreOS のやろうとしてることは色々あるんですけど、その中の1つに Docker の container をネイティブでサポートしてるってのがあるので。Docker で作ったアプリケーションを自分の Vagrant のうえで動かしてもいいし、Linode にイメージを作ってプッシュしてもいいし。ちょっと管理するのめんどくさくなったら Google Compute Engine にプッシュして動かすことも出来るっていう。どんどんアプリケーションがポータブルになるだけじゃなくて、インフラも含めてポータブルになっていくっていう感じですね。

naoya: そうそう、これは結構面白いっすね。しかも Docker について最初に話題にしたのってまだ半年も経ってないと思うんだけど。

miyagawa: ないと思いますね。

naoya: 数ヶ月前、4ヶ月前とかっすよね。この4ヶ月位でこの勢いで普及して。いや～、なんかすごいことになってるな、と思ってみてました。

miyagawa: 確かに。Google 自体も Docker 的なツール、LMCTFY、 "Let Me Containerize That For You" っていうソフトウェアを出してるんですけど。これは Docker よりかなりローレベルな、LXC のラッパーみたいな感じだったんすけど。やっぱり Docker のね、LXC をうまく抽象化したというか、ここまでポータブルに出来るっていうのは割とすごかったんだろうなぁ、と。

naoya: やっぱりあれっすよね、色々その後も見て、こういうことに使えるとか、それこそ Immutable Infrastructure の話題とかになってって、重要だったね、と。LXC っとやっぱり AUFS がセットになってるっていうのがとにかく重要ですよね。履歴を途中で全部管理してて再生可能にするってところが。

miyagawa: そう、LXC とか cgroups とか、そういうローレベルなテクノロジーで Jail 化されたような仮想化環境を作って Linux のなかで動かすっていうのに、ファイルシステムとかイメージの状態を管理するっていうのがくっついていて、それが API として提供されてるっていう、そこがいいんですかね。

naoya: そうそう。結局、そういう風にカジュアルに上げ下げできると、どうしても途中の状態をどっかで記憶しといて、それをコピーして使いまわすみたいなことがしたい、っていう当然の話があって。昨日も、ほら、Jenkins って前のテストの状態が残って他のテストがコケるみたいなことあるけど、そういうのをクリアにするために Jenkins のテストを Docker でやりたいけど、VM だと時間かかっちゃうから Docker で、って話を書いてた人がいて。

miyagawa: そうだね。

naoya: そういうことをやろうとすると、逆を言うと Docker でテスト、ここまでセットアップできてればここから先はテストに使えばいい、みたいな。途中の状態をどこで保存しとくか、みたいな話があって、それが AUFS がセットになってるおかげですごく簡単に実現できるのがものすごく大きいと思ってて。

miyagawa: 多分、Jenkins のテストを Docker で動かすっていうのは最初に Docker の話をしたときにしていて。今実際に見てみたら、Jenkins のプラグインとか結構出てるみたいなんで、そこら辺も普及してきてるとは思うんですけど。一昨日かな、Twitter で話してて「違う発想だな」と思ったのは、CPAN Testers っていうのがあって、CPAN にモジュールをアップロードするといろんな環境の人がインストールするときにテスト走らせてくれて、その結果をメールとかで送ってくれて DB になって集積するんですけど。

基本的には Continuous Integration に似てるんだけども、実行環境がエンドユーザーのところになっているっていう。分散されて、しかも特定の OS ではなくて Windows もあるし Mac もあるし Linux もあるしっていう。そういうところでテスト出来るのが違うんですけども、一番の大きい違いは Travis とか Jenkins を Docker で動かすとかいうと、完全に Immutable な環境なので、今言ったみたいに前のテストの結果が添付ファイルに残っていてその結果こけるとか、そういうのが防げるというメリットはある。

つまり、自分のプロジェクトをテストしたいのに全然関係ないところでコケてうざい、っていうのを解消する意味ではすごくいいんですけども、オープンソースのモジュールを CPAN で出した時に、「このモジュールが入っているとコケる」とか、そういうのが Immutable な環境では再現することが出来ないんですよ。

naoya: （笑）逆にね。

miyagawa: だから、「この OS で lib なんとかが入ってるとコケます」とかそういうのは、そういうクリーンな状態でテストするとわかんないんで、そういうのわかるという意味では Immutable じゃない環境でテストできるっていうメリットもあるのかな、っていう。

naoya: 確かにね。ただそれは、それはちょっと逆説的すぎるっていうか、理想的な状態に持ってこうとすると Immutable な方がいいんであって。その前の過渡期からそういう環境が必要とされてるけど、みんなが Immutable になったらそもそもそういうものがほんとに必要なのかっていうのはちょっとありますね。

miyagawa: まぁね。オープンソースとかの場合だけかな、必要悪みたいな感じではあるんだけど。

naoya: うん。まぁ、ありますね。あれみたいな感じですね、「汚い町で育った人間は免疫力がすごいついてるから、その後もすごい強いんだけど、東京みたいに清潔な町で育つと変なアレルギーを持ちやすい」みたいな話があって。

miyagawa: 子どものときから動物園に連れていくとなりにくい、みたいな話ですね。

naoya: Immutable Infrastructure みたいなのが進み過ぎると、アプリケーションが若干脆弱になって（笑）

miyagawa: （笑）確かにあるかも。

29:55

naoya: でね、ちょっと無理やり AngularJS の話を結び付けたいんですけど。要は、Immutable Infrastructure が、今の話もそうなんだけど、すごい勢いで進化してるじゃないですか、この数ヶ月間で。だから、最近インフラレイヤーってのがものすごくホットなんですよね。これ、stanaka さんがブログにも書いてたけど、その要因の1つとして AWS が一気に流行った、普及したとか色んな背景があるんだけど、何にしてもものすごい話が速いと。

で、一方フロント側も、Angular とか JS のフレームワークとか進化が速くて。これは多分 HTML5 とかモバイルとかが牽引してるんですよね。ただなんか最近、僕が観測範囲が狭いだけかもしれないけれど、真ん中ってあるじゃないですか、僕らが一番得意だった分野。サーバーサイドっていうか。そこがちょっとなんか、テクノロジー的にそんなにホットな話題が今ないのかな、って気がしていて。だから、僕最近よくカンファレンスとか行って話すんですけど、AngularJS の話をした次の日にインフラの話をしていて。なんかこう間(あいだ)がなくて前と後ろしかなくてすごい脳みその切り替えが大変なんですよ。

miyagawa: いわゆるフルスタックエンジニアってところで言うと、フロントエンドからインフラまでって考え方だと、両極端のところは「話して欲しい」って需要があるんだけど、真ん中の方は「MVC で Rails とか使えばいいよね」っていうか、あんましその辺が変わらないよね、っていう話ですかね。

naoya: だから、Rails がある程度その辺の問題を全部解決しちゃったっていうことなのかもしれないし、逆に、モバイルになってネットワークの向こうじゃなくてフロントエンド側になるべく計算処理を寄せていってユーザービリティをあげましょう、みたいな考え方になってるから、サーバーサイドの色んな凝ったテクニックが必要なくなってきてる、みたいなのもあると思うんすよね。だから、そういうのも含めて、唯一 Go が盛り上がってるところはあるけど、ただ Go もどっちかっていうと DevOps とかそういうもうちょっとレイヤーの低いところで盛り上がってるんで、ほんとに Web アプリケーション作る、みたいな面でのサーバーサイドっていうのが、ここ半年、1年くらい面白い話がないなと思って。

miyagawa: しかも極端な話すると、サーバーサイドいらないっていう。MBaaS とか。

naoya: そうなんすっよ。

miyagawa: クライアントサイドを使ってアプリを作った時にデータどこに保存しよう、とかが、今までだったらサーバーサイドエンジニアの力、腕の発揮どころで API デザインして DB モデル作ってとかやってたんだけど、MBaaS で、Parse とか Dropbox とか使って、iCloud とかも一応あるけど、そういうので全部 Key-Value Store で保存して。それでプッシュは全部サーバーに送ってもらえばいいし、っていう。

naoya: そうそう。

miyagawa: そういうことになると、あんまり出番がなくなってくるっていう可能性もありますよね。

naoya: うん。なんかそういうこともあって、最近はフロント周りが、一方で、話すことが多いんですけど。全然僕フロントエンジニアではないのに。なぜか AngularJS とか JS の話ししてて。

miyagawa: Angular はテックトークみたいなので入門的な話をしてましたけど。

naoya: そうそう。

miyagawa: かいつまんで言うと、AngularJS はどういうもんですかね？

naoya: かいつまんで言うとねぇ。難しいとこなんだけど、あれですよ。Backbone.js とか、いわゆる MVC フレームワークとは結構違うんですよね。最初「そういうものかなぁ」と思って触り始めたんだけど、実際 Angular って HTML を拡張して動的なアプリケーションに対応できるようにするフレームワークというかプラットフォームというか、そういうもんなんですよね。で、Backbone はどっちかっていうとプログラムの構造化に力点が置かれているから、JS で普通に書いてるとグローバルでべたーっとしちゃうのをちゃんと MVC に、MVC じゃないか Backbone の場合は。ちゃんと役割に分担しましょうっていうのを強制する感じなんですけどね。

miyagawa: うん。Angular も Backbone も Knockout とか色々あるんですけど、元々は jQuery でフロントエンドのアプリケーション書くってなると限界があるというか。基本的にイベントに全部バインドさせて、DOM の変更をキャッチして AJAX とかでサーバーに投げて結果帰ってきたら DOM を全部に撒き散らす、みたいな。そういうやり方が限界があるっていうか。すごい簡単だったらいいんですけど。そういう限界があるとしたとき、フロントエンドの新しい書き方。色々やり方があるんだけど、こういうベストプラクティスというか、こういう風に M と V とデータを分離したらいいよね、っていうのが Backbone で。

naoya: そうそうそう。

miyagawa: Backbone は僕もやったことないんであれなんですけど、決められたレールがあって、こういう風に書いてけばデータバインディングがうまく動くから書けるよって。多分、そういう感じですよね。

naoya: そういう感じ。だから Backbone はどっちかって言うと、僕はそういう印象を持ったんだけど、昔は JS すごい得意な人が自分で「こんな感じでいいんじゃない？」って構造化してたアプリケーションの形ってのがあって、それをそこまで JS 得意じゃない人も Backbone に従ってドキュメントに書いてる通りにすればその人たちがやってたのと同じような構造になるっていうことを、後押しするフレームワークなんですよね。僕はちょうどサーバーサイドをゴリゴリ書いてて、若い人たちは JS をガンガン書いてて、「僕はサーバーサイドやるから君はフロントエンドやってよ」って言って、当時書いてもらった JS とかが大体 Backbone を使った時と同じような構造に今思い返すとなってたな、と思ってて。Backbone はそういうものなんですけど。Angular はそういう観点でいくと全然違って。

36:30

miyagawa: 違いますよね。僕もスクリーンキャストいくつか見て、今自分が作ってる仕事で作ってるアプリの管理画面のコンソールを Angular で1日で書いたんですけども。他にも knockout とか色々あって、僕使ったことないから比較することは出来ないんだけども、面白いところはデータバインディングで、HTML 自体がテンプレートになっててそこにブラケットとか、ng-なんたらって、いわゆる DOM のイベントとかをキャッチするのと同じような感じで。

データが変更された時にここの DOM にパッて出たり出なかったりっていうのを、今までだったら jQuery でデータ持ってきた時に $なんちゃらで CSS セレクタで DOM の要素持ってきてそこに .text で投げ込んでとか、そういうのを全部やんなくていい、っていうのがまずデータバインディングの気持ちよさはあるかな、と思ったんすけど。Angular でも他の Javascript のフレームワークでも結構、シングルページアプリケーションね、SPA っていうのを作るのに向いてる。というかそれをやるのを目的に作られたと思うんですけど。

僕がここ何年くらい書いてるアプリは基本的に JSON の API しかない、みたいなアプリを書いてるので、API だけあってあと「コマンドライン叩いてね」みたいなのもなかなか難しいケースとかがあって。やっぱり「Web の UI が欲しいよね」ってなったときに、今までだったら同じアプリのなかに管理 UI を作るか、別アプリとしてフロントを作るか、みたいなところは結構悩む時があって。どういう事かというと、/api の下に RESTful な API がばーっとあったとして、/console とかで HTML をレンダリングして MVC サーバーサイドでやるみたいなアプリを書くと、本来は API と話すんであれば同じサーバーにある必要はないんで、別アプリとしてフロントエンドを作ってエンドポイントをコンフィグとかで切り替えるのがカッコいいなぁ、とは思うんですけど。

naoya: わかるわかる。

miyagawa: それやると、git のリポジトリ2個に分けたほうがいいなぁ、とかなって。

naoya: 結構めんどくさいんですよね。

miyagawa: 開発作業をするときは git clone で2個持ってきて、ポートを5000番で API サーバー立ち上げて 5001 でフロント立ち上げて、とかやんなきゃいけなくて。それがうまく動くと、テストがしやすいとか、ローカルサーバーからステージングのバックエンドの API に切り替えるのがコンフィグだけで出来るとか、環境変数の切り替えで出来るとかっこいいんですけど。割とめんどくさいな、と思っていて。Angular とかを使ってシングルページアプリをやると、同じサーバーからフロントエンドを吐くんだけど、基本的にスタティックな HTML だけなんで、相互に影響されることはないなぁっていうところでちょっと気持ちよさがありますね。

naoya: 切り分けポイントが明確になるってのがありそう。

miyagawa: そうそうそう。ほんとに分けたければ、どっか別のアプリケーションにエクスポートして別のサーバーから吐くってことももちろんできるし。

39:45

naoya: そうっすね。だから、AngularJS で書く時って HTML を書くじゃないですか。あの HTML に erb とか Rails でレンダリングするテンプレートエンジンは基本使わないほうがいいっていう風にみんなよく言いますよね。Angular とか使うなら、完全にスタティックな Web サイトとして作ってアプリケーションとして動的に動かす、っていうのがいいよって話で。

miyagawa: そう。けど、僕いま Rails で API サーバー作っていて。HTML を出すのって結構 Rails はクセがあって、Asset Pipeline って仕組みを使って HTML とかを色んなディレクトリにばーって置いておくと最後にまとめて出す、みたいなのがあるんすけど。なかなかそれクセがあって、Angular の ngTemplate ってのが URL からロード出来るんですけど、それ本番環境でやると色々クセがあったりとかして。なので、一応 Haml で書いちゃってはいるんですけど、Haml で書いた HTML を index.html で全部展開して、ng-template ってタグで囲って。名前つきでやるとキャッシュに入るじゃないですか。それで読み込む、みたいなことをやっていて。ただ、これがほんとにベストなやり方なのかなっていうのはちょっと疑問があって。

naoya: （笑）

miyagawa: 取り敢えず動くからいいか、ってやってるんですけど。

naoya: Asset Pipeline は Angular とか使うときは使わないっていう選択をした方がいいってこないだ誰かが書いてましたけどね。

miyagawa: それは書いてて思いましたけど。やっぱ、Haml を1回使っちゃうと、HTML を手で書くのすごいダルいな、って思っちゃう。

naoya: いやそれはわかる。僕も Slim 派。僕の場合は Grunt とかのプラグイン使って、そっち側で全部 Slim とかもコンパイルしちゃうんで。元々 Rails そんなに依存してない開発をしてるから、っていうのもあるんだけど。

miyagawa: 確かに Grunt とかを使う方がいいのかもね。

naoya: うん。ま、Grunt もね、あれはあれはセットアップすると色々バッドノウハウがあって。

miyagawa: なんかその、Grunt の話とかも YAPC とかで見たりとかしたんだけど、Rails 的な開発手法を Node とかを使って色んな環境で使えるようにするっていうのはいいアイディアだと思うんですけど。Rails の開発しちゃうと Rails がいろんなもの提供してくれるから、「それに乗った方がいいんだろうな」って思っちゃって、bundler があって、Asset Pipeline があって、なんちゃらかんちゃら、と。じゃあ今度は Angular 使うんで Asset Pipeline 使わないでこの Grunt ってのを使うんですよ、とかってやると、なんかこう。

naoya: そうなんですよ。全く同じ目的のものを全然別のプラットフォーム、Node.js と Ruby とで2つ同じようなの使って、とかなるから。ちょっと冗長なんですよ。

miyagawa: そう、元々のサーバーサイドのアプリが sinatra とかで出来ていて、Asset Pipeline の仕組みがなければ全く疑問もなく行けるんだけども。かぶっちゃうとちょっとやなんですよね。

naoya: そうそうそう。すごい役割かぶるんですよね。最近はだから、Ruby と Node.js が特にそういうとこの開発が盛んだってのがあって。お互いに似たようなもの作ってて、「これどっちでやるんだっけ？」みたいなの多いですよね。

miyagawa: そういう意味では、さっき言ったみたいにフロントとバックエンドのアプリが完全に別れてれば、「このアプリはフロントエンドだから Grunt を使って、バックエンドの方は Asset Pipeline を使って」ってのが。リポジトリとして、アプリとしてわかれてればそこは気持ち悪くないんだろうな、と思うんだけど。1個のアプリにまとめちゃうと気持ち悪いっていう。

naoya: そうですね。でも大体、往々にしてそういうのって最初 Rails で作ってて、途中から「Rails だけだとハンドリングできないから」って Grunt 入れましょう、みたいな感じじゃないですか。実際の現場って。

miyagawa: （笑）

naoya: そんなスクラッチからきれいな状態で書けるなんてことないから。

miyagawa: そうそうそう。

naoya: 大体「なんでここに Grunt と Rails 両方あんの？」みたいなことがあちこちで起こってると思ってる。

miyagawa: 確かに。Angular は発想、哲学的なところが割と「HTML を拡張する」って部分じゃないですか。基本的には ng-なんとかっていうアトリビュートでもいいし。確かタグとしても使えるんですよね、IE のサポートを無視すれば。

naoya: そうです。

43:45

miyagawa: どっちでも同じ意味としては使えるんですけど。ただ、Javascript の書き方が割とクセがあるっていうか。すごい細かいこと言うと、コントローラーがなんで ctrl なんだ、みたいなとことか。

naoya: （笑）

miyagawa: 最初スクリーンキャスト見てて、「なんでそれ略しちゃうの？」って思ったんすけど。ま、それはどうでもいいんだけど。

naoya: なんか妙なダサさがあるんですよ。

miyagawa: あと、Dependency Injection ってのが売りらしくて、ファンクションの引数のところに $scope とか書くと、「$scopeに依存してるんだな」ってなって勝手にそこの仮引数の名前を読んでそこに Inject してくれるっていうのが。だいぶ気持ち悪さあるな、って思ったんすよね。

naoya: そうなんですよね。Dependency Injection っていうとかっこいいんだけど、実際は関数定義を1回文字列としてパースして、そこに $scope ってあったらその関数のなかで $scope ってオブジェクトが作られるって感じの作りになってて。キモいっていうか「それやっていいのか？！」ってレベルで。

miyagawa: （笑）

naoya: でも、DI って大体そういう実装になっちゃうじゃないですか。Java のときも初期の時は JVM にフックして裏側で Inject したりとかしてたんで。そういうキモい感じは確かにあるんですよね。

miyagawa: そう、だから CoffeeScript で書くと勝手にそこを変えちゃったりとかする。あ、CoffeeScript じゃないや、その辺も Rails の話なんですけど、デフォルトで uglifier っつうので全部文字列難読化しちゃうんで、そうすると Dependency Injection 動かなくなるっていう。どうでもいいバッドノウハウとかあって。

naoya: （笑）あるんですよね。

45:23

miyagawa: ただ、コントローラーはいいんですけど、service とか factory とか、最初のデータバインディングのところから「サーバーサイドのコンポーネントを入れましょう」とか「RESTful なところを ngResource で」とかやり出すと結構学習曲線が難しいな、とは思いましたけどね。

naoya: まさにカンファレンスでそういう話題になってて、みんな1回そこでつまづくんですよね。ただ逆に、ちゃちゃっと管理画面作りたいとか、自分 JS 得意じゃないけど、ちゃんと動的に動くアプリをまともなフレームワーク使って作りたいなってときにはすごい便利なんですよね。

miyagawa: 僕も管理画面のアプリを1ヶ月前にちょっと作って、で2週間ヨーロッパに旅行に行ってきて、既にその時点で7割くらいしかわかってなかったです（笑）

naoya: （笑）

miyagawa: これはなんでいるんだっけ、みたいな。結構学習曲線きついな、とは思いましたね。ただ、その管理画面以外のところで、PhoneGap を使ってプロトタイプ的なアプリをちょっと作ってたことがあって。それもちょっと前なんすけど、その時に AngularJS を使ってみたら割と結構気持ちよかったですね。ネイティブのモバイルの Objective-C とか Android の Java の API とかを使って書くのと、データドリブンでやってくってのは似てると思うんですけど。

モバイル HTML で PhoneGap とか Cordova 使って書くと、HTML で jQuery で書くことはもちろん出来るんだけど、そうするとさっきも言ってたような「データバインディングとか自分でやんなきゃいけない」とか「画面が遷移するとそれが消えちゃう」とか、そういう気持ち悪さがあるところが、Angular だと色んなページを画面のレイアウトみたいにして扱って、データがその中で永続化したりとか。サーバーからデータが返ってきたらリストが動的に変更されて、みたいのはモバイルアプリのプロトタイプ作るときにちょっといいかも、と思いました。

naoya: というか、PhoneGap とか僕も触ったことあるんですけど、あれがまさに、HTML を論理マークアップとかじゃなくて、View を組み立てるためのプログラミングのテンプレートとして扱うっていうコンセプトだから。多分 Angular とすごい相性がいいんでしょうね。

miyagawa: それは思いましたね。

naoya: 開発の方向というか手順というか。全く同じベクトルを向いてる、っていうのがあって。

miyagawa: 実際にそれを使って PhoneGap とかで大規模なアプリを作る、ってなったときも、Angular はそういうのにも向いていく仕組みとかユニットテストしやすいとかはあるんで、そこら辺もメリットとしてはあるかもしれないな、とは思いましたね。

naoya: そうですね。でも、その後のカンファレンスの感想見てると、やっぱり Javascript すごい自由自在に使えますよって詳しい人とかは「Angular ちょっとないなぁ」っていう感想を持つ人が多いみたいですね。

miyagawa: 僕も Twitter とかで発言すると、英語圏の知り合いとかは「knockout が薄くていいよ」とか、あるいは「Angular 使うんだけど、Angular が提供してる機能はあんまり使わずに、薄いデータバインディングとしてだけ使う」とか、そういう人も結構いたな。

naoya: あ、でもそういう感じのことをみんな書いてて。僕の周囲の人は Backbone に双方向データバインディングの、ニューヨーク・タイムズの人が作った薄いライブラリがあるんですけど、それを組み合わせるくらいがちょうどいいんじゃないかな、って言ってて。Angular まで行くとちょっとやりすぎ、とか。要するに欲しいのは双方向データバインディングと HTML 側にイベントを寄せるっていうのかな、その2点くらいのはずなのに、Angular ってフルスタックみたいな感じでいろんなもの提供しすぎてて。

まあ、Angular 側の人からの視点ってのは実は高いところにあって。Web Components とか HTML5 の持った新しい仕様と最終的には繋がるんだ、ってことを目標にしてるから。そこに多分ズレがあって。

miyagawa: 確かに。

naoya: 要は Backbone みたいなちっさいなフレームワークが JS を構造化するために欲しいって思ってる人には、Angular の本当に基本的な20％くらいの機能しかいらないんだけど、Angular のビジョンを実現しようとするとそれ以外のところが全部必要になるってとこで。そういう構図があるんだなぁ、と思って見てました。

miyagawa: jQuery とかにも依存してないしね、jQuery lite みたいなのが内蔵されてたりとか。

naoya: jqLite。

miyagawa: うん。ただ、Promises は ng.$q ってので使えたりするけど。そういう Web Components とかっていうのは Google らしさなんだろうなぁ、って思うんですけど。Angular 開発してるの Google のチームなんで。Web のあるべき姿というか、Javascript とか HTML のあるべき姿、こういう形もありだよねっていうのをやるためのプラットフォームとして多分 Angular を使ってるって側面もあると思う。

naoya: あー、そうそうそう。まさにそういう感じ。あくまで今までの JS の苦痛、痛みを和らげるって観点ではなく、HTML5 ってのをちゃんとやったらこうなるんだっていう押し付けがましさがあるっていうのはあるんだけど。でも、僕みたいにその辺のビジョン、JS に関してはこだわりがないから、やりたいと思ったことがパパっと作れればそれでいいって感じだと、Angular はすごくフィットするっていう感じですね。

miyagawa: なるほど。

naoya: そんな感じっすね。

miyagawa: そんな感じっすかね。あの、GitHub とかの話はまた今度。

naoya: （笑）割と1時間パッとすぐ喋っちゃう。

miyagawa: パッと行っちゃうんですよね、話し始めるとね。

51:15

naoya: ちょっとあれだな、このアジェンダのなかで雑談的に話しておきたいのは、あれっすね、Amazon Prime Air っすね。

miyagawa: これね。

naoya: これは全然文脈違うんだけど、むちゃくちゃ面白かった。

miyagawa: これは、今週の頭くらいっすね。Drone ですね、発送ボタンを押して。まだラボの機能、ものなんで、実際に動いてるもんじゃないんですけど、発送ボタンを押す代わりに「30分で届ける」ボタンを押すと、倉庫から荷物がピックアップされて無人の飛行機 Drone が持って行って家の前に落としていく、っていう。そういうデモをやってて。

naoya: いや、これすごいですよね。めっちゃ未来感。

miyagawa: 未来感あるね。

naoya: みんな「あんなの飛んでたら撃ち落とす」とか言ってて（笑）

miyagawa: （笑）

naoya: すげーおもしろかったんだけど。

miyagawa: 一応こういう無人飛行っていうのは、アメリカだと FCC のクリアが降りてないんで、この辺は Google とか Amazon とか、そういうところがロビーイングして、こういうのを出来るようにしていく。

naoya: やってますよね。Google は車でやってますよね、自動操縦。

miyagawa: 無人運転車ですね。

naoya: なんか、こういうのを本当にやるのが結構すげーなー、と思ってて。Google は多分将来的に Google Map とかと組み合わせて。で、Google 確か Uber に出資してるじゃないですか。

miyagawa: はい。

naoya: で、Uber 的な iPhone アプリとかで「ピッ」てボタン押すと、自動車がぶーんって来て。で、行きたい場所「ピッ」って押すとそこに自分を運んでいってくれるとか。例えば、届けたい荷物置くとそこまで持ってくとか。ほんとにそういうことを、10年かかるかわかんないけど、やろうとしてるんですよ。で、Amazon もそういう感じじゃないですか。

miyagawa: Google は昨日だか、元 Android の head の Andy Rubin が Android 止めて今やってるシークレットプロジェクトを、東大のロボットベンチャーとかを買収してロボットを作るっていうのをやってるみたいなんで。そういう SF みたいな世界を Google はやろうとしてるのは1つあるんだけど。Amazon も負けてないっていうか。ただ、Amazon っていうのは結構消費者よりの会社なんで、こういう「すぐ見てメリットがわかる」っていうところが結構すごいかなぁ、と思ったね。

naoya: いやー、でもこれめっちゃいいですよね。あのテクノロジーを使って運んでこられたのが漫画本1冊とか（笑）

miyagawa: （笑）

naoya: ゲーム1本、DVD 1本とかね。

miyagawa: めちゃくちゃでかい Amazon のパッケージングに入ってて。

naoya: （笑）そうそうそう。で、パカってなか開けたら USB メモリーが1個しか入ってない。

miyagawa: まあでも、日本は今でも配送はね、すぐ来るっしょ？Amazon Prime だったら。

naoya: うん。こないだ Uber が日本に上陸したんですけど、結局あれも日本ってタクシーがものすごく発達してて、理路整然としてて、誰もタクシー捕まえられないとか評判が悪いとかで困ってないから。ちょっと違うんですよね。

miyagawa: そうね。

naoya: なんか日本の場合は、普段乗れない車で迎えに来てくれる、みたいなところが1つ売りになってて。

miyagawa: そう。Uber とか、結局サンフランシスコとかでも「タクシー捕まえられない」とか、あるいは捕まえてもタクシーの運ちゃんのマナーが悪いとか。ずーっと携帯で喋ってるとかたばこ臭いとか。そういういろんな問題があって、それを解決するためのテクノロジーなんですけど。マーケットによってそういう需要が違うってことだよね。

naoya: そうそう。だから、Amazon Prime Air も、多分日本人の人は、純粋に空飛んで持ってくるってとこに「うぉーーっ！」とか言うんだけど、多分他の国の人たちだと、「これがあればよくわからないガラの悪い兄ちゃんが荷物持ってくるのに悩まされることがない」とかいってほんとに問題が解決されると本気で思ってて。でも日本人の場合は Amazon の場合はヘタしたら昼に頼むと夕方に届いたりするんで。

miyagawa: そうそうそう。

naoya: ま、あと2～3時間早くなっても別にな、っていうのもちょっとあって。そういうのもあって真剣にやらないのかもしれないけど。国土も狭いし。

miyagawa: そうっすなー。

naoya: これめちゃ面白かったっていう話で最後。

miyagawa: そんなところで。今日の Show Notes は rebuild.fm/27 から見れます。なんか、ポッドキャストで聞いてる人はもちろんどんどん増えてて嬉しいんですけど、そもそもポッドキャストの使い方がわからないって人も結構いたみたいで。僕のブログポストにアップしてますんで、それを読んでもらうといちいち「更新まだか～～」ってクリックしたりしなくてもいいんでオススメです。ま、そんな感じですかね。

naoya: はい。本日もありがとうございました。

miyagawa: ありがとうございました。どうもー。

---

Transcribed by @harupong http://blog.harupong.com/