Functionality」とはアプリをiTunesConnectでAppStoreに申請し審査された時に、以下の様なリジェクションが出て不許可になることがあります。includes.iOSアプリ開発申請に慣れたデベロッパーであれば一瞬で凍りつきます。Functionality」だからです。ここでは過去に3つのアプリでこのリジェクトを受け最終的に審査をパスした経験からこのリジェクションの恐ろしさと問題点を書こうと思います。Functionalityってなに?これはなにか一言で言うと「これはク○アプリですね」ということです。AppStore側の立場から言えば、その様な陳腐なアプリが大量に登録されるということは検索ノイズが増え、全体の品質のブランディングにも影響するので、たしかにこのルールは間違いではありません。開発者はそのアプリに価値があり世の中の人に使ってもらいたいという思いがあるからこそ、AppStoreに申請しています。納得がいくわけがありません。シンプルだからこそ使いやすいのはApple製品の価値そのものでありますし、アプリを使いはじめて数分の人に何がわかるんだという気分になります。それがAppleの答えなのです。恐ろしいのか先が見えない他のリジェクト理由はほぼ100%修正方法が明確になっていて、そのリジェクトに対策する工数が測れます。「アプリ名に余計な文字列が入っている」リジェクトが出たとすれば「アプリ名を改変する工数」として見積もり可能です。「メタデータを変えてね」というリジェクトなら「メタデータを変更する工数」、「テストできないから動画送ってね」というリジェクトなら「動画を作成する工数」として大体把握できます。「アイコンがXXと似ている」でも「XXと似ていないアイコンを作る工数」として把握出来ます。その工数と審査が通る価値を天秤にかけて、意思決定が出来ます。4.2リジェクトに関しては性質が全く異なります。4.2リジェクトは「とにかく駄目、機能を増やすかコンセプトを変えて」というリジェクトです。変えればいいの?変えた結果、ちゃんと審査が通るの?全く保証も情報もありません。ここからコストを1千万かけようが1億かけようが、審査が通る保証は全くないのです。他のリジェクト理由はGuidelineにはっきりと問題がそのルールに適合するかどうかが記載されています。それに対して4.2を決めるのは「レビュー担当の主観」です。悪く言えば「雰囲気で決めている」ということです。道路の横の壁に落書きがあったとしましょう。それをみて「いい絵だ」「だめな絵だ」、感じ方は人それぞれです。100人いたら100人ともが「いい絵だ」と感じることも100人ともが「だめな絵だ」と感じることもありえません。それぞれの感じ方、さらには絵じゃなくて見ている人のその日の体調や気分によっても思いは変化します。「Appleがそんな曖昧な仕組みを設けるわけがない」と思う人もいるでしょう。以下の2点がネット上で多数報告されている事実からこの審査が個人なりグループの主観に頼っているのは間違いないでしょう。一度審査が通ったアプリがUI変更のないバージョンアップで4.2リジェクトされたBundleIDを変えて同じソースコードのビルドを出しなおしたら審査が通った答えを教えてくれない人工知能が発達したとは言え、アプリの価値を評価するのには完璧ではないでしょう。そこを人力の主観に頼るのは致し方ないことです。ここが4.2リジェクトの更に恐ろしいところ。「どうすればいいのかは絶対に教えてくれない」そう、こちらがどんな質問をしようが先程の「とにかく駄目機能追加して」の定型文が機械的に送られて来るだけで、どうすればいいのかは全く教えてもらえない、というか人間の返事も送られてこないのです。質問内容によらず、前回と全く同じ定型文が送られてくる、まるで壊れたロボットとやり取りしている様な気分になります。主張してもジャッジする人がいない「そんなバカな、そんな失礼なことをするならその事を問題にすればいいではないか」と思われるでしょう。その答えは「誰に?」です。後述しますが、レビューは一度担当が決まると、そのバージョンはずっとその担当が行います。いくらメッセージで主張しても、その担当しか見ないのですから、それを咎める人もいません。誰も見ていないところで2人だけでフィギュアスケートで競っているのと同じです。ジャッジする人がいないので勝ち負けもあったものじゃありません。シンプルじゃなくても適用される「じゃあミニマムじゃないように機能増やせば?」となりますが、そうではありません。Functionalityはあくまで章の名前で、その規定はどんなアプリにでも適用されます。Functionality」です。Functionalityを適用することができる」となります。AppStore上には特定のインターネットサイトからの情報しか使っていないアプリの方が多いのですから。ピンポイントで対処しても、何食わぬ顔でリジェクトテンプレートが変わります。その内容は「ネイティブ機能が弱い」などガイドラインのどこにも書いていない独自ルール。)警察官が気に入らない容疑者を逮捕できる公務執行妨害と似ています。なんでもありのワイルドカード。Functionalityなのです。安心してはいけません。UIを変えてない?いいえ、担当が変わりますレビューの仕組みここではAppStore/iTunesConnectのレビューの仕組みを書きます。経験的な想像ですが、正しい部分もあると思います。一度リジェクターにアサインされたら外してもらえない先程も書きましたが、あるバージョンを審査に出したら担当がアサインされます。バージョンアップの場合だからといって前回と同じ担当とは限りません。担当は言語やジャンルなどによって専門があります。日本語オンリーのアプリを申請にだしたら、かなり特定されたレビューエンジニアが担当になるでしょう。開発者からのチェンジはききません。リジェクトされる度に説明を申し送りするのは不効率なので当たり前といえば当たり前なのですが、、、ちなみに審査側の事情で担当が変わる場合はあるようです。急に動画請求の傾向が変わったり、出ていなかったリジェクトが審査過程で新たに出る場合、担当が変わった時に再度イニシャルチェックをしている可能性が高いです。Functionalityが出ます。それはリジェクト地獄の開始の合図です。電話がかかってくるリジェクトを繰り返すとアメリカの担当から電話がかかってきます。日本への電話の場合は日本語を話す担当がかけてきます。これはレビュー運営のルールで決まっているのでしょう。「開発者に電話でしっかりと説明したよ」というフラグ立てです。functionalityのテンプレとほぼ同じ。電話だからといってこちらの質問、「どうすればいいのか」には一切答えてくれません。相手はロボットと思ったほうがいいでしょう。Centerはリジェクターしか見てないリジェクト時のAppleとのコミュニケーション手段は正式ルートで2つ。Submissionにすると送信が出来なくなります。どちらも見てはいるのですが、「見てはいる」レベルで、返信はほぼ来ません。どちらも同じ特定の担当しか見ていないので、どんなにその対応について否定しても、空の星に向かって喧嘩しているのと同じです。アピールボード唯一担当以外にメッセージを送れる手段がアピールボードです。ここに何か送っても「ここはレゾリューションセンターが消えてしまった人向けの窓口だからレゾリューションセンターに書いてね」と返ってきます。(おそらく唯一)担当以外にアピールできる手段ではあります。Center問い合わせに対する返答ノルマはありません。対してアピールボードについては、アピールボード担当者が返答するノルマがあります。Centerに書いてねという返答ですが。Centerの問い合わせは何ヶ月放置しても担当としては問題ないということです。ID」を変えるというものが多数あります。「別のアプリ」として申請するということです。先程も書きましたが、担当はバージョンごとに固定されますが、別アプリとして出すと、再度担当割当が行われ、運が良ければ担当が「リジェクター」から外れるということです。functionalityに対処してパスした方法を記します。ユニークさをひたすら主張これは「地球一シンプルなメッセンジャー」を申請した時にパスした方法です。Functionality。「地球一シンプルなメッセンジャー」という名前のアプリに「シンプルだし駄目」とはなんという問答でしょう。Sale」に変更されました。再申請なしでもそんなこと出来るんだなと驚きました。シンプルでも申請は通ります。「地球一シンプルなメッセンジャー」がパスしたのですから担当が忙しくなるタイミングまで断続機能追加これは自動型動画視聴アプリを申請した時のこと。Functionality。Centerもロボット的対応で全く質問や主張には答えてくれないので、途方にくれていました。いつかは通るだろうと、ちょっとした機能などを加えて、毎日申請しました。どれもすぐにリジェクトされ、文章はすべて同じ定型文。電話で言ってた内容を素直に実装しても同じ。「電話で言ってたじゃん」は通用しません。(担当の苦情を言う相手がいない)本当に見ているのか??最初から気に入らないから何をしても通すつもりないんじゃないだろうかとへこたれましたが、しつこく毎日それを続けました。今考えても、最後に追加した機能はそれまでと比べても比較的意味の薄いものでした。単なるWebリンク追加だったと思います。今思えば、その機能を認められたというよりは、たまたま担当のレビューしなきゃいけないアプリが増えてきて、そろそろいいか的に通されたような感じでした。裏を返せば、サラリーマン的に反対に暇な時は仕事を絶やさないように、そういった行いをしているのかもしれません。勘ぐりすぎかもしれませんが。Functionalityと一緒に別の、例えば「メタデータを変えてね」などが来たらラッキーかもしれません。ここでメタデータを変えて、機能はそのままで通った例が報告されています。上にも書いたBundleIDを変えて担当をリジェクターから外す技、やったことはありませんが、仕組みを考えると納得がいきます。別件の電話中に突然4.2こんなこともありました。ユーザー投稿型のアプリには報告ボタンをつけなければいけないのでつけていたのですが、あるバージョンアップ(UI変更なし)でリジェクト。Fumctionalityではありません)。報告ボタンはワンアクションでないといけないです。そこで「はいわかりました」と言って切ればよかったのですが思わず反論してしまいました。筆者ワンアクションだと、ユーザーが"なぜ報告するのか"がわからないじゃないですか、報告を受けた側も困りますよね?どうればいいんですか?珍しく担当も「スライドをつかえ」など反論してきますが、スライドだけじゃ全てに対処できないと口論気味にちょっと熱くなってしまいました。Functionalityされた瞬間です。Functionality。「アプリ変更してね、どうすればいいかは内緒。コストを1千万かけようが1億かけようが、審査が通る保証は全くないから。今までかけたコスト?知らない」まさに「ミニハラ被害」と呼んでもいいくらいの不条理さです。愚痴っぽくなってしまいましたが、私はAppleが大好きですし、これからも製品や開発を続けていこうとおもっています。Functionalityのガイドライン自体はもちろん必要だと思います。「人による主観評価のゆらぎ」「だめというだけでどうすればいいかを伝えない」ことについては、同じことを感じている開発者の方が多数いらっしゃるかと思います。改善し、開発者とのより良い関係に、ソフトウェア世界の発展に繋げて頂きたいものです。Functionality」とは。