ホーム ブログ ページ 8

「グッズは出る?」「まだ続くよね……?」 ゴエティアクロス、ユーザーから頂いたご質問に開発チームが答えます!

0

アピリッツのオンラインゲーム『ゴエティアクロス(ゴエクロ)』は、もうすぐ3.5周年を迎えます。もっともっと盛り上げて末永く愛されるコンテンツにしたい……ということで、ユーザーの皆さまから寄せられた質問に、プロジェクトリーダーの黒川が正直にバンバンお答えします!(2022年1月 取材)

ゴエクロの設定資料集やグッズみたいなものを出す予定はありますか?

皆さまからのご要望が多ければ、検討はしていきたいですね! 一般的な販売というより「完全生産受注」とかなら可能そうですね!

そろそろ前作で出てきたキャラクターが終わりそうですが、この先はあるのでしょうか?

そうですね。外伝で新キャラクターをどんどん実装したり、ゴエクロのメインストーリーで出てくるキャラクターを実装したりなど色々検討していますので、まだまだ先はあります!

コラボとか最近ないですが、予定とかありますか?

アピリッツのオリジナルタイトル(例えば式姫など)とコラボできたらいいなと思います。それとは別に外部のゲームやアニメのコラボも現在検討中です。お楽しみに!

アプリが重すぎてまともにゲームができないことがあります! 改善して……?

ゴエクロは様々なプラットフォームで展開しており、原因特定にかなり時間を要しています…。ユーザーの皆さまからご指摘をいただいていることは重々承知しております。

現在も原因調査を1つずつ行い、原因特定を急いでおります。進展あり次第ご報告させていただきます。

※現在は「読み込みが重いため落ちてるのでは?」と仮説を立て「手始めにエフェクトチップから、グラフィックリソース周り少しずつ軽量化模索中」になります。

盤想戦などのコンテンツのテコ入れはありますか?

テコ入れの予定はあります! 盤想戦でのテコ入れについては、出現するエネミーを更新したり、盤想戦イベントのようなものを開催する予定です。また、その他のコンテンツも順次テコ入れをしていく予定です!

声がついていない魔神に、今後ボイスがつくことはありますか?

現在ボイスがついていないRやNの魔神達には順次つけていくことが確定しております! ただ、コロナ渦で収録もなかなかできないため、時間はかかるかなとは思います。
どの魔神からボイスがつくかはお楽しみということで!

露店や交換所などのアイテムのリニューアル予定はありますか?

3.5周年のタイミングや、他のキャンペーン時に、アイテムや価格の見直しをして整えていきたいと思います
また、ユーザーの声でご希望が多い「金の転輪」に関しても、ラインナップや交換できるUR魔神の供物の対象魔神の更新等も行う予定です。

去年はロードマップがあったけど、今年はロードマップないの?

ロードマップに関しては、3.5周年付近と4周年付近で公開いたします。
年2回は更新していきたいと考えています。

ゴエクロってまだ続きますよね……?

はい! まだまだ続きます! メインストーリーの天界との戦いは佳境を迎えつつあります。しかし、その後も新しい形でゴエクロの世界が続くように協議しております。
また、運営一同も元気いっぱいなのでご心配無用です!

今後もこんな感じでQ&Aを公開していきます。これからもゴエティアクロスをよろしくお願いいたします!

コロナ中でも社員同士のつながりを大事にしたい

0

コロナが少し落ち着き始めていた2021年の後半。アピリッツでは社内懇親会を始めました。この懇親会は、プロジェクトをまたいで社員同士のつながりを育むことを目的としていました。プレゼント企画をやったり、いろいろ楽しかったんですよ。現在は残念ながら再び感染症のリスクが高まってきたので懇親会やカフェの運営は休止しています。仕方のないことですが、やっぱりさみしい! ということで、社長の和田発案のもと、お菓子を配ってます。(2022年1月取材)

オフィスに無数のお菓子たちがやってくる

せっかく配るのならば社員みんなにキッチリ配りたい! という懇親会運営チームの確固たる意志によって、シュークリームやエクレアといったみんなが好きそうなお菓子が発注されました。その数およそ数百。社員全員に行き渡らせるにはそのくらい必要です。が、時を同じくして、感染症対策のために原則リモートワーク中心に勤務体制が切り替わったところでした。全員が一斉に出社する日はありません。じゃあ、あのお菓子たちは一体どうなっちゃうんだろう……と密かに胸を痛めていたアピ社員は大勢いたはず。

幸いなことに賞味期限に余裕のあるお菓子もあったため、数日に分けて配ることになりました。

