あんさんぶるスターズ！の運用について

Slide 1

Slide 1 text

あんさんぶるスターズ！の運⽤について関⻄ゲーム勉強会2016WINTER ©Happy Elements K.K

Slide 2

Slide 2 text

⾃⼰紹介 • 草苅景（くさかりけい） • @kusakari • Happy Elements株式会社カカリアスタジオ所属 • チーフエンジニア • 「あんさんぶるスターズ！」グループリーダー ©Happy Elements K.K 1

Slide 3

Slide 3 text

あんさんぶるスターズ！とは ©Happy Elements K.K 2

Slide 4

Slide 4 text

あんさんぶるスターズ！とは ©Happy Elements K.K 3 項⽬内容ゲーム内容スマートフォン向け「アイドル育成プロデュースゲーム」リリース⽇ Google Play版2015年4⽉28⽇ App Store版 2015年5⽉1⽇略称あんスタ！

Slide 5

Slide 5 text

アイドル育成プロデュースゲーム ©Happy Elements K.K 4

Slide 6

Slide 6 text

あらすじ舞台は男性アイドルを育成する「私⽴夢ノ咲学院」。夢ノ咲学院に転⼊してきたたった⼀⼈の⼥⼦⽣徒（プレイヤー）が、プロデュース科の第１号として選ばれ、個性豊かな30⼈以上の男性アイドル（全10ユニット）たちをプロデュースすることに…。 ©Happy Elements K.K 5

Slide 7

Slide 7 text

実績 • 200万ダウンロード（2016年9⽉） • Google Play 2015年ベストゲーム • 「夢王国と眠れる100⼈の王⼦様」と同時選出 • ⼥性向けゲームでは初 • 2016年9⽉15⽇ App Store トップセールス1位 • ⼥性向けスマホゲームではトップクラス ©Happy Elements K.K 6 INSIDEより引⽤

Slide 8

Slide 8 text

運⽤サイクル • ⼆週間ごとにイベントとガチャを実施 • ⽉に⼆回ずつ • イベントを中⼼とした運⽤サイクル • 本⽇はこの⼆週間における「ίϯςϯπاըϑϩʔͱ ͩ͜ΘΓϙΠϯτ」、「ӡ༻ɾ։ൃϑϩʔ」という⼆軸でご紹介 ©Happy Elements K.K 7

Slide 9

Slide 9 text

ゲーム制作の「ポイント（=こだわり）」コンテンツ編 ©Happy Elements K.K 8

Slide 10

Slide 10 text

⾃⼰紹介 ©Happy Elements K.K 9

Slide 11

Slide 11 text

①⾃⼰紹介 • 堤万弥（つつみまや） • Happy Elements株式会社カカリアスタジオ所属 • 「あんさんぶるスターズ！」コンテンツディレクター ©Happy Elements K.K 10

Slide 12

Slide 12 text

②⾃⼰紹介 • ೥ʹΞϧόΠτͰ)BQQZ&MFNFOUTגࣜձࣾʹΠϥετ Ϩʔλʔͱͯ͠ۈ຿ • カードイラストを２〜３タイトル経験 • →ファンタジー神話カードゲームの終盤イベントでシナリオを担当 ©Happy Elements K.K 11 • ೥ΑΓʮ͋Μ͞ΜͿΔελʔζʂʯͷίϯςϯπσΟ ϨΫλʔͱͯ͠ۈ຿ • 開発開始後「あんさんぶるガールズ！」を後任に引き継ぎ、現在は「あんさんぶるスターズ！」のコンテンツディレクターを担当 • ೥ʹʮ͋Μ͞ΜͿΔΨʔϧζʂʯͷίϯςϯπϓϥϯ φʔͱͯ͠ۈ຿ • 新規タイトルの⽴ち上げでイラストレーターとして参加 • →キャラクターや世界観設定、イベント企画を担当したことがきっかけで、そのままプランナー(コンテンツディレクション)業務がメインになる

Slide 13

Slide 13 text

