ホーム ブログ ページ 8

NERの使い所 with AWS Comprehend

0

はじめに

デジタルイノベーション部の浅田です。

この記事もそうですが、現代社会では何か文章を書くということを老若男女問わず多くの人が行なっているかと思います。記事といった形式張った形ではなくとも、SNSへの書き込みであったり、メールの文章、チャットでのやりとりなど、現代社会では至るところで文章が生成されています。

このような文章、すなわちテキストデータから、何かしらの知見を得ようという試みはテキストマイニングと呼ばれますが、その時に使われる技術が自然言語処理(Natural Language Proccessing、以下NLP)という技術です。

そのNLPを構成する一つの要素に、固有表現抽出(Named Entity Recognition、以下NER)というものがあります。

そして、AWSで固有表現抽出のサービスを提供するのがAmazon Comprehend(以下、Comprehend)というサービスになります。

そこで、固有表現抽出とはどのようなもので、何がうれしいのかをご紹介します。そしてComprehendを使うことで簡単に固有表現抽出を活用できることをご紹介したいと思います

NER(固有表現抽出)とは何か

そのままですが、固有表現(Named Entity)を抽出(Recognition)する処理ということになります。固有表現とは何かというと、大雑把に言えば固有名詞です。

例えば「国家」は一般名詞(Entity)であり、「日本」は固有名詞(Named Entity)です。同様に、「組織」は一般名詞であり、「アマゾン」は固有名詞です。

このように、「日本」という単語が「国家」というカテゴリの特定のものを表現していると認識する処理が固有表現抽出ということになります。

ただ、注意していただきたいのは、特定の物体だけでなく、「日時」といったものも固有表現に含まれます。なので、「2021/12/03」という表現が、時間一般の特定時点の表現であるということを認識するのも固有表現抽出です。同様に「42」という数値も、数値一般の特定表現として認識するのも固有表現抽出のタスクです。

NERができると何がうれしいのか

例えば、

  • 色々なドキュメントを整理してナレッジを得る目的で多数のドキュメントから特定の組織に関する文を抜き出したい
  • チャットボットに対するユーザの発言から、ユーザが購入しようとしている製品名を抜き出したい。

上記のようなケースで組織名や製品名の判定にNERが役立ちます。

同様のことを「正規表現でやれるのではないか」と思った方がいるかもしれません。実際、Pythonの自然言語処理ライブラリであるspacyでは、正規表現のパターンを使って固有表現抽出を行うような機能もあります。

ただ、いくつかのケースにおいては正規表現だけではうまくいきません。

例えば、ドキュメントから「アマゾン」という組織名を探し出したいとします。その時にドキュメント内に組織名としての「アマゾン」と熱帯雨林の「アマゾン」との記述が混在していた場合、正規表現ではうまくいきません。この場合、組織としてのアマゾンと地名としてのアマゾンを文脈から区別する必要があるためです。

そして、それを行うことができるAWSのマネージドサービスがComprehendになります。

Comprehendの主要機能

2021/12現在、Comprehendができることをあげると、以下のようなものがあります。

  • 固有表現抽出
  • キーフレーズの検出
  • 使用言語判定
  • 個人情報識別(英語のみ)
  • 感情判定
  • 構文解析(日本語未対応)
  • トピックモデリング

今回は、固有表現抽出に絞って、ご紹介します。

Comprehendで固有表現抽出をしてみる

Comprehendには、GUI上で機能を試すための画面が存在します。

東京リージョンのReal-time analysisの画面にアクセスすると、以下のような画面が表示されます。

ここのInput textとなっているテキストボックスに「我々はアマゾンの奥地に踏み入った」という文章を入力して、Analyzeのボタンを押します。

すると以下のような解析結果が得られます。

アマゾンがLocation(場所)のエンティティタイプとして抽出されました。

もちろん、CLIなどでも実行できます。

今回は文章として、「アマゾンはワシントン州シアトルに本拠がある」を指定して実行してみます。

aws comprehend batch-detect-entities --text-list アマゾンはワシントン州シアトルに本拠がある --language-code ja

上記コマンドを実行すると、以下のような結果が得られます。

{
    "ResultList": [
        {
            "Index": 0,
            "Entities": [
                {
                    "Score": 0.9488572478294373,
                    "Type": "ORGANIZATION",
                    "Text": "アマゾン",
                    "BeginOffset": 0,
                    "EndOffset": 4
                },
                {
                    "Score": 0.923648476600647,
                    "Type": "LOCATION",
                    "Text": "ワシントン州シアトル",
                    "BeginOffset": 5,
                    "EndOffset": 15
                }
            ]
        }
    ],
    "ErrorList": []
}

今回のアマゾンはORGANIZATION(組織)として認識されています。

このように、Comprehendを利用することで簡単に固有表現抽出を行うことができます。

おまけ

Comprehendをカスタマイズ

便利なComprehendですが、一般的なエンティティは識別できるものの、ドメインによっては不十分な場合があります。そのようなケースのために、Comprehendには固有表現抽出を追加で学習させる機能があります。

学習させるにあたって2つのタイプの学習方法を選べます。

  1. 認識させたい固有表現を含む/含まないテキストデータを用意するとともに、その文のどこにどんな固有表現があるのかを明示したデータ(アノテーションデータ)を用意
  2. 認識させたい固有表現のリストと、その固有表現を使用した/使用していないテキストデータ(未アノテーションデータ)

1の方法は、文章中の固有表現の位置を明示(アノテーション)するので、手間はかかりますが、2のデータよりも正確な認識能力を期待できます。

ただし、残念ながら現時点でComprehendのカスタマイズは日本語には対応していません。今後に期待です。なので、以下は今後Comprehendのカスタマイズに対応した場合に役立つ情報としてご参照ください。英語は対応していますので、以下の情報は英語のモデルをカスタマイズする際にも、もちろん有用なやり方となります。

Amazon SageMaker Ground Truthによるアノテーションの省力化

1,2の方法ともに、データはより多くあれば、学習されたモデルの性能も期待できるものになりますが、特に1の場合は文章中の位置まで情報を付与しなければいけないので、手間がかかります。

