元テックリードが明かす
Twitterがモバイルアプリ改善で無視した「無駄な指標」、重視した「真の指標」
モバイルアプリケーションの性能悪化は利用者の不満を高め、離脱を引き起こす。既存の監視手法では改善効果を証明できず、膨大な検証作業に忙殺されていたTwitterは、この“限界”をどう突破したのか。
企業とエンドユーザーのデジタル接点の中心がモバイルデバイスに移行する中、アプリケーションの品質は事業の成否を分ける。2015年当時、短文投稿サービス「Twitter」(現「X」)は、低スペックデバイスや低速通信の条件下で利用する層の開拓を目指していた。しかし開発現場には、アプリケーションが強制終了するクラッシュ以外の詳細な性能指標が存在しないという課題があった。
そこで開発チームは、バックエンド向けの構造化ログシステムを流用し、遅延などの基本数値を計測し始めた。この取り組みによって初期の改善は収益拡大につながったが、解決しやすい課題が片付くと、状況が変わる。基本的な数値だけでは小さな変更の成果をデータで証明できなくなり、検証作業に膨大な時間を要するようになったのだ。
この壁を突破するため、開発チームは大きな方針転換を迫られた。彼らが構築した独自のデータ収集システムと、パフォーマンスの概念を覆す「ゴールデンメトリクス」の正体とはどのようなものか。元Twitter社のAndroidパフォーマンス部門テックリードの体験談を紹介する。
独自指標を構築して“無駄な検証”から脱却
ロンドンで開催された技術イベント「CNCF-hosted Co-located Events Europe 2025」において、Twitter社でAndroidパフォーマンス部門のテックリードを務めた経歴を持つハンソン・ホ―氏が登壇した。ホー氏はセッション「Transmissions From the Tweet Factory: How Observability Transformed Mobile Performance at Twitter」に登壇し、モバイルアプリケーションにおけるオブザーバビリティ(可観測性)の重要性を説いた。
2019年、アプリケーション改善の限界に直面したTwitterは、“真のオブザーバビリティ”獲得に乗り出した。
当時、バックエンドシステムの開発においては、複数システムをまたがる処理経路を追跡し、遅延やエラー箇所を特定する「分散トレーシング」技術が存在していたものの、モバイルデバイスへの適用は進んでおらず、標準的な手法も確立されていなかった。モバイルアプリケーションは、突然の通信切断やOSによるバックグラウンド処理の強制終了など、サーバよりも過酷な条件で動作することが求められるからだ。
このような制約の下、処理性能が限られたデバイスのコンピューティングリソースを圧迫せずにデータを収集することは極めて難しい。既存の仕組みを適用できないと判断した開発チームは、独自の仕組み「Production Client Tracing」(PCT)の構築に着手した。
PCTは、オープンソースアプリケーション観測ツール「OpenTelemetry」のトレース機能に近い構造を持ちながら、モバイルアプリケーションおよびWebアプリケーションでの動作に特化して最適化されたものだ。Twitter開発チームは既存のインフラにPCTを組み込み、アプリケーションにデータ収集用のソースコードを組み込み、自由なデータ分析を可能にした。
モバイルアプリケーション開発者にとって、処理の開始から終了までの一連の流れを記録し、どこで遅延やエラーが発生したかを追跡、可視化する「トレース」という概念自体がなじみのないものだった。そこで開発チームに対しては、複雑な仕組みを隠す抽象化レイヤーの導入や、適切な計装のためのガイドライン策定といった組織的な支援も並行して実施された。
パフォーマンスの定義を変えた「ユーザー操作失敗率」
PCTを活用することで、これまで見過ごされていた事実が次々と明らかになった。その一例としてホ―氏が挙げたのが、なぜか毎日数万人のエンドユーザーが、ある特定の古いバージョンのアプリケーションを使用し続けている事象の解明だ。
データを分析した結果、この古いバージョンは特定の通信事業者が販売するモバイルデバイスにプリインストールされているものであり、エンドユーザーが意図的にアップデートを避けているわけではないことが判明した。この事実が可視化されたことで、開発チームは改修作業を緊急の課題として扱う必要がないという、データに基づいた合理的な意思決定を下すことができたのだ。
PCTの導入がもたらした最大の功績は、ビジネス目標に直結する新しい「ゴールデンメトリクス」として、「ユーザー操作失敗率」(User-Operation Failure Rate)を発見したことだ。これは「エンドユーザーが開始した操作のうち、正常に完了しなかった割合」で定義される。
従来のバックエンド監視では、システムがリクエストを受け取ってから応答を返すまでの処理時間が重視されてきた。一方でユーザー操作失敗率は、アプリケーションのクラッシュによる失敗だけではなく、処理が遅いためにエンドユーザーが待ち切れずに「諦めた」ケースも「失敗」としてカウントする。
何秒の待機時間を「遅い」と感じるかは、エンドユーザーが使用しているデバイスの性能や通信条件によって大きく異なる。システムの応答速度という単一の指標にとらわれるのではなく、エンドユーザーの期待値に対してアプリケーションがどう応えたかを測ることで、パフォーマンス問題の本質が浮き彫りになる。「エンドユーザーの離脱」を失敗と定義することで、パフォーマンスの悪化がプロダクトへの悪影響を示す指標に昇華したのだ。
独自開発から標準化へ
「システムではなくエンドユーザーを観察する」というアプローチの転換によって、Twitter社は多様な条件下で利用されるアプリケーションの課題を正確に把握し、優先順位を付けて改善できるようになった。
ホ―氏は、「エンドユーザーを中心としたオブザーバビリティの導入が、開発のペースや意思決定の在り方を根底から変えた」と振り返る。
かつてTwitter社のような巨大企業が、膨大な開発費用と人的リソースを投じて独自に構築しなければならなかったモバイルアプリケーション向けのオブザーバビリティシステムは、OpenTelemetryなどのオープンな技術規格として標準化が進み、成熟しつつある。セッションの最後でホ―氏は、OpenTelemetryを活用することで洞察を得ることができると強調した。エンドユーザーの真の体験を可視化する取り組みは、企業規模を問わず、全てのアプリケーション提供者にとって不可欠な手段になっている。
本稿は、Cloud Native Computing Foundation(CNCF)が2025年4月18日に公開した動画「Transmissions From the Tweet Factory: How Observability Transformed Mobile Performance... Hanson Ho」を基に作成しました。
Copyright © ITmedia, Inc. All Rights Reserved.
本記事は制作段階でChatGPT等の生成系AIサービスを利用していますが、文責は編集部に帰属します。
関連記事
新着ホワイトペーパー PR
-
製品資料
[NTTインテグレーション株式会社] 取引先のセキュリティをどう管理する? 「SCS評価制度」対応の勘所を解説 -
製品資料
[NTTインテグレーション株式会社] SCS評価制度「★4」取得のカギ 最大の壁を突破する方法とは? -
製品資料
[NTTインテグレーション株式会社] 2026年度末から運用開始 「SCS評価制度」に備えて製造業がやるべきことは? -
事例
[ネットワンパートナーズ株式会社, アイビーシー株式会社] ハイブリッド環境の一元管理と快適な無線LAN環境、三井ホームはどう実現した? -
市場調査・トレンド
[TD SYNNEX株式会社] 調査で学ぶセキュリティ運用の実態 人を増やさず品質を維持する方法とは?
こんなメディアも見られています
TechTargetジャパンに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
ベンダーコンテンツ PR
From Informa TechTarget
SpecialPR
アクセスランキング
-
1
なぜ「全社配布Copilot」は使われないのか? 失敗に学ぶAI定着
-
2
損保ジャパンはなぜ「COBOL」を捨てなかったのか? 脱メインフレームの真相
-
3
1200万円のSaaS導入を回避 スギ薬局「運用費10万円」のAIエージェント構築術
-
4
100億円の「Linux更新」を回避 みずほ銀行が選んだ“おきて破り”のRHEL延命策
-
5
ITエンジニア1265人調査 生成AIを使い込むほど「人の確認」が重い理由
-
6
AIが本番環境を削除し復旧に13時間 「暴走」ではなかったAWS事例
-
7
高額GPUを買っても成果ゼロ? 「プライベートAI」の落とし穴
-
8
「結局使わなくなる」Microsoft 365 Copilotを半年で定着 キリンの3施策
-
9
レガシー基幹システムをSAPに統合 山善が突き止めた「標準化と個別最適」の境界線
-
10
【漫画付き】"RAG導入失敗3例"と処方箋 「入れても使われない」を終わらせる
ホワイトペーパーランキング PR
-
1
DX/AI投資の壁を突破、現代の最高財務責任者が直面する課題と克服のヒント
-
2
不審メールの経路や見せ方に変化? 2026年夏の3事例から見えた動向と対処方法
-
3
「オンプレミス回帰」せざるを得ない“合理的な理由”
-
4
バックアップは“取っているから大丈夫”なのか? ランサムウェア時代の備え方
-
5
システムの保守がモダン化を阻む? 「変えない判断」から脱却する方法とは
-
6
生成AIを開発に導入しても効果が見えない? 実証実験で分かった成果と課題
-
7
経産省DX指針から読み解く、受発注業務デジタル化ロードマップ
-
8
ネットワーク遅延の原因、「パケットロス」の基礎知識と効果的な解決策
-
9
5分で分かる Microsoft 365のデータ損失に備えるためのバックアップの仕組み
-
10
Microsoft 365を安全に運用 うっかりミスやサイバー攻撃に備えるデータ保護術
TechTargetジャパン SNS
インフォメーション
注目情報をチェック
TechTargetジャパンをフォロー