デブサミ2016へ行ってきた

こんにちは、uzuraです。
Developers Summit 2016、通称「デブサミ2016」へ行ってきました。
今年のデブサミは2月18日〜19日の2日に渡って開催され、僕は両日とも参加させて頂きました。

まだまだ知識不足なこともあり、セッションの中でついていけない箇所も多々あったのですが、自分で理解できた範囲でレポートを書きました。
セッションを聴きながら社内のSlackに実況を垂れ流していたので、主にそれを元にまとめてあります。

また、僕はフロントエンドのエンジニアなので、フロントエンドの技術に関するセッションをメインで聴いてきました。
そこそこの数のセッションを見てきたので、目次から気になるセッションの見出しにジャンプして読んで頂いた方がいいかも。

参考資料

デブサミ2016 講演関連資料まとめ

1日目

SparkやBigQueryなどを用いたモバイルゲーム分析環境

スピーカー	小松 裕一 [サイバード]
時間	2月18日(木) 12:10〜12:40
資料	http://www.slideshare.net/yuichi_komatsu/sparkbigquery
どんな話？	自社の提供するソーシャルゲームで、ログやアンケートをどうやって解析して役立てているかというお話

• スマホ向けのソーシャルゲームを作っている会社 (イケメン○○のシリーズは聞いた事があった)
• 環境は AWS (Amazon Web Services) や GCP (Google Cloud Platform) を用いて構築されている
• ログ解析は主に3種類ある
  1. Cynapse という BI ツールによる、KPI の可視化
  2. アドホック分析 (エンジニア利用) による、過去ログや大量データの集計
  3. アドホック分析 (アナリスト利用) による、ユーザの行動やアンケートの分析
• Cynapse による解析
  • S3 にログデータを集約 → Spark でデータ加工 → RDS に処理データを格納
  • 全コンテンツのログのフォーマットを統一することで、形式特定や形式変更のコストが不要になり、スムーズな分析が可能となっている
  • ユーザのプロフィール、ログイン情報、課金情報、ガチャ情報、アイテム情報を主に集計してユーザの動向を分析している（生々しい…ｗ
• アドホック分析 (エンジニア利用)
  • 大量データの分析はBigQueryを使って解析
• アドホック分析 (アナリスト利用)
  • アンケートなどのテキストデータは、RMeCab で形態素解析をして出現頻度を集計したりしている
  • 連続した単語群を集計することで、例えば「アバター」「保存」「数」というつながりが多かったら、「ゲーム内のアバターの保存数を増やして欲しい」という要望が多いことがわかる

JavaScript.trend(spec) /* 最新言語仕様を軸とした JavaScript の最先端解説 */

スピーカー	浅井 智也 [Mozilla Japan]
時間	2月18日(木) 13:05〜13:50
資料	http://www.slideshare.net/dynamis/java-scripttrendspec
どんな話？	JavaScript の標準化の歴史や最新言語仕様、パフォーマンスについてのお話

• 技術に関する細かい話でしたが非常にわかりやすく、若干毒舌の効いたトークも面白くてとても良いセッションでした
• JavaScript が標準化に至った歴史
  • 元々 Netscape 社で開発された JavaScript を、 InternetExplorer 用に模倣して作られた JScript とかが世に出てきて、実装ごとに非互換な部分が多くなってきてしまったので標準化しよう！という話になって ECMAScript が作られた
  • Perl や Ruby、C# など、様々な言語の影響を受けて機能追加や刷新が行われてきた
    • 「CoffeeScript という一昔前に一部で流行ったものもあって…いや誰かに怒られそうだから今のは撤回します」って仰ってて笑ったｗ
  • JavaScript は、最初は10日くらいで作られた「やっつけ仕様」だったらしい
  • 当時 Java が流行していたので、マーケティングの理由からそれをもじって JavaScript という名前に変更されてリリースされた
  • 今後は ECMA は1年ごとに更新予定で、GitHub で管理されていて新しいアイデアや機能の実装の進捗とかがわかるので、今後どういった機能が実装されるかもある程度わかる
  • ES5からES6にかけてページ数が約2倍になったため 「今の JS しか知らないということは JS の半分も使いこなせていないということである」 と仰っていたのが印象に残った
  • Babel
    • Babel というトランスパイラ（最新仕様で書いても下位のコードに変換してくれるツール）を使えば、「Edgeの前のあまり名前を挙げたくないブラウザ」でも安心
    • gulp 等のタスクランナーと連携すると非常に便利なのでオススメとのこと
