Skip to content
Published on

ビッグテック開発文化 完全ガイド: Google、Meta、Amazon、Netflix、Apple はどう違うのか (2025)

🇰🇷KO🇺🇸EN🇯🇵JA
Split View필사 모드
Authors

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

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

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

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

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

本稿では:

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

を比較分析する。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 のエンジニアが重要なコードを書く前に:

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

新製品提案時:

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

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

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 項目)

  • 意思決定速度: 設計ドキュメントの平均承認時間 (週)
  • 会議時間比率: エンジニア基準の週あたり会議時間 %
  • デプロイ頻度: 1 日のデプロイ回数
  • レビュー往復時間: PR 平均マージ時間 (時間)
  • オンコール負担: 週あたりページ数、夜間比率
  • 心理的安全性: 「ミスを言える」アンケートスコア
  • 1-on-1 実施率: スキップ率 %
  • Perf の透明性: 評価基準が明文化されているか
  • キャリアラダー: Staff / Principal レベルの定義が公開されているか
  • 離職 / 定着バランス: eNPS、voluntary attrition
  • 非同期文書比率: Slack 対 Notion / Confluence
  • 新人オンボーディング: 最初の PR までの時間

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 代でもコーディングする方法

次回で。

Discuss on Twitter • View on GitHub