oguma

Aimingインフラチームを支え(てくれてい)る技術と設計(3/3)



この記事を読むのに使用する時間の目安 = 5〜10分

你好!
Magandang hapon po!
こんにちわ! インフラチームの 小熊 です。

前回 から大分時間が経ってしまいましたが、Aimingのインフラ事情をいくつか紹介したいと思います。

TL;DR

必要だと思える時にTDIでインフラ構築をするようにしています。
また、インフラのテストもCIで回すようにしています。
普段はGithubで、その結果とReview commentを見てmergeといった流れになります。
とくに新規性のある内容はありませんが、誰かの何かのヒントになればということで、Tipsなども少し載せます。

本題

TDI

TDI (Test driven infrastructure) = テスト駆動インフラストラクチャ
を指します。

インフラの「品質管理, 事故防止, 安定したリリース管理」を行うため
定義したインフラが適切に動作するかをテストしながら構築していく手法になります。

その考え方自体は古くからあり、以下のようなサイトが参考になります

前回紹介したとおり、弊社ではServerspecを使用しています。

AnsibleやKubernetes など、もともとインフラを定義するもので、さらに重ねてインフラを定義してテストを行う必要はあるのか? という議論もあると思いますが、以下の条件の際は出来る限りテストを書くようにしています。

  • private関数, local変数 のような scopeが限定的なものは基本的にテストしないが、逆にscopeが広い場合
    • Ansibleは基本的にglobal scopeになります
  • roleなどの汎用性を高くしていて組み合わせて利用している上で、それぞれのroleで依存関係もある場合
  • 全てのエラーで停止するわけではなく、楽観的なエラーハンドリングが存在する場合
    • e.g,) Ansibleだと ignore_errors, failed_whenを使っている箇所がある
  • 複数のtoolや環境を組み合わせていて、統合的なテストがしたい場合
    • e.g,) Ansible on the Vagrant, Containers + VM Instances

他にも、重要な箇所で安心感を得るために書いた方が良いときは書くようにしていて、Jenkins等のCIでテストを回すようにしています。

pipelineで全ての環境変数による設定のテストを行い、それで問題を発見した場合はmerge前にfix commit を入れるようにしています。

Serverspec Tips

基本

以下を参考にroleで分けるようにしておくと扱いやすいです。
http://serverspec.org/advanced_tips.html#how-to-use-host-specific-properties

また、一般的ではありますが環境変数で制御するようにすると汎用的に扱えて良いです。
例えば、Jenkins によるテストの場合はどうするとか、タイトルにより特別な設定があるといったこともテストができるようにした方が良いと思います。

Rakefile サンプルコード

require 'rake'
require 'rspec/core/rake_task'
require 'yaml'
require 'highline/import'
require 'json'

unless ENV['ANSIBLE']
ENV['TARGET_HOST_YML'] = ask("Enter servers.yml path (spec/env/servers.yml): ")\
  if ENV['JENKINS_SERVER_COOKIE'].nil?
end
ENV['TARGET_HOST_YML'] = 'spec/env/servers.yml'\
  if ENV['TARGET_HOST_YML'].nil? || ENV['TARGET_HOST_YML'].empty?

desc "Run serverspec to all hosts"
task :spec => 'serverspec:all'

namespace :serverspec do
  properties = YAML.load_file(ENV['TARGET_HOST_YML'])
  task :all => properties.keys.map {|key| 'serverspec:' + key.split('.')[0] }

  properties.keys.each do |key|
    msg_for_test="on Vagrant" if "#{key}" === "wordpress"
    desc "Run serverspec to #{key} #{msg_for_test}"

    RSpec::Core::RakeTask.new(key.to_sym) do |t|

      # 環境変数チェック #########

      # Setされているか検証したい環境変数
      verify_env_vars = %w[PJCODE TARGET_ENV SERVER_NAME]

      # verify_env_vars の環境変数 を使用していないServerspec roles = 環境変数Set有無の検証をしたくないrole
      no_verify_roles = %w[vuls] # このroleは上記の環境変数は使っていないから存在チェックもしない

      properties[key]['roles'].each do |role|
        no_verify_roles.each do |no_verify_role|
          if !role.include?(no_verify_role)
            verify_env_vars.each { |env_var| raise NameError, "環境変数 #{env_var} がセットされていません" if ENV[env_var].nil? }
          end
        end
      end

      ENV['TARGET_HOST'] = key
      t.pattern = 'spec/{' + properties[key]['roles'].join(',') + '}/*_spec.rb'
    end
  end

  properties.values.each do |role|
    json = JSON.load(role.to_json)
    ENV['SERVERSPEC_ROLES'] = json['roles'].to_s
  end