• JavaScript の最新の言語仕様
  • いろいろと直感的な書き方ができるようになるので、書きやすい/読みやすいコードを書けるようになりました、というお話
  • テンプレートリテラル、デフォルト引数、可変長引数、スプレッド演算子、分割代入…詳しくはスライドにて
  • let や const 、ブロックスコープ変数の登場で (function(){ ... })() という呪文のような構文をもう書かなくていいのが嬉しい
• JavaScript のパフォーマンスについて
  • JavaScript が遅い遅いと言われていた原因は、現在かなり解消されつつあるが、それでもまだ場合によっては非常に遅い場合もある
  • 原因1. 型が動的であること
    • 型チェックのオーバーヘッドが常に発生する
    • asm.js の登場で解消、型が一意に確定するような記述をすることで高速化が可能
  • 原因2. ソースコードが機械語ではなくテキスト形式であること
    • WebAssembly によって解消

大規模Redisサーバ縮小化への戦い

スピーカー	駒井 祐人 [アカツキ]
時間	2月18日(木) 14:10〜14:55
資料	http://www.slideshare.net/ssuserf3788f/redis-58419914
どんな話？	自社で運営するソーシャルゲームの Redis サーバを高負荷に耐えるため64台まで増やしたけど頑張って8台まで減らしましたというお話

• サウザンドメモリーズとかテイルズオブリンクを運営している会社
• やたらめったらミサワが出てくるスライドが印象的でした（↑の資料では削除されてる模様）
• Redisを64台から8台に減らしたノウハウのお話
• 最初はRedis8台だったが、サービスリリース後に負荷が大きすぎるので緊急で64台までスケールアウト
• AWS のElastiCache を用いた運用だったためランニングコストが高騰し、縮小化へ
• keys("*") というコマンドを使用していたのが高負荷の主な原因
  • 上記コマンドはそもそも本番では細心の注意を払って使用すべしとリファレンスに書いてあるとのこと
• ノードを増やした際に特定のノードをコピーして増やしたため、同じデータが重複しまくってゴミになる問題も発生していた
• マージして重複を排除したかったが、それらしいドキュメントやツールがどこにもなかったため、自分たちで方法を検討することに
  • 案1：key/valueを抜き出して別のDBに再格納する
  • 案2：dumpを出力して結合する
  • 案2の方法の方が計算量が少ないためこちらを採用
• 各サーバのDBのヘッダ・データ・チェックサムをバイナリレベルで分割して結合した
  • 話にするとシンプルだけど実際やるのを考えると非常に怖い話…
• オペミス等トラブルもあったが4時間で作業完了
  • 135万円/月→38万円/月までコスト削減
• しかし、上記の変更が原因となって、接続数上限に達した＆上限変更ができないという問題が発生
  • DB数自体を減らすことに（8DB/1サーバ → 4DB/1サーバ）
  • 今度は案1を採用して対応
• 最終的には現在は8台で正常に運用できていますという話でした

リアクティブ・アーキテクチャ～大規模サービスにおける必要性と課題

スピーカー	岡本 雄太
時間	2月18日(木) 15:15〜16:00
資料	http://www.slideshare.net/okapies/reactive-architecture-20160218-58403521
どんな話？	分散システム（マイクロサービス、リアクティブシステム）の利点と、運用の難しさやノウハウ

• 45分でスライド98枚を説明するのでかなり駆け足で難しいセッションでした…
• 分散システムでは、開発組織のスケーラビリティ、性能のスケーラビリティ、耐障害性を目的とする
  • 3つのうち1つ目をマイクロサービス、2つ目と3つ目をリアクティブシステムで実現する
• アプリケーションを小分けにしてそれぞれが連携して運用するのがマイクロサービス
  • マイクロサービスの各コンポーネントの連携は、なるべくシンプルに、依存なくすべき
• リアクティブシステムはScalaを開発したTypesafe社が主導
  • アプリケーションの要求の変化（リソースの増大、稼働率やレスポンスのシビア化）
  • 大規模システムを構築する組織はこの変化に対処する設計原則をすでに発見している
  • そのような特徴を備えるシステムをリアクティブシステムと呼ぶ
    • リアクティブシステムの説明は抽象的であまりピンと来なかった
