ホーム ブログ ページ 6

Storybook for HTMLを使ってみた【準備編】

0

デジタルエクスペリエンス部デザイン&プランニンググループ所属Webデザイナーの今井です。
デザイン&プランニンググループはWebシステムやアプリ開発のチームとともに連携しながらのデザイン制作が得意分野でしたが、最近ではUXやビジネス要件定義という上流工程やReactなどフロントエンド案件に関わることも増えてきました。
今回はデザイン&プランニンググループとしても初めてとなる非常に大規模なコンテンツ制作案件を円滑にすすめるために導入したStorybook for HTMLについて書いていきます。

Storybookと使用目的

StorybookはUIコンポーネントとアプリケーションを切り離してコンポーネントを開発・管理できるツールです。
ReactやVueなどフロントエンドの開発で活用されることが多いのですが、今回は大規模なコンテンツ制作案件のため、コーディングに関わる人数も多くなり、スキルレベルも様々になるので、品質を一定レベルに保つことと作業スピードの向上を目的として導入しました。

Storybookのセットアップ

Storybookのインストールは公式にある通りに実行します
参考:https://storybook.js.org/docs/html/get-started/install

npx storybook init --type html

インストール中

Do you want to run the 'npm7' migration on your project?(y/n)

とでますが、これは何も入力しないでEnterでスキップします。

次にhtmlのコピーを簡単に行いたいので、アドオンを追加します

npm install @whitespace/storybook-addon-html

アドオンのインストールが終わったら、.storybook/main.jsにアドオンを追加します

module.exports = {
"stories": [
"../stories//.stories.mdx", "../stories//.stories.@(js|jsx|ts|tsx)"
],
"addons": [
"@storybook/addon-links",
"@storybook/addon-essentials",
"@storybook/addon-interactions",
"@whitespace/storybook-addon-html" //storybook-addon-htmlを追加
],
"framework": "@storybook/html"
}

main.jsを保存したら、Storybookを起動します。

npm run storybook

起動後ブラウザでStorybookを確認すると、HTMLタブが表示されます。

外部ファイルの読み込み

案件では共通のcssやjQuery、共通のjsファイルを読み込む必要があったので、Storybookでも同じ様に適用される様にしていきます。
storiesやnode_modules等と同じ階層にpublicディレクトリ を作成し、必要なファイルを配置します。

package.jsonを開き、scriptsの起動時にpublicが読み込まれるようにコマンドに -s ./public を書き加えます

"scripts": {
"test": "echo \"Error: no test specified\" && exit 1",
"storybook": "start-storybook -s ./public -p 6006",
"build-storybook": "build-storybook -s ./public"
},

次に.storybookディレクトリにpreview-head.htmlを作成し、読み込みタグを書いて保存します。

<link rel="stylesheet" href="/common/css/style.css" />
<script src="/common/js/jquery-3.6.0.min.js"></script>
<script src="/common/js/common.js"></script>

Storybook再起動すると外部ファイルが読み込まれるようになります。

ブランドロゴの設定

Storybookはデフォルトでロゴ画像が設定されていますが、テーマの設定で変更することができるので、public内に配置したロゴ画像を出してみることにします。

テーマの設定に必要なファイルはmanager.jsYourTheme.jsです。
YourTheme.jsのファイル名は任意ですが、特に理由もないので公式のドキュメントの通りにします。
ファイルは.storybookディレクトリに配置します。

まずmanager.jsでテーマファイルを読み込む設定をします。

import { addons } from '@storybook/addons';
import yourTheme from './YourTheme';

addons.setConfig({
theme: yourTheme,
});

次にYourTheme.jsで任意のロゴに置き換える指定をします。

import { create } from '@storybook/theming';
import logo from "../public/common/img/logo_appirits.png"

export default create({
brandTitle: '任意のタイトル',
brandImage: logo,
})

指定したロゴに変わりました。

ロゴ以外にもテーマはいろいろと設定できるので、サイトのテーマカラーなどに合わせることができます。
参照:https://storybook.js.org/docs/react/configure/theming

Storybookの準備ができたので、次回【実践編】でコンポーネントを作成していきます。

Windowsでgitを使用する時に注意すべき設定【アピリッツクリエイターズナレッジベースから】

0

ES部の岡庭です。今回は以前担当していたプロジェクトのgit管理でつまづいた内容をまとめます。

はじめに

本題の前に改行コードというものについて少し話します。

テキストファイル等でエンターキーで改行した際「改行」を表す文字というかコードが打たれるわけですが、その「改行」の種類が複数存在します。
使うOSによって主流の改行コードが異なるようです。

  • Windows:CR+LF
  • Mac  :LF

⇒このCRとかLFとかいうのが改行コードと呼ばれています。

プログラマーがMac、プランナーがWindowsという環境では改行コードの統一が必要です。

どんな問題が起きるのか

SourceTreeやTortoiseGitを使用しているとチェックアウト/コミット時にgitがWindowsに合わせた改行コードに自動変換する機能(AutoCrlf)が初期設定時のデフォルトはtrueになっています。

この設定が混在した状態になると、pullしただけで 触ってないのに全ファイル全行に改行コードの差分が出る状態 になったりします。

git上では変更として全行真っ赤に差分検知されますが、目視で違いに気付くのは難しいです。

こうなると本当の差分が埋もれてチェックの妨げになるため、ConnectではWindowsでgitを使用するメンバーは全員AutoCrlfの設定を統一するようにしていました。

WindowsとMacが混在するプロジェクトで、git上でテキストファイル系(csv/html/xml等)を扱う場合に注意が必要です。

どう向き合うべきか

このAutoCrlfという設定自体は悪いものではなく、リポジトリにCRLFが混ざってしまうということをユーザーに意識させずに未然に防いでくれる機能なので通常はありがたいものです。

問題は、プロジェクトメンバーのAutoCrlfの設定が統一されていないことで、falseユーザーがCRLFのままコミットした状態で、trueのユーザーがチェックアウトするとそれ以降全部のファイルが差分検知される状態になってしまいます。

設定値チェックアウト時コミット時
trueLF → CRLFCRLF → LF
input変換しないCRLF → LF
false変換しない変換しない

設定の種類は表の3種類があり、windows作業者は基本的にはtrueかinputで統一しておくのが安定なのかなと思いました。

エンジニア側でビルド前にLF置換作業を行う等のセーフティネットがあるのであればfalse統一でもいいかもしれませんが、falseとそれ以外が混ざると混乱が生まれるのでプロジェクト全体で方針を決めるのが良いと思います。

変更方法

初期設定で設定をtrueにするか選択できるようになってますが、初期設定をすり抜けた場合の修正方法が少しわかりにくかったので紹介します。

SourceTreeの場合

操作 > ターミナルで開く > 黒画面のターミナルが開くので以下のコマンドを入力しEnter

git config --global core.autocrlf 【設定値】

【設定値】には、true / input / falseの何れかを指定

TortoiseGitの場合  

TortoiseGit > 設定 > 設定の出どころ[グローバル] > 自動改行コード変換[AutoCrlf]のチェックボックス

まとめ

gitの設定で勝手に改行コードが変わって、覚えのない差分が出ることがあるというお話でした。

専門分野ではないので説明に不足があったかもしれませんが、詳しく調べたい場合は以下のキーワードで検索すると詳細な記事がたくさんあります。

  • AutoCrlf
  • git 改行コード自動変換

アピリッツは働く仲間を募集中! 採用ページはこちらです!

資格ってホントに役に立つの? アピリッツの若手エンジニアがAWS認定資格を勉強する理由(後編)

0

「2022 APN ALL AWS Certifications Engineers」に選出された21卒入社の串田 匠彌(くしだ たくや)と、今まさにAWS認定資格の勉強を続ける22卒入社の澤入 広(さわいり ひろ)に、胸の内を率直に語ってもらうシリーズ第二弾。今回は「AWSの資格や勉強は、仕事で役に立つの?」というテーマでぶっちゃけてもらいました。今回の聞き手も、アピリッツCDXOの西脇です。 (取材 2022年9月)

「テストと実務は別」だけど?

AWS認定資格のテストは、知識を頭に入れて、それでテストをうけて、合格しますよね。実際の仕事とのギャップはありますか? あと「これ役に立ったな」って点も知りたいです。

AWSのサービスの概要についてパッと調べてすぐ理解できるのは、開発の現場でとても役に立ちます。社内のAWSで困っている人の手助けができるようになったのも、すごくうれしい。前は「何が課題なのか、どうすれば解決するのか」がわからなくて、つらかったんです。

資格勉強をやったおかげで、とにかく調べる時間が圧倒的に減りました。考えている時間とタスクを終わらせるスピードが違ってくる。

たとえばお客様から「こんなソリューションを導入したい、こんなシステムを構築してほしい。AWSでどんなサービスを使えばいい?」とご相談いただいたときに、「調べてあとで回答します」じゃなくてその場で「コレです!」とちゃんと回答できる。

仕事全体を進める速度が上がるっていうのはその通りですね。もう一つの大きなメリットは、お客様からも信頼して頂ける点だと思います。お客様とお話ししているその場でバンバン! と回答できると、ファンになってもらえるし、次の打ち合わせを楽しみに待ってくれる(笑) 

たしかに、いろんなことをご相談頂けるようになっていますね。

うん、そうなるとね、いい状態でプロジェクトを進められます。これって自分たちのやり方1つで変えられることなんですよ。別にPMだけがすべてをコントロールしているわけじゃなく、開発に関わるスタッフ全員で信頼度を積み重ねていける。そのほうが良いものを作れるんです。お客様も僕らもうれしい。

自分はまだその境地に達していないというか、まだ課題はたくさんあるなと感じています。ただインターンで働き始めたころと比べると、勉強を続けて理解できることも増えてきました。だから、もっとインプットしなきゃなと毎日思っています。

澤入さんはアウトプットが得意なタイプだと思うんです。業務上のコミュニケーションはとても上手い。つまり、アウトプットはできているのだから、あとは知識のインプットを頑張ればいい。

アウトプットができるって大事ですよ。

AWS認定資格の話に戻りますが、「テストと実務は別だよね」っていう意見は世の中に一定数あります。僕はそれは正解でもあると思うけれど、それは「テストで学んだことが役に立たない」って意味では決してないとも考えています。

知識を身につけて、イチから調べる頻度が減るのは大きなメリットです。料理も慣れると早くなると思うのですが、それと似ているかも。慣れていないと「猫の手でこうやって切って……!」とか少しずつやりますよね。

初めて料理する人はレシピをいっぱい見るし、「大さじ1とは?」って考えるけど、慣れると味付けもチャチャっとできるもんね。

猫の手!の串田さんと、それを眺める澤入さん

「お客様に本当に必要なこと」をどう見極める?

串田さんも澤入さんも、社会人になってまだ1~2年ですが、未来予想を聞かせてください。

一生コーディングしていることはなさそうだなと思っています。技術を身に着けているという前提で考えると、お客様のビジネスを把握した上で、お客様のビジネスを技術面からサポートできる人になりたいです。本当に必要なことだけに特化して開発を進める立場の人間になっていくんじゃないかなと思っています。

串田さんの言う「(お客様に)本当に必要なこと」って、どう見極めていくのがいいんだろう?

最優先にすべきことは、お客様のビジネスを理解することだと思います。そのビジネスに必要な機能だけを実装できるようになりたい。それって技術的な知識だけでなく、理解力も求められるのかなと思います。

エンジニアとして仕事をしようと思う人は、ビジネスじゃないところで生きていきたいケースが多いかもしれません。「ひたすらコードを書いていたい!技術を磨きたい!」って。

職人気質と呼べるでしょうし、尊いものなのですが、その仕事って彫刻で例えるなら、彫刻を作る職人さんではなくて、彫刻を彫るためのノミを研ぐ職人さんの仕事なんですよ。研ぎ師。その研いだノミは、もちろんすごく鋭くていい道具ですよ。

でもね、そうはいっても僕らアピリッツの仕事は、あくまでその鋭いノミを使っていい彫刻を彫ることなんです。ずっと研いでばっかりじゃダメ。技術を使って良質な開発をして、お客様に納品するのが仕事。

たしかに使う技術ベースで話をするのと、お客様からの要件ベースで話をするのだと、おそらく後者のほうがプロジェクトとしては上手く進むように感じます。

「技術者としての好奇心」と「ビジネス」のバランス

とはいえ、技術に特化したい研ぎ師的エンジニアの気持ちもわかるんですよ。ずっと同じことを繰り返すのは飽きるし、やりたくない。やっぱり新しい技術的チャレンジが欲しいんです。そういう要素は仕事にちょっと入っていてほしい。

だから、技術的挑戦をどのくらい、どのタイミングで入れるか、いかに彼らが挑戦できる環境にするかはいつも考えています。たとえば「お客様のビジネスを成功させるには、この新しい技術は絶対に必要だ」と判断したら、提案の段階で入れます。たとえそれが初めてのチャレンジでも「僕らなら、AWSからのバックアップも得られます」って説得する

ビジネスを優先させるためだけに技術者としての好奇心を殺すのはよくないし、知識や技術にこだわることは仕事じゃない。バランスを取っていくのがIT業界ではすごく大事だと思います。

バランスのことを話す西脇さん

AWSの勉強だけじゃ身につかないこと

自分は今まさに選択肢があり過ぎて迷っている状態です。最近鈴木さん(FS部の部長)との1on1でもこの話になりました。

インフラにも片足を突っ込み、バックエンドもやらせてもらって、ちょっとわからないな……と思っていると正直に話したら、鈴木さんに「それ、100%迷子になるよ!」と予言されてしまい、いろいろと考えているところです。

AWSに限らずいろんなことを勉強し、経験を積んで、やがてトータルで考えられるようになったら、その終着点はPMのような全体を見る人なのかなと考えています。

AWSに限らずいろんなことを勉強するのはいいことだと思います。たとえばDockerの知識がないとECSはまともに使えないし、サーバレスで行くなら、要件に沿ってFargateを使ってコンテナサーバレスにするのかAPI Gatewayとか使って完全にサーバレスにするのかを判断しないと、あとあと面倒なことになるんです。そういう判断はAWSの勉強だけじゃ身につかないので、広く掘り下げていく必要があります

