Chaos and Order

💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

はじめに — 「うちも Netflix みたいにやろう」

スタートアップの創業者「Netflix みたいな自由と責任の文化をつくりたい」

2 カ月後「なぜチームがぐちゃぐちゃなんだ?」

答え: Netflix の文化は「最高水準のパフォーマーだけがいる」という前提の上に成り立っている。 Keeper Test (この人が辞めると言ったら引き留めるか?) が機能するには、全員が Keeper でなければならない。シニア経験者しか採らない Netflix の採用フィルタなしに、文化だけコピーすると破綻する。

文化は移植可能か? 部分的に。 組織規模、市場、人材プール、プロダクト成熟度が違えば、必要な文化も違う。

本稿では:

5 大ビッグテックの実際の文化 — Google、Meta、Amazon、Netflix、Apple
韓国ビッグテック — Naver、Kakao、Coupang、Toss、Baemin
コアメカニズム — Perf Review、コードレビュー、ミーティング、意思決定
自社に合う文化の選び方 — 規模別の推奨

を比較分析する。Season 3 Episode 4。前回「スケーリング変曲点」では Conway の法則を扱ったが、今回はその反対側 — 文化がどう組織構造を定義するか。

Chapter 1: Google — 「Data-driven + Design Doc」

1.1 キーワード