• 「マイクロサービスはリアクティブシステムの実例の1つと考えることができる」
• レジリエンス＝耐障害性ではなく、もう少し広い概念であり、障害があった場合にどう復旧するかといった能力の意味合いも含む
  • 障害は必ず起こるので、エラーを別のコンポーネントに波状させない工夫や、障害が発生した際にどういった復旧の仕方をするのかが重要
• リアクティブシステムの課題
  • コンポーネント間の通信は非同期処理で行うが、コンポーネント同士の要求速度/処理速度を合わせなければならない
  • Back-Pressure … AからBへ要求を送る前に予めBの現在の余裕を確認する
  • 「そろそろ怒涛のスライドストリームをバックプレッシャー無しで叩きつけるスタイルはなんとかした方が良い感はある」と仰っていて笑ったｗ
• 分散オブジェクト設計の第一法則は 「オブジェクトは分散させるな」
  • なんでも分散させればいいという話ではなくメリット・デメリットを考慮する必要がある、という意味

マイクロサービス時代の大規模動画配信基盤 〜 Ruby × Go = ∞

スピーカー	小嶋 聡史 [DMM.comラボ], 江藤 慎吾 [DMM.comラボ]
時間	2月18日(木) 16:20〜17:05
資料	http://www.slideshare.net/DMMlabo/rubygo
どんな話？	DMMの動画配信サービスで使用されているコンポーネントの構成についてのお話

• どういった経緯でその技術を採用したのか？という話が詳細に聞けて興味深かった
• 動画配信サービスのマイクロサービス化について
• 従来は MONOLITHIC ARCHITECTURE (巨大な1システム) で運用していたが、ニーズへの対応にスピードが求められるようになり、開発の短期化を図ってマイクロサービス化
• 動画配信には VOD（動画配信）とLOD（生放送配信）がある
  • このセッションでは主に後者についてのお話
• マイクロサービス化するにあたって、サービス間の連携や、通信のオーバーヘッド、セキュリティの問題、デバッグのしにくさなどが課題に
• サブシステム切り出しでは、論理的な独立を考慮（業務や組織やデータなどの観点）して一貫性を保った
  • 物理的な独立性も考慮して、パフォーマンスや耐障害性も
• マスターコントローラやハンドラーは Rails、裏画面は Angular.js、プレイヤーのマネージャは Go
• 1つの変更が他に波及しないように、共通部分はModuleとして切り出した
• APIポリシー定義は、Twitter REST APIを参考にした
  • デバッグしにくい問題は、HTTPヘッダにトレースIDをつけて通信することで解消
• 技術選定で大事にしたい事
  1. エンジニアに習得できるか
  2. エンジニアが成長できるか
  3. エンジニアを確保できるか
• その結果、Ruby + Go + Angular.js という組み合わせに
  • Node.js や PHP7 なども候補にあがったが、メンバーの強いモチベーションにより Ruby on Rails を採用することに
  • バックエンドAPIの選定にあたって、今回の条件は
    • 高負荷をさばける
    • 開発・保守しやすい
    • 今後盛り上がりそう
  • ↑によりGo言語を選定
    • Go言語はシンプルかつ厳格なルールを持った言語だが、純正のツールにより気の利いたチェックをしてくれる
    • 徹底的なシンプルさを追求していて、バージョン依存も極力ないようにしてある
    • 「Goに入ってはGoに従え」

2日目

次世代モバイルデータベースRealmのテクノロジー解説と最新情報

スピーカー	岸川 克己 [Realm Inc.]
時間	2月19日(金) 10:00〜10:45
資料	非公開？
どんな話？	モバイルデバイス専用DB「Realm」の紹介

• 僕の普段していることとは分野違いなこともあって、少々難しい内容だった
• Realm（レルム）とは、モバイルデバイス専用の新しめなDB
  • 従来は SQLite がシェアを担っていた部分
  • オープンソースで、高速な動作、Objective-C, Android, Swiftに対応
  • モバイルに最適化されている
  • 日本語はチャットサポートもあったりして手厚い対応らしい
  • あらかじめ関連するデータをひも付けて保存しているので、RDBでいうJoinにあたる処理のコストが低い