③業務内容 • ओʹήʔϜ಺Πϕϯτͷاը • イベントのテーマ、⾐装デザインやカードのイラスト監修、シナリオの発注など • Ϣχοτ$%΍෣୆ɺάοζɺࡶࢽͳͲͷ؂म • ユニットCDのコンセプト、舞台脚本、グッズのデザイン、雑誌の記事などを監修 ©Happy Elements K.K 12

Slide 14

Slide 14 text

運⽤における「ポイント（=こだわり）」をゲームの最⼤の強みである「コンテンツ」の制作サイドから紹介します ©Happy Elements K.K 13

Slide 15

Slide 15 text

本⽇は「イベント企画」の流れからそれぞれの「ポイント=（こだわり）」を順に紹介します ©Happy Elements K.K 14

Slide 16

Slide 16 text

「イベント企画」におけるそれぞれの「ポイント=（こだわり）」 • イベントのメンバーを決める • テーマを決める • ⾐装とステージデザインを決める • ストーリーの展開（あらすじ）を考える • シナリオとBGMを発注する • シチュエーションに合わせてイラストを制作する • まとめ ©Happy Elements K.K 15

Slide 17

Slide 17 text

「イベント企画」におけるそれぞれの「ポイント=（こだわり）」 • イベントのメンバーを決める • テーマを決める • ⾐装とステージデザインを決める • ストーリーの展開（あらすじ）を考える • シナリオとBGMを発注する • シチュエーションに合わせてイラストを制作する • まとめ ©Happy Elements K.K 16

Slide 18

Slide 18 text

イベントのメンバーを決めていきます ©Happy Elements K.K 17

Slide 19

Slide 19 text

「あんスタ」にはアイドル育成校に通う36⼈のアイドルがいる。キャラクターの登場頻度やストーリー展開の予定で決めていく。イベントのメンバーを ©Happy Elements K.K 18

Slide 20

Slide 20 text

「イベント企画」におけるそれぞれの「ポイント=（こだわり）」 • イベントのメンバーを決める • テーマを決める • ⾐装とステージデザインを決める • ストーリーの展開（あらすじ）を考える • シナリオとBGMを発注する • シチュエーションに合わせてイラストを制作する • まとめ ©Happy Elements K.K 19

Slide 21

Slide 21 text

テーマを決めていきます ©Happy Elements K.K 20

Slide 22

Slide 22 text

テーマを決める１／４イベントに登場するメンバーを決めたら、⾒せたいところを考えながらʰςʔϚʱを決める。今回は8⽉に実施したイベントを元に、2組のアイドルユニットの⾒せ⽅を紹介。 ˣࠨ͕݄ʹ࣮ࢪͨ͠ʰḐ೤ˑւลͷϏʔνϚονʱ ӈ͕݄ʹ࣮ࢪ͍ͨͭ͠΋ͷํ޲ੑͷΠϥετˣ ʢແ๷උɺͪΐͬͱΦϑͷ࢟Λ૝૾ͤ͞Δʣ ʢΨʔυ͕ݎ͍ɺઓୂ΋ͷ͕શ໘ʹग़͍ͯΔʣ ©Happy Elements K.K 21 『流星隊（りゅうせいたい）』は戦隊ものをモチーフにしているため肌を出さないスーツ系⾐装が多い。夏の露出できる季節のため、これまでほぼ未登場であるカジュアルな⾐装を着せることにした。さらに、アイドルではあるものの、たまにはステージ以外の仕事姿も描きたい。以上から『海の家』をテーマにした。

Slide 23

Slide 23 text

テーマを決める２／４ ©Happy Elements K.K 22 『2wink』（トゥウィンク）はテクノポップをモチーフにしているためかわいい⾒せ⽅が多い。「男らしさ」をアピールし、かわいい男の⼦にあまり興味がない層にアプローチした。海でできる格好良いシチュエーションとして『ビーチフラッグ』をキーとしてイラストを制作。（画像はこれまでの『2wink』のリーダー葵ひなた）

Slide 24

Slide 24 text

テーマを決める３／４ ©Happy Elements K.K 23 これが「男らしさ」を強調し制作したイラスト。普段の「かわいい」印象から『ギャップ』があるイラストが完成した。