TGIF (Thank God It's Friday): 毎週金曜の全社 Q&A。創業者が直接回答 (2020 年以降は縮小)。
Design Doc: コードを書く前に必ず文書を書き、レビュアー 2〜5 名。
Readability: 特定言語の LGTM 権限を得るための社内認定制度。
20% time: 業務時間の 20% を別プロジェクトに (Gmail や AdSense はここから)。

1.2 Design Doc 文化

Google のエンジニアが重要なコードを書く前に:

Design Doc を書く (4〜30 ページ): 問題定義、目標 / Non-goals、アーキテクチャ代替案の比較、選択した解決策と理由、影響予測 (性能、コスト、セキュリティ)。
レビュアー指定 (通常 Staff+ 2〜5 名)。
フィードバック反復 (1〜4 週間)。
承認後、コーディング開始。

利点: 誤った方向を早期発見、組織学習 (過去の判断理由が検索できる)、新人オンボーディング資料。

欠点: 遅い (小さな仕事には過剰)、文書力がエンジニア評価に過度に影響。

1.3 Perf Review の悪名

Google Perf は複雑さで有名:

Self-assessment を半期ごとに。
Peer review: 同僚 3〜7 名。
Calibration: マネージャーが集まりグレード調整 (forced curve に近い)。
Promotion packet: 昇進申請時は数十ページの文書。

Stack Ranking 論争: 明示的ではないが事実上存在。下位 N% に PIP 圧力。

2023 年改編: 「GRAD」(Googler Reviews and Development) に簡素化。

1.4 コードレビュー文化

LGTM (Looks Good To Me): 承認の意。
Readability 制度: 言語別の試験通過が必要。
レビュアーは平均 2 名以上。
Critique (社内ツール): Gerrit ベース、行単位コメント。

公開データ: 平均レビュアー 1.7 名、平均コメント 4〜5 件、中央レビュー往復 4 時間。

1.5 欠点

意思決定が遅い: Design doc → レビュー → 承認の多層化。
政治: Promo-driven development (昇進に有利なプロジェクトだけ)。
プロジェクト廃止で悪名: Google Reader、Wave、Stadia... 「Google Graveyard」。

Chapter 2: Meta (Facebook) — 「Move Fast and Break Things」

2.1 キーワード

Move Fast: 元は "Move fast and break things"、2014 年に "Move fast with stable infra" に修正。
Bootcamp: 新入社員が 6 週間複数チームを体験してからチーム選択。
Dogfooding: 自社プロダクトを自分で使う。
Hackathon: 四半期 1 回、48 時間集中。
Done is better than perfect (オフィスのポスター)。

2.2 Bootcamp の独自性

一般企業: 入社時にチーム配属。

Meta: 6 週間の Bootcamp 中に 3〜5 チームのプロジェクトを体験し、本人がチームを選ぶ。

利点: 新入社員が実体験でチーム選択、複数チームとネットワーク形成、入社後のミスマッチが減る。

欠点: 6 週間のオンボーディングコスト、人気チームへの偏り。

2.3 Dogfooding

社員は Facebook、Instagram、WhatsApp を日常的に利用。
新機能は社内で先に使う。
バグレポート文化が定着。

プロダクトの感覚は「使うこと」から来る。

2.4 Move Fast の現実

初期: 1 日数万デプロイ、破壊的変更も一旦デプロイ。

2014 年以降: "Move fast with stable infra"。理由:

プラットフォーム安定性 (数十億ユーザー影響)。
規制対応 (GDPR など)。
Review board 強化。

それでも 1 日数万デプロイ、ただし Gating mechanism が増加。

2.5 Perf Review

PSC (Performance Summary Cycle): 半期ごと、自己・同僚・マネージャー評価、グレードは Redefines / Greatly Exceeds / Exceeds / Meets All / Meets Most / Meets Some。Stack ranking の悪名: 下位 10% は PIP (Performance Improvement Plan)。

2023 年 "Year of Efficiency": 大規模レイオフ。文化の硬化。

Chapter 3: Amazon — 「Two-Pizza + Working Backwards」

3.1 キーワード

Leadership Principles (LP): 16 項目 (元は 14)。
Two-pizza team: ピザ 2 枚で足りる規模。
Working Backwards: 発売プレスリリースを先に書く。
6-page narrative memo: PowerPoint 禁止、6 ページの散文。
OP1/OP2: Operating Plan (年 2 回の計画サイクル)。

3.2 6-page Memo

ミーティング開始時に 30 分間、6 ページの文書を黙読。その後ディスカッション。

なぜ PowerPoint を使わないか:

スライドは思考を断片化する。
発表者中心で、聴衆は受動的になる。
派手な図形の裏に弱い論理が隠れる。

Bezos: "The narrative structure of a good memo forces better thought and better understanding."

構成: 文脈と問題、データと分析、提案と代替案、予想される反論と回答、付録 (Raw data)。

3.3 Working Backwards

新製品提案時:

Press Release: 発売日基準で「この製品が発売されました」というプレスリリースを書く。
FAQ: 顧客や記者が尋ねそうな質問と回答。
逆算計画: このプレスリリースを実現するには今何が必要か。

顧客価値が先、技術はあと。「技術的に容易」ではなく「顧客が望むもの」から始める。

3.4 Two-Pizza Team

Bezos:

"チームはピザ 2 枚で食事できる規模 (約 6〜10 名) であるべきだ。"

通信経路は n*(n-1)/2 で増える。10 人なら 45 経路、20 人なら 190 経路。小さいチーム = 速い意思決定とオーナーシップ、大きなチーム = 政治と遅延。

3.5 Leadership Principles — 16 項目

Customer Obsession
Ownership
Invent and Simplify
Are Right, A Lot
Learn and Be Curious
Hire and Develop the Best
Insist on the Highest Standards
Think Big
Bias for Action
Frugality
Earn Trust
Dive Deep
Have Backbone; Disagree and Commit
Deliver Results
Strive to be Earth's Best Employer (追加)
Success and Scale Bring Broad Responsibility (追加)

面接の LP 質問: 「Customer Obsession を示した事例を教えてください」。

"Disagree and Commit": 反対でも決定後は全力で実行。意思決定麻痺を防ぐ。

3.6 Frugality (倹約)

初期のデスクはドアから作った (今も一部)。
無料ランチなし。
出張は安価なフライト。

メッセージ: お金は顧客価値に。

Chapter 4: Netflix — 「Freedom and Responsibility」

4.1 キーワード

Culture Deck: 2009 年の 125 ページスライド、シリコンバレーの必読書。
Keeper Test: この人が辞めたら引き留めるか?
Stunning colleagues: 最高水準の同僚。
No rules rules: 休暇無制限、経費ポリシーなし。
Informed captain: 意思決定者一人が責任を持つ。

4.2 No Rules Rules

休暇: 無制限、承認不要。経費: "Act in Netflix's best interest"。ドレスコード: なし。承認フロー: ほぼなし。

なぜ機能するか: 全員が A-player。大人として扱えば大人らしく振る舞う。

なぜ機能しない可能性もあるか: 新人にはルールが必要。階層文化では濫用される。

4.3 Keeper Test

マネージャーが定期的に自問:

"このメンバーが明日「別の会社に行く」と言ったら、どれだけ必死で引き留めるか?"

答えが「あまり引き留めない」なら、解雇 + 寛大な退職金。

利点: 継続的な高パフォーマンス。欠点: 心理的安全性が低下、リスク回避的になる。

4.4 Context, not Control

マネージャーはコンテキストを提供、細かい指示はしない。社員は情報に基づいて判断。ミスは許容、同じミスの繰り返しは許容しない。

4.5 Informed Captain

各決定には Informed Captain 一人: 多様な意見を集め、一人で決定し、結果に責任を持つ。合意 (consensus) を避ける。Amazon の "Disagree and Commit" に類似。

4.6 Netflix になれない会社

Reed Hastings の警告:

"この文化は、成熟した会社 + 卓越した人材 + シンプルな製品 (動画ストリーミング) の組み合わせで機能する。"

スタートアップ、製造業、医療、金融では危険でありうる。

Chapter 5: Apple — 「Secrecy + Integrated Excellence」

5.1 キーワード

Secrecy: 社内でもプロジェクト情報を遮断。
DRI (Directly Responsible Individual): すべての事に単一責任者。
Functional organization: 部署は機能別 (Engineering、Design、Marketing)。
Integration: Hardware + Software + Services 統合設計。
Taste: エンジニアリング以上の美的基準。

5.2 秘密主義

Project names: プロジェクトはコード名で呼ぶ。
Need-to-know basis: 同じプロジェクトでも他チームとは情報隔離。
物理的分離: 特定建物・フロアの入退室制限。
NDA: 厳格な秘密保持契約、違反は訴訟。

理由: 競争優位、ローンチのインパクト、知財保護。

欠点: 社内協業が難しい、社員がコンテキストなしで働く、プレス関係の緊張。

5.3 DRI 文化

すべての問題、すべての機能、すべての決定に 一人の名前:

"このボタンの DRI は誰ですか?"

その一人が質問され、決定し、結果に責任を持つ。

利点: 責任分散を防ぐ、速い意思決定、品質オーナーシップ。欠点: 本人がボトルネック、Single point of failure。

5.4 Functional Organization

一般企業: 製品別事業部 (Product A、Product B)。

Apple: 機能別組織 — Hardware engineering、Software engineering、Design、Marketing。iPhone は全機能部署が協業して作る。各部署は世界最高の専門家。CEO が最終調整点。

なぜ特異か: 多くの会社は規模拡大で事業部制に移るが、Apple は機能組織のまま (Steve Jobs 以降も)。統合されたプロダクト体験には統合された組織が必要。

5.5 Taste と Reject

Steve Jobs は数千のアイデアに "No" と言ったと有名。「我々がやらないことが我々を定義する」。会議で最初のデザインに「ゴミだ」と言われても驚かない。

多くの会社の問題: 作りすぎ。Apple はフォーカスする。

Chapter 6: 韓国ビッグテック — Naver、Kakao、Coupang、Toss、Baemin

6.1 Naver

開発文化: 日本式のディテール + 韓国式スピード。
組織: NAVER Cloud、Search、AI Lab など子会社分離。
Perf: 絶対評価への改編を模索 (2020 年代)。
強み: 検索、AI、ClovaX。
弱み: グローバル市場での存在感、新製品リリース速度。

6.2 Kakao

開発文化: 英語ニックネーム使用、平語使用、「アジャイル」強調。
組織: Crew (クルー) 基盤、平等志向。
問題: 2022 年のデータセンター火災で露呈したインフラ / DR の課題、以後文化改革要求。
強み: メッセンジャーのエコシステム、速い実験。
弱み: 子会社乱立による複雑性、内部政治。

6.3 Coupang

開発文化: Amazon DNA (LP 類似)。
強いデータドリブン: 実験、A/B、数値中心。
Working Backwards を採用。
強み: 物流、データ、米国上場 (NYSE)。
弱み: 労働強度への懸念。

6.4 Toss

開発文化: Silo 組織 — 製品チームに Tech / Design / PO が同居。
TMT (Toss Mission Talk): 四半期ごとの全社共有。
意思決定: Silo リーダーが実質的権限。
強み: 製品完成度、速いリリース、UX。
弱み: Silo 間調整、急成長下での文化維持。

6.5 Baemin (Woowa Brothers)

開発文化: 「松坡区で上手に働く方法」ポスターが有名。
雑談、会議、主導権: 具体的な実践ガイド。
組織: 製品中心組織。
強み: 開発者採用ブランド、エンジニアリングブログ。
弱み: Delivery Hero 買収後の文化変化。

6.6 韓国ビッグテック共通特性

残業文化は改善中: 週 52 時間制の定着。
英語使用: Toss と Coupang は英語コミュニケーションが普通。
開発ブログ: ブランディング手段として活発。
ジュニアに優しい: 新卒公募 + 社内ブートキャンプ (Woowa Tech Course、SSAFY)。
転職サイクル: 2〜3 年が普通、ビッグテック ↔ スタートアップ間移動が活発。

Chapter 7: Perf Review 構造比較

7.1 サイクル

会社	サイクル	特徴
Google	半期	GRAD (簡素化)
Meta	半期	PSC、Stack ranking
Amazon	年 1 回 (OLR)	Forced distribution
Netflix	年 1 回	Continuous feedback 志向
Apple	年 1 回	マネージャー裁量大
Naver/Kakao	半期	絶対 + 相対混合
Coupang	半期	Amazon 類似
Toss	年 1 回	Silo リーダー評価

7.2 等級体系

Google: Not Enough Impact / Significant Impact / Outstanding / Transformative
Meta: Greatly Exceeds / Exceeds / Meets All / Meets Most / Meets Some
Amazon: Top Tier / Highly Valued / Least Effective (URA — Unregretted Attrition Rate 目標値)

7.3 Stack Ranking の影

Microsoft は 2013 年に Stack Ranking を廃止。理由: 内部競争激化、協業阻害、低パフォーマー「押し付け合い」。

多くの会社がいまだ変形版を使用。「必要悪」か「害悪」か論争は続く。

Chapter 8: コードレビュー文化比較

8.1 レビュアー数

Google: 1〜5 名 (平均 1.7、Readability 必要)
Meta: 2〜3 名 (Phabricator)
Amazon: 1〜2 名 (CR 必須)
Netflix: 自律的、ケースバイケース
Apple: 非公開、機能チーム内部

8.2 レビュースタイル

Google: 厳格、Readability 重視、スタイル一貫性 > 個人の好み
Meta: 実用的、デプロイ速度優先
Amazon: "Are you sure?" 質問中心、Dive Deep
韓国: 会社により差が大きい。Toss は厳しく、Baemin は実用的。

8.3 自動化レベル

Google: 社内ツール (Critique、Tricorder)、数百の linter
Meta: Phabricator、Sapling (VCS)、Infer (静的解析)
Amazon: CodeGuru (自社)、パイプライン内の多数のゲート
一般的スタートアップ: GitHub + Actions + ESLint/Prettier

Chapter 9: ミーティングとコミュニケーション比較

9.1 ミーティング文化

Amazon: 6-page memo + 30 分黙読 + 議論 — 文書中心。
Google: Slides + Q&A — 発表中心。
Meta: 短い standup + Workplace (社内 Facebook) の投稿 — 非同期 + 短く。
Netflix: 小グループのミーティング、「Memo culture」を導入中 — 少なく。
Apple: DRI 中心、小規模 — 縦型報告。

9.2 非同期 vs 同期

会社	傾向
Amazon	文書中心 (非同期可能)
Google	混合
Meta	同期 + Workplace 投稿
Netflix	小規模同期 + メモ
GitHub/Automattic	完全非同期 (ミーティングほぼゼロ)
韓国	概ね同期 (ビデオ / 対面)

9.3 1-on-1

共通: 週 1 回、30 分〜1 時間。

Google: 成長コーチング、四半期 OKR 確認。
Amazon: 成果中心、障害物の除去。
Netflix: Context の交換。
Toss: Pair PO / デザイナー / 開発者構造で頻繁。

Chapter 10: 採用フィルター比較

10.1 Google

4〜6 ラウンドの面接 (技術 + リーダーシップ)
Coding interview: アルゴリズム強め
Hiring committee が最終決定 (採用マネージャー ≠ 決定権者)
Level: L3 (新卒) 〜 L10 (VP)

10.2 Meta

Coding 2 ラウンド + System design + Behavioral
リクエストすれば面接結果メールを返送
Level: E3 〜 E9

10.3 Amazon

「Bar Raiser」: 別チームの面接官を含む (バイアス除去)
LP 質問に集中
オンサイト 5〜6 ラウンド

10.4 Netflix

シニアのみ採用 (新卒はほぼなし)
Culture fit を強調
Keeper Test を前提にした採用
報酬: 業界トップ水準 (Top of Market)

10.5 Apple

チーム特化の面接、共通プロセスは少ない
非公式の Bar Raiser 的存在
秘密主義テスト: 面接中もプロジェクト情報は開示されない

10.6 韓国ビッグテック

Naver / Kakao: コーディングテスト + 2〜4 次面接
Coupang: Amazon 類似 (LP ベース)
Toss: TMT カルチャー面接
Baemin: コーディング + 人柄 + カルチャー

Chapter 11: 文化の失敗事例

11.1 Uber のトキシック文化 (2017)

問題: 攻撃的な成長優先、社内ハラスメントの隠蔽、創業者 Travis Kalanick の言動、Hustle 文化の極端化。

結果: 創業者辞任。Susan Fowler のブログ投稿がきっかけ。

教訓: 文化の欠陥はいずれ外部に露呈する。

11.2 Zappos の Holacracy 実験

Tony Hsieh は 2015 年に Holacracy (マネージャー不在の構造) を導入: マネージャー撤廃、サークル型組織。結果: 14% の社員が退職。完全な失敗ではないが普及せず。

教訓: すべての組織に合う文化はない。

11.3 Basecamp の 2021 年政治論争

Basecamp: 職場内の政治 / 社会イシュー議論を禁止 → 37% の社員が退職。

教訓: 文化変更は既存社員との信頼を破壊する。

Chapter 12: 文化チェックリスト (12 項目)

Chapter 13: 10 の文化アンチパターン

1) Cargo-culting

