昨年9月、私たちはiOSおよびAndroid版Proton Mailのメジャーアップデートを開始しました。
表面上、新しいアプリはモダンなデザイン、より良いパフォーマンス、オフライン機能を提供しますが、見た目以上のものがたくさんあります。舞台裏では、アプリは新しいテクノロジースタック上でProton Mailを完全に書き直したものであり、内部的にはエンジニアリングトランスフォーメーションと呼ばれるプロジェクトです。新しい（novel）という言葉は意図的なものです。なぜなら、私たちの知る限り、確立された本番アプリのコンテキストで選択されたテクノロジーが使用されたのはこれが初めてだからです。
この記事は、私たちのチームがこの変革を実現する過程で経験した魅力的な旅に光を当て、コミュニティから寄せられたいくつかの質問に答えることを目的としています。何よりもまず、その背後にある根拠は、現状を変える必要性です。
すべての始まり
物事を変える必要があるという認識は、2023年10月のある金曜日の夕方に生まれました。それは驚くほど明確に具体化しましたが、突然のことではありませんでした。Mailおよびカレンダーモバイル製品に関するユーザー体験に影響を与えている、一見無関係に見える問題の共通点を見つけようと費やした数ヶ月の集大成でした。
単純化しすぎるリスクはありますが、問題点を次の3つの領域に要約できます：
- 品質： iOS版MailとAndroid版Mailは、単独で見ると、品質とパフォーマンスの面で期待を下回っていました。
- iOSとAndroid間の機能格差： 一部の機能は一方のプラットフォームでのみ利用可能であり、もう一方がいつ追いつくかは明確ではありませんでした。
- エンジニアリング速度： 主要な更新や待望の機能が、両方のプラットフォームでタイムリーに提供されていませんでした。
問題の一部はモバイルを超えて広がっており、それらに答えるには、テクノロジードメインから組織のスケーリング、特に急成長しているテック系スタートアップの魅力的な問題空間へと話を逸らす必要がありました。しかし、モバイルエコシステムの脆弱性は、テクノロジーとアーキテクチャに深く根ざしていました。
モバイルエンジニアリングのスケーリング
モバイルエンジニアリングのスケーリングには、バックエンドやWebチームのスケーリングとは意味的に異なる独自の課題が伴います。これらの違いは、プラットフォームの断片化とモバイルエコシステムの運用の現実から生じています。モバイルチームは通常、さまざまなオペレーティングシステムやデバイス（電話、タブレット、時にはウェアラブル）にまたがる複数のプラットフォームをサポートする必要があります。iOSとAndroidにはそれぞれ独自のプログラミング言語、フレームワーク、ツールがあり、複数のチーム、重複したコードベース、プラットフォーム固有の作業と製品関連の作業の間での絶え間ないトレードオフなど、多大な労力の重複につながります。製品提供を同期させるには、膨大な量の調整が必要です。
業界全体の課題は、Protonにとって特に深刻でした。Mailやカレンダーなどの機能性アプリは、市場に出回っているほとんどのモバイルアプリよりも本質的に複雑です。さらに、エンドツーエンド暗号化を処理するために必要なクライアントロジックの追加レイヤーを加えると、特に「厚い」クライアントになってしまいます。当時、AndroidチームはMailをより良い品質基準に書き直すのに忙しく、18ヶ月の大半を費やした投資でした。iOSも再設計が急務であり、カレンダーは言うまでもありませんでした。重複のコストはすべてのエンジニアリングリソースを食いつぶしており、同じことを繰り返していては成功しないことが明らかになりました。
行き詰まっていることを認識することの最大の利点は、それが現在の現状の制約の外で考えるための強制的な要因として機能することです。もし、私たちをここまで導いた選択やコミットメントの重荷から解放され、新たにやり直すことができるとしたら、どうするでしょうか？成功した企業が過去10年間にこの問題にどのように対処したかを詳しく見ると、彼らが次の2つの可能な戦略のいずれかに従ったことに気づきます：
- 彼らは問題に資金を投じ、底なしの投資や莫大なリターンの組み合わせによって高い運用コストを相殺しながら、これまで以上に大きなチームを構築しました。これは、ProtonのVCなしのビジネスモデルにとって選択肢ではありませんでした。私たちは、広告ベースの投資家に支えられた競合他社の支出と競争することはできません。
- 彼らは無駄をなくすためにアプリを再設計し、（可能な限り）共有コードベースを使用してアプリを構築しました。
オプション1は論外であり、進むべきパスは決まっていました。
目的のための手段：適切な技術スタックの選択
次のステップは、実際にその仕事をこなせる技術スタックを選択することでした。
過去15年間、クロスプラットフォームのモバイル開発には、「万能」なソリューションが溢れていました。HTML5、Xamarin、React Native、Flutter、Kotlin Multiplatformなどです。それぞれが、ネイティブ開発を完全に置き換えるという同じ約束を持って登場しました。実際には、ほとんどが完全に失敗するか、厳しく制約された問題空間内でのみ成功しました。プラットフォームの違いを消滅させる普遍的な抽象化はありません。大規模なモバイルアプリを出荷し、保守したことのある人なら誰でもこれを知っています。唯一の信頼できる前進方法は、ツールのトレンドから前進するのではなく、具体的な要件から逆算することです。
私たちはその最終目標を、選択されたソリューションが満たさなければならない一連の交渉不可能な要件（1）に変換し、評価プロセス全体を通してそれらを指針となるフレームワークとして使用しました：
- コストとタイムスケール： スタックは、iOSおよびAndroid全体でProton Mailを出荷、保守、および進化させるために必要なコストと時間を大幅に削減する必要がありました。
- ユーザー体験： ネイティブに近いパフォーマンスとインタラクション品質を維持する必要がありました。それ未満のものは論外でした。
- 戦略的な将来性： ソリューションは長寿命である必要がありました。私たちは、ロードマップが他のベンダーの継続的なサポートに依存するようなサードパーティのフレームワークを避けることについて意図的でした。
最初の2つの制約の間の緊張関係は、この業界における聖杯のようなものです。つまり、「ネイティブアプリのパフォーマンスとユーザー体験を提供するクロスプラットフォームソリューション」です。
私たちは当初から、当時支配的だった2つのクロスプラットフォームフレームワークであるReact NativeやFlutterがこの基準を満たすことができるかどうか懐疑的でした。それでも、Mailのメッセージリストビューの概念実証実装を構築することで、その懐疑論を検証しました。
React Nativeはすぐにその限界を露呈しました。大規模なデータセットをスクロールすると、そのインタプリタ実行モデルのコストが痛いほど明らかになりました。Flutterはより優れたパフォーマンスを発揮しましたが、UIは特にiOSで明らかにネイティブではないままでした。さらに重要なことに、FlutterはGoogleによって管理される独自のフレームワークであり、Googleには社内技術を放棄した歴史(新しいウィンドウ)があり、最近Flutterチームの大部分を解雇していました。長期的なセキュリティと信頼性の保証がある製品にとって、そのレベルの外部依存は容認できませんでした。
Kotlin Multiplatformは次の候補でした。これは魅力的なオプションであり、特に深いAndroidの専門知識を持つ組織にとってはそうですが、最終的には私たちのユースケースには不十分でした。共有UIレイヤーの欠如、成熟度に関する疑問、およびその実行モデルによって導入される追加のオーバーヘッドが、その利点を上回りました。
この時点で、結論は明らかであり、私たちの当初の直感と一致していました。望ましい結果に一貫して近づく唯一のアーキテクチャは、意図的に混合されたスタックです。各プラットフォームのネイティブUI（AndroidではJetpack Compose、iOSではSwiftUI）は、高性能で低レベルな言語で記述された共有ビジネスロジックレイヤーによってバックアップされています。このアプローチには実績があります。Dropboxは、言語の運用コストと認知的コストのために2019年に放棄するまで、モバイルプラットフォーム間でビジネスロジックを共有するためにC++を使用したことで有名です。
2023年末までに、Rustはシステムプログラミング言語の系統における後継者として明確に浮上しました。
RustはC++と同じパフォーマンスエンベロープを占有しますが、その歴史的な負債の多くはありません。ガベージコレクションなしで強力なメモリ安全性保証を提供し、コンパイル時にスレッドセーフな並行性を強制し、大規模で非常に有能なオープンソースエコシステムによってサポートされています。同様に重要なこととして、Rustはネイティブモバイル言語（iOSのSwiftとSwiftUI、AndroidのKotlinとJetpack Compose）とクリーンに統合され、UIレイヤーを侵害することなくコアロジックを共有するための実用的な選択肢となります。
これはリスクのない決定ではありませんでした。当時、Rust中心のアーキテクチャ上に構築された大規模なコンシューマー向けモバイルアプリの例はほとんどなく、チーム内のRustの経験は限られていました。
しかし、有意義なイノベーションが低リスクの領域で起こることはめったにありません。本当の課題はRustそのものではなく、組織の慣性、つまり実績のある保守的なアプローチから、クリアな制約とエンジニアリングの判断に導かれた意図的な実験へと移行することでした。
新しいProton Mail：結果と学び
今日まで早送りして、その賭けがどうなったかを見てみましょう。
下の図は、Mailモバイルのアーキテクチャを表しています。Rustコアは、アプリのビジネスロジック全体を担当しています。私たちはRustの使用を通常のアプリ（ネットワーキング、ストレージ、アルゴリズム計算）を超えて、複雑なナビゲーションロジックの処理にまで押し広げました。その好例が、メッセージリストの無限スクロールを管理するロジックです。型破りではありますが、これはコードの再利用を最大化するという目的を達成するための鍵となりました。その結果、コードベースのほぼ80%がiOSとAndroidで共有されるようになりました。
これは、より速く、より高品質な市場投入につながったでしょうか？最終的な判断を下すにはまだ時期尚早ですが、初期の兆候は非常に勇気づけられるものでした：
- リリース後の2か月間で、チームは両方のプラットフォームで機能更新の毎週のケイデンスを維持することに成功しました（合計12回の機能リリース）。
- プラットフォーム間の機能格差を解消し、スヌーズ、カレンダーRSVP、スワイプして次のメッセージへ移動するなど、待望の機能をAndroidにもたらしました。
- この初期段階でさえ、新しいコードベースは両方のプラットフォームで以前の世代よりも安定していることが証明されています。iOSのクラッシュ率は0.05%（0.12%から低下）である一方、Androidのクラッシュ率は過去のベースライン（0.19%）に戻っています。これは、Rustのランタイム安定性を強く支持するものです。
このアプローチの下では、サポートもより効果的にスケールします。2つの独立したコードベースに分散したわずかに異なるロジックの欠陥から生じる表面上は類似した問題を追跡するよりも、単一の共有された根本原因を特定して解決する方が多くの場合高速です。アプリのオフライン機能を支えるロジックに影響を与えるある種のカテゴリ同期の問題を修正する際に、以前は作業仮説であったものの経験的な確認が見つかりました。1つの根本原因、1つのソリューションです。これは、バージョン7.6.2で出荷されたRebasingモジュールによって上の図で表されています。
コインの裏側は？
- バグやリグレッションは、より広範な影響を及ぼし、両方のプラットフォームのユーザーに影響を与える可能性があります。すべてを手に入れることはできませんが、エンドツーエンド（E2E）テストを過剰に行うことでリスクを確実に軽減できます。
- 水平方向のテクノロジー分割に沿ってユーザー向けソリューションをスライスする場合と同様に、知識のサイロ化が生じ、エンドツーエンドのユーザー体験に対するエンジニアリングの焦点が失われるリスクがあります。これを認識し、意図的にリスクを軽減する必要があります。最も効果的な対策は次のとおりです：
- テクノロジーレイヤーではなく機能を提供するためにサブチームを調整します。
- モバイルエンジニアを「フルスタック」になるようにトレーニングする。つまり、Rustのコードベースとネイティブプラットフォームの両方でデバッグ、サポート、エンジニアリングを行えるようにする。
エンジニアリングトランスフォーメーションの次は
このプロジェクトの当初から、その賭けがProton Mail単独の範囲をはるかに超えていることは明らかでした。この技術スタックをProtonの主力アプリに適用することに成功したことは、常に長い旅の最初のステップとして意図されていました。それは最終的に、このアプローチがモバイルエコシステムの他の部分にも展開されることを意味します。
そのシナリオは現在展開されています。私がこの記事を書いている間、アカウントおよび支払いSDK、ならびに次世代のProtonカレンダーモバイルアプリは、この新しい技術的方向性に合わせて書き直されています。
これは、エンジニアリングトランスフォーメーションの第2の波の始まりを示しています。これは、プラットフォーム間だけでなく製品間でもコンポーネントの再利用を容易にするように設計されたアーキテクチャフレームワークを使用して、テクノロジーの青写真を拡張する進化です。この移行は一夜にして起こるものではありませんが、お客様がProtonに期待する、シームレスに統合されたプライバシー優先のエコシステムを構築するための基本です。
(1)：Simon Lewis、『A strategy for application implementation on multiple platforms（複数のプラットフォームでのアプリケーション実装のための戦略）』、2023年。