お菓子のチカラは偉大

配り方も工夫しています。社内のSlackで「この時間帯にフロアのXXに置いてます。本日はシュークリーム・どらやき・エクレア・バームクーヘンです。ご自由にお持ちください!」とアナウンスがなされたあと、その日に出社している社員たちが密を避けつつお菓子をピックアップしていきます。ちなみに、今回のお菓子のセレクションは、アピリッツのスイーツ番長ことクラウドインテグレーション部部長・剣持が監修しました。

ある日のかわいいお菓子たち。一箇所に集まりすぎないように、社内の数カ所に置いてます。

お菓子って人を笑顔にするパワーがあるんですよね。会話はしづらい状況ですが、エンジニアやデザイナーたちがニコニコしながらどらやきやチーズケーキを抱えているのを見るだけで幸せな気持ちになります。「やってよかったな~」と運営チームもホッコリしているそうです。

コミュニケーションをどう取っていくか、社員同士のつながりをどう大切にしていくか、悩ましい日々が続きますが、試行錯誤を続けていきます。

「バリューを一緒に作っていきたい」ムービングクルー代表・五島正道インタビュー

0

2022年1月から株式会社ムービングクルーがアピリッツのグループ会社になりました。ムービングクルー代表の五島に、アピリッツにジョインを決めた理由やこれからアピリッツで挑戦したいことを聞きました。(2022年1月取材。聞き手・アピリッツCDXO西脇)

相談できる相手ができた

西脇:ムービングクルーの皆さんがアピリッツに参画してもうすぐ一ヶ月たちます。机を並べて仕事をしたり、打ち合わせに同席したり、共に過ごす時間が増えていますが、アピリッツってどんなふうに見えますか?

五島:ジョインする前からの和田さんや経営陣のみなさんとの対話でも感じていたことですが、若い勢いに満ちているなと思います。志やモチベーションを持ってやっている人は若いな、と。ものを作り出していく場面で必要とされる若さだと思います。

西脇:ゼロから作り出すフェーズって、上手に運営をまわしていくフェーズとは違ったものが求められますよね。

五島:アピリッツと一緒になろうと決める後押しにもなりました。M&Aに向けて対話を重ねるたびに「私達と同じ香りがするな、感覚が近いな」と思うことがたくさんあって、私自身がふつうの感覚で話せましたし、ムービングクルーの社員がステップアップして、組織を大きくしていくことを考えると、アピリッツへのジョインはもうこれしかないっていうチョイスでした。

西脇:Web周りのフィールドであったり、受託開発をしていること、いろんなお客様と一緒にビジネスをしてきたこと、そのあたりの経験で重なるところが沢山あるなと私も感じています。

五島:ムービングクルーを設立して16年、アピリッツに加わることで相談できる仲間ができたなと感じています。心強いです。

実は、知り合いからは「M&Aで自分の会社を譲渡するとマリッジブルーみたいな気持ちになるよ」と言われていたんですよ。でも、アピリッツにジョインすると決めたあと、ぜんせんそんな気持ちにはなりませんでした。「ぜひ一緒になりたい!」と思って動きました

西脇:それはよかった。僕自身もかつて事業売却してアピリッツに参加しました。そのときいっしょにジョインした仲間は、今も全員アピリッツでそれぞれ活躍しています。その様子を見ていると「あのときの自分の選択はやっぱり正解だったんだな」と思える。ですから、五島さんがそういったことを実感するまでにはもう少し時間が必要かもしれませんが、まずはよかったなと思います。

調印後、代表和田と五島氏で握手

ファンサイトの開発・運営への本質的な理解にバリューを出したい

西脇:さっき五島さんが「私達は同じ匂いがする」と言ってくれましたが、同じ匂いがしつつも、ムービングクルーの事業はアピリッツにはない領域で、それがいいなと思っています。

五島:エンタメ系のファンクラブビジネスに関連する事業が多いです。

西脇:エンタメ系のビジネスって動きがすごく速い印象ですが……

五島:独特のスピード感がありますね。ずっと開発を続けてきたので、お客様からのご相談を伺ったら、持ち帰らずにその場ですぐに「つまり、こういう設計ですね」と話を進められます。

西脇:その知見って一朝一夕じゃ身につかないですよね。しかもファンクラブビジネス以外の開発もずっとやっていますよね。

五島:はい、大手メーカーさまの研究開発など、エンタメとは違った分野の開発も行ってきました。エンタメだけじゃないというのも、うちの強みです。

