GameWithを支えるインフラ基盤

柴山嶺氏（以下、柴山）：みなさんのんびり聞いていただければと思います。10分という枠なんですが、あまり気にせずしゃべります。

（会場笑）

タイトルは「GameWithを支えるインフラ基盤」。インフラ基盤というとスコープが広すぎるので、今回はスケールイン・アウト戦略についてお話しします。

大まかな流れはこんな感じでしゃべりたいと思います。まず自己紹介をして、GameWithのサービス紹介をします。先程、牧野の方からもあったんですけど、もう少しシステマチック的な観点から紹介します。あとは、どのようにスケールインとスケールアウトをするかと、課題と今後の展望ですね。

ちなみにスケールイン・スケールアウトはわかりますか？　Webサーバーなどを横に並べて増やしたり、減らしたりすることをスケールイン・スケールアウトと言います。

僕自身、何をしている人なのかと言うと、本名は柴山と申します。

TwitterのアカウントやGitHubなど、諸々は@serimaでやっていますので、もしよければフォローお願いします。

今はエンジニアマネージャーをやっていて、且つサーバーサイドエンジニアで技術広報などをしています。技術広報は兼任というか、ほかのみんなもブログ書いたり結構やってくれます。リードとは言わないですけど、技術広報や、エンジニアの採用関係を牧野さんと一緒にやっています。

僕がなぜGameWithに入ったかを簡単に説明します。僕が入社したのは2017年の3月ですね。マザーズ上場の3ヶ月前でした。当時はエンジニアマネージャーではなく、普通にサーバーサイドエンジニアとして入社しました。エンジニアとしては社内で10人目くらいです。

選んだ理由は、組織に興味があって今後マネジメントもやっていきたいからでした。正直、ゲーム開発はしたくないけど、ゲームには関わっていたい（笑）。というのは、前々職がグリーでソーシャルゲームを作っていたことがありました。そこでゲーム開発自体はもういいなというのがありました（笑）。

（会場笑）

そんな感じでゲームには関わっていたい気持ちはありました。うちの会社の社長は若くて、今29歳ですかね（注：2018年8月21日時点）。元エンジニアで創業時はコードを書いていたので、そういうところもあってエンジニアの気持ちとかわかってくれるのでは？　みたいな気持ちがあって入社しました。

あとは単純に会社がめっちゃ成長していたのが選んだ観点の大きなファクターですね。

次に、前職や前々職では何をしていたのかお話します。実はこの会社はもう5社目です。年齢は31歳なんですけど、わりと転々としている感じの人です。前職は占いコンテンツの会社でアプリ開発。その前は新規事業やソシャゲの開発などをしていました。

もっと遡ると、スマホが出る前に実は学生起業をしていて、チェーン店に特化した店舗検索システムをガラケー向けに作っていたこともありました。

GameWithの概要

ということでそろそろ本題に移っていきます。

これは『GameWith』。みなさんたぶんご存知ですね。一度は見ていただいているはず。ここに来ていただいている方は（笑）。

（会場笑）

これは弊社IRの資料から持ってきたものです。

やはりトラフィックがある程度はあります。国内ウェブサイト30位で、わりと上位。ゲームメディアでは1位という感じです。

ゲームメディアと言っても、みなさんが一番見ているのはゲーム攻略情報だと思います。

攻略記事と動画とゲーム紹介。あとは先程も牧野からありましたけど、ユーザーコミュニティ。SNS機能もあったりします。結構言われるのが、コンテンツ作成で使っているのが、「WordPressがメインなんでしょ？」ということですよね。

（会場笑）

いやいや、そんなことはないんですよ（笑）。そこは伝えていきたいポイントですね。

やはり記事がメインというかコンテンツメインのウェブサイトなので、そうやって見られちゃうのはしょうがないと思います。でも、しっかりと開発していることは伝えていきたい気持ちがあります。

うちが取り扱っているゲーム数は56個（注：2018年8月21日時点）。昨日数えてみました。こんなにやっていました。『モンスト』『パズドラ』『FGO』あたりのビッグタイトルを扱いつつ、最近はコンシューマーゲームの攻略も始めたりしています。

GameWithの裏側

ここからエンジニアっぽい話をしていきます。うちのサービスは今は基本的にAWSを使っています。これは1週間のELBのRepuestCount、リクエスト数ですね。