end

Serverspecで、あいまい(範囲)判定がしたいとき

厳密性が必要なく、あいまいな判定にしておきたいときもあると思います。

たとえば、サーバのSpecで自動的に設定される値をテストしたい場合
(e.g,  リソースが異なるサーバが数種類あるけど、計算上は全てこの範囲に収まっていれば問題ない。など)

そのようなときは以下のようにすると判定ができます。

describe command("awk '\$1~/start_servers/{ print \$3}' /etc/php-fpm.d/#{ENV['PJCODE']}.conf") do
  its('stdout.to_i') { should be_within(14).of(20) }
end

この場合、14が差分になります。
20に対して、+-14 以内が許容される という意味になります。

上記の例ですと、
下が6 までok, 上が 34 まで ok
となります。

mariadbのinnodb_buffer_pool_size を自動的に設定している場合も範囲で判定しています。

mariadb10のspec sample

# spec/mariadb_10/variables_spec.rb
require 'spec_helper'

describe command("awk '\$1~/innodb_buffer_pool_size/{ print \$3}' /etc/my.cnf") do
  its('stdout.to_i') { should_not be_within(99.9).of(100) }
end

上記の例は、should_not判定なので
俺の innodb_buffer_pool_size が 0.1 から199.9 の範囲に収まるわけはない
もっと多く割当たるはずだ
という判定になります。

ちなみに上記で、
innodb_buffer_pool_size         = 2000MB
など、MBなどの単位が入っていても問題なく判定できます。

https://ja.stackoverflow.com/questions/23703/serverspec-%E3%81%A7-%E7%AF%84%E5%9B%B2%E6%8C%87%E5%AE%9A%E3%82%92%E3%81%97%E3%81%9F%E3%81%84-rspec-%E3%81%A7%E3%81%84%E3%81%86-be-within-of-%E3%82%84-start-with

その他のテストツール: infrataster

インフラ面から見てエンドツーエンドのテストを簡単に行えるように出来るツールです。
CapybaraやSelenium のようなインフラ用のツールです。
deploy後のチェックに使ったりします。

こちらも割と多くの記事が出ていますので
細かい説明や手順は載せません。

この記事は、要所だけということで。

infratasterの設定について

通常は以下のように設定します。

Infrataster::Server.define(
  # Name of the server, this will be used in the spec files.
  :proxy,
  # IP address of the server
  '192.168.0.0/16',
  # If the server is provided by vagrant and this option is true,
  # SSH configuration to connect to this server is got from `vagrant ssh-config` command automatically.
  vagrant: true,
)

これを汎用的に使いたい場合は、同じく環境変数でハンドリングするようにしますが、設定情報はyamlでまとめておいた方が楽なので、以例えば、以下の様に環境変数 SERVER_NAME にSETするようにして、該当するYAML内の残りの設定を読み込ませるようにすると良いと思います。

spec/spec_helper.rb の例

# spec/spec_helper.rb
require 'infrataster/rspec'
require 'highline/import'
require 'yaml'

raise "Error: 環境変数 SERVER_NAME が入っていません\n\
`コマンドラインからecho $SERVER_NAME` で確認の上、`export SERVER_NAME=xxx を実行してください`\n\
e.g.) export SERVER_NAME=wordpress  # for vagrant"\
  if ENV['SERVER_NAME'].nil? || ENV['SERVER_NAME'].empty?

# Jenkinsのテストでは対話式にしない
ENV['TARGET_HOST_YML'] = ask("Enter servers.yml path (spec/env/servers.yml): ")\
  if ENV['JENKINS_SERVER_COOKIE'].nil?

ENV['TARGET_HOST_YML'] = 'spec/env/servers.yml'\
  if ENV['TARGET_HOST_YML'].nil? || ENV['TARGET_HOST_YML'].empty?

@properties = YAML.load_file(ENV['TARGET_HOST_YML'])

