Japanese.以下Facebook社の開発プロセスについてのyeeguy氏のブログを日本語訳したもの。95%程度はあっていると思うが詳しく確認していないので詳細は適当な部分がある。題名は原文へリンクしてある。yeeguyFacebook社のやり方に感心している。(もしやってみたとしても、他の会社全てでうまくいくわけではないだろう)。以下に示すのは、会社でどのようにソフトウェア開発をしてリリースをしているのか、Facebook社に在籍する多くの友人と話しているうちに集まったメモだ。Facebook社の開発者主導の文化が大いに世間の詮索の的になっていて、一方他の会社では開発者主導の文化が実現可能なのか、どんな方法で実現するのかという難しい問題に取り組んでいる。Facebook社では内部のプロセスをとても慎重に選定する。そのため、外部の人間にとってはFacebookが他の会社と比較して大幅に効率的にサービスを改良し最適化しているのかが簡単にはわからない。Facebook社がどのように機能しているのかをもっと理解するための試みとして、外部の人間の立場で個人的にこれらの考察を数ヶ月の期間にわたってまとめた。情報提供者に対するプライバシーを尊重し、全ての氏名、特定の機能や製品について言及している部分は削除した。これらの考察をまとめてから公開するまでに6ヶ月以上も待ったので、きっとこれらのメモの内容は少し古くなってしまっている。Facebook社の成果、あるいはFacebook社がいかに首尾一貫して製品を提供してきたかについて反論するのは難しい。一般ユーザー(コンシューマ)を対象としている多くのインターネット企業がFacebookの例から学べると思うし、学んで欲しい。Facebook社の内部についての視点をまとめるのに協力していただいた多くの方々には多大に感謝している。epriest氏やfryfrog氏など、訂正、編集についてのまとめをしていただいいた方々にもまた感謝する。注:2010年7月の時点でこの会社には2000人近くの従業員がおり、およそ1100人の従業員がいた10ヶ月前よりも増えている。一年たたずにほぼスタッフが2倍!規模において上位2つのチームはエンジニアとオペレーション担当で、それぞれ400から500人のチームメンバーが所属する。これらの2チームだけで会社のおよそ50%を占める。全てのエンジニアは4週間から6週間の「ブートキャンプ」トレーニングを経験する。このトレーニングを通してバグの修正をしたりシニア/テニュア(永任権を持つ?)エンジニアによる講義を聴いたりすることでFacebookのシステムについて学ぶ。“内部の権限を持ってすれば可能になってしまうと想像できるようなひどいことを社内の誰かが実行してしまうのを防ぐため、とても優れたセーフガードがある。サポートに連絡するような「立場に」ならざるを得ない場合、その内容が記録されるのには理由があり、しっかりとレビューされる。ここでは道を踏み外す者は許容できない。”エンジニアなら誰でもFacebookのコードベースの任意箇所を思い通りに変更でき、チェックインできる大いにエンジニア主導の文化である。「ここではプロダクトマネージャは基本的に役に立たない」というのはあるエンジニアによる言葉の引用。エンジニアは開発過程の途中で設計を変えたり、プロジェクトの順位を変更したり、アイデアが浮かんだらいつでも新しい機能を加えたりする。異チーム合同の月例ミーティングでは、エンジニアが進捗報告を発表する。プロダクトマーケティングやプロダクトマネジメントの人間もこれらのミーティングに参加するが、これらの人が話し過ぎると「この間のミーティングではプロダクトがおしゃべりしすぎた」などという評価がリーダーに対して返ってくる。彼らはエンジニアが公的にプロダクトを所有する状態を望んでおり、開発するものについてエンジニアがコンタクトの中心となるのを望んでいる。プロジェクトに対しての人員配置は完全に自主的である。プロダクトマネージャがエンジニアのグループに声をかけ、アイデアを説明し、熱心に興味持たせるよう働きかける。エンジニアは、取り組むならどのアイデアが面白そうか判断する。エンジニアは上司(マネージャ)に「今週はこの5つのことに取り組みたい。エンジニアマネージャはたいていエンジニアの希望をほうっておき、時には特定のタスクをまず片付けるように指示することもある。フロントエンドのjavascript、バックエンドのデータベースコード、またそれらの間にあるもの全て。デザイナーに助けを求めたければ(人数は限られるが専属のデザイナーがいる)、デザイナーを説得してプロジェクトに参加するように興味を持たなければいけない。アーキテクトに助けを求める場合も同様。一般的には、エンジニアは必要なもの全てについて自ら対応するよう期待される。機能についてのあるアイデアが実現するに値するかどうかの議論は、一般的に1週間を実装に費やしてユーザーの一部に対してテストすることで解決する。ネバダ州のユーザーのうち1%を対象とする。そこに全ての名声があるから。フロントエンドのプロジェクトとユーザーインタフェースに取り組むことについてエンジニアの熱心な興味を引くのは難しい場合がある。「ここは私が作ったんだ」と特定の機能を指差したいがためにお客さんが触れるような箇所に関わる、というようなコンシューマービジネスの場合とは反対の状況である。Facebookでは、ニュースフィードのアルゴリズム、広告のターゲットを絞るアルゴリズム、memcacheの最適化などのようなバックエンドの案件はうまみが多くエンジニアが欲しがるプロジェクトだ。特定の高優先度の機能(例えばニュースフィード)に影響があるコミットはマージ前にコードレビューを受ける。FeedについてはZuckerberg氏が必ずどんな変更点もレビューするほど重要だが、これは例外的なケースだ。“全ての変更点についてコードレビューは義務となっている(つまり、一人以上のエンジニアによってレビューされる)。この記事の言わんとしているところはZuck氏が個人的に全ての変更点を見るわけではないということだと思う。“全ての変更点は最低1人によりレビューされ、特に招待しなかったとしてもシステムは他の誰にでも簡単に見ることができ、コードをレビューすることができる。レビューされていないコードを混入するには、意図的かつ悪意を持った行動が伴うはずだ。”QAは全く存在しない。関わった仕事についてエンジニア自らがテスト、バグ修正、リリース後の運用に責任を負う。単体テストや結合テストのフレームワークは存在するが、時々利用されているのみである。実際には会社にQA(チーム)が存在していることを付け加えたい。正式なQAグループではない。職場にいる、あるいはVPN経由で接続している全ての従業員は次のタイミングでリリースされる全ての変更点を含むバージョンのサイトを使っている。このバージョンは頻繁に更新され、世間のユーザーに見えるものよりも通常1〜12時間先行している。全ての従業員はどんなバグでも報告するように推奨され、これらの報告に対しては迅速に行動が起こされる。“多くのエンジニアはバグのないコードを書くことができる。ほとんどの会社がそれに対してのインセンティブを設けていないだけだ。QA部署があるなら、単純に彼らに任せてエラーを見つけてもらうのが簡単だ。これは主観的な意見であったということに注意してください。他の会社での標準的な開発プラクティスと対照的に述べるためにこの記述を入れました。“我々はテストを自動化した。その中にはリリースが世に出る前にパスしなければいけない「push-blocking」テストも含まれる。「ほとんどのエンジニアはバグのないコードを書くことができる」ということは我々は全く信じておらず、ビジネスの基礎とできるような妥当な考えだとも思っていない。プロダクトマネージャは独立性と自由さを持っている。影響力を持つカギは、エンジニアリングマネージャと本当に良い関係を築くことである。ばかげたアイデアを提案しない程度に、十分な技術が必要。それはさておいても、ロードマップやバックログを作成する際に許可やレビューを受ける必要がない。”プロダクトディレクタはロードマップに載っている事ついてすら全てきちんと知ってはいない。プロジェクトマネージャの数は比較的少ないが、彼らは皆、社内の本当に重要で個人的に興味のある部分について責任を負っていると感じている。“この9つのレベルは同心的(concentric)ではない。完全な外部リリース)。他の6つの段階は付属的なものであり、内部ツール、ビデオアップロードホストなどである。”最小のレベルでは6サーバーだけになる。火曜日の新規リリースが6サーバーを対象に行われる(レベル1)場合、オペレーションチームはそれら6つのサーバーを監視し、正しく機能していることを次のレベルへと移行する前に確認する。リリースが問題を引き起こした場合(例えば、エラーが出る、など。)には更新を停止する。問題となるチェンジセットをコミットしたエンジニアは問題の修復に専念することになる。リリースはレベル1からやりなおしとなる。