Slide 25

Slide 25 text

テーマを決める４／４イベント開始の3⽇前に⾏っている予告では反響が⼤きく、想定していた反応が得られてよかった。（公式Twitterアカウントのリプライ欄） ©Happy Elements K.K 24

Slide 26

Slide 26 text

テーマを決める上での「ポイント」 ©Happy Elements K.K 25

Slide 27

Slide 27 text

テーマを決める上での「ポイント」 • قઅʹ߹ΘͤͨϞνʔϑͱʮ৭ʯΛܾΊΔ • 設定しているアイドルユニットのイメージカラーは残して⾐装デザインを⾏っている(10組あるため混ざらないように配慮) • 開催する前後のイベントの⾊も意識し、似た印象にしない⼯夫をしている ©Happy Elements K.K 26 7⽉イベント『⻘』 8⽉イベント『⽔⾊』 9⽉イベント『緑』

Slide 28

Slide 28 text

「イベント企画」におけるそれぞれの「ポイント=（こだわり）」 • イベントのメンバーを決める • テーマを決める • ⾐装とステージデザインを決める • ストーリーの展開（あらすじ）を考える • シナリオとBGMを発注する • シチュエーションに合わせてイラストを制作する • まとめ ©Happy Elements K.K 27

Slide 29

Slide 29 text

⾐装とステージデザインを決めていきます ©Happy Elements K.K 28

Slide 30

Slide 30 text

⾐装とステージデザインを決める ©Happy Elements K.K 29 イラストが「あんさんぶるスターズ！」における最⼤の売りのひとつ。イラスト=キャラクターをより魅⼒的に演出するのが「⾐装」と「背景」である。

Slide 31

Slide 31 text

⾐装とステージデザインの「ポイント」 ©Happy Elements K.K 30

Slide 32

Slide 32 text

⾐装とステージデザインの「ポイント」 ©Happy Elements K.K 31 • 決めた「テーマ」からぶれずにイラストに落とし込む。 • ⾐装とステージのデザインも「テーマ」を反映し統⼀感を出す。 • カードのレアリティによる差は⾐装デザインにも反映させ、⾼レアリティの価値が伝わるように配慮。⾐装は『海の家』の従業員海パンとユニットのテーマカラーでデザインしたシャツ背景は『海の家』ほぼ⾒えないが⾐装と店の名前も揃えている

Slide 33

Slide 33 text

「イベント企画」におけるそれぞれの「ポイント=（こだわり）」 • イベントのメンバーを決める • テーマを決める • ⾐装とステージデザインを決める • ストーリーの展開（あらすじ）を考える • シナリオとBGMを発注する • シチュエーションに合わせてイラストを制作する • まとめ ©Happy Elements K.K 32

Slide 34

Slide 34 text

ストーリーの展開（あらすじ）を考えていきます ©Happy Elements K.K 33

Slide 35

Slide 35 text

ストーリーの展開（あらすじ）を考える • ライターにシナリオを発注するために、登場キャラクターとテーマに合わせて簡単なあらすじを作成する。 • 話のとっかかりになる程度の⽂章量を作成。 (丸投げでは書きにくい) ©Happy Elements K.K 34

Slide 36

Slide 36 text

「イベント企画」におけるそれぞれの「ポイント=（こだわり）」 • イベントのメンバーを決める • テーマを決める • ⾐装とステージデザインを決める • ストーリーの展開（あらすじ）を考える • シナリオとBGMを発注する • シチュエーションに合わせてイラストを制作する • まとめ ©Happy Elements K.K 35

Slide 37

Slide 37 text

シナリオとBGMを発注していきます ©Happy Elements K.K 36

Slide 38

Slide 38 text

シナリオとBGMを発注 ©Happy Elements K.K 37 • あらすじとイメージを明確に伝えるため、参考画像もまとめて共有。 • イメージを共有することで、こちらが意図している⽅向性への理解度が増す。シナリオにもイラストとリンクした描写を描いてもらえる。（臨場感や没⼊感が増し、ユーザーがよりのめり込みやすくなる） • BGMもイベント毎に⽤意することで、シンプルな仕様のゲームにも変化を付けることができる。

