Septeni Engineer's Blog

セプテーニエンジニアが綴る技術ブログ

新宿Geek Lounge#3 分析基盤 Meetupを開催しました

こんばんは、@kimutyamです。

弊社で開催した新宿Geek Lounge#3 分析基盤 Meetupのレポート記事です。

f:id:kimutyam:20170919202026j:plain

第1~2回とScalaネタのイベントでしたが、 今回は分析基盤をテーマにイベントを開催致しました。

20:00~20:05 オープニングトーク

弊社、河内の軽快なオープニングトークから乾杯スタート

f:id:kimutyam:20170919203105j:plain

20:05~20:25 EMBULKの歴史 過去・現在、これから

f:id:kimutyam:20170919202904j:plain

gitpitch.com

EMBULKの歴史 過去・現在、これから

はじめに、@hiroysatoさんの登壇です。
題名どおり今までのEmbulkの変遷についてお話をいただきました。
当初はEmbulkのプラグインが少なく出来ることが限定的だったそうですが、 今や200を超えるプラグインが開発されたようです。
@hiroysatoさん自身も必要に応じて、プラグインを開発されたそうです。

資料中のEmbulkプラグインのまとめEmbulk(エンバルク)組み込みプラグインの設定覚え書きは私も普段大変お世話になっているまとめです。

プラグインも資料もなければ作ってきたらしく、 大変素晴らしくEmbulk&Digdagに貢献してこられたのだと改めて感じました。

20:25~20:45 動画系メディア企業で行われているETLの実際

f:id:kimutyam:20170919205310j:plain

動画系メディア企業で行われているETLの実際

続きまして、@smdmtsさんの登壇です。

「分析基盤刷新PoC」「ETL実例紹介」「ETLでぶつかった壁」の3部構成にお話をしていただき、実践向けの内容になっていました。

冒頭のPoCではSSOT(Single source of truth)を目指して検証した結果、 分析基盤の構成にTreasure Dataが導入したそうです。
Firebase Analyticsの生ログをBigQueryで分析したところスキャン量増大問題とSQL難読問題が発生していたところをFirebase Analyticsの生ログを最終的にTreasure Dataにロードすることで解決した具体例があげられています。
その仮定で7つのEmbulkプラグインを開発したそうです。

@smdmtsさんはScalaでEmbulkプラグインを開発していて、 私個人として非常に参考にさせていただいています。

20:55~21:15 セプテーニで分析基盤(Treasure Data)を導入した話

f:id:kimutyam:20170919210116j:plain

セプテーニで分析基盤(Treasure Data)を導入した話

最後に私の登壇です。 私が日々開発しているPYXISでどのように分析基盤を構築したかを説明させていただきました。
導入背景とアーキテクチャ構成、Treasure Dataを利用して良かった点をお話しました。
アーキテクチャはよく使われているパターンかもしれませんが、 社内事情を踏まえた上で開発者とデータアナリスト(非エンジニア)との業務連携するために工夫したことを紹介しました。

※本件は後日別途ブログエントリーで補足させていただきます。このエントリーにもリンクを載せておきます。

21:20~22:00 懇親会&じゃんけん

f:id:kimutyam:20170919213308j:plain

懇親会の風景です。
@oreradioさんよりTreasure Dataグッツをいただき、じゃんけん大会をしている様子です。
ありがとうございました!!

感想

今回は私も登壇しましたが、とても楽しかったです。(小並感)
私はEmbulk/Digdag/Treasure Dataに関して歴が浅いのですが、
界隈の人たちがとにかく優しいおかげですぐに参入できました。

日々の業務でTreasure Data社からの手厚いテクニカルサポートを受けたり、
Twitterで困ったことをつぶやいたら丁寧に教えていただけたり、
普段仲良くさせていただいてる@smdmtsさんに直接聞いたり..w

ありがとうございました。
今後とも宜しくお願い致します。

Scala関西Summit2017に参加してきました!

セプテーニ・オリジナルからの参加者

f:id:takashima0411:20170909182509j:plain
弊社からの参加者
8月にジョインしたばかりの青山さんを含め、5名が弊社から参加しました!

全体の流れ

寿司

これはScala関西Summitに関係ありませんが、前日に梅田で食べたお寿司です。

f:id:takashima0411:20170908202735j:plain
寿司
f:id:takashima0411:20170908202341j:plain
とても美味しい寿司

会場

f:id:takashima0411:20170909101826j:plain
会場外観
会場の天満研修センターです。 遠くから見ても圧倒的存在感を放つ立派な会場です。

f:id:takashima0411:20170909100626j:plain
メインホール
弊社の名前が付いたメイン会場です。 少し恥ずかしいですね。