西脇:そういったムービングクルーが持つ特性や、ファンサイト開発と運営の本質的な理解って実はなかなか手に入らないものなんです。だから、今回のアピリッツとのM&Aによって、さらにバリューを出してほしいです。

業務的な経験値ってなかなか明文化しづらいものですが、「アピリッツに任せると運営がよくなった」とお客様に実感して頂けるような、そういったトータルでの強みがバリューだと考えています。

五島:まさにそういうことができると思ってM&Aに踏み切りました。

自分の得意なことに固執しない人

西脇:五島さんはどんな人と一緒に働きたいですか?

五島:踏み出す勇気のある人がいいなと思います。一歩踏み出して、もし壁にぶち当たっても「10年後20年後こうなりたい」と考えて自分で突破できる人です。なので、たとえば「この言語を使えます」というアピールを受けても、そこはあまり重視しません。

西脇:わかります、「複数言語使えます」って、ちょっと乱暴に言うとどうでもいい話なんですよ。

五島:プログラミング言語って誰かが作ったものです。その言語の上でやっているだけだと思いますし、技術の世界ではゲームチェンジが多い。ですから、自分の得意なことに固執しない人のほうが強いなと感じます。

西脇:五島さん自身はプログラミングが好き?

五島:好きですね。今でも家で仕事と関係ないことをちまちま書いていたりします。クラウドが出てからエンジニアの世界はがらっと変わったと思いますが、それはそれで面白いです。無数のサービスが出ているので、それらを見るのも楽しい。

話を戻しますと、言語や技術の世界は変化の流れが速いです。だからこそ、その人がどういうことを考えて、どういう仕事をしてきたかを知るのは大切だと思います。

なので、採用面接で変に取り繕うくらいなら「お金がほしいから」って正直に言ってもらったほうが「ああ、そうなんだね!」って受け止めて先の話ができる(笑) メッキってどんなに頑張ってもやがて剥がれてしまうものなので。

3年後5年後に、他社に転職できて、大きなことに挑戦できる可能性のある人がいいですね。

西脇:うん。で、3年後5年後にアピリッツももっと大きくなっているから、そのエンジニアがステップアップを考えたときに「あれ、アピリッツにいたままでも大きなことに挑戦できるな」って思ってもらえますからね。

五島:一緒にやっていきましょう!

Excel関数:XLOOKUPについて (アピリッツCREATORSナレッジベース)

0

アピリッツのオンラインゲーム事業でクリエイター派遣を担っている「エンパワーメントサービス部(ES部)」。このES部を中心としたデータベース「CREATORSナレッジベース」からのおすそ分け記事です。今回はプランナーとしてマスターデータの管理を担当している毛塚 孝さんのナレッジです。(2022年1月 取材・作成)

今回のナレッジベースの作者
” 毛塚 孝 ”さん
プランナー。
ゲームサウンド、シナリオ、ゲームデータ作成を経験後、アピリッツに参加。
得意分野はExcelなど使ったマスターの最適化やデータ作成。
好きなゲームはボードゲーム。

XLOOKUP とは

XLOOKUP関数は、「VLOOKUP」や「HLOOKUP」の上位に当たる関数です。

「VLOOKUP」や「HLOOKUP」と同じ検索結果を求めることができ、さらに「VLOOKUP」ではできなかった、検索値より左のセルの値をとることも簡単にできます。

同様に、「HLOOKUP」ではできなかった検索値より上のセルの値をとることもできます。
設定項目も増え、工夫次第で色々な使い方ができます。
ここでは、基本的な使い方、各項目の設定のやり方やちょっとした応用を書いていきたいと思います。

ちなみに「XLOOKUP」はoffice365のサブスク版、office2021(買い切り)で使えます。
それ以前のExcelでは使用できないので、XLOOKUPを使う際は自分以外のExcelのバージョンに注意が必要です。

XLOOKUPの書き方

XLOOKUPでは6つの項目を設定します。後半3つは省略可能です。

=XLOOKUP(検索値,検索範囲,戻り範囲,見つからない場合[省略可],一致モード[省略可],検索モード[省略可])
  • 検索値:どんな内容で検索するか。
  • 検索範囲:「検索値」のある範囲を指定。「VLOOKUP」のように「A1:E10」のような範囲で指定せず、「A1:A10」や「A:A」のように列(まはた行)で指定する。
  • 戻り範囲:取り出したい内容のある範囲を指定。
    •  「検索範囲」と同じ幅を指定する。例えば検索範囲を「A1:A10」とした場合に「C」列に取り出したい値があるなら、「C1:C10」という形で指定する。
    •  「A:A」ならば「C:C」と指定する。
    • ※「検索範囲」と「戻り範囲」は実際の数式では場所を固定するために、以下のように「$」を入れて指定箇所を固定すると数式をコピーしたときにずれなくなるので、入れましょう。手打ちで入れるほか、範囲指定時に「F4」を押すと固定できます。