知識をもつこと自体は仕事じゃないんですけど、技術に詳しいことは立派な武器になりますね。ということで澤入さん、最終的にはAWS認定資格の全制覇を狙ってね。期待してます!

アピリッツの採用ページはこちらです!

120万円以上の報奨金? やりがい? アピリッツの若手エンジニアがAWS認定資格を勉強する理由(前編)

0

AWS認定資格を取得するエンジニアがアピリッツには多数在籍しています。そして、AWS認定資格をすべて取得するエンジニアも増えてきました。モチベーションってなんなのでしょう? 若手でも取れるもの? もともと勉強は好きだった? 「2022 APN ALL AWS Certifications Engineers」に選出された21卒入社の串田 匠彌(くしだ たくや)と、今まさにAWS認定資格の勉強を続ける22卒入社の澤入 広(さわいり ひろ)に、胸の内を率直に語ってもらいました。聞き手はアピリッツCDXOの西脇です。 (取材 2022年9月)

ぶっちゃけ、お金だよね? ……というわけでもなかった資格全制覇の動機

去年からアピリッツは「APN表彰手当」という社内制度を作って、社を挙げてエンジニアのAWS認定資格取得を応援しています。この成果はちゃんと出てきて、社内のエンジニア達のあいだでAWS認定資格の勉強が盛んになってきました。「この資格試験に合格しました」って報告が僕のところにもたくさん届いてる。

やっぱりこれって「APN表彰手当」が120万円以上出ることが大きいのかなと想像しますが、実際はどうなんだろう?

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

自分の場合は、報奨金の総額120万円はもちろん魅力でした。モチベーションの4割くらいはお金だったと思います。

残りの6割は?

好奇心ですね。「APN表彰手当」が始まったとき、社内では「そんなの、ハードル高いよ」って声があがっていました。一部のベテランエンジニア以外は無理なんじゃないか、って空気感だったと思います。

「AWS認定資格を全部取る前に、段階的に出る報奨金が増えたらいいのに」という声がありましたね。でも、あくまで「全部取る」にこだわった。

で、ちょうど入社まもない串田さんが「ソリューションアーキテクト-プロフェッショナル(以下、SAP)」を取ったから、マネージャー陣は「彼は全部行けるんじゃないかな」って思った

関連:4月入社の新人がAWS Certified Solutions Architect-Professionalに合格した話

「入社一年目で無理なんじゃない?」って風潮も確かにあったけれど、「それ、本当かなあ?」と思ったんです。本当にダメなのかどうかを、限界までやって自分で確かめたかった。高校球児が甲子園を目指して精一杯がんばるような働き方にチャレンジするのも面白いかもなと思いました。

それに報奨金もいい臨時収入になるし、きっと実務もできるようになるだろうし、会社での評価も上がる。じゃあ試そうか、って。

試したら、全部とれちゃった。

去年串田さんがAWS認定資格をコンプリートした事実を、今年入社した僕らは知っています。だからもう「若手には絶対に無理」とは思っていません。道を切り拓いてくれた先輩がいるし、さらに報奨金でグッと後押ししてもらっています。

今年もFS部部長の鈴木さんが「AWS認定資格を勉強するエンジニアを増やそう!」「みんなで受けよう!」ってムーブメントを作っていますね。

をね、かけてますね。

どれかひとつのAWS認定資格に合格して「受かりました」って鈴木さんに報告しに行くと「おう。で、次は何を受けるの?」って言われていました(笑)

関連:「5年後、10年後のキャリアだけじゃなく、30年後も考えよう」メディアサービス部(現・FS部) 部長 鈴木利夫 インタビュー

合格発表はドキドキする?

勉強をして、受験して、結果を見るときは緊張した?

試験直後に自分ですぐに結果を確認できるのに、最初に受けたとき僕はそれを知らなくて、結果のメールが届くのをドキドキしながら待っていました。

澤入さんが「受けたんですけど、まだ結果がわからない……!」と言ってて、「いやそんなはずないでしょ、受けた直後にわかってるよ!」って(笑)

紆余曲折ありつつ、受かったことがやっとわかって「ああよかった」と思いましたが、うれしかったのは一瞬で、「さあ次は何を取ろうかな」って。次はSAPを受けます。

利夫(注:FS部部長・鈴木のこと)のが効いてる(笑)

一番印象に残っているのは最後の試験です。問題を解きながら「ああ、受かるな」と思った。でその場で合格がわかってガッツポーズして、受験会場を出て「さあどうしようかな」って。

全制覇して、自分で合格祝いとかはしたの?

いやなにも(笑) で、合格がわかったその足で会社に行って、鈴木さんに「さっき(全部のAWS認定資格に)受かりました」と報告しました。そしたら「そっかあ……」って。「もうちょっと何かあるだろ!」と思いましたが(笑)

うれしかったんだろうね。

そう思います。「そっかあ……」のあと、すぐに「ここからAWSに申請できるから、やっといて〜」って教えてもらったので、やっぱり気にかけていたのかなぁ、と。

勉強って好き?

ふたりとも、もともと勉強は好きな方?

勉強はあまり好きではありませんが、、何もしないと不安なので、安心感を得るために勉強をしています。

私はインターンでアピリッツに入ったので4月に入社したときには仕事にも多少は慣れていましたが、それでも変化が激しいWEB業界でやっていけるのか不安でした。

きっと慎重なタイプですよね。澤入さんの仕事ぶりをSlackで見ていると「細かい報告もちゃんとしてくれる人だな」と思います。変化や検討状況を細かく共有してくれる。これができるかどうかって、新人とかベテランとかは関係ないんですよね。仕事をする上で、「これは有用で意味がある」って思ってできているかどうかの違いじゃないかなと。そして、周りにちゃんと伝えているほうが、頼む方もやってる本人も安心だなと思います。

串田さんはどう? 勉強好き?

自分の場合、「勉強する」っていうのは「気になったことを調べている」だけなので、それを勉強って呼んでよいのであれば好きですね。エンジニアは、開発で「なぜタスクでこれをやる必要があるのか?」と疑問を持って、それを突き詰めて調べるのが大事なんじゃないかなと思っています。

理由が自分なりにハッキリしていないと、何らかの答えを出したときに自分で腹落ちができないんですよね。自分で理解して答えを導き出すと、それは暗記じゃない形で頭にずっと残る。若手のうちからそのクセを身につけると、その後もナチュラルにできるんじゃないかな。

そのうち「何もしない週末」が耐えられなくなる(笑)。僕、こないだ自分の誕生日に「この土日は何もしない!」と決めていたのに、日曜の夕方になんだかすごく虚しくなった。「もったいねー!」って(笑)

私も同じく、AWS認定資格の受験勉強中は通勤の電車の中でずっと勉強していたんですが、受験が終わったあとに参考書を持たずに電車に乗ったら「あれ?」って思いました

澤入さんは、週末もちゃんと勉強するタイプの人なんだなと思います。そうしないと多分合格は難しいから。

―― つづきます!

お勧めユーザー選定方法考察

0

アピリッツ コンテンツデザイン部の金井と申します。今回は膨大なレコード数を保有するテーブルからのランダム抽出に関して書いていきます。

結論

元々ある莫大なテーブルから愚直にクエリを叩くのではなくて、別にテーブルを作ってそこから効率的に参照するようにすれば良いと思います。

良くある仕様相談

プランナー「ゲーム始めたてのユーザーにもフレンド機能を積極的に活用して欲しいから、以下の条件でお勧めユーザーが出るようにしてくれない?」

  • チュートリアル完了済み
  • フレンドでない
  • BANユーザーでない
  • フレンド数がMAXでない
  • 3日以内にログインしている
  • ユーザーとのプレイヤーランクの差が-5~+5以内
  • お勧めユーザーとして出る事を許容している

サーバーエンジニア「りょーかい。(クエリ叩いて該当するユーザーを検索して指定数絞り込むだけだから……うん、そんな時間掛からないかな)1~2営業日で実装できますね」

はい、落とし穴です。

愚直に実装した結果

例えば、以下のように愚直にクエリを叩くような実装にしたら、

FRIEND_COUNT_MAX = 30
RECOMMEND_SEARCH_DATE_RANGE = 3
RECOMMEND_SEARCH_RANK_RANGE = 5
RECOMMEND_SEARCH_LIMIT_COUNT = 100
RECOMMEND_SEARCH_SAMPLE_COUNT = 30
def search_recommend_users(time = Time.current)
  ban_user_ids = BannedUser.current(time).pluck(:user_id)
  friend_user_ids = Friend.where(status: Friend.status_value(:friend), user_id: self.id)
  except_user_ids = ban_user_ids | friend_user_ids

  recommend_users =
    User \
    .where("? < last_login_at", time - RECOMMEND_SEARCH_DATE_RANGE.day) \
    .where(rank: (self.rank - RECOMMEND_SEARCH_RANK_RANGE)..(self.rank + RECOMMEND_SEARCH_RANK_RANGE)) \
    .where.not(id: except_user_ids) \
    .where(is_allow_recommend_search: true, is_tutorial_finished: true) \
    .order(:last_login_at) \
    .limit(RECOMMEND_SEARCH_LIMIT_COUNT)
    .to_a

  friend_counts = 
    Friend \
    .where(status: Friend.status_value(:friend), user_id: recommend_users.pluck(:user_id)) \
    .group(:user_id).count
  recommend_users.select! { |user| friend_counts[user.id].to_i < MAX_FRIEND_COUNT }
  recommend_users.sample(RECOMMEND_SEARCH_SAMPLE_COUNT)
end

幾らインデックスをきちんと張ってようとも、QA検証まで恙無く通っても、負荷試験で莫大なユーザー数を登録するような試験を行うと、死ぬと思います。

もし、そのままリリースしてしまったら、その機能で数秒待たされるとか、そんな事が頻発したりだとか……。
原因としては、上記の仕様においてはユーザーを一意に絞り込めるような条件が存在しないので、ユーザーが増えれば増えるほど、クエリの負荷が増大していく訳ですね。

リリース1週間前までずれた負荷試験で平均レスポンス10秒越えのAPIが出ちゃったか〜……帰りたいなぁ……

じゃあ、どうしたら良いんでしょうか。
個人としての現状のベストとしては、以下です。

改善への考察

まず、現状の実装の問題点や、仕様でもうちょっと絞り込めるようにして良いような部分を見つけましょう。

現状の実装の問題点としては、愚直にクエリ検索をする一番のデメリットは、ゲームが繁盛するに連れて検索量が莫大になっていってしまう、って事ですね。

また、仕様を見返してみてみると、一番優先度の低いと言うか、もっと厳しくして良いものが一つありますね。

  • 3日以内にログインしている

繁盛しているゲームならこれを1時間以内、とかにしても良いと思いますし、それで検索量も一気に減って解決! とかなると思うんですけど、繁盛していないゲームになると、深夜にアクセスされた時には、工夫しないと何も検索結果として出てこないとか有り得そうだったり……。

まあ、この2点から考えると、最後に何らかのアクションを起こしたユーザー群から絞り込む、で良いんじゃない? って発想が浮かんできました。
要するに、別にお勧めユーザー検索用のテーブルを作り、そこにトリガーとなるアクションを起こしたユーザーを入れて、その末尾のレコード数十件を引っ張ってくるって形ですね。
そういう形ならば、幾らユーザーが増えようとも参照量は一定ですし、時間帯で検索に引っ掛からなくなるような不安もなくなります。

ただ……この手法にも欠点がない事もなくて。
ゲームが過疎ってしまうと、同じユーザーばっかり抽選されるようになります
この手法はお勧めユーザー抽選以外でも、アクティブなデータからの効率的な参照方法として使えると思いますが、ゲームそのものが過疎らなくても、その機能が余り使われなくなるとか、そういう要因でこの事象が発生してしまう可能性はぼちぼちあります。

そういう点も留意した上で、プランナーに今のままの仕様じゃサーバーが死ぬ事と、これこれこういう理由で、ここの仕様をこう変えて貰いたいという事を伝えて、首を縦に振って貰って、改修しましょう(振ってくれない? ……その時は青い空の広さをぼんやりと眺めましょう)。

書き換えたら多分こんな感じのソースになる

FRIEND_COUNT_MAX = 30
RECOMMEND_SEARCH_RANK_RANGE = 5
RECOMMEND_SEARCH_LIMIT_COUNT = 100
RECOMMEND_SEARCH_SAMPLE_COUNT = 30

# フレンド数が増減した、お勧めユーザーランクが上下した、ログインした、などの各種トリガーの度に呼び出す
def check_user_recommend
  # lastで参照する為、古いデータは削除する
  UserRecommend.where(user_id: self.id).delete_all

  return unless self.friends.where(status: Friend.status_value(:friend)).count < FRIEND_COUNT_MAX
  return unless self.is_allow_recommend_search
  return unless self.is_tutorial_finished

  UserRecommend.create!(
    user_id: self.id,
    user_rank: self.rank,
    ...
  )
  end
end

def search_recommend_users(time = Time.current)
  ban_user_ids = BannedUser.current(time).pluck(:user_id)
  friend_user_ids = Friend.where(status: Friend.status_value(:friend), user_id: self.id)
  except_user_ids = ban_user_ids | friend_user_ids
  rank_range = (self.rank - RECOMMEND_SEARCH_RANK_RANGE)..(self.rank + RECOMMEND_SEARCH_RANK_RANGE)

  recommends =
    UserRecommend \
    .where(user_rank: rank_range) \
    .where.not(user_id: except_user_ids) \
    .last(RECOMMEND_SEARCH_LIMIT_COUNT)

  User.where(recommends.sample(RECOMMEND_SEARCH_SAMPLE_COUNT).pluck(:user_id))
end

対象ユーザーを抽出する部分がとってもスッキリしましたね!