受付

f:id:takashima0411:20170909100835j:plain
受付
会場前から参加者で賑わっており、Scalaの関西での盛り上がりを感じさせます。

お昼ごはん

f:id:takashima0411:20170909131245j:plain
お好み焼き
弊社社員で天満のお好み焼き屋さんでお昼をいただきました。 この後河内さんによるこの世のものとは思えない味のたこ焼きテロがあったとかなかったとか。。。

懇親会

f:id:takashima0411:20170909202047j:plain
懇親会会場
さくらインターネット株式会社様のオフィスをお借りして懇親会が開催されました! グランフロントの高層階から見える夜景は素晴らしいうえ、料理のクオリティも素晴らしいものでした。

弊社社員のセッション

元インフラエンジニアが
Scalaを触ってつまづいたところ。

f:id:takashima0411:20170909110045j:plain
尾上さん

最近インフラエンジニアからアプリケーションエンジニアに転向した尾上さんです。 新卒社員と一緒に麻植さんからScala研修を受けた際に感じた難しさなどを語ってくれました。 インフラエンジニアとしてチームを支えてくれのと同様、これからはScalaでチームを支えてくれること間違い無しですね!

Scala の関数型プログラミングを支える技術

f:id:takashima0411:20170909115859j:plain
青山さん

8月に入社されたばかりの青山さんです。 青山さんの関数型プログラミング力には弊社も非常に期待しており、その知識の一端をここでは発表していただけました。

iOSエンジニアのためのScala入門

f:id:takashima0411:20170909160439j:plain
嶽さん

GANMA!でエンジニアをしている嶽さんです。 ScalaだけでなくSwiftも使いこなす嶽さんからはSwiftエンジニアが0からScalaを学ぶ際に押さえておきたいポイントを紹介していただきました。

Scala on JVM をプロファイリングするツールの紹介

f:id:takashima0411:20170909163143j:plain
河内さん

PYXISのテックリード河内さんです。 フィボナッチ数列を例にJVM上のパフォーマンスチューニングの方法を紹介していただきました。 直前にタイトル変更となるトラブルが有りましたが、さすがの内容で聴衆の評判も良かったようです!

PlayとIntelliJで学ぶデバッグ入門

f:id:takashima0411:20170909160937j:plain
PYXISの平社員です。 今回は身の回りのみなさんが意外にデバッガを使えていなかったので、デバッガの基本的な使い方と、IntellliJ上で動かした場合、sbt上で動かした場合などそれぞれのケースでデバッガをアタッチする方法を紹介しました。 発表時間45分では時間がギリギリで、サンプルもあえて手打ちしたら想定とは異なった動きをしてしまうなど練習不足が出てしまいました。

全体の感想

スタッフの皆さんに手際よくサポートしていただけたため、懇親会も含めつつがなく進行しました。 全体的に時間の余裕があり、ゆったりとお昼ごはん食べられたり移動の合間にも質問などが行なえたのはストレスフリーでした。 また、セッションの流れも良く出来ていて、AkkaStreamの話を聞きたければ重複無く順番に聞けるようによく練られていました。 後日動画公開があるとはいえ、気になるセッションを生で聞いて質問できるというのは大きいので非常に嬉しいですね。

私はScalaMatsuriには毎回参加していますが、Scala関西Summitの熱気も決してそれに負けないと感じました。

弊社からの参加者が全員登壇するというのは去年私が入社した時には考えられなかったことです。 人材が厚くなってきていることを感じますね。

人材募集中!

株式会社セプテーニ・オリジナルでは一緒に働いていただけるエンジニアを募集しています。 すでにScalaを使いこなしている方も、これからScalaに挑戦したい方もどしどしご応募ください!

第2回新宿Geek Loungeを開催しました!

2年目エンジニアの大北です。 今日は9/5に開催した弊社主催のエンジニア交流イベント、第2回新宿Geek Loungeのレポートをお送りします!

第2回目のゲストは、スターバックス社のJamie Allenさん。(※講演は通訳付きです)

Jamieさんは、スターバックス社のバックエンド開発を牽引するDirector of Engineeringであり、過去にはLightbendでSenior Directorを務めていたそうです。

Scalaエンジニア歴は9年!Effective Akkaの著者、Reactive Design Patternsの共著者でもあります。

20:00〜 Jamieさんの講演(前半)

f:id:sachipapi423:20170906013527j:plain

新宿Geek Loungeは乾杯からスタート。

ビールやワイン、ジュースなど思い思いのドリンクを取って席につきます。

f:id:sachipapi423:20170906015338j:plain

