「地獄のアプリ開発」を経験した元Uberのエンジニアがその真実を語る

大規模なソフトウェア開発は多くの人が関わり、多額の資金が費やされますが、時として社内外の要因によって開発現場が地獄と化す場合もあります。近年ではみずほ銀行の基幹システム開発が書籍化されるほど苦難の道を歩んだことはIT業界で知られていますが、そんな「地獄の開発現場」がかつてUberにも存在したと、元UberのエンジニアであるMcLaren Stanley氏が当時の状況を振り返っています。

ことの発端はLoren Brichter氏の「長い間、ウェブアプリはOSにインストールして使うアプリと同じくらい快適に動作することに挑戦していましたが、ここ数年でその立場は完全に逆転してしまいました。むしろ今日ではアプリは不利なくらいです」というツイートでした。

「Uberアプリのサイズは331MBです」というBrichter氏のツイートに対し、Stanley氏は「Uberのアプリがそんなに大きい理由はSwiftです。Objective-C版のアプリのサイズはSwift版の3分の1でした」とリプライ。

このやりとりを皮切りに、Stanley氏は「これまでに巻き込まれた不幸の中で、最悪の開発現場の悲劇」の話をはじめました。時は2016年までさかのぼります。Uberは当時急成長を遂げていましたが、反面アプリ開発で問題も抱えていました。組織の成長とともにアプリの構造は複雑化していき、バグやデザインの悪化が見られるようになったとのこと。こうした問題を解決するため「アプリを最初から開発し直す」という決定が下され、「先々の5年間におけるUberのモバイル開発を担うに足る」アーキテクチャの設計が始まったとStanley氏は語っています。

iOSアプリの開発言語としてSwiftが選択肢にありましたが、Swiftは数々の問題を抱えていたため利用が禁止されていたとのこと。しかし、アーキテクチャチームはSwiftの問題はほとんどがObjective-Cとの相互運用にあり、純粋なSwiftアプリを開発すれば問題ないと判断。また、AndroidアプリとiOSアプリのアーキテクチャを統一したいという思惑から、最終的にSwiftを開発言語に採用することが決まったとのこと。

アプリの開発開始から数ヶ月の間は、プロジェクトは成功のように思えたそうです。しかし、コアチームでの開発から、全社的な開発へとプロジェクトの軸足を移し始めたあたりから、歯車が狂い始めたとStanley氏。当時のSwiftコンパイラが非常に低速で使い物にならず、アプリのビルドにかかる時間が長くなってしまった結果、デバッグなどがまったく機能しなくなってしまったとのこと。また、当時のSwiftはライブラリを動的にしかリンクすることができなかったため、アプリの起動に最大で12秒もかかるようになってしまったとStanley氏は語っています。

Stanley氏はチームのディレクターに「プロジェクトをやめる必要がある」と話しましたが、すでに計り知れないほどの人的リソースと金額を費やしてしまっており、後戻りできる状況ではありませんでした。また、プロジェクトを諦めることは、ディレクターやその上司、ひいては役員の責任問題にも発展します。そこで開発チームは巻き返しを図るため、適材適所の人材配置を行い、致命的な問題に取り組み始めたとのこと。この時点で、すでに予定していたアプリのリリース日から数週間経過していたため、チームはある企業と秘密保持契約を結んで開発の援助を求めましたが、その企業も問題を解決することはできませんでした。チームはコードの25％にあたる部分の書き直しを強いられたとのこと。

チームの努力によりさまざまな問題に対する解決の糸口がつかめ始めましたが、モバイルデータ通信を用いたアプリインストール時に存在していた100MBのサイズ制限を乗り越えることができなかったとStanley氏。iOS 9以降にサポート対象OSを絞れば新しい機能によりアプリのサイズを圧縮できましたが、当時iOS 8の利用者は数千万人という大規模なものであり、切り捨てるには大きすぎました。しかし、チームは技術上の問題からやむなくiOS 8のサポートを打ち切り、iOS 9以降をサポートするという決断を下しました。