$A$1:$A$10
  • 見つからない場合[省略可]:「検索値」で検索した内容が見つからない場合の処理を指定。「”検索内容がみつかりません”」というように「”」で括った文章の指定や、数式を入れて見つからなかった場合の処理を入れられる。
  • 一致モード[省略可]:以下の数値を設定することで、「検索値」に対しての検索のルールを指定できる。
    • 0:「検索値」と完全に同じ内容で検索。「検索値」が見つからない場合は「#N/A」エラーになる。「一致モード」を省略した場合は、この設定になる。
    • -1:「検索値」と「検索範囲」が数値の場合に有効。「検索値」が見つからない場合に、「検索範囲」にある値で「検索値」の次に小さい値を「検索値」として検索する。
    • 1:「検索値」と「検索範囲」が数値の場合に有効。「検索値」が見つからない場合に、「検索範囲」にある値で「検索値」の次に大きい値を「検索値」として検索する。
    • 2:「検索値」で「*」や「?」などのワイルドカードを使って検索できるようにする。この指定をしないとワイルドカードが使えない。
    • ▼ワイルドカードを使った指定の方法:ここでは「*」と「?」を説明
      • *:検索値に「”*A”」、「”A*”」、「”*A*”」といった形で指定することで、「A」の前後の「*」のある方向にいずれかの内容があっても、その内容を検索する。
      • 「”*A”」なら「123A」、「あいA」などの任意の内容の後ろにAがつくものを「検索値」としてを検索する。
      • 「”A*”」なら「A456」、「Aかき」などのAの後ろに任意の内容があるものを「検索値」として検索する。
      • 「”*A*”」なら「あいうA123」のように「A」を含む内容を「検索値」として検索する。
      • ?:任意の値として指定する。「”A?C”」、「”AB??E”」などの形で指定し、「?」1つにつき1文字分を任意の内容があるものとして検索する。
      • 「”A?C”」なら「ABC」、「AあC」などを検索し、「”AB??E”」なら「ABCDE」、「ABかきE」などを検索する。
      • 「?」の文字数が合わない場合はエラーになる。
  • 検索モード[省略可]:以下の数値を設定することで、「検索範囲」の検索の方向を指定できる。
    • 1:「検索範囲」を上から、または左から検索する。
    • -1:「検索範囲」を下から、または右から検索する。
    • 2:「検索範囲」がすべて数値で、それが昇順である場合、検索の速度が速い計算をしてくれる。データ量が相当多い場合に有効な設定。「検索範囲」が数値でないとエラーになる。
    • -2:「検索範囲」がすべて数値で、それが降順である場合、検索の速度が速い計算をしてくれる。データ量が相当多い場合に有効な設定。「検索範囲」が数値でないとエラーになる。
    • ※省略可能箇所で、一部を省略してその後ろを有効にしたい場合、例えば、「見つからない場合」と「一致モード」を省略して「検索モード」で下から検索する設定にしたい場合は以下の様に指定する。
=XLOOKUP(A1,A1:A10,C1:C10,,,-1)

XLOOKUP書き方色々

■縦方向に指定した「戻り範囲($B$2:$B$6)」の、「検索値」のある行の内容とる場合

=XLOOKUP(H3,$A$2:$A$6,$B$2:$B$6)

■ 横方向に指定した「戻り範囲($B$4:$F$4)」の、「検索値」のある列の内容とる場合

=XLOOKUP(H3,$B$1:$F$1,$B$4:$F$4)

■ 「検索値1」で指定した縦の「検索範囲」に対して「検索値2」で指定した横の「検索範囲」の交わる箇所を求める

=XLOOKUP(H3,$A$2:$A$6,XLOOKUP(I3,$B$1:$F$1,$B$2:$F$6))

「XLOOKUP」を2重に使用することで、列と行の内容を指定して表の位置を求めることができます。

後半の「XLOOKUP」の書き方が、上記までの書き方と少し違います。

XLOOKUP(I3,$B$1:$F$1,$B$2:$F$6)

後半では「検索値:C」で「C」の列を指定し、以下のように表の範囲を指定すると、この数式は「D2:D6」の範囲を持ちます。

検索範囲:$B$2:$F$6
XLOOKUP(I3,$B$1:$F$1,$B$2:$F$6)

