UZABASE Tech Blog

株式会社ユーザベースの技術チームブログです。 主に週次の持ち回りLTやセミナー・イベント情報について書きます。

お試し就職制度を導入した話と、導入するに至るまでの話

入社して約2ヶ月くらいしか経ってませんが、この技術ブログに初投稿です。皆さんご存知(?)あやぴーさんid:ayato0211です。 何を間違ったのか、社内では筋トレの人として名前が売れてしまいましたが、本業はClojureエンジニアです。所属しているのはSPEEDAの開発チームです。

さて、本業はClojureエンジニアです、と書きながら今日はタイトルにある通り、お試し就職制度を導入したよって話と、そこに至るまでのお話です。最近は有名なIT企業があちらこちらで行っているので、あまり珍しくはなくなったと思うのですが、弊社ユーザベースでもお試し就職制度を試験的に導入することになりました。いわばお試しのお試しですね。

お試し就職制度超概要

まずは端的にお試し就職の概要を簡単に書いておきます。

対象者

  • SPEEDAの開発エンジニアとして選考を受けている方
    • かつ、二次面接まで通過している方、で希望される方のみ
    • 残念ながらSREチームでは行なっておりません

もう少し条件を緩くしたい気持ちもありましたが、システムで扱っている情報が情報だけに選考をある程度進めた方のみを対象とさせてもらいました。

期間

  • 2,3日程度(これ以上の期間は応相談)

報酬

  • 要相談
  • 基本的に報酬は出ると考えてもらって大丈夫です

勤務形態

  • 8時間労働(短縮は応相談)
    • 実際の勤務時間は受け入れチームに依存します

勤務地

経験できること

  • SPEEDAの開発
  • アジャイル開発の現場
    • ペアプロ
  • 開発メンバーとのランチ(and/or ディナー?)
  • and more?

導入に至るまで

さて、本来であればこういった記事を書くのは、エンジニア職ではなくどちらかというと非エンジニア職(例えば広報や人事みたいな)なイメージがあると思います。ですが、これを書いているのがエンジニア職の僕である、というところにユーザベースの面白さというのがあると思うので、この記事の残りではこの制度を導入するに至るまでの経緯を書いていこうと思います。

きっかけ

話は少し遡るんですが、僕がユーザベースに入社するときに、最もネックに感じていたのは仕事の取り組み方のところでした。具体的には、僕が所属しているSPEEDAの開発チームでは、常にペアプロで開発を行なっています。僕にとってはこれが入社して、本当にうまくやっていけるのかと最も不安に感じたところだった、といっても過言ではありません。他にも本当にClojureのプロダクトがあるのか、都市伝説ではないのか、という不安などもありました(ちなみにClojureプロダクトはちゃんとありました!!)。といった感じで、一般的に同じエンジニア職だとしても、転職というのはそれなりにハードルや不安を感じるものだと思います(新しい会社に馴染めるのか、実はこわい会社じゃないのか、嘘ついてるんじゃないか、などなど)。

実際に入社して、数日ほど仕事をしていると徐々にこの開発チームの良さというか、素晴しさみたいなものを知ることができました。その中でもったいないなと思ったのは、この環境をあまり開発チームの面々が表立って 発信していない ということでした。また、こんなに素晴しいチームだともっと早く知ることができていたら、もう少し早く入社したいって思ったかもしれないのに、という気持ちもありました。

あ、ちなみに弊社CTO林のインタビュー記事で若干今のチームにも通じる話が書かれているので興味がある方は是非読んでみてください。

newspicks.com

実際に起こったこと

こういった想いがあり、自由を文化とする弊社であればお試し就職制度を作ることはできるだろうと考えました。そして、採用周りを担当してくれているカルチャーチームのメンバー(Kさん)とCTO林に、「どうですか、やってみませんか」と打診をしたのが導入開始に向けた動きのはじまりでした。このとき僕はまだ入社して3週間も経っていないくらいのときでした。