Slide 39

Slide 39 text

「イベント企画」におけるそれぞれの「ポイント=（こだわり）」 • イベントのメンバーを決める • テーマを決める • ⾐装とステージデザインを決める • ストーリーの展開（あらすじ）を考える • シナリオとBGMを発注する • シチュエーションに合わせてイラストを制作する • まとめ ©Happy Elements K.K 38

Slide 40

Slide 40 text

シチュエーションに合わせてイラストを制作していきます ©Happy Elements K.K 39

Slide 41

Slide 41 text

シチュエーションに合わせてイラストを制作する • ⽉⼆回のイベントサイクルで制作スパンが短いため、シナリオの納品前にストーリーのおおまかな流れが書かれたプロットや、イラストを制作しやすそうなシチュエーションを先に送っていただき制作。 • シナリオの納品後に、シナリオからイラスト映えするシーンを抜粋して制作することもある。（ライターとイラストレーターだと⾒ているところが異なるため） • シチュエーションを先にもらっていても、納品されたシナリオで展開が変わって該当のシーンが異なっていることもあるため、こまめに連絡を取ってお互いに対応。 ©Happy Elements K.K 40 （Slackで連携している）

Slide 42

Slide 42 text

イラスト制作での「ポイント」 ©Happy Elements K.K 41

Slide 43

Slide 43 text

イラスト制作での「ポイント」 • キャラクターらしい表情、仕草にこだわりつつ、レアリティに合わせて構図のダイナミックさを描き分ける。 • キャラクターの性格や⼈となりがある程度ユーザーさんに浸透しているため、最近は普段とは違った表情やシチュエーションで変化を付けている。（いわゆるギャップ） ©Happy Elements K.K 42

Slide 44

Slide 44 text

「イベント企画」におけるそれぞれの「ポイント=（こだわり）」 • イベントのメンバーを決める • テーマを決める • ⾐装とステージデザインを決める • ストーリーの展開（あらすじ）を考える • シナリオとBGMを発注する • シチュエーションに合わせてイラストを制作する • まとめ ©Happy Elements K.K 43

Slide 45

Slide 45 text

まとめ ©Happy Elements K.K 44

Slide 46

Slide 46 text

まとめ • ゲーム制作の上では、ʮϙΠϯτʢͩ͜ΘΓʣʯをしっかり持って運営して⾏くことが⼀番⼤事である。 • ʮϙΠϯτʢͩ͜ΘΓʣʯが伝わるように⼼がければ、ユーザーさんはきちんと理解しゲームとしての魅⼒と受け取ってくれる。 • さらに、 ʮϙΠϯτʢͩ͜ΘΓʣʯが他社のゲームと差別化を図れることにつながるのではないかと思う。ただし、 ʮϙΠϯτʢͩ͜ΘΓʣʯが過ぎると運営に⽀障が出る（締め切りまでに終わらずリリースギリギリになる）ため、効率も考えていいバランスを取ることが不可⽋。 ©Happy Elements K.K 45

Slide 47

Slide 47 text

質疑応答 • 時間も⾒させて頂きつつ… ©Happy Elements K.K 46

Slide 48

Slide 48 text

運⽤・開発フロー編 ※ここから開発者向けの内容になります ©Happy Elements K.K 47

Slide 49

Slide 49 text

使⽤しているサービス • Slack（チャット） • Skype→HipChat→Slack • 興味のあるチャンネルは、他アプリのチャンネルでも閲覧可能 • GitHub（ソースコード管理） • ⾃社でホスティングせず、可能な限り管理コストを省く • GitHub Issues（タスク管理） • Asana→backlog→GitHub Issues • タスク管理はいろいろ試したものの、完全に満⾜できるものはない • 業務にツールを合わせるのではなく、ツールに業務を合わせていく⽅が柔軟 • GitHubとの連携は⾮常に⼤きなポイント ©Happy Elements K.K 48