Jamieさんの講演が始まります。 スターバックス社やLightbend社での経験を話しつつ自己紹介をされるJamieさん。実はコーヒーは全く飲まないそうです(笑)

スターバックス社の開発テーマは、「ビジネス価値をもたらすこと」。今回のお話は技術力の追求とビジネス上の価値の関係性をメインにお話いただきました。

f:id:sachipapi423:20170906015853j:plain

Functional ProgramingかReactiveなのか?

Jamieさんの答えはどちらも良いところがあるので取り入れる、でした。

またAkkaを使うべきか、というテーマには、Akkaは必須ではなく、ビジネス上の価値が出せることにフォーカスすべしとの見解でした。

たとえば、1日15億件のエラー通知システムを開発した際もAkka Clusterは必要ないと判断したそうです。

20:30〜 休憩

f:id:sachipapi423:20170906013507j:plain

ここで待ちに待ったディナータイム★

見た目も素敵なお料理を美味しくいただきました!

20:45〜 Jamieさんの講演(後半)

f:id:sachipapi423:20170906013539j:plain

後半のテーマはデータについて。

スターバックスカードに70億ドルもの額がチャージされているスターバックス社は、Jamieさん曰く「銀行」

お金という点で必ず問われるデータの一貫性、また世界中に展開するサービスという点で必要となる可用性のトレードオフは、Kafka、Cassandraなどのシステムを使って実現しているそうです。

Jamieさんが今注目しているのは、Google Cloud Spannerで、データの一貫性を保ちつつスケールもできるのだとか。ただJamieさんご本人も「クレイジーなサービスだ!」(素晴らしいという意味で)とおっしゃっていました。

Google Cloud Spannerの概要はこちらが参考になると思います。 jp.techcrunch.com

Jamieさんのスライドはこちらから見れます。

www.slideshare.net

21:30〜 じゃんけん大会

f:id:sachipapi423:20170906104746j:plain

Jamieさんの講演後、サプライズでDeepLearning4j作者のAdamさんから抽選で本をいただきました。 じゃんけん大会を制した参加者の方に、Adamさんのサイン付き本が贈られました!(おめでとうございます!)

LT① 玉置さん

f:id:sachipapi423:20170906013544j:plain

FutureのExecution Contextを中心にお話していただきました。

詳細はブログでも読めるそうで、恐らくこちらの記事だと思います。

qtamaki.hatenablog.com

最後の締めは庄内弁のありがとう「もっけだの」でした!

LT② Adamさん

f:id:sachipapi423:20170906013627j:plain

そしてAdamさんのLT。

「Adamさん:日本語を勉強しています。けど英語話します」でした(笑)

テーマはDeep Learning For Enterprise、どのようなEnterprise(例えば企業なのか学校なのか)にはどのような形のDeep Learningが適切なのか、などのお話をしていただきました。

ゆっくり分かりやすく話してくださったため、通訳の方はいなかったものの「理解できた!」という声が多かったです。

スライドはこちらからご覧いただけます。

www.slideshare.net

22:00〜 お疲れ様でした!

f:id:sachipapi423:20170906015319j:plain

終始和気あいあいとした雰囲気の会場でした。参加者の方々の会話に花が咲き、イベント後も飲みに行ったとか行かないとか。

次の新宿Geek Loungeは9/19(火)

第3回のテーマはデータ分析基盤! Embulk, ETL, Treasure Dataなどについて、3人の登壇者の方にそれぞれお話いただきます。

shinjuku-geek-lounge.connpass.com

次回も美味しいご飯とお酒を用意して、セプテーニオリジナルのカフェスペースでお待ちしております!

Gruntをnpm-scriptsに置き換えたらバージョンアップが捗った

こんにちは、オリジナル新作マンガの配信サービス、GANMA!のチームに所属する@paralleltoです。
最近はSwift 3を使ってiOSのクラアントアプリを開発していることが多かったのですが、 ひさしぶりにブラウザ上で動作するフロントエンドの開発環境をいじる機会があったので書いてみます。
前提として、フロントエンドの開発環境ではGruntというタスクランナーを介して コンパイルユニットテストを行っています。
今回、Gruntをnpm-scriptsに置き換えるにあたって感じたことをまとめています。

Gruntとは

圧縮、コンパイルユニットテスト、lintなどの反復タスクを最小限のコストで自動化するもの。
https://gruntjs.com/

npm-scriptsとは

package.jsonのscriptsフィールドにシェルコマンドやnpm runコマンドを記述し、 コマンドラインからnpm run <script名>で呼び出すことができるもの。
一部の予約されたscript名はrunを省略してnpm <script名>で呼び出すことができる。
予約されたscript名の例:start、restart、stop、test
https://docs.npmjs.com/misc/scripts

