move fast

どんな本?

podcast でエンジニアインタビューを行っている著者が facebook 社員のインタビューをまとめたもの
facebook 内部の情報や体制、文化などが書かれている

感想

SNS 黎明期でとにかくユーザをとるために素早く開発しリリース、一時はGoogle とも戦いながらも勝ってきた facebook の開発力や体制が垣間見えたのは面白かった。開発者の手元で動作確認ができたら本番にリリースされ、バグっていたらすぐ修正する。そんな綱渡りのような開発でも価値を出し続けていったのは当時の競合などへのひりつきが見えた。1週間で基本的にリリースしていくなんて自分はやったことないが、toC ではそれが日常なんだろうか。そのペースでユーザに価値を提供でき、数字もついてくるならよっぽど楽しいだろうな。 仮に1週間でリリースするとなったら

• Day-1: 設計fix 開発
• Day-2: 開発
• Day-3: 開発
• Day-4: レビュー/リリース判断
• Day-5: 修正開発/レビュー/リリース

みたいな感じか。こう考えると手を動かして機能開発以外のプロセスは自動化されているのが必然。

• ユニットテスト

• E2Eテスト

  • ブラウザ or モバイルを通してのテスト
• デプロイ

機能ができても、他に影響がないかの確認や結合時に意図しない動きをするのはよくあるし確認に時間かかったりするので自動化できていれば強いと思った。ある程度の規模までソフトウェアが育ってきたらなおさらだろう。

製品の大枠方針などはトップダウンで決められるとしても、ボトムアップで何かしらイノベーションを起こすモチベーションを持って、何か作ってみるのはやってみようと思った。色々情報を集めてはいるが、動くもので社内から反応を集めたい。机上での説明は想像しにくかったりで賛同を集めにくい。code wins arguments はシンプルだけどエンジニアがやるべきことを凝縮していると思った。

要点など

• facebook は最初HTML5でmobile application 対応しようとしていた

  • しかし、パフォーマンスが思うように出ず、結局ネイティブ対応に切り替えた

    • 開発力を確保するために会社ごと買収などした

    • 当時はiphone が出たばかりでモバイルアクセスよりもデスクトップアクセスが圧倒的に多かった

      • しかし、今は9割がスマホ経由のアクセス

• Google+ は明確な競合で、彼らを打ち負かさないといけなかった(2011)

  • マークザッカーバーグがとったのは、ハードワークでとにかくプロダクトを進めること。これをしないと自分たちが締め出されてしまう。ゼロサムゲームに勝利しなければならない

    • その週の日曜、facebook の駐車場は満車。一方google はいつもどおりの休日

      • google は勝つために仕事をしていない

      • 結局このコミットの差が大きく働き(?)、facebook はソーシャルネットワークの雄の座を明け渡さなかった。

        • ハードワークがどのくらい寄与したかはわからないけど、トライアンドエラーを多く実行できるのはサービスとして強いのではないか
      • google は個々のサービスは非常に優秀だが、ソーシャルでは力を発揮できなかった。自分たちでサービスを悪くしていってしまった

• cash cow

  • 大きな収益源になっているサービス。その元

• Facebookでは、新製品の開発はボトムアップで行われることが多い。一人のエンジニアが、ある機会を見つけては、時間をかけてプロトタイプを作って試してみる。プロトタイプの開発は、エンジニアが日々の仕事の傍ら、夜や週末に働いて何かを作ろうと決心することが多い。また、上司の許可を得て、数週間かけて試作品を作る場合もあります。また、Facebookのクリエイティブなプロセスは、ハッカソンを通じて体系化されています。

  • しかし、製品を成熟させるにはユーザに繰り返しさわってもらって、改善をする投資が必要不可欠

• Instagram 登場時、facebookは、facebook camera で対抗するも勝てなかった。

  • しかし、そのおかげでソーシャルフォト市場を直接理解することができた

    • 10億ドルでも割安だという判断に至った。(当時Instagram は13人だった模様)

