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

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

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. あらすじ 舞台は男性アイドルを育成する「私⽴夢ノ咲学院」。 夢ノ咲学院に転⼊してきたたった⼀⼈の⼥⼦⽣徒（プレイ ヤー）が、プロデュース科の第１号として選ばれ、個性豊か な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גࣜձࣾʹΠϥετ Ϩʔλʔͱͯ͠ۈ຿ • カードイラストを２〜３タイトル経験 • →ファンタジー神話カードゲームの終盤イベントでシナリオを担当 ©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. テーマを決める１／４ イベントに登場するメンバーを決めたら、⾒せたいところを考えながらʰςʔϚʱを決める。 今回は8⽉に実施したイベントを元に、2組のアイドルユニットの⾒せ⽅を紹介。 ˣࠨ͕݄ʹ࣮ࢪͨ͠ʰḐ೤ˑւลͷϏʔνϚονʱ ӈ͕݄ʹ࣮ࢪ͍ͨͭ͠΋ͷํ޲ੑͷΠϥετˣ ʢແ๷උɺͪΐͬͱΦϑͷ࢟Λ૝૾ͤ͞Δʣ ʢΨʔυ͕ݎ͍ɺઓୂ΋ͷ͕શ໘ʹग़͍ͯΔʣ ©Happy Elements K.K 21 『流星隊（りゅうせいたい）』は戦隊ものをモチーフにしているため肌を出さないスーツ系⾐装が 多い。夏の露出できる季節のため、これまでほぼ未登場であるカジュアルな⾐装を着せることにした。 さらに、アイドルではあるものの、たまにはステージ以外の仕事姿も描きたい。 以上から『海の家』をテーマにした。
23. テーマを決める２／４ ©Happy Elements K.K 22 『2wink』（トゥウィンク）はテクノポップをモチーフにしているためかわいい⾒せ⽅が多い。 「男らしさ」をアピールし、かわいい男の⼦にあまり興味がない層にアプローチした。 海でできる格好良いシチュエーションとして『ビーチフラッグ』をキーとしてイラストを制作。 （画像はこれまでの『2wink』のリーダー葵ひなた）
24. テーマを決める３／４ ©Happy Elements K.K 23 これが「男らしさ」を強調し制作したイラスト。 普段の「かわいい」印象から『ギャップ』があるイラストが完成した。
25. テーマを決める４／４ イベント開始の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