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

miyagawa: 今回初ゲストですけど。

hotchpotch: はい。

miyagawa: 舘野祐一さんです。

hotchpotch: どうも舘野祐一です。ネット上だと id:secondlife 、これ はてなID なんですけど。他は Twitter とか GitHub とかは hotchpotch って ID でやってます。よろしくお願いします。

miyagawa: お願いします。この hotchpotch っていうのはどういう由来っすかね。

hotchpotch: これはですね、昔、坂本真綾のアルバムでそういうのがあってそこから。で secondlife って、なんか昔はよかったんすけど、仮想空間の secondlife が出てきてから、ID がまったくとれなくなっちゃって。別のないかな、って今の hotchpotch にしたんですけど。でも、一般的な英単語ってやっぱり取られやすかったりもするから。もっとユニークなやつにしとけばよかったなって、今は思いますけどね。

miyagawa: そうね。secondlife もしとれたとしても、すごい間違いツイートがいっぱい来ると思う。

hotchpotch: そうそうそうそう。SEO、検索効果も低いし、あんまりいいことないな、ってのはありますよね。

miyagawa: そうそう。僕の元同僚で、今 GitHub に入った dice がいるんだけど。Twitter の ID が昔はね、angrydicemoose っていう長い ID を持ってて、あるときに @dice が空いてたのか知らないけど、変わったんだよね。で最近、DICE ってゲームメーカーがあるんだけど、そこへの苦情が彼のところに来まくってるんだよね。

hotchpotch: (笑)

miyagawa: 「@DICE お前のゲームはクソだ」みたいな感じで。

hotchpotch: やっぱ一般名称はそういうのが色々あるからつらいよね。

1:37

miyagawa: セコンさんは Rebuild のヘビーリスナーらしい。

hotchpotch: Rebuild 僕聞きまくってて。どの回も4～5回とか聞いてて。通勤途中と、あとお風呂入ってる時に Bluetooth のスピーカー持ち込んで音楽流したりするんすけど、だいたい音楽か Rebuild かどっちかを流してることが多くて。もーずーっと聞いてるので。かなり聞いてますよ。

miyagawa: 嬉しいっすねー。Twitter とか見てると、ながら聞きで聞く人がすごい多くてね。「週末の掃除しながらに最適」とか、「ランニングしながら」とか。

hotchpotch: うんうんうん。

miyagawa: いいですよね。でも、コード書きながら聞いてる人もたまにいるらしいんだけど、僕は頭を使う作業にこういうポッドキャストはあんまり向かないんじゃないかな、って思うんだけど。

hotchpotch: スイッチが難しくなっちゃうけど。けど、コード書いてるとポッドキャストの内容あんまり頭に入んないんだけど、裏側の音楽的なコンテキストは技術的な話ししてるから、脳がこっちにスイッチするってのはあんのかもしんないですね。

miyagawa: そうそうそう。あとは、2回目以降とか、1回話が分かった状態で流し聞きするとかではいいかもしんないけどね。

hotchpotch: あ、そっかそっか。分かってるからなんとなくつまみ食い。アニメとかも1回目見るときは真剣なんだけど、2回目とかはすげーダラダラ見てもなんか分かってる、みたいな。

miyagawa: そうそうそう。そういうのあるかもしんないけど。

hotchpotch: やっぱポッドキャストすごい聞くようになったのは、Rebuild のどっかで miyagawa さんが Android や iPhone のポッドキャストクライアントをオススメしてたことあったじゃないですか。

miyagawa: うん。

hotchpotch: あれまでは、普通に Web で再生ボタンとか押して聞いてたんで、あんまり聞けなかったんだけど。やっぱツールが変わるとすごく変わって。ストリームデータが保存されてる状態でどこでも聞けるし、どこでも続きから聞けるし、みたいな。ポータビリティをすごい持ったら、めちゃくちゃ聞くようになって。クライアントの力ってすごい大きいなぁ、みたいなのは。

miyagawa: そうそうそう。そうなんすよね。でちょうど、Rebuild.fm 専用のクライアントっていうのを作った人が先週いまして。

hotchpotch: レジャスポ太郎が。

miyagawa: レジャスポ太郎くんが作ってくれたんだけど。これは一応 Android だけで使える非公式クライアントなんですけど。ま、番組で紹介しちゃってるんで公式みたいな感じになっちゃうけど。

hotchpotch: 一応非公式、みたいな。

miyagawa: そうですね。ポッドキャストのクライアントは世の中にいっぱいあるんだけど、彼の主張としては、Rebuild 以外のポッドキャストほとんど聞かないし、それに特化したやつを作りたかったっていう。なんだか面白い理由で作ったらしいんだけども。

hotchpotch: うん。

miyagawa: 見た目はさすがに特化してるだけあって結構面白くて。特に、Show Notesっていう、エピソードで紹介したページとか URL を紹介してるんだけども、それの見せ方がサムネイルとか出てきてちょっと面白いかな、とは思いますね。

hotchpotch: そうなんだよね。下の方にリストで、テーブルビューで2つわ～って並んでて。ちゃんとサムネイルが出る場合はなんとなくわかりやすい、みたいな。

miyagawa: まだバージョン1、0.1かな。

hotchpotch: そうそうそう。

miyagawa: なので、ストリーム再生とかがあんまり安定してないというか。直感的じゃない感じがしたんだけど。今朝ちょっと見てみたらアップデートしてて。バックグラウンドでダウンロードしてキャッシュするみたいなのができるようになってましたね。

hotchpotch: 確かそれ、最初のバージョンにもあったんだけど「すごいスムーズ」みたいな感じじゃなかったのかな。でもやっぱり、モバイルのポッドキャストクライアントって、ストリームでダウンロードして、例えばネットワーク回線が切れてもどこでも聞ける安心感みたいなのってすごい大事だから。そういうのがうまく入っていくと普通に使いやすいクライアントになるんじゃないのかな、って。

miyagawa: そうっすね。あとは、僕がオススメするのもなんですけど、ダウンロードして聞くタイプだと、再生速度とか変えられるものが多いんですよね。僕はだいたい日本語のポッドキャストは 1.4 倍くらいで、英語のは 1.2 倍くらいで聞いてるんだけど、少し時間が節約できる、みたいな感はありますけどね。

5:46

