モバイルアプリ vs ウェブアプリ:プロダクトに適した「形」を選ぶために
私たちが支援したある創業者は、美しくデザインされたネイティブ iOS アプリの開発に 8 万ドル近くを投じました。ローンチから 6 ヶ月後、実際にダウンロードした顧客は 4% にも満たない状況でした。彼のユーザーは製造工場の調達マネージャーであり、勤務時間中はデスクトップブラウザで作業し、個人のスマートフォンに新しいアプリをインストールすることは滅多にない人々でした。そのアプリは間違ったアプリではありませんでした。オーディエンスに対して間違った「形」だったのです。
モバイルアプリ対ウェブアプリという問いは、技術的な決定のように聞こえます。しかし、そうではありません。それは配布に関する決定であり、習慣に関する決定であり、そして技術的な装いをまとった予算に関する決定なのです。
問うべきは、ユーザーが「決める場所」であって、「持ち歩くもの」ではない
どのプロダクトチームも、いずれは同じ問いに行き着きます。「モバイルアプリを作るべきか、ウェブアプリを作るべきか？」しかし、この問いの立て方そのものが最初の誤りです。より優れた問いはこうです。ユーザーがあなたのプロダクトを必要とするその瞬間、彼らはどのデバイスを手にしていて、どのようなネットワークに接続しており、離脱するまでにどれだけの摩擦を許容できるのか？
もしユーザーが電波 1 本の状況で故障した機械の前に立つフィールド技術者なら、オフラインで動作するダウンロード済みのネイティブアプリは贅沢品ではありません。もしユーザーがオフィスのモニターで 3 社のベンダーを比較検討しているマーケティングリードなら、アプリをインストールしてほしいと頼むことは、評価を中断してほしいと頼むことに等しいのです。
プロダクトの「形」を、その瞬間の「形」に合わせること。それこそが真の決定です。
ウェブアプリ:親密さを犠牲にして得るリーチとスピード
ウェブアプリはブラウザ上で動作します。その強みは構造的なものです。1 つのコードベースがあらゆるデバイスに対応します。アップデートはアプリストアの審査を経ることなく、全ユーザーに即座に届きます。Google 検索による発見は、アプリストアのアルゴリズムから勝ち取る必要のない無料のトラフィックです。
トレードオフはエンゲージメントの深さです。ウェブアプリはデバイス機能へのアクセスが限られています。iOS のプッシュ通知は依然として制約があります。バックグラウンド同期は不安定です。カメラや Bluetooth との緊密な統合は成功したり失敗したりします。さらに、ウェブアプリはブラウザのタブの中に存在し、他の 15 個のタブと競い合います。ユーザーはブラウザのタブを中心に日々の習慣を築くことはなく、ホーム画面のアイコンを中心に習慣を築くのです。
プロダクトが評価され、比較され、あるいは時々しか利用されない場合には、ウェブファーストを選択してください。これは、ほとんどの B2B ツール、SaaS ダッシュボード、マーケットプレイス、コンテンツサイト、そして大部分の EC サイトに当てはまります。
ネイティブモバイルアプリ:リーチを犠牲にして得る親密さと深さ
Swift や Kotlin、あるいは React Native や Flutter のようなクロスプラットフォームフレームワークで構築されたネイティブアプリは、ホーム画面に居場所を持ちます。その場所は単なる不動産ではありません。それは頻度の約束です。ユーザーは、頻繁に開くことを想定したプロダクト、例えば銀行、配車、フードデリバリー、フィットネス、メッセージング、ゲームなどのアプリをインストールします。
ネイティブアプリはハードウェアへのアクセスも解放します。信頼性の高いプッシュ通知、バックグラウンド GPS、カメラや生体認証 API、オフラインデータ、Bluetooth 周辺機器などです。もしプロダクトがこれらのいずれかに依存しているなら、ブラウザはあらゆる場面であなたと戦うことになるでしょう。
トレードオフはコストと摩擦です。2 つのコードベース、あるいは独自の複雑性を抱えた 1 つのクロスプラットフォームコードベース。修正を数日間ブロックし得るアプリストアの審査サイクル。そして最大のハードルは、そもそもユーザーにインストールしてもらうことです。すべてのインストール画面は崖です。業界データは一貫して、アプリストアのリスティングを訪れた人のうち、実際にインストールするのは 4 人に 1 人未満であることを示しています。ブランドへの信頼がまったくない初回訪問者の場合、この数字はさらに悪化します。
プロダクトが毎日または毎週使われる場合、ハードウェアが重要である場合、そして価値が明白であるためオーディエンスがインストールを厭わない場合には、ネイティブを選択してください。
中間の選択肢は実在し、そしてしばしば活用されていない
両極端の間に位置する 2 つの選択肢があり、ベトナム市場ではあまり活用されていません。
Progressive Web App、略して PWA は、ホーム画面にインストールでき、オフラインで動作し、Android でプッシュ通知を送信できるウェブアプリです。iOS のサポートは改善されつつありますが、依然として部分的です。多くの B2B ツールや社内ツールにとって、PWA はネイティブの恩恵の 80% を、コストの 30% で提供します。
React Native や Flutter のようなクロスプラットフォームフレームワークは、1 つのエンジニアリングチームが共有コードベースから iOS と Android の両方に出荷することを可能にします。ネイティブの磨き上げをいくらか諦め、わずかなパフォーマンス税を支払うことになりますが、ほとんどの業務アプリではそのトレードオフに価値があります。1 つのチーム、2 つのプラットフォーム、そしてより速いイテレーションです。
この決定においてクライアントが犯す 5 つの誤り
- 競合がアプリを持っているという理由でネイティブを構築する。 競合のアプリは墓場かもしれません。真似する前に、彼らのアプリストア評価とダウンロード数を確認してください。
- 安いという理由でウェブを構築する。 初期見積もりは確かに安いです。しかし、低いエンゲージメント、失われたユーザー、そして 2 年目の再構築を含む「間違った形」の生涯コストは、決して安くはありません。
- インストールの崖を過小評価する。 創業者はユーザーがインストールしてくれると仮定します。現実のユーザーは、インストール意欲が生じるまさにその瞬間に、強力で具体的な理由を必要とします。
- ユーザーの実際のデバイスやネットワークを無視する。 洗練されたネイティブアプリも、共有のローエンド Android 端末を使い、途切れがちな倉庫内 Wi-Fi しか使えない倉庫作業員にとっては役に立ちません。
- すべてを一度にやろうとする。 小規模チームで初日にウェブ、iOS、Android のすべてを出荷することは、3 つすべてが凡庸なものになることを保証します。
私たち自身の仕事から:短い事例
あるベトナムの物流会社は、ドライバー向けのネイティブ iOS 専用アプリに 6 ヶ月と多額の予算を費やした後、私たちのもとを訪れました。ドライバーはローエンドの Android デバイスを使用しており、シフト間で共有していました。そのアプリは決して普及しませんでした。私たちはこれを、ディスパッチャーが SMS で送信できる短い URL からインストール可能な、Android ファーストの PWA として再構築しました。6 週間以内に、稼働中のドライバーの 80% を超える普及率に達しました。技術的にはそれほど印象的ではありませんでした。しかし、「合致度」は遥かに優れていたのです。
あなた自身の決定のための 5 ステップのロードマップ
- ユーザーの瞬間を描写する。 誰が、どのデバイスを、どのネットワークで、どのような心境で持っているとき、あなたを必要とするのか？1 段落で書き出してください。
- 利用頻度をランク付けする。 毎日、毎週、毎月、あるいは時々。「時々」はほぼ常にウェブファーストを意味します。
- ハードウェアの必要性を監査する。 プッシュ通知、GPS、カメラ、オフライン、Bluetooth、生体認証。いずれかに強い「はい」があれば、ネイティブか PWA の方向へと押し出されます。
- 配布方法を見積もる。 新規ユーザーはどのようにあなたを見つけるのか？SEO とリンクはウェブに有利です。既存の信頼度の高い顧客からの紹介はネイティブに有利です。
- まず 1 つの「形」にコミットし、それをうまく出荷する。 6 ヶ月で優れたウェブアプリを作ることは、12 ヶ月で凡庸な 3 プラットフォーム同時ローンチをするよりも優れています。
要点
モバイルアプリとウェブアプリの選択は、技術的な問いではありません。それは、ユーザーがあなたのプロダクトと出会う瞬間の「形」に関する問いです。「形」を正しく捉えれば、技術は実装の詳細になります。間違えれば、どれほど優れたエンジニアリングもローンチを救うことはできません。
もしあなたがこの決定を検討しており、最もエンジニアリングコストがかからない選択肢を含めて、率直なセカンドオピニオンを求めているなら、MerkTechs チームは喜んでお話しする用意があります。私たちはこれらの「形」のそれぞれを、実際のベトナム企業のために構築してきました。その中には、誤った選択から始まり、正しい選択にたどり着くための支援を必要とした企業も含まれます。