ごめんなさい。ここの部分の仕様が、SV的にとても危ないものだと分かったので、これこれこういう風に修正しました。なので、非常に申し訳ありませんが、ここの部分だけ再度QAをお願いします。挙動としてはこことここの部分がこんな風に変わっている以外は特に変わりありません。本当に申し訳ありませんがよろしくお願いします。

没案

ユーザー単位に1~100くらいでランダムな数字を振ったりして、その値を参照される度にランダムに指定し、数値が合致するユーザーだけを抽出する。
=> QA検証的にも分かりづらいし、本番で不具合が起きても検証出来ない

検索を全ユーザーDBからではなく、自分の属するユーザーDBのみからにする。
=> ……妥協案で敗北した気分になるから嫌だ。

住み心地はどう? アピリッツ社員寮「アピトリー」、入居者インタビュー・女性編

0

アピリッツは2022年から社員寮を導入しました。2023年の本格運用に向けて、先行で何名かのアピリッツ社員がモニター入居しています。入居のきっかけや手続き、そして肝心の住み心地について教えてもらいました。(取材 2022年8月)

→前回の男性編はこちら

「ひとり暮らししたいな」と思っていた

―― 社員寮に応募したきっかけを教えてください。

私は実家が都内にあります。アピリッツに入社した当初は実家から通っていたのですが、「社会人になったことだし、そろそろひとり暮らししたいな」と思っていました。でも、初めてのひとり暮らしを家族は心配していましたし、費用もかかるので、二の足を踏んでいたんです

そうこうしているうちに会社で「社員寮はじめます!」とアナウンスがあり、応募することにしました。

―― 社員寮なら、ひとり暮らしのハードルが下がりますよね

まず、部屋を借りるときの初期費用が社員寮なら不要なのがいいなと思いました。手続きも人事のみなさんが進めてくれて、電気やガスや水道の手続きもおまかせできました。

あと家族が「社員寮なら、いいよ」と賛成してくれたんです。「万が一何かあったときに安心だろう」って。

―― セキュリティの面でも安心ですか?

私が入居している寮はマンションタイプで、一階の共有エントランスも鍵がかかっています。あと寮母さんが常駐しています。

川沿いで暮らす夢が叶った

―― 寮は月島にありますね。街の雰囲気はいかがですか?

川沿いでとても気持ちのいい場所です。治安もよくて、スーパーマーケットも近くて、なにより銀座のすぐ近くなのでとても楽しいです! お台場へのアクセスもラクです。月島の家賃相場で考えると、私が今払っている家賃は格安だなと思います。会社が家賃負担をしてくれるのでありがたいです。家賃+水道光熱費+通信費で6.5万円ほどで生活しています。

―― 社員寮に入ったことで通勤時間は短くなりましたか?

5分短縮されました。勝どき駅から寮までは徒歩7分くらいです。駐輪場も借りたので、週末は自転車でいろんなところに出かけています。月島、楽しいですよ!

―― 寮にお友達は呼べますか?

基本的に同性の友人は入れます! 騒ぎすぎなければお泊りも可能です(笑)!

音は? 普通の賃貸との違いは? 気になる住み心地

―― お部屋のクオリティはいかがですか?

新築ではありませんが、壁の厚さもじゅうぶんですし、周りの生活音も聞こえません。Wi-Fiの速度も問題なしで、リモートワークにも対応できます。ワンルームなのでリモートワークと生活のメリハリをつけることが最近の課題ですね。

私が入居した寮は自分の部屋にキッチンやバスルームがあります。食堂はついていませんが、私は自炊したかったのでちょうどよかったです。

――引っ越しの荷物はどのくらいでしたか?

衣類など身の回りのものを大きなスーツケースに3こ分くらい持ってきました。ベッドと机と小さな冷蔵庫はすでにお部屋にあって、自分で揃える家具はあまり必要なかったのも寮でよかったポイントだなと思います。洗濯機も共用ですが待ち時間は全然ありません。好きなときに洗濯できています。

私が自分で持ち込んだ家具は、自炊用にもう少し大きなサイズがほしかったので冷蔵庫と、電子レンジ。あとはテレビです。ちなみにテレビは会社の懇親会の抽選で当たったものです(笑)

ということで身軽に入居できました。

通勤時間・広さ・街の雰囲気、何を優先する?

―― しばらくは社員寮に住み続けますか?

はい!快適ですし、月島も大好きなので、長く住み続けたいです。

―― 今後もアピトリーに入居する社員はたくさんいるはずです。アドバイスできることは?

社員寮を検討される方は、新卒採用で地方から東京に初めて来る人もいらっしゃるはずです。そうすると最初の部屋選びってきっと迷うと思うんです。ひとによって何が優先事項なのかも違うでしょうし。なので、ぜひ私に相談してください。「この駅は朝の通勤時間はとても混んでいるよ」とか「ここはいろんなお店や街に近くて便利だよ」とか、いろいろアドバイスできると思います!

―― ありがとうございました!

アピリッツの採用ページはこちらです!

「各自が考えながら開発を進める環境を作りたい」工藤 嵩大インタビュー

0

アピリッツでは若手幹部候補の育成を続けています。8月から新たに部長代行に就任したアピゲー部の工藤は、入社後いくつかの部署やES部での社外の開発を経験したのち、いまのポストに就きました。経歴や抱負について語ってもらいました。(取材 2022年8月)

実は、ES部への異動は乗り気じゃなかった

―― 工藤さんは中途採用で2014年にアピリッツに入りましたよね

前職では主にコンシューマーゲーム開発をしていました。新卒で入社して、クライアントエンジニアとして7タイトルほど作りました。

―― アピリッツ入社のきっかけは?

知人の紹介です。アピリッツに入社してからは、当時運営中のゲームタイトルの保守や改修、コンテンツ追加実装を担当していました。

―― アピリッツの第一印象ってどうでした?

ホワイトだなあ、と思いました(笑)。きちんと開発をしつつ、家にも帰れるのでよかったです。そのあとES部に異動して他社のゲーム開発に関わるようになりました。

―― ES部で他のゲーム会社に派遣されることに抵抗はありましたか?

最初はあまり乗り気ではなかったですね。他の会社に派遣されて働くのであれば、それって転職と変わらないと思いましたし、だったら転職でもいいかなあとすら考えていました。ちょうど「いっそ新しい環境に身を置くのもいいかな」と迷っていた時期でもあったので……

新しい設計思想や開発体制を知った

―― そこで転職を選ばなかった理由ってなんなのでしょう

ES部から派遣された大手ゲーム会社でよい経験が積めたからです。

ES部に異動する前はエンジニアのタスク管理を主にやっていて、自分で実装することが少なくなっていました。でも常駐先ではクライアントエンジニアとしてガリガリとコードを書けて実装に携われた。

要求されている内容を実現するためにはどうしたら良いか、より良いものにするためにはどうしたら良いのか、試行錯誤を重ねながら仕事ができるというのが、とてもやり甲斐があって楽しかったです。

―― ES部で経験を積めてよかった、という人は多いですよね

はい。環境が異なれば開発ルールやフレームワークといったものも違います。すると今まで自分が経験したことがない、新しい思想や開発体制を体感できます。

そこから、その開発の良い点やそうではない点も見えてきますし、自分自身での開発スタイルに取り入れることで、よりよい開発の進め方を模索できました。

常駐先で新しいつながりも生まれましたし。つまり、新しい環境が楽しかったんです。

だから、新しい環境で身につけた経験を社内にフィードバックして、より良い開発環境を目指せたらなと考えるようになりました。

各自が考えながら開発を進める環境を作りたい

―― 2021年の11月からはアピゲー部に異動していますね、どんなことを担当していますか?

リードエンジニアとしてエンジニア全体のまとめや、スケジュール管理です。各作業者の作業進行を円滑に進行させるために、各職種のメンバーと会話しながら状況整理とスケジュール確認をおこないます。また、ゲーム全体のパフォーマンスチューニングや基盤機能の改修や修正等も担当しています。

―― そして「部長代行やらない?」って執行役員の八木さんから声がかかったのですね

ビックリしました。まずはそういったお話を頂けたこと自体がとても嬉しかったですね。今後のことを考えると、そういった役割も必要だろうと思っていたので、部長代行に挑戦してみようという気持ちになりました。

ただ、やはり今までの様に100%開発に全力を注ぐことはできなくなってしまうという点については、少し寂しさを感じる所もありましたね。現場目線と管理目線、それぞれを交えて、試行錯誤しながらやっているところです。

―― 周りの反応は?

「部長代行じゃん!(笑)」とかですね(笑)。「おめでとう」と言ってくれる人もいて、すごくうれしかったです。

―― 最後に抱負を聞かせてください

アピゲー部の技術力向上と開発環境の最適化に取り組みたいと考えています。より効率良く作業を進められる環境を整え、より面白いゲームにするためにはどうしたら良いかということを、各自が考えながら作業を進める環境を目指し、自社ゲーム全体のクオリティ向上のために努力を重ねて行きたいと思っています。

―― ありがとうございました!

住心地はどう? アピリッツ社員寮「アピトリー」、入居者インタビュー・男性編

0

アピリッツは2022年から社員寮「アピトリー」を導入しました(名前は社員みんなで考えました☆)。2023年の本運用に向けて、先行で何名かのアピリッツ社員がモニター入居しています。入居のきっかけや手続き、そして肝心の住み心地について教えてもらいました。今回は男性編です!(取材 2022年8月)

敷金礼金なし、家具つきが魅力

―― 社員寮にいち早く入居した理由は?

もともとは実家住まいでしたが、ずっと一人暮らしには興味がありました。ただ、ゼロからのスタートはハードルが高いなあと思っていたんです。自分で用意するとなると、部屋探し、契約、敷金礼金の用意が必要です。

でもアピリッツの社員寮なら、敷金礼金は不要でしたし、家賃も相場より抑えたものになります。ベッドや机、クローゼットなどの家具もついてきます。自分で用意した家具はPCとモニターと椅子です。椅子だけはこだわりました。会社にあるような座り心地が良いものを使いたかったので。

入居に関する手続きは全部会社の人事のみなさんがやってくださいましたし、自分でやったことは内見と書類を記入したことくらいです。

ということで気軽に入居できました。

―― 入居している寮の最寄り駅は、東急東横線の自由が丘駅と東急大井町線の等々力駅ですね

はい。静かな高級住宅街で治安もいいです。とくに都内へのアクセスがとても便利であることが嬉しいです。通勤時間も20分ほど短縮されました

―― 社員寮について心配事はありましたか?

ネット回線の速度だけが気がかりでした。リモートワークでも回線速度は大切ですし、趣味のオンラインゲームでも大事な要素だったので。幸い回線速度に問題はありません。快適に使えています。

自分の場合、大浴場を共用することとか、食堂や共有スペースでの洗濯については全然気にしていませんでした。

大浴場は24時間入れます

―― 大浴場は、その名の通り大きい?

大きいですね、ホテルにある大浴場をイメージしてもらえれば。15人くらい入れるはずですが、混雑はしていません。いても3人くらいかな。

―― 大浴場は24時間入れるのですか?

入れますよ! 朝9時半から10時半のあいだだけ清掃タイムですが、それ以外の時間ならば真夜中でも入れます。自分は夜遅い時間に入ることが多いです。まだ使ったことはありませんがマッサージチェアもあります。

―― 快適そうですね

洗面所ですれ違う人も少ないですし、洗濯機もいつでも使える。広い食堂でも5人以上いるのを見たことがないです。もしかしたら今は入居者が少ないのかも。

―― じゃあ生活音も気にならない?

全然聞こえません。ゴミ捨てもラクですし、エアコンもちゃんと効いて涼しいし、快適に暮らしています。

フリースペースもいっぱい

―― 食堂がついていますよね、利用していますか?

自分は全然使っていません。というのも3日前までに申し込まないといけなくて、それが少し面倒だからです。ボリュームや栄養の点でいえばメリットは大きいのですが、その3日前ルールだけがネックで……。

―― これから社員寮に入居する人にアドバイスは?

プライバシーが気になる人は、お風呂や洗濯機の共用が気になるだろうなあと思います。キッチンも共用なので、料理好きの人は少し面倒に感じるかも。でも週末に料理している人はいますよ。

駅からの距離についても、内見のときに自分で実際に歩いてみて体感したほうがいいですね。

あと、洗濯物を干すスペースを工夫したほうがいいかも。乾燥機も使いますが、部屋干しする場合は窓だけだとちょっと足りないので。

ちなみに、同性の友人であれば部屋に入れますし、申請すれば宿泊もできます。

―― 同じ寮にアピリッツ社員がいたら交流すると思いますか?

同期入社した新卒の仲間が数人いたら楽しそうですね。寮の中にフリースペースがたくさんあるのでそこで集まったりするとよさそうです。自由が丘はカフェも多くておしゃれで楽しい街なので、休日も楽しいですよ、おすすめです!

次回は社員寮ユーザーの女性にも話を聞きます!お楽しみに~。

アピリッツの採用ページはこちらです!

UnityのChild Force Expandは罠という話【アピリッツクリエイターズナレッジベースから】

0

ES部デザイナーのMです。

UnityのGUIにLayout Groupというコンポーネントがあります。
実装に関わってる方は知らない方はいないくらい頻出な機能ですね。

Layout Groupとは  

要素を縦や横に並べるためのコンポーネント。
Horizontal、Vertical、Gridの3種類があります。

ボタンを並べたりキャラを一覧で並べるのに使ったり
本当にたくさん使いどころがある機能かと思います。

Child Force Expandのチェックを外そう  

今回は初心者の方、UnityでUIを組み始めて間もない方に伝えたいことなのですが

Child Force Expandのチェックはとりあえず外そう!

です。(Gridにはなかったかと思うので今回は関係ありません)

最新のverは分からないんですが、
Unity2018等ではLayout Groupコンポーネントを追加すると
必ずChild Force Expandというところにチェックが入っています。