KさんもCTOの林も「いいですね、是非やりましょう」といった良い反応を示してくれたので幸先良いなと感じました。早速、Kさんに実現させたい場合どうしたら良いかと相談すると、簡単に総務と労務にコンタクトを取ってくれて、労務の方と話してみてくださいと道を作ってくれました。それから労務の方を捕まえて話をして、いくつかのアドバイスを貰うことができました。ここまでである程度の実現方法と課題は見えてきていて、とりあえずやるだけならやれそうというところまで形になりました。念の為、法務にも見てもらった方が良いだろうということで、法務の方に話をしてみると法務的な懸念点がいくつかゴロゴロでてきたので、ミーティングをして課題がクリアできることを確認してもらってokが出た、というのが先週、入社から1ヶ月半時点での話です。

伝えたかったこと

上の話を読んで「ふーん、それで?」という感想を持つ人はきっと多いだろうなと思います。ただ、僕はこの一連の話が実にユーザベースの文化を表わしていると感じています。具体的には以下のようなところです。

  • 入社して間もない人間の突飛な発言でも認めてくれる
  • 発言した人間が自分で動いていける(むしろ動かないといけない)
  • 様々な立場の人が行動をしている人間に手を貸してくれる
  • 現場レベルで相談して新しい制度/仕組みを作っていける

普段の仕事でも良いなあと感じることは多いですが、こういった経験は今までになかったのでとても新鮮でした。

最後に

今回は、お試し就職制度を導入したよって話と、そこに至るまでのお話を書きました。ということで、ユーザベースでは僕と一緒にClojureを書きたいエンジニアを募集しています。話だけでも聞いてみたいっていう方は僕に直接コンタクト取ってもらってもいいですし、下の募集から直接応募してくれても大丈夫です。

www.uzabase.com

【超新卒!イベントレポート】新卒入社した会社でモヤモヤしている君へ

f:id:hir023:20181012171750p:plain NewsPicksエンジニアの久保です。

10/4(木)に、第二新卒として転職を考えているエンジニアを応援するイベントとして、
「超新卒!〜活躍する第二新卒エンジニアの最前線〜」を開催しました!
転職を考えているエンジニアも企業側の参加者の方にも、かなり満足度が高かったので、こちらでも発信していこうと思います!

超新卒とは?

超新卒とは、"まだ新卒人材である""新卒という型にはまらず挑戦してほしい""新卒を超えた(第二新卒という)存在である" という想いを込めて、第二新卒として転職を考えている人のことを表現しています。
そのような超新卒なエンジニア向けに、第二新卒として転職を考えているエンジニアを後押ししたり、転職に悩むエンジニアの今後のキャリアを考える参考になる場になればと思い始めたイベントが、「超新卒!〜活躍する第二新卒エンジニアの最前線〜」になります。

なぜ開催するに至ったか?

新卒で入社後すぐに「思っていたのとは違う」「やりたいことができそうにない」とミスマッチを感じる人は少なくないと思います。
また、一方で少なくともまずは3年間は転職せずに働くべきという意見もあります。
しかし、ミスマッチ解消や早期のキャリアアップを目指して、新卒入社後すぐに第二新卒として転職し、活躍するエンジニアを取り上げることで、 「第二新卒」という選択肢を取ることを悩んでいるエンジニアへの後押しになればと思い、開催しました。

開催概要

下記の4社から1名ずつ登壇いただきました。

  • 株式会社エウレカ
  • 株式会社Gunosy
  • 株式会社scouty
  • 株式会社ニューズピックス

イベント詳細はこちらをご確認ください。 newspicks.connpass.com

f:id:hir023:20181011121638j:plain
エウレカ 恩田氏
新卒入社2年目で転職され、「エンジニアの市場価値」という観点や「その企業においてエンジニアがどのように優遇されるか」という観点から、転職先の企業選びをされた体験談を話していただきました。

f:id:hir023:20181011121632j:plain
Gunosy 岡田氏
老舗IT企業からGunosyに転職した経験を元に、「エンジニアにおける社内評価と市場価値の相違」「成長曲線を変えるための転職」という観点で 転職に対する考え方と、転職後、Gunosyでマネージャーになるまでに起こったスキル・価値観の変化について話していただきました。

f:id:hir023:20181011121646j:plain
Scouty 伊藤氏
scoutyでの新卒既卒や年齢を問わずに活躍できる組織体制から、学歴や職歴ではなくスキルを重視したエンジニア採用を実現するという同社のビジョン、第二新卒でも企業からスカウトされるために重要なことについて話していただきました。