Infrataster::Server.define(:"#{ENV['SERVER_NAME']}") do |server|
  server.address = @properties[ENV['SERVER_NAME']]['address']
  server.vagrant = @properties[ENV['SERVER_NAME']]['vagrant']
end

spec/env/servers.yml の例

# For infrataster

example.com:
  address: '192.168.1.1/24'
  vagrant: false

# { Vagrant
wordpress:
  address: 'wordpress'
  vagrant: true

# } End of Vagrant

例えばこれで、
SERVER_NAME=wordpress bundle exec rspec
など。

こうしておくことで汎用的かつ、特定の対象をテストしやすくなります。

もちろんspec側でもその環境変数は有効に利用できます。

require 'spec_helper'

_uri = "http://#{ENV['SERVER_NAME']}/"

describe server(:"#{ENV['SERVER_NAME']}")do
  describe http(_uri) do
    it "reponse status" do
      expect(response.status).to eq(301)
    end

    it "responds with content inflated automatically" do
      expect(response.headers['content-encoding']).to be_nil
    end
  end

  describe capybara(_uri) do
    it 'shows welcome page' do
      visit '/'
      expect(page).to have_content 'WordPress へようこそ'
    end

    it 'shows sample page' do
      visit '/?page_id=2'
      expect(page).to have_content '新しく WordPress ユーザーになった方は、ダッシュボードへ行ってこのページを削除し、独自のコンテンツを含む新しいページ
  作成してください。'
    end

    it 'shows unclassified page from sample page' do
      visit '/'
      click_on '未分類'
      expect(page).to have_content 'カテゴリー: 未分類'
    end
  end
end

各ツール共通で使える値は、共通で扱える環境変数名にしておくとintegrationしやすいです。

e.g,)
export SERVER_NAME=”wordpress”
docker, k8s, ansible, serverspec, infrataster でも同じ環境変数を利用

Security check

vuls や専用ツールで定期的にチェックを入れています。

Kubernetes

最近、弊社でもKubernetesを扱うようになってきました。

Kubernetes-helmで YAML生成するのも良いと思うのですが、以下のようなsnippetツールを見つけたので、紹介させていただきます。

https://github.com/ipedrazas/kubernetes-snippets

少しは楽できるかな?と思い、使い始めたところです。

さいごに

誰かにとって少しでもお役に立てれば幸いです。
Aimingではインフラエンジニアも募集しております。
ご興味のある方がいましたら、ぜひご応募ください。


CephFSとGlusterFSの性能比較検証


こんにちは! インフラエンジニアの趙です。

業務では、主にゲーム公式サイトのインフラまわりを担当しています。

弊社の一部公式サイトでは、WordPressを用いてオートスケールを導入しています。データ以外でステートフルな部分はCephFSにまかせています。

CephFSの運用につきましては、弊社小熊の記事に詳細がありますのでご参考にしてください。

ちまたではCephFSよりもGlusterFSを使っている方が多く、理由の一つとしてその速度がよくあげられていますが、特に比較記事が存在しないようでしたので検証してみました。

今回、用いたCephFSは2017年の8月にリリースされたばかりのLuminousになります。
リリースノートを見る限りでは、jewel(前のLTS ver)よりも速度の面においてかなり進化してる模様です。

検証に用いたOSS一覧

OSS Version
CephFS 12.2.2
GlusterFS 3.10.5
nginx 1.10.1
php 7.1.9
MariaDB 10.1.26

CephFSの構成図

GlusterFSの構成図

検証方法

  • 測定するたびに必ずLinuxのcacheをpurgeする。
    • e.g. ) echo 3 > /proc/sys/vm/drop_caches
  • 測定結果は3回測定した後の中央値とする。

 

検証結果

  1. ddコマンドを用いて、大型のファイルを作成する時間を測定
  2. ddコマンドを用いて、小型のファイルを大量に作成する時間を測定
  3. アパッチベンチで100セッションを同時に送り、Request per secondを測定
  4. Fioでのベンチマーク
    1. random writeで10MBを16個並列で作成
      1. fio -name=r -direct=1 -rw=randwrite -bs=4k -size 10M -numjobs=16 -runtime=16 -group_reporting
    2. random readで10MBを16個並列で読み込み
      1. fio -name=r -direct=1 -rw=randread -bs=4k -size 10M -numjobs=16 -runtime=16 -group_reporting