アプリのリリースは盛大に行われ、最初は好評を得ていました。しかし、新しいアプリはユーザーがピックアップ地点を手動で指定しないと「最後にGPSで位置情報を取得した場所」がピックアップ地点となる仕様であったため、現在地とは異なる場所がピックアップ地点となってしまい、ユーザーの評価は次第に悪くなっていったとのこと。チームは仕方なくバックグラウンドでも位置情報を取得するようにアプリの仕様を変更しましたが、これによりUberはユーザーから「邪悪な会社」扱いされ始めたとStanley氏は振り返っています。

ユーザーはこうした仕様変更を受けてUberアプリの位置情報取得を許可しなくなってしまいましたが、アプリは位置情報の取得を前提に設計されていたため、状況はますます悪化。また、ドナルド・トランプ大統領が発したイスラム教圏の入国とシリア難民の受け入れ停止を定める大統領令に対するデモ活動がジョン・F・ケネディ空港で行われた際に、Uberは「ドライバーが抗議を利用して利益を得る」のを防ぐために割増賃金を一時停止することを発表しましたが、この決定が「デモ活動を拡散させようとしている」と世間に受け取られ、「#DeleteUber」活動へと発展。Uberへの風当たりは次第に強くなり始めました。

Uberのアカウント削除を促す「#DeleteUber」がトレンドになった理由とは？ - GIGAZINE

こうした外部要因だけでなく、内部的にも「Swift派」と「Objective-C派」に派閥の分裂が生じていたとのこと。Swift派はSwiftに執着して問題を否定し、Objective-C派は解決策を提示せず不平のみ発するようになり、社内は緊張状態になっていたとStanley氏は語っています。

アプリのサイズに関する問題も、いまだ完全な解決には至っていませんでした。一週間に1.3MBのペースでアプリのサイズが増加しており、三週間後にはまたモバイルデータ通信による制限に達してしまうというタイミングで、社内のデータサイエンティストが制限対象になってしまった場合の影響を分析。その結果はStanley氏が「破滅的でした」と評するとおり、Uberアプリを初めてダウンロードするほとんどの人がモバイルデータ通信を用いているというものでした。

チームはアプリのサイズをなんとか減らすため、コードを1行ずつ調べて不要な機能の削除を行いました。チームは限界に到達しており、疲弊しきっていましたが、誰もが問題に集中していたとのこと。こうした状況は「優秀なエンジニアが輝き始めたとき」だったとStanley氏は語っており、実際にあるエンジニアのひらめきによってアプリのコンパイルが最適化され、11MBものアプリサイズ圧縮に成功。チームは他にもさまざまな問題を解決していきましたが、Uberの成長スピードはすさまじく、アプリのサイズはますます大きくなっていきました。

最終的には、Appleがダウンロード制限を150MBまで緩和し、Swiftのコンパイル時におけるアプリサイズ最適化オプションを提供したことで、開発の余裕が生まれたとのこと。「もしAppleが制限を緩和していなかったら、私たちはコードをObjective-Cに書き直すことを余儀なくされたでしょう」とStanley氏は語っています。

Stanley氏は「途中で大勢の人が燃え尽きました。多額の費用が投入され、手痛い失敗となりましたが、それでも新しいアプリの開発には価値があったと思っています。新しくUberに入社したエンジニアは、アーキテクチャの一貫性を愛しており、その裏にある失敗を知ることはありません」と当時の失敗を前向きに評価。Stanley氏はこの経験から「完璧なプログラミング言語は存在しないため、トレードオフを理解し派閥戦争に発展させないこと」「障害点を設定し、到達した場合は間違いに気づくこと」「批判ばかりで解決策を提示しない人にはならないこと」「ひとつのことに固執して大きな問題を引き起こさないこと」とアドバイスを贈っています。