「フェイスブック 不屈の未来戦略」を読んだ
フェイスブックの開発者の一人が描いたフェイスブックのこれまでとこれからのインサイドストーリーをまとめた本。創業ストーリーの内情を熱く語るというより、フェイスブックの成功が「偶然」ではなく「努力の成果」であると語るように、戦略についてメインで書かれている。一気にすらすら読めた。
フェイスブック 不屈の未来戦略 (T's BUSINESS DESIGN)
- 作者: マイク・ホフリンガー,Mike Hoefflinger,滑川海彦,大熊希美
- 出版社/メーカー: TAC出版
- 発売日: 2017/06/26
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (1件) を見る
以下、印象に残ったエピソードや言葉をまとめていく。最後の方に出て来るが、フェイスブックがバーチャルギフトを早くに試していたのは知らなかった。
フェイスブックの起点
多くの人はインターネットで情報を検索するのに検索エンジンを使うだろう。しかし、ザッカーバーグは人を検索するためのツールがないことに早くから気づいていた。リーダーであるザッカーバーグ、そして会社としてのフェイスブックの起点はそこになる。
ザッカーバーグは最初に大学のコースマッチのサービスを製作しはじめた。
世界トップ集団の共通点
ミッションを遂行する熱意を絶やさない
彼らが掲げたミッションは大規模で長期に及ぶものだ。周りは達成できないだろうと信じず馬鹿にするか、彼らの真似をして競合となった。まだ存在しないものを形にするには、外部からの圧力と内部で発生する問題と向き合わねばならない。普通のリーダーならそれだけで気力をそがれるところだが、トップ集団は違う。
例として、ジョブズ、ラリー・ペイジ、そしてザッカーバーグが挙げられている。
スティーブ・ジョブズの「人類の進歩をもたらす思考ツールを作る」というミッションにおける最大のブレークスルーは、最初の製品を出してから30年後に形になった。ジェフ・ベゾスも「地球上で最もカスタマー視点で考える企業」を構築するのに30年かけている。ラリー・ペイジが「情報を整え、世界中どこからでもアクセスできるようにする」ために始めた会社と同時期に誕生した子供は、もう大学に入学する年齢だ。ザッカーバーグの「世界をよりオープンにつなげる」、イーロン・マスクの「持続可能な交通システムの確立」の冒険は10年を過ぎたところだ。
愚かで賢いビジョナリーである
彼らには、他人に見えないものが見えている。もしくは、他人がとるに足らないと思うものに注目している。愚かなアイデアには何の意味がない。賢いアイデアには人が殺到する。賢いアイデアよりはるかに重要なアイデアは、一見愚かに見えるアイデアだ。それが賢いアイデアであると競合が気づく前から彼らは動き出し、大きく差をつけるのだ。
誰よりも早く、プロダクトを作る。
プロダクトを軸に優秀な開発者を惹きつけるアカデミーを作る
ミッションを達成できるかどうかはプロダクトの品質にかかっている。そして、プロダクトの品質は、そのプロダクトを手がける人の才能、目的意識、努力に影響される。未来を作るという強い信念を持つリーダーは、優秀な人材を採用することに時間を使い、直接彼らと働くこちに重点を置いている。
ジェフ・ベゾスはアマゾンの株主向けの手紙にこう書いている。
「野球とビジネスの違いは、野球では成果が限定されていることです。バットを振った時、ボールをいかに確実にとらえていようと、その一振りで得られる点数の上限は4点です。しかし、ビジネスでは打席に立った時、1千点獲得できるチャンスが時折やってきます。たった一振りでそのようなリターンを得るためには、強く大胆でいることが重要です。」
優秀な開発者が会社にいることで、強く大胆に動けるというエピソード。
「いいね!」ボタン
2006年時点のニュースフィードは、単にユーザのクリック数、コメント、シェア、投稿の非表示、スパム報告などを解析するだけだった。しかし、2009年2月に「いいね!」ボタンが登場したおかげで、ニュースフィードでの解析範囲は大幅に拡大した。ユーザのエンゲージメントは10倍近く増え、「いいね!」ボタンはニュースフィードにとって空気のように欠かせない存在となった。「いいね!」ボタンは登場してから最初の3年でおよそ1兆回使われた。以前のコメント数とは比べ物にならない数字だ。
今や定番になった「いいね!」ボタンに関するエピソード。
多言語化によるグロース
フェイスブックでは、マイスペースのようにサービスの提供地域を決めて、数十人規模のチームを翻訳に充てたり、プロの翻訳者に翻訳を依頼したりすることはしなかった。フェイスブックチームは自社プラットフォーム上に翻訳のための専用アプリケーションを開発した。このアプリはフェイスブックのサイトを30万のワードやフレーズに対象となる言語のユーザにクラウドソースの要領で翻訳を依頼するものだった。ユーザ自身がサイトを翻訳し、良い翻訳に投票していく。最後にプロの翻訳者がサイト全体をチェックするという手法で、フェイスブックは多言語化サイトを制作した。これにより、フェイスブック初の多言語化ページであるスペイン語は2週間で、ドイツ語は2日間、フランス語はたったの24時間で完成させることができた。
上記の手法により、より多くの人がフェイスブックを利用できるようになった。
フェイスブック・ゼロ
2010年5月、新興市場向けにピリハピティヤは最小限のテキストだけを表示するフェイスブック・ゼロをローンチした。フェイスブックは、45の国に及ぶ50の事業者と提携し、彼らのネットワークを介してフェイスブック・ゼロを利用する場合は、データ通信量がかからない仕組みを作った。
さらにより多くの人がインターネット上で人と通じるという価値に気づいた。
ペタバイト、エクサバイト
今では毎日、何十億人というユーザに数千億のコンテンツを届け、100億以上の「いいね!」、コメント、シェアのデータを収集している。10億以上の投稿写真を保存したりするためには、毎日数ペタバイトの容量が必要になる。ペタバイトは100万ギガバイトだ。ユーザがアップロードした写真をすべて保存しておくには、さらに数エクサバイト(数十億ギガバイト)が必要となる。
フェイスブックはネットワークや電力消費までを自社で設計している。
日本
日本の人口は、中国の10分の1未満の約1億2000万人だが、この国の広告の市場規模はアメリカと中国についで、3番目に大きい。2018年の広告試乗は430億ドルと推定され、日本人1人当たりの広告費は中国の6倍、インドの35倍にもなる。フェイスブックにとっても日本のユーザを獲得する価値は高い。日本では人口の91%がインターネットを利用しているが、フェイスブックのユーザ数は2500万人で、シェアは22%にとどまる。
実名性と日本の文化の相性の悪さ。インスタグラムが鍵になる。
バーチャルギフトの失敗
フェイスブックが早くに展開したバーチャルギフト(2007年2月から2010年7月)やクエスチョンズ(2010年7月から2012年10月)といった機能は、社内でもサービスを強化し、ユーザエンゲージメントを高めることができると期待されていた。フェイスブックのユーザは頻繁に友達の誕生日を祝うし、友達の友達から知識を得るということも行っていた。上記の2つの機能は、こうしたユーザの行動を軸にしたものだった。ただ、これらの機能はコミュニティーの一部で人気を得たものの、フェイスブックが目標とする月間数千万人が利用するような機能にはならなかった。面白いことに、この2つの機能におけるグロースの妨げとなったは正反対の要因だった。「バーチャルギフト」の課題は、この機能を活用するユーザを十分獲得できなかったことだった。誰かがフェイスブックで友人にギフトを送っているのを見たら、それを他のユーザも真似しようと試みるだろう。しかし、そもそもそうしてギフトを贈るロールモデルが少なかった。一方、クエスチョンズでは、投稿された質問に専門家でない人たちが回答しすぎていた。
バーチャルギフトを早い段階で展開していたが、上手くいかなかった。
10の教訓
著者はフェイスブックの成長を10の教訓としてまとめている。
- あなたにとって最後の仕事は何か
- フェイスブックは独立した上場企業となるために、ヤフーの買収を断った。ザッカーバーグは世界をよりオープンにつなげる計画を実行している。
- 機能の引き算は価値の足し算
- フェイスブックはニュースフィードを開発した。ユーザ規模が100倍になっても品質の高いニュースフィードを届けられるよう、プロダクトの改善に努めてきた。
- 北極星、マジック・モーメント、コア・プロダクト・バリュー
- フェイスブックはそれぞれの専任チームを置いて、誰よりも細かく数字を追った
- すべてのカスタマーに価値を提供できるなら、みんなが喜べる
- フェイスブックはニュースフィードにオークション型の質の良い広告プロダクトを導入した
- 速さは価値
- 世界で最もエンゲージメントの高いサービスを提供するため、フェイスブックはソフトウェア、ハードウェア、ネットワーク、設備とその電力消費まで自社で設計している
- 最大の某業は先にキャズムを超えること
- Google+に勝てたのは、キャズムを超えていたから
- 誰かが革命を起こす前に自身を改革せよ
- ザッカーバーグはインスタグラムのCEOと1対1で話し合い、競合他社が買収するよりも前にインスタグラムを買収した
- 盤石なビジネスがあれば、未来のために投資できる
- ザッカーバーグは中国、日本、インドで直面している課題を乗り越え、成功するには時間がかかることを認識しているが、足元が盤石なため、取り組むことができる
- 社員のエンゲージメントがすべて。人材の強みだけに光を当てる
- フェイスブックでは、社員全員がそれぞれにとって最もエンゲージメントの高い仕事に着手できるかんこ油を整えている
- 誰より真剣にミッションを追求する
- フェイスブックが成功したのは、どんなに苦しい時も、彼らがミッションを追求することをやめなかったから
10の質問
10の教訓に対する、質問もまとめられていた。会社やプロダクトを振り返る要素として良さそう。
- あなたが作っているのは、機能か、プロダクトか、ミッションか?
- あなたのプロダクトは何を便利にしているか?
- あなたのプロダクトが目指すべき北極星、マジック・モーメント、コア・プロダクト・バリューはなんだろうか。
- あなたのプロダクトがすべてのカスタマーに提供する価値は何か?
- 通信インフラをより盤石にするために何ができるか
- あなたのサービスの普及率はどれくらいだろうか。競合の普及率はどうだろう?
- あなたなら自社をどのようにディスラプトするだろうか。今すぐそれを実行に移そう。
- 長期の目線で戦略を建てているだろうか。その施策は時間をかけて取り組む価値があるだろうか。会社の中核となるビジネスは順調に推移しているだろうか。
- その日、一番良かった出来事は何だったか、最後に社員に聞いたのはいつだったろうか?
- あなたは、他の会社よりも真剣に自社のミッションを追求しているか?
まとめ
フェイスブックがここまでグロースできた経緯がまとまっていて、興味を持って読むことができた。とにかく早く価値のあるプロダクトを出して、キャズムを築いて、プロダクトをグロースしていくことが大事だと改めて思った。
NakamyにPNGの圧縮処理を入れた
iPhoneのホーム画面のスクリーンショットは1MB ~ 2MB程度の容量があり、すぐにS3を圧迫してしまう懸念と、ホーム画面一覧の表示速度が遅いので、圧縮処理を入れた。
アップロードには、carrierwaveを使っているのでcarrierwaveの処理内に圧縮処理を追加した。PNGの圧縮処理にはpietを用いた。
- carrierwaveuploader/carrierwave: Classier solution for file uploads for Rails, Sinatra and other Ruby web frameworks
- albertbellonch/piet: A perfect image optimizer for Ruby
圧縮のアルゴリズムとして、optipngとpngquantが選べる。optipngは可逆圧縮で、画像の劣化はないが、1MB => 700KBぐらいの圧縮率。さらに処理時間が最速のオプションを選択しても、少し長い。対して、pngquantは非可逆圧縮で画像は劣化するが、1MB => 200KBぐらいの圧縮率で、処理時間も短い。TinyPNGなどでも使用されている。
画像解析用に可逆圧縮バージョンも残しておこうと思ったのだが、そもそもiTunes Search APIで取れるApp Store上のアプリの画像とホーム画面のスクリーンショットを撮った時の各アプリの解像度が違ったので、潔くpngquantで圧縮することにした。
書き加えたのは下記。
# Gemfile gem 'piet' gem 'piet-binary'
# app/uploaders/image_uploader.rb include Piet::CarrierWaveExtension process :custom_optimize def custom_optimize pngquant end
あと、ansibleに下記を加えて、EC2の環境を整えた。
# main.yml - yum: name=pngquant state=latest enablerepo=epel
そのうち、新しいホーム画面がアップロードされていくと、ホーム画面一覧画面の速度が改善されるはず。
第12回若手Webエンジニア交流会でLTしてきた
概要
下記に参加してきた。
第12回若手Webエンジニア交流会 #wakateweb - connpass
発表資料はこちら。
所感
懇親会で、「Nakamyの人ですよね?」と話しかけられたのが嬉しかった。
若手Webには、学生も多く参加していて、学生の発表者も多かった。若手の勢いを感じた。
宣伝
弊社でMeetupなるものを開催するそうなので、良かったらぜひご参加ください。
Nakamyで友達情報を更新できるようにした
Nakamyのホーム画面一覧ページに上記のようなボタンを追加した。このボタンを押すと、友達情報を更新できるようにした。これで、自分より後から登録した友達のホーム画面も一覧で確認できる。Nakamyについては下記参照。
Nakamyというサービスをリリースした🎉 - Webナントカ
この機能を使ってみて、やはり一定件数以上を一覧表示する際に画像が重たいので、画像のファイルサイズ圧縮に取り組んでいく必要性を感じた。とりあえず、早めにページネーションを実装したい。
その他やったこと
Slackチームを作って、通知を受け取れるようにした。連携したのは、下記サービス。
- Github
- Sentry
Githubはissueが作成されたら通知が行くようにした。Sentryは最近社内で採用しているので、個人プロジェクトでも導入した。他のエラー通知系のサービスとの価格比較は下記記事にまとまっている。どのみち個人で使う分には、無料枠で収まるのだが、将来的に課金することになった際の価格帯の安さと機能やUIに使い慣れる意味でSentryを選んだ。
エラートラッキングサービスの比較 (as of 2017/09/20) - Qiita
(エラーが発生すると、通知されるようになったので、バシバシとエラーを上げてください 🙏)
Nakamyというサービスをリリースした🎉
Nakamyとは
URLは https://nakamy.com
友達がiPhoneをどのように使っているか気になったことはありませんか?
Nakamyは友達のiPhoneの中身を覗けるサービスです。ホーム画面のスクリーンショットをアップロードすることで、Facebook上の友達とホーム画面を共有でき、友達がインストールしているアプリを見ることができます。
将来的には、友達だけでなく、年齢情報や職種などの属性でホーム画面を探す機能を追加し、新たなアプリとの出会いをサポートしていきたいと思っています。
上記のようなサービスを開発した。
基本的に、自分のホーム画面をアップロードすれば、友達のホーム画面が見れるという仕組みである。現状、友達のホーム画面一覧しか見れないが、将来的には、ユーザ属性による検索やアプリのレコメンドをできるようにして、アプリを探す時のサポートをしていきたいと思っている。
まだまだ機能的に足りない部分が多いが、友達のホーム画面が見れることが最低ラインだと思ったので、MVPとしてリリースすることにした。たぶん、世に言う、αリリース。
開発したきっかけ
自分はiPhoneユーザなのだが、世の中に便利なアプリがたくさん溢れている中で、自分がインストールしているアプリは多くても200個ぐらいで、さらに日常的に使っているアプリは数十個で、もっと便利なアプリを知るきっかけがあると良いなと思っていた。
そのため、知人や友人とご飯に行く際に、「どういうアプリ使ってる?なんかおすすめない?」みたいな会話を積極的に行っていたのだが、そこで話題に挙がるアプリは1つか2つ程度で、結局あまり引き出せず、それならいっそ、ホーム画面をアップロードさせて、それを画像解析して、共有すればいいのではというアイデアを思いついたのがきっかけだった。
さらに、ホーム画面は、フォルダに格納する派なのか、並べ方は見た目を重視しているのか、カテゴリで分けているのか、普段スマホを持つ手は右手なのか、左手なのか、など、その人ならではの使い方が出るので、面白さを感じていた。色んな人のホーム画面を見てみたいと思っていた。
(ちなみに、iOS9からURLスキームでホワイトリスト方式に変わり、アプリ上で、iPhoneに入っているアプリのリストを取得するのは困難となった)
開発にかかった期間
大体2ヶ月ぐらいかかった。個人開発なので、使える時間が少ない上に、モチベーションに左右されるので、なかなか進捗しなかった。
開発に入る前に、技術構成を練るフェーズと画像解析を試してみるフェーズがあった。
技術構成を練るフェーズでは、 react_on_rails_on_SSR_on_SPA_with_HMR_with_redux_with_CSS_Modules
な環境を作るところまでいったが、環境構築で満足してしまった。その他、アプリ化することを考えて、RailsでAPIを書いて、フロントはnext.jsという構成を考えたり、色々妄想と試実装を繰り返していたが、それだけで月日が経っていってしまった。結局、MVPの検証からやろうということで、速度優先で、シンプルにRailsのViewを使ってシンプルにアプリケーションを書くことにした。後から一部をVueコンポーネントに置き換えていくことを構想している。
画像解析の方は、簡単なテンプレートマッチングを実装したのだが、いかんせん、画像全体だと比較回数が増えすぎてしまうので、ホーム画面からアプリ画像を切り出す処理を書いたところで、止めている。結局MVPで必要なものは、「友達のホーム画面を見ること」という結論に至り、アップロード機能など、アプリケーションに必須な部分の実装を優先することにした。
今後の実装予定
今の実装のままだと、先に登録した人は後から登録した友達のホーム画面を見ることができないので、取り急ぎ、友達情報の更新機能を実装していく。その他については下記のIssueに方針をまとめた。
今後の開発予定 · Issue #1 · kikunantoka/nakamy_issue · GitHub
バグ報告、改善要望は大歓迎なので、下記リポジトリでissueを立てるか、Twitterで連絡していただけると助かります。
Issues · kikunantoka/nakamy_issue · GitHub
キクナントカ(@kikunantoka)さん | Twitter
今後のプロダクトの磨き方
とりあえず、現状だと、Facebook上の友達が使っていないと何もできないので、友達以外のホーム画面の一覧を見れる機能を実装した段階でプロモーションをかけていきたい。AWSの無料枠が使える1年の間にサーバ代を賄えるぐらいのマネタイズも行いたいと思っていて、逆に1年以内に芽が出なければ、個人で赤字をひたすら垂れ流すサービスをやっていてもしょうがないと思うので、閉じる判断をした方が賢明な気がする。その辺りも上手くやっていきたい。
終わりに
僕とFacebookで友達になっていて、興味を持った人は、良かったら使ってみてください。
そういえば、早いもので、昨日で今の会社に入社してから1年が経った。この1年で草がだいぶ生い茂った気がする。