結果

  • 今回の環境においては、単一のファイル作成、並列でのREADはCephFSのほうが速い。
  • 並列でファイルを作成する場合においては、GlusterFSのほうが速かった。

 

まとめ

  • 読み込みではCephFS、書き込みではGlusterFSの方が優秀と一長一短な結果となりました。
  • 弊社のWordPressを用いている案件では読み込みの方が重要なので、CephFSの方を採用すべきです。しかし、最新のCephFS検証において以下の不具合が発生したため、これからはGlusterFSを採用しようと考えています。
    • CephFSの不具合
      • FIOで(random write)のサイズを一定以上大きくした場合に、処理が止まってストレージにアクセスできくなる

 

最後に

“gluster backed block storage” を作成し、メンテナンスを容易にするgluster-blockが現在開発中のようです。これが上手く機能すれば、CephFS並の読み込み速度を得られるのではないかと期待しています。
検証してみたかったのですが、CentOS7では動かないようなので、今回は見送りました。
WordPressでオートスケールを構築する際、ストレージ候補の参考になれば幸いです。


takezawa

HALインターンシップレポート(東京本社編)


こんにちは。
人事の竹澤です。

大阪スタジオで実施した「HAL大阪/名古屋インターンシップ」に続き、
東京で実施した「HAL東京インターンシップ」について書きたいと思います。

東京本社では、HAL東京から7名の学生様におこしいただき、
実際の開発現場にてゲーム制作をおこないました。

チームは、プランナー2名、デザイナー3名、エンジニア2名。
チーム一丸となってゲーム制作に臨みます。
Aimingのインターンでは、各職種1名づつのメンターがつき、
不明点や疑問点をフォローをしながらをゲーム制作をおこなっていきます。

期間中のミッション&カリキュラムは以下の通りです。

ミッション&カリキュラム

「自律したチーム」「心理的安全性の確保」

  • 発言しやすい空気を作り、ミスを許容できることでチームの生産性を上げること
  • 課題や問題が発生したとき、まずは自分たちで”考えて”からメンター相談すること


講義

  • 企画の仕事について
  • デザイナーの仕事について
  • エンジニアの仕事について
  • git/レビュー講義&アジャイル開発について



フィードバック

  • スプリントレビュー(週1)
  • 中間発表
  • 最終発表
  • Aiming社員試遊会
  • Aimingマネージャーからの作品フィードバック(職種別)
  • コードレビュー(エンジニア)


社員交流会

  • マネージャーとの座談会
  • ランチ会
  • 懇親会

 

 

 

スプリントレビューやKPTなど振り返りを多くとることによって、現状を把握し問題点を早期発見することができました。
今回の制作では、(ほぼ)全ての管理をgithubでおこない、仕様や制作中の画像、バグ報告など一元管理することに成功しました!(github使ったことないメンバーもいたのにすごい!)

それでは、1か月の成果を簡単に紹介します。

制作物

【BOMBTET】


ジャンル:オンライン爆発アクションゲーム
ターゲット:20代の男女
コンセプト:協力して敵を倒す楽しさ


爆弾の爆破を利用して、仲間と協力し敵を倒すオンラインアクションゲームです!
遊び方は簡単!
自爆して、仲間を爆風で飛ばして、敵にぶつけて攻撃する!というもの。

1人で突撃しても攻撃できますが、部位ごとに与えられるダメージ量が違うので、
協力することで大ダメージを与えることができます!
スタンプを使ってうまく連携するのがポイントです。

また、キャラクターごとに特徴が違うので選択するキャラクターによっても
ゲームの難度が変わります。

試遊会では実際にオンラインで4人対戦したのですが、うまく爆風にのって攻撃できたときの爽快感がすごかったです!
(ちなみに私は下手すぎて全然違う方向に飛んだり飛ばしてしまったりでした…)

総評

フィードバックされたアドバイスを一身に受け止め、
こちらが提案した内容を自分たちなりに「考え」、出した答えを共有してくれる…
そんな素晴らしいチームでした。

チーム内の情報共有はもちろん、メンターへの報告や連絡を欠かさずおこなってくれたので
早い段階で問題を解消することができ、余裕をもって最終日を迎えることができました。

それぞれが自分の役割を果たし、相手を尊重できるそんなチームだったと思います。