を独立してセルに入れると、上記画像のようにCの範囲が表示されます。
ちなみに数式は「D9」のセルに入れていますが、その下のセルに自動で値が入ります。

■ 「見つからない場合[省略可]」の使い方

・エラーの場合に文字列を返す:A列に「検索値」が無い場合に「対象の値は存在しません。」と表示する。

=XLOOKUP(H3,$A$2:$A$6,$B$2:$B$6,"対象の値は存在しません。")

・エラーの場合に数式を返す:「IF」関数を用いて、A列に「検索値」が無い場合に、5より大きい値の時は「入力の数値を5以下にしてください」を、1より小さい時に「入力の数値を1以上にしてください」を表示する。

=XLOOKUP(H3,$A$2:$A$6,$B$2:$B$6,IF(H3>5,"入力の数値を5以下にしてください","入力の数値を1以上にしてください"))

※上記数式では「1より小さい場合」を記載していないが、そもそも前の式で検索値1~5が引っ掛かり、IFで5より大きい数値の場合を指定しているので、1~5と5より大きい値ではない場合が1より小さい値になるので、記載がなくても求められる。

■ 「一致モード[省略可]」の使い方:「検索範囲」が数値の場合に有効

・「検索値」が見つからない場合に次に小さい箇所を求める。

下記の場合、「3.5」が検索範囲に無いので次に小さい「3」の箇所を求めている。

=XLOOKUP(H3,$A$2:$A$6,$B$2:$B$6,,-1)

「検索値」が見つからない場合に次に大きい箇所を求める。

下記の場合、「4.5」が検索範囲に無いので次に大きい「5」の箇所を求めている。

=XLOOKUP(H3,$A$2:$A$6,$B$2:$B$6,,1)

■ 「一致モード[省略可]」で「2」を指定した場合のワイルドカードの書き方

「検索値」で「”*き*”」と指定して「検索範囲」に「き」が含まれる箇所を求める。

=XLOOKUP("*き*",$A$2:$A$6,$B$2:$B$6,,2)

「検索値」を他のセルを指定し、「検索範囲」でそれが含まれる箇所を求める。

=XLOOKUP("*"&H3&"*",$A$2:$A$6,$B$2:$B$6,,2)

「検索値」で「”く?こ”」と指定して「検索範囲」に「く」と「こ」の間に任意の位置文字のある箇所を求める。

=XLOOKUP("く?こ",$A$2:$A$6,$B$2:$B$6,,2)

■ 「検索モード」の使い方

・「検索範囲」に同じ内容が含まれているとき、「検索モード」で「2」を指定することで、「検索範囲」を下から検索する。
 下記の場合は、「H3」のセルに指定した「2」を「検索値」として、「検索範囲」を下から検索しているので、「B5」セルの箇所が求められている。

=XLOOKUP(H3,$A$2:$A$6,$B$2:$B$6,,,-1)

・「検索範囲」に同じ内容が含まれているとき、「検索モード」で「-1」を指定することで、「検索範囲」を右から検索する。
 下記の場合は、「H3」のセルに指定した「B」を「検索値」として、「検索範囲」を右から検索しているので、「E1」セルの箇所が求められている。

=XLOOKUP(H3,$B$1:$F$1,$B$2:$F$2,,,-1))

違う列の内容を「検索値」としてそれぞれの列の内容を「検索値」として1つずつ指定してそれらがどちらもある「戻り範囲」の内容を求める方法

・「検索値」と「検索範囲」を「&」で繋いで設定することで、それらの「検索値」がすべてある「戻り範囲」の内容をとることができる。
以下の場合は「検索値1(4)」と「検索値2(う)」がどちらもある「戻り範囲」の「C5」セルの箇所が求められている。

=XLOOKUP(H3&I3,$A$2:$A$6&$B$2:$B$6,$C$2:$C$6)

・上記に加え、横の「検索範囲」も指定する場合

=XLOOKUP(H3&I3,$A$2:$A$6&$B$2:$B$6,XLOOKUP(J3,$C$1:$F$1,$C$2:$F$6))

・「検索値」2つ+横の「検索範囲」も指定する場合

=INDEX($C$2:$F$6,MATCH(H3&I3,$A$2:$A$6&$B$2:$B$6,0),MATCH(J3,$C$1:$F$1,0))

アピリッツCREATORSナレッジベースから:【初心に】文字間・行間・間隔の話を雑に簡潔に【帰ろう】

0