1週間なのでだいたいこの波が1日くらいみたいな感じで、それが7個あるみたいなイメージです。

これが昼の波、夜の波みたいな感じです。これがとある1日のお昼12時ごろのスパイクと21時くらいのスパイク。注目すべきは2倍以上のスパイクが来ていたりします。

とあるまた別の日のリクエスト数。今度は昼が大きくて夜はそんなにない。

そういうケースもあったりします。

うちのサービスというかサイトの特徴として、先程言ったようにリクエスト数が定常的にそこそこ多いところと、リクエスト数の増減が外部依存なんですよね。

以前、ソシャゲを開発しているときは、自分でイベントやスケジュールを組みますし、ある程度、Webサーバーなどを横に並べておく事前準備などがわりとできました。

それに比べると、うちは取り扱っているゲームのイベントや障害などに依存しがちで、特定の記事へのトラフィックが急に来たりしたこともあります。わりと負荷予測が立ちづらいんですよね。

当然1つのゲームじゃなくて複数のゲームを扱っていることで、いろいろ複合的な要因があって、より予測が難しい感じです。

また、イベントが始まった瞬間から急激にリクエスト数が増加することがありました。さきほど、見せたスパイクの図だとこの5分、10分もない数分間でここまで立ち上がるみたいなスパイクが結構あります。

テレビCMや『ガイアの夜明け』など、「WBS（ワールドビジネスサテライト）」砲などと言いますけど、それに近しいスパイクぶりが特徴です。

GameWithのインフラ構成

これは本番系のざっくりした概略図です。

そんなに難しい構成ではありません。gamewith.jpでRoute 53でELBにぶら下げて、EC2インスタンスがある。キャッシュやDB、デプロイサーバーなど、いろいろあります。構成としては特殊なことはそんなにしていないです。

今回話すスコープはここにしています。

EC2インスタンスとELBと、jelaというものがあります。ここについてしゃべります。

構成要素としてはこんな感じです。

AWSのS3とELBとEC2とHubotとGoogle Apps Scriptを使っています。

今回はここにフォーカスした概略図をさらに書いてきました。

先程の問題をある程度半自動というか、完全解決はしていないんですが、現状はこんな感じで対応しています。基本的にうちはChatOpsでデプロイまではいかないんですけれど、サーバーの台数設定などをチャットで管理、コントロールできるようになっています。

台数、スケジュール、この時間に何台くらいほしいかは、実はエンジニアが設定しているのではありません。うちの会社は攻略部という部署があります。なので攻略部に翌月のイベントなどを考慮した負荷予測を立ててもらっています。

それをエンジニアが用意したGoogle Spreadsheet＋Google Apps Scriptでごにょごにょして（笑）、S3のバケットにエクスポートしたものを置いておく。Hubotがそのバケットに置いたファイルを定期的に読みに行って、今の時間は何台みたいなことを定期的にやっていく仕組みがあります。

ここにops-toolsとあるんですけれども、Hubot自体はただのインターフェースです。ops-toolsというGoが書かれているものなんですが、Goで書かれているインスタンスを制御するためのスクリプトのようなものがあります。Hubotがops-toolsを操作して台数をコントロールする。

あとはオプティマイズの処理もあって、何時に何台という明示的な台数設定と、あとはELBの直近何分間のリクエストカウントを見て、次の何分間の台数を算出するロジックがあります。そのロジックがops-toolsなどに書かれている感じです。

これはSlackの、先程言ったHubotですね。

jelaという名前なんですけど、このjelaという名前は創業メンバーの飼っている猫の名前。彼はもう退職してしまいましたが（笑）。猫の名前だけは生き続けています（笑）。

（会場笑）

これはoptimizerが走ったときの様子で、「現在30台で、次29台にしたいです」「1台減るよ」という感じです。

こちらはスケジューラが指定台数を設定するときの画面ですね。ログがひたすら流れていくみたいな、そんなチャンネルになっています。

それによって、サーバーの台数を事前にある程度ここまで波を立てておくみたいことをしています。

先程のグラフだと、しきりに波があるんですが、実はこのように予測がされていて、そこまでいかなかったけど一応イベントのために予測がされていて、インスタンス自体は温まっていた状態です。そういう風に動いています。

課題とこれからの展望

課題としては単純に金銭的なコストを削減していきたいところと、攻略部の人が入力してくれるみたいな話があったと思うんですが、これが職人技となっているので、どうにかしたいのが課題です。

