はじめに
こんにちは。ゲームの「審査」を担当しているAppReviewチーム所属の＠hito-shiです。
今回、初めてアドベントカレンダーに参加させていただくことになりましたため、審査という業務においてシフトレフトを試みた体験についてお話しできればと思います。
どうぞよろしくお願いいたします。
ところで審査とは？
さきほどから審査、審査と言っているのですが、「審査」と言うとAppleやGoogleへアプリリリースのために申請するアプリ審査のことを思い浮かべる方が多いのではないかと思います。
わたしが担当しているのはこのプラットフォーマーによるアプリ審査のことではなく、社内でリリース前の企画内容が出来上がったときに社内レギュレーションや法令（景表法など）に適合しているかチェックすることで、これをわたしの会社では「審査」という風に呼んでいます。
業界的にはニッチな役割ではありますが、そのままではリリースできない内容や危ない企画があれば「このままでは出せないよ」と炎上する前にストップをかけたり、安全に進めるよう迂回路や別案を提示したりして、リスクを未然に防止する役割を担っています。
本記事のテーマ
審査担当によるチェックはある程度決まっているものがないとチェックができないため、企画内容が固まった工程に入ってから行われることが多いです。
しかし、今回の新タイトル開発では従来の「出来上がってからチェックする」やり方にこだわらず、「開発チームの企画会議に審査担当が突撃して参加をしていく」といういわゆるシフトレフトを試してみました。
結論から言うと、1日のMTG数が増加して体力的にはしんどいものがありました。
ですがそれ以上に
- 手戻りの削減
- スケジュールの透明化
- 開発チームとの距離も近づき関係性が構築できた
と多くのメリットが得られました。また、審査担当のわたしだけではなく、ゲーム開発のチーム側からも仕様検討の初期段階から参画してくれてFBをもらえたことで非常に助かった。と感謝の声をいただくという予想以上の効果もありました。
この記事では、そんな審査担当であるわたしがどのように開発プロセスに食い込み、どんなリアルな課題を解決していったのか。その実体験と、そこから見えたメリット・デメリットを共有します。
1. 前提：新規開発のスピードに既存フローが追いつけなかった理由
従来のフローの限界
通常、審査対応というのは以下のような「ウォーターフォール型」で進行しています。
- 企画担当がチーム内で企画をFIXさせる
- 審査担当者に確認依頼を投げる
- 審査担当がNG/OKを出す
- NGであった場合、指摘箇所の修正やリスク判断を行って対応
■フローの一例
安定運用に入っているタイトルで十分な確認期間を設けて依頼・確認がされているならこれでも回ります。しかし、タイトなスケジュールでリリースを目指すタイトルにおいてはこれがリリース直前で大きなネックになる可能性もあります。
開発が進んでから大きな懸念が生じてしまった場合に方向性の転換や手直しをしなければならないということになりかねないためです。
今回のプロジェクトでも、開発初期はスケジュール調整が難航しており、このままではリリースに間に合わないかもしれないという危機感がありました。
2. やってみたこと：審査担当も「開発チーム」に近づく
そこで今回は、以下の2つのアクションを実施しました。
① 企画会議への参加
プランナーがチーム内で企画を検討する会議に、審査担当者も直接参加しました。
依頼が来るのを待つのではなく、「ホワイトボードの前で議論している段階」から話を聞くスタイルです。
② QA・LQA・開発チームとの週次定例
QA・LQAチームや開発責任者も同席する定例MTGに審査担当も参加しました。
ここで審査の進捗や予定を報告し、「いつ頃何の仕様がFIXし、いつ検証が必要か」をリリース日から逆算して毎週細かくすり合わせを行いました。
責任者が同席することでその場で意思決定が行われるため、タイトなスケジュールを乗り切れる調整が可能になりました。
③ 待つのではなく、自分たちで「仕様」を取りまとめる
開発スケジュールがタイトであると同時に、開発チーム側のリソースもカツカツでした。
仕様の変更や調整が日々行われる中で、完璧にFIXした仕様書が出てくるのを待っているだけでは審査側のキャッチアップが全く追いつきません。
そこで、仕様書が出来上がるのをただ待つという姿勢はやめて以下のことを行いました。
3. 【メリット】リスクの早期検知と仕様・スケジュールの解像度向上
会議への参加などのアクションによって具体的にどのような効果があったのか。実際の事例（フェイクを入れていますが実話ベースです）を紹介します。
事例①：販売予定商品へのフィードバック
ある日の企画会議で、今後ゲーム内ショップで販売される商品設計について議論されていました。
「〇〇をセットにした商品を売りたい。セールはこれくらいの間隔でやりたい。Webショップの設計はこうしたい・・etc」
従来であれば、仕様書が完成してから審査担当の元に来て、「景表法や社内ルール的にどうなの？」と調査・回答し、プランナーとのやり取りも発生して時間がかかっていたでしょう。
しかし、その場にいた私はすぐに口を挟むことができ、実施できること・できないことや表示上で注意が必要な点などのFBが迅速に可能になりました。
事例②：サブスク特典の設計
サブスクリプション（月額課金）機能の導入会議でも同様です。
「サブスク加入特典として、ゲーム内通貨や特典をいろいろと付けたいんですけど、この設計で大丈夫か？」
サブスクは特典設計も複雑で後から大きな手戻りが生じてしまうと痛い部分です。
特典として何が提供可能かについてその場でルールを提示し、安全なラインで企画を進めることができました。
最大のメリット：「行間」が読めるようになる
審査担当としてのメリットは仕様やスケジュールの解像度が上がったことです。
「この案件はチーム内では方向性が決まっているみたいだけど上長の承認待ちのステータスだから、来週まで動かないな」
「この機能はチーム内で意見を募集して改善を予定しているみたいだから、仕様FIXはまだ先だな」
会議に出ていると、こういったドキュメントには書かれない「空気感」がつかめます。
結果、「まだ確定しなさそうだから、今のうちに別の案件を処理しよう」といった、審査側のリソース配分の最適化やスケジュールを先回りして調整することが可能になりました。
4. 【デメリット】正直、コストはめちゃめちゃ高かった
良いことづくめに見えますが代償もありました。オーバーヘッドの増大です。
1日の大半を占める会議時間
情報をキャッチアップするために多数の会議へ参加しましたが、1つ1つの議論が長引くことや、夜間帯のMTG参加が必要になることも多々ありました。
自分のそのほかにやらなければいけない実作業や資料作成は、会議が終わった夕方以降や夜間に行うこともしばしばありました。体力勝負です。
情報の取捨選択の難しさ
全ての会議が審査に必要な情報だけを議論するものだったわけではありません。 今日の会議は自分の担当領域外の話題だな……という時間を過ごすこともありました。
情報のハブになることと、自分の作業時間を守ることのバランスは今後の課題です。
5. 結果：無事にリリースを迎える
様々な取り組みを経て無事にアプリはリリースされました。
この取り組みの結果、開発チームの方からは以下のような言葉をいただきました。
「仕様検討段階から会議に参加していただき、直接その場で質問ができたりFBがもらえ、リスクのある個所を修正できたため助かった。タイトなスケジュールの中、大きなリスクなくリリースが達成できた」
単なる「チェック担当」という枠を超え、同じゴールを目指す「ワンチーム」に近づけたことが何よりの収穫でした。
開発のスピード感と、審査の正確性。この両立を実現したプロセス改善が評価され、結果としてWin-Winな関係構築ができたと思っています。
6. まとめ
今回の経験から得られた教訓は以下の通りです。
1.「シフトレフト」は審査でも有効
- 効率を重視し仕様がFIXしてから確認することが多い審査業務ですが、上流工程に入り込むことで全体の手戻りを最小化できる
2.対面コミュニケーションは生きた仕様書
- 変わり続ける仕様をドキュメントだけで追うのは難しい場合がありますが、会議に出て「生の声」を聞き、解像度をあげることは有用
3.審査担当は「敵」じゃない
- 早期に相談してもらえれば、私たちは「NGを出す人」ではなく「安全な進め方を教えるガイド」になれる。
おわりに
正直なところ「体力勝負・工数度外視」という力技で解決した側面もあり、効率化という課題は残っていますが、それ以上にメリットが大きかったと考えているので実施してよかったと思っています。
今回の経験を通じて、立場が異なるメンバーを早期に味方に引き込み、一体となって進めていくことの重要性を肌で感じることができました。
また、今回わたしたちが開発チームの輪に入っていけたのは、開発チーム側がわたしたちを受け入れてくれる土壌を整えてくれていたというのも非常に大きいです。
実際にこの取り組みを始める前にも、これから密に連携をしていくのだからと、開発チーム側からチームビルディングの場を設けていただき、心理的な壁を取り払ってくれていました。
今回ご紹介した「審査担当 と 開発チーム」という関係性以外にも、部署をまたがった協力が不可欠な取り組みは多くあると思いますため、こういった試行錯誤が、みなさまのプロジェクトの参考になりましたら幸いです。
それではみなさま、良い年末をお過ごしください。