なぜGruntをnpm-scriptsに置き換えるのか

フロントエンドの開発環境のレガシー化を防ぐため、TypeScriptを2.xにアップデートしたかった。
現状、TypeScriptのビルドにはgrunt-tsの5.5.1を利用しているが、TypeScriptのサポート状況は1.8となっている。
TypeScript 2.x系にアップデートするためには、grunt-tsの6.0.0-beta.16を利用する必要があるが安定版ではない。
いい機会なのでgruntをnpm-scriptsに置き換える研究をやってみた。

メリット

  • Gruntプラグイン作者への依存がなくなる
  • Gruntの抽象レイヤーがなくなるためデバッグしやすい
  • ツールとGruntプラグインの両方のドキュメントを行き来する必要がなくなる
  • スクランナーの知識を必要としない(npmの基礎だけ知っていれば読める)

デメリット

  • 置き換えのコストが発生する
  • 便利なGruntのメソッドが使えなくなる
  • 設定がjsonファイル(package.json)なのでコメントが書けない

Gruntをnpm-scriptsに置き換える

ここから具体例を交えてGruntをnpm-scriptsに置き換えていきます。
まずpackage.jsonを見て、依存してるGruntプラグインを確認します。

package.json

{
  "devDependencies": {
    "grunt": "1.0.1",
    "grunt-chmod": "1.1.1",
    "grunt-contrib-clean": "1.0.0",
    "grunt-contrib-compass": "1.1.1",
    "grunt-contrib-copy": "1.0.0",
    "grunt-contrib-jasmine": "1.1.0",
    "grunt-contrib-sass": "1.0.0",
    "grunt-contrib-symlink": "1.0.0",
    "grunt-contrib-watch": "1.0.0",
    "grunt-karma": "2.0.0",
    "grunt-text-replace": "0.4.0",
    "grunt-ts": "5.5.1"
  }
}

Gruntが実際にどのプラグインを使っているかはGruntfile.jsを見るとわかります。

Gruntfile.js

module.exports = function(grunt) {
  grunt.loadNpmTasks('grunt-chmod')
  grunt.loadNpmTasks('grunt-contrib-clean')
  grunt.loadNpmTasks('grunt-contrib-compass')
  grunt.loadNpmTasks('grunt-contrib-copy')
  grunt.loadNpmTasks('grunt-contrib-sass')
  grunt.loadNpmTasks('grunt-contrib-symlink')
  grunt.loadNpmTasks('grunt-contrib-watch')
  grunt.loadNpmTasks('grunt-text-replace')
  grunt.loadNpmTasks('grunt-ts')
}

あれれ~?おかしいぞ~?次の2つの依存は使われていないようです。削除してしまいます。

  • grunt-contrib-jasmine
  • grunt-karma

※余談ですがテストはkarmaをコマンドラインから直接呼び出して行っていました。
メンテナンスする人が変わるとこういった消し損ないも出てきてしまうので、 今回のように定期的に見直すことは、開発環境をクリアに保つ上で大切だと思います!

シェルコマンドの置き換え

次に置き換えられそうなプラグインはこれらです。

  • grunt-chmod
  • grunt-contrib-clean
  • grunt-contrib-copy
  • grunt-contrib-symlink

ファイルの権限変更、削除、コピー、シンボリックリンク、どれもシェルコマンドで行うことができます。

  • chmodコマンド
  • rmコマンド
  • cpコマンド
  • lnコマンド

ではなぜGruntプラグインで行っていたかですが、大きく分けて2つの理由があると思います。

例えば、globのパターンマッチング(*/.tsなど)を使った複数ファイルの繰り返し処理は、 シェルコマンドで書くよりも、JavaScriptで書いた方がメンテナンス性が高いと思います。

これらを必要としない小さなタスクであればシェルコマンドへ、 そうでなければ同等のNPM packagesに置き換える必要があります。
置き換え例:

  • “grunt-chmod" → "shelljs”
  • “grunt-contrib-clean” → “rimraf”
  • “grunt-contrib-copy” → “cpx”
  • “grunt-contrib-symlink" → "shelljs”

そして上記の依存を使ったJavaScriptファイルをそれぞれ用意し、

scripts/chmod.js

const shell = require('shelljs')
const files = require('./files.json')

// いろいろ処理
files.forEach(file => shell.chmod(444, file))
...

npm-scriptsからnodeを経由して呼び出せるようにします。

package.json

scripts: {
  "chmod": "node scripts/chmod.js"
}

コマンドラインから実行します。

npm run chmod

