商材の性質やシーンに応じてスマホアプリをGooglePlayやAppleStoreのようなストアに公開することがマイナスに働くこともあります。
商材として価値の有る電子データをお持ちの商社さんとアプリ化の話をしていて、
「それはスマホアプリにしてストアで公開すると上手く行かないかもなぁ・・・」
経験上そう思ったことが有りました。
この記事ではそう思う原因になった、実際に幾度か仕事でストアアプリを開発運営して「これはキツい」と思った７点を挙げたいと思います。
プロジェクトを企画する際「スマホユーザを掴むにはアプリだよね」と安易にストアアプリにせず、ストア公開することにはデメリットも有ることを知っておけば、他の選択肢を取ることが出来てビジネスチャンスが広がるかも知れません。
目次
- 1 B2Bアプリの定義
- 2 お勧め出来ない理由
- 3 結論
- 4 どうしてもアプリにするならPWAにする
- 5 ストアはゲームプラットフォームと捉え、ビジネスアプリはPWAでWebと共存へ
B2Bアプリの定義
ここでは「特定業種の複数他社に対して、業務支援を行う為の電子データ商品を売買するパッケージ」と定義します。
（＊）因みにこれは企業が開発するエンタープライズビジネスアプリの話です。C2Cアプリや規模が小さいB2Cゲームアプリならストアに公開するメリットは有ります。私自身も個人的にストアアプリを開発していますし、ストア方針を全面批判するものではありません。
お勧め出来ない理由
(1) アプリ内課金が基本なので課金方法を柔軟に設定出来ない
対企業向けアプリはユーザ企業の規模やルールに合わせて料金体系をカスタマイズしないと採用されない可能性が有ります。
「うちの会社は月末締めの固定費でないと予算が下りないんだよね」
みたいな感じです。料金プランを柔軟にして顧客を増やしたいところですが、ストアで公開されたアプリの電子商品売買は一律してストアの課金APIを通して行うルールになっています。
この為例えば、
未契約企業や個人ユーザはアプリ内課金で決済するが、
大口サービス契約法人は自前の決済サービスで月末決済にする
といった例外的な決済を含む運用が出来ません。もしこういった実装を行ってアプリ審査時のレビューでAppleやGoogleに発覚した場合、審査がリジェクトされ、アプリを公開することが出来ません。
事実上、ストアアプリでの電子データ商品売買はストア決済を使うしか方法が無く、ストア決済ではビジネス戦略に合わせた料金設定が難しく、サービス展開がし辛いです。
例外
ストア決済でなくても良い例外として、Tシャツのような現実世界の品物を売買する場合があります。B2Bではサーバなどのアプライアンス商品がこれにあたるかも知れません。しかしこういった販促アプリはカタログになり勝ちで、Webで代替出来ます。Appleのアプリ審査条件には「Webでは実現出来ない事」が挙げられており、これもまた審査に通らない可能性が高くなります。「Webサイト立ち上げればアプリにする必要は無いでしょ？」と言われるんですね。
4.2 最低限の機能Appを作成する際は、Webサイトを単に再パッケージしたようなものではなく、優れた機能、コンテンツ、UIを作成するようにしてください。特に便利でも、ユニークでも、「Appらしく」もない場合、そのAppをApp Storeで提供することはできません。
https://developer.apple.com/jp/app-store/review/guidelines/#minimum-functionality
実際、物販を行うならWebサイトの方が流入経路が多いのでアプリ化のメリットは余り在りません。
折角開発したのに審査レビューで落とされては売上どころか開発費用も回収出来ません。
理由１のまとめ
ストアアプリは顧客に合わせた料金戦略を立てることが難しい。
(2) ストア決済は要30%の手数料、2年目からの手数料減額は全てに対してではない
ストアで公開したアプリでマネタイズするにはストア決済（アプリ内課金）を使わなければならないことが分かりました。
「それでもいい」と決めたら次は決済手数料について知っていきます。ストア決済では以下のいずれのタイミングでも、売り上げの30%をGoogle、Appleに支払う必要があります。
- 有料アプリが売れた
- アプリ内課金が発生した
- 月額課金などの定期購読の料金支払いが発生した
最安値の価格設定である100円の場合、70円が運営の取り分、30円がGoogle、Appleの取り分になります。
2年目から15%になる、と公式アナウンスがありますが、これは「3．定期購読が発生した」に対してであり、「定期購読を1年間続けたユーザ」が対象です。
有料アプリの購入、消費型のアプリ内課金に関しては2年目も手数料30%のままです。1年サービスを継続運営したからといって、翌年から全てのユーザ課金手数料が減額される訳ではありません。
定期購読タイプ課金の手数料減額は嬉しいですが、ビジネスユースだとオンデマンドの商品が主だったりするので、減額メリットを享受できるケースは限られてきます。
ストアサーバ運用、レビュワ人件費を考えると30%の手数料は妥当なのかも知れません。しかしStripeやPaypal等のカード決済代行サービスの手数料が3～6%あたりなのを考えるとGooglePlay、AppleStoreのビジネスプラットフォームとしての魅力は薄れます。
理由２のまとめ
手数料30%は高すぎる。15%減額も提供機能によるので使いづらい。
(3) 課金トランザクションを作れない怖さ
アプリ内課金の場合、ユーザが課金ボタンを押したタイミングで決済が完了します。その間にアプリ側に制御が戻ってくることはありません。
電子データを売る場合にユーザが購入ボタンを押した後にデータを作るとします。その際に何かしらのエラーが発生した場合、課金が発生しているにも関わらず商品を渡せないことになり、空売りになってしまいます。
実際には納品（課金トークンを消化）するまで課金処理が終わらないように実装しますが、ビジネスによっては外因的要因で再実行しても納品物を作れないかも知れません。その場合は空売り確定です。
課金トークンを消化出来ない為に課金処理は終わっていませんが、ストア決済は完了してしまっています。
「商品を渡せなかった方が悪い」という訳です。
しかもまずいことに支払いをキャンセルするAPIは提供されていない為、アプリ側で「商品がお渡し出来ないので返金します」のような対処を実装することが出来ません。
対策として「データが整ってから課金ダイアログを出す」実装にすれば危険性は下がりますが、例えば「自社グループ会社の他の課金サービスBにアクセスして代理購入、代行料を徴収するアプリ」の場合を考えてみましょう。
Bサービスに運営が自腹課金をして商品を確保し、代行料を上乗せした金額を課金ダイアログに表示するとします。
商品は必ず納品出来る状態ですが、ユーザが購入する、しないを課金ダイアログ上で決めるのはこの時です。
ユーザが「購入しない」と意思決定した場合・・・課金サービスBに対する運営側の出費が発生するだけになります。間の抜けた話になりますね。
理由３のまとめ
決済から商品お渡しの処理を制御出来ない為、決済前に商品の授受が確定出来ないビジネスにアプリ内課金は適合しない。
(4) 払い戻しが鬼門
前項のような課金後エラーが発生した場合、アプリ利用者主動の払い戻しを強いてしまうことになります。またエラーでなくともユーザの意志で払い戻しを要求されることもあります。
その際Google、Appleで払い戻しに関するお金のスタンスが異なることに注意が必要です。
- Google：手数料30%は翌月運営側に返却する
- Apple：手数料30%は運営側には返却しない
iOSアプリではアプリ利用者に対する払い戻しはAppleの取り分まで運営側が支払わなければいけません。
100円のアプリ内課金を払い戻した場合、30円の赤字になってしまいます。これでは最早ビジネスとは呼べません。
ゲームなどではゲーム内通貨を用意することで現金決済を切り分けて対処するケースが多いです。
ビジネスアプリでも「電子的な購入チケット」を現金で課金し、購入の際は購入チケットを使う方法が考えられますが、この場合は「資金決済法」と呼ばれる日本の法律に準拠する必要があります。
会社が倒産してサービス継続出来なくなった場合でもアプリ利用者に購入チケット代を返済出来るよう、自治体に供託金を預けるなどの必要が出てくる訳です。
そこまでしてストア公開する必要があるのか・・・？
と疑問符がついてくるんじゃないでしょうか。
理由４のまとめ
AppStoreを使ったビジネスアプリは最悪赤字の可能性すら出てきます。
(5) 両プラットホーム運用は片方に引きずられる
Android、iOSアプリを公開していて、バックエンドとなるクラウドサービスがあるとします。
次回のアプリリリースはバックエンドのRESTサービスが更新されている必要がある為、バックエンドサービス更新と同時でなければならない、などということは往々にして発生します。
この際、Androidは審査が通ったがiOSはリジェクトされたとします。
古いままのiOSアプリでは新しいRESTを使えない為、Android新版リリース、バックエンド更新をiOS審査が通過するまで出来ないという運用障害が発生してしまいます。
こうなってしまったら全体的なサービス展開は遅れ、iOSアプリ審査を通す為の追加開発費用も発生します。
Androidの審査はリリース後審査なので提出直後は機械審査の為比較的通りやすいですが、iOSの場合は審査時に人間のレビュワが目を通します。
AppStoreの運営方針も変更が入りやすい傾向がある為、長らく審査に通っていたアプリの審査が通らなくなる、なんてことも珍しくありません。
理由５のまとめ
Google、Appleによる審査という外的要因が入ることによって主体的なサービス運営計画に歪が生まれることは計算の内に入れておく必要があります。
(6) アカウント取り消しに陥った場合、企業イメージ低下は免れない
アプリをリリース出来なくてはサービス存続が危うくなり、事前にユーザ企業と契約でもしていた場合、運営側は是が非でも審査を通そうとします。
AppleやGoogleにメールを送って事情を話してもレビュー審査が覆ることは殆どなく、同じ内容の指摘内容が再送信されてくるだけです。
何回もこれを繰り返すと最悪の場合、Googleアカウント停止、Apple Developperアカウント停止になります。
判断がグレーな点として、前述のTシャツのような物販以外でも「アプリ内で使用するのではない電子データ」もストア決済を使わなくて良いと言われています。
ですがアプリ内で使わないかどうかを判断するのは提出側ではなくレビュー者で、こちらの想定とは裏腹に「アプリ内課金を使ってください」と指摘を受ける可能性は有ります。
「電子データを売ってるけどこれはアプリ内で使用するものではありません」と幾ら主張してもレビュワには届かない可能性が高く、正当と思われる抵抗でも、改善なく行えばGoogleやAppleにとっては有害なアカウントと見做されてしまいます。
こちらはストア開発者アカウントを作る際、契約文に合意をしている為、法的にも彼らの方が有利です。
アカウント停止になればその企業名で二度とGooglePlay、AppStoreにアプリを公開出来なくなります。
企業のGoogleアカウントの停止は他にもGoogleアナリティクス、Googleアドセンス、Google Search Consoleその他諸々が使えなくなることを意味します。これらに依存している場合代償は大きいです。
理由６のまとめ
ストアをビジネスプラットフォームにすると「Apple、Googleには絶対服従」という社訓でも出来てしまいそうです。
(7) ゲームアプリ以外はストアの広告力に期待出来ない
それでもストアに載せれば広告力が有るんじゃ・・・と言う方も居ますが、正直な所そこに過剰な期待を寄せるのは得策ではないかも知れません。
ストアに検索をしにくるスマホユーザは若年層の個人ゲームユーザが大半という統計が出ています。
企業アプリを探している決裁権のある人はまず少数ですし、少々DLされても検索順位が上がることはほぼ無いからです。
ストアの広告力に期待するなら、
- Google広告を出す
- ランディングページを作ってSEO対策し、Google検索流入を狙う
- 各種SNSで広報し、認知度を上げる
を地道にやっていく方が成果が上がります。Google検索が導線として機能するのであればストアの広告力に頼る必要は有りません。
理由７のまとめ
ビジネスアプリの場合、期待している程の広告力はストアには有りません。
結論
ゲームやB2Cではない、契約の伴ったB2B用途なら特に、アプリをストアに公開するメリットは薄く、足枷の方が多くなります。
どうしてもアプリにするならPWAにする
とはいってもアプリとしてインストールさせることが出来れば安定した固定顧客としてロックイン出来る強みは有ります。営業窓口さんのスマホへプッシュ通知が出来れば営業人件費の削減にも繋がります。
「Progressive Web App」はHTTPSのWebサイトをストアアプリと同じようにスマホへインストール出来る技術です。
昨今ビジネス系のアプリはストアアプリからPWAアプリに移行する動きが顕著です。以下のようなメリットがあります。
PWAのメリット
- Webからの流入ユーザをアプリユーザにコンバージョン出来る。
- 自由に公開出来るので審査に落ちて運用がままならななくなる事態が無い。
- リリースはHTTPSサーバへのアップロードのみで一瞬。運用がスムーズ。
- ストアアプリでは無理だった個人課金、契約企業課金の併設が可能。
- アプリ内課金以外なら決済までのトランザクションを作ることが出来る。
- アプリ内課金以外の決済なら30%も手数料を取られない。
ストアの制約が無くなることで、出来なかったことが出来るようになります。
PWAのデメリット
- HTTPSサイトを用意する必要がある。
- 個人ユーザの課金に対する心理的不安を解消する必要がある。
- スマホへPWAインストール出来ることにユーザが気付きづらい。
- ブラウザ上で動くのでスマホ端末機能が十全には使えない。
勿論上記のようなデメリットもありますが、解決が可能なものばかりです。
HTTPSサイトを用意する必要がある
月額1000円以下でレンタル出来るのでAppleのデベロッパー登録料より安いです。元々Webサイトを持っていればそこに置けば良いです。
個人ユーザの課金に対する心理的不安を解消する必要がある
W3C正式勧告が近い「Payment Request API」を使うことでWeb Payment標準に乗ります。今後Web上での決済はこのAPI画面を使うことが主流になっていくと言われ、「いつも使っている決済画面」になれば不安は和らぐはずです。
スマホへPWAインストール出来ることにユーザが気付きづらい
時折表示される「ホーム画面にインストール」バナーをクリックするか、メニューからインストール出来ますがまだ認知度が低いです。認知度が上がるのを待てなければ、ユーザがWebアプリとして使用中、アプリ側でPWAインストール出来る旨を通知してあげる方法が取れます。
また、ブラウザベンダのPWAインストールに対する補助機能提供も今後厚くなるはずです。
ブラウザ上で動くのでスマホ端末機能が十全には使えない
昨今はブラウザ機能が発達して代替が効くものが多いです。
- SQLite → IndexedDB
- カメラ → getUserMedia()
- センサー → ブラウザ上のセンサーAPI
のように多くのことがブラウザ上で実現可能で、端末のフル性能が必要な3Dバリバリのゲーム、とかでなければネイティブアプリにする必要は必ずしもありません。
ストアはゲームプラットフォームと捉え、ビジネスアプリはPWAでWebと共存へ
アプリをストアに公開すると様々な制約が付いて回ります。
今までの時代はiOSアプリがストア経由以外のインストール経路を作らなかったことに加え、課金方法がストア決済に集中していた為に「なんでもストアアプリ化」風潮が有りました。
PWAのようにOS関係なくインストール出来るようになれば、不特定多数にアプリを公開する為には必ずストア公開しなければならない。といったことがなくなります。
WebPaymentの為のAPIが標準化されていくことによって、ストア課金以外の決済方法もユーザに定着していきます。
「Webで集客したユーザをそのままアプリユーザとしてコンバージョンする」ことが出来ればビジネスの幅も広がります。
PWAアプリさえ出来てしまえば後はWeb集客に注力。
B2Bアプリはストアに公開するよりも、このスタンスの方が未来が明るそうです。
宣伝して貰えるプラットフォームが出来ればもう最高なんですけどね。