f:id:hir023:20181015180302p:plain
ニューズピックス 久保(筆者)
大手SIerから、「技術を極めたい」「プロダクト作りに関わりたい」「もっと成長したい」という想いから転職した体験談をもとに、転職する上でどのようなアクションをしてきたのか、について話をしました。

f:id:hir023:20181015180801p:plain 各社の発表後には懇親会としてお酒とピザでパーティーが催され、参加者の方々と各企業担当者がカジュアルに会話をして、大いに盛り上がりました。

参加者特典

  • 特典として参加者の方全員に、各登壇企業へのカジュアル面談パスをお贈りしました。
    ニューズピックスの場合には、参加者の80%から面談の希望を頂戴しており、とてもよい出会いのかたちを作れたと思っています。

開催してみて

  • やはり新卒入社後すぐに転職をすることへの抵抗や一歩踏み出せないといった、同じような悩みを抱えている方が多いように思いました。
    今回のイベントに参加して、前向きに転職を考えたいという人もいた一方で、「現在の会社でまだまだできることがある。まずは頑張ってみるべきだと気付かされた。」といった方もおられ、転職するか否かはさておき、参加された方への気付きとなる会だったように思います。
  • 登壇企業側からも、次回以降もぜひ参加したいというお声もいただきました。
  • 総じて、参加者・企業側ともに満足度の高い会になりました。

今後について

  • ぜひとも第2回を開催したいなと思います。開催時期は12月を予定しております。
  • 新卒入社3年目以内、もしくは20代で少しでも悩んでいるエンジニアはぜひ次回参加してください!
    connpassのNewsPicksグループ にジョインいただければイベント開催時に通知が届きます。
  • また、登壇を希望される企業様はお気軽にご連絡ください。

GaugeのParameterを使いこなす

こんにちは! SPEEDA日本事業部でテストエンジニアをやっている工藤です。

Gaugeシリーズの第三回目です 第二回目の記事はこちらから

今回はGaugeの「Parameter」について書きます。 ParameterはGaugeでテストを書くにあたり、基礎的かつ重要な機能です。

Parameterとは

GaugeのStepはパラメータを受け取ることができます。 Parameterを使いこなすと、Stepの再利用性をさらに高めることができます。

GaugeのParameterの機能はかなり充実していて、主に下記のようなParameterがあります。

  • Simple Parameters
  • Dynamic Parameters
  • Table Parameters
  • Special Parameters

今回はSimple ParametersとDynamic Parametersについて書きます。

Simple Parameter

Simple Parameterはその名の通り一番シンプルで、Stepに渡したい値をダブルクォーテーションで囲みます。
* Go to "Top" page

例えば、下記のようなSpecファイルがあります。
login.spec

## 日本ユーザーとしてログイン
* ログインフォームに日本ユーザーのログイン名を入力
* ログインフォームに日本ユーザーのパスワードを入力

## 中国ユーザーとしてログイン
* ログインフォームに中国ユーザーのログイン名を入力
* ログインフォームに中国ユーザーのパスワードを入力

テストコードでは4つのStepに対応したメソッドを記述する必要があります。
login.kt

class login {
  @Step("ログインフォームに日本ユーザーのログイン名を入力")
  fun fillInJpnUserName() =
        `$`(".username").sendKeys("jpn_user")

  @Step("ログインフォームに日本ユーザーのパスワードを入力")
  fun fillInJpnUserPassword() =
        `$`(".password").sendKeys("passwprd_jpn")

  @Step("ログインフォームに中国ユーザーのログイン名を入力")
  fun fillInForeignUserName()  =
        `$`(".username").sendKeys("chn_user")

  @Step("ログインフォームに中国ユーザーのパスワードを入力")
  fun fillInForeignUserPassword() =
        `$`(".password").sendKeys("passwprd_chn")
}

※SPEEDA開発チームではSelenide × kotlinでテストコードを書いています。

そこで以下のようにパラメータを使えば同じStepを使いまわすことができます。
login.spec

## 日本ユーザーとしてログイン
* ログインフォームにユーザーのログイン名"jpn_user"を入力
* ログインフォームにユーザーのパスワード"passwprd_jpn"を入力

## 中国ユーザーとしてログイン
* ログインフォームにユーザーのログイン名"chn_user"を入力
* ログインフォームにユーザーのパスワード"passwprd_chn"を入力

