アプリを提供するプラットフォーム

アプリを提供しているプラットフォームをWebアプリとネイティブアプリの2つに大別し、それぞれの特徴からリリース戦略をあげて、Wantedlyとしての基本戦略を書いていきます。

Webアプリ

Webアプリは、Webブラウザ上で利用できるアプリです。

デスクトップとモバイルのデザインがあり、閲覧するデバイスや画面幅によってレスポンシブに切り替えます。モバイルは、デスクトップから機能を制限することや、モバイルのデザインがない場合があります。

Webアプリは、デプロイ容易性が高い特徴があります。

リリースしたい機能や施策ごとにPull Requestを作成し、Pull Requestをマージすることで即座にデプロイされます。 Pull Requestのマージをリリース決定判断とすると、リリース決定判断からユーザーに届くまでのリードタイムは、10分前後です。

デプロイ容易性を活かし、Canary Releaseによりバグの影響範囲を最小限に抑えたり、デプロイのロールバックを行うことでユーザー影響を素早く最小限に抑えることができます。

ネイティブアプリは、Webブラウザを介さず、OSのようなプラットフォーム上でネイティブに動作するアプリです。

代表例として、iOSとAndroid向けのネイティブアプリがあります。他にもiPadやmacOS、Windowsのデスクトップアプリもネイティブアプリに該当します。

プラットフォームごとに最適なデザインが異なります。プラットフォームを横断してデザインする際には、各プラットフォームの特徴を捉える必要があります。

ネイティブアプリは、ユーザーがアプリをインストールしてユーザーが利用可能となるため、アプリを配信する必要があります。基本的にApp StoreやGoogle Playといったプラットフォーマーのストアへ配信し、プラットフォーマーの審査を通ったらユーザーが利用可能となります。

プラットフォーマーの審査は、半日から2日程度かかる場合もあり、コントロールできません。そのため、リリース決定判断からユーザーに届くまでのリードタイムが長くなります。

ストアでアプリをリリースしても、ユーザーがアップデートをしない限り、新しいバージョンがユーザーに届きません。一度ユーザーに届いてしまったバグは、バグを修正したアップデートをユーザーがインストールしない限り、ユーザーの手元に残り続けます。

こういった特徴から、ネイティブアプリのリリースは、品質を重要視します。そのため、リリースごとに1週間程度の準備期間を設けています。 QAの実施期間、デザイナーによる品質確認、QAバグ対応やストアレビュー対応などが含まれます。

ネイティブアプリは、デバイスのハードウェアを扱えたり、プラットフォームのAPIを活用できるため、Webに比べるとできることがかなり広いです。ただし、AppleやGoogleといったプラットフォーマーの制限を受けます。例えば支払いが発生する場合、プラットフォーマーの手数料が取られるケースがあります。

ユーザーがネイティブアプリを使うには、アプリをインストールするという手間が必要です。また、ユーザーに新機能を使ってもらうには、アプリをユーザーにアップデートしてもらう必要があります。 Webでは、サーバーサイドの変更でアップデートを提供できます。

ネイティブアプリは、インストールする反面、一度インストールすればユーザーがアクセスしやすいです。 Push通知のような定期的にユーザーを引き付ける要素もあり、Webよりもユーザーエンゲージメントが高い傾向があります。

Webのほうがユーザーへのデリバリー速度が早いので、グロース施策はWebを中心に行います。ネイティブアプリは、Webで成功したグロース施策を取り入れてエンゲージメントを高め、Webではできないネイティブアプリに最適な施策を中心に開発します。

流入しやすいWebから利用してもらい、アプリのインストールを促し、アプリによる定着という流れができるとよいでしょう。

ネイティブアプリでも、Webと同様のリードタイムにするCodePushやziplineのような技術はありますが、高いリスクがあります。高い要求があれば検討していきます。

最終更新 11 か月前