毎日顔を合わせていたので少し寂しくなりましたが、
今回の経験を活かして新たなゲーム制作をおこなってくれることを楽しみにしています。



mori

HALインターンシップレポート(大阪スタジオ編)後編


こんにちは。人事の森です。

前編に続きまして、「HALインターンシップ」後編では、素晴らしい活躍を見せてくれた3チームの各リーダーに突撃インタビューを行いましたので、その様子をお送りします。

 

まずは、リーダーの紹介。

向かって左から、

  • Aチーム「Dengeon」:岡野 浩之さん(HAL名古屋)
  • Bチーム「コウモリたちのバッドディ」:横山 慈永さん(HAL名古屋)
  • Cチーム「キツネットワーク」:蒲生 大地さん(HAL大阪)

 

こちらの爽やかなお三人が様々答えてくれました。

 

(HALインターン リーダーインタビュー) ※敬称略

 

森:まずは、Aimingのインターンに参加しようと思った理由を教えて下さい。

・・・すごく緊張気味の3人ですが、まずは岡野くんから・・・!

 

岡野:僕はHAL名古屋から来てますが、HAL名古屋は先生からの紹介によってAimingさんを勧められました。僕のインターン先がAimingと知って、テンションあがりました。ログレスをやっていたので、とても嬉しかったです。

横山:僕はAimingのことはよく知らなかったですが、スマホゲームの会社だと聞いて嬉しかったです。最先端の開発を知ることが出来ると思いました。

蒲生:僕はHAL大阪で、HAL専科(夜間に行われる特別ゼミのような授業)でAimingさんの授業を受けていたので、Aimingのことはよく知っていました。そこで働く人達にとても興味を持ったので、インターンに行きたいと思い応募しました。

 

・・・Aimingは、HAL大阪で「専科」を受け持っています。「オンラインゲームプランニング専科」や「オンラインゲーム開発専科」など。蒲生君はプランニング専科の受講生でした。

 

森:3人はどうしてリーダーになったのですか?

全員:皆の推薦です。(全員一致)

 

森:Aimingでは、チーム開発を行う上で、「リーダー/リーダーシップ」は非常に大切なものだと思っています。社内では、随所でこの力が重要視されます。皆さんはリーダーって何だと思いますか?心掛けてることとかあったら教えて下さい。

岡野:皆を引っ張っていきながらも、前に出すぎるのではなくて、共に歩きながら肩を組み、周囲を鼓舞することを心掛けていました。リーダーはすごく有能な人じゃなくても出来るんだ、と思うようにしています。飛び抜けた技術がなくても、コミュニケーションをしっかりとることでリーダーシップを発揮しようと思いました。

横山:制作は終わりが見えないこともある。リーダーとは、「闇を払っていく役割」と思います。他の人を置いてけぼりにしてはいけない。

森:リーダーは「闇を払っていく」役割。良い言葉ですね。(闇を駆けるコウモリとかかっているいるのかしら・・・?) ※以下参照画像。

 

蒲生:チームメイトの仲を保つこと。今回のインターンでは、HAL名古屋の人は、大阪勢より人数が少ないので、肩身の狭い思いをさせないように気を付けました。そして、納期を守ることを厳守しようと思いました。過去に、クオリティを上げる事に必死になり納期を守らなかった経験があるので、その反省が元になっています。

森:Cチームの進捗報告、素晴らしかったです。あと何が残っているのか、この先の展望と合せて説明されていて、とても良かったです。

 

森:1ヵ月過ごした中で、「面白かった」ことを教えて下さい。

蒲生:学校でもチーム開発は経験していますが、ここに来てる人達はモチベーションが元々高いので、何もかもがスムーズだったことです。人生で1番楽しいチーム開発でした。チームメンバーの頑張りで、新技術を取り入れることも出来たし、たくさんのチャレンジがありました。

横山:リーダーを経験できたことです。リーダー経験は初めてではないですが、チーム全体のSlackの会話を俯瞰して眺めるようにしたり、全体把握に努めました。

 

森:では逆に、開発中に1番苦労したことはなんですか?

岡野:UNETの勉強が難しかったです。初めて触ったので、進捗が上手くいかず、何も出来ない状態が最初の1週間続きました。間に合うのかな・・と不安になりましたが、上手くいって本当に良かったです。他にはネットワークの環境構築やエフェクト、アニメーションの作成も、「苦労」とは違いますが、頑張りました。