hotchpotch: あ、そうですね。僕、iOS の方しか知らないんですけど、標準の API で制御できるんですよね、再生速度を。

miyagawa: そうそうそう。

hotchpotch: だからクライアントの方も実装そんなに大変じゃないってのがあって。

miyagawa: Apple のポッドキャストクライアントもね、サポートしてるんだけど。ちょっと面白い話があって、Apple のデフォルトの API、オーディオを流す API は 1.5x 2.0x 、1.5倍、2倍速あるんだけど、あれを選ぶと実装は 1.25倍と 1.5 倍らしいんですよ。

hotchpotch: （笑）

miyagawa: で、他のアプリも 1.5 倍ってやったときは実際 1.25 倍にするのか 1.5 倍にするのかって、クライアントによって実装状況が違ってて。いわゆる Apple の 1.5 倍っていうの、ほんとの 1.5 倍 は違ってるらしい。

hotchpotch: それっていうのは、1.5 倍にデータサイズを縮めたときに時間軸では 1.25 になるのか、それとも、1.5 っていうとみんな 1.5 にセットするんだけど、1.25 くらいの方が聞きやすいから 1.25 にしてんのかって、どっちなんですかね。

miyagawa: 多分、Apple があるポイントで後者にしたんだろうね。1.5 って言ってるけど 1.5 速すぎるから、みたいな感じで。でも、あんま直感的な感じじゃないんだよね、そういうことされると。

hotchpotch: そうだよね。なんか60分聞こうと思って 1.5 で、みたいな感じで想定してると、「あれっ」て。みたいな感じになるかもしれないね。

miyagawa: そうそうそう。そういうのが結構面白くて。今はそれが、ほんとに 1.5 なのか、昔の 1.5 なのかっていう API があるみたいなことを言ってた（笑）

hotchpotch: （笑）

miyagawa: 更にカオスになるだけだと思うんだけど。

hotchpotch: なんか、実装コードとかすげーカオスになってそうだよね。これはリアルの 1.5 だからどうこう、みたいな if 文のチェックが入って、みたいな。

7:41

miyagawa: そうね。レジャスポ太郎くんは、Android 開発者としてはやってると思うんだけど、COOKPAD も最近、モバイル専業のデベロッパーの人が結構入ってると思うんですけど。

hotchpotch: うんうん。

miyagawa: そのあたりは結構増えてきてはいますよね。

hotchpotch: そうだね。今はやっぱり、うちの会社 Ruby の会社で有名、Ruby や Rails のデベロッパーの人が結構いるみたいなので有名なところがあったんだけど。僕、今月から CTO になったんですけど、今更ながらにモバイルファーストみたいな感じで、本当にモバイル向けの開発をしっかりとやっていくベースも作らないと、正直なところモバイルアプリの方に関しては全然世の中から取り残されてる状態なので。ちょっとやってかなくちゃなー、ていうところもあって。

2つポイントがあって、1個はフロント側のモバイルのアプリっていうのを、しっかりいいモノを作れるところっていうのをもっとエンジニアも採用したいと思ってるし、そこの部分の技術を高めるってのもあるんですけど。裏側の Ruby や Rails サイドの、いわゆる API 的な部分の作り込みっていうのもモバイルの方にシフトしていくっていうのをやっていて。僕がすごくショックだったのが、去年いろいろモバイルの、例えば MBaaS とか、モバイル向けの Heroku みたいなのを色々調べてたりとかしてたときに、「僕が思う使いやすい API」と、「モバイルアプリから見た使いやすい API」って全然コンテキストが違って。

例えば Rails の方の API だったら、RESTful なきれいな API を提供して、oAuth の認証方法をちゃんと整えて提供すれば便利だよね、思ってるんだけど、実際はそこにもうちょっと上のレイヤーでいろいろ手を入れなくちゃ全然便利なものにならなくって。例えばモバイルの場合、シンクロナイズド API みたいな、モバイルのアプリケーションでデータを操作したときにネットワークがあったらネットワークで通信してちゃんとサーバーと同期するし、ネットワークがなかったらローカルではデータの更新とか行われつつネットワークが繋がった瞬間に同期してうまく整合性を保つ、みたいなものがすごく重要になっていくんですよ。

そういうのを自分ではあんまり意識しないで普通にサーバーサイドだけ作ってた、みたいなのがショックで、このままやっていくと技術的に「シンプルでいいもの」みたいに舵を切っちゃって、本当にもっとコストをかけるべきなのはそこじゃない、みたいなところの API の作り込みに時間をかけ過ぎちゃってたかな、というのがすごい反省点として見えてきて。そういうところも含めて、もっとモバイルアプリケーションに対してどうこうできる、みたいなところを進めていかなくちゃな、みたいな。改めて感じたりしましたね。

10:16

miyagawa: うん。

hotchpotch: で、そういうところから、サーバーサイドの API だけをやってるんじゃなくて、モバイル開発の背景を理解したからこそ作るべき API っていうのをちゃんとやっていかないと、道がどんどんそれていっちゃうな、ってすごい反省点もあって。そういう意味で Ruby や Rails のエンジニア にはモバイルのアプリの作り方の背景を理解してやって欲しいみたいなところもあるし。モバイルアプリの方のエンジニアは、そこが実際使いづらいものだったら、もっとどんどんコミュニケーションとってほんとに使いやすいもの作っていかないと、他社にどんどん負けちゃうなみたいなところをすごい感じたっていうのがあって。そういう意味で、モバイルアプリっていうのをサーバーサイドの開発者側も、クライアントサイドの開発者側も、もっともっとしっかりと意識しないとダメになるなぁ、みたいなところを感じましたね。

miyagawa: なるほどね。日本の、実際にモバイル系の開発する求人って、アメリカだとすごい需要のほうがずっと買ってて供給が足りない、モバイルデベロッパー引く手あまたって感じなんですけど、日本の方もおんなじような感じなのかな。

hotchpotch: 日本の方もそうだと思いますよ。あとは、キャリアのスイッチみたいなところがまだまだ日本の場合は Web の方に結構人がいるなあって感じが感覚としてあって。そこがまだ全然スイッチできてないからこそ、需要と供給のバランスはまだまだアンバランスで。多分、2～3年するとそこって解消されて、競合優位性、モバイルアプリが書けるからどうこうみたいなのはなくなる、むしろみんなが書けるようにはなってるとは思うんですけど。

