技術選定の成功事例5選: Netflix, Discord, Shopify, Airbnb, Supabase

はじめに

技術選定は、プロダクトの成長やチームの生産性に大きな影響を与えます。本記事では、世界的に成功した5つの企業の技術選定事例を分析し、その判断の背景、結果、そして私たちが学べる教訓を解説します。

身近な例えで理解する技術選定の重要性

技術選定は「職業選び」に似ています。

• 最初の選択が正しくなくても、途中で変更できる（ただしコストがかかる）
• 自分（チーム）の強みを活かせる選択が最も良い結果を生む
• 周りが選んでいるから、という理由だけで選ぶと失敗する
• 長期的な視点と短期的な現実のバランスが重要

事例1: Netflix -- Java/Groovyからの段階的進化

背景

Netflixは2007年にDVDレンタルからストリーミングサービスに転換。急激なユーザー増加に対応するため、2008年からオンプレミスのデータセンターからAWSへの移行を開始した。

技術選定の経緯

技術構成図

[ユーザー (2億人以上)]
    |
    v
[AWS CloudFront (CDN)]
    |
    +-- [Open Connect (独自CDN)]
    |   （世界中のISPに設置された
    |    動画配信専用サーバー）
    |
    v
[Zuul (API Gateway)]
    |
    v
[マイクロサービス群 (1,000以上)]
    |
    +-- [コンテンツサービス (Java)]
    +-- [レコメンデーション (Python + Spark)]
    +-- [UIサービス (Node.js)]
    +-- [A/Bテスト (Java)]
    +-- [課金サービス (Java)]
    |
    v
[データストア]
    +-- [Cassandra (ユーザーデータ)]
    +-- [MySQL (マスターデータ)]
    +-- [S3 (動画ファイル)]
    +-- [EVCache (キャッシュ)]

成功のポイント

1. 段階的な移行: 一度に全てを変えず、8年かけて段階的にクラウド移行
2. OSSへの貢献: Zuul、Hystrix、Eureka等を開発しOSS化。コミュニティからのフィードバックで品質向上
3. Polyglot Architecture: サービスごとに最適な言語を選択（Java、Node.js、Python）
4. Chaos Engineering: 本番環境で意図的に障害を発生させるChaos Monkeyで耐障害性を検証

教訓

「最適な技術は1つではない。サービスの特性に合わせて複数の技術を使い分けることが、大規模システムでは重要。」

事例2: Discord -- Go + Elixir + Rust

背景

Discordは2015年にゲーマー向けチャットアプリとしてローンチ。リアルタイム通信が命であり、低レイテンシと高い同時接続数が求められた。

技術選定の経緯

技術構成図

[ユーザー (1.5億人以上)]
    |
    v
[CloudFlare (CDN + DDoS防御)]
    |
    v
[API Gateway]
    |
    +-- [Gateway (Elixir)]
    |   （WebSocket接続管理、100万以上の同時接続）
    |
    +-- [REST API (Python)]
    |   （CRUD操作）
    |
    +-- [Voice Server (C++/Rust)]
    |   （音声通信）
    |
    v
[データストア]
    +-- [Cassandra → ScyllaDB (メッセージ)]
    +-- [PostgreSQL (メタデータ)]
    +-- [Redis (プレゼンス、キャッシュ)]
    +-- [GCS (メディアファイル)]

GoからRustへの部分移行

Discordは2020年にメッセージの「Read States」サービスをGoからRustに書き換えた。

GoのGC（ガベージコレクション）による一時停止がレイテンシスパイクの原因だった。Rustはメモリ管理をコンパイル時に解決するため、GCが存在せず安定したパフォーマンスを実現。

教訓

「最初から完璧な技術を選ぶ必要はない。問題が明確になってから最適な技術に移行すれば良い。」

事例3: Shopify -- Ruby on Rails一本勝負

背景

Shopifyは2006年にRuby on Railsで構築されたECプラットフォーム。2025年現在も基本的にRuby on Railsをメインスタックとして使い続けている。

技術選定の経緯

技術構成図

[加盟店 (数百万店)]
    |
    v
[Shopify Edge (CDN)]
    |
    v