今後の展望としては、コスト削減という意味ではスポットインスタンスなどを使っていくことであったり、インスタンスタイプをもっと適切なものにする。最近だとc5のインスタンスなど、たくさん出ていると思いますが、それを使うなりする。あとは台数算出をもう少しいい感じにすることかなと思います。

最近検討しているのがコンテナ化です。あとはマルチクラウドなどを検討しています。今は普通にVMベースで動いているんですが、そもそも立ち上がりが数秒や10秒で立ち上がるならばオートスケールでいけるんじゃない？　という仮説を持っています。それがもし上手くいくなら、そもそも設定がいらないことを検討したいなと思っています。

今、うちは全部AWSなんですけれども、GCP、GKEを使えないかという話もあります。うちのgamewith.jpではまだ使っていないんですが、新規事業ではGKEを使ってみていてコンテナ化を今検証中です。

こんな課題がほかにもインフラだけではなくて、PHPのコードやフロントにもある。ゴロゴロ転がっています。

こんなフェーズを楽しめる人にとっては、すごく楽しい環境だなと個人的には思っております。という感じで、これで締めるとたぶん牧野が喜ぶと思うので（笑）。ゲームをより楽しめる世界を創るというところに共感してくれる方は、ぜひぜひ！　と言う感じで終わりたいと思います。いいですか？

牧野：はい、大丈夫です！　ありがとうございました。

（会場拍手）

ELBの処理能力について

牧野拓也氏（以下、牧野）：もしご質問があれば、この場でいくつかいただきたいんですけど、ある方いらっしゃいますか？

（会場挙手）

ありがとうございます。

質問者1：例えばELBの暖気など、ELBのスケールが間に合わないことがよくあるパターンだと思うので、そういうときはなにか対策などをされたりしますか？

柴山：ELB自体はいつも1個ですね。

質問者1：ELBのインスタンス自体が自動で増えるじゃないですか？

柴山：ELBにぶら下げているインスタンス？

質問者1：そうです。ELBが後ろで立ち上げているインスタンスは勝手に増えたりします。

柴山：勝手に立ち上がるのは、オートスケーリンググループの話ですか？

参加者：ELB自体の暖気の話で、ELBは負荷によってスペックというか処理の能力が変わってくる部分のお話かなと思います。

質問者1：そうです、そうです。

柴山：なるほど。そこはとくに今はやっていないですね（笑）。

加我：たぶん、恒常的にある程度のアクセスはあるので、そこまで申請しなくてもやれているのが現状かなと思っています。

牧野：そのとおりです。

（会場笑）

柴山：ちなみにカメラマンをしている方が。

加我：一応インフラエンジニアです（笑）。

牧野：インフラエンジニア兼カメラマン？

加我：そうですね。カメラマン兼インフラエンジニアですね。

（会場笑）

牧野：ほかにいかがでしょう？

（会場挙手）

質問者2：さばいているリクエストの性質は基本GetBotですか？

柴山：基本的にGetですね。記事へのリードがメインですね。

質問者2：ありがとうございます。

牧野：ほかにありますか？

（会場挙手）

質問者3：さきほどの予測の図とトラフィックの図があったと思うんですけど。ぴったり合っててすごいなと思ったんですけど、外れたときにレスポンスが遅くなったことはけっこうあったりするんですか？

柴山：たまにあります。ちなみに、障害でまれに落ちるんですが、落ちるときはどういうときかと言うと、例えば攻略部の方たちがスケジュールを入れているじゃないですか。

当日になってゲームのイベントが時間通りに開催されないということで、そのときは台数は増えるけどアクセスは来ない状況が続きます。ただoptimizerは時間通りに走ってしまうケースがあります。アクセスがないからインスタンスの台数は下がります。イベントが始まります。ドカーン！

（会場笑）

というケースで何度かありました。この1年くらいはないかもしれないですけど、以前それで落ちたことはあります。

牧野：ほかにいかがでしょうか？　だいぶGameWithの課題を突きつける質問が多くて……。

柴山：心が痛い（笑）。

（会場笑）

牧野：いや、ありがたいなと思います。柴山は以上になります。どうもありがとうございました。

（会場拍手）

レガシーコードの中でも迅速にユーザーに価値を届ける

牧野：こんな感じで進行していきたいと思います。次は2人目、メモリーですね。良きタイミングで始めてください。