横山:企画が決まるのが遅く、コンセプトを練るのに苦労しました。制作では、結合する時にバグが発生してしまい、バグをとったらまた別のバグが出る・・・これは大変でした。エンジニア全員でPhotonの勉強をやったことも印象的です。

蒲生:企画が2週目の水曜日まで決まらなかったので、エンジニアに負担をかけてしまいました。HALではまだネットワークをやっていないので、Photonを初めてやったし、Sub versionを触るのも初めてでした。初めてのことは大変ですが、インターンを通して学べたことは大きいです。

・・・初めての経験を試行錯誤してちゃんと成果物として完成できた、素晴らしい・・・!

 

森:幾つか行ったグループワークはいかがでしたか?

岡野:紙飛行機のワークショップが印象に残ってます。丸めて飛ばしたのは僕のチームですが、飛びはしたけど、「品質としてはお客様に出せないよね」と言われたのが気付きでした。思考錯誤の過程も面白かったです。ログレスディスカッションは、緊張して頭真っ白だった。記憶がないです(笑)

横山:マシュマロチャレンジや紙飛行機のように、ルールを初めて知り、限られたツールや時間の中で実施する体験は初めてでしたが、発想力を持ってチームワークで改良してくのが楽しかった。

・・・チームワークで見事に改良した結果がこの笑顔^^
蒲生:僕も、紙飛行機チャレンジが印象的です。クオリティを求めすぎて、求められてるのは「3メートル以上飛ぶことを量産する」なのに、6メートル以上飛ぶことを誇ってしまった。他には、見積もりと結果という考え方や、固定概念に囚われないこと等、「なるほど」と思うことが多かったです。

・・・これですよね。めちゃくちゃ飛んでましたよね。歓喜の声が響いてました。

 

 

森:Aimingのスタッフ(主にメンターさん)と交流しての印象を聞かせて下さい。
蒲生:とにかく「優しい!」です。先程褒めて頂いたタスク管理の方法は、メンターさんに教わったんです。すごく参考にしました。ホワイトボードに アナログトレロを書いて「タスクの見える化」を教えてくれたのもメンターさんです。見える化は凄く大事。身をもって知りました。これを取入れてから、開発が一気にスムーズになりました。メンターさんは自分より年が3つだけ上とは思えない程、しっかりしている。何か相談したら、最初に必ず「それ分かる」って共感してくれるんです。この言葉にすごく安心しました(笑)

横山:メンターが自分たちを信頼してくれてると感じました。お母さんが息子を見るような温かい目で見てくれました(笑)気軽に沢山のことを相談させて頂きました。

 

・・・試遊会では、ディレクターがゲームの感想を伝えます。メンターも同席し、フィードバックを確認。真剣そのものです。

 

岡野:色んな指導の仕方があるのだということを知りました。厳し目なお言葉も貰いましたし、成果物を見て褒めてもくれました。砂漠とオアシスを両方持っていて、締める所はちゃんと締めてくれてる。厳しさとやさしさを併せ持っている印象です。

 

森:何かしらの成長がありましたか?

全員:YES!

・・・最後の言葉、「YES!」を聞いて、私たちも心底「よかった」といえるインターンシップでした。参加してくれた学生の皆さん、1ヵ月本当にお疲れ様でした。

 

 

(まとめ)

1ヵ月を通して、皆個々にチャレンジがあり、成長を実感できる体験が出来たとの言葉、何より嬉しく思います。3チームともに素晴らしかったのは「チームワーク」。リーダーに協力しようという姿勢があり、リーダーはメンバーを思いやる心があり、終始明るい雰囲気のまま進行しました。また、インタビュー中には「メンターさんが厳しい言葉をくれた」との回答がありましたが、該当メンターは入社1年目の新卒スタッフ。後輩が出来、指導する立場となってその難しさに直面し、言わなくてはいけないという責任感から出た言葉なので信頼関係が生まれる。こちらにとってよい学びの機会となりました。

 

 

・・・こちらの写真↑ Bチームメンバーと、一昨年にこのHALインターンのメンターを努めてくれたAimingスタッフの姿も。昨年メンターを努めたスタッフが、翌年にはメンターさんのアドバイザー的なポジションとして、順繰りに後輩をサポートしていく仕組みがあります。

 