miyagawa: うん。

hotchpotch: でもやっぱりそこは全然足りないってのは日本の現状見てても思いますね。

12:00

miyagawa: なるほどね。でも、COOKPAD は結構 Ruby とか Rails の開発のコミュニティのなかで言うといい人材が揃ってるとは思うので、サーバーサイドにおいてはすごく強みがあったと思うんだけど。そこを活かしつつ、モバイルの方もどんどん強くしてかなきゃ、みたいな感じですかね。

hotchpotch: そうですね。そこはやっぱりすごいトライな部分だと思ってて、古い開発にずっと慣れてると、それがいいからっていうことで判断を Web 側、違う側に振っちゃってる部分もあって。僕自身がそうだったんですけど。そこを変えていかないと多分ダメだし、通常の Rails の開発っていうか、モバイルのアプリケーションに乗った裏側の API 開発ってなんなんだろ、っていうところをしっかり考えていかないと、ミスマッチなスキルを伸ばしてしまうっていうことにもなっちゃうかな、とも思ってて。

miyagawa: 結構ね、昔はモバイルサイトは HTML5 みたいなサイトがあって、アプリはそれにガワをつけて、みたいな感じが主流だったと思うんですけど、やっぱりそれもどんどんネイティブにシフトしてハイブリッドみたいな感じでやっていく、みたいなところですよね。

hotchpotch: そうですね。100% ネイティブにするべきかどうか、というのはさておいて、ネイティブの良さをすごい理解してないと、アプリで表現するときに、HTML なんだけネイティブなんだっけっていう判断を誤っちゃうので、両方を知った上でしっかりと。ネイティブの方が絶対いいところはネイティブだし、そうじゃないところは HTML でやっても別に問題ないんじゃないみたいなところをちゃんと見極めていかないとすごい判断を誤るなぁ、ってのはありますね。

miyagawa: 先週、先々週のポッドキャストで、37 signals の話何回かしたんですけど。彼らもいろんなプロダクト持ってて、最近は Basecamp に統一していって会社名も Basecamp に変えた、みたいなことがあったんだけど。ただ、Basecamp 自体は結構 Rails で作ってることもあって、モバイル的な UI も最初は HTML5 で作ってたみたいなんだよね。だけど最近、ここ一年くらいで iOS アプリと Android アプリを出してる。

会社名を変えた経緯のなかの一つに、Highrise とか Campfilre とかいろんなサブプロダクトがあって、Basecamp に集約すると1個しかプロダクトがなくなっちゃうって思うんだけども、実際 Basecamp ってプロダクトも Web と、最近出してるモバイルのアプリと、Email でメーリングリストみたいに Basecamp 使えるんで。そういう風に考えると 3 つプロダクトがあるようなもんだ、って言ってて。それだけ作り方、使い方がどんどん変わってきているのな、っていう。モバイルが Web の延長線上、みたいな作り方では全然ダメで、モバイルに特化した違うプロダクトという感じで作っていく意識が感じられたな、と思ってたんですよね。

hotchpotch: そうだね。しかも、Basecamp が最初そうだったように、Web の開発者からするとモバイルで表示できる Web を作るんだったらこうする、とかがすごい短い工数で作れるから、そっちを先に作っちゃいがちなんだよね。でもやっぱり、いま話してくれたように、コンテキストが全然違うから、モバイルはモバイルに合わせて特化したものっていうのを作らないと、別に Web で出しても特に使いやすいものにならない、みたいなものっていうのはすごいあるよね。

miyagawa: うん。最初の方に話してくれたけど、API に関しても RESTful な API っていうのはすごくデザインもしやすくて設計もすごくシンプルなものになっていって、メンテとか開発のしやすさって意味ではすごくよくて。で、それがよくない、っていうよりはそれを中心にそっちがメインであるという風に考えてモバイルをその上に乗せてどんどん開発していくと、結局スマートフォン向けに HTML5 のアプリを作るのとほぼ同じような感じで既存にあるものに合わせてクライアントの方、表示する方をどんどん変えていかなきゃいけないっていうか。無理やり合わせていく、って感じになりがちなんですよね。だからモバイルの UI/UX に合わせた API レイヤーみたいなものをどんどん作っていかなきゃいけない、みたいなのは、僕とかも最近舘野君とかと話してやってます、最近はね。

hotchpotch: そうですね。最近は結構そっち多いですよね。うちの会社だと SOA、Service Oriented Architecture で、小さな粒度で API 切り出すっていうのはすごいやってたことなんですけど、そこの上にどう組み立てるのかっていうのはまた別の問題としてすごいあって。アプリに合わせて特化した API ってどういう風に作っていくのがいいんだろっていうのをね、しっかり組み立てていかないとごちゃっとした汚い API を作っちゃってあとあと「色んなとこに API ありすぎ問題」みたいな感じにもなりがちだし。そこをどういう風に解決していくのかっていうのは、まだ「これだ！」っていう明確な解は見つかってないけど、いくつか試してるみたいなところっすよね。

miyagawa: そうですね。実際、UI とか UX みたいな話もそうだし、あとはアプリになってくると1つ問題になってくるのがバージョンをコントロールする問題っていうか。1回 App Store 出したアプリっていうのは、基本的にユーザーが 100% 全部ずっとアップデートし続けるわけじゃないわけですよね。

hotchpotch: うんうん。

miyagawa: だから、古いバージョンで使ってた API で、「これよくないから新しいバージョンに変えたいんだけど、古いクライアントはこの API まだ使ってるから」みたいな感じで、どんどん Ad Hoc な API の継ぎ足しみたいなのがどんどん出てきて。

hotchpotch: うんうん。

miyagawa: そういうところもシンプルな API だけで対応しようとすると、せっかくすごいシンプルな API のはずなのにクライアントが山ほどあってそれ用に最大公約数みたいな API しか作れなくて使いにくいものになりがちっていうのはあって。その辺を一緒に解決できないかな、っていうのをずっと最近考えてるよね。

18:07

hotchpotch: そうそうそう。結構難しいよね、そこ。現状欲しいものはこれだ！みたいなのは決まってるけど、将来的には変わっていく可能性も十分あるし。

miyagawa: その辺がちょっと面白いな、と思いますけど。