Slide 50

Slide 50 text

• https://speakerdeck.com/shibayu36/hatenaburogutimufalsekai-fa- hurotogithub • こちらの内容を参考にさせて頂き、運⽤・開発フローを整備 ©Happy Elements K.K 49

Slide 51

Slide 51 text

⼤事にしていること安定した運⽤できるだけ不具合を減らす⼤きな機能を着実に進めていく ©Happy Elements K.K 50 そのためには… 進捗・責任の可視化、ルールの明⽂化などが重要本⽇は、その取り組みの⼀部をご紹介

Slide 52

Slide 52 text

開発チーム構成 • ։ൃϦʔμʔʷ • 社員エンジニア×3 • 学⽣アルバイトエンジニア×2 • プランナー×1 • デザイナー×1 ※チーム全体は約30名 ※サポートチームは別チーム ©Happy Elements K.K 51

Slide 53

Slide 53 text

開発リーダーの役割 • 開発フローの明確化 • 可能なら明⽂化も • 開発に関する判断を実施 • 判断には実装⼒必須 • 例えば、タスク・レビュアー割り当て • 開発全般における責任を開発リーダーがもつ • そのため、最悪⾃分で対応できる⼈が望ましい ©Happy Elements K.K 52

Slide 54

Slide 54 text

イベント周期に合わせた運⽤ • ⼆週間に⼀度、⽉⼆回のイベント • 運⽤フローはイベントサイクル合わせ • 基本的に⼆週間で1マイルストーン • クライアントアップデート • 基本的にイベントに合わせて、⼆週間に⼀度のアップデート • サーバーアップデート • イベントサイクルに加えて、⼀週間に⼀度アップデート • 定期導⼊⽇を決めて細かな対応をまとめて導⼊ • 例えば、誤字脱字、軽微なイラストの修正、管理画⾯修正など ©Happy Elements K.K 53

Slide 55

Slide 55 text

3つのGitHubリポジトリー • hekk/boys • サーバープログラム⽤のリポジトリー • hekk/boys_client • クライアントプログラム⽤のリポジトリー • hekk/boys_issues • 上記2リポジトリーではIssuesを使⽤せず、こちらだけを利⽤ • 実運⽤ではサーバーとクライアントを横断したIssueが多いこともあり⼀元化 ©Happy Elements K.K 54

Slide 56

Slide 56 text

運⽤フロー ©Happy Elements K.K 55

Slide 57

Slide 57 text

運⽤フロー • Issuesに要望・不具合など書き出し • Issuesの棚卸し（開発リーダー） • リリース内容調整（開発リーダー） • 開発打ち合わせ • 開発 • 申請、公開 ©Happy Elements K.K 56

Slide 58

Slide 58 text

要望・不具合書き出し1 • エンジニアはIssuesに直接登録 • この時点では対応するかどうかは未定だが、とりあえず登録しておいてもらう • チーム内他職種、サポートはGoogle Spread Sheetに記⼊ • ⼼理的障壁を低く ©Happy Elements K.K 57

Slide 59

Slide 59 text

要望・不具合書き出し2 • 要望・不具合の場合は、それぞれ「要望」・「バグ」ラベルをつける • デザイン・UI変更が必要な場合は「デザイン」ラベル • リリース時にお知らせが必要な場合は「お知らせ」ラベル • リリース時にサポート共有が必要な場合は「サポート」ラベル • その他にもいくつのラベルが存在 ©Happy Elements K.K 58 Issue登録時のルール

Slide 60

Slide 60 text

要望・不具合書き出し3 ©Happy Elements K.K 59 • 最終的にはhekk/boys_issuesの1マイルストーンがこのような形に

Slide 61

Slide 61 text

Slide 62

Slide 62 text

棚卸し • 毎週⼀回、開発リーダーが実施 • チーム内他職種、サポートの記⼊したGoogle Spread Sheetの要望・不具合を、対応・検討するもののみIssuesに棚卸し • 優先度のラベルをつける • 優先度関連のラベルは開発リーダーのみがつける • 「優先度低」以上はこの時点で対応確定 ©Happy Elements K.K 61

