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

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

関西ゲーム勉強会2016WINTERでの発表内容です

37d70278f8cf62eccf8127bc7baaf62a?s=128

KUSAKARI Kei

December 08, 2016
Tweet

Transcript

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

  2. ⾃⼰紹介 • 草苅 景(くさかり けい) • @kusakari • Happy Elements株式会社カカリアスタジオ所属

    • チーフエンジニア • 「あんさんぶるスターズ!」グループリーダー ©Happy Elements K.K 1
  3. あんさんぶるスターズ!とは ©Happy Elements K.K 2

  4. あんさんぶるスターズ!とは ©Happy Elements K.K 3 項⽬ 内容 ゲーム内容 スマートフォン向け「アイドル育成プロデュースゲーム 」

    リリース⽇ Google Play版2015年4⽉28⽇ App Store版 2015年5⽉1⽇ 略称 あんスタ!
  5. アイドル育成プロデュースゲーム ©Happy Elements K.K 4

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

  7. 実績 • 200万ダウンロード(2016年9⽉) • Google Play 2015年ベストゲーム • 「夢王国と眠れる100⼈の王⼦様」と同時選出 •

    ⼥性向けゲームでは初 • 2016年9⽉15⽇ App Store トップセールス1位 • ⼥性向けスマホゲームではトップクラス ©Happy Elements K.K 6 INSIDEより引⽤
  8. 運⽤サイクル • ⼆週間ごとにイベントとガチャを実施 • ⽉に⼆回ずつ • イベントを中⼼とした運⽤サイクル • 本⽇はこの⼆週間における「ίϯςϯπاըϑϩʔͱ ͩ͜ΘΓϙΠϯτ」、「ӡ༻ɾ։ൃϑϩʔ」という⼆

    軸でご紹介 ©Happy Elements K.K 7
  9. ゲーム制作の「ポイント(=こだわり)」 コンテンツ編 ©Happy Elements K.K 8

  10. ⾃⼰紹介 ©Happy Elements K.K 9

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

    ©Happy Elements K.K 10
  12. ②⾃⼰紹介 • ೥ʹΞϧόΠτͰ)BQQZ&MFNFOUTגࣜձࣾʹΠϥετ Ϩʔλʔͱͯ͠ۈ຿ • カードイラストを2〜3タイトル経験 • →ファンタジー神話カードゲームの終盤イベントでシナリオを担当 ©Happy Elements

    K.K 11 • ೥ΑΓʮ͋Μ͞ΜͿΔελʔζʂʯͷίϯςϯπσΟ ϨΫλʔͱͯ͠ۈ຿ • 開発開始後「あんさんぶるガールズ!」を後任に引き継ぎ、現在は 「あんさんぶるスターズ!」のコンテンツディレクターを担当 • ೥ʹʮ͋Μ͞ΜͿΔΨʔϧζʂʯͷίϯςϯπϓϥϯ φʔͱͯ͠ۈ຿ • 新規タイトルの⽴ち上げでイラストレーターとして参加 • →キャラクターや世界観設定、イベント企画を担当したことがきっか けで、そのままプランナー(コンテンツディレクション)業務がメイン になる
  13. ③業務内容 • ओʹήʔϜ಺Πϕϯτͷاը • イベントのテーマ、⾐装デザインやカードのイラスト監修、シナリオ の発注 など • Ϣχοτ$%΍෣୆ɺάοζɺࡶࢽͳͲͷ؂म •

    ユニットCDのコンセプト、舞台脚本、グッズのデザイン、雑誌の記事 などを監修 ©Happy Elements K.K 12
  14. 運⽤における「ポイント(=こだわり)」を ゲームの最⼤の強みである 「コンテンツ」の制作サイドから紹介します ©Happy Elements K.K 13

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

  16. 「イベント企画」におけるそれぞれの「ポイント=(こだわり)」 • イベントのメンバーを決める • テーマを決める • ⾐装とステージデザインを決める • ストーリーの展開(あらすじ)を考える •

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

    シナリオとBGMを発注する • シチュエーションに合わせてイラストを制作する • まとめ ©Happy Elements K.K 16
  18. イベントのメンバーを決めていきます ©Happy Elements K.K 17

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

  20. 「イベント企画」におけるそれぞれの「ポイント=(こだわり)」 • イベントのメンバーを決める • テーマを決める • ⾐装とステージデザインを決める • ストーリーの展開(あらすじ)を考える •

    シナリオとBGMを発注する • シチュエーションに合わせてイラストを制作する • まとめ ©Happy Elements K.K 19
  21. テーマを決めていきます ©Happy Elements K.K 20

  22. テーマを決める1/4 イベントに登場するメンバーを決めたら、⾒せたいところを考えながらʰςʔϚʱを決める。 今回は8⽉に実施したイベントを元に、2組のアイドルユニットの⾒せ⽅を紹介。 ˣࠨ͕݄ʹ࣮ࢪͨ͠ʰḐ೤ˑւลͷϏʔνϚονʱ ӈ͕݄ʹ࣮ࢪ͍ͨͭ͠΋ͷํ޲ੑͷΠϥετˣ ʢແ๷උɺͪΐͬͱΦϑͷ࢟Λ૝૾ͤ͞Δʣ ʢΨʔυ͕ݎ͍ɺઓୂ΋ͷ͕શ໘ʹग़͍ͯΔʣ ©Happy Elements K.K

    21 『流星隊(りゅうせいたい)』は戦隊ものをモチーフにしているため肌を出さないスーツ系⾐装が 多い。夏の露出できる季節のため、これまでほぼ未登場であるカジュアルな⾐装を着せることにした。 さらに、アイドルではあるものの、たまにはステージ以外の仕事姿も描きたい。 以上から『海の家』をテーマにした。
  23. テーマを決める2/4 ©Happy Elements K.K 22 『2wink』(トゥウィンク)はテクノポップをモチーフにしているためかわいい⾒せ⽅が多い。 「男らしさ」をアピールし、かわいい男の⼦にあまり興味がない層にアプローチした。 海でできる格好良いシチュエーションとして『ビーチフラッグ』をキーとしてイラストを制作。 (画像はこれまでの『2wink』のリーダー葵ひなた)

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

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

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

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

    Elements K.K 26 7⽉イベント『⻘』 8⽉イベント『⽔⾊』 9⽉イベント『緑』
  28. 「イベント企画」におけるそれぞれの「ポイント=(こだわり)」 • イベントのメンバーを決める • テーマを決める • ⾐装とステージデザインを決める • ストーリーの展開(あらすじ)を考える •

    シナリオとBGMを発注する • シチュエーションに合わせてイラストを制作する • まとめ ©Happy Elements K.K 27
  29. ⾐装とステージデザインを 決めていきます ©Happy Elements K.K 28

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

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

  32. ⾐装とステージデザインの「ポイント」 ©Happy Elements K.K 31 • 決めた「テーマ」からぶれずにイラストに落とし込む。 • ⾐装とステージのデザインも「テーマ」を反映し統⼀感を出す。 •

    カードのレアリティによる差は⾐装デザインにも反映させ、⾼レアリティの価値が 伝わるように配慮。 ⾐装は『海の家』の従業員海パンと ユニットのテーマカラーでデザインしたシャツ 背景は『海の家』 ほぼ⾒えないが⾐装と店の名前も揃えている
  33. 「イベント企画」におけるそれぞれの「ポイント=(こだわり)」 • イベントのメンバーを決める • テーマを決める • ⾐装とステージデザインを決める • ストーリーの展開(あらすじ)を考える •

    シナリオとBGMを発注する • シチュエーションに合わせてイラストを制作する • まとめ ©Happy Elements K.K 32
  34. ストーリーの展開(あらすじ)を 考えていきます ©Happy Elements K.K 33

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

    34
  36. 「イベント企画」におけるそれぞれの「ポイント=(こだわり)」 • イベントのメンバーを決める • テーマを決める • ⾐装とステージデザインを決める • ストーリーの展開(あらすじ)を考える •

    シナリオとBGMを発注する • シチュエーションに合わせてイラストを制作する • まとめ ©Happy Elements K.K 35
  37. シナリオとBGMを発注していきます ©Happy Elements K.K 36

  38. シナリオとBGMを発注 ©Happy Elements K.K 37 • あらすじとイメージを明確に伝えるため、参考画像もまとめて共有。 • イメージを共有することで、こちらが意図している⽅向性への理解度が 増す。シナリオにもイラストとリンクした描写を描いてもらえる。(臨

    場感や没⼊感が増し、ユーザーがよりのめり込みやすくなる) • BGMもイベント毎に⽤意することで、シンプルな仕様のゲームにも変化 を付けることができる。
  39. 「イベント企画」におけるそれぞれの「ポイント=(こだわり)」 • イベントのメンバーを決める • テーマを決める • ⾐装とステージデザインを決める • ストーリーの展開(あらすじ)を考える •

    シナリオとBGMを発注する • シチュエーションに合わせてイラストを制作する • まとめ ©Happy Elements K.K 38
  40. シチュエーションに合わせて イラストを制作していきます ©Happy Elements K.K 39

  41. シチュエーションに合わせてイラストを制作する • ⽉⼆回のイベントサイクルで制作 スパンが短いため、シナリオの納 品前にストーリーのおおまかな流 れが書かれたプロットや、イラス トを制作しやすそうなシチュエー ションを先に送っていただき制作。 • シナリオの納品後に、シナリオか

    らイラスト映えするシーンを抜粋 して制作することもある。(ライ ターとイラストレーターだと⾒て いるところが異なるため) • シチュエーションを先にもらって いても、納品されたシナリオで展 開が変わって該当のシーンが異 なっていることもあるため、こま めに連絡を取ってお互いに対応。 ©Happy Elements K.K 40 (Slackで連携している)
  42. イラスト制作での「ポイント」 ©Happy Elements K.K 41

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

    Elements K.K 42
  44. 「イベント企画」におけるそれぞれの「ポイント=(こだわり)」 • イベントのメンバーを決める • テーマを決める • ⾐装とステージデザインを決める • ストーリーの展開(あらすじ)を考える •

    シナリオとBGMを発注する • シチュエーションに合わせてイラストを制作する • まとめ ©Happy Elements K.K 43
  45. まとめ ©Happy Elements K.K 44

  46. まとめ • ゲーム制作の上では、ʮϙΠϯτʢͩ͜ΘΓʣʯをしっかり持って運営 して⾏くことが⼀番⼤事である。 • ʮϙΠϯτʢͩ͜ΘΓʣʯが伝わるように⼼がければ、ユーザーさんは きちんと理解しゲームとしての魅⼒と受け取ってくれる。 • さらに、 ʮϙΠϯτʢͩ͜ΘΓʣʯが他社のゲームと差別化を図れる

    ことにつながるのではないかと思う。 ただし、 ʮϙΠϯτʢͩ͜ΘΓʣʯが過ぎると運営に⽀障が出る(締め 切りまでに終わらずリリースギリギリになる)ため、効率も考えていいバ ランスを取ることが不可⽋。 ©Happy Elements K.K 45
  47. 質疑応答 • 時間も⾒させて頂きつつ… ©Happy Elements K.K 46

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

  49. 使⽤しているサービス • Slack(チャット) • Skype→HipChat→Slack • 興味のあるチャンネルは、他アプリのチャンネルでも閲覧可能 • GitHub(ソースコード管理) •

    ⾃社でホスティングせず、可能な限り管理コストを省く • GitHub Issues(タスク管理) • Asana→backlog→GitHub Issues • タスク管理はいろいろ試したものの、完全に満⾜できるものはない • 業務にツールを合わせるのではなく、ツールに業務を合わせていく⽅ が柔軟 • GitHubとの連携は⾮常に⼤きなポイント ©Happy Elements K.K 48
  50. • https://speakerdeck.com/shibayu36/hatenaburogutimufalsekai-fa- hurotogithub • こちらの内容を参考にさせて頂き、運⽤・開発フローを整備 ©Happy Elements K.K 49

  51. ⼤事にしていること 安定した運⽤ できるだけ不具合を減らす ⼤きな機能を着実に進めていく ©Happy Elements K.K 50 そのためには… 進捗・責任の可視化、

    ルールの明⽂化などが重要 本⽇は、その取り組みの⼀部をご紹介
  52. 開発チーム構成 • ։ൃϦʔμʔʷ • 社員エンジニア×3 • 学⽣アルバイトエンジニア×2 • プランナー×1 •

    デザイナー×1 ※チーム全体は約30名 ※サポートチームは別チーム ©Happy Elements K.K 51
  53. 開発リーダーの役割 • 開発フローの明確化 • 可能なら明⽂化も • 開発に関する判断を実施 • 判断には実装⼒必須 •

    例えば、タスク・レビュアー割り当て • 開発全般における責任を開発リーダーがもつ • そのため、最悪⾃分で対応できる⼈が望ましい ©Happy Elements K.K 52
  54. イベント周期に合わせた運⽤ • ⼆週間に⼀度、⽉⼆回のイベント • 運⽤フローはイベントサイクル合わせ • 基本的に⼆週間で1マイルストーン • クライアントアップデート •

    基本的にイベントに合わせて、⼆週間に⼀度のアップデート • サーバーアップデート • イベントサイクルに加えて、⼀週間に⼀度アップデート • 定期導⼊⽇を決めて細かな対応をまとめて導⼊ • 例えば、誤字脱字、軽微なイラストの修正、管理画⾯修正など ©Happy Elements K.K 53
  55. 3つのGitHubリポジトリー • hekk/boys • サーバープログラム⽤のリポジトリー • hekk/boys_client • クライアントプログラム⽤のリポジトリー •

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

  57. 運⽤フロー • Issuesに要望・不具合など書き出し • Issuesの棚卸し(開発リーダー) • リリース内容調整(開発リーダー) • 開発打ち合わせ •

    開発 • 申請、公開 ©Happy Elements K.K 56
  58. 要望・不具合書き出し1 • エンジニアはIssuesに直接登録 • この時点では対応するかどうかは未定だが、とりあえず登録しておい てもらう • チーム内他職種、サポートはGoogle Spread Sheetに

    記⼊ • ⼼理的障壁を低く ©Happy Elements K.K 57
  59. 要望・不具合書き出し2 • 要望・不具合の場合は、それぞれ「要望」・「バグ」 ラベルをつける • デザイン・UI変更が必要な場合は「デザイン」ラベル • リリース時にお知らせが必要な場合は「お知らせ」ラ ベル •

    リリース時にサポート共有が必要な場合は「サポー ト」ラベル • その他にもいくつのラベルが存在 ©Happy Elements K.K 58 Issue登録時のルール
  60. 要望・不具合書き出し3 ©Happy Elements K.K 59 • 最終的にはhekk/boys_issuesの1マイルストーンがこ のような形に

  61. 運⽤フロー • Issuesに要望・不具合など書き出し • Issuesの棚卸し(開発リーダー) • リリース内容調整(開発リーダー) • 開発打ち合わせ •

    開発 • 申請、公開 ©Happy Elements K.K 60
  62. 棚卸し • 毎週⼀回、開発リーダーが実施 • チーム内他職種、サポートの記⼊したGoogle Spread Sheetの要望・ 不具合を、対応・検討するもののみIssuesに棚卸し • 優先度のラベルをつける

    • 優先度関連のラベルは開発リーダーのみがつける • 「優先度低」以上はこの時点で対応確定 ©Happy Elements K.K 61
  63. 運⽤フロー • Issuesに要望・不具合など書き出し • Issuesの棚卸し(開発リーダー) • リリース内容調整(開発リーダー) • 開発打ち合わせ •

    開発 • 申請、公開 ©Happy Elements K.K 62
  64. リリース内容調整 • ⼆週間に⼀度、開発リーダーとプランナーで実施 • Issueごとにマイルストーンを設定 • このタイミングで実装担当者も割り振る • 考慮すべきポイント •

    プロモーション的に必要な機能開発を含める • ユーザーさん的にうれしい内容を含める • アップデートがあってもユーザーさんに⾒える改善がなければ、アップデートしたく ないはず • ⼤きい機能はステップ分けして含めて、⼆週間ごとに進捗確認、スケ ジュールが⾒直しできるように ©Happy Elements K.K 63
  65. 運⽤フロー • Issuesに要望・不具合など書き出し • Issuesの棚卸し(開発リーダー) • リリース内容調整(開発リーダー) • 開発打ち合わせ •

    開発 • 申請、公開 ©Happy Elements K.K 64
  66. 開発打ち合わせ • 開発リーダー、エンジニア、プランナー、デザイナー で実施 • 開発内容の周知とスケジュール確認 • 基本的に周知・認識合わせだけなので短時間で終了 ©Happy Elements

    K.K 65
  67. 運⽤フロー • Issuesに要望・不具合など書き出し • Issuesの棚卸し(開発リーダー) • リリース内容調整(開発リーダー) • 開発打ち合わせ •

    開発 • 申請、公開 ©Happy Elements K.K 66
  68. 1つのIssueに対する 開発フロー ©Happy Elements K.K 67

  69. 開発フロー ©Happy Elements K.K 68 ブランチの作成 実装 レビュー依頼 レビュー マージ

    差し戻し エンジニア レビュアー 開発リーダー レビュアー割り当て
  70. ブランチの作成 • 1つのIssueに対して1つのブランチを作成 • forkはせずブランチを作る • _yourname/xxx-yyy-zzzのような形 • GitHubの使い⽅は簡易版Git-Flow(今回は省略) •

    ブランチ作成と同時に[WIP]なPull Request(以下 PR)を作成 • WIPはWork In Progressの略 • 担当タスクの明確化と経過の可視化 ©Happy Elements K.K 69
  71. PRの作り⽅ ©Happy Elements K.K 70 IssueのURL 関連URL チェックすべきポイントは チェックボックスを設ける .github/PULL_REQUEST_TEMPLA

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

    K.K 71
  73. レビュー依頼2 • 仕様が複雑な場合、仕様まとめをコメントに載せる • レビュアーが仕様を探さなくても良いように ©Happy Elements K.K 72

  74. レビュー依頼3 • 必要なデータの作り⽅をコメントに載せる • どういうデータを作る必要があるかレビュアーが調べることがないように ©Happy Elements K.K 73

  75. レビュアー割り当て1 ©Happy Elements K.K 74 [WIP]を取る 「レビュー依頼」 ラベルをつける 開発リーダーが レビュアー割り当て

    Slackで レビュー依頼
  76. レビュアー割り当て2 • レビュアーは開発リーダーが割り当てる • 優先的に割り当てる⼈ • 元々そのコードを書いた⼈ • 周辺コードに理解がある⼈ •

    実装者とレビュアーが責任をもつことを明確化 • チーム状況などにもよるが、少⼈数のチームで開発リーダーがアプリ のソースコードを把握しているという状況であれば、開発リーダーの みが担当を割り当てるのが良いと考えている • 重要なコードはレビュアーを⼆⼈割り当てる • 重要であることを明確化 • 例えば、⼤きめの改修や課⾦系の機能 ©Happy Elements K.K 75
  77. レビューの流れとラベル状況例 ©Happy Elements K.K 76 実装 レビュー マージ レビュー依頼 レビュアー割り当て

    エンジニア レビュアー 開発リーダー
  78. リポジトリーのPRとラベル • 最終的にはクライアントのPR欄はこのような形に • 誰が担当していてどういう状態かがわかりやすくなる ©Happy Elements K.K 77

  79. レビュー時の⼼がけ1 ©Happy Elements K.K 78 • チーム開発の必読書⼆冊 • ここでは詳しく触れませんが、前提知識としてオススメの⼆冊 •

    新メンバー加⼊時にまず読んでもらう 実装とレビューの 前提知識 開発チームコミュ ニケーションの 前提知識
  80. レビュー時の⼼がけ2 • 以下を予め決めておくことが重要(あんスタの例) • レビューの⽬的 • 新しいメンバーが最短時間で理解できるソースコードとする • バグのダブルチェック。実装者とレビュアーが責任を持つ •

    実装者に求める基準 • サーバー: Ruby on Railsの基本的な使い⽅を理解している • クライアント: C#3.0およびUnityの基本的な使い⽅を理解している • レビュアーのスタンス • 指摘→修正の流れではなく、基本的にはディスカッションで、質 問・提案という形でコメントする • 好みの問題となれば、実装者・開発リーダーを尊重する ©Happy Elements K.K 79
  81. これらの話をチームルールとして明⽂化 • チーム参加時に読んでもらう • ルールはQiita:Teamで管理 ©Happy Elements K.K 80

  82. 話を運⽤フローに戻して ©Happy Elements K.K 81

  83. 運⽤フロー • Issuesに要望・不具合など書き出し • Issuesの棚卸し(開発リーダー) • リリース内容調整(開発リーダー) • 開発打ち合わせ •

    開発 • 申請、公開 ©Happy Elements K.K 82
  84. 申請・公開 • 最近の審査は平⽇(⽶国時間)の24〜48時間程度で完 了 • 1回は出し直せるくらい余裕をもって申請 • アプリ公開から24時間以上あけた上で強制アップデー トを実施 •

    強制アップデート時に更新が来ていないユーザーさんがいないように ©Happy Elements K.K 83
  85. まとめ ©Happy Elements K.K 84

  86. まとめ 個々のIssueに対する開発フローを整備 進捗・責任を可視化、ルールの明⽂化 ©Happy Elements K.K 85 安定した運⽤ もちろん、ルールを決めた後も重要 ルールの意識付け、ルールを運⽤に合わせて改善

  87. ご静聴ありがとうございました! • ⼀緒にゲームを作る仲間を募集中! • happyelements.co.jpより応募お願いします! ©Happy Elements K.K 86