そうするとテストコード側のStepの記述も減ります。
login.kt

class login {
  @Step("ログインフォームにユーザーのログイン名<userName>を入力")
  fillInUserName(userName: String) =
        `$`(".username").sendKeys(userName)

  @Step("ログインフォームにユーザーのパスワード<password>を入力")
  fillInUserPassword(password: String) =
        `$`(".password").sendKeys(password)
}

上記の例で示したようにParameterなしだとユーザー毎にStepを作成しなければいけません。 しかしParameterを利用することでステップの再利用性が上がり、結果としてテストコードの記述量も減らせます。

Dynamic Parameters

Simple Parametersと同じくらい多用するのが、Dynamic Parametersです。 Dynamic Parametersには主に下記二つの用途があります。

  1. Conceptに値を渡す
  2. Data Driven Executionをする際に、テーブルの値を参照する

Conceptに値を渡す

まずはこちらの用途から見ていきます。
Dynamic ParameterとConceptを使うと、Specファイルの可読性を上げることができます。 ConceptファイルでDynamic Parameterを利用してConceptを定義します。
<>内で指定したフィールド名を使うと、Concept下のStepでもその値を利用することができます。
login.cpt

# ユーザー<userName>とパスワード<password>でログインする
* ログインフォームにユーザーのログイン名<userName>を入力
* ログインフォームにユーザーのパスワード<password>を入力
* ログインボタンをクリック

Specファイルでは通常通りConceptを呼び出すのですが、その際に値を渡してあげます。
値の渡し方はSimple Parameterと変わらず、渡したい値をダブルクォーテーションで囲みます。
login.spec

## 日本ユーザーでログインする
* ユーザー"jpn_user"とパスワード"password"でログインする

## 海外ユーザーでログインする
* ユーザー"foreign_user"とパスワード"password"でログインする

SPEEDA開発でもDynamic ParametersとConceptを併用することで、よりSpecファイルのテストシナリオを仕様書のような記述になるようにしています。

Data Driven Execution

Data Driven Executionで、テーブルの値を参照する際にもDynamic Parameterを利用します。
Data Driven Executionを利用することで、同じようなStepを繰り返し記述する必要がなくなり、Specファイルの記述量をさらに減らすことができます。
例えば、下記のようなSpecファイルがあったとします。

# Simple Parameterのみを利用したログイン確認

## 日本ユーザーでログイン確認
* ユーザー"jpn_user"と"pass_jpn"でログインする

## 中国ユーザーでログイン確認
* ユーザー"chn_user"と"pass_chn"でログインする

## シンガポールユーザーでログイン確認
* ユーザー"sgp_user"と"pass_sgp"でログインする

Simple Parameterを利用してStepを再利用できていますが、全く同じようなテストシナリオが複数記述されていて冗長な感じがあります。 このようなケースではDynamic Parameterを使ってData Driven Executionにすることで、記述がスッキリします。

# Data driven executionを使ったログイン確認

     |id|userName |password|
     |--|---------|--------|
     |1 |jpn_user |pass_jpn|
     |2 |chn_user |pass_chn|
     |3 |sgp_user |pass_sgp|

## 各ユーザー毎にログイン確認
* ユーザー<userName><password>でログインする

上記の例だと、## 各ユーザー毎にログイン確認というテストシナリオが3回実施されます。
その際に、下記のテーブルで定義されているuserNamepasswordの値が行ごとに代入されて実行されます。
Data Driven Executionを使わない場合、テストシナリオの数が必要以上に多くなってしまい読む人にもストレスを与えてしまいます。
Data Driven Executionを利用した二つ目のSpecファイルの方が記述量が少なく、変数となるパラメータもテーブルにまとめられているので読みやすくなっています。

まとめ

  • ParameterでStepに値を渡すことができ、Stepの再利用性を高められる
  • ConceptとParameterを使えば、より可読性が高いテストシナリオを書くことが可能
  • Conceptに値を渡すときにDynamic Parameterを利用する
  • Dynamic Parameterを利用することで、Data Driven Executionをすることができる

Gauge正式バージョンがリリースされました!

Gaugeがβ版を終えて、正式バージョンの1.0がリリースされました!