メモリー（@m3m0r7）氏（以下、メモリー）：はじめまして。メモリーと申します。よろしくお願いします。

緊張していて風邪ひいちゃったんですけど、あまり気にせずお願いします。今日の話す内容なんですけど、「レガシーコードの中でも迅速にユーザーに価値を届ける」といった内容でお話させていただきます。

趣味は散歩とラーメンの食べ歩きなので、最近少し太ってきてやばいです。趣味はそれくらいですね（笑）。

メインでやっているのがサーバーサイドと半分インフラと、フロントエンド。NLPはNatural Language Processingといって、自然言語処理を大学のときにやっていました。

私も柴山と同様、数社渡り歩いてきたんですけど、1社目が恵比寿にあるベンチャーでBtoBのメディアをやっている企業でアルバイトをしていました。

そこで17歳のときから4年くらい社内インフラからサービスの開発全般などをやっていました。

その次の会社では、オンラインサロンのサービスを展開していた会社にいました。そこでは2年間くらい開発全般をしていまして、そのあと受託開発会社に入ってリードエンジニアとして1年間やっていました。今はGameWithでエンジニアとして働いています。

経歴と開発環境

これは私の経験になるんですけど、今までどんな開発環境下だったのかを説明したいと思います。

1社目の恵比寿にあったベンチャーなんですけど、メインで扱っている言語がCakePHP1.2でした。当時はCakePHPの最新系は2系だったので相当レガシーでした。

ちなみにエンジニアは私1人でした。数人入ってくれたんですけど辞めてしまって、「辛いなぁ」みたいな（笑）。結局1人なので開発すべてを担当していました。

その会社は営業系の会社だったので、GitHubを入れたいって言っても、毎月お金がかかるものは入れたくないということで、メールにzipを添付して、やりとりしていました。

（会場笑）

2社目の会社では、CakePHP1.3で、当時は3系が最新版でした。これもレガシーですね。

エンジニアは7人で、うちインターンが4人くらいですかね。「フレームワーク？　なにそれ知らない」という感じの会社さんで、コアファイルを直接いじっていました（笑）。

なにがヤバいのかと言うと、いろいろなコントローラがあるんですけど。そのコントローラの1番上にfunctions.phpみたいな感じのファイルがあって、それを全部のインクルードしていました。相当レガシーですね。

3社目は受託開発の会社です。エンジニアは私1人で、プロジェクトマネージャーも私が担当していました。クライアントはBootstrapやWordPressなどが結構好きで、それを指名してくるという形でしたね。

クライアントはGitの使い方を知らないので、この会社でも久しぶりにzipで送る作業をしていました。

（会場笑）

GameWithもレガシーコードは満載だった

今までの経験を踏まえて今日話すことは、この3つです。

1つ目なんですけど、「レガシーコードは会社が生きている限り不確実性を伴いながら成長する」2つ目は、「ユーザーに価値を届けるためにどうしたらいいのか」という内容を話したいと思います。最後はまとめですね。

いきなりなんですが、GameWithも実はレガシーコード満載です。わかっていたんですけど（笑）。

（会場笑）

例えば、散りばめられたコードが高級IDEで追うのも難しいです。

他にもスネークケースとキャメルケースが入り混じっているコードがあったりします。あとは書き方がほかのコードと統一されておらず、なぜかマージされているコードや、IDEで飛べないみたいな感じのコードがあります。「IDEは何だろう」と考えさせられるコードが多いです。

ほかにもいろいろあるんですが、コントローラに殴り書きされたロジックや、照合順序、ANDやORなどが適切に使われていない、緊急対応でレビューすらされなかったコードが蔓延していたりしました。

会社の新しいフェーズによってデータの移行などが必要になってくると思うんですけど、そのメソッドなどが消されず、残されたまま。なぜか3,200行くらいある謎のクラスが陣取っています。

（会場笑）

なぜレガシーコードは生まれるのか？

しかし、なぜレガシーコードが生まれるのかを考えたときに、この3つだと思っています。

1つ目は、事業のフェーズによって必要・不必要なコードが必ず生まれる。例えば、今やっているビジネスがAというビジネスで、新しいビジネスはBだとしたら、Aというコードは不要になってくると思います。