Child Force Expandとは、Layout Groupの中の子(並べたい要素)を、
Layout Groupの空白が埋まるように引き伸ばす機能です。
子のサイズが強制的に変わります。
Widthなら横、Heightなら縦の余白を埋めるサイズに引き伸ばしてくれます。

この強制サイズ変更が罠です。
一見便利そうですが、UIを組む上では画像のアスペクト比が変わってしまったりするので
不必要なことが多いです。
正直デフォルトでチェックを入れないでほしい。

チェックを入れたまま、その強制サイズ変更に合わせてレイアウトを組んでしまうと
後で外して元に戻すのがしんどいことが多々あります。
ピンポイントで例を上げるのが難しいのですが…。

もちろんこのサイズ変更が必要なときもあります。
必要だと思ったら後でチェックを入れればいいだけです。
強制サイズ変更を前提にしてUIを組む必要はありません。

地味なお願い  

デザイナーは元より、エンジニアでuGUIに関わられている方、
Layout Groupを使う際は、「必要なさそう」もしくは「よく分からない」と思ったら
とりあえずチェックを外してから使ってもらえると、
後で誰かが助かるかもしれません…。

ソーシャルゲームにおけるミッション機能のサーバーサイド実装の考察:反省編

0

アピリッツ コンテンツデザイン部の金井と申します。前回から一年半以上が経過し、自らが携わっているゲームも無事リリースまでこぎつけ、そして暫くの時間が経過しました。
その中で、こういう改修はすべきではなかったなー、という事を書いていこうと思います。

結論

状態の増える改善は改悪!

過程

引き継いだソースは、基本的に全てのAPIでミッションの受注処理が含まれていました
その受注処理は煩雑であり、その処理が入っているが為に、許容出来るものだとは言え、全体的にレスポンスの遅延が発生していました。

私はそれを嫌い、ログインの段階で必ず通るAPIにのみ、ミッションの受注処理を仕込むように変更しました

すると、日付変更、データ更新などの、必ずログインに戻されるタイミング以外でのミッション……例えば、イベント開始と同時に有効にしたいミッションの受注が不可能になりました

それへの解決の為に、私は、未来のミッションを予め受注しておく、という処理を組み込みました。

ま、多少問題もあったものの、負荷試験も大丈夫だったし、受注処理も1APIでのみ対応になってソースコード的にもスッキリ!
リリース後もミッション関連でバグは起きて……しまった。

このソースコードは淡麗な醤油ラーメンの如く理路整然としているのだ!

問題

さて……これの何がいけなかったでしょうか。
私はリリース後までこの改修で発生してしまう問題に気付けませんでした。
また、これが引き起こす特殊な事象に関しては、運用になってからやっと気付けるような代物で、リリース前のQAでも素通りしてしまいました。

また、上記の改修が顕在化した要因として以下の事柄があります。

  • この頃のソーシャルゲームでは、ミッションを達成した瞬間、通知がゲームの端に飛んでくるような仕組みが良くあると思うのですが、それが一つ。
  • そして、未来のミッションを予め受注しておく、という処理を組み込んだとは言え、そのプロセスは基本的な受注処理と同じ部分を通っているという事が一つ。

…………。
はい。
例えば、初心者の為のイベントミッションで、累計*回**をする、みたいなミッションがあったとします。
ここで重要なのは、開始してからのカウントではなくこれまでの累計という事です。
初心者でもゲームを遊んでいれば簡単に達成出来るようなミッションで、既に長時間遊んでいれば即時達成しているようなミッションです。
要するに、こういうミッションでは予め受注して即時達成するという事が起きる訳ですね。
そこで私は、考慮漏れを引き起こしました。

即時達成したミッションの通知が、ミッション開始前の時刻なのにユーザーに飛んでしまったんですね。

ユーザーからしたら、何か通知飛んできたけど、ミッション一覧にそんなミッションないし、受け取る事も出来ないしで、訳が分かりませんね!
他にも一定の操作をしていると、一部のミッションが達成不可能になったりだとか、そういう事まで起きてしまい。
後から補填の為のバッチ処理を組み込んだりする必要が出て来ました。
まあ……後から補填処理を組み込んで修正出来るくらいの代物で、本当に大事には至らなかったのですが。それでも不具合としては結構大きめな部類で、結構凹みました。

原因

改修によって、状態が増える、それに対する影響などを考慮出来ていなかった事ですね。
今回の未来のミッションを受注するという改修に関して言えば、

  • 未来のミッションを受注しておらず、まだ有効でもない時間
  • 未来のミッションを受注しており、まだ有効でない時間
  • 未来のミッションを受注しており、有効となっている時間

という3つの状態が新規に発生してしまった訳です。そして、それらへの考慮が足りなかった。
いや、そもそも、そんな新たに発生した状態を考慮する必要が出てくるような改修はするべきではなかった
修正するにせよ、その未来受注をそのままにして対応しようとした場合、

  • 予め受注、即時達成したミッションを開始時刻が過ぎた直後のAPIで達成通知を送る必要がある
  • 累計カウントのミッションの場合、予め受注し、そして有効でない時間に進捗した分への考慮

等々、とてもじゃないけれど、やってられないような、やったとしてもエンバグを発生させそうな複雑な処理になりそうですし。

ぼ、ぼくのやってきた事は、良かれと思って河川に外来種を放流する行為に過ぎなかったのですね。

対応

結局、未来のミッションを予め受注するという処理をやめました。
詳しくは書きませんが、全てのAPIにミッション受注処理を入れ直すというような汚い事はせず、それだけはしないようにする、という対応が出来たので。
その修正を反映して、無事に本番で機能している事も確認出来て、やーっと、ほっと出来ました。

反省

最初にも書いた通り、リファクタリングにおいては、状態の増える改修はすべきではない、という事ですね。
良かれと思ってやった事が、実は改悪だった。そんな事を今回、自分はやらかしました。
なので、思いついたような実装方法や改修が、どんなに素晴らしいものに見えても、着手する前に距離を取って考えてみる時間が必要だと実感しました。
特にそれがシステムの根幹に位置するものに関しては、寝かせて翌日に見直してみたりだとか、どんなに一任されている事柄だろうと他者の目もしっかりと入れたりだとか、そういう事をした上で着手に入る必要がある。
そう、実感しました。

また、後から色々考えた結果、今回に関しての最善策は、

全てのAPIにミッション受注処理を入れる事は変えずに、受注する必要があるかどうかを軽い処理で判定出来るようにする。

という所感です。
それがクライアントもサーバーも、多少コードとしては煩雑でも一番安心出来る、簡潔な受注処理になりそうだと思っています。

アピリッツCREATORSナレッジベースから:エンジニア向けの業務効率化

0

ゲームの運営をしていく時に、エンジニアの手が必要になる作業で、新規の開発、不具合対応、本番反映などの作業が多くあります。それらの作業で、何度もする作業が多くあり、その作業をどうにかして短縮もしくは無くすようにすることで、業務の効率化を行います。

業務効率化で行ったこと

  • Jenkinsの導入
  • 作業のマニュアル化
  • 作業をプランナー、デザイナーに依頼

Jenkins(ジェンキンス)の導入

Jenkins(ジェンキンス) とは、特定の作業の自動化をするツールです。

このツールを使うことで以下のことなどが行えます。

  • 各環境への反映作業の自動化
  • AWSで行う作業(例:スナップショットの取得など)
  • アプリのビルド作業
  • アセットバンドルのビルド作業

コマンドで実行できることは行うことができるので、大抵の作業がjenkinsで行うことができます。

また、gitにpushされた時、特定の時間に自動で動作させることができ、実行後にSlack,Chatworkに連絡を入れることも出来ます。

今まで、手動で打ち込んできたコマンドがJenkinsによってボタン一つで完了することが出来るので、業務効率化になり、

また、自動なので、打ち間違いなどのヒューマンエラーが起きづらいです。

作業のマニュアル化

普段している作業をマニュアルにして、そのマニュアルを見ながら行うことで、どのエンジニアが行っても同じ結果が得られるようにします。

また、何らかの不具合が起きた際の対応などを記載することで同じような不具合をすぐに修正することができます。

個人的に頭の中で作業の確認をしながら進めるより、マニュアル化を見ながら、作業をする方が余計なことを考えないで済むので、楽に行えます。

作業のマニュアル化を行った例

  • 反映作業
  • イベント実行時のサーバー対応
  • 課金のお問い合わせ時の調査手順

作業をプランナー、デザイナーに依頼

上記で記載したJenkinsや作業のマニュアル化をすることで、エンジニアが行ってもプランナー、デザイナーが行っても同じ結果を得ることができます。

その為、Jenkinsの使い方、マニュアルの共有を行い、エンジニアの手からプランナーへ作業を依頼して、業務を減らして行きます。

減らした分で、エンジニアにしかできない作業を行うようにします。

作業をプランナー、デザイナーに依頼する例

  • Jenkinsを使用しての各環境への反映作業
  • Jenkinsを使用しての画像のビルド作業
  • 課金のお問い合わせ時の調査手順

まとめ

エンジニアの業務効率化をすることで、普段同じような作業を行うことが減り、新しいことを行えるようになります。

最初はその業務効率化の時間を作ることすら難しいかもしれないが、少しずつ業務効率化を行っていくことで次の業務効率化へ繋げて行きましょう。

プロジェクトによって場合は変わりますが、作業のマニュアル化が一番取っ掛かりやすいので、これから始めるといいと思います。

もしJenkinsの導入がすぐに出来るのであれば、業務効率化はかなり進めれるので、ここを目指しましょう。

アピリッツCREATORSナレッジベースから:モデリングにおける「印象」の合わせ

0

ES部の3Dデザイナーの伊藤がゲーム開発の現場に入って間もなく実感したという「身につけて一番よかった」モデリングのテクニックの紹介です。実際の行程つき!(2022年7月 取材・作成)

このナレッジの作者
伊藤さん
3Dデザイナー
ゲーム専門学校を経て、2021年2月にアピリッツ入社

3Dデザインにおける経験がまだ浅い私が、ゲーム開発の現場で得て一番よかったと感じたモデリングのテクニック「印象合わせ」の紹介です。知っている方も多いかと思われますが、こちらのハサミを実際にモデリングすることで、その手法を紹介したいと思います。

印象抽出をする前のモデル

まず、上記のハサミを印象抽出なしで30分で作成するとこうりました。

ハサミの「印象」をメモ+反映させると……?

次に、実物のハサミのスクショを撮り、ざっくりと印象となりえる部分をメモしてゆきます。
(現場ではイラストからの作成で行っていたため元イラストからでも可能です)

あとは、メモした印象をモデルに落とし込んであげます。

抽出した印象をモデルに落とし込み、テクスチャをつけると、このようになります。

かなり元のハサミと近い印象を受けるようになりました。

まだまだ未熟者で、実物のハサミとの差異はございますが、印象抽出を行うことによってかなり実物のハサミに近づいたと思います。作業時間はテクスチャ合わせ1時間半くらいになります。

人間はパッと見の印象で物の形を判断するらしく、そのおおまかな印象を抽出しモデルに落とし込んであげることで、実際には差があるととしても、印象さえ合っていれば「似ている!」という認識(錯覚?)になるらしいです。

この「印象合わせ」が最近知って良かったと感じたテクニックでしたので紹介させていただきました。

アピリッツでは仲間を募集しています。

採用エントリーはこちら!

ソーシャルゲームサーバーエンジニアってどういう事してるの?

0

アピリッツ コンテンツデザイン部の金井と申します。今回はソーシャルゲームサーバーエンジニアの業務内容を紹介していきます。

端的に言えば?

ゲームを作っているエンジニアなのに、グラフィックやサウンドを作る事も、それを動かすようにプログラムを組む事もなく、かと言ってそれを生かしてユーザーを楽しませるような企画を考える事もせず、ひたすらに文字だけと睨めっこしている悲しい部門です。

はい。そうです。
ゲーム制作をしているのに、その面白さを作り上げる事には余り関わらない部門です。

自主ゲーム制作をした事があるならば、
ベジエ曲線だとか三角関数だとかを使って弾幕を生成したり、
四元数を使って三次元空間で回転操作をしたり、
円と円の距離を計算して当たり判定を実装したり、
60fpsで都度画面をクリアして描写しなおしたり、
だとかあると思いますが、そういう事も全くしません。高校以降の数学を使う事もほぼほぼ無いかと思います。

しかしながら、ソーシャルゲームの世界をsocial……社会的な、他者と競いあったりコミュニケーションをしたりするゲームとして成り立たせるのには必須の部門であり、
また、その世界を(きっと後に来る億単位の損害賠償の請求と共に)終わらせる力と権限を持っている唯一の部門でもあります。
TRPGのゲームマスターと言ったら多少語弊があるでしょうが、それに近いところに属する業務を行なっていると言って良いと思います。

具体的に言えば?

ソーシャルゲームのサーバーアプリケーションの開発、運用とそれを構築するインフラストラクチャーを構築、運用しています。
……。これだけ言われても良く分からないと思いますので、もう少し詳しく。

サーバーとは?

ユーザーデータを一括管理したり、ユーザー間のマルチプレイの同期などをしているものです。
ソーシャルゲームはインターネットに繋がっていなければプレイ出来ませんし、そうでなくても電波の悪い状況にいると一々通信に何秒も掛かったりして、快適にプレイ出来なくなったりしますが、そもそも何故そうする必要があるのかと問われれば、例を挙げると以下のようになります。

  • スマホの機種変更をした際にソーシャルゲームのユーザーを引き継げるのは、スマホそのものにこれまでガチャでウン万円を掛けて獲得したカードや装備が保存されているのではなく、サーバーでそのユーザーを構成するデータを一括管理しているからです(この機能を悪用してアカウント売買とかする輩も居るけれど……)。
  • ランキングイベントなどで他人のスコアを参照したり、競い合えるのは、サーバーで全ユーザーのスコアを管理しているからです。
    また、チート対策が出来ていなければ、チート野郎による不正なスコアに誰も追いつけなくなってしまいます。
  • ランキング機能の他にも、ギルド機能やマルチ機能もサーバーがなければできません。

