とある上場企業のモバイルゲーム開発の流れ

自分の仕事を人に話す練習として、また経験を一つ書き起こそうと思います。
話を聞かせる相手として想定するのは、全く畑の違う業界の人、生産業の方、何らかの教授をイメージして
なるべく好奇心を掻き立てる、興味を抱いてもらえるようなタネを埋め込むよう努力して見ます。

ということで、モバイル/スマホゲーム開発の流れについて
30分くらいで書けるだけ書いてみます。

ゲーム開発の流れ

• 前提として、受託開発ではなく、自社製品の開発です。
• 会社の体制としては、ゲーム開発プロジェクトはプロジェクト単位で所属するメンバーを束ね(project oriented)、
  広告、ミドルウェア管理は横断部署として存在、
  デザイナーは所属部署がありつつ、実質プロジェクトに所属し、ほぼつきっきりという状態。

項目	誰が	具体的に何をするのか	面白ポイント
プロジェクト発足	ゲーム開発部署の管理部門	- 事業面の理由からプロジェクト発足を決定。 - プロジェクトのリーダーを決定。
プロジェクト企画体制構築	プロジェクトリーダーを中心に	- 管理部門から受けた基礎要件をもとに、必要なゲームプランナーやエンジニア(リーダー), デザイナーを集める。 - 以後の開発や承認フロー、ステークホルダーを事前に定める。	- 新規立ち上げ時ほど重要な場面なので、招聘がかかるのは比較的有能なメンバー。社内的にも花形なので羨ましがられる。(特に昨今、ゲームの長寿化が進んでいるので、初期開発よりも運用に携わるメンバーの総数が圧倒的に多い)
企画開始	メンバー全員	- 競合/市場調査や未来の予測を踏まえ、儲かる x 新たなポジション のゲームを考える(目星や話の道筋を立てやすくするための制約の検討)。 - 簡単なペライチの企画書に始まり、ペーパーモックなどで検討を重ねる。	-めっちゃ時間かけてしまいがちだし、時間がかかる気持ちもわかる。 -モック時点で面白くするのむずいけど、思えばこの時点で面白く無いと、結局面白い仕組みができてないということだと思う。 - システムとして動く形にすぐにできると、イメージが膨らみやすく話を展開しやすい。でも壊すことを躊躇う気持ちが生まれかねないので、そこは容赦無くスクラップ&ビルドする。 - ミーティングで却下、もしくは議題に挙げてないゲーム仕様を勝手に盛り込むデザイナーさんとか現れるので、機会と規律は保つ。
経過報告&承認	ゲーム開発部署の管理部門 プロジェクト	- 決められた開発段階を卒業し、次のステップに進むにあたり承認を受けるための会議を設ける。 - 何ステップに分けて用意する。	- 事前の期待値調整は大事。 - 偽りないポジティブなメッセージをもって管理部門をも仲間に引き込めると強い。 - 蜜月になって監査性能を潰すのはダメですが。
本開発	プロジェクト	- お客さんに楽しんでもらう製品を作る。	- 過去の開発資産を使えるとやっぱり早い(けど、車輪の再発明しがち)。 - メインの遊びの部分を早く遊べる状態にし、何度も遊んでは仕様や演出の修正を重ねる。
品質担保テスト	プロジェクト	- 品質管理チームとともに協力して、不具合を無くし、仕様を定めきる。	- ゲームの品質管理だけを仕事にした会社もあるって、知らない人多そう。 - とあるIPの超人的な知識があったためにほぼ正社員的なポジションを手に入れた人もいたり。 - それくらいIPものの設定に関する知識は、デザインや素材監修の面で心強い(あのXXの顔の傷は、右頬じゃなくて左頬みたいな)。
社外βテスト	プロジェクト&有志のユーザ	- 完成したゲームを一般公開して遊んでもらう。 - このときに合わせて行うユーザの属性に関する調査データは、以降の広告戦略や事業データ分析上で超重要。	- ゲームの面白さ自体を評価する声が大きく無い限り、結局すぐに飽きられるので要確認。
リリース	プロジェクト	- 一般ユーザに、β版から調整を加えた製品バージョンのゲームを公開する。	- どきどきするし、ユーザの声は嬉しいもの。 - GooglePlayやAppStoreの新着フィーチャーアプリとして取り上げられると数十万ダウンロードを期待できるものの、そうで無い場合、流入確保に多大な苦労と費用。
運用	プロジェクト	- 事業データを監視しつつ、事業計画に基づき、ゲームを進化させていく。 - キャラクターの能力の上限を解放していくことでリソース価値を保ち続けるのが一つの手だが、陳腐化が前提となっており、自らの首をしめることや新規ユーザにとっての敷居をあげることにもなる。 - Cygamesとかは、面白く無い古典的なゲームをよくも広告でそれだけ売り続けるなという印象。褒めてます。	- 運用中に、資金管理に関連する法律や制度等に変更が加わり対応を迫られることがある。 - いわゆる高額課金ユーザみたいな方もいらっしゃってありがたい話ではあったのですが、プロジェクト参画者も含め金銭感覚がずれていて、自分には居心地がよくなかったです。どうせの出費なら、家族とか恋人を喜ばすための出費に携わりたい、と。 サービス開発の一連の流れをありがたいことに十分経験させてもらえたので感謝していますが。
閉鎖	プロジェクト	- 事業計画通りにことが運ばず、社内や市場環境の変化も後押ししたりで、生き残れるアプリはほんの一部です。 - ユーザにごめんなさいとありがとうをしながら、迷惑を最小限にする配慮をしながら店じまい。 - 利用規約に閉鎖時を想定した文言を含めておかないと、いざというときに結構怖いことに。	- みんなお葬式ムードな時こそ、積極的に遺留品回収をして、組織の資産として今後に役立てるのが大事。

こんな具合です。
本開発あたりで、制限時間: 30分がせまり適当になってますが、ご愛嬌で。
多分、時間あるときにちゃんと加筆修正します。
表形式、超見にくいので、普通に章立てて目次でも置きます。
感想等ありましたら、伺えると嬉しいです。ではでは。