• Realm vs CoreData
  • 12万件の全件検索比較
    • Realm: 0.0004秒
    • CoreData: 8.01秒
  • 12万件データ検索のメモリ消費の比較
    • Realm: 全件 12MB、部分一致 12MB
    • CoraData: 全件 65MB、部分一致 18MB

【ユーザ企業が語る！】チーム開発をサポートし、生産性や品質の向上を実現するソフトウェア開発環境とは？

スピーカー	金城 雄 [NTTアドバンステクノロジ], 近藤 翔太 [インターネットイニシアティブ], 廣田 華代 [マクニカネットワークス]
時間	2月19日(金) 11:05〜11:50
資料	http://www.slideshare.net/You_Kinjoh/siergithub-enterprise
どんな話？	GitHub Enterprise を社内で採用するに至ったまでの軌跡に関するお話

• GitHub Enterprise の話を期待していたが、主に GitHub そのものの利点に関するお話だった
  • 普段業務で使用しているため、その分納得感はあった
• GitHub Enterprise とは、オンプレミスの閉じた環境で使えるGitHubらしい
  • リポジトリは使い放題、ユーザ数で課金
  • GitLab 等の類似製品と比べて何のメリットがあるのか？という質問には「GitHubがやっているという点です」
• Githubとは、開発者による開発者のためのプラットフォーム
  • 2008年サービス開始
  • 350億円のサポートを受けている
  • 昔は「gitを使っていることがメリット」だったのが、今は 「gitを使っていないことがデメリット」 と言われるまでに
• GitHub Enterprise (以下、GHE) を如何にして自社へ導入したか (金城さん)
  • スピーカーの方の会社は現在トライアル導入中のため、導入後の効果についてはまだあまり話せないということ
  • マクニカネットワークスが国内の代理店になっている
    • 個人的にはマクニカは SSG のイメージだった
  • マクニカの人が社内に来ることがあり、その席で強く内部へ推薦したとのこと
    • 「熱意が重要」
  • 導入を推薦するにあたって、費用対効果がどうなのかということが問題になった
    • 決裁権限を持っている人が技術のことをわからない場合、お金のモノサシでしか測れないため
    • 最終的に、費用対効果が測りようがないので、熱意だけでがんばって説き伏せたという話だった
• GHE を使うことは、外部にソースコードが出ないため、セキュリティのメリットが大きい
  • 普通の GitHub で、Private だと思ってコードをあげてたら Public だった…という事態は意外によくあるとのこと
• GHEと内製開発の文化 (近藤さん)
  • IIJ では、CVS、SVN、Gitlab、Gitrious 等のバージョン管理が混在していたが、2年半前にGHEに統合した
  • GitHub も検討したが社外にソースコードを出したくないという意見が多かった
  • 使い方も多様化していて、マークダウンで書いたドキュメントだけを集めたリポジトリとかもあるらしい
  • GHE には、WebUIがそのままポータルになる、PRするとWebUI上でそのまま議論できる、プロジェクト外でも柔軟に見れるといったメリットがある
• Octocat ステッカーも配ってましたが、蓮コラっぽくて社内では不評でした
  • これらしい、雪のイメージの模様
    

Web開発者ならおさえておきたい「常時SSL/TLS化の実装ポイント」

スピーカー	平賀 巌 [シマンテック・ウェブサイトセキュリティ]
時間	2月19日(金) 12:10〜12:40
資料	非公開？
どんな話？	常時 SSL/TLS 化に関する業界全体の動きと実装についてのお話

• 常時SSLとはWebサイトをすべてHTTPS化すること
  • HTTP/2 をうまく利用すると通信速度も高まる
• 2015年8月時点で、インターネットの全トラフィックの20％は HTTPS 通信
• 各ブラウザで、HTTP/2サイトとの接続速度向上や、HTTPのページに特定の条件で警告を出すよう検討している等、常時SSL化に向けて移行していってる
  • Firefox の次期バージョンで、 HTTP のページで <input type="password"> が使用されていると警告を表示する機能が追加検討中
• アメリカ政府は「2016年末までにすべての.govサイトを常時SSL/TLS化」することを宣言
  • 現在、36%のアメリカ政府のサイトが対応済み