アピリッツのオンラインゲーム事業でクリエイター派遣を担う「エンパワーメントサービス部(ES部)」。このES部が中心となって作っている「CREATORSナレッジベース」というものがあります。仕事で身につけたことや感じたことを、アピリッツのゲームセグメントのメンバーで共有する秘密基地のようなスペースです。
「会社をどんどん成長させていくには、若手も中堅もベテランも、全員が協力する必要があります。そこで重要となるのは、情報共有のベースです!」というES部の村上の熱い熱い情熱によって2021年のある日に誕生しました。ほんと、いい内容がいっぱいあるんです。なので、ほんの少しだけ公開します。(2022年1月 取材・作成)

今回のナレッジベースの作者
” やつき ”さん
2Dイラスト・UI・UXデザイナー。
フリーのイラストレーターや印刷業界でDTPデザイナーとしても活躍したのち、アピリッツに参加。

概要

UIデザインをしていて避けて通れない、文字間・行間、
レイアウトを組んでいて項目のまとまりが悪い時など…のオブジェクトの間隔の話。

学校で学んだ人もいれば、業務を通して掴めてきた人もいれば、資料を読み漁って勉強した人もいたり、デザインをする上で必ず通る所ではあるけれど基礎的なものすぎてスルーしがち・されがちな知識。

UIデザイナーは少ないという話もありますが、その理由として「難しそう」「知識を教わる機会も少ない」というのが挙げられています。

そのため、今回は私自身が印刷業界にいたときに学んだことの一つで、また、当時の先輩から学んで、わかりやすいなぁ…とUIデザイナーになっても助かっている内容をご紹介します

迷ったら一回ためしてみると大体解決するなぐらいのナレッジです。難しく行くのではなく、雑にシンプルに行きたいと思います。

本題

1.「読ませたい方向の間隔を狭くする」

2.「画面全体の間隔を大・中・小とざっくり区切る」

意識することはこれだけです。
資料や教本を見ると、詳しく書かれていたり、「何ポイントでこの割合で」などありますが、正直この2点さえ抑えておけばなんとかなるな…ということと、
誰かに教えるときなど、とてもシンプルで役に立ってます。

下記は過去に、人に教えたときに作った図解です。

3.キリのいい数字にしておくと、自分もエンジニアさんも多分楽

Unity組み込みをデザイナーがすることもあると思いますが、共通とまではいかなくても
個人的なもので数値を大体一定のパターンルールにしておくと
誰かにお願いするときも、数値で指定でき設計も楽かもしれないなという
後々みんな楽で、幸せになるよね…きっと…という伝わらないかもしれないけれどほんの少しの思いやり、思いやり大事…。

個人的に役に立った雑学

◆身近なもので見てみよう漫画のコマ割り

漫画家さんや作家さんと話すことが多々あった私ですが、その中で聞いた話があり面白いと思った話があります。
作品や展開でもちろん変動しますが、大体の漫画のコマとコマの間隔は、縦と横で幅が違います
アナログ漫画の場合、作家によって横が大体何ミリで縦は何ミリと大体の数値を決めている作家さんも居ました。(例:縦8mm 横3mm…等)
横に連なっているコマの間隔は狭く、縦つまりは行(段)が変わるコマの幅は目線が下にいくため少し広くとっていたりします。

前述であげた内容と一致していたことでありUIデザインでよくあげられる内容として、目線誘導の「Zの形」があげられますが、漫画のコマ割りなどでも同じ話をよく耳することがあり UIだろうが漫画だろうが雑誌だろうが根本は「ユーザーが見やすいもの」「人間の共有意識」として設計されている共通ルールの一つみたいなものなんだろうな…というのが個人的な感想です。

あとがき

文字間・行間・間隔の話を誰かに教えるときなど、難しい資料や理屈よりも
身近なものや好きなものから読み取っていくのが、実の所一番頭に入ったり、興味を持ってもらいやすくなると思います。

とても基本的で、基礎的な話だからこそ、入口的なものは楽しんで学べたら良いとも思いますし、楽しんでいれば学習意欲も上がります。難しい理屈や知識は、後からでも付いてくるものだと個人的には思います。

とても個人的な内容が多くありますが、少しでも参考になったら嬉しいです。

AWS Snowball Edge を使ってみた! 全工程レポート

0

最初に AWS Snowball / Snowball Edge について

AWS Snowball をご存知でしょうか? あまり使う機会がないかもしれませんが、Snowball は巨大なデータを AWS に送る場合に利用できる物理デバイスをやり取りする仕組みです。これを使うとネットワーク経由で時間をかけて転送する必要はありません。
いまのところ、1台の最大容量は 100TB ですが、複数台使えばペタバイトクラスのデータを AWS に送ることもできます。