ステークホルダーからの不確実な仕様の中手探りで実装を進めることがありました。例えば部署に別れていると、どうしてもよくわからない仕様などがあるんですよね。「これ、こうしたい」「でもどうしたいの？」みたいな。

ステークホルダーがなぜか10人くらいいたりして、混乱するみたいな状態があったりします。「これ明日まで」みたいな感じで、急ぎの実装でレビューがまったくされていないようなコードがあったりします。

また、開発メンバーとチーム自体のそれぞれの技術スタッフの違いでコードの誤差というか、レガシーと呼ばれるようなコードが生まれると思っています。

どうすれば、ユーザーに価値を届けることができるか考えた時に、GameWithではいくつかの施策を行うことにしました。実際に行なっている施策を紹介します。

例えば、最近始めたことなんですけど、不要なコードを見かけたら他人事と思わずにリファクタリングしていこうと考えていくチームの一体感が大事だと思っています。開発の高速化にもつながるので、やっていったほうがいいかなと思います。

これはあくまでリファクタリングが目的ではなく、チームの開発速度を高めるためのリファクタリングだと認識するとより良いチームになるのかなと思います。例えば、私が最近やっているのは、PHPDocという、Javadocみたいな感じのものを書いていたりしています。

ステークホルダーからのいろいろな仕様に関しては、窓口を複数ではなく一本化することで、ディレクターが情報を巻き取ってくれていて、その結果、エンジニアがとても開発しやすい環境に徐々にシフトしてきています。

技術スタックの違いに関してはみんなのベースを整えるために、底上げの仕組みとして、もともとレビュワーが属人的だったんですけど、それを当番制にしてみんなでレビューしていくようにしました。

これでまとめになります。レガシーコードは属人的な部分もあり開発の足枷になるんですけど、なるべく排除していきたい。とはいえ、そのコードがお金を生み出しているのも事実なので、上手くレガシーコードと付き合いつつ、最終的には脱却し、、ユーザーへ迅速に価値を届けることができると。

自分からレガシーコードを脱却しようと動くことで、チームにもいい影響が出ますし、いろいろなことも見えてくると思っています。以上です。

（会場拍手）

チーム全体でリファクタリングを進めるために

牧野：ありがとうございます。では先程と同じようにご質問がある方がいればぜひお願いします。

（会場挙手）

質問者4：先程、発表の中で古いコードなど、いらなくなったコードを、リファクタリングするのをチームで呼びかけて、それを直していくとおっしゃっていました。たぶん実運用で本当に……呼びかけただけで上手くいくとは自分の経験的に思っていないです（笑）。

（会場笑）

ほかにも具体的な要因はありますか？

メモリー：そうですね。例えば今どういうところに懸念を抱いていますか？

質問者4：チームのメンバーによっては呼びかけられたものの、見てもスルーするままの人が出てくるわけじゃないですか。そういった人は受け入れることになってしまうんですかね？

メモリー：例えば、コードレビューをしているときに、誰かがレビュワーを担当していても、それが「やっぱりおかしいよね」となったら横から入るのも全然ありだと思っています。

結局、誰が知識を沢山持っているのはわかり切っていると思います。そのスタックによって変わってくるので、やはりわかっている人がやっていくのも大事だと思います。答えになっているかわからないですけど……すみません。

質問者4：いえ、大変参考になりました。ありがとうございます。

リファクタリングとスキルについて

質問者5：「プロジェクトとしてリファクタリングをするんだ」みたいに人員と工数を取ってやることはできないのかな？　と思っています。自分の会社も開発系なんですけど、そういうことをやっていたりします。

エンハンスしていくと、どうしてもレガシーになってくるので、プロジェクトとしてそういうことを設けたりすることもありなのかなと思います。

メモリー：ありだと思います。ただ弊社はまだ成長段階なので、エンジニアが少ないのもあって、現状難しいのもあるんですよね。進んでいくと、やはりチームのマネジメントなども変わってきて成長していくのはあると思います。

質問者5：ありがとうございます。

質問者6：レビューを担当制で割り振っていたと思うんですけど、あれはスキルレベルなどを問わず完全にランダムという感じですか？

メモリー：完全にランダムです。

質問者6：そのあとのリリースチェックというか、この人が承認したらプロダクションとして出せるところは、どうなっているんですか？

メモリー：現状なくて、GameWithだとQAエンジニアというポジションの方がいて、その方が品質をチェックしてくれます。そのあとにリリースというかたちになります。問題があった場合はリバートなどをして、また修正するかたちになっています。

