技術選定の失敗事例5選: Twitter, Uber, Medium, Healthcare.gov, Digg

はじめに

技術選定の「失敗」から学べることは、成功事例以上に多い。失敗事例を知ることで、同じ過ちを避け、より良い判断ができるようになります。本記事では、5つの有名な技術選定の失敗事例を分析し、その教訓を解説します。

身近な例えで理解する技術選定の失敗

技術選定の失敗は「家の建て方の失敗」に似ています。

• 基礎が弱い家 = スケールを考慮しない技術選定。住人が増えると家が傾く
• 増築しすぎた家 = マイクロサービスの過剰分割。部屋が多すぎて管理不能
• 流行に飛びついた建材 = 新技術への過度な期待。見た目は良いが耐久性がない
• 設計図なしの家 = アーキテクチャ設計なしの開発。後から修正できない

事例1: Twitter -- Ruby on Railsのスケーリング限界（Fail Whale時代）

背景

Twitterは2006年にRuby on Railsで構築された。初期は小規模なサービスだったが、2007年のSXSWでブレイクし、急激なトラフィック増加に対応できなくなった。「Fail Whale」（サービスダウン時に表示されるクジラの画像）が日常的に出現するようになった。

何が問題だったか

[問題のアーキテクチャ]

[全ユーザー] --> [Ruby on Rails (モノリス)]
                     |
                     v
                [MySQL (単一DB)]
                     |
                     v
                [Fail Whale が頻出]

問題点:
1. Rubyの処理速度が遅い（特にCPU負荷の高い処理）
2. 単一データベースのボトルネック
3. タイムライン生成が非効率（毎回DBクエリ）
4. キャッシュ戦略が不十分

タイムライン

移行後のアーキテクチャ

[ユーザー]
    |
    v
[API (Scala + Finagle)]
    |
    +-- [タイムラインサービス (Scala)]
    |   （Redis + Memcached でキャッシュ）
    |
    +-- [ツイートサービス (Scala)]
    |   （Manhattan DB）
    |
    +-- [検索サービス (Java)]
    |   （Earlybird - Luceneベース）
    |
    v
[データストア]
    +-- [Manhattan (独自KV Store)]
    +-- [MySQL (一部)]
    +-- [Redis + Memcached (キャッシュ)]
    +-- [HDFS (分析データ)]

何が間違いだったか

ただし、最初からScalaで始めるべきだったかは議論がある

Ruby on Railsの生産性の高さがあったからこそ、Twitterは最速でプロダクトを市場に投入し、ユーザーを獲得できた。最初からScala/Javaで開発していたら、ローンチが1年遅れ、その間に競合に負けていた可能性もある。

教訓

「MVPの技術とスケール時の技術は異なっても良い。ただし、スケーリング計画は早めに準備すべき。」

事例2: Uber -- マイクロサービスの過剰分割

背景

Uberは2010年にPythonのモノリスとして開始。急成長に伴い、2014年頃からマイクロサービスアーキテクチャへの移行を大規模に推進した。しかし、マイクロサービスの数が爆発的に増加し、管理が困難になった。

何が問題だったか

[問題: マイクロサービスの爆発]

サービス数の推移:
2014年: 数個のサービス
2016年: 500以上のサービス
2018年: 2,000以上のサービス
2020年: 4,000以上のサービス

問題:
1. サービス間の依存関係が複雑すぎて理解不能
2. 1つの機能変更に10以上のサービスの修正が必要
3. デバッグが極めて困難（分散トレーシングが必須）
4. 各サービスのオーナーシップが曖昧
5. テスト環境の維持コストが膨大

マイクロサービス過剰分割の典型的な問題

Uberの対応

Uberは「Domain-Oriented Microservice Architecture（DOMA）」というアプローチを提唱し、マイクロサービスをドメイン（業務領域）ごとにグループ化する戦略に移行した。

[DOMA (Domain-Oriented Microservice Architecture)]

[Gateway Layer]
    |
    +-- [Rider Domain]
    |   ├── サービス群（10-20個）
    |   └── ドメインゲートウェイ
    |
    +-- [Driver Domain]
    |   ├── サービス群（10-20個）
    |   └── ドメインゲートウェイ
    |
    +-- [Trip Domain]
    |   ├── サービス群（10-20個）
    |   └── ドメインゲートウェイ
    |
    +-- [Payment Domain]
        ├── サービス群（10-20個）
        └── ドメインゲートウェイ