• facebook は新しい製品開発をする上で贅沢な立場にある

  • まず、莫大な広告収入がある

  • 興味深いデータの宝庫にアクセスでき、フェイスブックのエンジニアはデータを研究し、幅広い最先端のツールを使って製品を作れる

    • facebook では新製品開発などの実験が盛んに行われている

      • 実験は単に貸借対照表を改善するだけではなく、企業の心理的な健全性にとっても重要です。
      • 強力なエンジニアリング組織には、エンジニアが創造性を発揮できる場が必要。
      • 毎日ソフトウェアのメンテナンスをしている優秀なエンジニアは、自分の夢が消えていくのを感じ、モチベーションを失ってしまいます。
      • そのようなエンジニアは、しばしば会社を辞めて、自由に発明できる場所を探します。エンジニアが日常的に実験することを奨励しない組織では、エンジニアリング文化は、実験する能力やモチベーションのないエンジニアを選ぶことになります。そうなると、会社はメンテナンスモードになり、ゆっくりと死んでいきます。

• Facebookは個人を重視している。

  • 経営陣は、個人が創造性を発揮できるように配慮している。
  • フェイスブックの従業員は、会社全体でも個々のチームでも、強い社会的結束力を持っている。これは、組織全体の従業員が、自分たちが重要なことをしていると心から信じているからこそ可能。
  • Facebookの製品の方向性はトップダウンで決められていますが、個々の社員には自由があり、ボトムアップでイノベーションを起こすモチベーションがあります。
  • また、Facebookには、"code wins arguments “ をはじめとする独自の文化的規範があります。これらの規範は、ブートキャンプと呼ばれるオンボーディングプログラムの中で、新入社員にすぐに植え付けられます。
• "私は、エンジニアが好きな仕事をすることを最適化します。" エンジニアは創造的に満足しているときに最高の仕事をするので、エンジニアは仕事中の75％の時間を情熱的なことに費やすべきだと考えている。by トム・オッキーノ (React チームのマネージャ)

• facebook のエンジニアリングモビリティ

  • エンジニアが同じチームに1年間在籍した後、"hack-a-month "と称して、別のチームでの経験を試してみることを奨励しています。そのチームが気に入らなければ、元のチームに戻ってもいいし、別のことをやってみてもいいのです」

• エンジニアがFacebookに入社すると、最初の数週間はFacebook bootcampというプログラムで、Facebookのエンジニアリング基準やベストプラクティスを学ぶことになります

  • エンジニアはブートキャンプの最初の数日間でコードを出荷することが期待されています。
  • 大学を卒業したばかりの人でも、20年の経験を持つ業界のベテランでも、誰もがブートキャンプを経験しなければなりません。ブートキャンプは、このように偉大な平等装置なのです。博士号を持つコンピューターサイエンティストは、Facebookに入社してCSSのバグを1週間かけて修正するかもしれません。人工知能の教科書を書いている人は、MySQLデータベースの設定に苦労するかもしれません。ブートキャンプは、あなたがどんな人であっても、組織が必要としている仕事をするというメッセージを送ります。

• 自分のプロジェクトを売り込めないマネージャーは、悪いチームに所属することになり、成功することができません。

  そのため、ダメなマネージャーはすぐに淘汰されてしまいます。ブートキャンプとヘッドカウントは、最高のプロジェクトと最高のマネージャーに体系的に報酬を与えます。

  トム・オッキーノのように高い評価を受けているマネージャーにとって、このプロセスは、彼が募集しているヘッドカウントがブートキャンプの卒業生にすぐに注目されることを意味します。トムのチームに参加したいブートキャンプ出身のエンジニアが続々と集まってくるので、Reactグループは人の入れ替わりに強くなっています。もしエンジニアがトムのチームを辞めたいと思っても、すぐにReactで働きたいと思っているブートキャンプの新卒者が流入してくることを彼は知っています。ブートキャンプとヘッドカウントは、Facebookが急速に成長しているからこそ可能なのです。

• Facebookの膨大なコードベースは、意図的に1つの大きなファイルシステムとして構成されており、インフラチームはニュースフィードチームのコードを見ることができ、ペイメントチームはグループチームのコードを見ることができます。このコード管理戦略は、"モノリシック・リポジトリ "と呼ばれています。