Aimingでは通年を通して多くの職種でインターンシップを受入れています。広々スペースで思い切り議論し、物作りに没頭することが出来ます!カリキュラムやスケジュールは柔軟に対応していますので、興味ある皆様、エントリーお待ちしています。

 

 

(おまけ)

 

最終日の打上げにて。多くのAimingスタッフも参加し、盛り上がりました。

 

 

             ★皆さんの未来に乾杯★

 

(完)

 

 


mori

HALインターンシップレポート(大阪スタジオ編)前編


こんにちは。人事の森です。

今日は、毎年恒例、大阪スタジオ10月の風物詩でもある「HALインターンシップ」について書きたいと思います。

大阪スタジオでは、HAL大阪とHAL名古屋から総勢24名の学生さんにお越し頂き、今季増床したばかりのオフィススペースを使ってインターンシップを行いました。広々としたスペースなので、活発な議論を交えながら伸び伸びと制作活動を行うことが出来たと思います。

今年のテーマは「伝える」「伝える」をテーマにしたゲームを制作してもらいます。24名をA、B、Cの3チームに分け、ゲーム制作を行います。1チームの内訳は、エンジニア4、プランナー3、デザイナー1。なかなか良いバランスではないでしょうか。
さて、3チームから、どんな「伝える」ゲームが生まれるのか・・・楽しみしかありません。

インターン生のフォロー体制としては、管理者やアドバイザーの他、最もインターン生と身近に接する「メンターさん」を任命します。このメンター任務を任されたのは、入社1年目の新卒エンジニア、新卒デザイナー、2年目のプランナーが2名という4人の若者達。彼らにとっても、学生を指導することで学びや気づき等、得るものがあることを期待して、インターンシップは始まりました。

 

1ヵ月という、長くて短いこの期間中に詰め込んだミッションやカリキュラムはざっと以下の通りです。

  • 「伝える」をテーマにゲームを制作(メイン)
  • 「中間発表」「最終発表」「Aimingディレクター試遊会」「Aimingスタッフ試遊会」による4段階のフィードバック(これも大事)
  • PDCAサイクルやチームワークの活用に着目したグループワーク(盛り上がりました)
  • 「ログレス」を分解するグループディスカッション(ログレスディレクターを前に、緊張で記憶がないという子がいました)

 

↓ ディレクターやメンターによる試遊会。思いがけないバグも発見されました。

 

↓ スプリント中に、「3メートル以上飛ぶ紙ヒコーキを幾つ生産できるか」というグループワーク。PDCAを上手く回して、チームで紙ヒコーキを作ります、飛ばします、そして数えてまた作ります。かなり忙しくスプリントを回していきます。

 

こ、これは・・・! 紙くず・・・? ゴミ・・? いや、紙ヒコーキ・・?

驚異的な数が3メートルを超えていますが、これを「紙ヒコーキです」とお客様に出すことはで出来ないでしょう。「紙ヒコーキ」の固定概念に囚われない姿勢は良いかもしれません。

 

 

それでは、1ヵ月の成果であるゲーム作品を、それぞれ簡単に紹介したいと思います。

 

まずはAチームから・・・

「Dengeon-美女と呪いの冒険」 

 

「伝達」の「デン」+「ダンジョン」=「デンジョン!」ピクトグラム(絵文字)によって「伝える」をデザインした最大4人同時プレイのマルチプレイヤーローグライクゲーム。
画面構成はサイドビューで、基本的にキャラクターの移動やバトルは自動で進行していきます。そこでこのゲームの肝となるのが絵の伝達というものです。(出た!伝える!)

各プレイヤー毎に示された異なるピクトグラムを全員が同時にお絵描き板に描く。そのピクトグラムを伝えあうことで、扉の先に待ち受けている様々な要素を推測していきます。その推測結果を元に有利な道を選択し、体力の回復、強力な武器の取得などを重ね、最終的にはボスを倒せればゲームクリアーとなります。
ローグライクというランダム要素がベースにありながらも、情報を的確に伝達することで最適な道を選択できる!ですが、お絵かきには時間制限があるので、うまく伝えられない時は、ランダム性による不安定なゲームプレイになってしまうという、何とも絶妙なこの塩梅がこのゲームの面白いところです。

 

 