watchの置き換え

特定のファイルが変更されたとき、自動的に関連付けられたタスクを実行するのがwatchです。
複雑なことをやっていなければ、TypeScriptなどのコマンドに標準で付属するwatchで何ら問題ないと思います。

ソースファイルに変更があったら再コンパイルする

tsc --watch

今回はgrunt-contrib-watchプラグインを使って複数のGruntタスクを実行していたため、 grunt-contrib-watchをchokidar-cliに置き換えて、以下のようなnpm-scriptsを書きました。

package.json

scripts: {
  "process1": "何か処理",
  "process2": "何か処理",
  "watch": "chokidar 'src/**/*.ts' -c 'npm run process1 && npm run process2'"
}

これでsrc配下の.tsファイルに変更があったときに、process1とprocess2が逐次実行されます。

grunt-text-replaceの置き換え

ファイルの内容を書き換えるものでした。
私はnodeのfsを使って同等の機能をJavaScriptで実装しましたが、 おそらく需要薄な内容なので割愛させていただきます。

Sass、Compassの置き換え

SassとはCSSの拡張言語のことです。
CSSと完全互換に加え、変数、ミックスイン、継承などの機能が追加されています。 CompassはSassで構築されたフレームワークで、Webの再利用可能なパターンを利用したり、 スプライトを簡単に作成することができます。
詳しくは本家をご覧ください。
http://sass-lang.com/
http://compass-style.org/

grunt-contrib-sassは非常に便利なプラグインです。
コマンドラインに比べて、複数ファイルをソースファイルに指定でき、 また、出力先の親ディレクトリがない場合は自動的に作成してくれます。
なんとかsassコマンドから同等のことが行えないか挑戦してみましたが、長くなりそうなので断念しました。

断念したモノ
  1. 拡張子がscssのファイル名を取得
  2. 拡張子を除いたファイル名を取得
  3. sassでコンパイルし、dist配下の同ディレクトリ配下に出力(ディレクトリが存在しないエラーが出る)
find src -name '*.scss' | sed 's/.scss$//' | xargs -I {} -P 16 sass {}.scss:dist/{}.css -compass --style nested

ここではnode-sass(compass使っている場合はcompass-mixinsを忘れずに)に置き換えて対応しました。

scripts/sass.js

const sass = require('node-sass')

const compile = input => {
  sass.render({
    file: input,
    outputStyle: "nested",
    includePaths: ["node_modules/compass-mixins/lib/"]
  }, (err, result) => {
    // ファイル出力処理
  })
}

grunt-contrib-compassは、単にcompassコマンドに置き換えられます。
compassはconfig.rbに設定をまとめられるのでコマンドラインではシンプルになります。

package.json

scripts: {
  "css:sass": "node scripts/sass",
  "css:compass": "compass compass compile --force"
}

TypeScriptの置き換え

TypeScript 2.x系を使っている人は、何も考えずにtscコマンドに置き換えられます。
--はnpm-scriptsを実行する際にカスタムオプションを渡すものです。
https://docs.npmjs.com/cli/run-script

package.json

scripts: {
  "tsc": "tsc",
  "tsc:dev": "npm run tsc -- -p ./tsconfig.dev.json",
  "tsc:prod": "npm run tsc -- -p ./tsconfig.prod.json",
  "tsc:test": "npm run tsc -- -p ./tsconfig.test.json"
}

ただTypeScript 1.x系を使っている人は注意が必要です。
grunt-tsにはreferenceという本家にはない便利なオプションが存在します。
このオプションを使用しているかどうかで置き換えのコストが大きく変わります。

TypeScript 1.x系では外部ファイルを参照する際に、referenceタグを書く必要がありました。

///<reference path="外部ファイルA.ts">
///<reference path="外部ファイルB.ts">
///<reference path="外部ファイルC.ts">

これを各ソースファイルに一つ一つ書いていくのは大変なコストだと思います。
grunt-tsのreferenceオプションはこの手間を補うためのオプションになります。

referenceオプションに下記のようなファイルを渡すことで、 各ソースファイルにreferenceタグを書かずともコンパイル時に参照を解決してくれます。

reference.js

///<reference path="外部ファイルA.ts">
///<reference path="外部ファイルB.ts">
///<reference path="外部ファイルC.ts">

まとめ

いかがでしたでしょうか。
最終的に、package.jsonのdevDependenciesは以下のようになりました。
パッケージ間の依存がなくなり、パッケージの更新や取捨がやりやすくなりました。

package.json