各ドメイン内のサービスは自由に通信可能。
ドメイン間の通信はドメインゲートウェイ経由。

教訓

「マイクロサービスは銀の弾丸ではない。モノリスの問題をマイクロサービスが解決するのではなく、ドメイン境界の適切な設計が問題を解決する。」

事例3: Medium -- Node.jsからGoへ、そして結局Node.jsへ

背景

Mediumは2012年にNode.jsで構築されたブログプラットフォーム。2017年頃にGoへの移行を試みたが、最終的にNode.jsに戻った。

何が問題だったか

失敗の原因

[失敗の構図]

1. 「Node.jsが遅い」という漠然とした不満
     ↓
2. 「Goなら速くなるはず」という期待
     ↓
3. Goで一部サービスを書き換え
     ↓
4. 問題:
   - Goのエコシステムが不十分（当時）
   - チームのNode.js経験を活かせない
   - 書き換え自体にリソースを消費
   - 本当のボトルネックはDB/キャッシュだった
     ↓
5. 結論: Node.jsに戻り、本当のボトルネックを修正

本当の問題はどこにあったか

教訓

「言語やフレームワークの変更で全てが解決すると思うのは危険。まず本当のボトルネックを特定し、最小限の変更で対処すべき。」

事例4: Healthcare.gov -- 技術選定以前の問題

背景

Healthcare.govは米国の医療保険制度改革（オバマケア）のWebサイト。2013年10月1日のローンチ当日にシステムがほぼ完全にダウンし、数ヶ月にわたって深刻な障害が続いた。

何が問題だったか

障害の規模

[ローンチ日の状況]

想定: 250,000同時ユーザー
実際: 5,000,000以上がアクセス

結果:
- 登録完了できたユーザー: 約6人（初日）
- エラー率: 99%以上
- 復旧までの期間: 約2ヶ月
- 追加投資額: 数億ドル

修正チームの対応

Google、Oracle、Redhat等からエンジニアが集められ、「Tech Surge」チームとして修復に当たった。

教訓

「技術選定の失敗は、技術そのものだけでなく、プロジェクト管理、テスト、組織の問題が原因であることが多い。」

事例5: Digg v4 -- 全面リニューアルの失敗

背景

Diggは2000年代のソーシャルニュースサイトの先駆者。2010年にDigg v4として全面リニューアルを行ったが、ユーザーの大量離脱を招き、実質的にサービスの終焉となった。

何が問題だったか

タイムライン

[Diggの衰退]

2004年: Digg創業。LAMP（Linux+Apache+MySQL+PHP）で構築
2007年: 月間3,000万ユニークユーザー。絶頂期
2010年8月: Digg v4リリース
         - Cassandra + Python に全面書き換え
         - UI/UXも全面刷新
         - 人気機能（bury機能等）を削除
2010年9月: ユーザーの26%が離脱
         - Redditに大量のユーザーが流出
2012年: 50万ドルで売却（最盛期の評価額は1.6億ドル）

「全面書き換え」はなぜ危険か

Joel Spolsky（Stack Overflow創業者）は「全面書き換えは、ソフトウェア企業が犯し得る最悪の戦略的ミス」と述べている。

教訓

「全面書き換えは最後の手段。段階的な改善（ストラングラーフィグパターン等）で、リスクを最小化しながら進化させるべき。」

5つの失敗から学ぶ共通パターン

失敗の共通要因

失敗を避けるためのチェックリスト

まとめ

各事例のポイント

最も重要な教訓

1. 技術の問題は、多くの場合、技術そのものではなく使い方の問題
2. 全面書き換えは最後の手段。段階的な改善が原則
3. 流行の技術ではなく、チームが使いこなせる技術を選ぶ
4. テストとモニタリングは技術選定と同じくらい重要

参考リンク

• X (旧Twitter) Engineering Blog
• Uber Engineering Blog
• Joel Spolsky: Things You Should Never Do
• Healthcare.gov Post-Mortem
• Martin Fowler: StranglerFigApplication