そうですね、最初の方で何を話したかったかというと、COOKPAD みたいなアプリもそうですけど、さっきの Rebuild.fm クライアントみたいに個人でデザインとか開発まで作れるモバイルエンジニアってのもなかなか人材としてはすごく難しくて。

hotchpotch: うんうん。

miyagawa: COOKPAD の場合、モバイルアプリのデザインとかっていうのは普通の Web サイトのデザインとかとまったく違うスキルが要求されると思うんですけど。その辺はどんな感じっすかね。

hotchpotch: うちはデザイン部っていうデザインの部が別に分離してるんですけど、そこはモバイルのアプリのデザインっていうのを考えてやってるんですよ。今は分業してやってるんですけど、エンジニアがどこまでモバイルアプリの UI/UX のところに関わっていくかっていうところなんだけど。やっぱこう、細部のすごい細かいところっていうのはさすがデザイナーだから出来るディテールっていうのはあると思ってて。そこの前部分の、いわゆるユーザー体験としてどういうデザイン描いてどういう操作させたい、みたいなのっていうのはエンジニアが記述できるようになった方がいいんじゃないかな、とも思ってて。

なので、個人で全部やるっていうのは、さすがに細部が詰められないとかっていうのがあると思うんですけど。そこじゃないレイヤー、例えば iOS だったらヒューマンインタフェースガイドラインっていうガイドラインがあって、それに沿って実装することによって Apple としてはこういう風にユーザー体験を UI を通じて提供したい、っていうのがあるので、そこをエンジニアが理解して、例えば最適な配置っていうのはある程度考えるし。で、細かいところっていうのはデザイナーと詰めて「こうだろう」っていうの話していく、っていう形になるのが一番いいんじゃないのかな、とも思ってて。まぁ滝口くん、あ、滝口くんってレジャスポ太郎＝滝口くんなんだけど（笑）

miyagawa: （笑）

hotchpotch: レジャスポ太郎氏もあの Android の Rebuild.fm のクライアントとはいえ、自分で1人でいわゆる Android の通常の UI のコンポーネントを使ってあそこまで表現できてるので、そこっていうのは結構エンジニアでも細部以外はやりやすくなったんじゃないのかな、と思うけどね。

miyagawa: そうですよね。やっぱりいま言ってくれた HIG とか、あとは Google の方も結構いろんな Android でツールというか、UI の部品がちゃんと出来てきてるんで。あえてグラフィックにごりごり凝って作るっていうのも、もちろんそれがうまくいけばきれいなアプリが作れるとは思うけど、あんまりそういうのを凝り過ぎるよりは標準で提供されてる物の上でやる方がいい物が出来やすい、プラットフォームが求めてる物が出来やすいかな、っていう気はしますよね。

20:59

hotchpotch: うんうんうん。で、その中で例えば、LINE とかって結構 LINE のアプリ結構出していて、デザインっていうのもある程度は統一図ってると思うんですけど、そういう意味で多分 COOKPAD も多分これからアプリをたくさん出していくとすると、COOKPAD 上ではこうすべき、みたいなある程度の定義っていうのは出来ていくんじゃないかな、っていうのは思っていて。それプラス OS 流の良さっていうところを一緒に出して作っていくみたいな形になってくるんじゃないのかな、と。

miyagawa: そうっすね。やっぱり、OS のネイティブでやる以上はそこの流儀っていうか、そういうパターンに乗ったものじゃないとユーザーが戸惑う部分もあるからね。

hotchpotch: うんうん。あと、プロダクト作るうえで、そこ知ったうえで壊すんだったらいいと思うんですよね。その、ヒューマンインタフェースガイドラインではこう定義されてるけど、僕たちが提供したいのってそこじゃなくてもっとこういう使い方をしてもらって新しい価値を提供できるんだって言って壊すんだったらいいんですけど。なんかよく分かんないけどとりあえず組み立てていって、UI の統一性がなされてないとか、ユーザーに対して、自分はこう思うけどユーザーに対して全然不便を強いるみたいなことに。なんか知らないで壊すっていうのはすごいよくないことだと思うので。

miyagawa: うん。

hotchpotch: ちゃんと壊すとしても知ったうえで壊すっていうのはすごいモバイル、なんかもうほんとに画面サイズが小さくて、小さい画面サイズにどう表現するかっていうのを徹底的に考えなくちゃいけないコンテキストにおいては、そういうところの知識っていうのも、特にフロントのクライアントサイドを作るエンジニアには絶対必須だなぁ、というのは感覚としてありますけどね。

miyagawa: なんか、僕ずっと結構 Android を使ってたので、Android のアプリってほんと基本的に iPhone のアプリをポートしただけ、みたいなアプリ結構多いじゃないですか。そういうのってすごい使っててイライラするっていうか。見た目は iPhone みたいな、iOS6 みたいなものをコピーしてきてるんだけど、全然 Android だとそこにボタンあるべきではないしみたいなのが結構あるんだよね。

hotchpotch: そうなんだよね。コンポーネントだってさ、例えばタブナビゲーションだったら Android だったら上にあって iPhone だったら下にあるとか、なんか色々なところで別だったり。あと、戻るボタンの挙動っていうのは Android はそもそも戻るボタンあるし、iOS の場合は戻るボタンがないからナビゲーションバーの戻るっていうのを基本的にとか。なんか色んなところあるけど、お互いのところ分かってないでとりあえず作っちゃうと「うぉーー！」みたいな（笑）

miyagawa: （笑）そうそう。

hotchpotch: これどーなんだ、みたいな。

miyagawa: ほんと多いんだよね。最近はでも、Android の4かな、Ice Cream Sandwich 以降からは、結構そういう標準 UI がだいぶまともになってきたのもあるんで、そういうのに乗った UI、アプリがだいぶ増えてきてはいるけど。まだね、これほんとただポートしただけだな、みたいなクソ UI のアプリとかね、結構あるんで。つらいよね。

hotchpotch: そういうのは多分徐々にはなくなっていくとは思うんだけどね、現状はやっぱりまだ結構、っていうのは。

miyagawa: Android First みたいな会社もちょくちょく増えてきて、昔だったら iOS の方がユーザーが圧倒的に多いし、作る部分においても iOS の方が作りやすいというか、SDK の充実度とか端末の種類の少なさとかがあったんだけど。最近はそうでもなくなってきてるんで。ほんとに Android らしいアプリが結構増えてきて僕としては嬉しいんですけど。