• SSL/TLS は SEO 順位向上要素の一つであり、2014年8月から HTTPS Web サイトの順位を優遇するロジックを実装
• HTTPS 対応しているなら、HTTP で通信して時は HTTPS のページにリダイレクトするようにすべし
  • cookie にも必ずセキュア属性をつけるべし

ソフトウェアテストから見たクックパッドのモバイルアプリ開発

スピーカー	松尾 和昭 [クックパッド]
時間	2月19日(金) 13:05〜13:50
資料	http://www.slideshare.net/KazuMatsu/20160216-devsumi-cookpad-matsuo
どんな話？	テストエンジニアの観点から見た、開発プロセスや体制のお話

• テストエンジニアとしてだけではなく汎用的に役立つお話だった
• 発表前週はバレンタインだったのでクックパッドは大変だったらしい（お疲れ様でした）
• モバイルアプリ版のクックパッドも少しずつ安定してきた
  • 2014年は Android 版のクラッシュ数が10,000件/日だったのが、最近は2,000件/日くらいになった
  • iOSは25,000件/日だったのが最近3,000件/日くらいになった
    • 僕もユーザですが確かに以前はよく落ちてた気がする…
• このあたりの改善や変化の軌跡をテストエンジニアからの観点で
• Quality is not equal to test by James Whittaker
  • 品質の確保とテストを実施することは決して同義ではない
• Quality is value to some person by Gerald Weinberg
  • 品質の価値は、エンジニアにとって、デザイナーにとって、ユーザにとって、全部異なる
• テストエンジニアのミッションは品質の向上＝様々なボトルネックの解消
• 開発に適した組織づくり
  • リズムの形成：リリース日の周期を固定させて余計な交渉ごとを除く
  • リリースマネージャ：リリースについて責任を持つ人を明示的に置く
  • botの整備：自動化できる部分は細かく自動化
    • アプリのレビューコメントを毎朝取得してチャットにポストしたり
    • PR時の自動チェックをしたり
    • 残っているIssueをチャットにポストしたり
• 振り返りと改善の習慣化
  • 2〜3週間程度で継続：長すぎると惰性、短すぎると手につかない
  • 開発する人の状態を観察：↑や朝回で
• テスト関係の効率化
  • before：項目と手順のみを列挙したテスト、理由や組み合わせがわかりづらい
  • after：テストの自動化、画像差分による判定の自動チェック、ブラックボックス中心化
  • マインドマップ、クラシフィケーションツリー、ディシジョンテーブル作成支援
• 上記の取り組みにより、開発者の心的負担の軽減、安心感向上
• 途中でAndroidとiOSの開発者を分散したが、開発フローやプロセスを整備していたため大きな変化は不要だった
• 2015年からは開発プロセスにデザイナーを組み込んだ
  • リリースマネージャのデザイナー版を設置してリリース時にチェック
  • GitHubのIssueで特定のラベルをつけるとデザイナーにmentionが飛び、チェックしなければマージできないような仕組みに
  • 明示的に組み込むことが大事
• 自動化テストの深化
  • アプリの画面網羅率の増加と差分検出
  • クライアントアプリからのリクエストのキャプチャにより、リクエスト過多の検出
  • リソース監視によるCPU使用率等の増加の検出
• 2016年はフィードバックループの深化が目標
  • テスト結果の成果物をデザイナーやディレクターにも関わりやすくする
  • 自動で取得された画像キャプチャを、開発者以外からもアクセスしやすいように整理するのが課題

そろそろ俺たちの本気を見せてやるぜ！～ マイクロソフトとOSSごった煮 DevOps 衝撃デモシリーズ！

スピーカー	牛尾 剛 [マイクロソフト コーポレーション], 寺田 佳央 [日本マイクロソフト]
時間	2月19日(金) 14:10〜14:55
資料	非公開 (主に実機デモ)
どんな話？	DevOpsを実現するための開発ツールのお話

• テンションが高く面白い話でしたが「DevOps はどのツールを使っているかではなく考え方だ！」と謳った割にツールの話しか聞けなかったので少しもやもや
• 当日の温度感は Togetter の方がよくわかるかも
  • セッション始まったらいきなり大声で「Are You Readyyyyyyyyyy!?!?!?!?」って言い始めてびびった
• 発表やデモには思いっきり Mac を使用
  • 「ぼくらマイクロソフトやけど、みて、ほら、Mac。全然愛社精神ないですよ！」
