要約:
Facebookは「開発者が主導する文化」によって数々のイノベーションを起こしていることで知られている。彼らは新しい機能や仕組みについてのリリースノートを公開しているが、そのほとんどは「それが何か」についてであり「どうやって」ではない。このノートは、そんなFacebookの文化の実態について、Facebookの友人たちが教えてくれたものをまとめたものだ。

僕はFacebookのやり方に魅了された。それはとてもユニークな仕組みで、そう簡単に真似できるものではない(真似しようとしても、どんな企業にとってもその仕組みが上手く機能するとは限らない)。このノートは、Facebookがいかにソフトウェアを開発し、リリースしているかについて、Facebookの友人たちと会話した記録を集めたものだ。

Facebookにはみんなも興味を持っているみたいだね。彼らの「開発者が主導する文化」は多くの人々に注目されるようになり、また多くの企業たちが、どうやったらそのような文化を作れるかと試行錯誤している。一方Facebookは、その仕組みが内部的にどうなっているかについては極めて秘密主義だ。Facebookの開発チームは新機能や仕組みに関するノートを公開しているが、そのほとんどは「それが何か」についてであって、「どうやって」ではない。Facebookがどのようにしてイノベートし、競合他社よりも効果的にサービスを最適化しているかを外から知ることは容易ではないのだ。私は、部外者の一人としてFacebookのやり方をもっと知る事を試み、数ヶ月間にわたって観測したことを整理した。ソースのプライバシーを尊重し、人の名前や特定の機能/製品に対する言及はすべて削除した。また、このノートを公開するまでに6ヶ月の期間をおいた。そうすることでこれらは少しは「時効」になる。 I hope that releasing these notes will help shed some light on how Facebook has managed to push decision-making “down” in its organization without descending into chaos… It’s hard to argue with Facebook’s results or the coherence of Facebook’s product offerings.多くのコンシューマ向けインターネット企業がFacebookの例から学ぶことができると思っているし、そうしてくれることを願っている。

Facebookの内部に対する考察をまとめることに協力してくれたみなさんに大きな感謝をしている。 epriestfryfrog のように加筆修正してくれた方々にも感謝している。