質問者6：最後はQAチームが？

メモリー：そうですね。

質問者6：わかりました。ありがとうございます。

キャメルケースとスネークケースが混在した理由

牧野：ほかにいらっしゃいますか？

（会場挙手）

質問者7：最初の方でキャメルケースやスネークケースなどが混在しているとあったと思うんですけど、なにかそれを統一させるような規約などはGameWithさんの中ではあったりするんですか？

メモリー：一応あります。私が入ったときにはもうできていて、GameWithではスネークケースに統一するというルールになっています。でもなぜかキャメルケースがあるんです。

（会場笑）

質問者7：結構分量が多くて読まれていない感じになっちゃうんですかね？

メモリー：そこで言うと、もともと古いコードだったので、古いキャメルケースが残ったまま、それが修正されない状態でどんどん次にマージされていってしまう。ほぼコピペみたいな状態になっていたりするので、今は「見かけたら直してね」くらいの感じです。

牧野：ほか、よろしいでしょうか？　では以上になります。ありがとうございます。

（会場拍手）

ブロックチェーンゲーム開発の取り組み

牧野：ラストにいきたいと思います。最後は色が変わりまして、ブロックチェーン事業のエンジニア、たけぽんです。

たけぽん（@takepon_phd）氏（以下、たけぽん）：たけぽんという名前で登壇しています（笑）。前の2人はメディアの裏側を支えるエンジニアという人たちで、僕はその裏側の裏側で新規事業の開発をしているような感じです。かなり裏の裏の奥のほうです。

今やっていることはブロックチェーンゲームの開発をしています。なぜやっているか、どんなことをしているかという触りを今日はお話しできればと思っています。

自己紹介しますと、実はWebのサービスなどを今まで全然やったことがなくて、素人みたいなものなので、この部屋の中で一番わかっていないという感じの技術者です。

一応工学博士とスライドに書いていますが、それくらいしかアピールすることがなくてですね（笑）。大学で研究をしていたり、そのあと企業に勤めて研究開発から新規事業に携わってきていました。研究と新規事業にこだわりはあるんですけど、技術的にはWebのサービス開発などはあまりわかっていないですので、Q&Aはお手柔らかに（笑）。

（会場笑）

GameWithには今年の7月に入社しました。一応R&Dエンジニアでの採用です。新規事業のエンジニアというポジションにいます。担当としてはブロックチェーンゲームの開発で、ブロックチェーン部分を開発も担当しています。

前職は印刷業界の会社に勤めていまして、コンピュータグラフィックスや、コンピュータビジョン、画像処理、AIやロボット、ARなどです。そういう流行りものを色々と触ってきて、最近はブロックチェーンにハマってやっています。

ブロックチェーンはゲームをどう変えるのか？

今日お話しすることは、なぜブロックチェーンなのか？　そもそも世の中がブロックチェーンになぜ注目しているのかということと、GameWithがゲームとブロックチェーンを掛け合わせてやろうとしているお話をします。

前談として、Twitterでもブロックチェーン自体の期待感についてけんすうさん（@kensuu）がおっしゃっています。

2000年前後くらいにもインターネットに対する期待感があったと思います。私も結構歳なのですが、その当時は大学生くらいでした。テレビなどでも見ていましたし、インターネットの流行りは、開発者というわけではなくて、あくまでユーザー目線だったんで羨ましい感じで過ごしていました。

その時と同じように、今の20代の人たちがブロックチェーンに対して期待感みたいなものを感じているんじゃないかなと。そういった流れもあり、僕たちもこれからブロックチェーン事業をやっていこうと思っています。

じゃあゲームとブロックチェーンをなぜ掛け合わせるか。ブロックチェーンは現実的に改ざんできないデータベースみたいな捉え方なんですけど。ブロックチェーンを使うとデジタルデータというものの所有権を持つことができると言えると思います。

仮想通貨は今、ただのデジタルデータなんですけど、それはお金として価値があって、普通のJPEGなどだったらいくらでも複製できると思います。でも仮想通貨は複製できないです。このように世の中に複製できないものがあります。

CryptoKittiesというゲームは1,300万円で猫を売っていて、デジタルのデータを所有できるようになってくるところが革命的だと思っています。

これまでのゲームとの違い

