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

アプリを提供しているプラットフォームを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バグ対応やストアレビュー対応などが含まれます。

Webとネイティブアプリの違い

ネイティブアプリは、デバイスのハードウェアを扱えたり、プラットフォームのAPIを活用できるため、Webに比べるとできることがかなり広いです。 ただし、AppleやGoogleといったプラットフォーマーの制限を受けます。例えば支払いが発生する場合、プラットフォーマーの手数料が取られるケースがあります。
ユーザーがネイティブアプリを使うには、アプリをインストールするという手間が必要です。 また、ユーザーに新機能を使ってもらうには、アプリをユーザーにアップデートしてもらう必要があります。 Webでは、サーバーサイドの変更でアップデートを提供できます。
ネイティブアプリは、インストールする反面、一度インストールすればユーザーがアクセスしやすいです。 Push通知のような定期的にユーザーを引き付ける要素もあり、Webよりもユーザーエンゲージメントが高い傾向があります。

特徴から見るプロダクトの基本戦略

Webのほうがユーザーへのデリバリー速度が早いので、グロース施策はWebを中心に行います。 ネイティブアプリは、Webで成功したグロース施策を取り入れてエンゲージメントを高め、Webではできないネイティブアプリに最適な施策を中心に開発します。
流入しやすいWebから利用してもらい、アプリのインストールを促し、アプリによる定着という流れができるとよいでしょう。
ネイティブアプリでも、Webと同様のリードタイムにするCodePushziplineのような技術はありますが、高いリスクがあります。高い要求があれば検討していきます。