[Ruby on Rails (モノリス)]
    |
    +-- [商品管理]
    +-- [注文処理]
    +-- [決済]
    +-- [在庫管理]
    +-- [顧客管理]
    +-- [API (GraphQL + REST)]
    |
    v
[データストア]
    +-- [MySQL (ProxySQL でシャーディング)]
    +-- [Redis (キャッシュ、ジョブキュー)]
    +-- [Kafka (イベントストリーミング)]
    +-- [Elasticsearch (検索)]

Railsで大規模に成功した理由

1. モジュラーモノリス: マイクロサービスに分割するのではなく、モノリス内を適切にモジュール化
2. YJIT: RubyのJITコンパイラをRustで開発し、Ruby自体のパフォーマンスを向上（Ruby 3.2に標準搭載）
3. データベースシャーディング: MySQLを顧客IDベースでシャーディング
4. Railsへの投資: Railsのコア開発に積極的に貢献

教訓

「技術の限界は、往々にして技術そのものではなく、使い方にある。既存技術を極限まで最適化することは、新技術への移行よりもコストが低いことが多い。」

事例4: Airbnb -- React Nativeへの挑戦と撤退、そしてWeb重視へ

背景

Airbnbは2008年にRuby on Railsで構築された民泊プラットフォーム。2016年にモバイルアプリの開発効率化のためにReact Nativeを大規模に導入したが、2018年に撤退を発表。

技術選定の経緯

React Native撤退の理由

ただし、React Nativeが悪いわけではない

Airbnbの撤退はReact Nativeの品質が低いからではなく、Airbnb固有の要件（複雑なアニメーション、マップ操作、カレンダー等）がReact Nativeでは実現困難だったため。

React Nativeが適しているケース:

• シンプルなUI（リスト表示、フォーム）
• 小〜中規模チーム
• Web開発者が多いチーム
• プロトタイプやMVP

教訓

「流行の技術が自分たちのプロジェクトに合うとは限らない。技術選定は、プロジェクトの要件とチームの特性に基づいて行うべき。」

事例5: Supabase -- PostgreSQL一本勝負

背景

Supabaseは2020年にFirebaseのオープンソース代替として登場。PostgreSQLを中心に据え、認証、ストレージ、リアルタイム機能を全てPostgreSQLの機能で実現する戦略を取った。

技術選定の経緯

技術構成図

[ユーザー]
    |
    v
[Supabase Gateway (Kong)]
    |
    +-- [PostgREST] -- PostgreSQLから自動的にREST API生成
    |
    +-- [GoTrue] -- 認証サービス
    |
    +-- [Realtime (Elixir)] -- PostgreSQLの変更をWebSocketで配信
    |
    +-- [Storage API (Node.js)] -- S3互換のファイル保存
    |
    +-- [Edge Functions (Deno)] -- サーバーレス関数
    |
    v
[PostgreSQL]
    |
    +-- Row Level Security (テナント分離)
    +-- pg_graphql (GraphQL)
    +-- pgvector (ベクトル検索/AI)
    +-- pg_cron (スケジュールジョブ)
    +-- pg_net (HTTP通信)

PostgreSQL中心戦略の成功理由

1. 既存のエコシステム活用: PostgreSQLの豊富な拡張機能を最大限活用
2. ベンダーロックインの回避: PostgreSQLはどこでも動く。Supabaseから移行しても、DBはそのまま使える
3. 開発者からの信頼: 「データは自分のもの」というメッセージが開発者コミュニティに響いた
4. OSSファースト: 全てのコンポーネントがオープンソース

教訓

「新しい技術を作るのではなく、既存の優れた技術を組み合わせることで、新しい価値を生み出すことができる。」

5つの事例から学ぶ共通パターン

成功の共通要因

技術選定の判断マトリクス

まとめ

各事例のポイント

最も重要な教訓

技術選定に「正解」はない。あるのは「その時点での最善の判断」だけ。重要なのは:

1. 判断の根拠を明確にすること
2. 判断が間違っていた場合に修正できる柔軟性を持つこと
3. チームが使いこなせる技術を選ぶこと

参考リンク

• Netflix Tech Blog
• Discord Blog: Why Discord is switching from Go to Rust
• Shopify Engineering Blog
• Airbnb Engineering - Sunsetting React Native
• Supabase Architecture