{
  "devDependencies": {
    "chokidar-cli": "1.2.0",
    "compass-mixins": "0.12.10",
    "cpx": "1.5.0",
    "node-sass": "4.5.3",
    "rimraf": "2.6.1",
    "shelljs": "0.7.8",
    "typescript": "2.4.2"
  }
}

また、今まではGruntfile.jsという大きなJavaScriptに書かれていた処理が、 npm-scriptsの小さなシェルコマンド、またはJavaScriptに分割されたことにより、 Gruntの知識をもたないメンバーでも各タスクの目的と処理がわかりやすくなったかと思います。

package.json

{
  "scripts": {
    "chmod": "node scripts/chmod.js",
    "process1": "何か処理",
    "process2": "何か処理",
    "watch": "chokidar 'src/**/*.ts' -c 'npm run process1 && npm run process2'",
    "css:sass": "node scripts/sass",
    "css:compass": "compass compass compile --force",
    "tsc": "tsc",
    "tsc:dev": "npm run tsc -- -p ./tsconfig.dev.json",
    "tsc:prod": "npm run tsc -- -p ./tsconfig.prod.json",
    "tsc:test": "npm run tsc -- -p ./tsconfig.test.json"
  }
}

スクランナーは知識を持つ人が、ある程度固定化された環境で使うには強力ですが、 開発環境をモダンに保ちたい、開発環境をさわれるメンバーを増やしたい場合は、npm-scriptsも十分選択肢に入りますね!

参考ページ

2017年セプテーニ・オリジナルの新人研修について

こんにちは。 昨年の8月に入社した嶽(だけ) @masayadk1229 です。

今回は私も携わらせて頂いている2017年のセプテーニ・オリジナルの新人研修についてご紹介したいと思います。 新人研修を担当されている方、新卒/中途問わず弊社に入社を考えている方などは少しでもご参考にして頂ければ嬉しいです。

※弊社では、新人のことをBN(Brand New)と呼んでいるので、これ以降はBNと記載致します。

全体的な流れとしては、以下の形でご紹介させて頂きます。

2017年BN研修チーム発足の経緯

弊社では、今までの新人研修は集合研修→配属チームでの研修→実戦に投入という形を取っていました。 具体的に昨年の研修の例をあげると、以下のような研修を実施していました。

2016年のBN研修について

  • 集合研修
    • JavaScript研修(自学)
      • プログラミング自体を学ぶ研修
    • JavaScript研修(講師あり)
      • Web界隈の最新状況の雰囲気をキャッチアップするための研修
    • Java研修(自学)
      • 習熟度に応じて渡される書籍は違うが、基本的にはJavaを学ぶ研修
    • Scala研修(講師あり)
      • 麻植さん(@oe_uia)に依頼する外部研修(14日連続で実施)
  • 配属チームでの研修
    • 掲示板研修(自由形式)
    • 掲示板研修(DDD)
      • DDDに従い、掲示板を作成

2016年のBN研修の課題

ただ、上記を実施したことで、BN配属後の現場では以下のような事象が発生していました。

  • 研修がプログラミング経験者向きになっており、初学者は研修を終えても十分に知識が身に付いていない
  • 配属チームごとに教育方針が違い、研修が長期化 or 研修が終わっても戦力化に時間がかかることがあった
  • 研修ではScala/Play/DDDを学ぶことになっているが、その他の土台となる知識を学ぶ機会が少ない

上記がチーム配属後の状況から課題として浮き彫りになりました。

よって、今年はBN研修チームを結成して、その課題を解消すべく動くことになりました。

BN研修チームで最初に決めたこと

BN研修チームのメンバーについては、弊社内で2017年1月前半に公募し、主導するマネージャー含めて6名のチームで動くことになりました。

第1回のMTGでは上記のチーム発足の経緯を鑑みて、まずは2017年のBN研修は何が達成できれば良いかをチームで考え、ゴールや研修に取り組む姿勢について設定しました。

BN研修のゴール

BN研修のゴールは「早期戦力化」。

戦力化というのは研修が終わってPJに入れたらゴールではなく、エンジニアとして自走(自ら学び、自ら走る)してチームに貢献できる状態を指す。

そのためにチームに参加したタイミングでも各チームへの負担を減らしつつ、BNもScalaに限らず一定程度の必要知識を習っている状態を目指す。

BN研修に取り組む姿勢

また、BNメンバーにおいても研修への姿勢として、以下のように取り組んで欲しい旨をお伝えしました。

BNそれぞれにスキル差があり進み具合もバラバラになる事が想定されるが、研修が終わるまではBN全員で一つのチームであるという意識を持ってほしい。

メンターや講師はもちろんフォローするが、それぞれの課題や研修内容についてお互いに話し合い、協力して理解を深めてくことが重要。

