はじめに
昨日の @shinespark さんによるワーキングホリデーのお話 、大変おもしろかったですね 
実際に働くために必要なことがよくまとまっており、海外旅行や語学留学とは明らかにハードルが高いことがよく分かりますね、やはりなんでもやるなら若いうちにということでしょうか。
本日は打って変わってAppStore Connectの審査にまつわるお話を、元ミクシィグループ、現株式会社Diverse所属の @imaizume がお送りいたします。
弊社DiverseのAdvent CalendarにもiOSネタで投稿しておりますので、よければそちらもご覧ください 
さて、今年自分が読んだ本の1つに、 @hirokidaichi さん著「エンジニアリング組織論への招待」があります。
この本の中で最もよく登場するキーワードの1つが「不確実性」で、中では大変分かりやすく「不確実性とはなにか」「どうしたら不確実性を減らせるのか」についての解説がなされています。
世の中にはたくさんの不確実な要素があり、我々を悩ませています。
そんな中、 我々iOSエンジニアを悩ませる不確実性の一つが、アプリ審査におけるAppleに関わる不確実性です 
Appleに関わる不確実性とは、例えばこんなものです。
- いつどんな理由で落とすかが不確実 (これまで見逃されていたHIG違反や表示不具合を突然見つけて審査に落とされることがある)
- どう直せば通るのかが不確実 (審査に落とされたときに具体的な指示をくれないことがある)
- どこまでレビューされるのかが不確実 (Apple側の検証端末やチェックされる画面・箇所が分からない)
-
いつレビューが始まって終わるのかが不確実 (ストア申請から審査開始・完了までの時間が毎回違う)
このようにAppleがもたらす不確実性はいろいろとあります 
審査は人間が、ときに定性的に行うものなので、上記の多くに対してはあまり不確実性を下げるための対策ができないのが現実です。
過去の審査記録で不確実性を下げられるかも 
しかし、審査開始や完了の時刻についてはどうでしょうか
毎回審査のステータスが変わるたびに、みなさんの手元にはAppleからのメールが届くはずです 
この到着をもって審査ステータスが変わったとみなすならば、 時間記録を元に過去の審査にどのくらいの程度の時間がかかったかを定量化・可視化できるはずです。
「最近は審査のスピードが早くなった」とか「朝に審査を始めて平均2時間くらいかかかる」というなんとなくの肌感に頼るのではなく、本当にそうなったかを確かめることは可能です。
審査記録という経験を元にすることで、スプリント計画と同様見積もり精度を上げることはできるのではないでしょうか
以前からそう思っていた自分は、この1年ほどAppStore ConnectからのメールをSpreadsheetに転記することで、審査に関するイベントを定量的に記録しています。
今回は担当するプロダクトの審査ステータス記録スクリプトを紹介し、実際の記録から審査時間に関する考察を書いてみました。
システム設計
審査時間を記録するためのシステム設計方針はこのとおりです。
- AppleからのメールをGmailで受ける(あるいはGmailへ転送する)
- Google Apps ScriptでAppleメールを取得
- 取得したメール内の文章に対する文字列マッチでステータスを確定
- Spreadsheetに受信日時と一緒に記録
なおGASのスクリプトは、私 @imaizume のGitHubにて公開済み 1ですのでよければご活用ください。
このスクリプトでは取得するメールの件数を100件に絞っていますが、より多くの記録が必要なら数を増やしてください。
また2018年6月に旧iTunes Connectが現AppStore Connectに改名 2 した関係上、それ以前の記録を取得するには検索対象文字列を修正する必要があることをご了承ください。
GASをGitHubで管理できるプラグイン を使うと便利にDLいただけます。 3
またGmailを検索してSpreadsheetへ転記する実装の基礎的な部分などはググってみてください、このあたり とかが参考になります。
記録結果
こちらが取得したデータの様子です。
(事情によりバージョンは非表示です。)
個人的にはアプリバージョンごとに提出・審査開始・審査完了の各イベントの対応を取りたいと思っています。
ただ、リジェクトにより複数回同一バージョンで審査にかけた場合の表示などを考えるのがめんどうなので、一旦 イベント:レコード = 1:1 にしています。
今回は特別に、対応を取ったデータを別のシートに作成してグラフ化してみることにしました 
1. 審査提出・開始・通過にかかる時間の推移
まずはこの1年ほどの間に、審査にかかる時間の変化があったかどうかを見てみます。
こちらは提出 
開始にかかる時間(N=38)。
なぜか提出ごとに波打っているのがおもしろいですね。
かなりばらつきがありますが、 平均値が20.8時間だったので、やはり審査開始に1日以上はかかることを想定し余裕を持った提出が大事ということになります。
なぜばらつきがあるのかですが、自分のプロダクトでは基本的に退社前にアーカイブをアップします。
すると、家に着くか寝る前あたりにアップロードが完了していることが多いため、基本的には日本時間の深夜に提出し、早朝に審査が開始されていることが多いです。
すると、運が良ければ6,7時間で翌日にすぐ審査が開始されますが、ときには1日待たされてしまうこともあるため、このような高低差の激しい結果となったようです。
続いてこちらは開始 通過にかかる時間(N=34)。
稀に8時間近くかかることがありますが、 基本的には4時間以内に通過しています、平均値は2.8時間でした、なので審査時間はかなり安定していることが分かりますね 
よって、リリース時のタイムテーブルなどは、4時間程度を目安に組むと安定するのではないでしょうか。
都度必要時間は変わるので、ある程度は運まかせにはなってしまいますが、 多くとも48時間程度を見積もっておけば、通過を前提にした場合に確実にリリースできそうだという感じであることが分かりました。
今回は通過のケースしかグラフ化していないため、リジェクトの場合はまたちょっと違ってくるかもしれません 
2. 提出・審査の開始時刻と開始・通過までにかかる時間の関係
次に、何時に提出・審査開始したら早くレビューが終わるのかを調べるため、時刻とのプロットもしてみました。
上から順に提出時刻と審査開始までの時間、審査開始時刻と審査通過までの時間、そして提出時刻と審査通過までの時間(開始からのトータル)です。
提出時刻は既に述べたように、自分のプロダクトの場合夕方から深夜にかけて集中していますが、昼に提出した場合もさほど通過までの時間に差はなさそうということが分かります。
また審査開始から通過までの時間は、きれいに昼の12時(日本時間)に向かって下がっていることが分かります。
つまり アプリ審査が、日本 
時間12時 
= サンフランシスコ 
時間19時 
に始まることが多いことが分かります。
そして先ほどと同様、提出から通過までのトータル時間は先程と同様、1日またされるかどうかでクラスタができているように見えます。
待たされない場合には、夜でも昼でもトータル時間はあまり変化がないようです。
まとめ
ということで、AppStore ConnectからのメールをSpreadsheetにおこして、審査イベントにかかる時間をグラフ化してみた結果でした。
こうしたデータを取り続けることで、みなさんのプロダクトのリリーススケジュールにおける不確実性が少しでも下がるのではないでしょうか
改善時間などにぜひやってみてください