そんな時に使えるAWSのサービスが[Amazon SageMaker Ground Truth](Amazon SageMaker Ground Truth | AWS(以下、Ground Truth)です。

教師ありの機械学習を行う際には大量の正解データが必要となりますが、Ground Truthは、それをサポートするサービスです。

画像データの分類や検出、テキストデータの分類などとともに、NER用のアノテーションもサポートしています。

大枠の流れとしては、以下のようになります。

  1. 未アノテーションのデータを用意する
  2. アノテーションを行う要素を定義する
  3. アノテーションを行う主体を指定する
  4. ジョブをアノテーション実行者に割り当てる

ここでは上記のうち2と3が特徴的です。

2についてですが、Ground Truthはインフラストラクチャを気にすることなく、アノテーションのためのGUIを提供します。素で行おうとすると、サーバを起動したり、ユーザを認証したり、アノテーションのGUIや処理ロジックを作成したり、アノテーションデータを保存したり、といった一連の流れを用意しなければいけません。Grountd Truthであれば、どういうデータをどのようにアノテーションさせたいかを指定するだけで、全部面倒をみてくれます。

そして、Ground Truthの面白い点が3です。機械学習に使用するためのアノテーションは人力で行うわけですが、Ground Truthは行う主体を以下の3種類から選べます。

  1. 社内の人間やパートナーなど限られたプライベートメンバ
  2. AWS Marketplace で利用可能なサードパーティベンダ
  3. Amazon Mechanical Turk を利用したクラウドソーシング

面白いのは2,3で、データの機密性やコストなどの問題が許せば、人的リソースもスケーリングすることができるということです。専門性が要求されるようなタスクはその知識を持ったサードパーティのベンダがいればそこに任せるという選択肢も取れます。

Ground Truthの実行画面サンプル

上記は、Ground Truthの画面ですが、このようなインターフェースをGround Truth側が用意してくれるので、タスクを割り当てられたメンバは画面上からポチポチするだけで、NERのデータをアノテーションすることができます。

繰り返しますが、現時点では残念ながらComprehendは日本語のカスタマイズモデルは対応していません。なので、実際にGround TruthとComprehendを組み合わせるとすれば、英語などのカスタマイズモデルを作成する場合に限られます。現時点では、日本語のアノテーションされたデータの利用用途はComprehend以外の言語モデルのトレーニング(例えば、SageMakerで独自のモデルをトレーニングするなど)になってしまいますが、Comprehendが日本語のカスタマイズモデルに対応すれば、あまり自然言語処理知識に詳しくない場合でも一般的でない独自ドメインでもNERが利用できるなど、利用用途が大きく広がると思います。対応が待ち遠しいですね。

終わりに

以上、NERとは何か、NERができると何がうれしいのか、そして、Comprehendを使えば簡単にNERを実施できるということを見てきました。

実際自前で、NERを実装しようとすると、データの準備に始まって形態素解析であったり、単語のトークン化、学習処理など自然言語処理や機械学習の知識を求められます。

一般的な用途であれば、Comprehendを利用することで、お手軽に機械学習のテクノロジーを利用した自然言語処理の恩恵を得ることができます。また、現時点では英語などの一部の言語にはなってしまいますがカスタマイズも可能で、Ground Truthを利用すればデータのアノテーションも、マネージドな形で省力化して実施することができます。

皆様のテキストマイニングライフの一助になれば幸いです。


参考リンク

Amazon Comprehend を使用してカスタムエンティティレコグナイザーを構築する

Developing NER models with Amazon SageMaker Ground Truth and Amazon Comprehend

Amazon Comprehend でサポートされる言語

LPIC-1合格体験記

0

 アピリッツ コンテンツデザイン部の金井と申します。今回はLPIC-1を取得した合格体験記です。

結論から言ってしまえば

 LPIC-1はLinuxの基本を理解した事を示せる資格。

 あずき本問題集買って8割9割の略語やコマンドや重要なパスを理解、暗記したら受かる。

 勉強する過程でLinuxを使う上での操作や技術への理解が深まるので、駆け出しのサーバーエンジニアやインフラエンジニアにお勧めの資格。

甘く煮込まれたりんごをふんだんに使ったアップルパイを食べながら勉強

そもそもLPICって何?

 Linux Professional Instituteという非営利のLinuxおよびオープンソースの認定機関が運営しているLinux技術者の認定資格です。
 Linux Professional Instituteによる認定(Certification)、という事で、LPICっていう名称になります。
 LPIC-1は、その初歩の試験になります。
 AWS認定でいうところのクラウドプラクティショナー、情報処理技術者試験でいう基本情報、くらいの認識で良いと思います。

 但し、クラウドプラクティショナーや基本情報とは違い、LPIC-1を取得するには101試験と102試験の2つに合格しなくてはいけません。
 受験料はそれぞれ税込16500円で、ストレートで合格したとしても33000円掛かります。結構高額ですが、アピリッツでは資格取得における支援があるので、多少は気楽に試験に望めました。

 まあ、要するに。アピリッツでは合格すれば黒字になるって事です。ストレートであれば。

そのLinuxって何?

 端的に言ってしまえばOSの一つです。日常的に触るPCで最も台頭しているOSはWindowsですが、そのWindowsでネットサーフィンやネットゲームやらをする時に裏側で稼働しているシステムを動かしているOSは、大半がWindowsではなくLinux、またそれから派生したシステムなのではないかと思います。
 サーバーエンジニアやインフラエンジニアとして働く上では十中八九このLinuxの上で色々構築する事になる、と言っても良いでしょう。

 さて、それではそのLPIC-1を取得する為にどういう風に勉強したかを書いていきます。

ぶっちゃっけ値段の割にはそこまで量のないサンドイッチを食べながら勉強

勉強方法と勉強期間

 まず、前提として。
 自分はサーバーエンジニア5年目で、少なからずAWSを使ってのインフラ構築やゲームサーバーの開発、運用経験があります。
 そこからの勉強だったので、LPICの勉強において、多少は理解している部分もありました。
 ……本当に多少でしたけれど。

 そして、勉強期間は101試験と102試験で合計4ヶ月と少しってところです。それぞれ2ヶ月くらいの期間を設けて受験しました。

 受験体験記とかのブログを見てみると1週間だとか10日間だとかで合格したというものもちらほら見受けられますが、
 自分には平日の仕事の前後に勉強もしっかりしたりだとか、休日を勉強漬けにしたりだとか、そこまでの気概はなかったので。
 土日にカフェでコーヒーやケーキを飲んだり食べたりしながら1~2時間程度あずき本問題集を読んでいました。

 ぶっちゃけ、自分がした事はほぼほぼそれだけです。
 加えてネット上に転がっている問題集を多少解いたりだとか、時々自宅PCのMacでTerminalを開いてコマンド叩いてみたりだとかしましたが、上の2冊を何度も読み込んで問題を8割9割解けるようになれば、満点は取れないものの、合格する分には十分でした。
 実際、得点率はそれぞれ80%程度だったと思います。
 因みに、MacのTerminalでは動かないコマンドが多かったです。ちゃんと色々叩いてみるなら、やっぱりLinuxの仮想環境を入れたりしないと駄目ですね。

苦労した点

 休日に1~2時間、参考書や問題集を読んでいただけで合格までこぎつけたとはいえ、苦労した点も幾つかあります。

 これまで業務をしていて、何となくで内実をしっかりと理解せずに使っていたコマンドやプロトコルなどの技術に関する勉強は、確かに業務に紐付くものとなりました。
 しかしLPICの為の勉強は、Linuxの歴史を学ぶ、というような側面もあるようなものです。
 要するに、今では新しい技術に刷新されていたりするものや、GUIでの操作で基本済んでしまうものや、これからも業務ではほぼほぼ使わないような知識やらもちゃんと頭に叩き込まないといけなかったりします。
 例えばディスプレイ関連の知識だったり、プリンターの操作コマンドだったり。他にも、今更シェルで正規表現やらコマンドやらをたっぷりと使ったツールを開発したとしても、基本黒魔術として扱われてしまうでしょう。
 そういう点では、実用性だけを求めて勉強しようとしてしまうと碌に頭に入らないものも出てきてしまいます。

例:

  • どうしてそれぞれのコマンドで同じオプション処理をさせる文字が違うんですか!!?? ……オープンソースだから、色んな人が色んな風に作ったんだろうなぁ……。
  • awkとsedとcutとtrがこんがらがった! 正規表現は……使わないで済むなら使わずに済ませたいです……。
  • RDPとSPICEとXDMCPって何が違うんだっけ? ディスプレイ操作なんてこれから使う事あるか?
  • lpとlprでオプションが違うけど、何が何だっけ? プリンター操作、これからコマンドでやる必要性なんて出てくるかなぁ……?
  • /etc/resolv.confって何だよ! eはどこいった! eだけを略したのか? いや、リゾルバーだからerか? どっちにせよたった2文字だぞ!? i18nを見習え!

 まあ、ちゃんと自分が興味を持てるように、記憶として定着しやすいように、読むだけでもちゃんと工夫しましょうねって話です。

合格して良かった点

 サーバーエンジニア5年目でも、<stdio.h>はおまじないと同レベルの認識でしかなかった操作だったりは多少なりともあって。
 そういう部分が少なからず裏付けされた知識になった事に関しては、良い進展だったと思います。
 ただ、それでも5年目なので、業務で使う事のある部分に関しては8割方は習得済みのものだったりして。
 勉強としてやるなら、もっと早くにやった方が良い事があったかなー、という印象でした。

合格した後にご褒美と称しながらダイエットを決意するパフェ
合格して悪かった点

 コロナ禍でリモートメインだったのもあって、それにカフェでケーキとか食べ過ぎて太った。

【ゴエクロデザインについて語ろう】その2:プロの作業環境とメイキング動画を公開します!

0

アピリッツのオンラインゲーム『ゴエティアクロス(ゴエクロ)』のデザインをもっと知ってもらいたい!ということで始まったゴエクロデザイン連載。第二回は、2020年9月に登場した「暁天書エル」のデザインから現在にいたるまでゴエクロのキャラクターデザインで活躍中のイラストレーター”enomi”氏に話を聞きました。作業環境のこと、デザインに込めたもの、存分に語ってもらいます! (取材 2021年12月)

作業環境はこんな感じ!

私がふだんデザインで使用している機材は次のようなものです。

PC:TSUKUMO BTOPC
ディスプレイ:EIZO FlexScan EV2450-BKR 23.8インチ

目が疲れにくく、発色もいいのでモニターはずっとEIZOのものを使っています。
高さや角度調整も細かくできるので便利!

液晶タブレット:Cintiq 13HD DTK-1300/K0

学生のときから使っている液晶ペンタブレットです。コンパクトで小回りが効くので、紙に近い感覚で描けて使いやすいんです。

「雪華輝晶グレモリ」メイキング

ゴエティアクロスで12月より登場している魔神「雪華輝晶グレモリ」はenomi氏がデザインしました。そのメイキング動画をアピスピ用に提供してもらいました! いろんな工程をへて生まれる「 雪華輝晶グレモリ 」、かわいいです!

「雪華輝晶グレモリ」はこんな思いを込めて描きました

メイキングとあわせて、「雪華輝晶グレモリ」のデザインについてenomi氏が込めた思いやコンセプトを語ってもらいます。

まず衣装についてお話しますね。「雪華輝晶グレモリ」は、現代のクリスマスデートをコンセプトに制作を依頼されました。「現代の」ということで、衣装デザインも過去に描かせいただいたものよりも、より現実世界に即したデザインに仕上げました。

それでハイネックのリブニットなんですね!

そうです。デートと言っても、あまりカッチリした衣装ではなく「私服感」を大事にして、より身近にグレモリを感じてもらえるようにしました。

街にいそう~。構図も「こっちに来て!」って感じで、優しい雰囲気ですよね。

はい。グレモリはお姉さんタイプのキャラクターなので、デートでも優しくエスコートしてくれそうだなと思いました。なので、ユーザーへ手を差し伸べている構図にしました。リアルにキャラクターと交流を楽しんでもらえるように心がけました。

あと、腕にも注目してもらいたいですね。今回、あえて異形化した腕をユーザー側に差し伸べています。これってグレモリが相手を信頼しているからこそできることだと思うんです。ですから、この構図からユーザーとグレモリの強い信頼関係や、心を開いているさまを感じてほしいなと考えました。

じーん。

実際、ユーザーでもそう感じ取ってくれている方がいて、うれしかったです。

デザイナーの思いがユーザーに伝わったんですね。よかった~!

第三弾もお楽しみに!

シリーズ企画「ゴエクロデザイン」を語ろう、今回はenomi氏の作業環境と「雪華輝晶グレモリ」への思いについてお伝えしました。今後もメイキング動画をご紹介していきます。どうぞお楽しみに~!

今までの連載記事はこちら!

 【ゴエクロデザインについて語ろう】その1:ゴエティアクロス「第3回 衣装デザインコンテスト」開催中

【荒木さんおめでとう!】荒木 愛、『なでしこグランプリ2021』準優勝!

0

アピリッツが誇る日本一のアマチュアポケットビリヤード選手・荒木さんが、先日開催されたオープン戦『なでしこグランプリ2021』にて準優勝しました。こちらの大会は、社内のビリヤード通いわく「プロメインのバリバリのオープン戦。そこでの準優勝は、昨年の女流球聖タイトル獲得と同等かそれ以上の偉業」なのだそう。すごい。やっぱ荒木さん強い。ということで、ご紹介します!(取材 2021年11月)

―― 荒木さん、準優勝おめでとうございます。感想を一言ください。

コロナの影響で約1年半ぶりに開催されたオープン戦で入賞できて嬉しいです!決勝は負けてしまい悔しかったですが……!

むかって右から二番目が荒木さん!(引用:Billiards Days.com )

―― 前回荒木さんにビリヤードのことをインタビューしたとき「毎日ビリヤードを練習してる。コロナでお店が閉まっているときは苦労した」と言っていましたよね。新型コロナが少し収束しつつありますが、練習に変化はありましたか?

しばらくはビリヤード場も時間短縮営業になっていましたし、思うように練習できない期間が続いていました。

ですが、最近はやっと平常営業に戻りました。アピリッツもフルリモートから出社比率を上げて勤務体制が変わってきましたし、おかげで以前のように仕事終わりに練習ができるようになりました!

―― エンパワーメントサービス部での仕事のあと、ビリヤードの練習!

はい。ビリヤード場が近いオフィスっていいですよ! どっちも頑張れる。ということで、これからは大会も徐々に再開されていくはずです。また優勝を目指して頑張りたいと思います!

―― 応援してます!

前回の荒木さんのインタビューもぜひ読んでください! ビリヤードのこと、そしてアピリッツのエンパワーメントサービス部でのお仕事について沢山お話ししています。【祝! 日本一】第12期 女流球聖位 荒木 愛 インタビュー【ビリヤードと仕事の話をします!】

↓ 当日の試合の様子の一部です。

2022年 新卒内定者顔合わせ会やりました

0

アピリッツの新卒内定者顔合わせ会は、2019年以降、オンラインとオフラインの同時開催となっています。内定式のリアル開催を見送った分、少しでも新入社員同士がコミュニケーションをとれる場となれば……という意図のもと、人事企画部が毎年アピリッツにまつわるクイズやグループワークを考えて実施しています。今年もやりましたよ! サクッとご紹介します。(取材 2021年11月)

今年は新オフィスでやりました

今年の内定者顔合わせ会は、2月に増床した新オフィスの会議室とカフェスペースでおこないました。ちなみに、この新オフィスの内装は2020年に新卒入社した若手社員がデザインしました。

オンライン参加しているメンバーも、モニター越しにディスカッションをおこないました

アピリッツにまつわるクイズのあとは、Webソリューションセグメントの内定者とオンラインゲームセグメントの内定者の混合チームでグループワークに取り組みます。今回のテーマは「会社を擬人化して自己紹介を作ってみよう」でした。クイズやグループワークには、アピリッツについてもっと知ってもらいたい、あと愛着も持ってもらいたい! という狙いがあったそうです。

デザイナー職の内定者がどんどん絵を描いていました。かわいい
卓球台も活用しました

オフィスの様子を見てもらうための社内見学ツアーも実施しました。人事がオフィスにカメラを持ち込んで生配信します。オフィスにいる社員が手を振ってくれるのが恒例行事となっています。

顔合わせ会のあと、一部のメンバーがオフィスのリフレッシュスペースに残ってボードゲームで遊んだそうです。さっそくオフィスを活用してくれてうれしい!

ということで、4月の入社までまだ少し時間がありますが、みなさんと一緒に働ける日を楽しみにしています。

Amazon QuickSightでゲームデータを分析したい

0

我が家のおうさぎ様がルンバをいじめて困っています。ゲームデザイン(GD)部クライアントエンジニアの中村です。

先日「AWS Certified Data Analytics – Specialty」に合格しました。この試験では、AWSのサービスを活用したデータ分析ソリューションの設計、構築、運用、保守の知識があると認定されます。さっそくこの知識を活かしていきたい所存でありますが、まずはダミーデータを使用してAmazon QuickSightでデータ分析をしてみたいと思います。

Amazon QuickSightとは

クラウド向けスケーラブルでサーバーレス、組み込み可能な ML ベースの BI サービス

https://aws.amazon.com/jp/quicksight/
引用:https://aws.amazon.com/jp/quicksight/

Amazon QuickSightAmazon AthenaAmazon Redshift、その他データベースなどからデータを取得し、グラフ化できる分析基盤です。インタラクティブなダッシュボードを素早く簡単に構築することができます。データを視覚化することで様々な情報の関係を分析し、ビジネスを向上させることができます。

サーバーレスであるため、サーバーのプロビジョニングやインフラ管理も不要です。分析対象のデータさえ用意すれば簡単に視覚化できます。

さらに機械学習を利用してデータの異常検知や予測を行うことができます。

ダミーデータを用意

ゲームアプリケーションではユーザーが行った様々な行動をログとして出力しています。このユーザー行動ログを分析することで、ユーザーがこのゲームの何に関心を持っているのか、人気のあるキャラクターは誰か、難易度は適切であるか、などを分析することができます。

このユーザー行動ログを収集するためにはAmazon Kinesis Data StreamsAmazon Kinesis Data Firehoseなどを利用することになりますが、今回はデータの抽出を割愛し「CSV形式のユーザー行動ログがAmazon S3に保管されている」状態から始めます。

さっそくソーシャルゲームを題材として、以下のような「キャラクター獲得ログ」のダミーデータをCSV形式で10,000件生成しました。このデータを視覚化します。

ユーザーIDキャラクター名レア度獲得場所獲得日時
28織田信長1gacha2021-11-08 01:09:14
14前田利家1shop2021-02-22 05:25:10
45羽柴秀吉1gacha2021-10-07 20:02:24
キャラクター獲得ログ(ダミー)

Amazon QuickSightでデータの視覚化

まずは簡単に「キャラクター別被獲得数」を表示してみました。

視覚化で棒グラフを選択し、フィールドウェルにnameフィールドをドラッグアンドドロップするだけで以下の画像のようなグラフを作成することができます。(ランダムなダミーデータですが)織田信長が多くのユーザーに獲得されているようですね。

キャラクター別被獲得数

キャラクター別にどの程度獲得されているかがわかったので、その割合を知るために円グラフを生成します。円グラフではすべての情報を表示することはなく、少ない獲得数のキャラクターはOtherにまとめます。これによって以下のようなグラフが出来上がりました。被獲得数TOP4のキャラクターだけで70%近くを占めていることがわかります。

キャラクター別被獲得数TOP4割合

さて、このグラフだけでキャラクター人気を知ることができるでしょうか?

ソーシャルゲームではガチャなどのランダムな獲得方法でキャラクターを手に入れた場合、それは人気であるとは言えません。今回のダミーデータでは獲得場所フィールドを用意しているため、ショップでの獲得に限定したグラフを作れば、ユーザーがわざわざショップで手に入れた人気なキャラクターがわかるでしょう。

そのためにこの円グラフにフィルターを付けました。獲得場所フィールド(source)をshopに限定したグラフが以下です。これを見ると、被獲得数TOP4のキャラクターである織田信長や羽柴秀吉などは表示されていません。つまり、Shopで購入された人気なキャラクターは異なっているということがわかります。

QuickSightではこうしたフィルターを数クリックで簡単に適用できます。

キャラクター別被獲得数TOP4割合 フィルタsource=shop

続いて視覚化ではよく見る時系列折れ線グラフを作成します。

今回のダミーデータでは獲得日時のフィールドがあるので、時系列で変化する獲得件数のグラフを作成しました。ここでは集計単位を”月”にしていますが、簡単に日、週、月、四半期、年の集計単位を切り替えることができます。期間が短い場合は日、週で集計すると見やすいですが、期間が長くなると月や年での集計が見やすくなります。

時系列件数

さらに、QuickSightの特徴の1つである「機械学習による予測」を追加します。この予測も、設定画面から「予測を追加」をクリックするだけで以下の図のようなオレンジのラインを簡単に追加できます。

集計されたデータが時系列である場合、今後どのように推移するかは把握しておきたいところだと思います。そのため折れ線グラフを作成したらとりあえず予測を追加しておくと良いでしょう。

時系列件数(予測)

最後にパラメータと計算フィールドを試してみます。

パラメータはQuickSightの可視化をする上で、用意されたデータとは別に利用したい数値や文字列を指定します。今回はキャラクター名をドロップダウンリストにして、特定のキャラクターを選択する機能を追加します。

パラメータの追加も簡単で、「新しいパラメータを追加」から名前とデータタイプを指定するだけです。

そしてこのパラメータをどのように操作するか定義するために「コントロールを追加」します。ここではキャラクター名をドロップダウンで選択させたいのでデータセットからnameフィールドを選択しました。

新しいパラメータを作成
コントロールを追加

これでQuickSight上でキャラクター名を選択するドロップダウンを表示できました。非常に簡単です。

キャラクター名コントロール

続いて、計算フィールドは用意されたデータのフィールドとパラメータを組み合わせて、QuickSight上で新しいフィールドを用意する機能です。今回は選択したキャラクター名に該当するレコードにフラグを立てていきます。その場合計算フィールドとして以下のようなコードを記述します。

nameフィールドがパラメータCharaNameと一致する場合に1とする、そうでない場合0とする、新しいIsSelectCharaフィールドを定義しました。

ifelse(name=${CharaName}, 1, 0)

これを追加したことにより、ダミーデータは以下のようになります。こうして計算フィールドを追加することにより、用意されたデータをさらに充実させることができます。

ユーザーIDキャラクター名レア度獲得場所獲得日時(New)IsSelectChara
28織田信長1gacha2021-11-08 01:09:140
14前田利家1shop2021-02-22 05:25:101
45羽柴秀吉1gacha2021-10-07 20:02:240
キャラクター獲得ログIsSelectChara追加

この新しいフィールドを利用して、「選択したキャラクターのレア度別獲得場所」をグラフにしました。

横軸をIsSelectCharaの合計、縦軸をレア度、色分けグループをsourceにすることで、選択したキャラクターがどこから獲得されたか、レア度別に知ることができます。グラフタイトルは <<$CharaName>> を利用することで選択したキャラクター名を表示させています。

このように、パラメータ、計算フィールド、コントロールを駆使することでデータを充実させ、様々な分析が可能となります。事前にどのようなデータ追加を行うか決めておけば、その労力は決して大きくありません。

榊原康政のレア度別獲得場所積み上げ
池田恒興のレア度別獲得場所積み上げ

これらの用意したグラフをダッシュボードに公開すれば、プロジェクト内外の関係者とともにデータを見ながらユーザーの動向を分析することができるようになります。

QuickSightダッシュボード

こういった分析は収集するデータや表示するグラフを事前に取り決めておかなければならないため、難易度が高くなります。しかしそんな中でもデータさえ収集してしまえば簡単に可視化できるツールとして非常に良いのではないかと思います。

是非担当案件にも取り入れていきたい所存であります。

AWS認定取得への道 CloudPractitioner編[その2]開催しました

0

新型NintendoSwitchの抽選に当たりません。ゲームデザイン(GD)部クライアントエンジニアの中村です。

先日「AWS認定取得への道 CloudPractitioner編[その1]開催しました」こちらの記事で認定取得のために勉強会を開催したことを報告しました。今回、その2を開催したので報告いたします。AWS勉強会としては通算第四回となります。

今回のお品書きは以下でした。

  • AWSの主要サービス
    • アプリケーション統合
    • アナリティクス
    • ディベロッパーツール
  • AWS操作の種類
  • ネットワーク
  • セキュリティとコンプライアンス
  • 管理・モニタリング・ガバナンス
  • サンプル問題を解きつつその解説

まず、前回から引き続いてAWSの主要サービスに関するお話となりました。初めに「アプリケーション統合」サービスとしてSNSとSQSについておおまかな説明を行いました。

Simple Notification Service

AWSの主要サービスである「アナリティクス」ではBIダッシュボードのQuickSightを紹介し、サーバーレスクエリのためのAthenaと、データ収集分析を行なうKinesisについて解説しました。

Kinesisを組み合わせてデータ分析をする

AWSの主要サービスである「デベロッパーツール」について、CodeCommit、CodeBuild、CodeDeployを紹介し、これらを個別に利用するのではなくCodePipelineで一元管理する必要があることを解説しました。

CodePipeline

「AWS操作の種類」としてマネジメントコンソール、SDK、API、CLIを紹介しました。

AWS SDK

「ネットワーク」の項目では、AWSの基本知識であるVPCとSubnetについて基礎を解説しました。さらにRoute53、DirectConnect、CloudFrontを紹介し、それぞれ何ができるかを解説しました。

PublicSubnetとPrivateSubnet

「管理、モニタリング、ガバナンス」の項目では、CloudWatch、CloudTrail、Config、Organizations、TrustedAdvisor、SecretsManager、SystemsManagerを簡単に紹介しました。これらについては普段の業務でも触れることが多いためある程度認識はされていたと思われます。

「セキュリティとコンプライアンス」の項目では、AWSを利用する上でセキュリティが重要となるため少し長めに解説を行いました。特にIAMは誤った設定を行うと危険であるため、MFAの重要性も説明しました。その他試験で頻出と思われる責任共有モデルや、WAF、Cognito、GuardDutyを紹介しました。

これらのサービスを解説した後、最後に8問のサンプル問題を用意し各々に解答させ正解を解説する流れを行いました。サンプル問題を解いていく中では、参加者はかなり内容を理解できていたのではないかと思われます。

2回に渡ってCloudPractitioner自体に関するキーワードと用語の解説を行いましたので、もう少し自ら深堀りすることで十分認定試験に合格できるところまで来たと思います。

私はこれからも引き続き各員の認定試験をサポートしていきたいと思います。

【ゴエクロデザインについて語ろう】その1:ゴエティアクロス「第3回 衣装デザインコンテスト」開催中

0

アピリッツのオンラインゲーム『ゴエティアクロス(ゴエクロ)』では現在「衣装デザインコンテスト」を開催中です。受賞作品はゴエティアクロス内でユニットとして実装されます。(また、ペンタブレットやアマゾンギフト券といった賞品も用意されています!)
今回で3回目の開催となるこのコンテスト開催を記念して、全3回の「ゴエクロデザインについて」の連載を行います! 第1回である今回は、アピリッツのリードデザイナーである飯山と、デザイナーの白岩がキャラクターデザインのフローを語ります。(2021年11月取材)

キャラクターの魅力や価値を知ってほしい!

― 「衣装デザインコンテスト」は今回で3回目です。このコンテストを立ち上げたのは飯山さんとのことですが、始まったいきさつを教えてください。

飯山:いくつか理由があります。まずは、ユーザーのみなさん同士でワイワイ盛り上がるようなキャンペーンがあるといいなと思いました。

そして、キャラクターにもっと興味を持ってもらえるといいなと……。ゲームを遊んでくださったユーザーのみなさんが手に入れたキャラクターたちは、世に出るまでにいろんなプロセスを経ています。どうやって作られたのかをもっと知っていただけると、より愛着を持って楽しくプレイしていただけるかなと考えました。

せっかくユーザーの皆さんの手元に届くキャラクターですから、目いっぱい好きになってほしい。その為に、プロセスの一部である「キャラクターデザイン」という部分を、ユーザーの皆さんと共有してみたいと思いました。

あとは、単純に私がやってみたかったんです(笑) 私がユーザーの立場だったら、自分の作った魔神のデザインがゲームに出てきたらうれしいなって思いました。

白岩:応募していただいた作品は開発メンバー全員で拝見しています。ゴエクロはこれからも新しい風をどんどん取り入れていきたいですし「ああこんな魅せ方があるのだな」とユーザーのみなさんに教えていただくことも沢山あります

―― 「応募があるかな」って緊張しましたか?

飯山:最初はドキドキしました! 「応募が全然なかったらどうしよう……?」って。でも、反応をたくさんいただけてうれしかったです。毎回応募してくださる方もいるんですよ。

入賞するのはどんなデザイン?

―― 応募作品の選考風景ってどんな感じでしょう?

白岩:まず開発メンバー全員で「いいな」「かわいいな」と思った作品を選びます。そしてデザイナーチーム側で実際にゲーム内で実装したときの見栄えなどを考えながら、ゴエクロの世界観に相応しいものに絞って決定しています。

―― 「実装したときの見栄え」というと……

白岩:実は、4頭身のデフォルメのイラストだとかわいいのに、ゲームの6~7頭身くらいになると急に印象が変わることってよくあるんです。デフォルメキャラの状態だと装飾がいっぱいあって華やかに見えたけど、本来の頭身で描くと間延びしてスカスカに見えてあんまり可愛くなくなってしまったり……。

飯山:そのこともあり、今回から応募のテンプレートの頭身を変更しました。よりゲーム内の姿をイメージしていただきやすくなったかなと思います。

―― ずばり、入賞のコツを教えて下さい。

飯山:キャラクターへの愛や設定に対するリスペクトが感じられるとうれしいです。

白岩:独自の世界観を持ちつつも、ある程度は世界観との整合性がとれていると、開発メンバーもユーザーの皆さんも親しめるキャラクターになるかなと思います。たとえば「盗むのが得意なキャラクター」なら、「ゴエクロの世界にあるどんな物をこの子は盗むんだろう?」など、空想を広げながら描いてみてください。

―― 受賞デザインはゲームに実装されて、その作者さんにプレゼントされるんですよね。

白岩:はい。「こんな細かいところまでゲームで再現してくれてうれしい!」という感想をいただくと「やってよかったな」って思います

飯山:ユーザーのみなさんに喜んでいただきたいなと思って始めた企画なので、私達もうれしいんですよね。

デザインに合わせてストーリーが変わることも

―― 実際の開発現場ではどんなふうにキャラクターが生まれていますか?

白岩:いろんなパターンがあります! イラストレーターに全てお任せして上がってきたものをデザインリーダーの飯山がフィードバックをおこなうケースだと、エンジニアやプランナーも混ざってワイワイ盛り上がります。

飯山:盛り上がりますね~。私からのフィードバックは「もうちょっと〇〇をこうしたら、もっと魅力的になるよ」「もうすこし〇〇を足していくことでゴエクロっぽさを出したいね」といった感じです。参考資料なども示して、修正の方向性を決めます。

―― 今までボツになったデザインってありますか……?

飯山:もちろんありますが、ボツは忘れます! しいて言うなら、没にするよりもそこから練り込んでいって商品化に耐えられるクオリティまで再構築してもらうことが多いです。

白岩:ラフの段階でバッチリ描いていただいているデザインが多いですからね。

―― ストーリーや企画ありきでデザインをすることもありますか?

白岩:もちろんあります。プランナーから上がってきた資料をもとにデザイナーが絵を起こします。プランナーさんがそのキャラに拘りを持っている場合は、ラフの段階で何度もやり取りをします。

飯山:逆にキャラクターの属性と武器の情報だけを先に教えてもらって、そこからデザイナーが「今回はハロウィンで行きましょう!」とプランナーに打診することもあります。その後、デザインをイラストレーターが決めて、そのデザインをベースにシナリオ執筆が始まることもありますね。

こんな感じでゴエクロの開発チームはそれぞれの役割があまり分断されていないんですよね。だから仕事の手が空いて暇になった人がいたら、その人が決まっていないものを着手していくことが多いです。

デザイナー側から「そのキャラクターなら、この属性じゃないほうがよいのでは?」と提案することもあります。ゲームの根幹の大切なところは、メンバー全員で話すことが多いのでデザイナーもゲームを作っている手応えを得られると思います。

ご応募お待ちしています!

―― 最後に「衣装デザインコンテスト」の宣伝を!

白岩:11/30(火)23時59分までです! ふるってご応募ください

飯山:キャラクターコンテスト以外にもゴエクロのデザインに親しんでもらうための企画を準備中ですので、どうかこれからもご注目いただけるとうれしいです。ということで、次回はイラストレーターのenomiさんの制作現場を取材させていただきます! メイキングもあるとかないとか……。どうぞお楽しみに!

AWS認定取得への道 CloudPractitioner編[その1]開催しました

0

秋を飛ばして冬がやってきてしまいましたね。エアロバイクで日々身体を温めています。ゲームデザイン(GD)部クライアントエンジニアの中村です。

我々GD部では7月から私主催のもとAWSに触れる人員を増やすために講座を開催してきました。

第1回は7月に「EC2+ALB+Route53」のハンズオンを行い、基礎的なサーバ構成を体験しました。

第2回は9月に「S3+Lambda+APIGateway+DynamoDB+Cognito」のハンズオンを行い、サーバレスアプリケーションを構築しました。

もともとGD部の知識向上を目的としていましたが、部の垣根を超えて徐々に多くの参加者が集まるようになりました。

そして今回、第3回として10月22日に「AWS認定取得への道 CloudPractitioner編[その1]」を開催しましたので報告いたします。GD部に限らず、CD部、AG部、ES部、XD部、CI部からも参加者が集まりました。

2021年10月現在で、AWS認定は11種類存在しています。これらの認定を取得することで、AWSクラウドに対する知識、スキルを持つことが認められます。

その中でも「AWS Certified Cloud Practitioner」は入門であり、クラウドへの理解と基礎的な AWS の知識が認定されます。そのため、まずこの認定を取得することを目標としました。しかしながら、認定を取得することがゴールではなく、そこで得た知識を業務に活かすことが重要なので、その点を意識させていきたい所存です。

今回の講座でも、私の方で以下のお品書きに沿って資料を作成しプレゼンテーションを行いました。

  • 認定試験の概要
  • サーバとクラウドとAWS
  • グローバルインフラと耐障害性
  • AWSの主要サービス
    • コンピューティング
    • ストレージ
    • データベース

「認定の概要」ではAWS認定にはどのような種類があって何を求められるのかを解説しました。

講座スライド資料より抜粋

「サーバとクラウドとAWS」ではオンプレサーバ、従来型データセンター、AWSクラウドの違いを解説し、なぜクラウドを選択するのかについて説明しました。

講座スライド資料より抜粋

「グローバルインフラと耐障害性」ではAWSクラウドのリージョン、アベイラビリティゾーンについて解説し、サーバ運用上の可用性と耐障害性を説明しました。

講座スライド資料より抜粋

「AWSの主要サービス」ではコンピューティングリソースのEC2とAutoScaling+ALBでのWebサービス構造の基礎知識、サーバレスのLambda、ECS、ElasticBeanstalk、Lightsailについて解説しました。

講座スライド資料より抜粋

次回、「AWS認定取得への道 CloudPractitioner編[その2]」として残りの基礎知識を解説します。その際はまた新たな記事で報告いたします。

Amazon SageMakerを利用した効率的な機械学習 with Rust

0

はじめに

デジタルイノベーション部の浅田です。

クラウドを利用した開発を行うにあたって、クラウドを上手く利用しようとすればするほど、ローカル開発環境と本番環境(クラウド環境)とでの実装方法の差分を少なくすることが効率的に開発を行う上で重要になってきます。

例えば、Amazon DynamoDBを利用してサービスを開発しようとすると、ローカル開発環境でどのように開発を進めるか?という課題が生まれます。DynamoDBであれば、ローカルのエミュレータが提供されているので、それを利用するという解決策が考えられます。

機械学習においても、ローカル開発環境と本番環境とのやり方を統一できたほうが、効率的に開発ができます。

その一つのやり方が、Amazon SageMaker(以下SageMaker)を利用することで、ローカル環境と本番環境とで差分の少ない、統一的な方法で開発することです。

また、機械学習においては学習処理と推論処理とが存在し、学習処理で作成した機械学習モデルを推論処理で利用するといったことが行われますが、SageMakerを利用することで、言語やフレームワークに依存しない形でそれぞれの処理を連携させることができます。

そこで、今回はRustでの機械学習をSageMakerで行う例を通して、

  • ローカル環境と本番環境とで統一的な方法で開発できる
  • 言語やフレームワークに依存しない方法で学習処理や推論処理の連携ができる

ということをご紹介したいと思います。

SageMakerでの4つの学習/推論処理パターン

SageMakerで機械学習モデルを学習するにあたって、大きく分けると4パターンあります。

  1. Auto Pilotを使って、完全にSageMakerに任せる
  2. 組み込みアルゴリズムやJumpStartを利用して用意されているアルゴリズムを選んで利用
  3. 組み込みのフレームワーク(Tensorflow, Pytorch, XGBoost, etc.)を利用
  4. 実行環境やコードをDockerイメージで用意

今回は4つ目のパターンになります。実行環境をDockerイメージにすることで、SageMakerに用意されていないような言語、フレームワークを利用して学習、および推論を行うことができます。

今回はRustでSmartCoreというフレームワークを利用して学習、および推論を行います。そして、それはRust & SmartCoreに限った方法ではないので、他の言語、フレームワークにも応用が利く方法になります。

Rust With SmartCoreでの学習処理

SmartCoreはRustで実装された機械学習フレームワークになります。Pythonの機械学習フレームワークであるscikit-learnと似たライブラリになっているので、scikit-learnを使いなれた方には、なじみやすいフレームワークとなっています。

以下が、SmartCoreを利用した学習処理のコードです。

use ndarray::prelude::*;
use ndarray::{Array, OwnedRepr};
use ndarray_csv::Array2Reader;
use smartcore::linear::logistic_regression::LogisticRegression;
use smartcore::metrics::accuracy;
use smartcore::model_selection::train_test_split;
use std::error::Error;
use std::fs::File;
use std::io::prelude::*;

const DATA_PATH: &str = "/opt/ml/input/data/training/iris.data";
const MODEL_PATH: &str = "/opt/ml/model/lr.model";

// CSVの読み込み
fn read_csv_to_array2() -> Array2<String> {
    let mut rdr = csv::ReaderBuilder::new()
        .has_headers(false)
        .from_path(DATA_PATH).expect("Can not read csv.");
    rdr.deserialize_array2_dynamic().unwrap()
}

// 特徴量のデータを取得
fn get_features(data :&Array2<String>) -> ArrayBase<OwnedRepr<f32>, Dim<[usize; 2]>> {
    let input = data.slice(s![.., 0..4]);
    let mut vec_x: Vec<f32> = Vec::new();
    for i in input.iter() {
        vec_x.push(i.parse().unwrap());
    }
    Array::from_shape_vec( (data.nrows(), 4), vec_x ).unwrap()
}

// 正解ラベルのデータを取得
fn get_target(data :&Array2<String>) -> ArrayBase<OwnedRepr<f32>, Dim<[usize; 1]> > {
    let target = data.slice(s![.., 4]);
    let mut vec_y: Vec<f32> = Vec::new();
    for t in target.iter() {
        let t_f = match t.as_str() {
            "Iris-setosa" => 0.,
            "Iris-versicolor" => 1.,
            "Iris-virginica" => 2.,
            _ => 0.,
        };
        vec_y.push(t_f);
    }
    Array::from_shape_vec(data.nrows(), vec_y).unwrap()
}

// 学習済みモデルを保存
fn save_model(model: &LogisticRegression<f32, ArrayBase<OwnedRepr<f32>, Dim<[usize; 2]>>>) -> Result<(), Box<dyn Error>> {
    let model_bytes = bincode::serialize(&model).expect("Can not serialize the model");
    File::create(MODEL_PATH)
        .and_then(|mut f| f.write_all(&model_bytes))
        .expect("Can not persist model");
    Ok( () )
}

// メイン処理
fn main() -> Result<(), Box<dyn Error>> {
    let data = read_csv_to_array2();
    let (x, y) = (get_features(&data), get_target(&data));
    let (x_train, x_test, y_train, y_test) = train_test_split(&x, &y, 0.3, true);
    let model = LogisticRegression::fit(&x_train, &y_train, Default::default()).unwrap();
    let y_hat = model.predict(&x_test).unwrap();
    println!("accuracy: {}", accuracy(&y_test, &y_hat));
    save_model(&model)
}

ここでは、ロジスティック回帰による分類タスクを実装しています。学習データは、UCI Machine Learning Repository: Iris Data Setを利用させていただきました。

SageMakerで学習処理を行うにあたって重要な点は2点です。

  1. 入力データは/opt/ml/input/data/training/配下にSageMakerによって格納されます。後に示すように、SageMakerではローカルのファイルや、S3上のファイルを学習データとして指定することができますが、SageMakerが学習処理コンテナ上の/opt/ml/input/data/training/に配置してくれるので、学習処理側ではファイルがどう指定されるかを気にする必要はありません。
  2. 学習したモデルを/opt/ml/model/配下に保存します。学習処理はコンテナ上で行われるので、学習したモデルは推論処理のためにコンテナ外に退避する必要があります。それはローカルであったり、S3であったりするのですが、学習処理側としては/opt/ml/model/配下に置いておけば、SageMakerがあとは保存の面倒を見てくれます。

Rust With actix-webでの推論処理

次は推論処理になります。SageMakerで推論処理のエンドポイントを立ち上げるにあたって、いくつかの条件を満たす必要がありますが、その一つにHTTPアクセスのインターフェースを実装する必要があります。早い話がWebアプリケーションを用意する必要があるということです。

なので、今回はactix-webというRustのWebアプリケーションフレームワークを利用します。

以下が、actix-webを利用した推論処理のコードになります。

use actix_web::{guard, web, App, HttpResponse, HttpServer, Responder};
use lazy_static::lazy_static;
use ndarray::prelude::*;
use ndarray::{Array, OwnedRepr};
use serde::Serialize;
use smartcore::linear::logistic_regression::LogisticRegression;
use std::fs::File;
use std::io::prelude::*;
use std::str;

const MODEL_PATH: &str = "/opt/ml/model/lr.model";

// レスポンスJSON用構造体
#[derive(Serialize)]
struct PredictResult {
    predicted: i32,
}

// 学習済みモデルのロード
lazy_static! {
    static ref MODEL: LogisticRegression<f32, ArrayBase<OwnedRepr<f32>, Dim<[usize; 2]>>> = {
        let mut buf: Vec<u8> = Vec::new();
        File::open(MODEL_PATH)
            .and_then(|mut f| f.read_to_end(&mut buf))
            .expect("Can not load model");
        bincode::deserialize(&buf).expect("Can not deserialize the model")
    };
}

// ヘルスチェック用
async fn ping() -> impl Responder {
    HttpResponse::Ok()
}

// 推論処理用
async fn invocations(body: web::Bytes) -> impl Responder {
    let csv = str::from_utf8(&body).unwrap();
    let v: Vec<f32> = csv
        .split(',')
        .map(|s| s.parse().expect("not floating number!"))
        .collect();
    let x = Array::from_shape_vec( (1, v.len() ), v).unwrap();
    let y_hat = MODEL.predict(&x).unwrap();
    HttpResponse::Ok().json(PredictResult {
        predicted: y_hat[0] as i32,
    })
}

// サーバ起動
#[actix_web::main]
async fn main() -> std::io::Result<()> {
    HttpServer::new(|| {
        App::new()
            .route("/ping", web::get().to(ping))
            .route(
                "/invocations",
                web::post()
                    .guard(guard::Header("content-type", "text/csv"))
                    .to(invocations),
        )
    })
    .bind( ("0.0.0.0", 8080) )?
    .run()
    .await
}

Webアプリケーション化するといっても、複雑なことをする必要はありません。

SageMakerで推論処理を実装するにあたってポイントは2点です。

  1. /pingへのgetリクエストに正常に応答すること。
  2. /invocationsへのpostリクエストに推論結果を返すこと。

なお、SageMakerが/opt/ml/model/に学習処理で保存されたモデルを配置してくれるので、推論処理側は外部にあるモデルを取得してくる処理を実装する必要はなく、/opt/ml/model/に保存されたモデルを読み込めばOKです。

Dockerイメージを作成する

さて、学習処理と推論処理のコードは用意できたので、次はそれを利用するためのDockerイメージを作成します。

SageMakerは学習処理の際に、trainというコマンドで実行します。つまり、コンテナ内でtrainと打った時に、前述の学習処理が実行されればよいということになります。同様に推論処理はserveというコマンドを実行します。

Rustの場合、話はかなりシンプルになります。学習処理のコードをtrainというバイナリに、推論処理のコードをserveというバイナリにコンパイルしたうえで、PATH環境変数が通っている場所(例えば/usr/bin)に配置すればよいということになります。

|-- Cargo.lock
|-- Cargo.toml
|-- Dockerfile
`-- src
    `-- bin
        |-- serve
        |   `-- main.rs
        `-- train
            `-- main.rs

上記のような形で、src/bin/trainに学習処理のコードを、src/bin/serveに推論処理のコードを配置した上で、

cargo build --release

とコンパイルを行えば、target/release/train, target/release/serveにバイナリが得られるので、それをDockerイメージの/usr/binに配置します。

上記を踏まえたDockerfileが以下になります。

FROM rust:1.56.0 AS builder
RUN mkdir -p /app
WORKDIR /app
COPY . /app
RUN cargo build --release

FROM debian:bullseye-slim
COPY --from=builder /app/target/release/train /usr/bin/train
COPY --from=builder /app/target/release/serve /usr/bin/serve
EXPOSE 8080

これをECRにpushします。

aws ecr get-login-password --region ap-northeast-1 | docker login --username AWS --password-stdin ${ACCOUNT_ID}.dkr.ecr.ap-northeast-1.amazonaws.com
docker build -t rust-ml:sagemaker .
docker tag rust-ml:sagemaker ${ACCOUNT_ID}.dkr.ecr.ap-northeast-1.amazonaws.com/rust-ml:sagemaker
docker push ${ACCOUNT_ID}.dkr.ecr.ap-northeast-1.amazonaws.com/rust-ml:sagemaker

SageMakerから、学習処理、推論処理を実行する

SageMakerの操作はsagemakerというpythonライブラリから行いますので、pipでインストールします。その際に、のちのちローカルモードも実行するので、sagemaker[local]としてインストールします。

python3 -m venv exec-env
. exec-env/bin/activate
pip install sagemaker

あらかじめ、S3バケット(今回の場合であれば、sagemaker-with-rust)にUCI Machine Learning Repository: Iris Data Setよりダウンロードしたiris.dataを配置しておきます。

SageMakerでの学習、および推論処理を行うコードは以下になります。

import sagemaker
from sagemaker.estimator import Estimator

session = sagemaker.Session()
account_id = session.boto_session.client('sts').get_caller_identity()['Account']
role = 'arn:aws:iam::{}:role/SageMakerExecutionRole'.format(account_id)

# 学習データの配置場所
training = 's3://sagemaker-with-rust/training'
# 学習済みモデルの配置場所
output = 's3://sagemaker-with-rust/output'

# 推論器の作成
est = Estimator(
    image_uri=account_id+'.dkr.ecr.ap-northeast-1.amazonaws.com/rust-ml:sagemaker',
    role=role,
    instance_count=1,
    instance_type='ml.m5.large',
    output_path=output,
)

# 学習処理
est.fit({'training':training})

# 推論エンドポイントのデプロイ
pred = est.deploy(instance_type='ml.t2.medium', initial_instance_count=1)

# サンプルデータで推論を呼び出し
pred.serializer = sagemaker.serializers.CSVSerializer()
pred.deserializer = sagemaker.deserializers.JSONDeserializer()
test_samples = ['7.2,3.0,5.8,1.6']
response = pred.predict(test_samples)
print(response)

# 終わったら削除
pred.delete_endpoint()

ちなみに各自でコードを実行する際にはS3のバケット名、およびroleに指定しているSageMaker実行用ロールは、ご自身のアカウントのものに変更する必要があります。

ポイントとしては、以下になります。

  1. Estimatorの作成時にimage_urlとしてpushしたECR上のイメージを指定
  2. Estimatorの作成時にoutputとして学習済みのモデルを配置
    • 学習処理で、/opt/ml/model/配下に保存したモデルがSageMakerによって指定した場所に保存されます
  3. trainingデータの配置場所をfitメソッドのコール時に指定
    • SageMakerによって、学習処理コンテナ上の/opt/ml/input/data/training/に学習データのファイルが配置されます

上記のコードをsagemaker-remote.pyとして保存し、

python sagemaker-remote.py

を実行して、以下のような結果が出力されれば成功です。

2021-10-24 06:19:12 Starting - Starting the training job...
2021-10-24 06:19:35 Starting - Launching requested ML instancesProfilerReport-1635142752: InProgress
......
2021-10-24 06:20:35 Starting - Preparing the instances for training......
2021-10-24 06:21:38 Downloading - Downloading input data...
2021-10-24 06:22:12 Training - Training image download completed. Training in progress.
2021-10-24 06:22:12 Uploading - Uploading generated training model
2021-10-24 06:22:12 Completed - Training job completed
.accuracy: 0.9777778
Training seconds: 34
Billable seconds: 34
-----!{'predicted': 2}

サンプルデータとして渡している’7.2,3.0,5.8,1.6’は、Iris-virginicaのデータなので、推論結果もあたっています。

SageMakerをローカルモードで実行する

さて、めでたくSageMakerでRustの機械学習処理を実行できたわけですが、実際に学習処理を行ってから、推論結果を得るまで10分ほどかかっています。また、課金時間としては数十秒ほどかかっています。

兎角、機械学習は試行錯誤の連続なので、このリードタイムはかなりクリティカルですし、課金金額も数十秒とはいえかかっているので、積み重なっていけばそこそこの金額になってしまうのも、避けたいところです。

そこで、SageMakerのローカルモードで実行することで、上記の問題を回避します。

SageMakerのローカルモードは、AWS環境のインスタンスを使う代わりに、自分の端末内でDockerコンテナを使います。実行結果を得るまでの時間も速くなりますし、課金も発生しないので、アルゴリズムを試行錯誤で試す際に向いています。

ローカルモード実行のコードは以下のようになります。

import sagemaker
from sagemaker.estimator import Estimator

session = sagemaker.Session()
account_id = session.boto_session.client('sts').get_caller_identity()['Account']
role = 'arn:aws:iam::{}:role/SageMakerExecutionRole'.format(account_id)

# 学習データの配置場所
training = 'file://.'
# 学習済みモデルの配置場所
output = 'file://.'

# 推論器の作成
est = Estimator(
    image_uri='rust-ml:sagemaker',
    role=role,
    instance_count=1,
    instance_type='local',
    output_path=output,
)

# 学習処理
est.fit({'training':training})

# 推論エンドポイントのデプロイ
pred = est.deploy(instance_type='local', initial_instance_count=1)

# サンプルデータで推論を呼び出し
pred.serializer = sagemaker.serializers.CSVSerializer()
pred.deserializer = sagemaker.deserializers.JSONDeserializer()
test_samples = ['7.2,3.0,5.8,1.6']
response = pred.predict(test_samples)
print(response)

# 終わったら削除
pred.delete_endpoint()

ちなみに、sagemaker-remote.pyと差分がないようにしているので書いてありますが、実際にはroleはダミーでも問題ないので、session ~ roleを取得している3行(4~6行目)は必要ありません。つまり、16行目をrole=”dummy/dummy”とすることで、 4~6行目 はなくても問題はありません。

ポイントとしては、3点です。

  • 学習データや学習済みモデルの配置場所をS3ではなく、”file://.”とすることで、ローカルに保存されるようにしている
  • Estimatorの作成時、image_urlにローカルのイメージ名(ここでは”rust-ml:sagemaker”)を指定する
  • Estimatorの作成時、およびデプロイする際のinstance_typeに’local’を指定する

SageMakerをローカルモードで動かす時に必要な変更はこれだけです。なので、環境変数などでローカル環境実行時と本番環境実行時との動作を簡単に切り替えることができます。

ローカルモードでの実行のリードタイムは30秒もないので、試行錯誤を手軽に繰り返すことができますし、料金もかかりません。それでいて実際に本番環境に適用するための変更はわずかで済みます。

上記のコードをsagemaker-local.pyという名前で保存し、

python sagemaker-local.py

を実行して、以下のような出力が出れば成功です。

Creating rxv8w31h0l-algo-1-ira5t ...
Creating rxv8w31h0l-algo-1-ira5t ... done
Attaching to rxv8w31h0l-algo-1-ira5t
rxv8w31h0l-algo-1-ira5t | accuracy: 0.93333334
rxv8w31h0l-algo-1-ira5t exited with code 0
Aborting on container exit...
===== Job Complete =====
!{'predicted': 2}
Attaching to 6d8lwisy9v-algo-1-cr4kt
Gracefully stopping... (press Ctrl+C again to force)

なお、accuracyは訓練データとバリデーションデータをランダムに選択しているので、実行の度に変動します。ローカルだから下がっているわけではありません。

終わりに

Rustでの機械学習をSageMakerで行う例を通して、SageMakerでローカルと本番時とでの差分を最小限にしつつ機械学習処理の開発をする方法をご紹介しました。

この方法は言語やフレームワークに縛られないやり方なので、他の様々な言語やフレームワークでも同じ方法で運用することができます。

このようにSageMakerを使うことで、ローカル環境と本番環境との差分をなるべく小さくしつつ、様々な言語、フレームワークに対応した統一的な開発、運用を行うことができます。

次回、文章からの固有表現抽出をSageMakerとComprehendを利用して効率的に行う方法をお届けする予定です!

【社内活動のご紹介】LT(Lightning talk)会はじまりました! 次回は10/27(水)

0

アピリッツでは社員が自発的に勉強をする集まりがあります。そのなかのひとつ「LT会」は、主にWebソリューションセグメントのエンジニアが、チームや部署を越えた情報共有を目的として開催しています。「単発の企画ではなく、これからも末永く続けたい」という熱意を持っているLT会の運営メンバーの幾田と島田に話を聞きました。(2021年10月取材)

「誰かの仕事」にもアンテナを伸ばしたい

ーー アピリッツの社員同士でLT会を始めたきっかけはなんだったのでしょう。

島田:ある案件の開発でプログラミング言語の「Node.js」を使っていました。そのナレッジを社内に伝えたいと思ったのがきっかけです。案件が終わってしまうと、そこで独自に調べたり工夫したりしたことが関係者だけで完結してしまうなと考えました。うちの会社はRubyがメインで、Node.jsで開発の経験を積んだエンジニアが少ないんです。

そして、「Node.jsについて話をしますよ!」という勉強会だけだと、単発で終わってしまいます。それはもったいないかなと。今までも勉強会を開催してきましたが、ひとつのテーマだけだと続かなくて。

幾田:技術について話したい人や、誰かの仕事に興味のある人にとっての受け皿になるといいなと考えて立ち上げました。プロジェクト内で技術に関して調べたことや、実際の開発で学んだことを、より横につなげたくて。自分の実際の業務に関わること以外にもアンテナを張る人は社内に大勢います

そういう人たちが自発的に集まって話し合える場を作りたかったんです。

今年の9月に「まずはやってみよう」ということで第一回を開催して、第二回も無事メンバーが集まりましたので、10月27日(水)19時半~20時半にやります。

ーー 11月以降のLT会のスピーカーは現在募集中ですか?

幾田:はい! 集まればやろうかなと思っています。スピーカーの集め方も、今後はいろいろ試していきたいです。

ーー ではあらためてLT会について教えて下さい。

幾田:まず、「LT会」というスタイルは世の中に色々あって、趣味でもなんでもプレゼンできるテーマフリーのLT会もあります。

今回私達が企画したLT会では、「エンジニアの技術に関すること」とテーマを絞っています。そして、なるべく気軽に話してもらいたいと考えています。

「場所があるなら、話してみようかな?」と思う人が集まるといいなと考えています。ジュニア層、ミドル層、シニア層誰でもいいです。ただ、実はまだまだ参加者が少なくて……!

ーー  えっ!

存続の危機

ーー  「LT会」、さっそく続かないかもしれない。

島田:過去に企画した勉強会でも「話したい人が話したいことだけを喋って、解散」という会が多かったんです。

幾田:運営側もスピーカーとして参加しますが、そもそも色んな人に参加してもらいたいわけですし、同じ人が話し続けたらネタも切れてしまいます。

ーー  さてどうしましょうか!

幾田:悩んでいますが、コツコツ続けていこう、と決めています。気軽に話してもらいたいので、フォーマットをこちらで用意すればいいのかな、うーーーん!

ーー  わかります。「気軽に話してもらうための場作り」って難しいですよね。会社ではアピリッツの社内向けに無料カフェを作りましたが、それも「ちょっとお茶を飲みに行こうよ」と社員同士で誘い合って交流の場となれば……という狙いもあります。

また、AWSの資格取得については社内Slackでコミュニティを作って支援をしています。これはテーマを絞って支援する形ですね

でも続けます!

ーー  LT会は業務ではないですし、いわば部活の一種なんですよね。

幾田:そうですね。同じ社内で働くメンバーの生の話を聞くのは楽しいですし、「他のプロジェクトの話も知りたかったなあ」とあとになって思うこともあります。なので地道に続けていきます。

LT会に参加すると、他部署の人の顔もわかりますし、親近感もわきます。ふだんの開発業務に加えて、プレゼン形式のアウトプットもやってみると、頭の整理にもつながります。LT会にはいいことがいっぱいあると信じています。ということで、みなさん応援よろしくお願いします!

祝・ゴエティアクロス3周年! 新しいチャレンジと開発チームの変化をぜんぶ正直に話します!

0

アピリッツのオンラインゲーム『ゴエティアクロス(ゴエクロ)』が2021年9月27日に3周年を迎えました。そして、開発チームもゲームと共に変化・成長することができました。彼らが「とても大きなチャレンジ」と呼んでいる3周年キャンペーンでの挑戦と、今のゴエクロチームの体制について、プロジェクトリーダーの黒川、リードプランナーの久野、そして開発当時からゴエクロに携わってきたデザインリーダーの飯山に話を聞きました。(2021年9月 取材)

3周年イベントを成功させたい

―― ついにゴエティアクロス3周年ですね。開発にかかわる皆さんにとって、うれしいことかなと思うのですが、いかがですか。

飯山:実はまだ「うれしい!」という感覚は薄いです。まずは、3周年記念のキャンペーンをしっかり盛り上げます。それを大成功させたら、はじめて心から喜べるかなと思います。

黒川:僕ら、今は「とにかくイベントを成功させるぞ」ということで頭がいっぱいです。

飯山:はい。2周年のとき以上にいい内容になると思います。

久野:いま、ゴエクロはユーザーさまにも楽しんでいただけて、ゴエクロそのものに勢いがついているので、いいタイミングだなと思います。

※ここからインタビューはしばらく中断され、キャンペーンの運営に関する熱い会議が始まりました。諸事情により記事では公開できませんが「もっとゲームを良くしたい!」という熱意に溢れていました。

黒川:3周年で弾みをつけていろんなことに挑戦したいのですが、まず最初にユーザーのみなさまにこの場を借りて自分たちの言葉でお伝えしたいことが……。

―― おねがいします。

全員:8月のイベントで大きな不具合を起こしてしまい、数日間ゲームの動作が不安定な状態がございました。本当に、申し訳ありませんでした!

黒川:根本的に解決するための方法をチーム全体で話し合って、対応を重ねてきました。

久野:真摯に改善を進めています。

飯山:そして、トラブルがあったにも関わらず、ここまでついてきてくださったユーザーのみなさま、本当にありがとうございます。

※ここからインタビューは再び中断され、修正点に関する振り返りの話が続きました。諸事情により記事では公開できませんが、メンバー全員が真剣に語り合いました。

「やろうぜ!」って声をかけて、発破をかける人

―― 飯山さんは開発時からプロジェクトに関わっていますよね。開発期間も含めるとチームにも3年以上の歴史があります。チームはどのように変わっていきましたか?

飯山:前提として、どのフェーズでも「いいゲームを作ろう、楽しんでもらおう」という熱意は変わりません。でも、空気は少しずつちがうなと感じます。

たとえば、開発からリリース初期のころは「文化祭の前日」のような賑やかさでしたし、運営が落ち着いてくると、その文化祭っぽさも落ち着くんです。

久野:私がゴエクロに参加したのがちょうど1年半前くらいで、そのときは比較的静かなチームだなと思いました。

飯山:仕事に関する話だけをするチームでしたよね。でも、そこから運営体制が変わって「新しいことを始めようよ!」って空気がうまれて。新しいことをはじめるって、やっぱり楽しいんですよね。チームも「文化祭の前日」みたいな雰囲気に戻りました。

開発室で記念撮影。たしかに、にぎやかな部屋です

黒川:僕が参加したのが3か月前で、そのときに「アピリッツで一番にぎやかなチームにしよう」と決めたんです。

飯山:今は本当にうるさい(笑)。

久野:黒川さんが来てから一気にうるさくなった(笑)。髪も日に日に派手になっていくし(笑)。

―― そういえば黒川さん雰囲気変わりましたね!

黒川:はい! 3周年に向けて気合入れようと思ってイメチェンしてみました!

2021年7月の黒川さん
2021年8月の黒川さん。後ろ姿だと黒川さんかどうかが最初わかりませんでした

黒川:それはさておき、僕は自分がゴエクロチームに合流するに当たり、チームを社内で最も賑やかにするぞ! と決めてましたけど、でもこれ、「今までのチームメンバー全員が陰キャ(内向きな人)だった」って話ではないと思っています。

何をやればいいかわからない、どこに向かって走ればいいかわからない状態だと、誰だって迷子になります。で、迷子になると、どんな人だって話せなくなる。

飯山:陰キャ陽キャの話は置いておくとして、「やろうぜ!」って声をかけて、発破をかける人はチームに1人は必要だなと感じました。そして、みんなで話をするようになると、「ゲームでこうすれば面白いかも、ユーザーがよろこんでくれるかも」ってアイデアが浮かびやすくなるんです。

久野:黙っているときだって、各自いろいろと考えてはいたのですが、自分の仕事で手いっぱいで、つい黙っちゃう。

飯山:今は、誰かが「これ面白いかも?」と言ったら「いいね!じゃあ、それを実装するためにどうしようか?」ってみんなでその話に乗っかって、みんなで動けるんです。

久野:アイデアがまとまったら黒川がスケジューリングを組んで、ゲームの中で実現できるようになりました。

ゴエクロチーム最大の挑戦

―― 3周年のキャンペーンもそうやってチーム全員で作ったのですよね。

黒川:はい。何度もお話していますが、ゴエクロチーム最大の挑戦だと思っています。運用難易度はとても高いので、チームメンバーには「すまん!がんばってくれ!」と先に謝っておきました。

今回の3周年でシナリオ、イベント、そしてキャラクターがエモくなるように考えました

久野:これがずっとやりたかったんです。そして、今のチーム体制だからできることだなと考えています。プランナー、デザイナー、エンジニアが三位一体になってゴエクロを盛り上げています。

飯山:デザイナーから「ここ、こうしたら面白くならない?」と提案して実装された仕様もあります。

黒川:今回のキャンペーンが終わったあとも、楽しい仕掛けを準備していますので、ユーザーの皆様には楽しみにお待ちいただければと思います。

さらに、3周年のチャレンジが上手くいけば、さらに挑戦できることも増えます。コラボにも挑戦したいですね!

※ここからインタビューがまたまた中断し、「コラボやるならどんなのがしたいか作戦会議」が始まりました。これも記事では公開できませんが、いつかよい発表ができることを期待しています!

黒川: 話がそれましたが、今のゴエクロチームの体制で成功したノウハウは、他の開発チームにも共有して広めていきたいです。売上やユーザーさまの反応といった数値でよい結果も出ているので、そのための努力は惜しみません!

久野:それは・・・黒川みたいなキャラの人が増え続けるってこと?(笑)

飯山:それはそれで、大変なことになる(笑) 1人でいいよね(笑)

黒川:いやいやいや! 黒川シリーズが増えてもいいじゃん!

関連記事:心からワクワクするような遊びを届けたい!「ゴエティアクロス」プロジェクトリーダーインタビュー

【ゲーム制作の現場から】04:シナリオ執筆のコト始め・プロット編

0

「04:シナリオのコト始め・企画書編」に続き、物語の筋を決定するプロット制作の風景についてです。

■ 狂気のプロット山脈

◎ そもそもプロットとは?

 物語の構成を書いたシナリオの設計図、それがプロットです。「誰がなにをして、どうなったのか?」因果関係を筋立てたものです。 脚本を書く前段階の資料となります。

出版社:みすず書房

 筋なので構成を考えますが、表現はゲームシステム上で展開します。よって、プランナーが想定するプレイ時間やシステムについて話し合いながら検討します。プロット打ち(打ち合わせ)でライターからは、「こんな話だから、これくらいの構成にしたい」などシナリオ構成論を交えたアイデアが出てくるでしょう。

 中身が決まれば、分量も決まります。先に予算的なことから分量をきめて、それにあわせ話をつくることもあります。

チェックする側が的確な指示を出せないと、無限リテイクが発生する。企画フェイズで各項目のゴールを設定しよう

◎ ゲーム性からの物量あわせ

 では、具体的にどのくらいのボリュームのシナリオを書くのか? それはスケジュールにも絡むので、企画フェイズであたりをつけます。

 小説ならばページ数の制限、映像作品ならば尺にあわせた長さがあります。同様にゲームの本(脚本)も、プレイサイクルとステージ構成にあわせた物量を決めます。ボリュームはゲームの制作規模(ステージ数や必要となるクリエイティブなど)に直結し、予算との関係性が大きくなります。そのため、ゲームプランナー側から制作ボリュームについて提案されることが多いのです。

 ライターは、物語の流れを大きなセグメント(節)にわけてどのように展開するのか? プレイサイクルを考慮してシナリオを何章何話で組むのか考えます。なのでプロットでは、ざっくとしていた尺についても詰めるのです。

◎ 実装までの流れ

 シナリオのボリュームが決まったら、物語の構成を決めるプロット起こしです。ログラインで話全体の見晴らしをよくして、物語の軸となる資料「プロット」に落とし込みます。それは因果関係が表した文章となります。ワードで書くことも、セルで一覧化できるように書く場合、様々です。

 出来上がったら関係者とプロットを共有し、意見交換。GOが出たら執筆して、初稿を提出する流れになります。

ライターの作業は、執筆要件からプロット、執筆と進む。わたしの場合、アイデアレベルの話を数枚荒書きしてからログラインにまとめる

■ ログラインの山を超えて

◎ 檣楼(しょうろう)からの見晴らし

 さて、何度かログラインという言葉が出ていますね。ログラインとはストーリーの文脈を簡潔にまとめ、物語の見晴らしを良くしたものです。ストーリーテリングの根幹となる作業です。 

  企画のアイデア、テーマや世界観のモチーフという源泉から情報を整理。キャラクター、舞台設定、キーとなる世界観の情報をカテゴライズし、可視化情報にします。すると、関係性のポイントが見え、ストーリーの整理できます。

 この作業は ストーリーアーク(Story Arc) と呼ばれるものです。ログラインを書くということは、構成アイデア出しとストーリーの整理整頓であり、プロット書きの地図を作成する役割も果たしているのです。

映画「スターウォーズ エピソード4/新たなる希望」のログライン。これだけでは面白さは伝わらない。どんな作品にできるか? 完成を想像できるDの目利きが必要

◎ 竜骨はゆらがない

  簡潔でわかりやすい言葉にまとめたログラインという幹から、プロットが生れ、いくつもの話が枝葉のようにつき、物語が成長するのです。

 ここで述べているログラインは、脚本構造についてのあらましで、プロット作成の前作業となります。その内容は、「主人公が抱える問題を、どこで何をして、誰と対峙して、どのように解決するか」といったものです。

 シナリオ概要を書く際にもライターは作品全体構造のログラインを出します。企画を進め、書くべき物語がより鮮明になってくると、章別のログラインも必要となってくるのです。

 それはどんなストーリーなのか?

 骨がしっかりしていれば、舟はゆらぎません。すべては「一歩一歩、順序よく」なのです。

■ ポイント・オブ・ヴュー

◎ 組んで検証

 続いて、プロットについてもう少しお話しましょう。何章・何話の話にするのか? どのようにキャラクターを登場させ、事件を起こし、解決に向かわせるのか? スジ組を構成するには、 物語が必要です。物語(Narrative)は、登場するキャラクターがいかに動くのかで決定します。

 ストーリーラインからキャラクターの経験や取得情報に即したエモーショナルライン(Emotional Arc)を考察。キャラクターが知り得る情報で、性格にあわせ、どのように反応するのか組み立てるのです。こうして全体を構成を決めつつ、行動にゆらぎがないかチェックです。

◎ 容赦なく斬る

 チェックとは、考えた話(Story)の構造を分解して検証することで、重要な工程です。解析スキルを発動させ問題点を抽出、調整するストーリーテリングのスキルが展開される部分。当然コストが、かかります。そのため予算がついてから動くのです。

 こうしてプロットを組み終わっても、より細かなキャラクターの動きや動線を共有する場合には「箱書き」と呼ばれる段階まで掘り下げます。

どのシナリオライターを選ぶか? 裁量権を持っているの者の真眼が試される

■ セントエルモの火

◎ 君の灯火、僕の光

 今回は、プロットを切る流れを説明させていただきました。プロットを切るには、ストーリーを簡潔にまとめたログライン出しが骨子となります。 そして、話の見晴らしをよくする過程で生まれた、設定資料を整理することも大切なのです。

 「誰のためのどんな物語なのか?」ワールドひとつ立て、登場するキャラクターたちの人生を描くことで、物語は形作られます。作家の頭にあるものすべてを資料すると、かなりの密度を持った情報になり、簡単に肥大化します。月極イベントが実装されるオンラインゲームでは、ストーリーやキャラクターの設定はもちろん、武具や文化・時代背景の設定が膨張し続けるのです。そのため資料の、整理整頓は大切なのです。

◎ カテゴライズとUX

 複雑な世界観や設定であるほど、カテゴライズと一覧がきちんと区別された、見やすくシンプルな資料を作成すれば、初見でも理解できます。それは、ライティングの揺るぎない指標となり、製作関係者の有益な資料となります。

※※ 次回は 、コト始めシリーズの終章。脚本の執筆フェイズ、「ライティング編」です。

記事に関するお問い合わせやシナリオのご相談は、総合お問い合わせフォームからご連絡ください。

【アカツキ×アピリッツ共同育成プロジェクト】「プロジェクトを育てることは、人を育てること」

0

株式会社アカツキとアピリッツの共同採用戦略「次世代ゲームプランナー育成プログラム」では、プロジェクトの中核となるゲームプランナーを両社で積極的に採用・育成しています。今回は、このプロジェクトに参加するとどのような成長が望めるのかをお伝えします。運営中タイトルならびに新規開発タイトルのディレクターであるアカツキの綿引氏(以下、敬称略)と、同じく開発プランナーを担当しているアピリッツの助國に、現場で感じたチームの成長と求める人物像について聞きました。(2021年8月 取材)

スピード感をつねに求められる現場

ーー アカツキさまとアピリッツで構成されたプロジェクトチームはどのようなチームなのでしょう?

アカツキ 綿引:ベテランの知識と若手の勢いがうまく噛み合ったチームだと思います。

私たちは、次の時流を読み取ってエンターテインメントを作っていきます。現場では、開発や意思決定などのあらゆる局面で、時流とリンクさせるスピード感が常に求められています。

その速さを実現するために、若手とベテランが融合したチーム編成がうまく機能しています。

アピリッツ 助國:「スピード感がある」というのは、私もとても実感します。実際に開発現場で目の当たりにするとびっくりするんです。人の成長しかり、開発の判断スピードしかり。

アカツキ 綿引:また、意見が言いやすい環境を作ることが大切だと考えています。私たちのプロジェクトでは、所属によらず、プランナー、デザイナー、エンジニア、CX、QAのそれぞれがプロダクトや組織に意見を発信できる文化づくりを意識しています。


取材はオンラインで行いました(左上:株式会社アカツキ 綿引氏、右上:株式会社アピリッツ 助國、下段はインタビュワーの村上(左)、白石(右))

「人が変わっても、品質が上がり続ける」チームづくりを目指した

ーー フラットな関係はどのように築いていますか?

アカツキ 綿引:一般的に言われる「パートナー会社との開発」では、受発注だけの関係になりがちですが、アピリッツとの開発では、ワンチームで進行するゲーム作りだけではなく、会社の垣根を超えて、両社の人材育成にも注力することも目指しています。

現在はリモートワークなども活用していますが、以前は同じ場所に出社して、お互い意見を伝え合ってチームを形成していきました。

アピリッツ 助國:他にも、「一番いい方法は何か?」を全員で考えるようにしていますね。

アカツキ 綿引:さらに、ポテンシャルの高い若手を1~2年目で重要な役目に抜擢して、その若手をベテランがサポートして開発を進めたりもしています。プロジェクトを育てることと、人を育てることがイコールだと考えています

最初からできる人に任せたら、開発は一時的には早く進むかもしれませんが、スキルも経験もその人に偏ります。そうやって属人化を進めるよりもチームで成果を出す。そのためには一人ひとりの持つ「この人に任せたら面白いものが作れるかもしれない」というポテンシャルに賭けるようにしています。

ーー 「ポテンシャルが高い人」とはどういう人でしょう?

アカツキ 綿引:ベースのスキルも大切ではありますが、最も重視しているのは「120点でアウトプットができる人かどうか」です。期待以上のものを作るスタンスさえあれば、期待する課題の難易度が実力とともに上がっていっても、その期待を超えたアウトプットを出し続けてくれるはずです。

そうやって本人の能力以上の役割を担ってもらう。ポテンシャルに賭けています。そうすることで、本人の成長にも繋がっていくと考えています。

また、もしそれで失敗してもチームでカバーしますし、フォローもします。だからこそ、安心して挑戦できるのです。

アピリッツ 助國:アピリッツの江川 ※もそうやって成長した一人ですね。関わる範囲が広く、難易度が高いややベテランがやるような仕事を若手の彼に担当させてみたら、課題や問題を解決しながら成長しあっというまに一人前になった

「この人にはこれを任せる。権限も与え、挑戦させる」とチーム全体に宣言し、それを全員が理解したうえでサポートします。会社の垣根を越えて人を育てているなと感じます。

成長した江川さん

※関連:アカツキ×アピリッツ共同育成プロジェクトで成長したプランナーに話をききました

貪欲に成長してほしい

ーー 若手が挑戦を続けているとき、どのようなフォローをおこなっていますか?

アカツキ 綿引:あえて難易度の高いタスクを与えているわけですから、筋肉痛のようにつらい状態になることもあります。そういうときは、まずは1on1で徹底的に話を聴いています。人って、自分の状況を把握している誰かがいるだけで、安心できたりするので。

もし決められた1on1の時間に収まらないときは、別途時間を取ってとことん向き合うこともありますね。

アピリッツ 助國:アピリッツとアカツキの間でも対話は重ねます。誰がどういう壁にぶつかっているか、その壁を乗り越えたらどんなことができるようになるか、常に両社で共有しながら進めています。

たとえば、開発プランナーとして小さな機能だけを担当している人に、半年後には大きな機能を任せられる人になってもらおう、などと目標を話し合うんです。そして、そのために必要なタスクや役割を渡していく。

こういった「成長への意識」がメンバー全体に行き渡るまでには時間がかかります。でも、地道に続けてきたことで成果につながってきたと感じています。

IPやサービスを提供する姿勢や心構え

ーー アカツキとアピリッツが協力してひとつのプロジェクトを進めるメリットはどんなところにありますか?

アカツキ 綿引:全く異なる文化を持つふたつの会社が共同で開発していることで、双方の良い文化や価値観を柔軟に取り入れ、独自のプロジェクトの価値観へ昇華できていると思います。

アピリッツ 助國:アピリッツとしては、IPやサービスを提供する主体としての姿勢や心構えをアカツキと経験できたのは大きな財産です。IPに対する愛情がないと、プロジェクトは成功しません。そういった姿勢を学べています。

そして、育成メソッドや組織体制はもちろんのこと、仕様書の作り方や会議の進め方に至るまでアピリッツとアカツキでは文化が異なります。それらを経験できたのもよかったです。

特に、このプロジェクトでは、若手がすごいスピードで成長していくんです。それを目の当たりにすると、こんなスピードで成長することが「ありえることなんだ」「うちの会社でもできるんだ」と思えるようになりました

私自身も、開発における意識や進め方が変わったな、成長したなと、まだまだ感じることがありますね。

ーー このプロジェクトではどんな人と一緒に働きたいですか?

アカツキ 綿引:チームと協働しながら、最後までやりきれるメンバーを求めています。協働とは、チームメンバーに対してリスペクトを持ってコミュニケーションを取り、一緒にゲームを作ることを指します。さらに、プランナーは様々なセクションを巻き込んで、機能開発を進行させるためのリーダーシップが求められますし、そこで、最後までやりきる胆力も必要になります。

もし今そうではなかったとしても、そういった能力をもった自分をイメージしてワクワクできる人と一緒に働きたいです。

アピリッツ 助國:吸収できるものがたくさんある現場ですから、今までの固定観念にとらわれずに柔軟に変化・吸収できる人と働きたいです。また、みんなで話し合ってゲームを作り上げていきますから、コミュニケーションを重ねることをいとわず、チームとしてのベストな解を探そうとする人は活躍できるはずです。

ーー お二人ともありがとうございました!

関連:共同育成プロジェクト特設採用ページ|株式会社アピリッツ

【ゲーム制作の現場から】03:シナリオ執筆のコト始め・企画編

0

「世界観設定のコト始め」の続きです。企画フェイズで、物書きから見える開発現場の風景についてお送りします。

■ それってどんなゲームなのヲォ!?

◎ 神は申された、はじめに企画書あれ

♪マスターAPKは歩いて来ない♪
♪だぁ~からぁ、企画を書いてぇ~、予算を取るんだよン♪

そう、ゲームのシナリオを書いてお賃金をいただくためには、ソフトウェア制作が始動しないと、お話になりません。それには情報共有するための資料、企画書が必要です。

ぱっと見て理解できる情報、読ませてわからせる情報。作成目的にあわせて、資料の粒度を決めます。

企画フェイズでプロジェクトのロードマップが敷かれ、長い旅がはじまる

◎ 設定が先か、話が先か?

さて、初見で理解できる資料とは、そもそも何でしょう?

映画の宣伝ポスターのように、ひとめで理解できる短い言葉とビジュアルが必要です。そのため、世界観を共有する資料を先行して作成することがあるのです。コンセプトアートを早めにあげ、開発者のイメージを統一するのです。

作家はストーリーが先と考えるかもしれませんが、TRPGのシナリオ作成と同じだと思ってください。世界設定が書かれたガイドブックがあって、そこにシナリオを乗せる形式に相当します。

コンピューターゲームとTRPGのシナリオ製作は似ている部分も多い

■ 企画書の中身

◎ 君の企画は10,000ボルト

では、ゲームの企画書には、どんなことが書かれているのでしょうか? 

まずは構成について。アイデア企画であればペラ1-2枚が求めてられます。アイデアが明確にあったり営業用の場合は、システムや画面遷移など設計原案を固めた、20~30枚程度のしっかりとした企画書になるでしょう。

後者の場合、わたしは大きく2つのパートにわけます。前半は、4~5ページのゲームの魅力を伝える見てわかる資料。後半は、二十数ページのシステム概要書です。では、具体的にどんな項目の情報が必要でしょうか?

ビビッと来るアイデアが詰まっていないとトラッシュボックスへ一直線です。紙の資料なら、SDG’s的にもよくありません

◎ 認識することで世界が生まれる

 タイトルにはじまり、こんなゲームですというコンセプト、ターゲット、RPGの肝となるシナリオの概要、作品の売りとなるゲームデザイン、製作にかかる要件を記したプロジェクトスコープ。これがあれば企画内容が伝わるはずです。

企画書と同時に、クリエティブの細かな一覧表など付随資料が生まれる

シナリオ面では、簡単な世界観と100~200文字のストーリーの概要が必要です。グラフィックイメージを描き起こす場合は、事前に発注用の設定も起こさないといけません。

◎ ライターから見える企画書の項目

シナリオへ直接言及はされていない項目には、どう関わり、どう見えているのでしょう? 

  • タイトル

 ゲームそのものを指す。テーマであったり、比喩的な表現。

 ⇒ ストーリーやプロットを作成するときに、テーマからブレない離れない為の灯火。

  • コンセプト

 ゲームの根幹をなす概念。ゲームジャンルや、何を表現して誰にどんな体験をして欲しいかが書かれている。

 ⇒ ここを起点にシナリオを描く。物語、キャラクターの性格・行動など、展開のアイデアを出す。

  • ターゲット

 対応機種、プレイヤーの年齢層と仮想ペルソナが設定されます。

 ⇒ ジャンルや読み手の年齢は、構成や文体に影響する。登場キャラクター造形は、人間関係の複雑化に関わり、ストーリーの展開の粒度に影響、構成は脚本の総量に影響する。

  • シナリオ概要/世界観概要

 それぞれペラ1枚で簡素な情報量が好ましいです。

 ⇒ これを書くためには、ログラインを切り、シナリオコンセプトやふわりとしたストーリーができあがっているでしょう。キャラクターについても言及することもある。

  • ゲームデザイン

 ゲームの肝となる、システムの概要。プレイサイクル、画面遷移図はプレイヤーがどんな体験でプレイするのかが書かれた設計図となります。

 ⇒ ゲームサイクル(プレイ時間)から物語の動線を把握、構成を組み、シナリオの総量を出します。プレイヤーの感情曲線(エモーショナル・アーク)を出して、芝居のリズムを想定。必要な演出やクリエイテブ量、各画面でライターが関わる部分の洗い出す。

 ⇒ 画面遷移を把握。プレイヤーの行動タイミングと取得情報から、ゲームを魅力的に魅せる演出アイデアを練り、必要な作業量を見積もる。

  • プロジェクトスコープ

 要件定義やどんな布陣で製作を行うかの、物量総括。企画を煮詰めて、クリエイティブや作業量を決め打ちすることで固める項目。

 ⇒ 何をいつまでに書かなければいかないかを判断。人繰りとスケジュールの材料となる。

 こうしてゲーム全体の構造想定ができ、クリエティブリストが揃うと、企画フェイズは大詰めです。

■ その企画、おいくら万円?

◎ お金という重力質量の問題

 プレイヤーがどんな世界で遊ぶゲームなのか? 企画が固まれば、シナリオライターは”作品”の話を考え始めることができます。

 しかし、企画フェイズでは商業的な面もクリアする必要があります。

 プレゼンして、開発承認を得て、予算を獲得するのです。そうお金勘定をしている層(レイヤー)では、ゲームはあくまで”商品”なのです。会社がいくら投資すると、どのくらいのリターンが得られるのか? ソロバンを弾いて、開発費用・運営費用を見積もらないとイケません。

 予算を取らないと先に進めないのですから、この重力には逆らえません。最優先項目に早変わりです。

 企画レベルのふわりとしたプロジェクトスコープを詰め、予算獲得のフェイズに進みます。もちろん、プロジェクトや会社によって、予算決めに必要な項目や手順は変わってきます。スマホのオンラインRPGの場合(経験上)こんな感じになりそうだという想定の元、話を進めます

制作現場にとっては予算は、人繰りの数字でしかない

◎ 要件確定、予測、トラブル回避

 シナリオ担当が、予算決めの重力から開放される行動。それは、推測されるシナリオ関連の作業量を企画者と共にソロバンして、人月を算出。エクセルファイルをスイングバイです。

PL(プランナー)、SV(サーバ)とCL(クライアント)、DS(デザイナ)の担当者で総量を算出。D(ディレクター)やP(プロデューサー)が調整して、見積もりが出来上がる

 シナリオパートだけを考えた場合でも、ラフプロット(簡単な話の筋組)ぐらいは切って章立てしていないと、見積もり精度が落ちてしまいます。しかし、諸事情でエイヤーっと決めなければならない場合もあります。そんなときは、金額に下駄を履かせたり、根回する知恵を働かせて、未来のトラブルを極力回避します。

 予算が組まれ、GOが出たら、本腰を入れてプロット起こしです。企画初動からシナリオ担当が参加していれば……。

■ 見ている世界の違い

◎ 職業的な第三種接近遭遇

 さて、ここでゲームの企画書とは誰が書いているか考えてみましょう。

 ゲームなのですから、ゲームデザイナーやゲームディレクターが書いていることが多いのではないでしょうか? 発注元があれば、制作プロデューサーかもしれません。

 そう、企画書を上げて予算を見積もった人間が、シナリオ制作に精通しているとは限らない、ということです。

開発がスタートするまでの助走期間で、ゲームとしての骨は固まる
  •  ゲームデザイナーから見える世界

 ゲームとは、あるルールのもと勝敗を決めます。ゲーム制作者から見えてるシナリオの世界は、「敵と味方がどこで何をかけて雌雄を決しているのか?」です。

 ゆえに、ゲームデザイナーの中心はゲームのルールやシステムなのです。

 話のモチーフ、舞台や登場キャラクターの相関図やファクション(勢力図)といった設定、ビジュアルをどうするのか、敵味方の見え方に気を配ります。別の言葉にすると、プレイヤーからどう見えるかが重要なのです。

  •  シナリオライターから見える世界

 物語とはヒトとヒトとのドラマであり、脚本は因果関係を芝居に落とし込んだものです。誰かの問題をどのように解決して結末を迎えるのかを描きます。

 ゲームのシナリオライターは、登場人物のココロ(感情)のゆらぎと、行動による変化で生まれる出来事(ドラマ)を綴ります。舞台で役者(キャラクター)にどんな芝居をさせるのかを、演出も含めて表現しようとするのです。

見る角度の違いで、受け止め方は変わる

◎ 畑違いの未知との遭遇

 ゲームデザイナーとシナリオライターの領域。専門性が違うので、当然モノの考えや視点は異なります。もし、脚本家や演出家の視点が足りない場合、何が起きるでしょうか?

 演出面の調整時間、エモーショナルラインの調整時間、できあがった芝居のリズム調整など、専門的な作業が見落とされることになります。これは時間=予算(スケジュールを含む)に直結しますので注意が必要です。正しい知識やそれと同等の嗅覚を持たない者のジャッジは、適当な判断でしかないのですから。

 この危険を回避するには、企画・グラフィック・プログラム・シナリオ・運営の専門的な知識を持った開発者が企画フェイズから目を光らせていることが大切です。

■ 音を探そう

◎ 企画書の本質

 ゲームの企画書。それは、「こんな世界やシステムをゲームにしたい!」という、クリエイターの表現欲求が書かれたコンセプトBOXです。シナリオを執筆するための根源情報となります。なぜコレを創っているのか見失い、無限のアイデアに流されてしまったとき、目指すべき道標となります。

 シナリオ担当は、企画の根源を見極め、世界観や設定を起こし、脚本を書き、芝居を成立させることが仕事です。

◎ あなたのD・E・C・C・G

 そんなゲームプロジェクトでは多くの人達が関わる、未知との遭遇です。専門性の違う人達があつまり、よい作品になるようにお互いが理解しあえる共通の音を探す。対話することで、うまくプロジェクトを進めるのです。

 相手が生き物であれば、対話することができます。諦めない努力は必要なのです。 

 ♪レ・ミ・ド・ドォ・ソ~ォ♪

 ※※ 次回は、「シナリオ執筆のコト始め・プロット編」です。

記事に関するお問い合わせやシナリオのご相談は、総合お問い合わせフォームからご連絡ください。

新卒社員の活動のご紹介。「図書委員が社内の技術書貸し出しの電子化を始めます!」

0

アピリッツに入社する新卒社員は、入社から1年間、業務と並行して「委員」として社内で活動します。今回ご紹介する「図書委員」もそのひとつです。図書委員は、社内にある数百冊の技術書の管理を担います。
「委員」のみなさんは、ただ作業をするだけではなく、自分たちで「ゴール」を決めて取り組みます。今年の図書委員のゴールのひとつに「DXへの取り組み(Slack等を通じての貸出管理システムの構築)による利便性の向上」というものを発見しました。このゴールを知ったアピリッツの執行役員でCDXO(チーフ・デジタル・トランスフォーメーション・オフィサー)の西脇が「素晴らしい!」と感動していたので、図書委員のメンバー5人に話を聞きました。(2021年7月取材)

AWSを使用して開発します

ーー 図書委員のメンバーはアナリスト、Webエンジニア、ゲームエンジニアとバラエティに富んでいますよね。アピリッツらしいチーム編成だと思います。

串田:それぞれの業務に近いところを図書委員プロジェクトでも各自が担うといいなと考えています。具体的な役割は、アナリストの舛中さんにはUXの提案と完成後の動作確認とレビュー、エンジニアの竹内さんと田中さんと霜島さんにはデータ作成やデータのインポートとテスト。全体を通しての開発は自分(エンジニア)が担当します。

AWSを使用してのアーキテクチャはなんとなく想像がついていますが、今後もし行き詰まったらAWSに詳しい先輩の浅田さんや竹藤さんに相談するつもりです。

霜島:自分が図書委員になったのは「DXってなんか面白そうだな」と思ったのがきっかけです。サーバ周りにすごく自信があったわけではないのですが、面白そうだしチャレンジすることにしました。あと、技術書や資料集が大量に積まれていたり、本棚にびっしり詰まっていたりすると壮観ですし、図書委員って楽しそうだなと考えたのも参加の理由のひとつです。

田中:わかります! 私も本が好きですし、自分にぴったりな委員です。

「読みたい気持ち」はあるけれど

ーー どういうきっかけで「貸し出しシステムを電子化しようぜ!」となったのでしょう?

舛中:自分の場合、「本を読むのを挫折しかけた」からです。田中さんや霜島さんと違って、自分はもともと本がすごく好きなわけでもなく……。でもだからこそ読みやすい環境の大切さを痛感しています

たとえば、アピリッツに入社して、さあマーケティングや開発に関わる技術書を読んでみるかと本棚の前に立ったものの、そこで目当ての本が見つけられなかったのです。並び順の規則性がサッパリわからなかった。

串田:わからないと目的の本を探すのに時間がかかります。探す時間がもったいないなと思いました。あと、貸し出し票が現在は紙なので「ボールペンどこ?」とか「この本の貸し出し票はどの台帳?」とか、借りるたびに探すのももどかしくて。

霜島:そうなんですよね。紙だと貸し出しの管理も大変です。貸出の台帳に返却期日を記入しています。ここで記入漏れが発生する恐れがあります。現に整理を始めてみると、返却されているのに返却確認欄にチェックがついていない本などがありました。

竹内:自分はもともと本の整理整頓が好きです。整理整頓好きの視点から見ても課題がありました。実際どれくらい本棚が乱れているかは、図書委員になるまでは把握していなかったのですが、本の分類作業を行っていくうちに「これは大変だな」と状況を理解しました。早急に対処したいです。

舛中:そんなこんなで、会社の本を読みたい気持ちはあるけれど遠ざかっている社員は少なからずいるんじゃないかなと考えました。彼らの背中を押すような委員になりたかった。

読みやすい環境を作っていきます

「自分で会社をよくしていけそう」

ーー 課題が多いですね。そして、問題があるなら自分たちで解決してしまおう、と。

田中:はい。どの委員をやるか考えていたときに、ちょうど「会社の書籍貸し出しのDXができたら……」という話が出て「会社のシステムに変革を起こし、自分たちで新しいものを作り上げていく絶好の機会だ!」と思いました。それで「やります!」って挙手しました。

もともとアピリッツに入社した理由も「ベンチャー企業の雰囲気があるし、自分で会社を良くしていけそう!」と思ったからです。これまでの「会社の本を借りて学習する」という体験をガラッと変え、会社の成長につなげたいです。

串田:アピリッツは年々大きく成長していますし、それに合わせた環境に変わっていくと思っています。変化の真っ最中のなかで、こういった小さな改善だったら入社から間もない自分たちでも出来るかも? と考えました。

舛中:これから入社する人たちのためにも、勉強しやすい環境を作りたいです。

霜島:返却日が近づいたらメールやSlackでリマインドする機能がほしいなあ……と想像しています。

舛中:貸し借りがスムーズになるといいですよね!

竹内:環境づくりで言うと、DXに加えてUXを意識した本の整理と分類にも着手しています。私はシステムからグラフィックデザインまで幅広い知識を持っているため、その知識が分類作業に生かせていると思います。

ーー 楽しみです。ちなみに、このインタビューは当初「貸し出しシステムが完成してから記事化しましょう」という話でしたよね。

串田:はい、次の新卒が入社する頃までに完成させて、それからお話ししようかなと思っていました。でもCDXOの西脇さんが「それじゃ遅いよ! こういうものは作ると決めたら宣言するといいよ!」って(笑)

仕事も増えてきましたし、ちゃんと自分たちで風呂敷を畳めるか不安になりつつありますが、委員会活動を終えた時には「根拠のある自信を持って、一人称で動くことができる人間」になれたらいいなと思います。

関連:技術書が豊富な『アピリッツの蔵書』を分析とともにご紹介!【書籍購入制度・図書】

心からワクワクするような遊びを届けたい!「ゴエティアクロス」プロジェクトリーダーインタビュー

0

今回は、アピリッツの自社IPタイトル「ゴエティアクロス」のプロジェクトリーダーを務めているアピゲー部の黒川に3周年を迎えるゴエクロの魅力や今後の意気込みなどについてインタビューしました!(2021年7月取材)

社外のゲームタイトルで開発を経験後、ゴエティアクロスのプロジェクトリーダーに

――自己紹介をお願いします!

2017年新卒で入社したアピゲー部の黒川 勝貴(くろかわかつき)と申します!現在は「ゴエティアクロス」のプロジェクトリーダーを務めています。実は、自分がプロジェクトに配属されてリーダーになったのは今年の5月からなんです……!

自分の仕事としては、開発チームを取りまとめて、プロジェクトをきちんと継続させるために運営と開発のスケジュールを立てたり、数値周りの分析をしたり、ユーザーの皆様に「面白い!」を提供するための新しい遊びを考えたりすることです。

ちなみに、ゴエティアクロスチームに参加する前は、コンテンツデザイン部に所属していました。当時は、アカツキさまのタイトルで開発プランナーを担当していました。エンパワーメントサービス部にいたこともあります。大手ゲーム会社でトップタイトルのプランナーを1年間やっていました。

――アピリッツではなく外の会社で働くことに抵抗はありましたか?

最初は抵抗がありました。でも、大規模なタイトルでキャラクターの性能に関する設計などを経験できたり、仕事をする上での良い転機になりました。成長できたと感じますし、視野も広がりました。なにより人脈ができたんです。当時、そこの会社で知り合ったプロデューサーの方とは今でも仲良くしていただいます。人生の宝です。今はまわりのアピリッツメンバーにも「エンパワーメントサービス部で外の仕事を経験するの、いいよ。オススメ」と言ってます。

――アピリッツの魅力について教えてください!

まず、上司との会話がめちゃくちゃしやすいです。アピリッツは、風通しの良い職場だと思います。会社って、上層部の方々に声をかけづらいイメージがあるじゃないですか。アピリッツはそんな壁はなく、いつでも気軽に相談ができます。

また、やる気があれば若手でもチャレンジができるのも魅力の一つですね!実際に新卒ながら大きいタイトルを任せてもらえたり、入社して良いことしかないです。(笑)

失敗しても先輩が守ってくれるので、尻込みせずに手を挙げて経験を積むことが大切だと思います。

雑談から生まれるクリエイティブ

――黒川さんの仕事で楽しい時はどんな時ですか?

ユーザーの皆様に喜んでもらえそうなキャンペーンを考えたり、新しい遊びを考えたりしている時ですね!

あとは、開発メンバーと「よりゴエティアクロスを楽しくするためにはどうすればいいか?」を会話する時も楽しいです!

僕は雑談から生まれるクリエィティブなものがあると思っているので、うちのチームはめちゃくちゃ会話が多いです! 常に大学生の文化祭の前日の夜みたいな雰囲気です(笑)

ふだんの会話から運営の士気が上がると良いものが作れる、良いものが作れるとユーザーの皆様に楽しい遊びを提供できる、この流れを大事にしているので今のゴエクロチームは1番賑やかなチームだと自負しています!

また、「アピリッツは働きやすい」「みんな良い仲間だ」と思えるようなチーム作りを心がけています。

(社員の仲間にお菓子を配る優しさを発見しました!)

――今後の目標について教えてください!

目先の目標としては、ゴエティアクロスという作品をこれからも大切に育てていくのが使命だと思っています!

長期的な目標だと……役職にこだわらず唯一無二の存在になるべきだと思っています。自分で仕事持ってきて事業を展開して会社に利益を生む、そういうことができる人になりたいです。あと、「東京ゲームショウ」と「E3」には出たいですね!

ゴエティアクロスはもうすぐ3周年

――ゴエティアクロスはもうすぐ3rdアニバーサリーを迎えますね。ゴエティアクロスの魅力について語ってください。

ゴエティアクロスとは、「神との戦いに敗れ荒廃した世界を舞台に、世界を救うために立ち上がったひとりの魔導師の物語」になっておりまして、主人公は72柱の魔神とともに世界を旅します。最近よくあるキラキラしたファンタジーゲーム寄りの内容ではなく、ダークファンタジーな内容になっており、割とグロテスクな内容も含んでいます。そういうゲームが好きなユーザーに向けたゲームですね!

また、ゲーム内のキャラクターも魅力的ですね!最近だと、新しく外伝ストーリーとして追加した『光の異界』に登場する「サタナキア」と「アガリアレプト」の姉妹が非常にユーザーから大好評でした!

「サタナキア」と「アガリアレプト」、ユーザーの皆様から好評でした!

――最後に意気込みをお願いします!

ゴエティアクロスは9月に3rdアニバーサリーを迎えます。そのような大きな行事ごとが待っている中、プロジェクトリーダーになった自分としては、責任重大だと感じて緊張しています。

ただ、それ以上にユーザーの皆様に、めちゃくちゃ面白くて心からワクワクするような遊びを届けたい! という気持ちが強いです!実を言うと……3rdアニバーサリーで行うキャンペーンや実装は、すでに全部決まっております!過去最大規模のコンテンツを用意しております。ぜひ楽しみにお待ちいただければと思っています。

これからもゴエティアクロスは進化していきますので、今後も応援していただければ嬉しいです!

いつかはE3に!

――黒川さんありがとうございました!

アカツキ×アピリッツ共同育成プロジェクトで成長したプランナーに話をききました

0

株式会社アカツキとアピリッツは、2021年6月より新しい採用戦略のひとつである「次世代ゲームプランナー育成プログラム」を開始しました。プロジェクトの中核となるゲームプランナーを両社で積極的に採用し、育成を行います。実はアピリッツには既にアカツキのゲームプロジェクトに参加しているメンバーが多数います。彼らはどのようにゲーム開発を行っているのでしょうか? アピリッツに新卒入社し、すぐにアカツキとの開発プロジェクトに入ることになった若手プランナーの江川に、自身の仕事と成長について話を聞きました。(2021年7月 取材)

関連リリース:アピリッツ、株式会社アカツキと共同で次世代ゲームプランナー育成プログラムを開始。次世代に活躍するリードゲームプランナー/ディレクター候補を採用・育成

入社から2年のあいだに成長したこと

ーー 江川さんは新卒でアピリッツに入社したのですよね。今はアカツキさまとのプロジェクトで何を担当していますか?

2019年にプランナーとしてアピリッツに入社して、現在はアカツキさまのとあるタイトルでマスターデータの管理を担当しています。データ入力そのものは他のプランナーもできるのですが、たとえば、マスターデータの構成や、プランナーがミスなくデータを入力しやすいような仕組みを考えて管理するのが僕の主な仕事です。

他にも、テストケースを作成したり、さまざまなプランナー業務を担当しています。その中でも、マスターデータについては僕が一番詳しいので「マスターデータといえば江川!」といった形でプロジェクトに関わっています

基本、アカツキさまとの開発では、全体的に幅広い範囲で仕事を任されることが多いので、現在の僕の立ち位置は少し特殊かもしれません。

ーー アカツキさまから「江川さんはパフォーマンスが高く、伸びしろも感じる」とお褒めの言葉をいただいてます。

ありがたいことに、その噂はいろんな人から聞きます。ちなみに、僕本人はまだ直接は聞いてないんですよね(笑) 「そうなんだ!?」ってうれしいですね。

たぶん、最初から良かったわけではないと思います。実を言うと、入社当時はプランナーの仕事内容すら僕はよくわかっていなかったので。

ーー プランナーの仕事ってどんなイメージだったのですか?

「ゲーム作るんだろうな」という、非常にざっくりしたものでした。

ーー (笑)。その初歩的な状態からプロデューサーに評価されるようになるまでに、どんなことをしましたか?

プロジェクトにアサインされた初期は、僕の役割は現在ほど明確には決まっていなかったので「できるところをやっていこう」と考えて動きました。

そうしていくうちに、今まで自覚していなかった自分の特性がわかってきたんです。

ーー どんな特性ですか?

まず、思いのほか効率重視でした。誰かが仕事で困っているなら、「こうしたらいいですよ」と伝えれば、早く仕事が進むと考えました。とくにマスターデータに関わるようになってからは、自分の業務の範囲外のことでも「ここの問題は、このメンバーならわかりそう」といったふうに人と人をつなげるのが得意でした。マスターデータを管理していると、そのプロジェクトにどんな開発メンバーがいて、何をしているかがよくわかるんです。

それから、最初はデータを扱うことは得意じゃないと思っていました。でも実際にやってみたら自分に合っているなと気がつきました

意外と効率厨でした

ーー 効率厨な性格とデータの管理って相性よさそうですよね。

そうですね(笑)

開発初期、リリース、そして運営まですべて関われた

ーー アカツキさまとの仕事で学んだことってどんなことでしょう?

ゲーム開発における一連の流れを学べました。開発初期、リリース、そして運営まで関われたのは幸運だったと思います。

そういった経験は僕の糧になっています。中でもとくに印象深いのは「良質なエンターテインメントを作る上での姿勢」です。上下関係がほとんどなく、誰に対しても意見が言えて、誰の意見でもそれが良いものだとしたら、ちゃんと取り入れられる。

良いものを作るためには、自分の意見をぶつけるべきだという姿勢が身に着きました

ーー それって、江川さんは最初からできたのですか?

いえ、最初は難しかったですよ!

新卒でアピリッツに入って、いきなり他社とのプロジェクトに参加することになって、自分のプランナーとしての長所や特技がまだわからない状態だったので、何をどこまでやればいいのかわかりませんでした。

でも、まわりの姿勢を見て、自分も見習っていきました。「教えてもらう」よりも「吸収していく」スタイルだったと思います。なにより、開発メンバーがみんな優しかったんです。質問や相談事があるときに「ちょっといいですか?」と話しかければ、二つ返事で「大丈夫です!」と応じてくれる。

現在の僕の役目はマスターデータ管理ですが、僕しか知らない部分もあるので、自ら伝えないといけない。伝え方がよくないときは「わからない」とフィードバックがあります。ですから、そこからさらに伝え方を工夫したり。コミュニケーションの大切さはこうして学んでいきました。

ーー 仕事でうれしかったことって、どんなことですか?

アカツキ内の新しいプロジェクトに移るときに、元いたチームのプロデューサーからねぎらいの言葉をもらえて本当にうれしかったです。あとは「社内で評価が高いよ」といったことを人づてに聞いた時には、しみじみうれしいですね。

聞かないことには仕事は進まない!

このプロジェクトには、こんな人が向いてます

ーー アピリッツはアカツキさまと共同育成プロジェクトを始めます。実際にアカツキさまとの開発に携わっている江川さんの視点から考える「このプロジェクトにマッチする、成長できる人」はどんな人物ですか?

物怖じせずに話せる人ですね。アカツキの開発メンバーは、質問したことはきちんと答えてくれます。ですから、自分で「ここどうなってますか?」「ここどうしますか?」といったふうに、課題をちゃんと認識して動ける人は、プランナーとして伸びると思います。

聞かないと仕事が進まないですしね。

ーー 江川さんはこの2年間でどんなふうに成長したと感じますか?

まず、ゲームづくりのいろはを学んで、自分の中で曖昧なイメージだったゲーム作りの輪郭がはっきりしました。その流れで、企画書を作ったり、企画を考えることだけがプランナーの仕事ではないことも学びました。仕様書やデータを作る役目もありますし、開発メンバー同士の調整もあります。とくにデータづくりや調整は自分にマッチしている仕事だったなと思います。

そして、この2年間、プランナー業務に集中できたのもよかったなと思います。QAや外部制作会社とのディレクションといった広義の意味でのゲーム開発ではなく、ひたすらプランナーとして働くことで、自分が目指すプランナー像がよりクリアになりました。

オールマイティーに働けて、どこかしらで必ず活躍できるようなプランナーになりたいです。チームに1人いると安心感のある存在を目指して行きたいと思います。

関連:共同育成プロジェクト特設採用ページ|株式会社アピリッツ

アピリッツが報奨金総額120万円以上の「APN表彰手当」を始めた理由

0

アピリッツはデジタル人材育成とブランド力向上を目的として、2021年6月から新たに「APN表彰手当」を定めました。アピリッツのエンジニアがAWS認定資格を取得し、社内外にAWSの技術を広め、AWS JAPAN APN ブログで表彰されること奨励する制度です。従来の資格取得促進制度と合わせると、社員個人が得る報奨金は120万円を超えます。「やろう!」と決めた社長の和田と、自らも勉強してAWSクラウドプラクティショナーを取得した執行役員の西脇に話を聞きました。(2021年7月 取材)

関連プレスリリース:「アピリッツ、DX時代におけるAWS活用の推進とデジタル人材育成、ならびに福利厚生の拡充を目的に、社内制度『APN表彰手当』を制定。AWSエンジニアに報奨金を年間最大121万5千円支給」

関連記事: 【2021 APN AWS Top Engineers」選出】アピリッツのAIエンジニア・浅田大輔インタビュー「資格と実際の開発とのギャップをいかに埋めていくか」

技術力の高さをもっと知ってもらいたい

社長発案でした

ーー AWS認定資格については、もともと「資格取得促進制度」で報奨金が設定されています。ここからさらに「APN表彰手当」というインセンティブに踏み込んだ理由を教えて下さい。

和田:アピリッツのAWSパートナー企業としての知名度を上げたい、というのが一番の理由です。AWSジャパンから当社や当社で活躍するエンジニアがご評価いただければ、AWSを活用した開発に強い企業であることを、お客様により一層ご認知いただけます。アピリッツが全社を挙げてAWSに強いエンジニアを育てていること、そして営業に力を入れていることをアピールしたかったのです。

それに、実際にAWS JAPAN APNブログに社名やうちの社員の名前が出ると、うれしかったんですよね。

ーーはい、うれしかったです。

和田:我々にAWSの技術力があることと、お客様に高い品質のサービスをご提供できていることの証明の1つですからね。

私はかねてよりアピリッツを「自分が頑張れば、自分に返ってくる環境」としたいと願って動いています。その一環として、社員自らが勉強することを促すために「資格取得促進制度」を整えました。それに対して、今回の「APN表彰手当」は、会社のブランド力をより上げていくために必要な制度であると考えています。

「APN表彰手当」の社内の反応は?

西脇です。全社で取り組んでます!

ーー 「APN表彰手当」発足後、社内にどんな変化がありましたか?

西脇:社内のSlackで「#aws試験対策本部」という、そのままズバリな名前のチャンネルがあるんですが、ここの参加者が増えました。とくにWebソリューションセグメントのエンジニアだけじゃなく、オンラインゲームセグメントのエンジニアも積極的に参加してくれるようになったので、とてもうれしいです。「APN表彰手当」の報奨金のインパクトもあったでしょうし、全社で取り組んでいるんだなと感じてもらえたのかなと思います。

ーー 「AWS認定資格を全部取るのは大変」といった声も上がっていますが……。

西脇:うん、大変だと思いますよ! でも「全部取る」ことを目標にしないと、人間そうそう全制覇なんてしないものだと僕は思っています。「忙しい」とか「今の自分の仕事に役に立つかわからない」とか、やらない理由がいくらでも出てきますから。

ーー  西脇さんは自分でもAWS認定資格を取りましたよね。

西脇:そうそう。「僕にもできたんだから、みんなできる。まずは挑戦してみよう」と言いたかったですし。先ほどお話ししたSlackチャンネル「#aws試験対策本部」に手書きの勉強ノートを公開したり、楽しかったです。

西脇さんの勉強ノート。1つのテーマを1ページにまとめるのが西脇ルール

プレミアコンサルティングパートナーを目指す

ーー 「APN表彰手当」の目的は「アピリッツの知名度向上」です。この知名度アップに加えて、西脇さんが考えるメリットは何でしょうか?

西脇:まずは「組織としての強さ」をアピールできるのは、いいことだと思います。「優秀な個人のエンジニアがいます」に留まらず、チームとしても強いってことですから。

さらに、AWS 認定 (Certifiation) プロフェッショナルや専門知識をもったエンジニアが増えると、アピリッツがAWSの「プレミアコンサルティングパートナー」となる道がさらに拓けます(現在のアピリッツは、その1つ手前の「アドバンストコンサルティングパートナー」です)。

プレミアコンサルティングパートナーになれば、よりAWSの技術を深めていけますし、仕事も増えます。お客様とアピリッツとエンジニア本人、すべてにおいてメリットがいっぱいある。

エンジニアのみなさんにとって「APN表彰手当」のハードルは決して低くはありませんが、無理な話じゃないと僕は考えています。そして、私達アピリッツがプレミアコンサルティングパートナーを目指すことは、ちっとも無茶な話ではないと思っています。ということで、組織としてはプレミアコンサルティングパートナーを狙っていきます!

【ゲーム制作の現場から】 02:世界観設定のコト始め

0

前話「01:RPGシナリオのコト始め」の続きです。今日はゲームシナリオの梁(はり)となる、世界観設定の考え方について書いてみます。

■世界観設定とは、なんぞなもし

◎ 情報は大きなカテゴリー分けから始めよう 

 有名ファンタジーRPGのポスターや広告、パッケージ。
 ひと目みれば、どんな世界なのか、ガツンと伝わってきますよね。

 表現内容を分解すると、メインビジュル、ロゴといった画像情報
 タイトル、キャッチコピー、会社名などのテキスト情報があるはずです。

 世界観を伝えるために、視覚的に飛び込んでく情報の構成とは?

 見て感じる「ビジュアル」、読んで理解させる「文字情報」。2つの大きなカテゴリーに分類できるのです。

◎ 情報構造体の把握

 例えば、「崖に立つ少年が遥か遠くの城を見つめる」ファンタスティックなビジュアルがあったとします。(いい感じのビジュアルを、頑張って想像してください。)

何もないとイメージが沸かないかもしれませんので、叩きを……カキカキ

 どうでしょう? 「なぜそう感じたのか?」を分析。構造体を意識すると、ふわっとした印象から、さらに世界が見えてくるはずです。

 少年は何者なのか? 生い立ち、家庭環境、なぜそこにいるのか?

 少年の”物語”を表現するために必要な、彼が生きる文明・文化、自然の世界構造(ワールドストラクチャー)を決める。

 それが「世界観設定」です。

◎ 視覚情報の整理

 では「崖の上に立つ少年が、森林の彼方に建つ白亜の城を見ている」という設定を立て、具体的な情報に落とし込んでみます。

 描かれている地形から場所、天候から時間、登場人物の見た目から年齢、装備や装束の小道具から身分や役割(職業)、といった構造を整理できます。

 ※シナリオにおける、人間や物事との相関関係は「キャラクター設定/舞台設定」と定義します

■世界構造を考える前に認識しておくべきこと

◎ 舞台があって登場人物があらわれる

 先例に出した少年がゲームの主人公で、剣と魔法の世界の住人。「騎士試験を受けるため、都に向かっている」とします。

 これを大カテゴリーに分けると、「場所」と「登場人物」になります。

 舞台があって、そこでキャラクターに(ゲームシステム上で)芝居をさせる。ゆえに、世界構造を決めるには、ふわりとでも脚本(シナリオ)も考えている必要があります。

 登場人物の設定があり、「どんな物語が何時(いつ)何処(どこ)で展開されるのか?」適切な場所と時間を選び、舞台を用意するのです。

ゲームでは舞台も役者も自在に作れるが、芝居に苦労する

 さて、さきほどのイラスト例を思い出しください。
 少年のビジュアル、舞台に必要な要素をイメージして、世界構造を考えてみましょう。

■自然環境に適応しながら、文明は育った

◎ ひとの世界は複雑系

 「少年が騎士試験を受けに行く」シナリオ設定なので、軍の規模・存在理由は必要となります。

 人を描くのですから、人物像があり、生い立ちに沿った衣食住の文化が根付いています。その地域の何を食べて、どんな言語や文字を使うのか。自然環境にあわせた家の構造、生活様式、季節行事や装飾品、楽器や娯楽もあるでしょう。武器や道具を使うならば、技術力や機械工作や鋳造技術に沿ったビジュアルも想定すべきです。

 人が意思疎通してより良い生活を求めると、市が立ち、街となり、国家となります。技術や政治形態が進歩して、文明レベルを押し上げます。国家のイデオロギーは、対立や戦争を産み、政治・経済・司法のありかたを変化させます。

 社会の遷移から騎士団の存在が明確になり、目的や背景がボンやりすることを防ぎます。

ヨーロッパの町並みには、暴力の歴史が刻まれている

◎ 世界は自然の中にあり、物理法則が働く

 気を配るのは、人間の環境だけではありません。

 文明圏をとりまく自然環境があります。モンスターを含む動植物には食物連鎖があり、生息地(コロニー)や縄張りが存在します。地形は天候に影響し、大気の変化は四季のサイクルにつながります。季節は農業や狩り、人や荷物の移動、祭儀といった生活に直接影響します。

 自然が生み出す資源や地理的な影響。それは国家間の戦争や驚異に対する、地政学的なリスクと密接に関わります。

◎ 魔法は熱力学に従わない

 そしてファンタジー世界の醍醐味、熱力学の法則を捻じ曲げる魔法のルールは、取り扱い注意品目です。

 魔法という謎の言葉は便利ですが、魔法の成り立ちや、発動原理(ロジック)、効果、特性を決めないと、作中のリアリティを殺すことになるので注意が必要です。

テーマやシナリオにあわせて、必要な項目をカテゴライズして情報を書く

■世界はどこまでも続く

◎ 深堀りは蟻地獄の砂

 テーマやシナリオプロットに沿って、「文明(ひとが創ったもの)、自然、魔法系のアンナチュラル」の大きなカテゴリーに分類。細分化して設定を組むと、「あっ、これ考えるの抜けてた!」ということが少なくなります。

 しかし、細かな設定を深堀りすると、関連項目が増え、情報量が肥大化します。
 情報の重複がなく、きれいに読める資料化はとても大切です。作る方は楽しいですが、読む方は興味がないのですから。

◎ 情報流通は見やすさにつながる

 なので、攻略本か設定資料集でも書くつもりで台割(※目次のようなもの)を切り、情報の優先度や情報流通の最適化しましょう。この配慮は、愛される資料作りにつながります。時間がない場合でも、開発に着手するために必要な情報から、優先的に構築しましょう。

 設定のないクリエイティブなんて、意味がありません。きちんと資料を作成しておくことは、必要なことです。

 もちろん叩き台レベルであれば、凝った設定は必要なく、「現代日本風」とか、「13世紀ヨーロッパのプロイセン風」、っと共有資料に短く書いておくだけでも問題ありません。ただし設定者は中身を十分に練っておかないと、ビジュアルの発注でトンチンカンな指示を出したり、誤りに気がつけません。

◎ 困ったら歴史から学べ

 世界を構築する資料を作るには、文化人類学を中心に、歴史、雑学が役立つことがあります。するすると思い描いたものが資料化できればいいのですが、困ったときは歴史や過去の文明、記録を参考に発想を広げるのがよいでしょう。

 歴史は人が歩んだ記録ですから、リアリティがあり、おかしな事になる率が少ないのです。

 特に西洋ファンタジーの分野では、剣と魔法要素がでてきます。地域別の文化に民族の生活様式、その中で行われる祭儀、伝えられる神話、宗教の歴史情報は発想の視野を広げてくれます。

戦いの歴史は経済、宗教、政治、地政学と絡み合い、調査対象は果てしない

■「すべては芝居のため」

 世界観とは物語と共にあり、設定は物語を構築するための補強材(または柱や梁)の役割を果たしていると言えます。

 最後にあらためて。シナリオを補完する世界観設定がなぜ必要なのか?
 その本質は、書いた本のお芝居を成立させるためです。

 キャラクターに芝居をさせるためには、舞台や環境にあったビジュアルが必要となり、動作させるシステムが必要になります。そのすべては設定資料から生まれるのです。

 一言で相手に伝えられる強固な世界観をつくるためにも、妄想力を膨らませ、物語の表現を支える美しい世界構造を紡ぐ。それが設定者の役割です。

※※ 次回は「シナリオ執筆のコト始め・企画編」です

ゲームの世界観やシナリオ制作、専門学校など教育現場での指導についてのお問い合わせを受け付けております。
総合お問い合わせフォームから「シナリオ・鈴木」宛にご連絡ください。

【2020新卒対談】入社して1年。実際に働いてみてわかった嬉しい誤算とは

0

今回は2020年に新卒としてアピゲー部(自社開発ゲーム部)に入社したプランナーとデザイナーの二名に入社の理由や実際に入ってみてどうだったか、話を聞きました!(2021年6月取材)

――簡単に自己紹介をお願いします!

今村:アピゲー部、今村と申します。学生時代は漫画制作を中心に、演劇、映画、文芸など様々な媒体での表現活動をしていました。デザインのゼミに所属したり、大学卒業後1年間CGの専門学校に通ったりもしました。その後、専門学校在学中にインターンとして「アンノウンブライド」のデザイナーとして入社し、今に至ります。現在ではデザイナーとしてUI以外のデザイン業務を主として、他にも何度かイベントのネタを提案したりシナリオを書いたり……様々な角度からタイトルに関わらせていただいています。

石田:同じくアピゲー部でプランナーをしております、石田です。今村君と同じタイトルのゲームを担当しています。地元(大分県)のゲーム系の専門学校を卒業してアピリッツに入社しました。専門学校ではITエンジニアの登竜門である「基本情報技術者試験」に合格し、また、C#とUnityの基礎を学びました。ちなみに中学時代から式姫のファンです。

右の石田さんが着ているTシャツのデザイン、実はアンノウンブライド……

――お二人のアピリッツに入社した経緯や理由を教えてください!

今村:学生時代、様々な媒体での表現に触れた結果として、ゲームというメディアの面白さや可能性に惹かれていました。そのことから、ゲームを制作している会社で働きたいと決めていました。会社選びでは、オリジナルIPを扱っていることを絶対条件に、会社を探しました。『ゴエティアクロス』のコンパクトながらツボを突いてくるような設計と、『かくりよの門朧』のような和風世界観での挑戦的制作に惹かれ、アピリッツを志望しました。

魅力的なゲームを作っている会社は多数ありますが、ホワイトな社風や、スタートアップ的なやる気があれば挑戦できる風土があるということが、アピリッツに入社しようと思う決め手になりました。

石田:式姫が好きという熱意のもと、専門学生の頃から第一希望をアピリッツに決めていました。無事、学生時代からの片思いが実りました!

――実際入社してみてどうでした??

石田:入社したては下積みというか、もっと地味な仕事ばかりかと思いきや、色々なことを任せてもらえて嬉しい誤算でした!

今村:わかる!!会社全体の事でいえば、様々な事業部の活躍により安定的に挑戦できる環境が構築されていることには感嘆せざるを得ないなと感じています。

石田:あと上下関係はあまりなく新人の意見も直接反映されるような文化もあるよね。

デスクが広いのでディスプレイ2つも置けちゃいます!

―― どんなときに「働いていて楽しい」と感じますか?

今村:毎日が刺激的で楽しく時間の経過が凄く早く感じます。特に、ユーザーの皆さんに反応をいただけると殊更に楽しい気持ちになります。直近だと、自分が書いたシナリオの一場面をユーザーさんがイラストにしてくれていて、物凄く嬉しかったです!また、やりたいことに挑戦させてもらえるのは有難いし面白いし楽しいです。

石田:僕はできないことが、できるようになり成長を感じた時が楽しいです。

ホーム画面に式姫が!

――アピリッツの社員てどんな印象?

石田:同期の皆さんの人柄の良さに感動しました。先輩社員は優しくしっかりしていて、目標にしたい先輩がたくさんいます。

今村:わかる……!アピゲー部の部長の吉田さんは、データドリブンで冷静な判断を下しながらも、やる気や熱意はしっかり受け止めてくれてくれる方です。そのため信頼ができて上司として最高です。(吉田さんのインタビュー記事はコチラ)

――今後の目標について教えてください!

今村:ゲームの世界観表現を根本から任せてもらえる人材になっていきたいなと思っています。究極的には、できるだけ多くのユーザーのセカイを変えてしまうような、そんなゲームが作りたいです!

石田:「式姫」を有名なIPにするヒット作を産み出します!

――最後にアピリッツを受ける学生さんに一言!

今村:ワークアズライフにサラリーマンができる面白い環境だと思います!楽しいです。

石田:アピリッツは、未経験でもチャンスがあります!

――お二人ともありがとうございました!

最近人気な記事