これは弊社の代表の今泉（卓也）なんですけど、今泉も『GameWith Magazine』で話しています。

我々はブロックチェーン自体の開発をしていくのではなくて、それを使ってどういう体験ができるのかを開発しています。

今泉が言っているのは、ゲームを仕事にするということです。今まで、スーパーファミコンなどのゲームもありました。最近のスマホのゲームで言うと課金をするみたいなイメージがあって、時間とお金を使ってゲームをして楽しむものなんです。個人的な意見で言うと、時間とお金を消費して楽しむ捉え方ですね。

ゲームをやればやるほど、お金が足りなくなったり、時間がなくなったりする現状です。それをこのブロックチェーンをゲームに持ち込み、ゲームをすることでアイテムがブロックチェーン上に乗れば、それは世の中に1つしかない、自分が所有しているアイテムを売買してお金が稼げるようになるといったイメージで、今はそういう世界を目指して作っています。

スマホゲームとブロックチェーンゲームが何が違うかと言うと、スマホゲームはスマホとサーバーがあります。単純に言うと、こういうふうにプレイするわけですよね。

ブロックチェーンゲームは同じようにスマホとサーバーがあって、ここでプレイ情報をやりとりしている。アイテムの売買はWebでサーバーのものを売り買いするインターフェースに今なっています。違いとしては主にブロックチェーン上にゲームのアイテムを乗せると売買ができるようになるイメージです。

ゲーム自体の開発はそんなに変わらなくて。少し変えるとブロックチェーンに乗るイメージで今作っています。

なぜブロックチェーンゲームを作るのか？

弊社のミッションとして先ほどお話ありましたが、「ゲームをより楽しめる世界を創る」を掲げていて、そういうミッションのもとブロックチェーンゲームを開発しています。

課金モデルをベースにしたゲームから、ゲームのデータを流通させるビジネスモデルを構築するために、まずは自らブロックチェーンゲームを作ってみようと思ってやっています。

GameWithがブロックチェーンゲームを出して、ユーザーに楽しんでいただいて、それでアイテムの売買などをできる世界を、まず世の中の人に体験していただく。

それを見て、ユーザーやゲームの開発会社など、いろいろな人がたぶん反応すると思うんですね。そういう世の中の反応を自分たちで起こしていくために、今新規事業としてそれらを開発しています。

何をしているかというお話は、まだちょっと言えなくてですね（笑）。

（会場笑）

なぜしているかは言えるんですけど、何をしているかというのはまだ言えなくて。もう少しお待ちください（笑）。そのうちリリースしたらぜひご覧ください。

ブロックチェーンの開発における技術スタック

どうやっているかは、ブロックチェーンの開発、EthereumやSolodityなどの開発をしたことがある人は今から言うことは聞かなくてもいいです。

一応、7月から入って今やっていることなので、そこくらいだったらお話できるかなと思って、今日は用意してきました。

プログラムはSolodityという言語で書きます。Ethereum上で分散型アプリケーションと難しく書いているんですけど、どういうことかと言いますと、Solodityという言語、JavaScriptみたいなんですが、そのコードをコンパイルして、Ethereum上のEVMというバーチャルマシン上にバイナリを置くんですね。

するとサーバー側からその関数を呼び出して実行して、トランザクションを発生できる。誰かから誰かへアイテムを送信するような動作原理になっています。

私がやっているのはSolodityでコードを書いて、コンパイルして、ここに乗せるところでして、こちらのゲームのクライアントとサーバーサイドは従来とほぼ変わらない。自分が用意した関数をコールしてもらう感じで今作っています。

今までと全然違った作り方というわけではなくて、今までの技術を活かしながら開発できるイメージです。なので、開発フレームワークもけっこう整ってきています。Truffle、OpenZeppelin、INFURA、Gethなどがキーワードであります。

Ethereum上にデプロイしてしまうと、実行するたびにGas代というお金がかかったりするんですね。なのでEthereum上でテストができないので、まずはローカルの環境でEthereumっぽいもので実行、テストします。

開発における課題

上手くいくと、次はテストネットでテストします。Ethereumは世界中でP2Pでできているメインネットと呼ばれるネットワークなんですけど、それとは別にテスト用に用意している人たちもいて、第2段階としてそこでデプロイして実行します。

テストネットでうまくいったら次はメインネットで動かします。まだ今はローカルやテストネットのレベルで開発をしています。