続いて、Bチームは、ホラーゲームが好きなメンバーによる

「コウモリたちのバッドディ」

最終発表会は、10月31日。つまり「ハロウイン」です。季節感にちなんだ作品を制作するなんて乙だなぁと感想を述べたところ、それは関係ないとのこと。でもコウモリがパンツ履いていて可愛いので問題ありません。

このゲームは、3人 vs 1人の4人同時プレイ、鬼ごっこタイプのマルチプレイヤーホラーアクションです。3人チームのコウモリ側と、1人のコウモリ駆除ロボット側に分かれてゲームをスタート!

逃げるコウモリ、追いかけるロボット・・・まさしくホラーです!でも赤や黄色のパンツがとってもキュート。

 

コウモリ側はマップに散らばった脱出用アイテムの歯車を一定数集め脱出すると勝利になります。また、一定時間以上逃げ延びても勝利です。(私はひたすら逃げ延び、そして勝利しました・・・!)

ロボットは制限時間内にコウモリを全て捕まえると勝利です。
コウモリは、暗闇の中、音波を飛ばして壁に反射させることでマッピングを行い視覚化することが出来ます。また、その視覚化したマップ情報をコウモリチーム間で共有し、これを脱出に活用します。(出た!伝える!)
ロボットは高性能なので自身が出した音と、さらにコウモリの音波もキャッチして有利にマップを走破できます。
暗い工場という不気味なマップの中を追われる恐怖と、追い詰め捕まえるという緊張感を味わうことができるゲームです。(でもカラフルなパンツがキュートです。)

 

最後はCチーム

「きつねっとわーく」

プレゼンがとっても上手なCチーム。発表会では、まるで自社商品を売り込むかのようなプレゼンで、私も思わず「早く遊びたい!」と言ってしまいました。チュートリアルもゲームプレイしながら体験できるようになっていて、とても分かりやすかったです。

このゲームは、3人同時プレイのマルチプレイヤープラットフォームアクションです。プレイヤーはそれぞれのキツネを操作して、全員でゴールとなる鳥居を目指して走ります。キツネにはそれぞれ、「目の良いキツネ」、「鼻の良いキツネ」、「耳の良いキツネ」と能力が割り振られており、その能力で道中に仕掛けられた様々な罠を発見することができます。

ですが、各キツネには1つの能力しか割り振られていないので、自分に分かる罠は他の2人では気付くことができません。そこで「いいね!」と「危険!」の2つのエモーションを使って罠や、見えない床の存在などを知らせる必要があります。(出た!伝える!)
コミュニケーションに使えるのは2つのエモーションのみなので危機の伝達を行うものの、上手くいかないこともあります。時にはジャンプや左右への移動などの身振りも合わせてコミュニケーションを模索しますが、上手く伝わったり、伝わらなかったりと、何とも言えないもどかしさがあります。これを開発チームは演出したかったのでしょう。このもどかしさが意外な程に心地よく、ワイワイと盛り上がる要素になっていて、パーティゲームとしてもとても楽しめました。(私は、「もう1回だけ」と言いながら何回もプレイさせてもらいました!)

 

(まとめ)

それぞれに個性の光る「伝える」ゲームが完成しました。フィードバックの場では、鋭い指摘やアドバイスをたくさん受ける場面がありましたが、落ち込む素振りもなく、真剣に意見を吸収しようとする姿勢がとても印象的です。今年のインターンは、3チームともに「チームワーク」が素晴らしかったです。

いつも、インターンの開発現場に入ると、元気いっぱいに「おはようございます!!」「お疲れ様です!!」。そんな元気な挨拶から始まり、最後は「ありがとうございました!!!」と、これまた気持ちの良いご挨拶を下さりました。

些細なことかもしれませんが、こんな元気な挨拶は、チームだけでなくインターン全体の雰囲気を明るく前向きに動かし、チームワークの醸成を促し、良いゲーム作り、チーム作りに繋がっていくのではないかと感じました。

次回、後編では、この3チームそれぞれのチームリーダーに、1ヵ月間を振返っての直撃インタビューを行いましたので、その様子をレポートします。

 

(おまけ)

最後は皆で記念撮影。賑やかだったスペースが静かになって少し寂しいです(´;ω;`)

 

皆さん、お疲れ様でした。後編に続く。