ノート:

  • 2010年6月の時点で、10ヶ月前には約1100人だった従業員が2000人まで増えた。1年未満で従業員が倍増!
  • 最も規模の大きな2つのチームは開発チームと運営チームで、それぞれ400~500人のメンバーを持つ。2つをあわせると、全従業員の50%を占める。
  • プロジェクトマネージャーと開発者の比率はだいたい1:7から1:10。
  • すべてのエンジニアは4~6週間の間、「ブートキャンプ」と呼ばれるトレーニングを受ける。これは、バグを修正したりより経験の豊富なエンジニアのレクチャーを受けることでFacebookの仕組みを学ぶものだ。その後、各ブートキャンプを受けた新人たちのうち力の及ばなかった10%の人々が辞めるよう忠告される。
  • ブートキャンプが終わると、すべてのエンジニアは本番データベースにアクセスする権限を得る。(このとき、「多大な力は多大な責任を伴う」ことに関するレクチャーを受け、どのような事をしたときに彼らを解雇しても良いかについての明確なリストに同意させられる。(個人情報を公開する、など)
  • [編集 thx fryfrog] 「同時に、従業員がとんでもないことをやらかしてしまうことを防ぐ優れたセーフティガードが存在する。もしあなたがサポートを必要とする立場にならなければならなかったら、これは理由と共に記録され、念入りにレビューされる。ここで迷うことは一切許されない。」
  • すべてのエンジニアはFacebookのどんなコードでも編集できる。そして好きなときにチェックインできる。
  • エンジニアリングが主導する文化だ。「プロダクトマネージャーはここでは本質的に役に立たない」と、あるエンジニアは言う。エンジニアは自由に内部仕様を変更し、取り組むプロジェクトの優先順位を変更し、新しいアイデアを追加することができる。[EDITORIAL]私(ブログの筆者)はプロダクトマネージャーなのでこの意見はとても気になる。この続きを読めば分かるが、Facebookの文化はプロジェクトマネジメントの考え方をきちんと受け入れている。プロダクトマネジメントという役割をないがしろにしたり排除したりしているわけではない。むしろ、企業文化は みんなが プロダクトに責任を感じるようにしようとしているように見える。
  • 毎月行われるチーム間ミーティングでは、エンジニアたちも進捗を報告する。マーケティング担当やプロダクトマネージャもこのミーティングに参加するが、特に遠慮のない時は、リーダーに対して「プロダクトはさっきのミーティングで喋りすぎだ」とフィードバックする。彼らが開発者に望むのは、製品のオーナーであることを公にし、その製品に対する問い合わせを受け付ける役割となることだ。
  • プロジェクトへのアサインは、各人の意志によって行われる
  • PMグループは、まずプロジェクトの魅力をみんなに伝えようとする
  • エンジニアたちはどのプロジェクトで働くのが面白そうかを考える
  • エンジニアたちはそれぞれのマネージャーに「今週はこの5つに取り組みたい」と相談する
  • マネージャーは、大抵の場合はエンジニアの好きなようにさせるが、時には他のタスクを先に終わらせるように言うこともある
  • エンジニアたちは機能を丸ごと握る。フロントエンドのjavascript、バックエンドのデータベースコード、そしてその間にある全てのもの。もし彼らがデザイナーの力を必要とするなら(専任のデザイナーは数が限られている)彼ら自身でプロジェクトの魅力をデザイナーに伝える必要がある。アーキテクトの力を借りる時も同様だ。しかし基本的には、彼らが必要とするものをすべて自分の手で行うことを期待している。
  • ある機能のアイデアに価値があるか否かについての議論は、通常、一部のサンプルユーザ(例えばネバダの1%のユーザ)に1週間あててみるだけで終わる。
  • エンジニアたちは普通はインフラやスケーラビリティ、「困難な課題」に取り組みたいと考えている。それが名声を得られるものの全てだ。エンジニアたちがフロントエンドのプロジェクトやユーザインターフェイスに興味を持つよう働きかけることは難しいだろう。これはあなたがコンシューマビジネスの中で目にすることは逆だ。彼らは「それ僕が作ったんだよ」と言えるような、ユーザが直接触れるような部分を作りたがる。Facebookでは、ニュースフィードアルゴリズムや広告ターゲティングアルゴリズム、メモリキャッシュ最適化などといったプロジェクトが最もおいしく、エンジニアたちがやりたがるのだ。
  • 重要な機能(e.g.ニュースフィード)に影響を与えるようなコードは、マージされる前にコードレビューされる。ニュースフィードへの変更はザッカーバーグ自身がレビューするに値するほど重要だが、これは例外的なケースだ。
  • [訂正 thx epriest] 「すべてのコードはレビューされる義務がある(i.e., 1人または複数のエンジニアによって)。上の文はただザッカーバーグが毎日すべての変更を見るわけではないと言っているだけのように思う」
  • [訂正 thx fryfrog] 「すべての変更は最低1人によるレビューを受る。システムは、例えあなたが望んでいなくとも、誰もが簡単にあなたのコードを見たりレビューしたりできるように作られている。悪意ある意図的な操作をしない限り、レビューされていないコードをコミットすることはできない。」
  • QAはいない。ゼロだ。エンジニアは自分のコードをテストし、バグを修正し、リリース後メンテナンスする責任を持っている。ユニットテストや結合テストのためのフレームワークも用意されているが、それらは散発的に使われるだけだ。
  • [訂正 thx fryfrog] 「公式のQAグループがいないだけで、QAは存在する。オフィス内やVPN経由で繋がったすべての従業員は次にリリースされるバージョンのコードを使っている。このバージョンは頻繁に更新され、通常は1-12時間ほど世界よりも早く目に触れている。すべての従業員はどんなバグでも目にしたら報告することを強く奨励されており、それらはすぐに対応される。」
  • re: QAや自動ユニットテストの少なさに驚いた - 「ほとんどのエンジニアはバグのないコードを書く能力がある。だけど彼らにはそうすべき理由がない。QAがいれば、ただ彼らに投げてバグを見つけてもらえば良いからだ。」 [編集: これは主観的な意見であることに注目して欲しい。この意見を含めた理由は、他の企業の一般的な開発プラクティスと比較するためだ。]
  • [訂正 thx epriest] 「我々は自動テストをやっている。リリースする前に必ずテストをパスしなければならない仕組みも持っている。我々は「ほとんどのエンジニアはバグのないコードを書く能力がある」だなんて完全に信じていない、much less that this is a reasonable notion to base a business upon。」
  • re: PMの影響力やコントロールの欠如に驚いた - プロダクトマネージャーは大きな主体性と自由を持っている。影響力を得るカギはエンジニアリングマネージャーと良い関係を築くことだ。的外れなアイデアを提案しないように十分にテクニカルになる必要がある。ちなみに、ロードマップをひいたり残課題を残したりするためにレビューを受ける必要はない。PMは比較的少数しかいないが、誰もが、企業にとって本当に重要でありかつ個人的にも興味を持っている領域に対して責任を感じている。
  • 通常、コミットされたすべてのコードは週次リリース(火曜日)にパッケージされる。
  • 特に努力すれば、変更はそれ以外の日にもリリースできる。
  • 火曜日のリリースを行うときは、変更に関わったすべてのエンジニアはオンサイトで待機する必要がある。
  • エンジニアはリリースがはじまる前に「点呼」のために常に特定のIRCチャンネルでオンラインになっている必要がある。そうしなければ公開処刑されることになる。
  • 運用チームは徐々にリリースされていく間にコードを動かす
  • Facebookは約6万台のサーバを持っている
  • 新しいコードをロールアウトするときは9つのコンセントリックレベルがある
  • [訂正 thx epriest] 「9つのプッシュフェーズはコンセントリックではない。コンセントリックフェーズは3つある (p1 = 内部リリース, p2 = 小規模な外部リリース, p3 = フル外部リリース)。残りの6つのフェーズは自分たちのための内部ツールやビデオアップロードホストのような補助的なものだ。」
  • もっとも小さなレベルは6つのサーバのみ
  • e.g, 新しい火曜日リリースは6つのサーバにロールアウトされ(レベル1)、運用チームはそれらを受け取り、次のレベルに渡るまでに正しく振舞っているかをチェックする。
  • リリースしようとしているものに問題が見つかれば (e.g., エラーが発生するなど) プッシュは停止される。該当する変更をコミットしたエンジニアは修正するために呼び出される。そして、リリースはレベル1から再びやりなおす。
  • 従って、リリースはレベル間を行き来する: 1-2-3-修正。1に戻る。1-2-3-4-5-修正。1に戻る。1-2-3-4-5-6-7-8-9。
  • 運用チームは非常によくトレーニングされ、信頼されており、ビジネスのことをよく理解している。彼らのサーバ指標は通常のエラーログや負荷・メモリ利用統計に加え、ユーザ行動が含まれている。E.g, 新しい機能が数パーセントのユーザにリリースされたら、運用チームは彼らの指標をもとに調査し、それを理由にリリースを止めることができる。
  • リリースプロセスにいる間、運用チームは個々のエンジニアをFacebookやメール、IRC、IM、SMSなどで呼び出すためのIRCベースのシステムを使う。運用チームの呼び出しに応答しない場合は公開処刑される。
  • コードがレベル9に達しstableとなったら、最終的に週次プッシュされる。
  • もしある機能が週次プッシュに間に合わなかったとしても、大きな問題になることはない(外部との強い依存関係がない限り)。機能は、ただ完成したときにリリースされる。
  • svn-blameされたり、公開処刑されたり、プロジェクトを失敗させたりすることがあまりに多ければ、そのエンジニアは解雇される。「これは強いハイパフォーマンス・カルチャーだ」。生産的でなくスーパーな才能を持っているわけでもない人は目立つ。マネージャーたちは、パフォーマンスの乏しい人々を脇に避け、6か月以内に、文字通りこう言う。「これじゃ仕事をしているとは言えないね、君はうちの文化にあわないようだ」。これはどのレベルの人にも適用される。CレベルでもVPレベルでも、超生産的でなければクビになる。
  • [訂正 thx epriest] 「バグを埋め込んだからといって呼び出されるわけではない。彼らが呼び出されるのは、変更をリリースしようというのに周りに誰も間違いを指摘したりしてサポートする人がいないときだ。」
  • [訂正 thx epriest] 「非難されても解雇には繋がらない。我々はこの点においては非常に寛大で、私を含めほとんどのシニアエンジニアはとんでもないものをプッシュした経験がある。私が知る限りでは、この種のミスによって解雇された人は知らない。」
  • [訂正 thx fryfrog] 「私もここで指摘されているような理由で解雇された人を知らない。私はうっかりサイトをダウンさせてしまった人々を知っている。彼らは問題を修正するために尽力し、みんながそこから何かを学ぶ。私は、公開処刑になることは解雇される恐怖よりも効果的だと思っている。」

Facebookの開発文化が時間をかけて進化していく様子を見るのは非常に興味深い。特に、この文化が企業を数千人規模にスケールできるかを見ることは。

きみはどう思う?「開発駆動文化」はきみの企業でつかうことができるかな?

22

翻訳状況

完成度: 100%
このページは有志が翻訳しました。
その他の参加者...

ページを登録した人