要するにサーバーは、

  • 見知らぬ誰かと競ったり、共に遊んだりするsocialな機能の為に必要不可欠なものであり
  • 時にユーザーの不正を暴いてゲームの健全さを担保し、スマホを機種変更した時にも続きからプレイ出来るようにしたりもする

為のものです。
かなりざっくりとですが。

世界を終わらせる権限を持っているというのも、ゲームを構成するマスタデータ、ユーザーデータを一元管理しているサーバーアクセスする権限を持ち、且つそれを好き放題弄ったり消し去ったり出来る技能を持っている、という事だったりします。

truncate table users;

サーバーを構築するインフラストラクチャーとは?

サーバーもコンピュータです。それもキーボードやマウス、ディスプレイなんてものがついていない、所謂パソコンとは別ものを使って、全ユーザーのデータを管理します(小さいアプリケーションなら、パソコンでも十分だったりするけど)。

しかし、サーバーも一台だけで全てのユーザーを捌ける訳じゃありません。ユーザーからのアクセスに応じて不正をチェックしたり、ガチャの結果を返したり、それをデータとして保存するのにも、そんな全てに対して時間が僅かずつ掛かりますし、そうして遊ぶユーザーは1日に10万人以上にも及ぶ事があります。
サーバー1台でどれだけのユーザーを捌けるのか。想定する同時接続数はどれだけなのか。
また、ユーザーデータはどれだけの規模になるのか。
その想定の分だけの各種サーバーを用意して処理の負荷を適切に分散させ、その全てでユーザーに快適で健全なプレイを邪魔しないように、正しいデータを迅速に返さなければいけません。

そこあたりの管理は、サーバーエンジニアとは別にインフラエンジニアと分けて担当する事も多いと思いますが、サーバーとインフラはとにかく密接に紐付いていますので、分けないところも結構あるのではないかと思います。
実際、自分もサーバーとインフラの両方の開発、運用を担当していますし(サーバー寄りではありますが)。

因みに、こちらでも世界を終わらせる権限を持っています。
サーバーを構成するインフラストラクチャーそのもの好きに操作する権限を持ち、それを好き放題弄ったり消し去ったり出来る技能を持っている、という事です。
サーバーを好き放題する力が、建物の中でバットを振り回すのに比べたら、インフラストラクチャーそのものを好き放題する力は、建物そのものを重機でぶち壊す力に等しいです。

AWSコンソールからスナップショットも含めてデータベースを吹き飛ばしている

まあ、もし本当にやったら、生涯掛けても払いきれないレベルの損害賠償を突きつけられると思いますし、そんな力を持てるからこそ、人としての信用がより一層必要である部門であるとも言えます。

纏めると

ソーシャルゲームのサーバーアプリケーションの開発、運用とそれを構築するインフラストラクチャーを構築、運用しています。

と言うのは、

ソーシャルゲームのsocialな部分を開発、運用しています。

と、言い換えられるのではないでしょうか。

それでどういう業務?

大まかに分けてしまえば、

  • サーバーアプリケーションの開発、運用
  • サーバーアプリケーションを構成するインフラストラクチャーの構築、運用

になってきます。

それぞれの開発、運用に対して説明していこうと思います。

サーバーアプリケーション開発、運用

端的に言えば、プログラムを書いて、ゲームアプリケーションとの意思疎通をし、ユーザーデータの管理をするアプリケーションを作成します。

そして冒頭にも書いた通り、ひたすらに文字だけと睨めっこしています。

ガチャで最高レアのキャラが出てきた時のようなド派手な演出が出てきたり、
様々な種類のノーツが秒間10を超えるペースで降ってきたり、
ギルドで格好良いデザインで動きまくるレイドボスに複数人で討伐しにいったり、
箱庭でキャラを好き勝手に弄ったりしている間も、
そんなクライアントがサーバーと通信するのは文字だけです。
ゲーム内で使う為のアセット(要するに絵とか3Dモデルとか全部ひっくるめた素材)もサーバーには置いてあったりしますが、サーバーとしてそれを使うのはゲームアプリケーションに送るだけで、それをサーバーの中で見たりする事は基本ありません。
強いてQAチェックの為に管理画面で別に確認出来るようにするくらいで。

基本的にやる事は、ゲームアプリケーションからこういう事したい、と通信が飛んできた時に、

  • 通信してきたユーザーを特定し
  • その要求が正しいものかを確認し
  • 必要なデータを更新し
  • クライアントにデータを返す

という事です。
そしてそれら全ては文字…プログラムで完結します。
ゲームアプリケーションを開発する場合には、概ね入力はユーザーの操作で、そこからプログラムを書く事によって演出という出力を達成していく、という形が多いでしょうが、
サーバーアプリケーションを開発する場合には、入力はゲームアプリケーションからの通信(文字)で、そこからプログラムを書く事によって達成される出力もゲームアプリケーションへの通信(文字)になります。
サーバー内では絵的な演出など何一つとして必要ないのです。

ゲーム作ってるのにつまらない現場だなあ、とか思うかもしれませんが、しかし。
サーバーは、全てのユーザーデータを管理している事や、それを操作出来る唯一の場所です。
ゲームアプリケーションはこうしたいと要求を飛ばしてくるだけで、実際のデータを操作する事も出来ません。
なのでここが疎かになると、ゲームアプリケーションが疎かになるよりもかなり悲惨な事が起きます。
例えば、

  • 育成をする際に素材が減らず、無限に育成出来てしまう
  • クエスト終了時に二重にリクエストを送る事で報酬を倍獲得する事が出来る
  • レイドボスのHPを不正に0まで持っていけてしまう
  • ゲームが正常に進行出来なくなる
  • 新たに機能を拡張しようとした時に強い制限が生じてしまう

等々……。

このクソコードを書いたのはもうこの会社には居ない人で、頑張って理解しようと思ったんですけど、私には実力が足りず……どうしようもありませんでした

そして、実際に書くプログラムに関してですが、
高校以降の数学を使う事も殆ど無いと前述しましたが、その代わりに他の部門よりもスマートさが強く要求されます。
数学で例えて言うと、問題自体の難易度はそう高くないが、綺麗に解く事を要求される、と言ったような感じでしょうか。
例を挙げると、

  • 正常に動作する事は勿論の事、
  • 起こり得る全ての状況に想定が出来ているか、
  • 新しく機能を追加したいとなった時に問題が発生しないか、拡張性は十分に取れているか
  • 万一何か起きた時にそのバグを追いやすい形になっているか

と言うような多岐に渡る事柄を考慮出来ていなければいけません。
再三書きますが、ユーザーの実データを取り扱う唯一の部門となりますので、かなーり慎重になる必要があります(まあ、それでも本番まで行ったミスは結構あるんですけどね!)。
舞台裏で大道具を管理している、と言うのとも似ているかもしれません。

そしてまた、上記の為には仕様に噛み付く事もあったりします。
ユーザーを楽しませるような企画を考える事はありませんが、その企画に異議を唱える事はあると言う事ですね。なんて嫌味な部門なんだ……。
まあ、言ってしまえば、ランダムな要因が多過ぎてQA(品質保証……本番リリースする前にテストする事と思って貰えれば大体合ってる)するのに莫大な時間が掛かりそうな仕様だとか、既存の実装を大きく揺るがすような仕様だとか、そう言うものに対して必要な期間が取れない場合はNOを突きつけたり、可能な代替案をこちらから示すべきだという事です。
十分に考慮、QAされずにリリースされた機能っていうのは大概後から色々厄介な問題を引き起こすものですから。
そしてその問題の原因がどこにあろうとも。
ユーザーデータを操作出来るのはサーバーエンジニアだけ…原因究明から補填対応までの後始末をするのはサーバーエンジニアなのですから。

サーバーアプリケーションを構成するインフラストラクチャーの構築、運用

良くあるサーバールームの絵としては、24時間エアコンで空調管理された部屋の中で、ラックに数多に配置されている機器に、沢山のコードが繋がっている、というのがあると思いますが、ぶっちゃけると自分はそんな部屋に入った事すらありません。
クラウドで管理された実体がどこにあるのかも分からないインフラストラクチャーを入社当初からずーっと弄ってます。

こういう実物も見た事は殆ど無かったり

そしてこちらに関しても、正直なところ高校数学とかも大して必要ないのですが、その代わりに要求される知識がかなり多くなります。
クラウドサービスの一つであるAWSでサーバーを構築するに当たってやる事としては、

Route53で各種ドメイン登録を行い、ALBでそれをロードバランシングし、S3とCloudFrontでCDNサーバーを構築し、Elasticacheでキャッシュサーバーを構築し、ECSでECRに登録されたDockerイメージを反映するEC2インスタンス群を管理させてAPIサーバーを構築し、AutoScalingで負荷に応じてサーバー数を上下させるようにし、それぞれSecurityGroupを用いて外部からの不正アクセスを弾き、CloudWatchを使ってS3に各種ログを管理し、時にはAthenaでログ追跡を出来るようにし、各種負荷を可視化し、デプロイはCodeBuildを使って各種段階を自動的に踏むようにし……。

みたいに、専門用語のオンパレードになります。
そのAWSには、専門の資格も10を超えるくらいにあったりしますし。

まあ、そんな複雑な事柄も一回構築を終わらせて正常に動く事まで確認出来たら、運用としてはそう大してやる事はない……と言いたいところですが、開発環境なんて良く増やしてくれなんて言われますし、本番環境もユーザー規模に応じてスペックを落としてコスト削減を図る事も時折やったりしますので、ちゃんとマニュアルを書いておいたり、AWSではCloudFormationという機能でインフラをコード化までしておいたりだとか、そういう事までしっかりとやる必要があります。

そして本番環境を作るに当たっては、想定される最大ユーザー数がプレイしても耐えられるか? という事をきちんと示しておかないといけません。
それに関しては過去に別に書いた事があるのでここで細かくは書きませんが、サーバーアプリケーションとインフラストラクチャーの両方に精通していないと、問題が発覚した時の原因究明すらままならない事もあります。
そういう点もあって、サーバーエンジニアとインフラエンジニアは兼業になる事が多いのではないかと思います。

何が面白いの?

冒頭でも書いた通り、ゲームを作るのに対してグラフィックもサウンドも何も関わってこない、更にゲームの面白さを構想する事もしません。
完成品も派手にキャラが動き回ったり、スタイリッシュなUIが機能する事もなく、はたまた絢爛豪華なサウンドが流れる事もなく。どこにあるか分からないサーバーから正常な通信が返ってくるだけ。
他の部門が面白さを0から1にしたり、1を5にも10にもするようなところであれば、サーバーは減算式。何も起きなければ100ではあるが、何か起きたら一気に落ちていく。正常に稼働していてもユーザーから称賛がかかる事は基本なく、何かあったら文句を言われるばかり。

けれど、誰が何をしようとも根本的な対応が出来るのはサーバーエンジニアだけです。
ユーザーがチートをして来ようが、それに対する最終的な防衛を行えるのも、自身を含んだ運営の誰がミスをしようとも、迅速に対応出来るのも、サーバーエンジニアだけ。
そして、その為の武器として手に持つのは純粋にロジックのみです。
そういう点では、ユーザーに喜ばれる仕事というよりは、同じゲームを開発、運営しているチーム内から頼られる仕事をする、と言う方が合っているかもしれません(漫画で例えるとフラジャイルの病理医みたいな立場かも。時々仕様にケチ付けるのも含めて)。

また、負荷というものへの考慮もクライアントとサーバーでは大きく変わってきます。
クライアントはマルチプレイなどが無い限りは基本ユーザー1人との対面を考えれば良いのですが、サーバーは今遊んでいる全てのユーザーとの対面を考える必要があります。
特にリリース時なんかは、想定されるユーザー数……時には数万人が同時に遊んだしても大丈夫な仕組みになっているか? という事までも考える必要が出て来たりします。
その為にも、プログラムはクライアントよりも効率化の必要性が高いです。
無駄を徹底的に省き、時にはデータをキャッシュして参照効率を更に向上させる。
どれだけアクセスが来ようとも、変わらず迅速なロジックと堅牢且つ柔軟なインフラを組み上げて、リリースと同時に雪崩れ込むユーザーを捌き切る。
また、リリースされてからアクセスが落ち着いて来た後に新しい機能が追加されたり、時が経ってユーザー1人辺りの資産が莫大になっていこうとも、サーバーはいつもと変わらない顔をしてレスポンスを正常に、迅速に返し続ける必要がある。
それは機能美を追求し続けるようなストイックさが強く必要で、そういうのが好きな人にはがっちり合うと思います。

あそこのソース、ああすればユーザー数が増えても軽量化出来るな……(後にそれが原因でバグを起こす)。

最後に

自身を含んだ運営の誰がミスをしようとも、迅速に対応出来るのも、サーバーエンジニアだけ。

これが何を意味するか分かりますか?
ゲームを運営しているサーバーエンジニアが行き着く先は、休暇中であろうとも仕事用のパソコンを持ち運び、何か起きたらすぐにパソコンを開いて原因究明、緊急性が高かったならば不具合対応から補填まで行う必要があるという事です。
……まあ、そこまで責任を負うようになったら、それなりのお金も貰えていると思いますし、ウチのチームはここからここまで電波の繋がらない場所に行ってしまいますと事前に伝えておけば、他の方々でサポート出来る体制です。

要するに、自分しか出来ない仕事なんて持たない方が良いって事です。あったらさっさとマニュアル化したりして、ノウハウを共有しましょう。
自分が好きな時に会社からの通知も気にせず好きに休める為には、それが必要です。

ユーザーからバグのお問い合わせです!!(GW中)

【社内活動のご紹介】LT会で話すってこんな感じ

0

アピリッツでは社員が自発的に勉強をする集まりがあります。そのなかのひとつ「LT会」は、主にWebソリューションセグメントのエンジニアが、チームや部署を越えた情報共有を目的として開催しています。LT=ライトニング・トークなので、気軽にコンパクトに参加できることを目指しているそうです。ところで、発表するってどんな感じ? スピーカーとして参加したエンジニアの徳永と竹内の生の声をご紹介します。(2022年5月 取材)

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