hotchpotch: 日本だと使ってるユーザーの割合が Android と iOS だと、世界的に見ても iOS の方が少し多いくらい？

miyagawa: 最初の方はそうでもなかったけど、最近は日本だともうほんとに iOS が圧倒的になってきてるよね。

hotchpotch: ドコモもキャリアから出したしね。もうそれで、日本人は結構。アメリカだと iOS 2～3割くらいだっけ、今って？

24:51

miyagawa: たぶん3～4割くらいかな。数でいったら Android が一番多くて、端末ベースでいうと iPhone が一番多いんだけども、Android の端末は Galaxy とか Nexus とか Motorola とか色々全部足すと、多分 iPhoneより多いって感じになると思う。

hotchpotch: でまあ、なんだろね。デベロップメントのやりやすさっていうのはね、Android だと様々な方法で、iOS の場合はそもそも Apple のデベロッパー向けの制約が厳しくて、例えば自分で野良アプリ作ったけど配布が難しかったりするじゃん。

miyagawa: はい。

hotchpotch: そういうのが Android だとすぐできるし、Android の場合はもし万が一大きなバグが出てすぐリリースしたいって思ってサブミットしても即、っていうのがあって。Apple の場合はそこでアプリのクオリティやセキュリティの問題を改善、担保してるっていうのはすごい分かるんだけど。どっちがいいんだろね、っていうのはね。

miyagawa: あるよね。実際、僕とかが、これあんまり話してないですけど、iPhone とか Android の COOKPAD のアプリの裏側の API とかの仕事してて。僕だけじゃないですけど。昔から使ってる API から僕らが作った新しい API に切り替えるのとかも、iOS の場合はローリングリリースってのが出来ないので、新しいアプリを出したあとサーバーサイドでフラグを立ててローリングリリースをする、みたいなことをやってて。で、Android の方は最近新しいバージョンを出したんだけど、それは Google の出してるローリングアウトの仕組みを使ってるのでサーバーサイドでそういう対応をする必要がなかった、みたいなところがあって。

hotchpotch: そうだね。

miyagawa: そこら辺は結構 Google の方がそういうサーバーサイドを含めた対応っていうと結構やりやすくなってるのかな、っていう気はします。

hotchpotch: なんか iOS 大変だったよね。さっきの API のバージョニングの話じゃないんだけど、実際 COOKPAD で裏側で使ってる iOS の API を1回ガラッと新しい API に置き換えたことがあって、でもそれって iOS の場合は「数%にリリース」みたいなことが App Store から出来ないから、ソースコード上でリクエストのヘッダ見てどっちのバージョンを使うかってのを、「1%のユーザーは新しいバージョンの API 使って問題ないか」みたいなものをさ、ゆっくりやっていって。

miyagawa: そうっすね。

hotchpotch: ソースコード上では実装は2つあって、新しい API と古い API を使うソースが両方1個のクライアントに入ってて、HTTP の、miyagawaさんや API チームが作ってくれたヘッダによって切り替えるやつをうまく使いつつ、どうにかなだらかな移行っていうのを成功させた、みたいなことがあって。

miyagawa: そうそう。あれ自体は実装は結構面白かったけど。ただ、Google がやってくれたままで出来るんであればそっちの方が全然簡単だったので。

hotchpotch: 去年の Google I/O で発表されたんだっけ？5% とか一部ユーザーに対して新しいアプリケーションのバイナリーを配布できる、みたいな。

miyagawa: うん。確かそうだと思いますね。

hotchpotch: それが出来たので、なだらかな大規模バージョンアップっていうのが Android アプリの場合すごいやりやすくなった、っていうのありますよね。

27:26

miyagawa: そうね。じゃここでうまく話がつながると思うんですけども。TestFlight っていう Android とiPhone のアプリをテスト環境で配信するっていうサービスがあったんですけど、先週 Android 対応がなくなってしまって。iOS も新しいチームを追加することが出来ない、みたいな感じで。これはもう終わったのか？って思われてたら、昨日「Apple に買収された」っていうのが出てましたけど。

hotchpotch: そうそうそう。Android を打ち切ってそろそろ、え、なんか不穏な動きでも出てきたのかな、って思ってたら、オフィシャルになるのかなみたいな。

miyagawa: そうっすね。これはまだちょっと詳細はよく分かんないんだけども、Apple が買収して、たださっきも言ったように新しいサインアップとかは中止してるので。TestFlight がそのまま Apple のデベロッパーセンター、iTunes Connect に乗るっていうほど楽観的ではないのかな、っていう気も僕はちょっとしてるんだけども。どういうことかっていうと、結構 Apple ってこういう買収したあとそこのサービスは潰してそのチームに新しいものを作らせる、っていうパターンが結構多いんですよね。

hotchpotch: うんうん。

miyagawa: 具体的には例えば Lala っていう音楽サービスを買って iTunes Match を作ったりとか。あとは Siri のところもそうだし。買ったものをそのまま Apple のブランドで出すってことはほとんどしなくて。チームのテクノロジーを買ってそれを自分の上にインテグレートするっていうパターンが多いと思うんですよね。

hotchpotch: うんうん。

miyagawa: 英語だとこういうの Acquihire って呼ぶんですけど。

hotchpotch: アクハイヤー？？

miyagawa: 要は Acquire で獲得、M&A の A が Acquire なんだけども、Hire ってのは雇うって意味で、サービスを買って人だけ雇ってプロダクトは潰すっていう。そういうの Acquihire っていうんだけど。多分これもそうなんじゃないかな、と僕は思うんだけど。

hotchpotch: なるほど。

miyagawa: どうなんすかね。

hotchpotch: うまくスイッチできればデベロッパーとしては言うことはそんなにないんだけどね。Apple のデベロッパーセンターの方で TestFlight 的なことが柔軟に出来るようになればいいな、いうのはあるんだけど。

miyagawa: ま、買収したくらいだから、こういう需要というか、デベロッパーの要求があるっていうのはたぶん分かってはいるとは思うんすよね。

hotchpotch: TestFlight すらも完全に閉じられるとだいぶ開発が、また一段階やりづらいみたいな感じ。開発というよりか配布がね。