ちなみに Snowball Edge は Snowball の機能拡張版という位置づけだったのですが、オリジナルの Snowball は現在既に利用できなくなっているため、Snowball といえば Snowball Edge の事を指すことになります。この文章では単純に Snowball と記述しています。

さて、こんな Snowball ですが、実際の所あんまり使う機会がありません。Snowball が必要になるほど大きなデータというのはなかなかなくて、1T くらいまでなら数日かけて手元の回線から送ってしまった方が手軽だったりします (AWS へのアップロードは課金されませんしね)。

今回は、8T 強のデータを AWS に移行する要件に Snowball を利用してみました。このサイズだとネットワーク経由で送っても十分行ける範囲ですが、実際に Snowball がどんなものか試す意味も含めて実施することにしました。今回はその一部始終を実際の写真をたくさん使ってレポートします。 ※この記事はパートナー杉浦達樹の多分な協力によって執筆されています。

実際の利用の流れ

それでは、Snowball が どういうものか分かったところで、実際の利用の手順を見ていきましょう。

ものすごく大雑把に言うと、 Amazon から巨大な NAS が送られてきて、データを投入して送り返せば S3 にアップロードしてくれる……そんなイメージで大丈夫です。

具体的には、

  1. AWS Console 上から Snowball Edge の注文を行う
  2. デバイスが送られてきたら、ネットワークにつなぎアクティベートする
  3. AWS に転送したいデータを Snowball 内にコピーする
  4. 電源を切って返送する

といった手順になります。

Snowball を注文する

最初は受取先の住所指定から

一番最初にデバイスの送り先住所を聞かれます。通常はオンプレの IDC に送る事が多いと思われますが、今回は弊社オフィスを指定しました。下の方にありますが、3~7 日で届くようです。おそらく国によっては配送オプションが複数から選択できるのだろうと思うのですが、少なくともこの時点の日本では 3~7 日の1択しかありませんでした。

デバイスを選択する

Snowball Edge はストレージ容量に特化したデバイスの他に、ローカル環境で ML などの処理を行うために SSD を搭載し、CPU 処理能力に優れた Compute モデルがあります。今回は単純にファイル転送ができれば OK ですので、 Storage Optimized を選択します。また、この時点で返却した後にインポートする S3 のバケットを選択する必要があります。 必要であれば作っておきましょう。

セキュリティ、 SNS トピックの指定など

続いて IAM ロール、そして通知用の SNS トピックを指定します。最後に OpsHub の案内が表示されます(今回は利用しませんでした)。

注文が終わったら

現在の注文 job のステータスが確認できるようになります。またこの画面から Snowball のクライアントと、そのために使用する credential のファイルのダウンロードができますので取得しておきましょう。

デバイスの接続とアクティベート

到着と開封

というわけで少し待つと到着しました。これが Snowball Edge デバイスです!

開封の様子を……と思いきや、外箱はありません。運送箱を兼ねているので、本当にこのまま送られてきます。コネクタ類や、コントールパネル、ケーブルなどは蓋を開けるとあります。この蓋はスライド式に収納できるようになっています。

背面コネクタ部の蓋を開放するとこのような感じです。

ちょっとびっくりなのは、配送ラベルの表示用として paperwhite が。そして、制御用のコンソールとして Fire 7 Tablet が埋め込まれています。全力で Amazon product が使われていますね!

電源を入れてアクティベート

付属している電源ケーブルとネットワークケーブルを接続し、電源を投入すると、しばらくの間掃除機みたいな物凄い音でファンが回ります。オフィスで動かすときは周りに断っておいたほうが良さそうでした。
この状態でしばらく待つと、ファンがだいぶ静かになり、インストラクションが表示された画面をループして設定待ちになります。

ここまで来たら、Snowball Edge client でアクティベートを行います。先程ダウンロードしておいた manifest ファイルと、unlock code が必要です。

この状態でしばらくたつと、コンソールパネルが操作可能になります。が、まだデバイスはロックされているので解除してやりましょう。

ここまで来ると、コンソールの S3 Service の表示が LockedUnlockingReady と変わります。Ready になれば、このデバイス自身を S3 サーバとして利用することができます。

ファイルを転送しよう

実は、その前にもう1ステップ必要です。これでデバイスの準備が出来ていますが、 S3 クライアントの認証をするための鍵がありません。こちらも Snowball Edge Client から取得します。

これで Snowball のための AWS Access key と secret key が手に入りました。 普段と同じ様に ~/.aws 以下に設定を書いておきます。 
それでは実際にアクセスしてみましょう!endpoint として configure のときに表示された Snowball の IP アドレスを指定します。

