読者です 読者をやめる 読者になる 読者になる

Google Apps Scriptの開発をモダンに行う方法

株式会社Speeeの山本です。皆様、こんにちは!

今回ご紹介させていただくのは、Speeeで実践しているGoogle Apps Script(以下 GAS) を用いたモダンな開発手法についてです。この記事を通してGASって「便利だし使えるかも!」と思っていただければ幸いです。

Google Apps Scriptとは

Google Apps Scriptは、言わずと知れたGoogleが提供するサーバサイドのスクリプト環境です。 基本的にはWebブラウザを通して開発を行います。 f:id:bino98ty:20160428185259p:plain

作業効率化に威力を発揮するGAS

Speeeでは特に、管理部門の作業効率化でGASを使用しているケースが多く、例えば

  • Slackの制限付きユーザを各種チャネルに招待するアプリケーション
  • メーリングリストの文面生成を自動化するアプリケーション
  • Speeeラウンジの使用状況を閲覧するアプリケーション

など、様々な用途でGASが使用されております。 また、GASはGoogle ドキュメントやGoogle スプレッドシートなどへの強力なAPIが用意されており、Google Driveを日常的に使用している環境では、特にGASを利用する利便性を見込めるのではないかと思います。

こんなに便利なGASですが、単なる作業効率化ツールとしての枠を超え、1つのアプリケーション開発に、GASを使用するケースも登場します。

開発事例の紹介

経理業務支援のアプリケーション開発にGASを採用

現在私は経理業務支援のアプリケーションを開発しているのですが、メイン機能はGoogle スプレッドシートとGASのみで開発しています。 経理業務支援のアプリケーションでは、 - クライアント様への売上/請求の一覧化 - 入金情報の管理 - 請求書発行と送付 という業務の自動化や効率化を行っています。

秘匿性の高い情報をGoogle スプレッドシートに預けることに対しての不安に思うかもしれませんが、 Google Appsが持つ強力なユーザ管理機能や、端末<->サーバ間の通信のセキュリティ対策を十分に行っているGoogle Appsを利用する方が、 オンプレでサービスを設置したり、他のクラウドサービスへホスティングしたりするより、信頼性が高いと思っております。

技術選定の場に於いて、下記のような理由でGoogle スプレッドシートとGASに利用が決定しました。

  • ユーザインターフェースを作成する工数の大幅カットが見込める。
  • Google スプレッドシートは 経理担当者 が直接システムを変更する余地がある。
    • (経理業務ドメインは難解のため、エンジニアと現場の方と共同で開発していきたかった)
  • 経理の方にとってGoogle スプレッドシートはExcelに似ているため新システムの学習コストが低い。

すべてWebブラウザで完結できることは上記のような利点もありますし、良いことのように思えます。 しかしエンジニアとしては、自分の好きなエディタを使って開発をしたいし、バージョン管理したいし、テストも書きたいし...と思うわけです。

Google Apps Scriptの開発をモダンに行う方法

Google Apps Scriptをローカル環境で...

今年の1月のことです。Googleのデベロッパーブログに下記の記事が公開されました。

コマンドラインから Apps Script プロジェクトをアップデートするためのコマンドラインインターフェース(CLI) が公開したとのこと。早速導入してみました。

使い方

本CLIを利用するためには、下記が必要です。必要に応じてインストールしておいてください。

  • node v0.12.x 以上

早速インストールして使ってみましょう。

$ npm install -g node-google-apps-script

Google の Developers Console から gappsで使うための OAuth2、その他のアプリケーション としてキーを発行します。詳しくはnode-google-apps-scirptのGitHubを見ていただければと思います。 https://github.com/danthareja/node-google-apps-script#11-default-apps-script-developer-console-project

無事に発行ができたら、キー情報が含まれたJSONを落としてください。あとは、インストールしたてのgappsコマンドを用い、認証をします。

$ gapps auth ./client_secret_<client_secret_key>.json

上記コマンドを打つと、