miyagawa: そうね。一応競合としては HockeyApp と、日本の Mixi がやってる DeployGate ってのがあって。DeployGate は Android では僕らも使ってますけど。ついこないだから iOS 版も対応したみたいですよね。

hotchpotch: でもさ、そういうのって例えば TestFlight を Apple が買収して自社でやりだすから、そういう他社がやってる配信って完全に潰すみたいなことっていうのは Apple は出来たりするわけなの？

miyagawa: そうですね。ただ、TestFlight が使ってる仕組みって独自にハックをしてるわけじゃなくて、エンタープライズ対応っていうか、会社とかで百台とかバルクで購入した iPhone に会社で使ってるソフトをまとめてインストールしたいみたいな仕組みの上に乗ってるんで。TestFlight を潰そうとするとそういうエンタープライズのニーズも潰すことになっちゃうから、なかなかいきなり潰すってのは難しいのかなとは思うけどね。

hotchpotch: なるほど。仕組み的に現状は出来るってことだよね。

miyagawa: うん。出来るし、ちゃんとそれがiTunes Connect の上で出来るようになったらもっと便利になるとは思うんすけど。

hotchpotch: うんうん。

miyagawa: 僕は iOS の開発をしてるわけじゃないんで聞いた範囲になりますけど、今の iTunes Connect のベータアプリのやり方がめんどくさいのは UDID をもらっていちいち登録するのがすごいめんどくさいって言ってて。1つには Apple ID とかでそれが認証できればものすごい簡単なのになーっていうのはありますよね。

hotchpotch: そうだね。

miyagawa: 例えば僕、友だちのアプリをテストさせてもらおうと思ってやると、iPhone と iPod touch とか持ってると全部 UDID が違うからね。だから、今送るのは iPod touch で、今度 iPad はこれで、みたいな感じですごいめんどくさい。

hotchpotch: そっか。Apple ID だったら端末複数紐付いてるので、miyagawaさんが持ってる機器全部に対してやれる、みたいなことが。

miyagawa: うん。その方が全然普通だと思うしね。その辺はサーバーサイドでプロファイルとかでやるっていうのが TestFlight とか DeployGate の1つの仕組みだと思うので。そういう風に iTunes Connect もなってくれれば開発者としては Win-Win だとは思うんだけど。

hotchpotch: そうだね。

32:15

miyagawa: じゃ、最後って言うか、もう1個買収関連で。WhatsApp っていうメッセージングアプリを Facebook が買ったっていう話をしましょうかね。

hotchpotch: 160億ドルだっけ。160億ドル。

miyagawa: そうそうそう。

hotchpotch: 1兆6000万くらい。

miyagawa: 1兆6000億だよ。

hotchpotch: あ、1兆6000億円くらいね。

miyagawa: （笑）

hotchpotch: そうそうそう。すげーな。

miyagawa: もう規模がわけわかんないけどね。

hotchpotch: 1兆6000億ってソニーの時価総額より高いんだよね、確か。

miyagawa: なんかそんな感じ。Twitter の時価総額の半分。あと NASA の一年分の予算（笑）

hotchpotch: （笑）なんか比較対象がようわからん、みたいになってる。

miyagawa: わかんないね、ほんとに。WhatsApp 自体日本ではほとんど知られてないアプリだと思うんで、説明しようと思うんですけど、僕も実は使ってなくてうまく説明できない。アメリカでもほとんど使われてないんですよ。

hotchpotch: え、どこで？ヨーロッパが強い？

miyagawa: うん。ヨーロッパとアジアと、あと中南米みたいな国。新興国っていうのかな。その辺で強いみたいですね。

hotchpotch: 世界的にはトップなんだよね。

miyagawa: メッセージングサービスのなかでは1番ですね。

hotchpotch: うんうん。

miyagawa: 基本的には日本の人には1番馴染みが深いのは LINE だと思うんですけど。LINE と同じような感じで電話番号を元にしてコンタクトリストとシンクしてメッセージングができるっていうただそれだけのサービスで。

hotchpotch: しかも商業的なものっていうのはそんなに入ってない。LINE だったら、例えば、LINE スタンプとかゲームとかと組み合わせて実際売上立ててるんだけど、WhatsApp は年間いくらとか、そういう感じなんだっけ？

miyagawa: そうすね。最初の1年無料で、次の年から年間1ドルで広告なし、有料スタンプとかもまったくなくて、すごくシンプルなモデルでやってる感じですね。で、会社自体も50人くらいでやってるので、Twitter とか Facebook とかと全然規模が違うんだけど。

hotchpotch: 50人とかそんな人数なんだ。メッセージングで世界最大規模だからもっともっとでかいのかと思ったら50人か。

miyagawa: そうそうそう。

hotchpotch: なるほどー。

miyagawa: あとはやっぱり、SMS の代わりなんですよね。で、僕らってあんまり SMS とか使わなくなってる世代っていうのもあって。若い層ではそれなりに使われてると思うんですけど。そこが違いかな、と思っていて。アメリカだとみんな結構 SMS 使うんだけど、日本ってほとんど SMS 使わないじゃないですか。

hotchpotch: ね。ときどきアプリの認証とかでちょっと使うかな、くらいだね。

miyagawa: そうそう。日本の場合は初期にドコモとか J-PHONE とか KDDI とかが Email をガラケーから送れるようになってて、それが無制限だったんで敢えて SMS でやる必要がなかった、っていうのもあるとは思うんですけど。

hotchpotch: 昔はそうか、キャリアメールがすごい強かったから日本は SMS がたいして流行らなかったみたいなのがあったと。

35:27

miyagawa: そうそう。で、アメリカの場合は SMS は結構未だに使われるんだけど、料金プランがどんどんどんどんオプションが少なくなってきていて。今は月額無料のうえに1通10セント、10円とかっていうプランと、あとは、月20ドル、2000円払って無制限っていうそのどっちかしかないんだよね。

hotchpotch: めっちゃ高いね。

miyagawa: 高いんだよー（笑）。ほんとね、AT&T とか Verizon とかはほんとそんな感じで。僕の入ってる T-Mobile は全込みで5000円みたいな感じなんだけど。

hotchpotch: うんうんうん。

miyagawa: 1通10円とかね、普通に気づかないで1通1通やってたらすぐ何千円とかになっちゃうし。かといって無制限の20ドルとかもふざけてるし。