Netflix 文化を生まれたてのスタートアップがコピー。前提条件 (シニアのみ、シンプルな製品) を無視。

2) ポスター = 文化という錯覚

壁に「Be yourself」だけ貼って実践なし。文化はマネージャーの毎日の判断。

3) Founder-dependent Culture

創業者がいないと維持できない文化。創業者が去ると崩壊。→ 文化の制度化が必要。

4) 「うちは家族」スローガン

解雇時のショック。家族は解雇しない。**「プロスポーツチーム」**の方が正直。

5) Stack Ranking なしでトップパフォーマーだけ欲しい

下位を改善する装置なしに最高だけ集まることを期待。現実的な運用不可。

6) すべてを合意で

Consensus の幻想。速い決定が不可能。Disagree and Commit を使え。

7) 匿名アンケートなし

本音が聞こえない。リーダーの耳が塞がる。eNPS + 匿名アンケート。

8) Perf Review が唯一のフィードバック

半期だけフィードバック。普段は沈黙。Continuous feedback が必要。

9) 会議だけで文書なし

決定が消える。同じ議論が繰り返される。Design doc 文化の導入を。

10) Hustle 崇拝

72 時間勤務の英雄視。短期は可能、長期はバーンアウトと離職。持続可能性が勝つ。

Chapter 14: 自社に合う文化 — 規模別推奨