ブロックチェーンの開発をしていて、今までとは少し違うのは、例えばデータをブロックチェーンに書き込むときに、Ethereumだと15秒くらいかかったりするんですよね。

また、Gasの設定が低いと書き込まれないことがあって、ここが今までのデータベースと比較するとぜんぜん違いますね。それをユーザーインターフェースでどう見せるか。アイテムを売りに出したけど、15秒間はなんの反映もされないから、どうやってこの待ち時間を埋めるかを考えています。

ブロックチェーンに書き込むたび、数円の手数料がかかります。それをユーザーが払うんだとしたら、アイテムを売るためにたびたび数円払わないといけないことがあったりします。

ゲームによってはアイテムを移動するためにその都度、数円かかったりするので今までタダでゲームやってきたのにゲームをやるだびにどんどんお金が減っていってしまうような仕組みに今ブロックチェーンのゲームはなっています。なので技術的というより、それをどうやったらユーザーが納得してくれるかを考えています。

最近だとアプリストアの審査に引っかかる課題もあります。iOSやAndroidで出していたけど、しばらくしてリジェクトされて、また出し直すようなことが起こっていたりします。

それは課金モデルが、ストアでお金を課金して手数料がAppleやGoogleにいくモデルではなくて、ゲームに直接Ethereumを組み込んで取り出す。ストアを通さない決済になるので、そのへんがちょっと難しい。

特にAppleは難しいところがあるので、それをどうやって回避するかというか、うまくやるかということを考えていたりしています。簡単に、こんな感じです。

牧野：ありがとうございます。

（会場拍手）

Ethereumを採用した理由

牧野：ご質問のある方いらっしゃったら、ぜひ。

（会場挙手）

質問者8：最初の発表でGKEを新規事業で検証を兼ねて使っているということだったんですけど、その新規事業はBCのゲーム事業ですか？

たけぽん：違う事業もそうですし、一応このプロジェクトでも試してはいます。

質問者8：ブロックチェーンなどではなくてアプリケーションサーバーでの検証ですか？

たけぽん：そうですね。そんなに深くは考えていないですけど、サーバー側のコードがGoで書かないと呼び出しにくいことがあります。「だったらGKE」という感じでやっていたりします。

質問者9：今回、Ethereumというパブリックのブロックチェーン上で実装するということだったんですけれども、さきほどおっしゃっていたようにスケーラビリティの問題やGasの価格の変動によって、トラフィックの変動が起こってしまったなどのデメリットが生じてきてしまうと思うんですね。

それに対して、プライベートのブロックチェーン、Cordaなどだとデメリットが少なくてゲームにより適切なんじゃないかなと思いました。その中でパブリックのものを選んだ理由を教えていただけますか？

たけぽん：選んだ理由は、手始めにやるとしたら今Ethereumで開発するノウハウがいろいろ貯まっていたり、そういう開発者とつながっていたりというところが大きいです。

比較をして絶対的にこちらがいいとかというわけではないです。我々がEthereumのブロックチェーンゲームを開発して出すということで、それ自体をメインの事業にしていくかというのはまだわからないです。たぶん、ほかの人もやりたいとは思っているはずです。いろいろな人がEthereum上でやりたいと思っているはずなので、そこをまず第一にやってみようと思っています。

質問者9：コミュニティを第一に見た場合にはEthereumが有利だった感じですかね？

たけぽん：そうですね。数が多いという。

質問者9：わかりました。ありがとうございます。

牧野：1個補足をすると、ブロックチェーンの選定はEthereum1択だったんですけど、メインネットに直結するのか、DAppチェーンなどを使うのかという検討はしました。

基本的にLoom Networkを使うかどうかは悩んだんですけれども、たけぽんが言っていたようにEthereumには参照できるライブラリだったり、プレイヤー、エンジニアが世界中にたくさんいて、世界中の頭いい人たちが頑張ってやっているそのソースを使えるというのはいいかなと思います。

逆にLoomにはなかったんですよね。は検討していた時期（登壇者注：今年の6月くらい）にはなかったんですが、今は増えてきているのでメインネット直結でやることも視野に入れています。

質問者9：なるほど。ありがとうございます。

牧野：ほかにある方いらっしゃいますか？

なさそうですかね。今日は3人のピッチをやらせていただきました。改めてありがとうございました。

（会場拍手）

Occurred on , Published at