「他にもこういう人いるんじゃないかな?」と思って登壇した

ーー LT会のスピーカーとして立候補したきっかけは?

徳永:Reactがわからなすぎてどこから手を付けていいかわからなかったという状況が直近であって、「他にもこういう人いるんじゃないかな」とか、手探りで進めていくうちに「チーム内でここは先に共有した方がいいところだな」と気がついたところあったので、どちらの立場の人にも共有したい、有識者の知見をもらいたい、と思ったのがきっかけです。

今回は「React初学者が感じた挫折ポイント5つ」というテーマで発表をしました。

React案件にアサインされたけれどまだ触ったことない、という状況において、

・勉強を始めた際に困ったこととその時どうしたか、どうすると良いか
・受け入れる案件側が先に伝えるべきこと
・実際React開発を進めて困ったこと

などについて話しました。

竹内:私が発表した内容はデザイナー寄りの内容だったのですが、だからこそエンジニアの多い弊社で自分の知っている技術を伝えてみようと思いました。JavaScriptでリッチなWebデザインを手軽に実現できるライブラリを4つほど紹介しました。Web上でのアニメーションやリッチなUIの実現における可能性を伝えられてよかったと思いました。

「JavaScriptでこんなアニメーションができるなんて知らなかった!」という感想もあったので、興味を持ってもらえてうれしかったです。

ーー 登壇は緊張しました?

竹内:それほど緊張はしなかったです。アピリッツの社員たちはみんな優しいので。

徳永:緊張しましたが、同じ初学者側からの質問や、有識者からは「こういうやり方もあるよ」みたいなコメントももらえて、情報共有の場になりよかったです。

あと、部内(クラウドインテグレーション部)で技術共有を推し進めていきたいという動きがあるのですが、部長の剣持さんが私の資料を見て、部内でも参考になりそうだとのことでSlackチャンネルで共有してくれました。

ーー 部をまたいだ情報共有で「なるほどな」「新しい視点だな」と感じたのはどんな点でしょう?

徳永:アピリッツのデザインチームの発表で、エンジニアとの連携について少し触れられていました。新しい技術にシフトしていく中で連携の仕方も変わっていくので、そのあたりの知見を共有してもらえたのはありがたかったです。

竹内:自分が今まで経験できていない技術の話を聞けるいい機会だと思います。それこそ徳永さんのReactのお話も貴重でした。また、先輩(山田さん)の発表の仕方が参考になりました。

10分はあっという間

ーー アピリッツのLT会の制限時間は10分間です。発表してみて体感的にいかがですか?

徳永:とても短かったです。過去に3分間の発表をやったことがあったので「今回は余裕があるだろう」と思っていたのですが、いざ話してみると後半のスライドはほぼ飛ばすことに……事前にリハーサルしておけばよかったです。聞いてる側としてもあっという間に感じることが多いです。

竹内:私は10分ギリギリくらいまで話していたようで、時間を有効に使えた気がします。最近のLT会では、3分で技術や業務的なこと以外にも話ができるコーナーもできたんですよ。

気負わず発表できる場所

ーー LT会はまた参加しますか?

徳永:はい。今回参加して、自分と同じ立場で困っている人も多いんだなとわかりました。また共有したいテーマが出てきたら参加してみたいと思います。

竹内:他の人の発表もいろいろ聞いて、またいつか出たいです。

徳永:人前で話すことに抵抗があるタイプの人には、LT会のような気軽な場で慣れることによって話すことへの敷居も下がっていくと思うので、練習のつもりで参加してみるのもよいと思います。

今年も「ミニプロ」やりました!22新卒Webエンジニア研修「ミーティングブース管理システム」開発

0

アピリッツのWebソリューションセグメントは、昨年から新卒研修のメニューの1つとして、22年新卒で入社した若手社員を対象とした「ミニプロ(ミニプロジェクト)」を行っています。今年のテーマは「ミーティングブース管理システム」の企画・実装・テスト・プレゼンです。サポートはありつつも、新卒だけでまるっと全部やります。
今年で2年目のミニプロ。指導や方針のアップデートについて、執行役員の西脇と、今年もサポートとして参加したエンジニアの及川と肘井に話を聞きました。(2022年6月 取材)

関連記事:社員検索システムを新卒だけで作ってみよう! 21新卒Webエンジニア研修「ミニプロ」成果発表会
関連記事その2:2022年度オンラインゲームセグメント新卒研修を行いました!!

「3つの観点」を行き来しながらサービスを考えて開発する

ーー 今年と去年のWebエンジニア育成の違いは何でしょう?

西脇:変わらず大切にしているところから話しますね。まず、研修の基本構成は一緒なんです。Rubyを学んで、実習としてミニブログを作ってみて、最後の仕上げの研修で「ミニプロ」をやる。このミニプロにアピリッツらしさが出ているはずです。

エンジニアとして開発のセオリーを学ぶことも大切ですが、プロジェクトは規模も内容も毎回違います。ですから、ミニプロでは次のようなことを身に着けてもらいたいと考えています。

1.開発者としての自分
2.お客さまのビジネス視点に立った自分
3.利用ユーザーとしての自分

この3つを大切にすることは、どんなプロジェクトにおいても不変です。3つの観点を行き来しながらサービスを考えて開発すると、お客さまや周囲から信頼されます。そういったアピリッツのエッセンスを、入社まもない段階で学んでほしかった。この下地ができていると、その後自分の得意なことや、やりたいことを伸ばすときに効くんです。エンジニアとしてのキャリアをうまく組み立てることができるはず。

このコアの部分以外は、去年と今年の内容はだいぶ違っていたと思います。

メンバーの割り振りかたを変えた

西脇:今年(2022年)は、メンバーの割り振りをこっちで決めました。去年もミニプロのPMOを担当してくれた肘井に、割り振りを全部任せたんです。

肘井:すでにインターンとしてアピリッツで活躍しているエンジニアもいましたし、なるべく公平になるように割り振りました。性別で偏りがないようにしたり。なんでこちらで決めたかというと、去年はドラフト形式でメンバーを決めたんです。でも、この方式は「つらかった」という感想がいくつか出まして……

西脇:いつ自分に声がかかるんだろうか。本当に必要とされるんだろうか」ってソワソワしたそうです。入社したばかりだし、そもそもスタートラインはみな一緒なのだからそんな心配はいらないよってこちらは思うのですが、当事者たちは違ってました

Aチーム。「限られた時間での数多くのオプション機能の作り込みがすごい!」「はきはきと聞き取りやすい良いプレゼン」という講評でした

期限内に終わらせろ!

ーー 進め方にも違いはありましたか?

西脇:スケジュールがより明確になりましたね。とくに「とにかく期限内に終わらせないとダメ」「このタイミングでここまで進んでいないとダメ」と締切を明示して、同時にスケジュールに余裕を持たせていました。プレゼンのリハーサルの時間も用意してやっていたので、全員の発表のレベルが高かったと思います。内容も発表もしっかりしてました。

及川:サポートする側も、毎日誰かが必ず開発の様子を見に行っていました。

肘井:とにかくサポートする先輩社員に「見に行こう!」と呼びかけて毎日行ってもらうようにしたんです。

及川:毎日顔を出している人には、とくに質問がしやすくなるんですよね。遠慮しなくなるし、遠慮しなくなってほしい。

肘井:今年のサポートメンバーは、去年の新卒社員が大勢いました。去年の自分たちが何に苦労して、どんなアドバイスに助けられて、何を待っていたかをよく覚えているので、その視点でサポートできていたのだと思います。

西脇:「4月~5月の研修終了後、6月からの配属先でどんな案件に入るのかを早めに話すようにしたほうが良い」といった、研修後についても意見を出してくれたのはすばらしい動きでした。

ーー 3つのチームに分かれて開発をしていました。それぞれどんな差があったのでしょう?

及川:役割分担やタスクの切り分け方に差が出ていました。例えば今回もっとも評価が高かったBチームは、タスクを非常に細かく分けてマージに気をつけていました。ドカンと大きくタスクを分けて、おのおのが黙々と開発をして、最後にマージするとうまく合体できなくて慌てることもあるので、そこでBチームがリードしていたと思います。

西脇:マージの段階で相互認識がズレているとわかって、そこから修正するのは大変ですからね。B班はインターンとしてすでに活躍しているエンジニアも参加していましたが、一方でエンジニアではないメンバーもいたので、「エンジニアとエンジニアではないメンバーが一緒にものを作るには?」を工夫しながらタスクを切ったのかもしれません。

今回最も高評価を得たBチーム。「ブースの利用×抽選 という点が新規性のある発想ですばらしい」とのこと。1位の副賞として焼肉好きの執行役員と焼肉に行きました

開発案件と並行して研修をサポートする

ーー サポートメンバーについても聞きます。単刀直入に言うと、忙しかったですよね?

及川:はい(笑)大変か大変じゃないかで言えば大変です。ただ「今年もミニプロをやる」とわかっていたので、それ前提で仕事を進めてバッファを取っておきました。

肘井:私も去年と比べて明らかに忙しかったのですが、「毎日必ずミニプロの現場に顔を出す」ことだけは守って、最低限を教えながら進めました。とはいえ、新卒同士で調べて解決してしまうことも多かったようです。

西脇:「忙しい」っていう点で言うと、実は新卒のメンバーのうち数名は、すでに開発案件に携わっている人がいました。すると、ミニプロの開発と案件が激突しそうになる。そのサインを先輩社員が察知して、「今の時期は研修を優先させてほしい。研修を受けさせてあげたい」って僕に教えてくれるんです。気がついてくれてうれしかったですし、とても助かりました。

Cチームのみなさん。「利用者目線で使いやすさなどを意識した作りになっている点が素晴らしい」「レスポンシブデザイン導入、他サービスを調査し取り入れている点がすごいです」と好評でした

次世代のリーダー育成

ーー 来年もミニプロはやりますか?

西脇:やりますよ! 新卒同士で話す機会が増えるので好評です。新卒同士の横のつながりが強まるとともに、ミニプロに関わったメンターの若手社員との縦のつながりとなります。さらに、こういった研修の場で若手社員に役割を持ってもらうことは、会社が「リーダーとして任せていきたい」という期待を込めているんです。

ーー 楽しみにしています!

2022年度オンラインゲームセグメント新卒研修を行いました!!

0

今年度からオンラインゲームセグメントの試みとして、21卒が新卒研修の計画を立て実施しておりました。新卒の同期は一生に一度の仲間のため、繋がりを大事にしてほしいという意図のもと、昨年の11月から21卒と部長陣との間で協議し、4月〜5月中旬にかけて開催いたしました。オンラインゲームセグメント初の試みとなるため、皆さんにどのようなことを行ったか&研修に至るまでの紆余曲折をここで紹介させていただきます。

MSビルの広場を使用し、研修を行いました。

第1回 サイコロ自己紹介・並べ替えゲーム・オンリーワンゲーム

・22新卒同士でサイコロの目に出たお題を答えてもらったり、自分たちの名前順に並べ替えをしてもらったり、「自分はこれは負けない」というものを紹介してもらったりしました!

第2回 好きなゲーム布教

・自分が布教したいゲームをチーム内で共有し、さらにチームで代表を決め全体で共有してもらいました。

第3回 ゲーム研究

・チームに分かれてもらい、他社様のゲームから各チーム1タイトルずつ選び、ゲームの面白さについて研究してもらいました。

第4回 アナログゲーム企画

・6チームに分かれてもらい「紙とペンで遊べるもの」というお題の元、アナログゲームの企画をしてもらいました。

第5回 アナログゲーム制作

・前回の研修時に企画したものを形にするため、道具を作成・テストプレイによるバランス調整をしてもらいました。

第6回 アナログゲーム発表・試遊会

・完成した作品を発表してもらい、その後部長陣・21卒・22新卒入り混じり、アナログゲーム試遊会を行いました。


新卒研修のプロデュースのこと

今年度は上記のような内容で新卒研修を実施致しましたが、実はこれらのコンテンツに至るまでかなり紆余曲折ありました・・・。

今回は新卒研修をプロデュースするにあたって多大なる貢献をしてただいた、21卒のSさんをお招きして色々お伺いしていきたいと思います。

こんにちは〜
新卒研修をプロデュースしてみてどうでしたか?
今年度の研修は21卒が8人、22新卒が28人と、新卒の人数が多かったので「研修どうしよう!」ってなりましたよね笑

そもそも、前回の踏襲がなく0からのスタートだったので、あせりましたね。
22新卒の人数が多かったからこそ、アナログゲームを制作して試遊会を行った際に盛り上がった感はありますね。

0から作り上げるのは大変でしたけど、やりがいはその分大きかったですね。
研修の内容については、特に右往左往しましたよね笑

新卒研修を考えている段階では「デジタルゲームの制作 or 企画書を書いてもらおう。」という案もありましたね。
でも最終的にアナログゲームを制作してもらいましたけど・・・

アナログゲーム制作になった決めてってありますか?

アナログゲームだと、0から自分たちで作ったゲームになる & それを遊ぶことによって交流が深まると思ったからですかね。
しかも、1つのものを作り上げるには全員に主体性がないとできないですし・・・

なるほど、主体性と同期の交流を増やして欲しいという思いが根底にあるんですね!

そうですね。21卒の僕たち同士があまり関わる機会が少なかったので反面教師というかなんというか・・・笑

・・・笑
Sさんが新卒研修のプロデュースを通して成長できたなという部分はありますか?

実は研修を行ったり、人前で発表するという機会が初めてだったんですよ。
スケジュール管理だったり、資料作りだったり、所謂PM作業に近いこともできたと思います。
普段の業務ではあまりそういうことをしないので、貴重な経験でした。

いつ、どこで、どんな新卒研修を行うか、本当に0から考えましたよね!
22新卒の方々だけでなく、私たち21卒の成長にも繋がったかなと思ってます! 今日はありがとうございました!

どうも。

このような経緯がありつつ、今年度の新卒研修が開催されました。


