技術選定の決め手を27件のofficial sourceから抽出して8軸+6問チェックリストにした
TL;DR
技術選定は「速いか」「流行っているか」の直接比較より、まずworkload / failure mode / existing assets / migration shapeで候補を強く絞り、そのあとにiteration speed / performance economics / operational standardization / strategic leverageで順位づけする方が再現性が高い。ビッグテックとスタートアップ27件のofficial sourceを横断して抽出した8軸モデルと、実務で先に問うべき6問のチェックリストを紹介する。
なぜこの記事を書いたか
技術選定の議論は「Rustは速い」「TypeScriptはエコシステムが広い」のような単一軸の比較に陥りやすい。しかし実際にビッグテックやスタートアップのofficial blog / engineering blogを読むと、決め手になっているのは単純なベンチマーク結果ではなく、もっと複合的な判断だった。
たとえばDiscordがgo→Rustに移行した理由は単に「Rustが速いから」ではなく、GCのtail latency spikeがワークロードに合わなかったからだ。StripeがTypeScriptに移行した理由も「型があると便利」ではなく、大規模コードベースのrefactor safetyとmigration toolingが決め手だった。
こうした事例を27件集めて横断的に分析した結果、技術選定の決め手は8つの軸に正規化でき、実務では6問のチェックリストを順に回すことで再現性の高い判断ができることがわかった。
8軸モデル
27件の事例から抽出した技術選定の判断軸を、重複を潰して8つに正規化した。
graph LR
subgraph "順位をつける（下流）"
E["5. Iteration speed<br>変更速度"]
F["6. Performance economics<br>性能と経済性"]
G["7. Operational standardization<br>運用の標準化"]
H["8. Strategic leverage<br>戦略的てこ"]
end
subgraph "候補を絞る（上流）"
A["1. Workload fit<br>ワークロードの形"]
B["2. Safety & reliability<br>一番痛いfailure mode"]
C["3. Ecosystem & asset reuse<br>既存資産の再利用"]
D["4. Migration shape<br>移行の形"]
end上流4軸：候補を強く絞る
1. Workload fit — その技術はワークロードの形に合っているか。high-QPS + low-latencyなのか、long-running orchestrationなのか、CPU-bound batchなのかで、適する技術は根本的に異なる。DiscordがGoからRustに移行したのは、GCのtail latencyがリアルタイム通信のワークロードに合わなかったからだ。
2. Safety and reliability model — 一番痛いfailure modeは何か。Cloudflareがnginxの代わりにRust製のPingoraを作ったのは、メモリ安全性がインフラの信頼性に直結するからだ。DropboxもRustを選んだ理由に、sync engineでのデータ破損リスクの最小化を挙げている。
3. Ecosystem and existing asset reuse — 既存資産をどこまで捨てられないか。FaireがKotlinを採用したのは、既存のJavaコードベースとシームレスに共存できるからだ。新しい言語がどれだけ優れていても、既存のライブラリ・ツールチェーン・チームの知識を活かせなければ導入コストが上回る。
4. Migration shape — 移行は一気か、共存か、config-changeレベルで済むか。MetaのJava→Kotlin大規模移行では、言語選択そのものよりcodemod / translation pipelineが決定因子になった。Vercelのturborepo Go→Rust移行でも、full rewriteよりincremental portを選んだ理由として、機能出荷の継続とinteroperability surfaceの最小化が重要だった。
下流4軸：最終的な順位づけ
5. Iteration and workflow speed — 実行速度だけでなく、editor startup / typecheck latency / hot reloadを含む開発ループ全体の速度。TypeScriptのnative portが注目されたのは、ランタイム性能ではなくエディタのフィードバック速度が主な動機だ。ShopifyのProject References導入も、型チェックのインクリメンタル化による開発体験改善が決め手だった。
6. Performance economics — 絶対性能だけでなく、インフラコストとの兼ね合い。Figmaがc++→WebAssemblyに移行したのは、ブラウザ上でのロード時間3倍改善がユーザー体験に直結したからだ。LinkedInがProtobufを導入したのも、serialization効率がインフラコスト削減に効いたからだ。
7. Operational standardization — mixed toolchainのコストをどう評価するか。MetaのJava→Kotlin移行では、Java/Kotlin混在コードベースを長く抱えるとparallel toolchainsとbuild speed penaltyが乗るため、言語adoption自体が運用標準化の問題になった。AirbnbのBazel移行でも、speedだけでなくhermeticity / repeatability / uniform build layerが決定因子だ。
8. Strategic leverage — この選択は次の標準化やplatform strategyに効くか。SwiftのIDE support拡張がOpen VSX対応でCursor / VSCodium / Kiroまで広がる動きは、editor compatibility自体がstrategic leverageになりうることを示す。MoonBitのWasm-first設計も、cloud-edge / AI-native workflowという将来の基盤を見据えた戦略的選択だ。
ビッグテック vs スタートアップ：重くなる軸の違い
8軸の重みは組織の文脈で大きく変わる。27件の事例を横断すると、以下のパターンが安定して見えた。
graph LR
subgraph "Big tech が重視"
BT1["Migration shape"]
BT2["Operational standardization"]
BT3["Existing asset reuse"]
end
subgraph "共通して重い"
CM1["Safety & reliability"]
CM2["Performance economics"]
end
subgraph "Startup が重視"
ST1["Workload fit"]
ST2["Iteration speed"]
ST3["Strategic leverage"]
end- Big tech は、mixed-codebase cost / shared toolchain / standardization penaltyを強く気にする。新しい技術の導入は「良い技術か」より「既存の数百万行とどう共存するか」が先に来る
- Startup は、workload fit / shipping speed / leverageを強く気にする。既存資産が少ない分、ワークロードへの適合度と開発速度のトレードオフが直接的になる
- 共通して safety / reliability modelとperformance economicsは、規模を問わず強い判断軸になる。ただしbig techはblast radius / compatibility / org-scale reliabilityを、startupはlatency / infra cost / shipping confidenceをより重く見る
代表事例ファミリー28件
8軸モデルの裏付けとなる事例を、6つのファミリーに分類した。各事例にはofficial sourceのURLを付けている。
A. 言語移行 / 型付け導入
| 事例 | 何を選んだか | 何から移ったか | 主な決め手 | 主軸 |
|---|---|---|---|---|
| Meta / Java→Kotlin at scale | Kotlin | Java | null-safety, codemod pipeline | Migration shape, Operational standardization |
| Meta / Translating Java→Kotlin | Kotlin (automated) | Java | headless translator + linters | Migration shape |
| Faire / Kotlin adoption | Kotlin | Java | Java interop, gradual migration, hiring | Ecosystem reuse, Migration shape |
| Expedia / server-side Kotlin | Kotlin | Java | null-safety, conciseness | Safety, Iteration speed |
| Stripe / TypeScript migration | TypeScript | JavaScript (Flow) | refactor safety, migration tooling | Safety, Migration shape |
| Slack / TypeScript at Slack | TypeScript | JavaScript | 大規模保守, type safety | Safety, Operational standardization |
B. ビルドツール / 開発基盤
| 事例 | 何を選んだか | 何から移ったか | 主な決め手 | 主軸 |
|---|---|---|---|---|
| TypeScript native port | Go (native) | TypeScript (self-hosted) | editor startup, typecheck latency | Iteration speed, Performance economics |
| Shopify / Project References | TS Project References | monolithic tsconfig | incremental typecheck | Iteration speed |
| Airbnb / Bazel migration | Bazel | Gradle | hermeticity, repeatability | Operational standardization |
| Vercel / Turborepo Go→Rust | Rust | Go | incremental port, behavior preservation | Migration shape, Performance economics |
| Swift / IDE support expansion | Open VSX | Xcode only | editor compatibility拡大 | Strategic leverage |
C. システム / ランタイム / インフラ
| 事例 | 何を選んだか | 何から移ったか | 主な決め手 | 主軸 |
|---|---|---|---|---|
| Discord / Go→Rust | Rust | Go | GC tail latency elimination | Workload fit, Performance economics |
| Dropbox / Rust in Capture | Rust | Python | memory safety, sync engine reliability | Safety |
| Cloudflare / Pingora | Rust (自社製) | nginx (C) | memory safety at proxy scale | Safety, Performance economics |
| LinkedIn / Protobuf | Protobuf | JSON | serialization効率, 既存framework統合 | Performance economics, Ecosystem reuse |
| Bun / Zig runtime | Zig | — | single binary, low-level control | Workload fit, Performance economics |
| Ghostty / Zig terminal | Zig | — | native統合, explicit control | Workload fit, Strategic leverage |
| TigerBeetle / Zig methodology | Zig | — | deterministic memory, reproducibility | Safety, Operational standardization |
D. フロントエンド / プロダクト基盤
| 事例 | 何を選んだか | 何から移ったか | 主な決め手 | 主軸 |
|---|---|---|---|---|
| Figma / C++→WebAssembly | WebAssembly | asm.js | ロード時間3x改善, runtime fit | Workload fit, Performance economics |
| Shopify / React Native | React Native | Native (iOS/Android) | mobile-web共有, iteration speed | Iteration speed, Strategic leverage |
| MoonBit / Wasm-first設計 | MoonBit (新言語) | — | Wasm-first, cloud-edge/AI-native | Strategic leverage, Workload fit |
E. AI / データ / サービング基盤
| 事例 | 何を選んだか | 何から移ったか | 主な決め手 | 主軸 |
|---|---|---|---|---|
| Uber / Michelangelo | 自社ML platform | — | training-serving consistency, release decoupling | Operational standardization, Strategic leverage |
| NVIDIA Triton / TensorRT-LLM | Triton | — | multi-framework substrate, batching/scheduling | Workload fit, Performance economics |
| Modal / Physical Intelligence | Modal | — | remote inference, topology最適化 | Performance economics, Operational standardization |
| Spotify / Chartify | Python (Chartify) | — | data scientist workflow fit | Workload fit, Iteration speed |
F. 信頼性重視バックエンド / オーケストレーション
| 事例 | 何を選んだか | 何から移ったか | 主な決め手 | 主軸 |
|---|---|---|---|---|
| Remote / Elixir | Elixir | — | reliability, orchestration | Safety, Workload fit |
| V7 / Elixir for AI infra | Elixir | — | fault tolerance, fewer moving parts | Safety, Operational standardization |
| Heroku / Elixir | Elixir | Node.js, Ruby | concurrency model, reliability | Workload fit, Safety |
| Slab / Elixir & Phoenix | Elixir | — | productivity + reliability両立 | Iteration speed, Safety |
6問チェックリスト
8軸を実務で使いやすくするために、6問に圧縮した。各問が主に束ねている軸を併記する。
- この仕事のワークロードは何か？ → Workload fit
- 一番痛いfailure modeは何か？ → Safety and reliability model
- 既存資産をどこまで捨てられないか？ → Ecosystem and existing asset reuse
- 移行は一気か、共存か、config-changeレベルで済むか？ 自動変換/codemod/build-fixで支えられるか？ → Migration shape
- 最適化したいのは何か？ 実行性能 / editor-build feedback / 開発速度 / 運用再現性 / ramp-upのどれか？ → Iteration speed / Performance economics / Operational standardization
- この選択は次の標準化やplatform strategyに効くか？ → Strategic leverage
適用例：3つのワークロード類型
チェックリストは抽象的に見えるが、ワークロード類型ごとに問いの優先順位が変わる。以下の3例で具体的に示す。
A. high-QPS backend / infraサービス
- Workload fitとfailure modeを先に問う — GC tail latency / memory safety / concurrency modelがワークロードに合うか
- 次にMigration shapeとexisting asset reuse — 既存サービスとの共存期間をどう安全に切り抜けるか
- 最後にPerformance economicsとOperational standardizationで順位づけ
代表事例：Discord (Go→Rust)、Cloudflare (Pingora)、LinkedIn (Protobuf)
B. 大規模プロダクトUI / アプリケーション
- Iteration speedを先に問う — runtime speedより、editor/build feedback loop / refactor safety / hot reloadが効くか
- Migration shapeとinteropの良さを重く見る — 既存コードベースとの共存コスト
- Strategic leverageはdesign system / shared tooling / mobile-web横断整合まで含めて見る
代表事例：Stripe (TypeScript)、Shopify (React Native, Project References)、Figma (WebAssembly)
C. AI / データ / MLプラットフォーム
- model名ではなくsystem workloadとしてWorkload fitを見る — バッチ処理なのかリアルタイム推論なのかストリーミングなのか
- Operational standardizationとSafety / reliabilityを早めに問う — training-serving consistencyとrelease decoupling
- Strategic leverageはtraining-serving consistency / team reuse / deployment topologyまで含める
代表事例：Uber (Michelangelo)、NVIDIA (Triton)、Modal (Physical Intelligence)
Tooling / 言語移行に特有の発見
事例を横断して、tooling / language migration固有の知見がいくつか浮かんだ。これは上の8軸モデルでは見えにくい、横断的なパターンだ。
- runtime benchmarkだけで判断すると見誤る — TypeScript native portの動機はランタイム性能ではなくeditor startup / typecheck latency / memory usageだった。Airbnb Bazelも速度よりhermeticity / repeatabilityが決め手
- migration shapeには「toolchain replatforming」も含まれる — アプリケーションコードの書き換えだけでなく、ビルドシステム・エディタ・CIパイプラインの移行も独立した選定観点になる
- mixed-codebase costは時間とともに増大する — MetaのJava/Kotlin混在は、parallel toolchains / build speed penalty / onboarding complexityとして累積した。移行の「共存期間」をどう設計するかが、最終的なROIに大きく効く
- Zig系の選択はRust比較そのものより「制約の束」で語られる — single binary / deterministic memory / low-level control / native統合 / 高速起動という束が、特定のワークロードに刺さる
まとめ
技術選定の再現性を上げるために必要なのは、「どの技術が最強か」を決めることではない。まず自分のワークロード・failure mode・既存資産・移行形で候補を絞り、そのあとに開発速度・性能経済性・運用標準化・戦略的てこで順位をつけるという問いの順番を持つことだ。
この記事で紹介した6問チェックリストの使い方をまとめる。
- まず6問を順に回して候補を絞る
- 各問で迷ったところだけ事例に戻ってrepresentative evidenceを引く
- 最後に8軸へ戻して、抜けている比較観点がないか点検する
この順番なら、事例を増やしても判断が散らばりにくい。
以上。