14.1 シード〜シリーズ A (5〜30 名)

推奨: Done > Perfect、全員が全コードを見る、非公式コミュニケーション。
避けるべき: Design Doc の強制、階層的 Perf Review。
ベンチマーク: 初期の Baemin、初期の Stripe。

14.2 シリーズ B〜C (30〜200 名)

推奨: チーム分離、明示的 1-on-1、シンプルな Perf (年 1 回)、非同期メモ。
避けるべき: Stack Ranking、Microservices の強行。
ベンチマーク: 中期 Shopify、中期 Toss。

14.3 成熟期 (200〜2000 名)

推奨: Level ladder の公開、Promo 制度、Design Doc の必須化、SRE 文化。
避けるべき: 規模に対して過度に集中した意思決定、Founder-bottleneck。
ベンチマーク: Notion、Figma。

14.4 ビッグテック (2000 名以上)

選択肢: Google 式 (Data-driven、Doc)、Amazon 式 (LP、Frugal)、Netflix 式 (High-talent density — ただし採用フィルタが前提)。
共通: 非常に明示的なプロセス、強い Culture statement。
リスク: 官僚化、イノベーション速度の低下。

おわりに — 文化は戦略を朝食に食べる

Peter Drucker の有名な言葉:

"Culture eats strategy for breakfast."

