前回の日常編に続き、サンフランシスコにあるモバイルゲーム開発スタジオの業務編（2014-18）です。もう退社から2年も経つので、ずいぶん変わったことも多いと思いますがまあ記録として。どんな感じで働いているのかも知ってもらうと業務も伝わりやすくなる気がしますので、こちらで興味を持っていただければ日常編もぜひ。あくまでも僕がいたのはサンフランシスコにあった一スタジオで、それほど外注や他スタジオとのコラボもなかったので、どれくらい一般的なのかはぜんぜん知りませんのでご注意ください。
gameneversleeps.hateblo.jp
業務全般で驚いたこと
僕の職種はゲームデザイナーで、日本でいう企画職にあたります。売り切りのコンソールゲーム開発では納期までに面白いものをなるべく高いクオリティで作ることが正義なスタイルでしたが、ゲームが基本無料の運営型になると、ゲームデザインのゴールは「最高の15時間」ではなく、「遊んでくれる人が年単位で長期間続けてくれる種類の面白さがあって、どこかでお金を払いたくなるきっかけが生まれること」です。長いわ！またサービスインしてからプレイヤーの反応をみてバランス調整やゲームの建て増しも大前提です。要するに目指すところがまったくぜんぜん違うのでゲーム設計の根本から何もかも違うわけです。
僕は日本のセガで入社して、北米セガスタジオ、北米バンダイナムコにいました。どちらも古くてまあまあ大きい会社です。モバイルは最後に少し開発しましたが、基本的に僕がいた部署はコンソール中心でした。なので、Free to Play（F2P）のモバイルゲームだけを開発するスタジオに入るとカルチャーショックの連続でした。むかーし日本からアメリカのゲーム開発に移ってカルチャーショックを受けまくったことがあって、この記事はその精神的続編でもあります。
gameneversleeps.hateblo.jp
金で人を集める
当時このスタジオは出したゲームが当たってお金がドーンと入ってきて、リクルーターがめっちゃ高い給料を餌にトップクラスのモバイルゲーム開発者に声かけまくっていました。あと、自分が紹介したシニアクラスの人が入社すれば基本日本円で100万円相当以上、Hot Jobとか呼ばれるその時々で急募な職種だったら150万円相当のボーナス*1があったので、優秀な人が優秀な人を呼ぶ現象が起きてました。友達のエンジニアとは、入社してボーナスでたら山分けしてやめて良いからうち入ってーって冗談でいってました。たぶん冗談だったと思います。
選良集いすぎ
サンフランシスコでいい給料をだして伸び盛りの業界ということもあり、結果、ゲーム業界内外からすごい人たちが集まっていました。1を聞いて10まで知ればいいのか20まで知ればいいのか即座に理解して、ちょっとした努力でそこに到達してしまうか、あっさり他の人に任せるか決断できちゃうような人たちです。それぞれが、自分だけの成功の方程式をしっかり持っている人たちとでも言いましょうか、ゲーム開発とまったく関係ない方法論をがんがんゲーム開発に当てはめてくるのはとても新鮮でした。びっくりするような失敗もけっこうありましたが、成功の要件が最終的に満たされれば、僕にとっての失敗にみえることも、些細なこともしくはまったく問題ないことって態度が共通してたように思えます。
トップクラスのゲーム開発者と面接官として話が聞けた
そんなすごい人たちを集める過程で、当たり前ですが面接が発生するわけです。そして一応リードゲームデザイナーなので僕も面接官をします。当時ヒットしていたモバイルゲームでは、ゲームデザイナーは一人か二人が普通で、あれオレ詐欺とかが発生する隙もそれほどなく、面接する人する人超ウルトラ濃い話ができてめちゃめちゃ幸せでした。売上トップクラスのモバイルゲームの開発者が来ようものなら、「あれって普通に考えたら○○ってルールにするところをあえて××にしてるのはなんで？」とか、コンソールから転職してきたばかりの僕にはゆるゆるGDCセッションの何倍も勉強になる話が聞けました。あれは本当に良かった。いや、僕に足りない部分を補ってもらうための採用だから会社に必要な話であって個人の興味を満たすためとかでは決してないですよ！（早口）
サンフランシスコにあるモバイルゲーム会社に転職して半年経つけど、今のところ一番良かったのは面接官として週一くらいでTop20内のアプリの開発者たちと直接突っ込んだ制作論を交わせるところだなー。特にエコノミーデザイナの視点は自分にはない部分が多くてすごく楽しい。
— IDA-10（菊地麻比古） (@IDA_10) 2014年12月14日
CEOとの開発会議がしょっちゅうある
いやー、これがアツかった！もちろん負の面も（山のように）ありますよ。でも、人を雇う、IPホルダーを巻き込む必要がある仕様の決定、コスト高めのイベント仕様など、これまでなら数か月単位で時間がかかったであろう決定が、ミーティング中に即決されるのに震えました。だからといって別に気軽に決まるわけじゃなく、毎回プレッシャーは半端なくて、会議のヒリついた空気は今思い出しても胃が痛くなったりします。ですが、「会社のお金を動かしている人はこうやって説得するんだな」という実感を通じて、お金を稼いで人を集めてゲームを作る会社規模のコアループを理解できたのはいい経験でした。
あとさすがに今はもう違うと思いますが、偉い人との会議はたいてい土日に何時間とかかけてやってました。平日はみんな通常のスケジュールあるから割り込みこませたくないってのもわかりますが、あれは良くなかったですね。
ディズニー（Marvel、超有名SF作品）、ハリーポッターなどとの巨大IPホルダーとの仕事
当時のCEOは会社を効率よくスケールするためには、自社IPをあれこれするより、デカい版権の力を借りようという判断でした。当時のF2Pのビルダーに求められるクオリティを満たそうとするとどのみち突っ込む金額が大きくなるので、ヒットする確率を少しでも上げたいという話でもありました。セガやバンナムでもソニックをはじめ名の知れた大きめなIPのゲームを作ってましたが、いやースケールが違った。巨大IPホルダーの話の通じるところ、通じないところを肌で感じられたのと、ヨーダがお出迎えしてくれる有名オフィスで観光ミーティングできたのは良かったです。でもまー正直あの面倒くさいやりとりはもうやりたくな（略）
「フレームワーク」ありきの企画
これは賛否両論あると思いますが、ゲームのシステムを0から考えるのは「車輪の再発明」だとして、その版権を活かせるのが間違いなさそうなベースにできるゲームのフレームワークを見つけるのとセットで初めて開発が始まる感じでした。日本での新規性のあるゲームシステムありきの開発、アメリカに来た当時の世界観先行の開発から、三回目のパラダイムシフト。例えば火垂るの墓とキャンクラ足せば大成功間違いなしみたいな感じですね。嘘です。
キャンクラと火垂るの墓のコラボコラ、自分で作っておいてどこに投稿したか（してないか）まったく覚えてないし探しても出てこないので、ここにポストします。 pic.twitter.com/iOWCZ8qXw6
— IDA-10（菊地麻比古） (@IDA_10) 2019年1月2日
コンソールと小さいモバイルから中～大規模モバイル専門の開発に移って驚いた編
ここから先、もう少し専門的な話になります。まあ小さいとはいえ、F2Pのゲームを0どころか-1くらいから始めてリリースして運営までやったので、まあ、それなりになんとかなるだろと高をくくって入社しました。想像と違ったのは、自分の僅かな経験など、すでに成功したタイトルをリリースし運営してきた彼らにとっては無に等しかったことです。むしろ僕の力が通じたのは、コンソール時代の大規模開発のリードの仕方と、後述する彼らがほとんど気にかけていなかったゲームデザイン手法でした。というわけで、必死にモバイルゲーム開発のノウハウを学びつつ、しっかりとゲームデザインし、それを大規模で開発する手法をチームに還元する生活が始まりました。
100万単位でダウンロード数があるモバイルゲームを開発＆運営してる人がごろごろいる
就職活動中は「F2PのモバイルゲームはとことんAccessibleにしてなるべくたくさんのお客さんを入れることと、Sustainableなシステムを構築して無理なく長くサービスが続けられるのがセットじゃないとだめなんですよ！」と涙ながらに面接で訴えていました。
しかし、そんな僕の主張よりもっと実践的で深い部分まで、彼らの経験を元にかなりの部分がチェックリスト化されていました。石油王が遊んでも無限にお金を使う理由があるか、逆にまったくお金を使わない人がきちんと楽しめるか、何かしらの進捗を得るまでにnクリック以内か、1プレイが1分でも1時間でも成立するか、などなど、今思えば当たりまえすぎることばかりだったと思いますが、2012年くらいにコンソールからモバイルに方向転換してプログラマー2人、ゲームデザイナー僕1人、アート1人で小さいF2Pモバイルゲームを手探り状態で四苦八苦しながら開発していた僕は完全に井の中の蛙というか異世界系のMobでした。「お、お前俺たちが必死で覚えたことよりもずっと高度なことをどうやって！！？？」「ん、普通に一番効率の良い作り方をしているだけだが？」
ゲームデザイナーがいない、仕様書がないことに驚く
そんな感じで学びの連続であったわけですが、彼らが特化していたのは、サービスとしてのゲームを最短距離でリリースして最大の利益を出すやり方でした。具体的には、売れてるゲームで絵がショボいやつを見つけて、綺麗なガワ被せたらもっと売れるでしょ？って理屈で物事が進んでいて、そしてある程度の成功を収めていました。ところが、Supercellの『ヘイ・デイ (Hay Day)』 とか『クラッシュ・オブ・クラン (Clash of Clans)』くらいからゲームデザインの複雑さが増し、物事がそう単純にはいかなくなって、きちんとゲームがデザインできる人を探すようになってました。
僕が入った時はちょうど転換期で、自分の前にはスタジオに1人しかゲームデザイナーという人がいなかったです*2。当然、仕事の概念も仕様書の概念も違っていて、「このゲームのここ（競合ゲームのスクリーンショットに矢印）を参考に実装してください」という書類もまかり通ってました。それが彼らにとって最も効率の良いやり方だったからですが、僕が2001年に入社したセガ・ソニックチームでそれをやったら寒いギャグだと思われて完全に無視されて終わってたと思います。
F2Pのゲーム「しか」知らない人とゲームデザインについて話す難しさ
僕が入った当時は、コンソールゲームはもちろん、買い切りのモバイルゲームですら作ったことがない人がたくさんいました。プロデューサー、プロダクトマネージャー、データアナリスやデータサイエンティストたちに至っては、半数以上がゲームの経験がありませんでした。そこで僕に必要になったのが、どうやって効率よく自分の作りたいものを伝えるかの戦略です。書類化をショートカットするための「あのゲームのあんな感じ」が通じる人がほとんどいなかったんですよ。
企画段階で彼らに説明する際に一番役に立ったのは、客観的な正当性の提示でした。逆に言うと、根拠となるデータを提示しないと話が通じないことが多かったです。これは新鮮でした。参考になるよってゲームを同僚に見せるとまずApp Annieで順位や売り上げの推移を調べたり、自社で試したことがあるフィーチャーだったら、即Tableauを叩いて実装後KPIにどんな変化があったか確認したりとか、Coolさが何よりも大切な価値観だったコンソール時代とまったく違いました。やる意味や価値がデータで裏付けられていないと納得しないわけです。 www.appannie.com
www.tableau.com
また、データの示し方の奥深さも知ることができて良かったです。データサイエンティストとデータアナリストと（勝手に）タッグを組んで、自分の表現したい面白さを肯定するにはどのようなデータをどのように提示しないといけないかをたくさん学びました。
仕様書の段階で「どのデータをみれば面白さが測れるか」が必要
前職では実装前にアイデアの面白さを数値化するという試みをしていました。
game.watch.impress.co.jp
www.4gamer.net
この会社では奇しくも別の意味で面白さを数値化する必要に迫られました。面白さの計測は、滞在時間だったり、課金率だったりいろいろですが、ユーザーが遊んだデータが見えるまでは完成と呼ばないくらいの勢いです。となると、仕様書にどうプレイヤーが楽しんだかを測るかが含まれていないと、きちんとフィーチャーが説明できないということになりますね。これが実装前に書かれていることで、仕様の意図がより明確になりますし、データアナリストチームがデータトラッカーを適切に埋め込むためにも必要なのです。
UI仕様の重要さ半端なかった
前職ではUIも全部自分でやってたので仕様を書くというよりは描くことが多かったのですが、
ここでは、UI/UXデザイナーという専門職がありました。ということは、彼らがUXデザインしたりUIデザインしたりするために、僕が必要な要件を書かないといけないわけです。仕様書は事前に打ち合わせしてどんな情報が必要か確認してから書きますが、だいたい書くより描くことが多くなりますね。モバイル開発だったらスクリーンサイズのなかでビジュアルモックアップもしくはデータテーブルのモックアップをつくるのが一番早い印象。
— IDA-10（菊地麻比古） (@IDA_10) 2014年5月16日
前職を引きずって中途半端にUIのサンプルを作ってめっちゃめちゃ嫌がられたりしましたが、結局落ち着いたのは、ユーザーが達成しないといけないゴール（欲しいものを買う、ユニットを移動する等）と、それをコミュニケートするために必要な要素をリスト化するところまでです。コミュニケートしたい情報を伝えれば、最適なナビゲーションとUIに翻訳してくれる人がいるなんて想像できませんでした。それも全部僕の仕事でしたから。
自然とUI/UXデザイナーともがっつり組むことになるので、それまで謎に包まれていた彼らの仕事が深く知れたのは感動でした。一応それまでも、情報は最小限、必要なものは目につきやすく手で隠れない画面上部に、文字はなるべくアイコンで、とかまあかじった程度の知識はあったつもりでしたが、「情報を伝える」という手段が、文字にする、絵にする、以外に、色、動き、位置、大きさ、順番、枠などの組み合わせで無限の可能性があることを知りましたし、そこから最適な解を見つけられるのが本当にすごい。なにより、操作や情報を整理する際のConsistency（一貫性）に命を懸けるプロ意識が、僕がアクションゲームを開発していた時のボタン毎のアクションの感覚を統一するための努力を思い出させてくれました。
エコノミーデザイナーという職がある
これも自分でやってたんですが、
このスタジオでは専門職がありました。僕が作ったゲームシステムにどんな数字を入れて運用するかのシミュレーションをスプレッドシート上で作って、アイテムの生産（faucet = 蛇口と呼んでました）と消費（sink = 流し）をそれぞれどれくらい開け閉めするかのバランスをとりつつ、課金アイテムがどれくらい進捗を早めるか調整する人です。これは時間を基準に遊びのバランスを詰めていく自分の（古い）レベルデザインの考え方がまあまあ当てはまりましたが、遊びのコアループの他に富豪プレイをする人や、長時間プレイをする人のための無限にリソースを消費できるサブループを作っておく（Infinite Sinkと呼ばれてました）のがF2Pならではだと思いました。ゲームデザイナーとして受けた侮辱で一番ひどかったのはアーティストにEXCELのショートカットを教えたら返ってきた「さすが方眼紙で飯喰ってる人間は違うねー」です。よろしくお願いします。
— IDA-10（菊地麻比古） (@IDA_10) 2013年5月30日
ストーリー作るの無理ゲーすぎない？
プレイヤーを惹きつけるためには、気になる展開にしないといけないわけですが、それと同時に完結することは許されていないわけです。最終的にストーリーのライターはGame of ThronesやWalking Deadなど、Cliff-hangerと呼ばれる先が気になる終わり方を多用しつつ数年にわたって長く続くつつテレビドラマの構造を参考にしました。原作のほうじゃないところがポイントですね。最初に舞台設定と大きな謎を用意して、大きなヤマを越えるたびにちょーっとずつ謎にかかわる部分が明らかになっていくわけです。で、リリース後はイベントがガスガス入ってくるわけですが、プレイヤーごとにどこまで進んでるか違うわけで、イベントの中でキャラクターが知ってるはずの内容が違うのにどう対処するかなどは日本のゲームをかなり参考にしました。
普通に仕様書を書いたら驚かれた
というわけで、最終的に落ち着いた仕様書のフォーマットは、フィーチャー仕様（概要、目的、機能、KPI）＋ 表計算（エコノミーデザイナーがいじる部分のデータストラクチャーを伝えるもの）＋ UI仕様 ＋ アート仕様（必要なアート素材の発注用） に落ち着きました。とにかくスピードが速い会社だったので、自分的には書類はかなり荒かったのですが、仕様書が美しく理にかなっていると社内で晒されたり、全体ミーティングでCEOから大々的に褒められたりしました。「お前、これエンジニアに後から聞かれる内容が全部書いてあるじゃないか！一体どうしたらこんなことができるっていうんだ！？」「ん、普通に仕様を書いただけだが……？」
はじめて同じチームに入った同僚に「おまえの仕様書はほんとうに美しい、まるでジャパニーズテンプルの設計図だ！」ってほめられた。えへへ。
— IDA-10（菊地麻比古） (@IDA_10) 2015年5月12日
終わりは始まりでしかない作り方
いや別にかっこつけてるわけじゃなくてですね、冒頭でも言いましたが、それまでは「プレイヤーが遊んで楽しんで初めてゲームデザインは完結する」だったのが、「プレイヤーがどう楽しんだのかをデータで分析して、さらにそれを運営しながら維持できる、もしくは改善できて、初めてゲームデザインが完結する」ようになったんです。これも長いわ！
gameneversleeps.hateblo.jp
要するに僕がコンソールで知っていた「完成」はスタート地点でしかなくて、そこからプレイヤー数や離脱率、お金を払ってくれる率などを元に柔軟にゲームを変更していく気満々でリリースするわけです。とはいえ、すべてに対してフレキシブルに作るのは不可能なわけで、エンジニアと相談しながら臨機応変に作り方を確定していきました。
エンジニア「ここを希望通りにフレキシブルに作るとけっこうかかるから、とりあえず最短で作ってリリースして、後でイベントとかでも使いたいってなったらリファクタリングしよう。」
有能な僕「OK！（親指を立てながら）」
みたいな会話を良くしました。学んだのは一番大事なのは最短でプレイヤーがどう楽しんでいるかがわかることで、不確定要素に対してむやみにスコープを増やさないように気をつけるようになりました。Tech Debtと呼ばれる技術負債については当然トラックされていて、手が空いたり、そういうタスクが好きなエンジニアが常に取り掛かれるようにしてありました。「時間かけてきれいに作っても売れなきゃしょうがなくない？」っていう技術に理解がない勢（だいたい偉い人たち）からのプレッシャーが強かったですが、エンジニアリードが優秀で、根元の方にある本気でヤバい負債はちゃんとリリース前に直しましたし（偉い人をいい感じに説得しといて～みたいな相談もよく受けました）、その後もイベントの状況をみて影響が出ない負債を積極的に返すようにリソースを管理していました。
MVPを定義するのに1か月かけた
さて、リリースが近づくとこれを決めます。MVPはMinimum Viable Productの略で、たぶんゲームじゃなくてアプリからきた言葉かと。プロジェクトごとに”Viable”（＝実行可能な・リリース可能な）の定義が違うので一般化しづらいですが、コンソール出身の自分でも時間かけすぎじゃん？ってくらい慎重に決めてました。議論のポイントは「どこまで作ればユーザーのテスト結果が有意か」の見極めで、僕が在籍中3タイトルロンチしましたが、だいたい最初の導入部分と、1-2か月相当のコンテンツとそれに使うメカニクスがMVPと定義されたと記憶しています。
最初のセッションの準備に命をかける
僕が直接みてたのはアベンジャーズのF2Pのビルダーゲームとハリーポッターのアドベンチャーでしたが、どちらもNUX（New User Experience）とかFTUE（First Time User Experience）とかFE（First Encounter）とかOn-boarding...もうなんでもいいんですけどそんな感じで呼ばれていた最初のセッションの構築にものすごい時間をかけていました。なんせ、F2Pで一番脱落率が高いのが最初のセッションなんで、細かくステップにわけてどこでユーザーが脱落（＝離脱後n日戻ってこない）するか、その人たちの傾向はどんななのかをものすごく細かくみれるようにしていました。最初からベストが絞り切れていないところはABテスト前提でスクリプトを組んでましたし、膨大な数の質問をリスト化して、ユーザーのデータを待ち受けていたのを覚えています。
意外だなと思ったのは、彼らがどこでユーザーがお金を払ってくれるかはあんまり気にしていなかったところです。どうやら過去の経験から、長く遊んでくれさえすればどこかでお金を払ってくれるという自信があるので、最初のセッションでどんなゲームルールでどんな魅力があるのかをいち早く伝えることにフォーカスするべきという確信があったようでした。関わったゲームはどれもストーリーでドライブするタイプの作りだったので、導入のシナリオはロンチまでに何度も何度も作り直して一番よくプレイヤーを掴めるものに研ぎ澄ましていました。
そんな感じで
リリースに至るわけです。この後も3回にわけて段階的にソフトロンチするとか、コミュニティマネージャーがチームとほぼ対等な力を持つ運営の仕方とか、データアナリストチームが5人体制とか、ゲームのパフォーマンスを分析するミーティングのアツさとか、まあいろいろあるわけですが、長くなりすぎたのと"HADES"ってゲームと今さらですがようやく北米で発売された『十三機兵防衛圏』が面白すぎるのでいったんここで切ります。"Cyberpunk 2077”までの更新を目指します。質問などあればコメントかTwitterでどうぞです！
