Facebook初期メンバーへ運営方法など質問してみました

Pocket

Facebook初期メンバーへ運営方法など質問してみました


Facebookが数百人しかいない頃からジョインしていたメンバーへ運営方法や、開発手法などいくつか聞いてみました。

忘れないようにメモとして残しておきます。
日本語訳は汚いですがご勘弁を


会社全体の年間目標はどのようにたてられていましたか?誰が目標設定をたててましたか?また、どのくらいの期間でOKR or KPIを定めて運営していましたか?
3ヶ月に一回目標に対して振り返る?
How were companywide yearly goals set? Who set these goals? Also, for what length of time were OKR or KPI fixed? Did you look back every three months?

Companywide goals were set by the CEO and his direct reports (the VPs of the different orgs, along with the COO and CFO). These were usually 6-month goals. The VPs and directors of the orgs then took those goals and determined how to create organizational goals that would fit into the company goals.

会社全体の目標は、CEOともにCEOの直属の下部に設定されていました。(CEOの下部とは、いろいろな事業部のVP、ならびにCOOとCFOです。)
一般的に6か月分の目標を設定していました。
それから、VPと事業部のディレクターたちが、その会社全体の目標をベースとして
組織の目標を決定していました。


会社全体でどのような目標をたてられていましたか。もし教えてもらえるなら教えていただけませんか?
例)DAUを○○にする。RRを○○にする。
What kinds of companywide goals were set? Would it be alright if you told me those goals? For example; We want DAU to be x, or RR to be x.

Usually a combination of measurable goals around growth, product metrics, technical performance, finance (e.g. increase DAU by X%), and broader strategic goals (e.g. launch X, make X acquisitions in such and such a market). Hard to get more specific than this.

通常に測定可能な目標と幅広いビジネス戦略の目標との両方でした。
成長や、KPIや、技術効率、財務的な目標(例えばDAUを○○%アップにする)など。
それか○○プロダクトをリリースすることや、○○のマーケットで買収を○○件する。
以上より、もっと詳しく説明するのが難しいです。


どのようにしてチーム分けされてますか?目標に応じて頻繁に新しいチームが生まれたり消えたりしますでしょうか?
How did you split up your teams? In order to reach different goals did you frequently make and disband various teams?

The split of teams (org chart) changed depending on the needs and focus on the company. Broadly, there were engineering, operations, sales, finance, and HR/recruiting organizations, each broken down into various subgroups. Since then, some newly acquired companies run independently of this breakdown as basically autonomous companies (e.g., Instagram, Whatsapp), while others get integrated into the Facebook org chart.

チーム分わけ(org chartというもの)について、会社の要求と終点によって代わりました。
大まかに、もともと「engineering, operations, sales, finance,
HR/recruiting organizations(人事部)」がありました。
各部は、下位企業集団に分けていました。
それ以来、新しく買収された会社はこの整理以外の経営を行っている(例えばInstagramやWhatsapp)。
基本的に、自立会社として営業しています。
逆にほかの買収会社は社内org chartに吸収します。


1チームどのくらいの人数なのか教えていただけますか?またマネージメントをする人も現場で手を動かしていたりしますでしょうか?
Can you tell me how many people were on a team? Did management themselves lend a hand (second sentence, I’m not sure of the use of this expression)

Varied widely, depending on the team. In engineering, anywhere between 3 and 30 per product depending on the complexity and strategic importance of the project. Managers rarely coded but were heavily involved in technical conversations and decisions.

この件について、チームによって大きく異なります。
技術部内、複雑さと重要性によって、1プロダクトに3人と30人の間のどこかが多いです。
マネージャーはめったにコーディングしていませんが、
技術的な会話と決定に大きく関わり合いました。


プロダクトの仕様変更や情報のアップデートの共有はどのように進めていましたか?
例)全社定例MTGを行っていた? / wikiなどにまとめてSlackなどで共有?
How did you disperse information about the status of projects or share updates? For example, at companywide meetings? Using a wiki or Slack?

The methods of communication were up to the team itself, so there was no standard process the whole company used. Generally, teams used a combination of Facebook (which we used like Slack), a task management system similar to Asana or Basecamp, and team meetings.

各チームで情報交換の仕方が自分で自由に決めさせられていましたので、
会社全体標準処理ということがありませんでした。
一般的に、Slackの使い方のようにFacebookを使いました。
それに、AsanaかBasecampと同じようなタスク整理システムともに、チーム会議も使いました。