戦略より文化が重要という意味。どれだけよい戦略でも、文化が実行を阻めば失敗する。

原則 1: 文化は宣言ではなく行動

「我々は Customer Obsessed だ」と 10 回言うより、今四半期に顧客 NPS を 20% 上げるために機能を遅らせる決定一つのほうが強力。

原則 2: 採用が文化の 90%

残り 10% は継続的な管理。採用を間違えれば修正不可能。

原則 3: 文化は移植可能ではない

コンテキストを理解し、一部だけ持ってくる。Amazon の 6-page memo は可能、Netflix の Keeper Test は危険。

原則 4: 文化は進化する

スタートアップと大企業で必要な文化は違う。アイデンティティは維持しつつ、形は変わる。

原則 5: 原典を読め

次回予告 — 「世界的な開発者 / CTO への道: シニアから Staff、Principal、そして VP まで」

Season 3 Ep 5:

Senior Engineer のプラトー
Staff+ エンジニアは何が違うか
Principal Engineer の日常
IC (Individual Contributor) トラック vs Manager トラック
CTO に至る経路
有名 CTO / エンジニアのキャリア分析 (Jeff Dean、Sarah Drasner、Kelsey Hightower)
韓国のシニア開発者のキャリア現実
転職、コンサル、起業の分岐点
40 代、50 代でもコーディングする方法

次回で。