$ aws s3 ls --endpoint http://192.168.11.154:8080 s3://2020-12-30 17:51:28 frs-archives

注文時に設定した bucket が自動的に作られていますね。ここにファイルを置けば良さそうです。
今回は隣のホストで tar を作りつつ、それを Snowball に転送するために例えば以下のようなコマンドを使いました。このあたりは実際に転送するファイルにより適切な方法は変わるかと思います。

ssh srchost "cd /path/to/src && tar c dir" |  pv -tabN "dir name xxx" | \  aws s3 cp --expected-size $[1]240*1024*1024*1024 --endpoint http://192.168.11.154:8080 -  s3://frs-archives/target.tar

返送して S3 にインポートされるのを待つ

ファイルの格納が終わったら、コンソールからデバイスの電源を落とします。

すると自動的に上面にある paperwhiteに返送用のラベルが表示されます。賢いですね!

蓋を全て閉じ、AWS console からリンクをたどって集荷の依頼をすれば、そのまま持っていってくれます。

数日後、コンソールを確認してみると、AWS 側に到着してインポートが始まっていました。インポート状況も AWS コンソールから確認できます。

あとはインポートステータスが 100% になるのを待つだけです!

ちょっと注意事項ですが、もし日本以外のバケットに移す予定の場合は、先に Cross Region Replication を設定しておくのを忘れないようにしましょう。
今回は最終的に US に送る予定だったのですが、先に Replication の設定をしていなかったため、結局手動でコピーする事になりました……。

Snowball を使ってみて

今回は本来そこまで必要のないサイズではありましたが、実際使ってみてかなり手軽だという印象を受けました。物理デバイスを扱ったり、配送を手配したりと言った手間はありますが、頻繁に更新されない大きなデータに対して非常に強力な転送手段になりますね。

実際に使う機会は結構限られているとは思うのですが、チャンスがあればみなさんも是非 Snowball を使ってみてください。

References

References
1 240*1024*1024*1024

アピリッツ 2021年振り返り!

0

2021年がそろそろ終わります。今年はアピリッツにとって新規上場の年。そして「よりよい会社をみんなで作っていきたい」という社長の和田の言葉通り、みんなでアピリッツを作っていく一年でした。会社の大きな動きを駆け足でご紹介します。(取材 2021年12月)

2月 東証JASDAQ(ジャスダック)スタンダードに新規上場

2021年2月25日に、東証JASDAQスタンダードに上場しました。

折しも新型コロナウイルス感染症で緊急事態宣言下であったので、よくある上場記念セレモニーは後日開催していただきました。また、2022年4月4日からの新市場区分は「スタンダード市場」です。

2月 オフィス増床(その1)

続々と増え続けるアピリッツの社員が、これからも安心してオフィスでコミュニケーションを取りながら働き、よいサービスを生み出せるように……とのことで、オフィスを増床しました。こちらは2020年に新卒採用で入社した社員3名が内装を考えました。

芝がきれいです

4月 入社式

2021年は30人の新卒社員を迎え、およそ2年ぶりに入社式を執り行いました。入社式の会場は、先程ご紹介した新オフィスです。

記念撮影のときだけマスクをはずしています

6月 年間最大121万5千円! 『APN手当』開始

福利厚生も拡充していきました。まず、全社員向けに「新型コロナワクチン接種休暇」を制定しました。そして、AWSエンジニアの育成強化を目的に社内制度『APN表彰手当』を制定しました。この制度により、条件を満たしたエンジニアには、最大で121万5千円の報奨金を支給されます。詳細はこちら この取り組みのあとから、ますます社内のエンジニアが学習や発表、メンバー育成を活発に進めています。

12月 オフィス増床(その2)

2月に増床をしたあとも、アピリッツの社員は毎月続々と増え続けています。ちゃんと安心してゆとりをもって働いてほしい……ということで、再び増床しました!

引っ越し前夜の様子。まだなにもないフロアで、ソファと木がスッと社員をまっていました
ある日突然現れた肩こり対策のマシン。みんなつかってくださいね!

今年もありがとうございました!

アピリッツは、これからもどんどん新しい変化があるはずです。来年も良い一年となるよう社員全員で努めていきます。

年末には社員同士の交流を応援するために、感染に気をつけつつではありますが懇親会も開催しました

おつかれさまでした! また来年!

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に対する愛情がないと、プロジェクトは成功しません。そういった姿勢を学べています。

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

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

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

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

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

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

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

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

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

最近人気な記事