コードを書く力は勿論だが、話を聞く力、話を伝える力、協調性など様々なことを研修を通じて学びとってほしい。

BN研修内容を決定するまでの経緯

ゴールが決まったので、ここからは実際にどんな研修内容にするかについて話し合いました。

BN研修内容を決定するまでの流れ

大まかには、以下の流れで研修内容を決定しました。

どのようなスキルが必要かを考える
↓
どんな研修を実施すればそのスキルが身につくかを考える
↓
研修イメージの中身について深掘りをする
↓
外部に研修を依頼するか社内のエンジニアが講師を担当するかを検討
↓
BN研修チームとしてのたたき台を作成
↓
予算面/スケジュール面で経営陣に合意を取る
↓
研修内容の決定

弊社で必要となるスキルのブレスト結果

参考までにBN研修チームで、弊社で必要となるスキルは以下の通りに定義付けました。

BN研修の内容について

今回、BN研修チームとしては実際に実施した(実施している)研修内容をご紹介致します。

この研修内容は、課題にあったプログラミング初学者も考慮に入れて、作成しています。

BN研修のカリキュラム

※ タイトルの後の括弧内は研修期間。

  • ソフトスキル研修(半日)
  • Macを使おう(数時間)
    • Mac初心者が多いため、ターミナルを使った基本的な操作などを教育する。
  • Web基礎研修(2日)
    • インターネットやシステムなど、Webに関わる基礎部分を書籍を参考に講義し、理解を促進する事で自分たちがこれから取り組む業務の基礎理解を促進する。
  • Scala研修準備(10日)
    • Scala研修の前段階として、最低限学んでおいたほうがいいと言われた書籍を参考にフォローを行う。
    • プログラミング(とできればJava)の基本用語・概念(クラス、インスタンス、メソッド、オブジェクト、戻り値、引数…) についてある程度理解している、ぐらいの理解度を目指す。
    • 参考書籍: Java言語プログラミングレッスン 第3版(上)(下)」
  • Scala研修(半日×14日)
    • コップ本をベースにScalaについて学ぶ
    • 麻植さん( @oe_uia)に依頼する外部研修(週2回で合計14回実施)
    • 参考書籍: Scalaスケーラブルプログラミング第3版」
  • サーバ構築講習(1日)
    • 自分たちが書いたアプリケーションを実行するサーバを最低限構築する技術を教育する。
  • データベース基礎(2日)
    • アプリケーションに必要不可欠なデータベースについての基礎を書籍を参考に教育する。
    • 参考書籍: 「SQL 第2版 ゼロからはじめるデータベース操作」、「Webエンジニアのための データベース技術[実践]入門」
  • 設計(アルゴリズム)基礎(半日)
    • プログラミングをする際に知識としてあったほうがよい一般的なアルゴリズムについての講義をする。
    • 参考書籍: 「アルゴリズムの絵本-プログラミングが好きになる9つの扉」
  • TDD研修(半日)
    • 弊社全体で行なっている研修を用いて、テスト駆動開発について講義をする。
  • スクラム基礎研修(半日)
    • チーム開発で弊社が採用しているスクラムについての概要を講義する。
  • チーム開発準備(半日)
    • チームで開発をする上で必要な情報をインプットする。
    • 具体的には、弊社が採用しているGit、 Atlassian製品の使い方(JIRA、Bitbucket、Confluence)の説明、活用方法を講義する。
  • DDD研修(1日)
    • 弊社が採用しているDDDについて、講義を行う。
  • チーム開発(実施日数未定/期限あり)
    • BNで研修の仕上げとしてチームを組んでECサイトの開発を行う。

上記をBN研修チーム外の方にも研修の担当講師としてご協力いただき、大方実施を終えました。

残りの研修は現在実施中のチーム開発とDDD研修が残っております。

今回に関しては外部研修は麻植さん(@oe_uia)のScala研修のみでした。

チーム開発研修

今年の目玉は他社でもよく実施するであろうチーム開発研修で、 チームで協力して何かを作り上げるということを経験してもらう内容になっています。

具体的には擬似的な顧客(プロダクトオーナー)を立てて、要件が曖昧な中で基本は丸投げしてECサイトの完成を目指してもらうものになっております。

こちら、以下の目的で研修を設定しました。

  • チーム開発を経験してもらう
  • 要件の掘り下げのフェーズから経験してもらう
  • 失敗を経験してもらう

こちら以外の研修は基本的に座学や自習が多く、こちらから与えるような研修ですが、チーム開発研修のみ自分たちでどのように動いて成功させるかの自発性も問われるものになっています。

