はじめに
こんにちは、2014年フューチャーに新卒入社した李守智です。金融・アパレル・医療等分野で、システム構築系のプロジェクトに上流から下流まで一貫して携わってきました。
アプリ配信の前提となるアプリストア規約の調査とその結果をアプリへ反映する流れについて話します。このお話は、2021年ごろにスマホアプリ（Android、iOS）を一般配信するために行っていた経験を土台にしています。
GoogleとAppleのアプリストア規約
どのアプリストアからアプリを配信するかは決まっていますか？ AndroidアプリはGoogle Play、iOSアプリはApp Storeからの配信が一般的ですよね。配信先ごとに規約を確認する必要があります。
開発が完了したアプリをGoogle Play ConsoleやApp Store Connectに登録したら、同じ規約に基づいてアプリストア側の審査を受けることになります。
Google Playのポリシー
https://play.google.com/intl/ja/about/developer-content-policy/
App Reviewガイドライン
https://developer.apple.com/jp/app-store/review/guidelines/
アプリストア規約は誰がいつ確認するか
アプリストア規約は、デベロッパーが確認するものだけでなく、事業者が確認するものもあります。デベロッパーまたは事業者からアプリストア側へ問い合わせをする必要が出てくるようなものもあります。
プロジェクト開始／計画の段階で顧客とそれぞれの持分を認識合わせし、工数を確保しておくと良いでしょう。開発が完了してからやろうとすると、後述するような変更等から手戻りが発生する恐れがあります。アプリ配信の実績のない事業者の場合、アプリストア規約に違反するサービスを考えている可能性もあります。
また、規約は随時更新されているので、開発中はもちろん、運用保守の中でもウォッチできるようにしましょう。
アプリストア規約はどのように確認するか
当時私たちがやっていた方法を共有すると、規約の本文1文を1行のチェック項目とするチェックリストを作成して管理していました。
対象の規約、規約のバージョン、チェック項目（規約本文）、確認者、確認日、判定、コメント等を書き、チェックリストそのもののバージョン管理も行いました。
このチェックリストで判定OKとならなかったものが、課題チケットやタスクチケット等になっていきました。
アプリストア規約がアプリ開発に影響を及ぼした例
事例（1）アカウント削除機能の追加
App Reviewガイドラインによると、アカウント作成に対応したアプリの場合、ユーザ自身がそのアプリ内でアカウントを削除できるようにする必要があります。
例えばあるアプリはアカウントを作成してログインした状態での利用を前提とするものであるとします。もちろん、このケースではこの規約をクリアする必要があります。ここで問題になるのは、最小限の機能だけ実装したMVPをまずリリースしようとしたときで、アカウント削除機能は優先度的にスコープから漏れがちということです。実際にはファーストリリース時点で必須であるため、アカウント削除機能とその導線追加などをの考慮を、最初からスケジュールに組み込んでおきましょう。
機能定義前にこの対応が行われていたら手戻りは防げます。一方で、仮に開発完了後にこの対応を行おうとすると、機能定義への追加はもちろん、アカウント削除機能への導線から発生する画面遷移の更新、開発・単体テスト、結合テストやシナリオテストなどなど、広範囲の変更が生じることになります。
事例（2）ユーザーデータの使用制限
ユーザーデータを収集するアプリの場合、ユーザーデータの使用をプライバシーポリシーに準拠した目的に制限する必要があります。これは、Google PlayのポリシーでもApp Reviewガイドラインでも謳われています。
この規約は、事例（1）とは違って、直感的にどんな対応をすれば良いか分かりにくいものでした。そこでまず、対応内容を決める前に以下のような思考の段階を経ました。
- システムの中のユーザーデータの出番を洗い出した上で
- その必要性がプライバシーポリシーに準拠しているかの評価をする
「プライバシーポリシーに準拠しているか」も、もう一段と解釈が必要かも知れません。プライバシーポリシーはユーザが承諾するアプリの利用規約の1つにもなるので、ざっくり表現すると「ユーザがその使い方をされると認識し、良いと了承している」ことと言えるかなと思います。
そうした検討結果としてユーザーデータのログ出力はプライバシーポリシーに準拠していないと自ら判断することもあります。例えばあるアプリで操作データを未加工でログ出力したとします。このケースでは、ユーザーデータが思わぬ使い方をされる可能性があります。なぜならログは容易に取得ができ、集計分析等が可能な一方で、その都度プライバシーポリシーに準拠した使い方がされることを、プロダクトのライフサイクルのすべての期間で保証することは難しいと想定できるからです。
そのため、運用保守の問い合わせ対応に必要な、ユーザを特定する情報以外のユーザーデータはマスキングしてログ出力するといった対応が必要です。もちろん、この対応を行うと障害対応などでログを用いた追跡の難易度が上がります。そのため、プロジェクト計画の段階で対応時期等をチームで合意して進められるようにすることが重要です。
その他の事例
詳細は省略しますが、他にも「アプリを使い始めた後でも、ユーザが利用規約への同意を撤回できるようにする」とか、「iPhone向けのアプリがiPadでもうまく動作するか」など、対応検討の必要な規約は複数ありました。
まとめ
どちらかというと、Google Playのポリシーよりも、App Reviewガイドラインからの方が、対応が難しい印象です。
規約の内容によって対応が簡単に決められるものもあれば、課題管理が必要なものもありました。アプリストア規約を基点とせずとも、プロジェクトのスコープに既に入っている対応もありました。いずれにせよ、品質の高いサービスを世の中に配信することにつながれば良いと思います。適時にアプリストア規約の調査を行い、プロジェクト品質に役立てましょう。