• とにかくテンションが高いぶっちゃけトークは聞いてて気持ち良かった
  • 「スポンサーセッションって退屈じゃないですか？ 製品紹介とかつまらんわ！」
• アジャイルにはマニフェストがあるけど、DevOpsにはないので、明確な定義がない
  • 「このツール入れたらDevOpsです！？あんなんぜーんぶ嘘！！」
    • 後々の展開を見るとこのあたりの発言に若干の矛盾を感じた
    • 「大事なのはツールではなくて考え方」 という考え自体は非常に共感できるものがあった
• ここからはデモ
  • VSTS, Jenkins, Docker のデモ
    • Gitへプッシュ → Jenkinsでビルド → Docker Cloudへデプロイ
  • レゴ・マインドストームというのを出してソフトとの連動のデモ
    • けど全然まともに動いてなかったのはご愛嬌
  • 最後は Minecraft の画面から Docker を動かせる UI(?)
    • コマンドを打ったらコンテナを表す建物ができて、建物の中に入るとコンテナのスタートやらストップが出来る
    • 名前は「Dockercraft」

アジャイル開発(GINZA)

スピーカー	野口 大輔 [ドワンゴ]
時間	2月19日(金) 16:20〜17:05
資料	http://niconare.nicovideo.jp/watch/kn1140
どんな話？	アジャイルの手法自体に縛られて何かを見失っていませんか？というお話

• 何事においても用意されたスタイルに合わせるだけでなく最適解の見極めが大事だと感じた
• セッション開始直前に「ドワンゴなのにスーツ着てるぞ」と会場(のTwitter)が若干のざわめき
• Practice Slaves kill Development
  • プラクティスに固執するあまりプロジェクトを壊してないか
• アジャイルの原点とは
  • 短い期間
  • 動くソフトウェアを中心
  • 関係者とのコミュニケーション
  • やり方を最適化
• 上記のように、アジャイルには決して「こうしろ！」というmustは出てこない
• Do Agile right
  • アジャイルには様々な手法があり、プラクティスを信じることで救われる気持ちになるが、それは決して本質的ではない
  • たくさんのツールや手法、認定制度、プラクティスの盲信…
  • 「Agile is Dead」
• ここからはニコニコが歩んできた改善の歴史のお話
• 現状より少し進むために何をするか
  • 現在位置＝現在の状態を知ること
    • これまで何をしてきたのか、今どんなことをしているのか、これから何をすることが必要なのか…
  • 目的地を知ること
    • 最終的な目的を考える
    • どこに向かっていてゴールはどこなのか、リリースが目標？売り上げ○○万円が目標？
• 現在地と目的地を考えて違和感がある場合は、進路を変える必要がある
  • ゆっくり進路を変えることが大事
    • 破綻しないように少しずつ変える、メンバーの理解を得る必要もある
• 現在地＆目的地と開発技法はあっているか、誰しもがもう一度冷静に振り返って考える
• 厳密さを捨てる勇気、プラクティスはあくまで基本であり全てではない
• なぜもっと自由にやらないのか
  • 制約やリスクがあるから
  • マネージャを縛る鎖は主に Quality/Cost/Delivery で、それ以外は案外なんとかなる
• 「アジャイル開発」を辞めて「アジリティの高い開発」を目指す
  • すべてを疑ってかかり、考えた上で最善の手を常に考える

その他、回っていて印象に残ったブースとか

ITエンジニアに読んでほしい！技術書・ビジネス書大賞2016

• 展示してありました、逆光ですが…
• 実際に店頭販売もしており、会場限定の割引価格で購入可能となっていました
  

kintone カフェ

• フリーバナナを配ってるのが印象的でした
• 無料自販機やWiFiスポットもあり、セッションの空き時間に休憩所として利用しました
• 肝心の kintone については、ハンズオンもやってましたが時間が合わず

Atlassian

• プロジェクト管理ツール JIRA のクレジット画面がイースターエッグになってて、インベーダーゲームになっていますよという紹介をしてました
• 実際にプレイしてタイムを計ることができて、上位3名はホワイトボードに名前が書かれてました
  • やってみたけど38秒とかで(おそらく)4〜5位くらいでした。。1位は28秒くらいだったかな…？
• 会社でも試そうとしてみたけどバージョンが違っていてゲームボーイのRPG風？みたいなのになってました