US以外の拠点とはどのように情報共有をしていましたか?
How did you disperse information to points outside the US?

In addition to the methods described above, lots of video conferences. Managers of global teams would usually travel between offices several times a year.

以上の方法に加えて、ビデオ会議がたくさんしました。
国際チームのマネージャーは普通に年に数回出張しています。


プロダクトの管理はgithubでしたか?コンフリクトとか、リリース日をどのようにさだめていたのか教えていただけますか?
Did you manage projects on Github? How did you do things like resolve conflicts or determine the release date?

We build custom software to manage diffs and revisions. This article is a bit outdated (the process has gained complexity over time) but gives a good overview: http://arstechnica.com/business/2012/04/exclusive-a-behind-the-scenes-look-at-facebook-release-engineering/

社内で立てたソフトでdiffと変更履歴を整理しています。
うちの処理がもっと複雑になったので、リンクの記事がちょっと古いけれども、
概要にとってなかなかいいです。


会社としてココだけは大事にしていたなと感じた点などあれば教えてください。
例)個人としての働きがいを大事にしているとか
As a company, was there anything you particularly wanted to treat with importance? Such as, making sure each individual was working on things they wanted to do?

Openness, trust, and transparency: Most information is available all employees, including upcoming projects and goals. There is a high level of trust placed in employees to tackle projects as they see fit.
Move fast: Employees are encouraged to test and iterate, rather than try to get it 100% perfect on the first shot (that’s maybe more of an Apple approach). Individual failures are not punished (e.g. pushing a bug, project doesn’t improve metrics), so long as effort and intention are good, and the person learns and adapts.
More thoughts: https://www.quora.com/What-s-the-internal-culture-of-Facebook-like

信頼、開放性、と透明性でした。情報の大部分を全社員に提供されています。
将来のプロジェクトも目標も含まれて。
問題を解決することを適当と思っているやりかたで、社員に高度の信用を与えています。
「Move fast」(急いでやること)。
(たぶん、アップルと違って)最初から100%パーフェクトにすることより、
試して反復するよう奨励しています。
個体の失敗の場合は、
担当者が知恵を身に付けて適応して、
意図、尽力でちゃんとがんばれば、
懲らしめていません。(例えばバグがプッシュされたらか、KPI改善失敗など)
以上のリンクでまたの思想があります。


Facebookならではのチームビルディング方法などはありましたか?
Was there anything like deliberate team-building methods at Facebook?

Mostly left up to managers to decide how they’d like to build teams. Often people take their teams off-campus for fun classes or activities. There are some company-wide events, like Game Day, Summer Party, and Holiday Party. Every Friday there is company-wide Q&A where anybody can ask questions of the management, and after that, there is an on-campus happy hour (beer and food).

ほとんどマネージャーに任せていました。
会社の現場から離れている場所に楽しいクラスや活動をすることが多いです。
会社全体イベントも少しあります。例えばゲームデー、夏パーティー、年末パーティー。
毎週金曜日、マネージメントに誰かでも質問できる会社全体Q&Aがあってから、
会社でHappy hour行っています。(レストランのサービスタイムのような食べ飲み会)


在籍中にFacebookの急激な成長によって出た問題点とかあったら教えていただけませんでしょうか?
Could you tell me about any problems that faced Facebook regarding its period of precipitous growth?

From a technical side, it is very difficult to serve data to 100M-500M-1B users without bugs, errors, poor server performance. Lots of attention and effort here as Facebook grew.
From an operations side, the challenge was answering the questions and policing the abuse of 1 billion people without dramatically expanding the size of the customer support team or making people wait months for a response. We built a lot of tools and created new processes and teams to handle these requests in the most efficient and effective ways possible.

技術的に、何らか不具合、エラー、悪いサーバー性能無しで1億~5億~10億人ユーザー様にデータを転送することがとても難しいです。
成長しながら結構焦点を絞りました。
Operations(業務部?)の観点で、
ユーザー様を数ヶ月待たせなくて、チームの人数を劇的に膨らまずに、
10億人の質問に答えて乱用の取り締まりするのは挑戦でした。
新しいツール、工程、チームを作ってそういう依頼をできるだけ効率で対応できました。


プログラムの技術選定をする人はいましたか?
Was there someone responsible for choosing the programming technologies?

Depends on the scope of the project, but usually left to the discretion of the engineering manager or director in charge of the project

プロジェクト範囲に頼っていますが、
普通にエンジニアのマネージャーかプロジェクトディレクターに任せています。

Pocket

あわせて読みたい