あえて、ここまで扱わなかったWebアプリを作成するという課題を設定し、プロダクトオーナーとのやりとりも自分たちで進めるものとなっています。

また、どのように進めるかをこちらから提示せず、丸投げでスタートさせたのは一旦失敗を経験してもらいたかったという意図もあります。

ここでいう失敗とは、極端な例で言えばバージョン管理システムを使わなければ競合が起こる、チームで話したことをドキュメントに残さないと仕様認識の齟齬が起きるなどを身を持って経験して欲しいかったからです。

このような失敗の経験をすることで開発プロセスやツール、開発手法などに関しても"なぜ採用しているのか"ということを考える機会を提供できると考えたからです。

BN研修を実施してみて

今回、弊社内で初の試みということで、様々なことがありましたが、問題が発生した中で抜粋していくつか紹介したいと思います。

研修運営の課題

研修を担当してくださった講師の方は資料作成など負担が大きいものになりました。 負担が大きくなった理由はいくつかありますが、個人的には以下のいずれかに該当するかなと思っています。(あくまでも個人の見解です)

  • 資料作成の時間を確保できていない
  • 資料にお手製の図などを入れたりして、見た目の作り込みだけでも時間がかかった
  • 参考書籍をうまく活用できなかった

研修運営の課題に関しての次回以降のアクション

今回はこのような課題が出ましたが、個人の見解としては上記の課題に関しては以下のアクションを起こせると思います。

  • 会社として業務時間の何割かは使って良いと許可を頂いてはいるので、開始時期さえ早めれば十分に時間は確保出来るので、着手を早める
  • 講師はBNメンバーに配布する課題書籍を頂けるのですが、その書籍を電子書籍などにして頂ければ、画面キャプチャーなどを使い、図の作成を短縮できる
  • 参考書籍に関しての検討は一度手元に届いてから内容を確認して、講師側と認識をすり合わせるようにする

上記の見解は個人のものですが、今回は研修講師の方々にそれぞれ振り返りページを作って頂きました。 振り返りページを元に、来年以降の研修は改善していきたいと思います。

カリキュラムの課題

今年のBNは3人全員プログラミング経験者でした。

その情報を踏まえたうえでプログラミング初学者も考慮した今回の研修の実施を行なったわけですが、以下のような事象が発生しました。

  • Scala研修準備を10日間前後で設定したが、当初の想定より時間が余った
  • Scala経験者がScala研修の前半に時間を少し持て余してしまった
  • インフラ系のカリキュラムの順序が悪く、知識を繋げて伝えられなくて効率が悪かった

カリキュラムの課題に関しての次回以降のアクション

今回は、こんなに早く全員がカリキュラムを終えることを想定していなかったため、以下のカリキュラムを追加しました。

  • アルゴリズム系の問題の演習を行なってもらった
    • 参考書籍: 「世界で闘うプログラミング力を鍛える150問 」
  • Vimの操作やLinuxについて知識について学んでもらった
    • 参考書籍: LPIC Level1の教科書」
  • SQLの基礎について学んでもらった
    • 参考書籍: 「ゼロからはじめるデータベース操作」

次回以降は、自習系のカリキュラムの場合は早く終わった人には何をやってもらうかをBN研修チーム内であらかじめ決めておくべきだと思いました。

終わりに

弊社では手探りではございますが、BN研修をこのような形で刷新を行いました。

個人的にはほぼゼロベースから、手探りながらもチームで研修を作っていけたのはとてもやりがいがありました。

今年のBNが現場に入ってから少しでも活躍できるように尽力はしましたが、私自身も資料作成が遅れるなど至らなかったところがたくさんありました。

自分自身が前職で新人研修を手厚くして頂き、周りの方から教育して頂いたことで今の自分があると思っているので、恩送りという意味でも来年以降もBN研修には協力していきたいと思っています。

また、弊社では中途入社の方へも平均して1〜2ヶ月程度の研修が用意されています。

詳細は…別の機会に紹介させて頂くとして、こちらも刷新に向けて動き始めているようです。

ご興味を持って頂いた方は入社して頂き、一緒に研修を作り、会社の未来も作りましょう!

XcodeでInterfaceBuilderの型を消し去ってみると色々得られて少し失った

こんにちは。

GANMA! チームで開発をしている、寺坂です。

GANMA!のiOSアプリでは、
XcodeInterfaceBuilder を活用してUI開発をしています。

今回は、InterfaceBuilderをより活用できようになる、かもしれない内容を書いていきます。

モチベーション

UITableViewのdalegateやdataSourceのように
自分で作ったViewのdelegateもInterfaceBulder(以下、IB)上で Outlet接続したい。

続きを読む