Please visit the following url in your browser (you'll only have to do this once): https://accounts.google...

などと表示されるはずなので、URLを踏んで認証してください。

Successfully Authenticated with Google Drive!

と、表示されるはずです。 gapps authで行った認証の情報については、ホームディレクトリ以下の.gappsに保存されます。

認証を無事に終えたら、gappsコマンドで管理するGASのファイルを指定します。 Google Drive上でGASのファイルを生成し、 ブラウザ上のエディタでスクリプトを保存してください。 f:id:bino98ty:20160428185257p:plain

そのURLにある Project ID をコピーして、下記のコマンドに貼り付けてから、実行してください。 f:id:bino98ty:20160428185258p:plain

$ gapps init <Project ID>
# Example
# gapps init jiofe3g4jHfr5dekD5deNIO9e...

いかがでしょう。ローカルに下記のGASのファイル達が落とされたと思います。おめでとうございます!

.
├── gapps.config.json
└── src
    └── コード.js

あとは、よしなにファイルを編集して、下記のコマンドを実行すると、ブラウザ上のGASも更新されているかと思います。

$ gapps upload

また、gappsコマンドを使うとき、下記のことを知っておくと良いかもしれません...!

  • GASにアップロードされるファイルは、jsファイル、htmlファイルのみです。
  • jsファイルは、アップロードのタイミングで、gsファイルに自動で変換されます。
  • リモートからローカルにファイルをダウンロードできるのは、この時だけです。例えば、gapps init した後に、ブラウザのエディタでコードを編集しても、ローカルには落としてこれません。

ローカルに落とせたということは...

GASのファイル郡をローカルに落とせるようになったということは、下記のことが可能になりました。

  • GitHubによるバージョン管理が可能になりました。
  • テストも書くことが出来るようになりました。
  • タスクランナーを用いることで、ECMAScript2015(以下 ES2015)記法やTypeScriptをローカルで書いて -> ES5に変換 -> アップロードというフローでの作業が可能になり、Googleへのアップロードを自動で行うこともできるようになります。

ここからは、応用編として上記3つの方法の実施についてもご紹介します。

応用編1: GitHubによるバージョン管理

早速やっていきましょう。 まずは、GitHubにRepositoryを作成し、リモートを追加します。

$ git remote add origin git@github.com:ユーザー名/プロジェクト名.git

次に、Gitの初期化を行い、管理対象のファイルをコミットします。

# GASを落としてきたディレクトリ上で...
$ git init

あとは、ファイルをよしなに編集し、add/commit/push!

$ git add .
$ git commit -m 'initail commit'
$ git push origin master

いかがでしょう。GitHubのリポジトリページを覗いてみてください。GASのファイル達がお待ちです。

応用編2: テストを実施

先述のGoogleのブログにもあるように、スクリプトをローカルに落とせれば、機能テストを書くことも可能です。

今回は、テストフレームワークにmocha、アサーションライブラリにchaiを導入してテストを書いてみます。

$ npm install -g mocha
$ npm install -g chai

次に、テスト用のjsを置くディレクトリを作ります。

$ mkdir test

あとは、テストを書いてあげてください。

プレーンなJavaScriptでnodeのrequire()を利用するため、今回は Browserify + Gasify を使ってみます。Gasifyはjs2gsのBrowserifyプラグインとなります。

$ npm install -g browserify
$ npm install -g gasify

GASにアップロードされるのはデフォルトの設定ではsrcに入っているjs、htmlファイルだけなので、

.
├── gapps.config.json
├── dev
│   └── hello.js # テスト実行先のJS
│   └── main.js  # browserify元JS
├── src
│   └── main.js  # browserify先JS
└── test
    └── hello_spec.js  # テスト元のJS

というディレクトリ構成を作り、コードの実態をdevディレクトリ以下に書き、テストをtestディレクトリ以下に記述していきます。

まずは、下記のようにhelloメソッドに対するテストを書きます。

var chai = require('chai');
var should = chai.should();
var hello = require('../dev/hello');

describe('code.js', function() {
    context('echo', function() {
        it('should return Hello yamamoto when the value is yamamoto', function() {
            hello('yamamoto').should.equal('Hello yamamoto');
        });
    });
});

そして、実態を用意します。

module.exports = function(name) {
  return 'Hello ' + name;
}
var hello = require('./hello');
global.callHello = function () {
  Logger.log(hello('yamamoto'));
}

さて、ここでテストを実行してみます。

$ mocha
  code.js
    echo
      ✓ should return Hello yamamoto when the value is yamamoto


  1 passing (7ms)

無事にテストが通りました!

そして、browserifyにsrc/main.jsを出力させアップロードし、GASとして使えることも確認します。

$ browserify dev/main.js -p gasify -o src/main.js
$ gapps upload

GASのエディタ上からcallHelloを選択、実行すると、

f:id:bino98ty:20160428185300p:plain

ツールバーから 表示 > ログ で出てきた画面上に、Hello yamamotoと表示されていますね。

f:id:bino98ty:20160428185301p:plain

これで、helloメソッドの機能テストがかけるようになりました!良かった。

応用編3: Gulp連携

さて、ES2015で盛り上がる昨今、GASもES2015で書きたいと思うエンジニアの方も多いはずです。 プロトタイプベースのオブジェクト指向であったES5と比べ、Rubyや他の言語で見られる クラスベースのオブジェクト指向を取りいれたES2015ですが、 普段からRubyやJavaを書いているサーバサイドエンジニアにとっても、Javascriptを書く障壁が低くなること、間違いないです。

さて今回は、Babel + GulpでES2015 -> ES5変換する手法を取り入れます。

まずは、Gulpのインストールからです。 1つ1つ$ npm install...するのがめんどくさいので、今回はこちらでインストール時に発行されたpackage.jsonを使います。 gapps initしたディレクトリに下記のJSONを保存します。

{
  "devDependencies": {
    "babel": "^6.5.2",
    "babel-core": "^6.7.4",
    "babel-preset-es2015": "^6.6.0",
    "babel-register": "^6.7.2",
    "gulp": "^3.9.1",
    "gulp-babel": "^6.1.2",
    "gulp-exec": "^2.1.2",
    "gulp-load-plugins": "^1.2.0",
    "gulp-plumber": "^1.1.0",
    "gulp-mocha": "^2.2.0",
    "browserify": "^13.0.0",
    "babelify": "^5.0.5",
    "gasify": "^0.0.1",
    "vinyl-source-stream": "^1.1.0",
    "mocha": "^2.4.5",
    "chai": "^3.5.0"
  },
  "babel": {
    "presets": ["es2015"]
  }
}

今回、ES2015で書かれたコードは、browserify -> babelify(+ gasifyプラグインを適用)という流れで、GASへのアップロードを行うファイルを生成します。 babel6系を使用する最新のbabelifyを使い、トランスパイルするとGASのアップロードする際に、失敗してしまうことがあります。 ですので、今回はbabel5系を使用するbabelify5.0.5を採用しています。

そして、同一階層上でインストールを実行します。

$ npm install

さて、あとでES2015を記述するディレクトリと、ES5をしまうディレクトリを作成します。また、ついでにgapps uploadも同じタイミングで実行してもらいます。

先述の通り、gapps uploadは、srcディレクトリのみをアップロードしようとするため、GASへ出力するJSの吐き出し先はsrcとします。

今回は下記のようなディレクトリ構成で実行していきます。

.
├── gapps.config.json
├── gulpfile.babel.js # gulpのタスクを実装するJS
├── dev_es2015   
│   └── hello.js # テスト対象のJS
│   └── main.js  # browserify元JS
├── src
│   └── main.js  # browserify先JS
└── test
   └── code.js   # テスト元のJS

下記のファイルをリポジトリルートに置いてください。

import gulp from 'gulp'
import gulpLoadPlugins from 'gulp-load-plugins'
import browserify from 'browserify'
import source from 'vinyl-source-stream'
import runSequence from 'run-sequence'

const $ = gulpLoadPlugins()
const src_es2015_file = 'dev_es2015/**/*.js'

gulp.task('gas-upload', ['browserify'], () =>
  gulp.src('.')
    .pipe($.exec('gapps upload'))
)

gulp.task('test', () =>
  gulp.src(['test/**/*.js'], { read: false })
    .pipe($.mocha({ reporter: 'spec' }))
)

gulp.task('browserify', ['test'], () =>
  browserify({
    entries: ['dev_es2015/main.js']
  }).transform('babelify')
    .plugin('gasify')
    .bundle()
    .pipe(source('main.js'))
    .pipe(gulp.dest('src'))
)

gulp.task('watch', () =>
  gulp.watch(src_es2015_file, ['test', 'browserify', 'gas-upload'])
)

また、hello.jsも、下記の通りES2015ライクな書き方にし、それに合わせてtestも修正します。

export default (name) => 'Hello ' + name
import chai from 'chai'
import hello from '../dev_es2015/hello'
var should = chai.should()

describe('hello.js', () => {
    context('echo', () => {
        it('should return Hello yamamoto when the value is yamamoto', () => {
            hello('yamamoto').should.equal('Hello yamamoto')
        })
    })
})

それでは最後に、gulpを走らせてみましょう。

$ gulp watch

gulpを走らせているときに、dev_es2015の中身に変更があれば自動でテスト/browserify/babelifyを実施。さらに自動でGoogleにコードを送るようになりました。

f:id:bino98ty:20160428185256p:plain

このgulpfileでは、下記を走らせています。

  • watchタスクで、dev_es2015ディレクトリに変更があるかを常にチェック
    • 変更があったら下記のタスクを実行
  • testタスクでは、mochaによるテストを実行
  • browserifyタスクでは、browserify -> babelify(+ gasifyプラグインを適用)を実施
  • gas-uploadタスクでは、gapps uploadを実行

これにて、めでたく、GASをES2015で記述できるようになりました。

まとめ

いかがでしたでしょうか。 Google Apps ScriptはGoogle Driveの連携が非常に簡単に行えることに加え、GASをより便利にするようなライブラリもGoogleが幾つか提供してくれています。(例えば、OAuth2認証を行うこちらなど)

また、Slack連携も簡単に行えるので、普段からDriveを利用しているかたなど、ちょっとした効率化を行う際の何かの参考になれば良いと願っております。

それでは、良きGASライフを!

サーバの見積もり方法

こんにちは。エンジニアの玉置です。

f:id:tama1029hq:20160330174059p:plain

今回はサーバの見積もり方法について紹介します。

クラウドサービスはとても便利な機能を提供してくれるようになっています。 サーバのオートスケールなども勝手にやってくれるようになり、開発者がアプリケーションのパフォーマンスを意識することが減ってきています。

しかし、パフォーマンスを意識しなくなることにもリスクが有ります。 クラウドサービスに任せっきりにした結果、無駄にコストを支払ってしまってることに気付けないかもしれません。 自分たちのサービスがどれだけのサーバーを稼働させているのかを把握しておくことは、消費されるコストの把握にもつながります。

サーバの見積もりを出すのに必要な情報ってなんでしょう?

現在自分が関わっているサービスだと、月間2000万ユーザーに使っていただいています。 サービスの性質上、短時間に大量のユーザーがアクセスすることもあります。 こうした状況で、サーバの見積もりを出すのに必要な情報は秒間最大アクセス数だと思います。

今回は秒間最大アクセス数を500と仮定して話を進めたいと思います。

今回扱うサーバの構成

Web Server、Application Server、DataBase Serverの3つのサーバを扱います。

図1. 基本構成

f:id:tama1029hq:20160330174324p:plain

図2. サーバ構成

サーバの種類 台数 CPUコア数
Web Server 1 2
Application Server 1 2
DataBase Server 1 2

それでは現状の把握をしてみよう

アプリケーションのパフォーマンスを測るのにjmeterを使用します。 jmeterはHTTPリクエストを大量に送ることで、大勢のユーザーがアクセスしている状況を作ることができます。

今回は単純なリクエストで使用しますが、シナリオ書いて実行などもできます。他のやり方もありますが、その先の事も考えjmeterの使い方を紹介します。

イメージ図

f:id:tama1029hq:20160330174325p:plain

jmeterの設定

100スレッドで、10秒間に10回送る設定の場合を見ていきます。

1.スレッドグループの追加と設定

テスト計画-> 追加 -> Thread(Users) -> スレッドグループ

f:id:tama1029hq:20160330174327p:plain

f:id:tama1029hq:20160330174333p:plain

2.HTTPリクエストの追加と設定

スレッドグループ -> 追加 -> サンプラー -> HTTPリクエスト

f:id:tama1029hq:20160330174339p:plain

好きなurlに書き換えてください f:id:tama1029hq:20160330174345p:plain

3.統計レポートの追加

テスト計画 -> 追加 -> リスナー -> 統計レポート

f:id:tama1029hq:20160330174351p:plain

これで100人が一気にアクセスしてくるのがテストでき、結果の集計も統計レポートがやってくれます。

上記の方法で出力したものがこちらです。

f:id:tama1029hq:20160330174358p:plain

このサービスがさばくことのできる秒間最大アクセス数は約60程度ということが分かりました。

ここまでで分かったこと

Web Server、Application Server、DataBase Serverを通して、秒間最大60アクセスをさばけるパフォーマンス、ということが分かりました。500アクセスをさばくためには、今の8倍必要です。 しかし、より詳細な見積もりをするにはそれぞれのサーバのパフォーマンスを見ていく必要があります。

それぞれのサーバのパフォーマンスの見方

dstatコマンドについて

まず、パフォーマンスを測るのに便利なコマンドについて説明します。

dstatのインストール $ sudo yum install dstat

およそ全部見れるdstatコマンド $ dstat -Tclmdrn --tcp --udp

試しに出力したもの f:id:tama1029hq:20160330174359p:plain

左から

  • epoch : 時間
  • total-cpu-usage : CPUの使用率
  • load-average : ロードアベレージ
  • memory-usage : メモリ使用量
  • dsk/total : ディスクI/O
  • io/total : I/Oリクエスト数
  • net/total : ネットワーク
  • tcp-sockets : TCPコネクション
  • udp : UDPコネクション

をそれぞれ一望することができます。

次にdstatコマンドを使って、Web Server、Application Server、DataBase Serverを前述したjmeterを使用した場合で見ていきましょう。

下記の例だと、dstatの結果を上から順にWeb Server, Application Server, DataBase Serverと並べてます。

f:id:tama1029hq:20160330174402p:plain

それぞれのサーバのパフォーマンスを見て分かること

パフォーマンスを見るときに、リクエストが詰まる要因は、メモリの使用量や、CPU使用率等、いくつか考えられます。 今回のケースだと、下図の赤で囲ってあるCPU使用率に着目すると、Application ServerでCPUリソースが足りない可能性があります。 Web Serverの最大パフォーマンスを測る場合を考えると、Application Serverがボトルネックになってしまっているので最大パフォーマンスを出せてるとは言えません。

f:id:tama1029hq:20160330174409p:plain

ですので、Application ServerのCPUのスペックを上げて測り直します。

すると、今度はWeb Server側のCPU使用率があがっているのが分かります。

f:id:tama1029hq:20160330174414p:plain

このように、詰まっている部分が解消されるようにスペックを上げていき、この手順を繰り返すことで、サーバ全体の最大パフォーマンスを測ることができます。

ではこの状態の秒間最大アクセス数を見てみます。

f:id:tama1029hq:20160330174417p:plain

Appliction Server でリクエストが詰まっていない状態だと、Web Serverは秒間最大アクセス数が 96.6 さばけることが分かりました。

Appliction Server は元々リクエストが詰まっていましたので、秒間最大アクセス数は 60 です。このように、それぞれのサーバで必要な台数は変わってくることが分かりました。

サーバの種類 秒間最大アクセス数500耐えるための台数 秒間最大アクセス数
Web Server 5 96.6
Application Server 8 60

終わりに

今回はサーバの見積もり方法を見てきました。jmeterを使用してサーバに対して負荷をかけ、サーバの最大パフォーマンスの見方を知ることで必要な台数の把握をすることができました。 これによって、何台起動するかを事前に知っておくことができ事前に費用の計算なども行えます。

余談

2コアを扱いましたが、実際はコア数が異なるサーバで運用すると思います。 扱いやすくするために1コアでの秒間最大アクセス数に置き換えておくと良いと思います。

また、CPUが1コアとマルチコアの場合で1コアあたりの処理能力が変わります。 自社サービスでの1例をあげますと

  • 1コアの場合、秒間最大アクセス数は22~24前後
  • 2コアの場合、秒間最大アクセス数は60~61前後

となっておりました。

第3回 Splathon (#splathon) が開催されたじゃなイカ

2016年3月20日、三連休のど真ん中、小春日和に恵まれた日曜日の昼下がり、六本木にあるSpeee(弊社)の4Fラウンジにて「第3回 Splathon」が行われたぞ。

こんにちは、Splathon運営メンバーの かわくぼっくす です。

Splathon って???

いま一度 Splathon の定義を振り返っておこう。

「スプラソン」(Splathon)とは、スプラトゥーン(splatoon)とマラソン(marathon)を組み合わせた株式会社Speee発祥の造語で、複数の参加チームが、マラソンのように、数時間から数日間の与えられた時間を徹してSplatoonに没頭し、戦果を競い合うイカイベントのことをいいます。

第1, 2回が気になるという方は、過去の開催記事をご覧になっていただくとして、まずは参加企業の紹介だっ!!

Splathon(企業対抗スプラトゥーン大会)を開催しました

第二回Splathonを開催したぞ(42日ぶり2回目の #splathon )

参加企業の紹介

第2回の10社からさらに増え、14社総勢60名超のイカたちが集まったぞ。 (この日のために三連休をイカづくしにした人もいたとかいないとか、、、)

※エントリー順、敬称略

企業名 チーム名 参加回数
Speee いっけね〜六本木六本木 3回目 (3回連続)
ドワンゴ ワン 3回目 (3回連続)
Google Alpha52ぃちゃん 2回目 (2回連続)
しくみ製作所 エースが居ないからTDからガチ勢をリクルート 3回目 (3回連続)
NHNPlayArt はわぁ… 初参加
pixiv pixivのpは小文字 3回目 (3回連続)
リクルート 青くなったR 2回目 (2回連続)
BookLive! ブキチライブ! 2回目 (2回連続)
博報堂 Hなイカ部 3回目 (3回連続)
サイバーエージェント ジロリアン 初参加
シャープ シャープメーカーネオ関東 初参加
グラニ Gratoon 初参加
スクウェア・エニックス DQXイカ部 初参加
Red Hat ikaハット 初参加

レギュレーション

ルール、ステージ

まず片方のチーム(A)がルールを決め、もう一方のチーム(B)がルールを確認した上でステージを決める。

1戦目の勝敗がついたら役割を入れ替えて、Bがルールを決めたのち、Aがステージを決める。

勝敗による勝点はイカのとおり

勝敗 勝点
勝ち 3点
引き分け 1点
負け 0点

ギア

第2回からレギュレーションに大きな変更はなく、今回もギア固定制を導入した。 前回大会後のアンケートでギアによる武器の有利不利もあったようなので、検討を加え「逆境」.「インク回復アップ」.「スペシャル減少ダウン」としたぞ。

※ レギュレーションの変遷

回次 メインギア構成 サブギア
第1回 自由 自由
第2回 インク回復量UP, サブ効率UP, イカ速UP なるべく付いていないものをチョイス
第3回 インク回復量UP, スペシャル減少量DOWN, 逆境 なるべく付いていないものをチョイス

予選

今回は、予選と決勝トーナメントの2部構成とした。

予選は、第2回から引き続いてのスイスドロー形式による組み合わせ抽選を採用したぞ。

各社4試合して、勝点上位4チームが晴れて決勝トーナメントに進めるわけだ。

f:id:technica-speee:20160325115010j:plain f:id:technica-speee:20160325115029j:plain f:id:technica-speee:20160325115033j:plain

第2回の上位チームでもあるドワンゴ、pixiv、Google らの前評判が高かったが、初参加企業がダークホースとなり、第1回、第2回の優勝チームが予選で姿を消すという予想外の展開に!!!!  (そして、こっそりプレーオフにコマを進める前回3位弊社。)

f:id:technica-speee:20160325115035j:plain

NHN(勝ち点10)、Google(勝ち点9)の2社は予選勝ち抜けを決めていたが、次点の勝ち点7に4チームひしめく混戦っぷり。

そこでルールはナワバリ、ステージはおまかせの1本勝負のプレーオフで残り2枠を争うプレーオフをやったぞ。

プレーオフの結果トーナメントに進んだのはイカの4社だっ!!

  • はわぁ… (NHNPlayArt)
  • Alpha52ぃちゃん (Google)
  • ジロリアン (サイバーエージェント)
  • いっけね〜六本木六本木 (弊社)

決勝トーナメント

準決勝

ここはサラッと。。。

Alpha52ぃちゃん (Google) vs いっけね〜六本木六本木 (弊社) は、1勝1敗でプレーオフを制した Alpha52ぃちゃん

はわぁ… (NHNPlayArt) vs ジロリアン(サイバーエージェント) は、2連勝した はわぁ… が決勝にコマを進めたっ。

決勝

はわぁ… (NHNPlayArt) vs Alpha52ぃちゃん (Google)

いよいよ手に汗握る決勝戦。

予選では 「はわぁ…」 が 「Alpha52ぃちゃん」に対して、 2 - 0 の完勝。

Alpha52ぃちゃん リベンジなるか !?

ところが、1戦目を取ったのは 「はわぁ…」。 Alpha52ぃちゃん 後がなくなった。

いよいよ優勝が決まるかの2戦目。 舞台は「ネギトロ炭鉱」ルールは「ナワバリバトル」。 後から知ったのだが、この日 はわぁ… は徹底してルールに「ナワバリバトル」を選択し、かつ負けなしだったんだとか。。。

ナワバリバトルに自信ニキの はわぁ… は、終始安定した試合運びをし、Splatoon 好きならおなじみの「ファイナルクリスタルダスト」で試合を決めるというニクい演出もしてみせた!!!

初参加で終始安定した試合運びをして優勝した はわぁ… には、Splatoon のカラフルなインクを連想させる「ポケットモンスター 赤、緑、青、黄」が優勝賞品として手渡されたぞ

f:id:technica-speee:20160325115037j:plain

主力が欠けていたため最下位となってしまった 「エースが居ないからTDからガチ勢をリクルート(しくみ製作所)」 のイカたちには、「じゃがりこ 赤、緑、青、黄」がプレゼントされた。

戦い終わって

この時点で 18:30 をまわっており、集まったイカたちもこの後の懇親会を待ちわびている様子。

ってなわけで、メシの時間だーぁ!!!

懇親会の中で、 Google さんが音頭とって Splathon運営 に感謝のことばをくださったのが、涙もろい僕は目からインクが流れそうでした。。。。(次回も良い会にするぞー)

イカたちの集合写真で締めっ

f:id:technica-speee:20160325115022j:plain

今回改善点を図った点

さて、観戦記などはここまでで第2回から今回への改善点を挙げていきます。

  • レギュレーションの変更
  • 通称:@hasegawシステムを2面構成に
  • 懇親会の食事の増量
  • ラウンジのコーヒーの味改善
  • 女子力たかめのオヤツを用意
  • WiiUゲームパッドの混線

レギュレーションの変更

上でも書きましたが、武器ごとの有利不利を縮めるべく変更

通称:@hasegawシステムを2面構成に

第2回は、スクリーン1枚1試合のみの投影だったのですが、同型のスクリーンを買い増ししての2試合を同時に投影できるようにしました。

f:id:technica-speee:20160325115026j:plain

懇親会の食事の増量、ラウンジのコーヒーの味改善

食事量が物足りないとの声もあったので増量し、弊社自慢の無限コーヒーも豆と水のバランスをマスターし前回よりも美味しいものが提供できました。

女子力たかめのオヤツを用意

今回運営に女性スタッフが入ってくれたのですが、その娘がせっせか作ってくれました。

f:id:technica-speee:20160325115018j:plain

これには運営サイドの僕も驚いています。。。

f:id:technica-speee:20160325115016j:plain

WiiUゲームパッドの混線

実は、第3回に先立って 2016.2.6 にWiiU を 16台持ち寄っての混線状況の確認と対策を講じる「WiiUゲームパッド混線確認会」なるものをやっています。

@hasegawシステムも稼働させて本番さながらに、Wifi の電波状況を確認するスマホアプリを片手に試行錯誤を繰り返しました。

レンジフードを買ってきて、WiiUのホイル巻きを作ったりもしました。。。 f:id:technica-speee:20160325115007j:plain

結局は、ラウンジに併設されている会議室を使うことである程度の混線は防げるようになりました。

WiiU を持参して参加してくださった皆様、この場を借りてお礼申し上げます。

次回 Splathon の予定

とまぁこんな感じで、着実に改善を加えつつ裾野を広げている Splathon

先日、次回開催へ向けての振り返り会も済ませ、「第4回 Splathon」へ向けて始動しているぞ。

  • 第1回 Splathon 2015.11.29 (日)
  • 第2回 Splathon 2016.01.10 (日)
  • 第3回 Splathon 2016.03.20 (日)

これまでの開催日をみていると、どうやら2ヶ月おきに行われているようだが、、、、、、具体的な日程などが決まったら Splathon の Slack にて案内を流すので待っていて欲しい。

「Splathon に興味がある」、「Splathon に参加したい」というイカたちは @yuma_iwasaki まで連絡してはイカがかな??

追伸

どうやら、我々の Splathon が海外(North California)でも捕捉されたようだ。

いつの日か、海を超えてワールドワイドに Splathon をやってみたいものだ。

第二回Splathonを開催したぞ(42日ぶり2回目の #splathon )

あいさつ

“今回は2016/01/10に都内某所で開催されたSplathonに潜入調査をしてきたのでその報告をするぞ。”

というわけで、今回は2016/01/10にSpeee社の4階ラウンジを使って開催された、第二回Splathonについて記事をしたためていきたいと思います。
担当は最近やっとウデマエがA-になったまじんです。 f:id:amirtta:20160115114032p:plain

Splathonとは?

“『Splathon』とはどうやらIT系の企業が集まってみんなでスプラトゥーンをする大会の名前らしい。読み方は『スプラソン』というようだ。”

Splathonとはスプラトゥーン好きの有志が集まって、楽しくイカしあう会です。
今回の開催で二回目になります。

(参照)第一回Splathon
Splathon(企業対抗スプラトゥーン大会)を開催しました – technica

参加企業

“なんと驚いたことに、この『Splathon』という大会には名だたるIT企業が10社も集まり、全14チームで激しい戦いを繰り広げたとのことだ。 う~ん、イカの魅力はどこまでも人を惹きつけるものだとしみじみ感じたぞ。”

今回は弊社Loungeスペースにて開催。前回の倍以上の人数が集まりました。

Speee(弊社)を筆頭に、

※()内はチーム名、/区切りは2チームの会社。

全10社(50音順)。70名を超えるイカした大人が集結しました。
チーム名から各社のカラーがにじみ出ています。
そして、前回Speee社に負けたしくみさんから溢れ出る打倒Speeeオーラ。
ちなみに弊社で外部の人を招いて行ったイベントでは最大規模でした。

開催中の様子ダイジェスト

Pepperも大注目のプレイ中の様子。

f:id:amirtta:20160115111930j:plain

まず目につくのが、大スクリーンに映し出される4台のプレイ映像。

f:id:amirtta:20160115111943j:plain f:id:amirtta:20160115112015j:plain f:id:amirtta:20160115112024j:plain

これはikalogの作者である長谷川さんがわざわざ準備してくれた、通称長谷川システム(勝手に命名)
これにより会場の一体感が更に上がります。

また、当日は#splathonというタグでTweetをたくさんしてもらったので下記にまとめました。

見返すと当日の勢いが感じられます。
- 第二回Splathon@Speee(IT企業対抗スプラトゥーン大会) まとめ #splathon – Togetterまとめ

企業対抗戦

今回は参加チームが多かったので、前回のような総当り戦ではなく、スイスドローという形式で企業対抗戦を行いました。
対戦を重ねる毎に近しい実力の相手とマッチングしやすくなる対戦形式です。

f:id:amirtta:20160115112649j:plainf:id:amirtta:20160115112654j:plainf:id:amirtta:20160115112659j:plainf:id:amirtta:20160115112703j:plain

そんな大白熱の1回戦の最終セット、「しくみ製作所」vs「Google
もう勝ちが決まったという状況からの大逆転劇!
会場全体がヒートアップしました。

この後も最後の最後で逆転が起こる接戦が何試合も有りました。
これだからスプラトゥーンはやめられない。

そして個人的に注目の対戦は「Speee」vs「Google
1戦目は最後の最後でGoogleさんに捲られ惜しくも負け…
2戦目は弊社のガチ勢4人が息を合わせ、KO勝利。

f:id:amirtta:20160115112826j:plain

勝利にはしゃぐ弊社ガチ勢。 f:id:amirtta:20160115114922p:plain

結果1勝1敗となり、決着は次回へと持ち越しされました。

そしてそんな強者どもの中、優勝を収めたのは…
f:id:amirtta:20160115113016j:plain
ドワンゴさんのチーム「ドワ」
前回優勝のピクシブさんを倒し、4戦全勝という圧倒的な強さを見せつけました。
f:id:amirtta:20160115113029j:plain

弊社は一応同率3位でしたが、今回のスイスドロー形式では中間層が横並びになるので厳密な順位は付けられませんでした。
ちなみに因縁のしくみさんも同率3位でした。

対抗戦の後はエキシビジョンマッチを行いました。
大会中に当たらなかった因縁の対決「Speee」vs「しくみ製作所」や、社内覇者決定戦「ドワ」vs「ンゴ」のバトルが行われ、一盛り上がりしました。
ちなみに弊社vsしくみさんの因縁対決は、弊社二軍を当てしくみさんに惜敗。
「ガチ勢チームなら負けなかった」との捨て台詞を残す弊社。またしても決着は先延ばしになりました。

懇親会

対抗戦後はみんなで軽食と少しのお酒で懇親会。
f:id:amirtta:20160115113212j:plainf:id:amirtta:20160115113222j:plain
参加社であるしくみさんからは美味しいお酒も頂きました。
f:id:amirtta:20160115113235j:plain
しかしみんなまだイカがやりたりないようで…

即興フェス

弊社西岡による自作フェスツール(Splathon前日に作成)を導入しての即興フェス。 Twitterにお題を投げてもらってその場で選んでメンバーとルールを決めてプレイ。

Splathonは終わらない。

会が終了した後も#splathonの勢いは止まらない・・・!
惜しくも優勝をのがしたピクシブさんは会社に戻って反省会and特訓を開始。

そんな特訓をしている会社がある中、飯テロを行うしくみさんと弊社。

まだまだスプラトゥーンの熱は収まらなそうです。

今回の発生した問題点

改善したい項目は幾つもあるのですが、特に問題だったのはWiiUゲームパッドの混線でした。同時に16台も稼働するというのを初めて試したのですが、やはり混線が多発しました。これを解決しないことには今後支障が出るので何がしかの対応をしたいと思います。
できれば任天堂さんに公式ツールとして有線ゲームパッドを出してほしいところです。

あとは会場の雰囲気を動画に取って残しておきたいというのが今回改めて思いました。
プレイ動画自体は録画できるのですが、やはり会場の空気感が伝わらないといまいちあとから見ても盛り上がりに欠けるので次回は検討したいところです。

次開催に向けて

“今回、我々は極秘情報を入手することに成功した。 どうやらこのSplathonとやらは次回開催が既に予定されているらしい… う~ん、なんということだ。 どうやら3月20日が第一候補らしいが…続報を待ちたい。”

というわけで次回は3月に開催を目指しております。
今回で既に人数が大変なことになっているのでもしかしたら抽選などになってしまうかもしれませんが、「興味が有るよ~」「参加したいよ~」という方は是非ご一報下さい。
あまりにも多そうだったら、事前にネット予選をやるかもしれないです。
※連絡は@yuma_iwasakiまで

ダイレクトマーケティング

“我々は、更なる追加情報を入手した。 どうやらSplathonの主催企業であるSpeeeは現在スプラトゥーンのウデマエが高いエンジニアを募集しているようだ。 興味がある人は一度どんな会社か確かめてみてもいいだろう。”

というわけで、弊社ではイカ採用もやっております。たぶん。
スプラトゥーンのウデマエが高くrubyができるエンジニア随時募集中です。
詳細はこちらから→Speee採用サイト

忘年する前に振り返りたいエンジニア新卒採用のはなし

エンジニアインターン

8月から始めたSpeeeの学生向けインターン"BizTech"も11月を持って終了しました。
今年は開発組織改革の一環で新卒採用でも新たな取り組みを行いました。

今までよりもさらに熱量高く取り組んだインターンでしたので、ここで一度振り返ってみようとおもいます。

BizTechとは?

Speeeでは " Business ✕ Technology " というテーマでより実践的なエンジニアインターンを実施しています。
具体的には実際に業務の一貫を担うα版プロジェクトや実業務を切り出して学生自らの手で企画・設計・開発・リリースまでをやります。
当然ディレクターとのやりとりや要件定義などもインターン学生自らがおこなう必要があります。

メンターとなるのは実際に業務をリードしているエンジニアで、設計レビューやコードレビューだけでなく、社会人として、プロのエンジニアとしての視点で大量のフィードバックをしていきます。

社会人経験を一足早く積んでもらい、これからエンジニアを目指すためにいまの自分に足りないものを発見してもらうために、全員が本気で取り取り組むインターンです。

【新卒採用】技術職インターンシップ ”BizTech” のお知らせ | 人事ブログ | 株式会社Speee

f:id:technica-speee:20160224104319j:plain

今年のBizTechを振り返って

昨年までは複数グループでテーマに沿って2週間程度で開発してもらういわゆるよくあるインターンだったのですが、今年からは実業務型にし、3週間、3〜4名と少人数に限定した形式に変えました。その分メンターががっつり入り、昨年よりも技術面、エンジニアとしてあるべき姿という点で熱いフィードバックができたと思います。

学生からも「苦しいインターンだったけど、成長し学びになった」「Speeeのインターンには参加すべき!」などと嬉しい声をいただいてます。

いま大学生がSpeeeのbizTechインターンに参加すべき5つの理由 ~ Runner in the High
【インターン四社目】まさかの要件定義から?!Speeeで学んだこと・成長したところ【12Days】 - 名前はまだない。
僕の2015年の就活とか開発について振り返る - はやしくんさん雑記

まさにこういうことがやりたくて、やったインターン
学生と社会人の枠を取っ払い、プロのエンジニアとしてあるべき姿で対話し、厳しさを知り成長してもらいたかった。その想いが通じた学生が多く参加してくれ胸が熱くなりました。

インターンが終わって東京にきたときにランチなどで会ったりしても、あのときの熱量を忘れず自走し成長しようと足掻いてる姿を見ると、いい課題を発見できたインターンだったんだなぁ、と個人的にも嬉しくなります。

失敗はどんどんしてチャレンジし続けていく姿勢がとても重要。

f:id:yusaku-hatanaka:20160113005922j:image:w300

こんな新卒と一緒に仕事がしたい

技術力がすごいやつ!を採用したいのはどこの会社も一緒だと思います。
僕らとしてもその点は変わらずです。

でもそれは今の技術力というよりも近い未来で花咲く技術力。
そのために高いレベルのチャレンジや投資をどれだけやっているか?が重要だと思ってます。

今自分にできる事の範囲でやっていても大きな成長はありません。
いま自分にできないからこそ、何か一つでもいいから武器をつくり、それを誰よりも一番になれるように伸ばす。そんなことができるやつと一緒に仕事がしたいです。

技術を伸ばしたい学生さんへ

とはいうものの、「技術力の基準がわからない」「周りにあまりプログラミングしている人がいなくてレベル感がわからない」学生からこんな声を頂くこともあります。
そんな時僕がいっているのは、

・アウトプットをGitHubやQiitaとかオープンな場で公開してみよう!
・実際にITエンジニアとしてバイトをして、コードレビューとか受けれる環境に飛び込もう!

ということです。
重要なのは経験値のある人からフィードバックをもらうこと。
そのフィードバックを受け、いつまでにどんなチャレンジしていくのかしっかりと目標をたてていくこと。
これはインターンでも同様の事を学生の方に語っています。

"ローマは一日にして成らず"

どんなに凄い人でも、苦難の日々はある。
だからこそ苦難にチャレンジして乗り越えていこう。

もしそういう悩みをもつ学生さんはぜひSpeeeに僕を尋ねてきてください笑
facebookメッセージをくれてもよいです。
こんなSpeeeで長期バイトに興味ある学生さんもご連絡お待ちしております。