• 2009年までのFacebookでは、ユニットテストはゼロでした。新機能が開発されると、開発者は自分のローカルマシンで手動でテストを行いました。インターフェイスをクリックして、すべてが期待通りに動作することを確認した後、開発者はそのコードを本番環境にプッシュしました

  • move fast という考え方のもと、早くコードを出して、バグれば早く修正していた

    • 最終的には、テストの不足がFacebookの開発ペースを狂わせることになりました。リリースプロセスには新たな制約が課せられ、Facebookは「テスト駆動開発」と呼ばれるソフトウェアエンジニアリングのスタイルを採用しました。
• Facebook社での経験をもとに、チャックはモバイル開発者に1週間のリリースサイクルを勧めている。「モバイルでは、コアプロダクトを毎週リリースする必要があります。そうすることで、アプリを存続させることができます。そうすれば、アプリを存続させることができ、正気を保つことができます。もしできないと思うなら、やってみるべきです。無理をしてでもスピードを上げれば、修正すべき点が洗い出されるはずです」。チャックは、モバイルでの1週間のリリースサイクルを誇りに思うのも無理はない。

• 2015年にfacebookはgraphql を oss 化した

  • フロントエンドとバックエンドの間の抽象

    • モバイルなどネットワーク弱いクライアントでも適切なデータを取得できるようになる

      • これまではカスタムのサーバエンドポイントが必要だった

  • 理想的なリクエストパターンは、その時々に必要な量のデータを正確に取得することです。「一番苦労したのは、ニュースフィードの問題でした。1回のネットワークリクエストで、ニュースフィードオブジェクトに必要なすべての情報を取得する方法が必要でした」。フェイスブックは、デスクトップ用に使っていたネットワークツールと同じものをモバイル用に使えないことが明らかになりました。

    • 例えば、graphQLで細かくデータ区切っておけば低帯域、低機能のホストでも動くように細かくfetch して動かすことがクライアントによってはできる

• 「私が入社したとき、私は180番のエンジニアでした。入社したとき、私は180番のエンジニアで、会社は設立5年目でした。毎日2億人のアクティブユーザーがいました。そして、コードベースにはテストがゼロでした。ゼロだ」マイクロソフトで働いてたニック

  • ただ、バグでユーザに悪い体験が多く提供され始めると改革が始まった

• Facebookでは、カレンダー、会議室の予約、ビデオチャット、問題の追跡、コードレビュー、コンテンツの修正などのソフトウェアを独自に構築しています。今日では、新しい会社がこれらのソフトウェアをすべて自社で構築することは狂気の沙汰のように思えます。平均的なスタートアップ企業は、Zoom、Googleカレンダー、GitHub、Slackなどの既製のベンダーを利用しています。しかし、FacebookはこれらのSaaSツールがすべて利用可能になる前の2004年に設立されました。Facebookはコミュニケーション・ソフトウェアやコラボレーション・ソフトウェアを社内で構築しており、それらのソフトウェアはすべて社員のFacebook IDに関連付けられています。一般的なソフトウェア企業では、ツールはすべてバラバラです。お互いにスムーズに会話ができないのです。Facebookで働くと、ビデオ会議からコードレビューまで、すべてのツールで仕事のアイデンティティがシームレスに統一されます。

  • ほんとなのか・・?

• HHVM の前身は php を c++ に直接変換するものだった。

  • php→c++→コンパイルは長時間かかるのでJITが実現できないか検証

    • v8 の上でphpを動かそうとした

      • 高コストで断念↓あんまりよくわかってないので原文訳まま

        PHPのクレイジーなところは、参照カウントのセマンティクスをPHPプログラムに公開していることです。V8やJVM、その他のJITランタイムの上でPHPランタイムを実行しようとすると、トレースコレクションのメモリフットプリントに加えて、参照カウントのメモリフットプリントを扱うことになります。このように、それぞれのランタイム環境で通常直面するオーバーヘッドが複合的に作用することになるのです

        • 自社で作るっきゃない → HHVM
        • こうした低レイヤを改善するエンジニアがいることで製品開発チームは無限といっても過言ではないリソースを手にしている。