Slide 63

Slide 63 text

Slide 64

Slide 64 text

リリース内容調整 • ⼆週間に⼀度、開発リーダーとプランナーで実施 • Issueごとにマイルストーンを設定 • このタイミングで実装担当者も割り振る • 考慮すべきポイント • プロモーション的に必要な機能開発を含める • ユーザーさん的にうれしい内容を含める • アップデートがあってもユーザーさんに⾒える改善がなければ、アップデートしたくないはず • ⼤きい機能はステップ分けして含めて、⼆週間ごとに進捗確認、スケジュールが⾒直しできるように ©Happy Elements K.K 63

Slide 65

Slide 65 text

Slide 66

Slide 66 text

Slide 67

Slide 67 text

Slide 68

Slide 68 text

Slide 69

Slide 69 text

Slide 70

Slide 70 text

ブランチの作成 • 1つのIssueに対して1つのブランチを作成 • forkはせずブランチを作る • _yourname/xxx-yyy-zzzのような形 • GitHubの使い⽅は簡易版Git-Flow（今回は省略） • ブランチ作成と同時に[WIP]なPull Request（以下 PR）を作成 • WIPはWork In Progressの略 • 担当タスクの明確化と経過の可視化 ©Happy Elements K.K 69

Slide 71

Slide 71 text

Slide 72

Slide 72 text

レビュー依頼1 • レビュアーがレビューしやすい形にする • 実装よりレビューの⽅が⼤幅に時間がかかるのは良くない • 例えば、表⽰が重要な画⾯の場合、スクリーンショットやアニメーションGIFなどをコメントに載せる ©Happy Elements K.K 71

Slide 73

Slide 73 text

Slide 74

Slide 74 text

Slide 75

Slide 75 text

Slide 76

Slide 76 text

レビュアー割り当て2 • レビュアーは開発リーダーが割り当てる • 優先的に割り当てる⼈ • 元々そのコードを書いた⼈ • 周辺コードに理解がある⼈ • 実装者とレビュアーが責任をもつことを明確化 • チーム状況などにもよるが、少⼈数のチームで開発リーダーがアプリのソースコードを把握しているという状況であれば、開発リーダーのみが担当を割り当てるのが良いと考えている • 重要なコードはレビュアーを⼆⼈割り当てる • 重要であることを明確化 • 例えば、⼤きめの改修や課⾦系の機能 ©Happy Elements K.K 75

Slide 77

Slide 77 text

Slide 78

Slide 78 text

Slide 79

Slide 79 text

レビュー時の⼼がけ1 ©Happy Elements K.K 78 • チーム開発の必読書⼆冊 • ここでは詳しく触れませんが、前提知識としてオススメの⼆冊 • 新メンバー加⼊時にまず読んでもらう実装とレビューの前提知識開発チームコミュニケーションの前提知識

Slide 80

Slide 80 text

レビュー時の⼼がけ2 • 以下を予め決めておくことが重要（あんスタの例） • レビューの⽬的 • 新しいメンバーが最短時間で理解できるソースコードとする • バグのダブルチェック。実装者とレビュアーが責任を持つ • 実装者に求める基準 • サーバー: Ruby on Railsの基本的な使い⽅を理解している • クライアント: C#3.0およびUnityの基本的な使い⽅を理解している • レビュアーのスタンス • 指摘→修正の流れではなく、基本的にはディスカッションで、質問・提案という形でコメントする • 好みの問題となれば、実装者・開発リーダーを尊重する ©Happy Elements K.K 79

Slide 81

Slide 81 text

Slide 82

Slide 82 text

Slide 83

Slide 83 text

Slide 84

Slide 84 text

申請・公開 • 最近の審査は平⽇（⽶国時間）の24〜48時間程度で完了 • 1回は出し直せるくらい余裕をもって申請 • アプリ公開から24時間以上あけた上で強制アップデートを実施 • 強制アップデート時に更新が来ていないユーザーさんがいないように ©Happy Elements K.K 83