22新卒はこんなゲームを作りました

今回研修の集大成として、22新卒の方々にアナログゲームを制作してもらったので、ここで紹介したいと思います!

このゲームどうにかしたい!! by チーム:苦しい

一言ルール説明:ミッションカードのお題に対する解決策をアイテムカードを駆使して提示しよう!

手札のアイテムカードでミッションカードをクリアできるように、こじつけることがポイント
試遊会での様子

わーど大戦争 by チーム:わんこ大戦争

一言ルール説明:他の人に当てられないように、手札に書かれたワードをうまく会話に紛れ込ませろ!

「話題カード」の会話をする際に、他の人の話に耳を傾け、何の「単語カード」を所持しているか推測することがポイント
試遊会での様子

すごく地獄すごろく! by チーム:チーム名を入力してください▼

一言ルール説明:縛りカードのお題を守りながらゴールを目指せ!

ゴールを目指すことも大事だが、縛りトークで盛り上がることが楽しむポイント
試遊会での様子

つなげろ!山手線 〜始まりの原宿駅〜 by チーム:平行線

一言ルール説明:山手線の駅と駅の名所を説明してポイントGET!

山手線の駅についての知識が身につくため、他の人にも自慢できちゃうかも!
試遊会での様子

ピタフォール by チーム:トラックボール

一言ルール説明:相手が出すカードを推測するゲーム。0を出して相手をだませ!

場のカードがコールした数より大きければ勝利!できるだけ大きな数字をコールした人が他の人のカードをめくることができるので、度胸が試されます笑
試遊会での様子

かずピッタン! by チーム:2ゃんこ

一言ルール説明:お題の数とぴったりになるようにカードを出そう。相手が×0で妨害してくるかも???

×0を出されると盤面の数も0になるので、大逆転の可能性あり!
試遊会での様子

22新卒の方々に作ってもらったゲームをMSビルのカフェスペースに置かせてもらっております。説明書を作成してもらってますので、お昼休憩の際に是非MSビルの広場で遊んでみてください!

※外部への持ち出しは厳禁です。


〜22新卒の方へのメッセージ〜

同期の人たちは一生に一度しか出会えない宝です!
これから今以上に業務で忙しくなることがあるかと思いますが、同期の方々とぜひランチ等々に行って、その繋がりを大事にして欲しいです!
来年の23新卒に対する新卒研修を、22卒の方々でプロデュースすることになった場合、新卒研修の枠組みは21卒が作りましたが、ぶっ壊してもらって構わないので、今年度以上の物が開催できることを期待してます笑

〜23新卒の就活生の方へのメッセージ〜

皆さん、もしご縁がありアピリッツへ入社し、オンラインゲームセグメントへ配属されることがありましたら、22新卒の方々が新卒研修をプロデュースしてくれるかもしれません!研修を通して同期の仲を深められるようなイベントを行ってくれると思うので、ぜひお楽しみに!!!

PyScriptで線形回帰してみた

0

運動不足解消のためランニングマシンの購入を検討しています。ゲームデザイン(GD)部クライアントエンジニアの中村です。

先日PyScriptがオープンソースで公開されましたので、さっそく試してきました。

PyScriptとは

PyScriptはPythonコードをブラウザ上でJavascriptのように実行させることができるフレームワークです。Pythonでの計算処理などをHTMLエレメントへ出力できることに加え、可視化ライブラリのmatplotも利用できてしまいます。さらに機械学習ライブラリであるscikit-learnも含まれているため、ブラウザ上で手軽に機械学習を行うことができます。

ちなみにPyScriptではPyodideで利用できるライブラリがそのまま利用できるようです。そのため tensorflow を利用することはできませんでした(Pyodide Version 0.20.0)。

基本知識

導入

公式サイトにあるように、HTMLでPythonを実行するためには以下のように記述します。これだけでPythonコードのprintが実行されます。実行された結果はdiv要素を生成してその中に出力されます。

<html>
  <head>
    <title>PyScript Hello World</title>
      <link rel="stylesheet" href="https://pyscript.net/alpha/pyscript.css" />
      <script defer src="https://pyscript.net/alpha/pyscript.js"></script>
  </head>
  <body>
    <div>!! PyScript Hello World !!</div>
    <py-script>
print('Hello PyScript')
    </py-script>
  </body>
</html>
hello_world.html結果

出力のコントロール

先ほどの例ではprintした文字列が新規に生成されたdiv要素に出力されましたが、Pythonによる計算・処理結果を特定のHTMLタグ内に出力したい場合、以下のように py-script タグに out を定義することで可能です。さらにメソッドも定義できます。

この例では now_time() メソッドで現在時刻を返し、py-scriptの最後に実行して結果をoutput-targetdiv要素に出力しています。

<py-script output="output-target">
from datetime import datetime
def now_time():
  return datetime.now().strftime("%Y-%m-%d %H:%M:%S")

now_time()
</py-script>
<div>Now Time is:</div>
<div id="output-target"></div>
hello_time.html結果

DOM操作

py-script内で定義したメソッドをHTMLのボタンで実行する場合、pys-onClick属性でメソッド名を指定します。

さらにElement()で指定したidの要素を取得でき、input要素ならそのvalueを参照できます。divpなどの要素に対してはwrite()メソッドでその要素内に文字列を出力できます。

<div class="flex">
  <input id="calc-1" class="border p-1 rounded flex" type="number">
  <div class="p-1">+</div>
  <input id="calc-2" class="border p-1 rounded" type="number">
  <div class="p-1">=</div>
  <div id="calc-result" class="p-1"></div>
  <button id="new-task-btn" class="p-1 text-white bg-green-600 rounded" type="submit" pys-onClick="run">
    Run
  </button>
</div>
<py-script>
def run(*ags, **kws):
  a = float(Element("calc-1").element.value)
  b = float(Element("calc-2").element.value)
  Element("calc-result").write(a + b)
</py-script>
hello_input.html結果

Pythonファイルの読み込み

さらにHTMLに直接の記述ではなく、別途Pythonファイルを用意して読み込ませることもできます。このあたりはJavascriptと同じ仕組みです。

<py-script src="./sample_script.py"></py-script>

機械学習ライブラリの利用

ある程度PyScriptの使い方がわかったところで、scikit-learnでの機械学習を試していきたいと思いますが、今回は非常に簡単な例として、多数のx,y座標を近似する線形回帰を記述します。

matplotの利用

まずは数値計算ライブラリのnumpyと可視化ライブラリのmatplotを利用して簡単なグラフを表示します。

numpyで100個の乱数を生成してx座標とし、一次関数に乱数を含ませてy座標とします。これをmatplotにで散布図として表示させています。pyscript.write("mpl", fig1)と記述することで指定のdiv内にmatplotの結果を出力します。

Pyodideに含まれるライブラリを利用する場合、head内にpy-envタグでライブラリ名を記述する必要があります。そうすることでpy-script内でimportすることができます。

<head>
  <link rel="stylesheet" href="https://pyscript.net/alpha/pyscript.css" />
  <script defer src="https://pyscript.net/alpha/pyscript.js"></script>
  <py-env>
- numpy
- matplotlib
  </py-env>
</head>

<body>
  <div id="mpl"></div>
  <py-script>
import numpy as np
import matplotlib.pyplot as plt
      
a = 0.5
b = 2
rand = 0.5
count = 100
x = np.random.rand(count).astype(np.float32)
y = x * a + b + (np.random.rand(count).astype(np.float32) * rand - rand*0.5)

fig1, ax1 = plt.subplots()
tpc = ax1.scatter(x, y, alpha=0.5,color="red")
pyscript.write("mpl", fig1)
  </py-script>
</body>
hello_plt.html結果

scikit-learnで線形回帰

最後に上記の散布図に対して線形回帰で一次関数の傾きと切片を予測させます。このとき予測させる数値をinputから入力できるようにしました。ブラウザ上で稼働させているため、こういったUIを簡単に利用できる点が非常に便利です。

簡単な線形回帰ですが、scikit-learnによる機械学習も正しく稼働しました。

      <body class="container">
        <div class="flex p-2">
            <label for="input_param_a" class="p-1">A</label>
            <input id="input_param_a" type="number" value="1" class="border p-1 rounded">
            <label for="input_param_b" class="p-1">B</label>
            <input id="input_param_b" type="number" value="1" class="border p-1 rounded">
        </div>
        <div class="flex p-2">
            <label for="input_param_rand" class="p-1">Random</label>
            <input id="input_param_rand" type="number" value="0.5" class="border p-1 rounded">
            <label for="input_param_count" class="p-1">Count</label>
            <input id="input_param_count" type="number" value="100" class="border p-1 rounded">
        </div>
        <button id="btn" pys-onClick="runTrain" class="p-1 text-white bg-green-600 rounded">実行</button>
        <div id="mpl"></div>
        <py-script>
import numpy as np
import matplotlib.pyplot as plt
from sklearn.linear_model import LinearRegression

def runTrain(*ags, **kws):
  a = float(Element("input_param_a").element.value)
  b = float(Element("input_param_b").element.value)
  rand = float(Element("input_param_rand").element.value)
  count = int(Element("input_param_count").element.value)

  x_train = np.random.rand(count).astype(np.float32)
  y_train = x_train * a + b + (np.random.rand(count).astype(np.float32) * rand - rand*0.5)
  
  lr = LinearRegression()
  lr.fit(x_train.reshape(-1, 1), y_train)
  prev_W = lr.coef_[0]
  prev_W0 = lr.intercept_

  fig1, ax1 = plt.subplots()
  tpc = ax1.scatter(x_train, y_train, alpha=0.5,color="red")

  _x = np.linspace(0, 1, count)
  _y = prev_W * _x + prev_W0
  ax1.text(0.2, prev_W*0+prev_W0, "y = prev_W * x + prev_W0")
  ax1.text(0.2, prev_W*0.1+prev_W0, "prev_W={:.2f}, prev_W0={:.2f}".format(prev_W, prev_W0))
  ax1.plot(_x, _y, color="black")

  pyscript.write("mpl", fig1)
        </py-script>
      </body>
hello_scikit.html結果

まとめ

今回はPyScriptを利用してscikit-learnで線形回帰を試してみました。ブラウザ上で実行するため、inputやbuttonなどのユーザインターフェースを手軽に利用できる点は非常に便利です。普段からPythonに慣れているエンジニアにとってはJavascriptを覚えるより簡単なのではないでしょうか。

しかしながら、動作環境の構築のためかページの読み込みに非常に時間がかかります。まだアルファ版ですのでこれから先の発展を期待しています。

衛生委員会からのお知らせ「生活習慣病の予防 食事編」

0

衛生委員会は「労働安全衛生法」に基づいて毎月実施される会です。アピリッツで働く人たちの危険または健康障害を防止することが目的です。衛生委員会で話し合ったことは、これまでも社内に周知をしてきましたが、せっかくなのでアピスピでも発信してみることにしました。今月は「生活習慣病の予防」のために、とくに食事で気をつけるべき点について、産業医の先生とお話ししました。野菜って大事!(2022年5月)

40歳までに10キロ増える人も

近年、肝機能とコレステロールの数値が高い人が多い印象です。とくに男性は20歳から40歳までのあいだに、体重が10キロほど増える傾向にあります。また、40歳のときの体型がその後も続く場合が多いため、せめて40歳までは食生活に気をつけてほしいですね。

10キロ!

会社によっては、会食や仕事後の飲み会で摂取カロリーが増えてしまうこともあります。都内通勤の方は勤務時間が遅い人も多いため、それが原因で間食が増えてしまったり、夕食が遅くなってしまうことも肥満の原因と言われています。

アピリッツでもゲーム事業部のメンバーは11時から20時の勤務なので、遅い時間に夕食をとる人は多そうです。栄養バランスに気をつけた食事ができるといいのですが……。生活を変えていけば、生活習慣病のリスクはすぐに下がるものなのですか?

血圧・肝臓の数値に課題のある人は、痩せればだいたい改善されることが多いです。このため、ウォーキングのキャンペーンを実施している企業もあります。若いうちは不摂生しても病気になりづらいので、なかなか気にかけることが難しいかもしれませんが、今のうちにできることをきちんとやることをおすすめします。

Advice

※ アピリッツが加入している関東ITソフトウェア健康保険組合でも運動奨励イベントを実施しています。要チェック!

圧倒的な食物繊維不足! 野菜を食べよう!

食事でとくに気をつけるべき点や、健康的に食事をするためのよい方法は?

とにもかくにも野菜を食べてほしいです! 食物繊維不足な人が多いんです。食物繊維が圧倒的に足りていません。1日350gを目安に野菜を摂りましょう。また、ご飯を食べるときは、野菜から最初に食べる(ベジタブルファースト)を意識してほしいです。そうすると血糖値の上昇も緩やかになります。

ベジタブルファースト!

野菜ジュースでもいいのですか?

糖質が高い野菜ジュースもありますから、摂りすぎには注意が必要です。野菜ジュースのパッケージに記載されている栄養成分表をチェックしてくださいね。

サプリメントや、最近流行の「完全食」はどうですか? 食に興味がない人にはありがたい選択肢なのですが……。

まだきちんと調べられていない状況ではありますが、菓子パンだけを食べ続けちゃうよりはいいと思います。

つづきます!

今後も、アピリッツの社員がもっと健康的に働けることを目指して、衛生委員会で話し合った内容を発信していきます!

「Web→ゲーム」「ゲーム→Web」、アピリッツなら事業をまたいだ挑戦ができる

0

アピリッツはWebソリューションとオンラインゲームの2軸で事業を展開しています。なので、「Web→ゲーム」や「ゲーム→Web」といった事業をまたいだ異動をおこなう人もいます。ゲームプランナーとして9年間アピリッツで活躍してきた村田は、アピリッツならではの学べる環境を活かし、2021年からWebマーケティングの世界に挑戦しています。きっかけは? ちがいは? いろいろ正直に話してもらいました。(2022年4月 取材)

「バイトしなきゃな」から始まったアピリッツでの仕事