hotchpotch: そうだよね。

miyagawa: どうかな、と思うんだけども。ヨーロッパで流行ってる理由の1つは、推測ですけど、やっぱりヨーロッパって色んな国があって、近くにいろんな人がいるわけですよね。で、例えばドイツに住んでる友だちが来年イギリスに引っ越すとかフランスに引っ越すとか、結構 EU の域内での移動が多いと思うんだよね。そういうときにインターナショナル SMS、国際経由で SMS するとどんどん料金高くなっちゃうから。そういうところでほんとに SMS の代わりみたいに使うっていう用途が多いのかなぁ、とは思うんだけど。

36:56

hotchpotch: でもまあ、今だとね、メッセージングのプラットフォーム、日本だったら LINE が強いし、インターネットを通したやりとり、Facebook Messenger とかね、そういうのがすごい重要になってきてて、そういうところでやっぱり地盤を固めないとね。モバイルのプラットフォームって、そこの部分のメッセージングって重要じゃないですか。Instagram や Twitter も Direct Messaging の重要性に、あ、これ Rebuild で話してたんだっけ？

miyagawa: Instagram はやってたね。Twitter ももうちょっとメッセージングを強化しよう、みたいな感じでやろうとはしてるけど。

hotchpotch: そうそう。やっぱりどこも個人間のメッセージングでより重要になってきてて、そこを握ってると情報のハブ、要するに Email の終焉じゃないけど、個人が Email を使う時代じゃ段々なくなってきてて、そういうやりとりっていうのはアプリ上のプラットフォームに移ってきてるっていうのが、実際に日本を見ていてもそうだし。そんなことになっているから、そこで世界規模のものを Facebook がガツンと買って、そこに乗せて何かをやる、っていうのはね、戦略的には正しいというか、すごい分かるな。

miyagawa: うん。

hotchpotch: Microsoft もさ、1～2年前に Skype 買収してね、ライブメッセンジャーと統合とかやってきたし。色んなところがメッセージングやってると思うんだけど、Google は、そっか、Google Talk...

miyagawa: Hangout ね。

hotchpotch: Hangout か、今は。Hangout をやってきていて、そこはそんなに流行ってるようには見えないけど色々やろうとしているけど、Apple ってどんな感じなの？

miyagawa: そうっすね…Apple は一応 iMessage があるんで、iMessage で間に合ってます、って言えば多分そうなんだけど。多分、Apple はそういう意味ではハードウェアと OS を持ってるんで、そこの上にメッセージングのプラットフォームを敢えて自分で作ろうとかっていうよりは、iOS のエコシステムの中で FaceTime とか iMessage とかで付加価値を出していこうっていう発想だと思うんで。あまり敢えてそこを強化してこうってことは興味はないと思うんだけどね。

hotchpotch: なるほどね。App Store に全部乗ってるし、そこのプラットフォーム握ってるからいっか、みたいな。

miyagawa: そうそう。iMessage はいいとは思うんだけど、SMS を使ってんのか iMessage を使ってんのか分かりづらいってのが1つと、あとは Android の人に送れないってのがあって。

hotchpotch: まあね、Apple だと自分のところは全部うまくやるけど、他のところとのつなぎ込みはっていうところは。

miyagawa: そう、そこはいつもそうなんだけどね。Facebook が買収したのの1つは、LINE ってすごく日本ではすごく人気があって、東南アジアでも結構最近は伸びてると思うんだけど、LINE ってメッセージングだけじゃないんですよね。プラットフォーム化してるっていうか。ゲームとかを出せたり広告配信が出来たり、スタンプ売ったり、いろんなことやってるじゃない。だから、Facebook と競合してるわけですよね。

hotchpotch: うんうん。

miyagawa: だから、Facebook が買うには規模が大きすぎるってのもあるけど、買いづらい会社だと思うんすよね。で、WhatsApp は完全にメッセージングにフォーカスしてるサービスだから、WhatsApp をほっといたら Google とかが買っちゃうんで、他に買われるくらいだったらすごい金出してでも買うっていうのが Facebook のやり方なので。そういうことなんだろな、とは思うんだけど。

hotchpotch: これほどモバイルのメッセージングが重要になるとかって、全然想像もしてなかったからね。3～4年前と今だと結構違くって、もう今は、すごいそこの部分超重要になってるじゃないですか。みんな毎日メッセージングやりとりして、プライベートで。

miyagawa: 最近日本に帰ってテレビを見ると、芸能人の人とかもね、Twitter をやってるのはもちろんそうだけど、LINE の ID を交換してー、とかも普通に喋ってるんで。浸透の仕方がすごいな、とは思いますけど。

hotchpotch: うん。LINE とかはビジネス的なところもすごいな、と思ってさ。あっという間にユーザー数獲得して、その後につなぎ込みが最初の年にスタンプもそうだしゲームもそうだし、今は LINE MALL とかってほんとに EC の方もやりだそうとしているし。すごく展開がうまい、すごい速さでやっていて。これって他のメッセージングのハブで持ってるとこってどこも出来てなかったところだから、そこっていうのはスピート感すごいあるし。横から見ていてすごい面白いな、と。

miyagawa: 確かに。それは思いますね、見てて。

hotchpotch: Facebook はね、いろいろ繋がってるとはいえ Facebook のタイムラインが中心となってものごとが起きていて。むこうの方は完全に個人間やグループ間のもうちょっと小さなミクロ的な部分のビジネスなりなんなりにつなげてやっていってる、っていうのは面白いな、と。

42:12

miyagawa: そうなんすよね。一応、Facebook のメッセンジャーっていうのは頑張ってはいるんだけど、一応オリジナルは Beluga っていうアプリがあって、これが多分2～3年くらい前に買収されて Facebook Messenger になったんだけど。これもさっき言った Acquihire モデルで、Beluga を作った人は全部買収されて、Beluga 自体はすぐシャットダウンするっていうような感じだったんですよね。多分、Facebook とか Twitter と違ってメッセージアプリって相手が1人いれば成り立つんですよね。

hotchpotch: うんうん。