―― 村田さんは2014年に正社員として入社したのですよね?

そうなんですが、もともとは2013年の6月からアルバイトを始めていました。大学を卒業したあと、2ヶ月くらい何もせずに遊んで暮らして、「あ、そろそろバイトしなきゃな」と思って、あと「ゲームプランナーやってみたいな」とも思って、それでアピリッツのオンラインゲームの部署にアルバイト採用で入りました。

―― ちなみに、「バイトしなきゃな」と思い立ってアピリッツを選んだ理由は……?

ここで何かかっこいいことを言えたら最高なんですが、正直にお話すると、ゲームの求人一覧をあいうえお順にソートして、それで見つけたのがキッカケです。

―― なるほど。

会社名が「ア」から始まるメリットが活きてますよね。

―― アピリッツって名前でよかったです。ということで、正直にいろいろ訊いていきます。

ハイ、そうしましょう。

―― デバッグの仕事からスタートして、次はあるゲームのデザインのディレクションを担当したんですよね。

ゲーム内に登場するアイテムの企画を考えてデザイナーに作ってもらっていました。

―― ゲームプランナー人生が着々と始まった、と。

始まりましたね。この頃オンラインゲームの広告の仕事も任せてもらえて、広告を配信するまでのフローや広告のタイプ、あと予算の勘所がつかめました。費用対効果を上げるためにターゲットを考える癖も身につきました。

たとえば、開発中のアプリを触りながらペルソナを定めて、そのペルソナにマッチした広告を考えて配信するといいんです。

そのあと一年間エンパワーメントサービス部(ES部)に異動し、大手ゲーム会社でプランナーをやっていました。これは経験してよかったなあと思います。「バイトしなきゃな」で入ったアピリッツしか僕は会社を知りませんでしたし、よその企業のマネージメントや社風を実際に知ることができて、視野が広がりました。

― ES部で活躍する人からは「クリエイターとして、いろんな経験ができて視野が広がった」という感想をよく聞きますね。

僕もそう思います。誰でも知っているような大きなIPに携われたり、いいところがいっぱいある。

ES部での1年のあとは、社内のゲーム開発チームに加わって、プロモーション担当となりました。ここでの経験のあと、Webソリューション事業に移ることに決めました。

「自分にマーケティングの知識はある?」

―― ゲームプランナーからWebマーケティングに移った理由って何だったのでしょう?

担当していたゲームでのプロモーションが一通り終わって、「次の仕事やキャリアはどうしようね?」と考えました。社長の和田さんとも面談しました。

ここでWebマーケティングに惹かれたんです。

今までゲームの広告を担当していましたが、きちんとした正解がわからないケースもありました。断片的な知識と経験で手探りでやっていて、もちろんプロモーションが上手くいくことも沢山ありましたが、そうではないこともありましたし、自分にはマーケティングの知識が足りないなと痛感したんです。

―― 岐路だったわけですね。

正直に話すと「転職したほうがいいのかな」とすら思ってました。2013年からアピリッツで働いてきて何度か自分のキャリアについて悩む瞬間はありましたが、「自分にはWebマーケティングの知識が足りない。もっとやってみたい」と感じたこのときは本当に悩んだ。

でも、ゲームプランナーをずっとやってきて、そこから「おもしろそうだから」といってWebマーケティングの会社に転職することを考えると……ちょっと抵抗あるなあ、とも思って(笑) 

―― 「そろそろバイトしなきゃ」みたいなライトな気持ちでは選べないというか、腰が重くなりますよね。

めちゃくちゃ重かったですね。経験も浅いわけですし。で、「そういえば、アピリッツならWebの仕事もあるな」と気づきました。「うちにはWebマーケティングのプロがいるじゃん!」って。もちろん、アピリッツでゲームの仕事を続けることも可能性として残っていましたが、ちょうどWebソリューションセグメントの執行役員の長谷さん(Webマーケティングのスペシャリスト)とはプライベートでもお付き合いがあったので、Web側に移ることの心理的なハードルも低かった。

知らない知識を学びやすい環境がここにあるじゃないか、と思いました。

そんなこんなで、Webソリューション事業に移って9ヶ月経ちました。

マーケティングはやっぱり面白かった

後ろの派手な風船は新入社員のみなさんの座席の目印です

――「面白そうだな」と思って飛び込んだWebマーケティングの仕事は、実際面白かったですか?

面白いですね! 今まで自分が手探りでやってきたことの答え合わせができたと思います。

今はデジタルエクスペリエンス部でGoogle アナリティクスのチームにいます。お客さまのWebサービスやサイトを理解して、どの指標を見ていくかを決め、設定して、計測します。

たとえ似ているWebサービスでも、お客さまごとに、それぞれに課題や伸ばしていきたい数値が違うんです。なので、たとえばGA4への移行ひとつとっても、Webマーケティングの定石を単純になぞっているだけじゃだめなところが面白いです。

このあたりはゲームでも同じようなことをしていました。たとえば「チュートリアルの突破率はどのくらいか?」「ゲームの進行具合と課金率の相関」などを見るんです。

―― ゲームでの経験も活きているんですね。

つながっていました。

―― つながりがありつつも、アピリッツのオンラインゲーム事業とWebソリューション事業の両方で働いて、違いは感じますか? 正直に教えてください。

うーん……仕事として大切な根本的な部分は一緒ですが、違うところもたくさんありますね。 まず、僕が今いるチームは、それぞれお客様は違えどみんなWebマーケティングをやっているので、同じ目線で同じ仕事をみんなでやっています。ゲーム開発もチームワークが大切ですが、それぞれに役割があるので、雰囲気はちょっと違います。

そして、Webマーケティングの仕事はスタートから完了までのスパンがゲーム開発と比べるとすごく短いんですよね。どんどん仕事のサイクルを回していくんです。だからなのか、若手が主体になって案件を動かしていく空気があります。

―― 村田さんが今いるチームは若手が多いですよね。

若手中心ですね。2021年に新卒で入ったメンバーも多くいます。彼らは僕から見たら超先輩ですよ。みんないっぱい勉強しているし、細かな知識を沢山持ってる。お互い忙しいときは「ここやっておきますよ」って助け合ったり。いいチームにいるなと思います。

―― よかった。正直な村田さんがそう言うんだから間違いないですね!

アピリッツのデジタルマーケティングについてはこちらをご覧ください!

『ゴエティアクロス』全力で駆け抜けた3.5周年

0

アピリッツのオンラインゲーム『ゴエティアクロス(ゴエクロ)』が2022年3月27日に3.5周年を迎えました。ゴエクロの開発陣に今回の3.5周年のこだわりと、4周年について話を聞きました。(2022年4月 取材)

強敵「命害」をフィーチャーしました

3.5周年のイベントでは、どんなところにこだわりましたか?

3.5周年では、ゴエクロでよく出現する敵「命害」をピックアップした内容にしたいと考えていました。

強敵

そもそも「命害」というのは、ゴエクロに実装された強力なエネミーたちの総称だったのですが、長らくその詳細が語られることはありませんでした。「強敵の集団」ということで、3.5周年を記念する大戦イベントに相応しい相手だったかと思います。

「命害」をどんなふうにフィーチャーしたのでしょう?

3.5周年イベントを開発していた当初は、命害大戦イベントの画面もそのまま3周年のものを使う予定でした。でも、せっかくの3.5周年ですし、ボスとの戦いを盛り上げる為に画面を新たに作り直しました! HPゲージを工夫したり、3周年の時とは違った「特別感」が出るように配列を工夫したり、イベントの段階ごとにボスの表情が変わるようにするなど、細かいところにこだわっています。

こういった内容を決めるのはゴエクロチーム全員で決めるのですか?

そうです! 開発陣全員で話し合って決めています。

2021年の9月から仕込んでました

長くサービスを続けていくと、周年のイベントも悩むんじゃないかなと思うのですが、いかがでしたか?

事前の準備が重要になってきますね。
たとえば、約2か月に渡って開催していた外伝「異界の侵略者」のフール編・ハーミット編から、今回の3.5周年本祭で開催した「命害大戦:ワールド」へとゲームを綺麗に繋げるために、スタッフ一同、去年の9月から準備していました。

同時系列でゴエクロの中でも最強格である「ラジエル」も登場させて、「いつもは敵側だけど今回だけは味方側」という熱い展開にも力を入れました!

あとは、「ワールド」という命害を操るボスがいるのですが、その敵としてのキャラクターの雰囲気や、実際に戦う際の熱い展開などをどう魅せるかについては、メンバー一同で悩みました。

てんこ盛りだったんですね

はい。だからシナリオチームも苦労したはずです。
「命害のストーリーを単独で楽しんでいただけるものにする」「ラジエルを登場させ、ストーリーを盛り上げる」「姉妹作『ゴエティア -千の魔神と無限の塔』とのストーリーの繋がりを明示する」
この3点が必須だったので、うまく繋がるように苦労して作ってもらいました。

運営が想定している以上に人気が爆発

ユーザーからの反応はどうでしたか?

全体的にユーザーからは好評でした!
前作の『ゴエティア -千の魔神と無限の塔』と『ゴエティアクロス』を密接につなぐ要素の登場で、前作を楽しんでくださっていたユーザーからの反応も多くいただきました。

あとは、3.5周年のフェス限として登場した「時界震天ラジエル」が爆発的人気で運営が想定している以上でした(笑)

あの黒髪の……!

ゴエティアクロスではめずらしいお姉さんキャラ「時界震天ラジエル」

はい、あのお姉さんキャラのラジエルです。ゴエクロでは、エルやバラムやビヒモスといった少女系キャラのほうがユーザーからの人気が高いんです。今回の「時界震天ラジエル」はガッツリ綺麗なお姉さんだったので、正直「大丈夫かな?」と心配していた節もあったのですが、人気が出てよかったです。

イラストレーターさんのフェチと熱意で通した黒髪のお姉さんが人気でよかったです

3.5周年の後夜祭も大成功

最後に、4/1のエイプリールフールのイベント「劇場版ゴエティアクロス 勇者爆誕!マステマイザー!」について教えてください

3.5周年の後夜祭で大々的にエイプリルフールネタを去年の9月くらいのタイミングから考えてました。
最初のエイプリールフールが魔法少女物だったので、今回はSFチックなロボット物にしようかなと思いました。

「本当にヒーローにしてやるぜ!」ということでヒーローになったマステマ

ちなみに、マステマを選んだ理由はですね、マステマには外伝で「ヒーローになりたい夢」があったからです。「それなら本当にヒーローにしてやるぜ!」という気持ちから、マステマイザーが生まれました。

実をいうとあのシナリオの原案は私が書いたんです。それをプランナーの久野がさらに面白くしてくれました。マステマのスーツやマステマイザーのビジュアル、LBの演出も、デザイナーだけではなくスタッフ全員でどうするかなど会話したくらいに力が入ってました。ロボデザイン見た時はかっこよすぎて痺れました!

ゴエクロらしい開発スタイルだったんですね

実際にマステマイザーが世に出た後、ユーザーがワイワイと盛り上がってくれていたので、「みんなヒーローものやロボットのも好きなんだな。うんうん」とちょっとうれしくなりました(笑)

4周年はどうなる?

最後に、4周年についてもちょっとだけ教えてください!

4周年はゴエクロにとっての大きな変化のタイミングとしたいと考えています。
天界との戦いの最中、主様やエルたちはどう立ち向かうのか? また、その先に一体何が待っているのか?
長年続いた流れから新しい流れに変えていく、そういう周年にしたいなと思っています。

もしかしたらゴエクロ2もあったりなかったり?

どうでしょうね。あるかもしれない、ないかもしれない……ですね! これからも全力でやっていきます!

【祝!今年も日本一】第13期女流球聖戦・アピリッツの荒木 愛がタイトル防衛に成功しました

0

アピリッツが誇る日本一のアマチュアポケットビリヤード選手・荒木さんが、日本アマチュアポケットビリヤード連盟主催の「第13期 女流球聖戦」にて、タイトル防衛に成功しました! ということで、今回も優勝記念インタビューです。(2022年4月 取材)

―― 荒木さん、優勝おめでとうございます。初めての防衛戦はいかがでしたか?

荒木:とても緊張しましたし、挑戦者だった去年よりも苦しい試合になりました。勝った瞬間は「嬉しい」よりも「疲れた」という気持ちが大きかったですが、今は勝てて良かったなぁとひと安心です。

―― 去年の女流球聖タイトル獲得時に「”今回はラッキーだった”と思われないように」と言っていたのが印象的でした。この一年、ビリヤードの練習量や試合への心構えで変化はありましたか?

荒木:練習量は以前と変わらずでした。去年と同じくコロナ渦が続いていたのでビリヤード場の時短営業もありましたが、その中でもモチベーションは維持できていたと思います。試合も開催数は少なかったのですが前より気を引き締めて臨むことができたと思います!その結果、大きな試合で優勝や入賞もできました。

かっこいい(引用:https://www.onthehill.jp/archives/53894 )

―― プロも参加する『なでしこグランプリ2021』で準優勝したり……

荒木:そうです!

―― アピリッツでの仕事と日本トップクラスのビリヤードの腕を両立させているのもすごいです。ということで、荒木さんがサポートを続けているアピリッツのエンパワーメントサービス部(ES部)についても聞きたいです!

荒木:ES部はいいですよ~。アピリッツの社内からも、そして社外からも、ES部の仲間となってくれるクリエイターが今後さらに増えるといいなと願っています。アピリッツの社内よりも大きなゲームプロジェクトに関わることができたり、最新の技術に触れる機会があったりと、スキルアップ、経験につながると思います! 社外のプロジェクトに参加することに不安がある人もいるかと思いますが、「他社に留学できる」くらいの気持ちでチャレンジしてもらえると嬉しいです。

―― ありがとうございました!

↓ 当日の荒木さん勝利の瞬間です! かっけー!

関連:【祝! 日本一】第12期 女流球聖位 荒木 愛 インタビュー【ビリヤードと仕事の話をします!】

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

最近人気な記事