miyagawa: 例えば、Twitter みたいなクローンを僕は今から作ります、ってやっても、5人とかしか登録しなかったら全然面白くないわけですよ。だけど、WhatsApp みたいなメッセンジャーだと、5人しかいなくてもその5人のなかで激しく使ってたりとか、家族全員がそれ使ってれば使い続けるわけですよね。複数のメッセージングアプリを使っても問題はないわけですよ。複数のソーシャル・ネットワークとか複数の Twitter みたいなアプリを書いて、いろんなところにクロスポストして、とかそういうめんどくさいことはなくて。

hotchpotch: うんうん。

miyagawa: 閉じた世界なんで、あの人がこれ使ってるから、っていう理由でそれ使い続けるっていうのはあるわけだよね。

hotchpotch: そうだね。誰か1人やりとりで重要な人がいたらそれを使い続ける理由になるからね。

miyagawa: そうそう。だからそういう意味では Facebook とかみたいに、たくさんの人が使えば使うほど価値が増してくってのは、WhatsApp ももちろんそうかもしれないけど、人数が1～2人でも1000人で使ってる人でも価値は変わらないっていうところはあるんすよね。

hotchpotch: なるほど。

miyagawa: そんなところは思いますけど。

hotchpotch: ふんふんふん。

44:49

miyagawa: Apple の iOS の新しいアップデートが出てましたけどね。

hotchpotch: あぁ、7.0.6。

miyagawa: 結構これやばいセキュリティのアップデートらしくて。なんか SSL の認証のコードにバグがあって。公開されてる diff を見たんだけど結構面白くて。goto 文が書いてあるんですよ。if ～ goto でループを抜けるんだけど、それが多分マージミスってて、C 言語なんで if のあとにブラケットなしで goto って書いて、その後ろにもう1回 goto って書いてあるんだよね。だからその if の影響範囲って C の場合はブラケットつけなければ次の行だけなんだけど、だからその次にもう1個 goto があるのはその if の条件に関わらず必ず goto しちゃうわけよ。

hotchpotch: うんうん。

miyagawa: だからそれで全部セキュリティチェックが漏れてて、SSL が無効なやつでもそのまま読みにいってしまうっていうバグだったらしい。

hotchpotch: すごいねこれ。僕も今 diff 見たけど、goto fail; goto fail; って2行書かれてて。

miyagawa: （笑）

hotchpotch: これねー。これ難しいね。ちゃんとテスト書かれてないと。人が見たらうっかり「別にいいんじゃないの、この実装で」でマージしちゃって。

miyagawa: 多分これマージミスだと思うんだけどなぁ。マージしたときにコンフリクトしてその人が修正するときに goto が2個残っちゃったんじゃないかと思うんだけど。

hotchpotch: しかもね、パッとテストしたときの挙動がさ、例外な部分チェックしてないとこれ気づかないから。「問題なく使えてるじゃん」っていうので。

miyagawa: Apple のテストカルチャーの問題かもしれないけど。結構面白いかな。

この話すると長くなるからしないけど、こないだね、Chrome の人とちょっと話した時に、Apple と Google ではテストの仕方が全然違うみたいな話をちょっと聞いて。それが面白かったんすよね。Apple はレンダリング結果のテストをするのにピクセル同士のテストしかしないらしいんですよ。要は「こういうページがあってこういう CSS があるとこういう結果がレンダリングされるはず」っていうテストケースはばぁーっといっぱい書いてあるのね。で、その結果は全部ピクセルで、画像が置いてあってそれと1ピクセルずつ合ってるかどうかっていうテストだけする感じなんすよ。

で、Google の場合はそういうのじゃなくて、CSS にバグが見つかったらコーナーケースをガンガン書いていって、この場合はここの影がちゃんと出てるか、とかそういうテストを執拗に書くんだけど。当時は WebKit 一緒だったからそういうテストをマージしようとすると「こんなくだらないテストはいらない」とか言って、「最後の、画像が合ってるかどうかのテストだけやればいいんだ」みたいな感じで、Apple の人はマージしてくれなかった、みたいな裏話を聞いて。そういう Apple と Google のテストに関する考え方が全然違う、みたいなところはあるっぽいっすよ。

hotchpotch: 面白いね。その、外側の最大のアウトプットのところだけをやるべきか、内側のユニットテスト、コーナーケースをすごい考えてやっていくか、みたいなね。

miyagawa: そうそうそう。

hotchpotch: よくある「テスト書きすぎ問題」と一緒でね、コーナーケースのテストばっかり書いていくと、実装ガラって変えたときにそこが出来なくなってみたいな話とか。お互いの思想の違いみたいなところも色々あるんだろうね。

miyagawa: その辺の話はね、特に Chrome の人で WebKit に関わってた人から聞くと色んな話が聞けて面白いっす。

hotchpotch: OSS のプロダクトをさ、推進してる会社が、1個の会社で全部やってるんだったら分かるんだけど、色んな会社が入ってたりするとお互いのところの会社の文化の違いが、みたいなところですごい大変そうな感じするね。

miyagawa: うん。あとね、似たような話だと Memcached の開発とかは Six Apart で元々やってたんだけど、Google とか Twitter とか Last.fm とかが色々パッチを提供してくれたりするんだけど、あるとき Twitter とかが完全に fork したやつを出して。「なんでこれをパッチにして提供してくれないんだ！」って本家の開発の人が怒ったりとか。色々ね、企業のエゴみたいなのも結構あるんだよね。

hotchpotch: なるほどねぇ。自社内でやれれば政治的な話はしなくて済むから楽、みたいなところもあるんだろうけど。

miyagawa: そうそう。そういうのに嫌気がさして WebKit をやめて Blink だったっけな、そういうエンジンに変えたりとか。ま、それだけではないとは思うけどね。そういうのも一部には多分あるんだろうな、という気はします。

hotchpotch: なるほどねぇ。

miyagawa: はい。ま、そんなところですかね。

hotchpotch: そんなところですかね。

miyagawa: 舘野さんの Twitter は @hotchpotch ですね。

hotchpotch: です。

miyagawa: コメントとかあれば、ハッシュタグで #rebuildfm などにもらえればと思います。Show Notes、さっき言った Apple のパッチの紹介とか、そういうページは http://rebuild.fm/33 から見れますんで、感想などお待ちしています。

hotchpotch: お待ちしています！

miyagawa: はい、じゃ、そんなとこで。

hotchpotch: はーい。

miyagawa: はい。ありがとうございました。

hotchpotch: ありがとうございましたー。

---

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