本当に良いエンジニアはいないのか?企業が採用に苦戦する本質とは

こんにちは。grooves にて Forkwell の事業責任者を務めている、赤川と申します。

この数ヶ月、 grooves では全事業部で積極的にエンジニアの採用活動を行ってきました。
当初は応募獲得に苦戦するだろうと思っていたのですが、結果は真逆で、あまりにも魅力的な方ばかりから応募いただけるので、採用に迷うことのほうが多いという結果になりました。

結果的に当初の予定より人員計画を増やすことになったのですが、それでもこの人と働きたいと思った方全員を採用できる状況ではなく、私たちとしてもぜひ一緒に働きたいと思っている方で、grooves を第一志望です、と言ってくれる方に対して採用枠の充足を理由にお断りしなければならないのは、非常に辛いことでした。

世の中には素晴らしいエンジニアがたくさんいるということを、改めて認識しています。

一方で、grooves が運営する Forkwell の元には、良いエンジニアが採用できないので支援してほしいという連絡が毎日届いています。
どの会社も、採用にはかなり苦戦していらっしゃるようです。

この差はなんなのでしょうか。

市場にはこんなに良いエンジニアがいるのに、どうして採用できない企業がこんなにいるのでしょうか。

私の意見は、魅力的なエンジニアに選ばれる企業が圧倒的に少ない、です。

選ばれないのは、差別化できるほどの魅力が足りないから

求人票を作る際に、STPを採用することは有効な手段の一つです。

STPとは、
適切な切り口で市場やユーザーを細かく分類して(セグメンテーション)、
分類した市場の中で狙う層を絞って(ターゲティング)、
その層に刺さる魅力で差別化する(ポジショニング)、
というマーケティングの基本的な考え方です。

STPを使うことで、自分たちの個性に合った方に自社を選んでもらいやすくできるのですが、そもそもポジショニングできるだけの魅力がないことが、多くの企業の課題になっているように思います。

この魅力づくりがないまま、採用ステップに進むから苦戦するのです。

魅力が足りない企業ほど、魅せ方にこだわりがち

魅力がある企業であれば、それを100%伝えることができれば、解決です。

Forkwell はエンジニアが選ぶべきかどうか正しく判断できるよう、なるべく詳しく求人に掲載していただくよう取り組んでいます。
しかし、10の魅力を10で表現することはできても、2の魅力を10に見せることはできません。

多くの採用広告では、このレートが100%からずれてしまうので、不幸が起きていると考えます。
このレートは、100%がいいのです。
50%であれば、まだ自分たちの会社が採用できないだけで済むのですが、150%にしてしまうと、入社した方が確実に不幸になります。これだけは絶対に避けなければなりません。

grooves はどうしているか?

結局、自社の魅力を底上げすることが一番です。

当たり前の給与

正直、大手企業やメガベンチャーと比較すると、届いていません。
それでも、事業の成長に伴って社員の給与は毎年平均10%で上がってきており、2018年は念願の賞与を導入することもできました(とはいえ、まだ年1ヶ月分を給与に上乗せできるレベルですが)。
ユーザーに価値を提供できれば会社が儲かる。会社が儲かった分はちゃんと社員に還元される。だからもっとユーザーに価値を届けようと頑張れる。そういうサイクルを目指して少しずつ積み上げてきました。もちろん、大手企業と並ぶには、高い生産性を実現しながら、よりユーザーに価値を届ける必要があることも理解しています。

最も大事なビジョン

私たちが何を目指したいのか、ぶれないビジョンを掲げています。
わざわざ大企業を断ってまで grooves に挑戦したいと思えるほど価値あるものを掲げなければいけません(少なくとも私はそう信じています)。
また、お飾りのビジョンには何の意味もありませんから、自ら実践する必要があります。groovesでは、 ワークシフトインフラを創るというビジョンに便乗して(ダジャレじゃないです)、様々な試みをしてきました。年初に話題にしていただいた記事もその1つです。

tech.grooves.com

他にも、フレックスやリモートワークは当たり前として、最近ではタイでのワーケーションにチャレンジする社員まで現れました。

www.wantedly.com

サービスがビジョンに沿っていることは大前提として、私たち自身でビジョンを体現することも、ビジョンの形骸化を防ぐために必要だと思っています。

チームの理想に近づける努力

ビジョンの中で働き方への取り組みを書きましたが、それだけではなく、チームとして理想の開発文化を作りあげていくということも大事です。

エンジニア自身が、「こんな組織にしたい」を言語化し、それに向けてどんな取り組みをしているのか発信していく。それに共感した人が集まり、理想とする開発環境ができていく。
その結果として、見積もりはみんなでする、テストを書く、PRをマージするにはプロジェクトで決められた人数以上のレビューが必要、ドキュメントを残す、gem などのライブラリは常に最新版を使うといったチームにとって当たり前の文化ができてきました。

Rails 5 リリース日に Forkwell を Rails 5にアップグレードしたのも、話題作りの意図もありますが、社内をエンジニアにとって刺激的な環境にすることで、働くこと自体も楽しんでもらいたいと思ったからです。

魅力が整ったら採用へ

こういった取り組みをした上で、エンジニアであれば Forkwell や開発ブログを通じて、ビジネスサイドであれば Wantedly などを通じて、伝達率100%を意識して発信しています。

grooves では、今年の2月から3月までに Forkwell Scout を使って20通のスカウトを送り、9名の素晴らしいエンジニアと面談することができました。スパムのようにスカウトを送らなくとも、良い出会いを作ることはできるのです。

現実的にはビジネスである以上、何かをする前に全てが揃うということはないので、今ある手持ちの魅力だけで戦うことにはなるのですが、魅力づくりに手を付けなければジリ貧が続くことを意識して改善を続けています。

まとめ

記事タイトルの「本当に良いエンジニアはいないのか?」という問に対しては、明確に「いる」とこたえます。
良いエンジニアに選ばれる企業が少ない、というのが私の見解です。

それを踏まえて、

  • 自社の魅力をあげよう
  • 伝達率を100%にしよう

という主張を行い、そのために grooves が行っているアプローチを書きました。

本記事が皆さんのよりよいエンジニア採用のきっかけになれば幸いです。

採用に苦戦しているポジションも

実はいま、最も採用に苦労しているのがデザインも好きなフロントエンドエンジニアです。
もし grooves に興味をお持ちいただけるようでしたら、ぜひ以下のリンク先からエントリーしてください。

jobs.forkwell.com

Forkwell のインフラをコード化するためにやったこと

ここ最近は既存のインフラを片っ端からコード化していた @sinsoku です。

やっとコード化が一段落したので、インフラ周りでやってきたことを技術ブログにまとめました。

作業をする前の状況

Forkwell のインフラ環境は2016年夏頃に「第1回 インフラがコード化されていないのはヤバい!」議論が起き、タスクの優先度が上がりました。 このときは @ta1kt0me が頑張ってくれて、既存 EC2 インスタンスを Ansible で作れるようにしてくれました。

しかし、弊社では AWS の ALB、EC2、RDS、ElastiCache、...など、いくつものサービスを使っています。 この AWS リソースはコード化されておらず、手作業で作っていました。

2017年12月末

サーバを Ruby 2.5.0 に上げる話が挙がり、そのとき「第2回 インフラが(以下略」の議論が起きました。

  • 不要そうな AWS リソースがあるけど、消すのが怖い
    • どこかで使われているかも...
  • 既存の設定にした意図が残っていない
    • デフォルト値と異なる箇所が分からない
  • コード化されていないのでレビューできない

といった課題は前々からありましたし、2017年も終わろうとしているのにまだ Immutable Infrastructure になっていないのも微妙です。

f:id:sinsoku:20180119104029p:plain

そこで、この機に AWS リソースもコード化する方針を立てて、対応することにしました。

Terraform の導入

AWS リソースをコード管理できるツールは AWS CloudFormationTerraform、Ansibleといくつか選択肢があります。

ただ、将来的には GitHub Organization などもコードで管理したいこともあって、Terraform を選択しました。*1

staging 環境のリソースをインポートする

いきなり production 環境のリソースを管理するのは怖いので、まずは staging 環境のリソースを管理することにしました。

  • terraforming
  • terraform import の機能
  • terraform state の機能

を駆使し、terraform.tfstate を作っていきます。

EC2 インスタンスをインポートする例

まずは既存のインスタンスを全部 ec2_instances.tf に出力します。

$ terraforming ec2 > ec2_instances.tf

次に、今回は管理対象外である production 環境の設定を頑張って削除します。

$ vim ec2_instances.tf

インポートをする前なので、 Terraform にはインスタンスの追加として認識されています。

$ terraform plan
.
.
.
Plan: xx to add, 0 to change, 0 to destroy.

1つずつ心をこめて import していきます。

$ terraform import aws_instance.web i-12345678

対応が終わったら、祈りながら plan を実行します。

$ terraform plan
No changes. Infrastructure is up-to-date.

上手くインポートできれば差分が出ない状態になります。

Terraform のディレクトリ構成

インフラの設定を1つのディレクトリで管理すると plan の実行に時間がかかったり、 *.tfstate が壊れた時のリスクが大きいため、ディレクトリを複数に分けました。

./infra
  app/                    # Forkwell のVPC, EC2, ElastiCache, ...
    .terraform/
    backend.tf
    main.tf
    vpc.tf
    ...
  auto_bundle_update/     # CodeBuild を使った自動bundle update設定
  users/                  # IAM 関係
  s3_buckets/             # S3 バケット設定
  metric_alarms/          # CloudWatch のアラーム関係

このディレクトリ構成が良いのかは自信ないですが、コード化さえできれば後からリファクタリングできるので、とりあえずこれで進めました。

ちなみに、他ディレクトリの値は terraform_remote_state を使って参照する作戦です。

セキュリティグループのテスト

セキュリティグループの設定はミスるとサービスが動かなくなったり、特定の機能がエラーになって非常に危険です。 このため、不要そうな設定であっても消しづらく、残ってしまいがちです。

そこで、既存のセキュリティグループに対するテストコードを書きました。

RSpec.describe 'staging' do
  let(:bastion_ip) { '123.456.789.1' }
  let(:bastion_user) { 'ec2-user' }
  let(:bastion) { Net::SSH::Proxy::Command.new("ssh #{bastion_user}@#{bastion_ip} -W %h:%p") }

  def mysql_config
    {
      host: '127.0.0.1',
      username: 'root',
      password: ENV['STAGING_DATABASE_PASSWORD'],
      database: 'forkwell_staging'
    }
  end

  describe 'in app server' do
    let(:server_ip) { '123.456.789.2' }
    let(:server_user) { 'forkwell' }
    let(:server) { Net::SSH::Gateway.new(server_ip, server_user, proxy: bastion) }

    it 'connects to MySQL server' do
      server.open(ENV['STAGING_DATABASE_HOST'], 3306) do |port|
        client = Mysql2::Client.new(mysql_config.merge(port: port))
        results = client.query("SELECT VERSION();")
        expect(results).to include("VERSION()" => "5.6.34-log")
      end
    end

    it 'connects to Redis server' do
      server.open(ENV['STAGING_REDIS_HOST'], 6379) do |port|
        redis = Redis.new(url: "redis://127.0.0.1:#{port}")
        expect(redis.info['redis_version']).to eq '2.8.6'
      end
    end
  end
end

このテストにより、全ての EC2 インスタンスで疎通確認するのが簡単になり、セキュリティグループを編集しやすくなります。

今後やっていくこと

今回は(staging環境の)既存リソースをコード化することを重視していたため、Terraform の変数や属性は使いませんでした。 やっとインポート作業が一段落したので、これからは少しずつリファクタリングしていきたいと思っています。

そして、メンバー全員が Terraform に慣れてきたら production 環境のコード化も進めていきたいですね。

(半分くらい) Immutable Infrastructure な環境で働きたい人

インフラ環境も改善されつつある弊社では一緒に働きたい方を募集しています!
興味ある方は下記URLからエントリーお願いします!

jobs.forkwell.com

*1:あと HashiCorp 社が好きだったり、Terraform の名前がカッコいい、といった個人的な好みも選定に影響しています

なぜ grooves はフレックスでの深夜勤務を認めることができなかったか?

昨日 2月末に株式会社groovesを退職します を発表したエンジニアのマネージャーを務めている(2018年1月時点)赤川です。

本記事の前半では、なぜ彼が望む「フレックスでの深夜勤務」を用意できなかったかを紹介し、後半では彼と共にプロダクト開発に携わってきた立場から、彼の推薦文を書きます。

なぜこの記事を書くのか?

  • フレックス制度の導入を検討している会社の参考にしてほしい
  • エンジニアの成長・キャリアアップを応援する Forkwell を運営している会社が、自社のエンジニアのキャリアアップや転職を応援しないのは嘘になるので、感謝をこめて送り出したい

今回の経緯

まず、今回の件について、彼とどのように会話を進めてきたかを紹介します。

  • 2017年8月 1on1 MTG で、自身の生産性をあげるためにフレックスを導入したいと伝えられる。フレックスについて調査開始。
  • 10月 エンジニアチームに、深夜時間以外でのフレックスを試験的に導入する(コアタイムは14:00-18:00に設定、月初・週初は対象外)
  • 11月 フレックスを試験導入から本導入へ移行(同上)
  • 12月 彼に退職したいと伝えられる。その際、フリーランスは可能かと正式に相談される
  • 同月 フリーランスの条件を提示する

これ以前にも、火〜金はリモートするかどうかを個人で判断できるようにするなど、エンジニアの自由度を広げていました(詳細は HOW GROOVES REMOTE WORKS を見てください)。

どのような文脈で進めたか?

grooves は「ワーク・シフトインフラを創る」をビジョンに掲げている企業です。 簡単に言うと、新しい働き方・流れを世の中に提示し、そのインフラを作ることを目指しています。もちろん、Forkwell もその大本のビジョンの元で運営されています。

「ワーク・シフトインフラを創る」をビジョンに掲げる以上、私たち自身も率先して新しい働き方をしていく必要があります。

そのため、リモートワークやフレックス制度などについては、会社全体で挑戦していく風土があります。

これまでも、個人のライフステージの変化に合わせて

  • 結婚を機に大阪に引っ越す社員のために、大阪にリモートオフィスを借りる
  • エンジニアだけでなく、全社でリモートワークを導入する

といった挑戦をしてきました。

今回のケースのように、全ての要望を実現できるわけではないですが、会社全体の生産性を上げるためであれば、実験する土壌はある会社です。

そんな風土をもつ grooves が、なぜ深夜のフレックスだけは導入することができなかったのでしょうか?

フレックス制度で、深夜の勤務を認めることができなかった理由

まず、フレックス制度に関して社労士などを通じて調べたことを記載します。
(なお、私自身は法律家ではないので、間違いがあるかもしれません。本文を鵜呑みにせず、社労士などにも確認してください。)

  • フレックスタイム制とは、必ず勤務すべき時間帯(コアタイム)を遵守したうえで、労働者が各自の始業時刻と終業時刻を原則として自由に決められる制度。
  • 1日の労働時間規制に代えて、清算期間における労働時間の合計によって勤務時間・時間外労働の有無が判断される。
  • フレックスでも勤務した時間はきちんと管理しなければいけない
  • 深夜帯に勤務した場合(22:00-5:00 が対象)は深夜割増賃金で支払わなければいけない

これが何を意味しているかというと、

  • もし全く同じ能力の人がいるとして、同じ労働時間・同じバリューだけを発揮している場合でも、個人の判断で深夜帯に働いた人だけが、給与を多くもらえることになる
  • 深夜勤務を認めたとしても、稼働時間を細かく申請してもらうことが必要となる

といった、難しさが生じることがわかりました。

これに対応するためには、深夜割増賃金まで見込み給与に含む等の制度に変更する必要があります。

さらに問題なのは、勤務時間の登録の義務付けは引き続き必要となるため、それを「10分遅れてもSlackで連絡すれば問題ない雰囲気」といえるかというと、管理されている感はでてしまいます。何より手間です。

そのため、法律に目をつぶる以外で、深夜帯に個人の裁量で働ける仕組みを見つけることができませんでした。

フリーランスなら解決するのか?

そこで出たのがフリーランス(業務委託)という選択肢です。 ここではまず、正社員とフリーランスの違いについて記述します。

正社員 業務委託
契約 雇われる者が雇い主に対して労務を従うことを約束し、雇主がその対価として報酬を支払うことを約束することによって成立する契約 一事業主として特定の仕事を処理することを目的として行なわれる契約
社会保険 あり(雇用保険、厚生年金、健康保険、労働保険 等) なし
その他社会保障 労働基準法に準ずる
最低賃金、有給休暇の有無、産休育休の有無 等など
最低賃金や有給休暇など、労働に関する法令が適用なし
雇用期間 基本は無期雇用 有期契約(1~3ヶ月契約にしているケースが多い)
時間・勤務地の拘束 労働基準法及び就業規則に準ずる 時間的拘束、勤務地の拘束はできない(双方の内規的な取り決めは実際のところするケースが多いが、企業から厳密に指定するのは違法
税金 年末調整の対応のみで確定申告の必要なし 確定申告が必要
給与の支払い方法 会社側で給与計算=>支払い 本人から請求書=>支払い
交通費 実費支給 基本は特に支給なし ※
小口精算 実費支給 基本は特に支給なし ※
勤怠管理 必要 必要なし

※ 会社主導の遠隔地の場合は、双方協議で負担する場合あり

他にも、フリーランスには以下の特徴があります。

  • リスクがある分、正社員より手取り額が高くなる可能性が高い
  • 受発注関係になるため、成果物でのみ評価され、人事考課は関係ない
  • ストックオプションを行使する際に、税金の徴収額が大きくなる

フリーランスなら、彼が望む働き方に近づけそうです。

本人にとっては、grooves で活躍してきた実績もあるため、初めての会社と比較すれば打ち切りリスクも少なくなります。
grooves としては実質的な支払い額が増えますが、制度変更よりは少ない投資で済みます。
他社に転職してしまうリスクは増えますが、何もしなければそのリスクは一層高まったでしょう。

結果的に彼は、このまま grooves で正社員を継続するメリットはないと判断し、今回の結論にいたりました。(もちろんフレックスだけが全ての理由ではないです。)

今回、grooves でフリーランスという選択肢が残っている上で、彼がWeb上で退職を表明したのは、広く世の中に自分の可能性を問うためです。

繰り返しになりますが、エンジニアの成長・キャリアアップを応援する Forkwell が、自社のエンジニアのキャリアアップや転職を応援しないのは嘘になりますから、寂しい気持ちはあるものの、ぜひ応援したいと思います。

推薦文

マネージャーの立場から見た、彼の長所は、

  • 圧倒的な実装スピード
  • ロジックに関する的確なレビュー
  • 高い問題意識と自主性
    • 彼の問題意識をきっかけに、形成された開発文化が多々あります
      • PRへのレビューは24時間以内に2人以上(ユーザーに早く価値を届ける、手戻りまでの期間を短縮するなどの意図)
      • エラーはすぐ確認する 等
    • この問題意識の高さは、コードや開発環境だけでなく、会社の制度にも波及します
  • 社外活動に積極的で、エンジニア界内での認知度・つながりが多い

です。

一方で、彼が苦手とするのは、

  • よそ見をしがち 
  • 興味のない分野でパフォーマンスがわかりやすく落ちる
  • 忖度

などがあり、言われたとおりにだけ働くタイプではありません。
「えっ?いまそれやってるの?」ということもあります。そういったことからアイディアを生み出すのが彼の魅力でもあるのですが。

すでに多くの会社からオファーが来ているようですが、我こそはという会社は、引き続きぜひ声をかけてあげてください

エンジニアを募集しています。

Forkwell では Rails エンジニアを募集しています。 今回、良くも悪くも私たちがどのような会社かが表に出ましたので、このような私たちを良いと思える人にこそ、ぜひ遊びにきてほしいです。

jobs.forkwell.com

となりの事業部の Crowd Agent でも Rails エンジニアを募集しています。

jobs.forkwell.com

また、自分からエントリーするのは恥ずかしい、と思われた方は、ぜひ Forkwell Scout に登録してください。

jobs.forkwell.com

皆さんのプロフィールを一人ひとりじっくり拝見し、興味を持った方にはこちらからお声がけさせていただきます。

引き続き、エンジニアの成長・キャリアアップを応援するサービスとして努力してまいりますので、 grooves をよろしくお願いします。

ユーザーニーズを把握する「UXリサーチ集中講座」に参加しました

みなさまこんにちは。 デザイナーの 711fumi です。

2017/11/18にユーザーニーズを把握する「UXリサーチ集中講座」 に参加させていただきました。 いろいろな学びがあったので、感じたことをいくつかご紹介できればと思います。

講座概要

講師は樽本 徹也さん。 UXリサーチャ/ユーザビリティエンジニアとして幅広い製品のUX/UI開発に携わり、UXに関する講演や書籍の執筆もされています。

この講座では、UXリサーチで必須となる「3大手法」を、ワークショップを通じてわかりやすく解説してもらえます。

3大手法

  • ユーザーインタビュー:「師匠と弟子」モデルに基づいたインタビュー
  • ペルソナ:複数のユーザーを合成して作り出す仮想のユーザー像
  • ジャーニーマップ:ペルソナの行動や感情の変化を時系列に図式化

内容については前回参加された方のレポートを見ていただけるとわかりやすいです(まるなげ) UXリサーチ集中講座 参加レポート

ペルソナ考えたり(絵がうまいのうらやま) f:id:blog_711fumi:20171118144146j:plain

ジャーニーマップ作ったり(温泉&ビール含めてトレランです) f:id:blog_711fumi:20171118175302j:plain

デザイナーとしての学び

イノベーションはユーザーテストから生まれない

プロダクトを実際に操作してもらいユーザーを観察する「ユーザーテスト」を行い、その結果を元に改善するという手法はよく行われています。 これは現在のプロダクトの機能を改善するという目的には繋がるのですが、そもそも「プロダクトがユーザーのやりたい/解決したいに沿っているか」は検証しづらい部分があります。
(数値分析なんかも同じかなと)

そこで今回学んだような「ユーザーリサーチ」を行い真のユーザーニーズを探ることが、プロダクトそのものの価値を検討する、より良い価値を提供するためのアイディアを考える際に有用なのかなと感じました。

また講座の中で「ユーザーの意見を集めるな、ユーザーの体験(UX)を集めろ」という話がありました。 「ユーザーのプロダクトに対する意見」ではなく「ユーザーの体験」から汲み取れる真のニーズから発想をスタートさせることが、プロダクトを大きく成長させるために重要そうです。

インタビュイーは聞かれたことしか答えない

インタビュイーは聞かれた事に対して「相手が欲しがっているのはこのくらいの情報だろうな」と考え要約して答えを返してくれます。 しかし我々が集めたいのはユーザーの体験なので、どんどんワードを捕まえて深掘り(質問)していく必要があります。 これが難しい…

講座ではユーザーの体験を引き出すコツみたいなものも教えていただいたのですが、特に印象に残ったのが「時間軸にそって質問する」というテクニックでした。
ユーザーが質問に答えてくれた時、「その前はどうだったのか」「その後どうしたのか」を質問することで、ユーザーがプロダクトに関わっている間(更にその前後も)の体験をズルズル引き出すことができますね。
ある行動の前後を掘り下げることで、「なぜその行動に至ったのか」「その行動がどう影響したのか」などの背景も引き出しやすくなるように思いました。

組織の認識を揃えるツールである

この講座ではペルソナやジャーニーマップなどのアウトプットの作成方法が学べるのですが、そういった見える形で「組織(プロダクト)の立ち返るべき情報」が存在しているというのはとても意味のあることではないかと思いました。
プロダクト(私の場合だとWebサービス)を日々運用していると、常にチームは「やるべきこと/やらないこと」の判断を求められます。
細かな機能改善から今後の開発方針まで「ほんとうに必要か」「今やるのか」「誰を喜ばせたいのか」などをリソースやビジネス状況を見比べつつ判断していかなければなりません。

しかし今回学んだような調査〜整理をおこない、私達のプロダクトが「いつ・誰の・何を」解決すべきなのかをはっきりさせておくことができれば、日々の判断での誤り(一貫性のなさ)や判断の難しさを減らすことに大きく役立つのではないかと感じています。

参考記事: UXデザインのために作成される主要な資料一覧

まとめ

書籍などでUX調査が必要という知識は得られても「どのようにやればよいのか」「何を意識しておこなうべきか」などを体感できる機会というのはなかなかありません。 今回ワークショップという形で、様々な業種職種の方と一緒に体験できたことは本当に貴重な経験になりました。

あとは自分のプロダクト開発に適応させるだけ!(それがむずかしい

おまけ

とかいろいろ書いていますが、私自身まだUXリサーチ初心者です(*´σー`)エヘヘ 一緒にgroovesのプロダクトを成長させてくれる人募集してます!

デザイナー
https://www.wantedly.com/projects/164427

エンジニア
https://jobs.forkwell.com/grooves#jobs

開発合宿でプロダクトを開発するロールプレイをしました

今年の6月にgroovesにジョインしたデザイングループのksm240です。 Crowd Agentという採用支援サービスの開発でデザイナーとして参加してます。 今回は 「今まさに転職活動してるデザイナーさんにgroovesのデザイナー業務に興味を持ってほしいし、あわよくば応募してもらえないかしら?!」っていう下心満載 で、groovesのデザイナーがどんな感じでプロダクト開発に関わっているのかを徒然なるままに書いていきたいと思います。

まずはざっくりと大まかな流れを知ってもらうために、先日grooves開発チームでおこなった合宿の内容を紹介していきたいと思います。 合宿ではチームビルディングを目的としたプロダクト開発のロールプレイを行いました。

なぜロールプレイをしたのか

Crowd Agentの開発チームではメンバーの半分以上がリモートでの勤務で、普段オフラインでひとところに集まって作業することはありません。「せっかく集まるんだから、集まらないと出来ないことをしたいね」ということから話が始まりました。 また10月の中旬ごろに、Crowd Agentの事業部長の交代や、新たな開発メンバーも増えたこともあり、「普段開発しているプロダクトとは別に、小さめのプロダクトを作るロールプレイをしてみるのはどうだろう」という事になりました。 新しい事業部長をプロダクトオーナーに据えて、要求分析から仕様策定までのプロセスを知ってもらうことが目的です。

実際やったこと

登場人物を決める

  • 困りごとを持っている人(ペルソナ)
  • プロダクトオーナー
  • 開発陣

この辺は合宿当日ではなく合宿前日までに予め決めておきました。合宿当日はこのロールプレイの他にも予定していたことがあり、ロールプレイに当てられる時間も長くても半日くらいだったので、前もって決めておきましょうということでした。 ペルソナの人物像も前日までに設定を済ませておきました。私より2ヶ月あとにジョインしたbary822さんがペルソナを考えました。 困りごとのペルソナを共有する bary822さんに考えてもらったペルソナとペルソナの困りごとについて共有します。

f:id:grooves:20171219144715p:plain

考えをesa.ioにまとめておいてもらいました。 普段の業務でもそうですが、デザイナーもこのあたりから話し合いに参加します。 実際どんなことで困っているのか、課題を感じているのかを直接聞いたほうがいいと思っています。 いざプロトタイプを作るときに「こういうUIのほうが馴染みやすいのでは」とか「こういう導線を作ってあげたほうがいいかもしれない」など色々と提案が出来ると思いますし、これは感情的なものかもしれませんが、きちんと腹落ちした状態でプロダクト開発に参加出来る気がします。

困りごとについて突き詰めていって、内容を精査する

使う道具はホワイトボードがあれば十分です。 共有した困りごとを、実際どんなことが起こっているのかという事実を話してもらいながら突き詰めていきます。 困りごとの他にも 「こんなことが出来たら便利だな」 みたいなことも書き込んでいきます。

f:id:grooves:20171219145947p:plain

どんな機能があれば良いのかをはっきりさせる

困りごとの具体的な内容が見えてきたら、それを解決するための機能を考えていきます。 Pivotalにストーリーを書いていくので「〇〇は▲▲が出来る」みたいな感じで考えていきます。

f:id:grooves:20171219145804p:plain

上に書き出したメモを元に、フロー図にして落とし込んでいきます。

f:id:grooves:20171219150110p:plain

この時「この機能もあったほうが こんな事があるかもしれないからあると便利 」みたいな、 事実としてはないけど将来起こりそうな問題 に対して解決するための機能は、この時点では盛り込まない方がいいかなと思います。雑に理由を述べると 「使うか使わないかもわからないものを作るのはリソースの無駄遣い」 っていうところですが、実際開発スケジュールが潤沢に確保できるわけではないですし、時間は有限なものなので、 必要なものを必要なものだけにとどめておいたほうが良い と思います。

仕様を作る(Pivotalにストーリーを登録していく)

Crowd Agentのプロジェクト管理ツールで使っているPivotalTrackerに考えた機能をストーリーに登録していきます。 まずはタイトルのところに「〇〇は▲▲が出来る」という形で書いていきます。 各ストーリーにはdescriptionを書くところがあって、詳しい仕様などはこの中に書き込んでいきます。 なぜその機能が必要なのか、どのような機能なのか、必要な項目は何か ……などなど、詳しく書いていきます。 今回は開発の流れを知るためのロールプレイということだったので、その部分は省きました。 実際に登録したストーリーがこちらになります。

f:id:grooves:20171219150148p:plain

仕様のプロトタイプ(ペーパープロトタイプ)を書いていく

そしていよいよペーパープロトタイプを作っていくわけです。デザイナーの出番です!でも、ぶっちゃけデザイナーじゃなくても出来る作業です!機能を開発するために、「この画面にはどんな要素が表示されているか」というのがわかればいいので、わざわざグラフィックツールなど使わずとも、ペンと紙があれば十分です。Post itがあると便利かもしれません。(今回は使いませんでした) 今回は合宿という限られた時間の中で進めていたので、ホワイトボードを2台用意して、参会者で2チームに分かれて作りました。

f:id:grooves:20171219150418p:plainf:id:grooves:20171219150433p:plainf:id:grooves:20171219150442p:plainf:id:grooves:20171219150454p:plainf:id:grooves:20171219150507p:plainf:id:grooves:20171219150514p:plainf:id:grooves:20171219150528p:plain

PivotalTrackerの該当するストーリーに、作成したプロトタイプの画像を添付しておくと、開発するときやデザインカンプなどを作るときに情報が確認しやすくてとても良いです。 今回のプロトタイプはホワイトボードだったこともあって、一個の画面に複数のストーリーが混在してしまっているので、画像を分割してから添付するといいかもしれませんね。

ペルソナな人に見せて、意見をもらう

出来たプロトタイプをペルソナな人(今回の場合はbary822さん)にレビューしてもらいます。 プロトタイプが、ベルソナの困りごとを解決するものに沿っているかという確認が目的です。 ここでよくあると思うのが「やっぱりこういう機能もほしい」みたいな要望が出てくることです。ストーリーに落とし込んでいく途中で、できるだけ「なくても問題ない」みたいな機能や仕様は入れないようにするんですが、「やっぱりほしいなぁ」って感じで掘り返されることがあります。 そういうときは「ホントのホントにそれは必要?ないと死んじゃうくらい必要??」というくらいに真剣に検討してみたほうがいいかと思ってます。本当に必要で、その機能がないとペルソナの困りごとが解決されないのであれば、新しいストーリーにすればいいと思いますし、「…やっぱりなくても問題ないね」という話になれば、そのときは掘り返されたことはきれいに忘れましょう。 もしくは「今はやらないけど将来的にはやるかもしれない」という温度感のストーリーを作っておくという手もあります。見積もりのときにBacklogに移動せず、Iceboxに入れたままにしておけばいいものですし、あとになっても「そういえばこのストーリー作ってたけど、いつやる?」という話になったときに再度検討すればいいと思います。

いざ開発へ

いよいよ開発へ!っていうところで、合宿でのロールプレイは終了しました。 実際は、GitHubにリポジトリを作って、ログイン認証で使うGoogle OAuthのAPIキーの取得までやったと記憶しています。先日メンバーに「そういえば、あれから何か進捗とかあったんですか?」って聞いたら、「……休日プロジェクトにやろうって思ってたんですけどね…」っていう返事を聞いたような気がします。

実際のCrowd Agentの開発フロー

Crowd Agentの開発チームではアジャイルな開発フローで日々業務を進めています。 Crowd AgentだけではなくForkwellでもアジャイル開発を採用していて、ジョインしたメンバーには「アジャイルサムライ」を読むことが推奨されてます。 フローは上記で紹介したロールプレイの内容と代わりありません。

開発チームとビジネスチームで集まって「ユーザーの困りごと」を共有

四半期ごとにメンバーで集まって、クオーターでどんなことを目標に開発を進めていくかを話し合って決めていきます。この時、開発メンバーだけでなく、ビジネスサイドのメンバーにも集まってもらって、ビジネスサイドの目標や課題を共有してもらいます。先程のロールプレイで言うところの「ユーザーの困りごとを共有する」部分に該当しますね。 ビジネスサイドのメンバーには日頃からCrowd Agentのユーザーさんからヒアリングをしてもらうことを日常的に行ってもらっています。リリースした新機能や回収した既存機能についてレビューが欲しかったりするときは、デザイナーもユーザーの元に訪問してユーザーインタビューをさせてもらうこともあります。ヒアリングした内容をレポートにまとめて、開発チームに共有したりすることもします。 ユーザーインタビューのレポートを踏まえて、クオーターで行っていく開発の内容を検討します。

課題を突き詰めて開発する機能を決めていく

共有された「ユーザーの困りごと」から開発する内容を決めて行きます。開発する機能が決まったら、PivotalTrackerにストーリーを登録、仕様を詰めていき、見積もりを行って開発をスタートさせます。 極小さな改修開発であればプロトタイプの工程はありませんが、UIなどが大きく変更する場合はデザイナーがグラフィックツールを使ってプロトタイプを作成します。 使用しているツールはSketchがメインになります。 Sketchで作ったプロトタイプをInVisionを使って、画面遷移などをつけて、エンジニアやビジネスサイドのメンバーに共有して、コメント機能を使ってレビューをもらい、貰った内容を反映させながらデザインをブラッシュアップしていきます。 Crowd Agentの開発メンバーはリモートワーカーが多いので、InVisionのようなコメントがつけられるツールは非同期コミュニケーションが円滑に出来るので、重宝しています。

f:id:grooves:20171219150725p:plain f:id:grooves:20171219150752p:plain

実装〜PR〜マージ、リリースまで

画面が決まったら、それを元に実装していきます。 Crowd Agentの開発チームでは、デザインの実装もデザイナーの仕事になります。 というより、あまり「ここからここまでが誰の仕事」っていうのは決まりが明確になってないです。 なので、エンジニアがデザインの実装を行うこともありますし、デザイナーがRSpecのテストを修正することもあります。各々が得意なところ、やってみたいところをやっていく…そんな感じで作業分担しています。開発で詰まったり、「この実装やったことないけどやってみたい!」っていうのがあれば、メンバー同士でペアプロを誘い合ったりすることもあります。知人に「こんな感じで開発してる」って話すと「ボーダレスな人たちの集まりだ」って言われたのを思い出します。そうかもしれません。

コードレビューも基本的に開発チーム全員で行います。 私はRubyをガリガリかけるわけではないので、バックエンドのレビューは参加しないことも多いのですが、自分のタスクの箸休めにPull Request一覧を眺めて気になったものがあれば、コードを眺めて「なるほどなぁ」って頷いたり、わからなかったり気になったことがあればコメントで質問したり……ということもあります(ごくたまーにですけど)。Gitの操作でわからないことがあればエンジニアの方に教えてもらうこともあります。レビューは気づきがあったりするのが楽しいなと思います。

UIに大幅な変更がある場合、コードレビューが終わった段階でStaging環境にデプロイして、実際に動く画面をビジネスチームやサービス推進チームに共有して触ってもらうこともあります。 ここで少しでも操作に違和感があったり、気になったりすることがあればレビューを貰ったりして、必要であれば再度調整を行います。 InVisionである程度動きがわかるようにプロトタイプを作っていても、微妙に「思っていた動きと違う」ということがあるのはあまりよくないなと思っているので、その段階でコミュニケーションを取ってお互い納得行く形になるように心がけてます。

そうして色んな所からレビューをもらいつつ、ブラッシュアップしたものがチーム全体で「いい感じ!」ってなれば、晴れてmasterブランチにマージされ、リリースされていきます。めでたい 🎉

終わりに

デザイナー求人の応募来てくれないかな?!という下心で、Crowd Agent開発チームでのデザイナーの関わり方という内容で紹介させていただきました。 事業会社でデザイナーをやってて「面白いな」と思うところは、作りっぱなしで終わりではなく、作ったらユーザーの反応を見て、もっと使いやすく使ってもらうにはどう工夫していけばいいかということを考えて、プロダクトを育てていけるところにあるかなと思っています。 ビジネスでやっているので「こんなふうに売っていきたい」、「こんな感じで見せていきたい」という欲求はもちろんあるのですが、サービス提供側の欲求とユーザーの課題解決の橋渡し役がデザイナーの仕事なのかなぁと思っています。 もし、これを見てるデザイナーさんで「ちょっと話を聞いてみたい」という方は、どうぞ、むしろ是非、Wantedlyの「話を聞きに行きたい」からご応募ください。 お話できるのを楽しみに待っています🙋

groovesのデザイナーの求人についてはこちらを御覧ください! <HR×IT>実装までお任せ!コーディングにも興味のあるデザイナーを募集! - 株式会社groovesのUI/UX デザイナー中途・インターンシップ・契約・委託の求人 - Wantedly

RWCに交通費会社持ちで参加してきた

こんにちは!Crowd Agentのエンジニアが先週行われたRuby World Conference 2017に参加してきました。非常に魅力的なイベントだったので、トークの中から印象に残ったものをピックアップしてご紹介します。

f:id:grooves:20171101103259j:plain
松江では”るびー”と聞くと宝石よりも「コンピュータの何か」を連想する人が多いそうな。

1日目

エンジニアのbary822です。groovesには最近加入して、大阪からフルリモートで働いています。

今回はRWCの1日目で行われたトークの中から、私の印象に残った2つをピックアップしてご紹介します。

Keynote by Matz

Rubyユーザー数推移

Rubyをつくってから、ユーザー数がどのように推移していったのか。というお話でした。

1人(Matz本人)だけから、メーリングリストを公開すると、2,3週間で200人になったそうです。当時は新しいプログラミング言語にユーザーが定着しづらい状況だったらしいので、それを考えるとこの伸び率はMatzの予想を遥かに超えていたそうです。それだけRubyの魅力に気づいた人が当時から多かったことがわかりますね。

また、ML経由で開発に参加する人も徐々に増えてきたそうです。当時はオープンソースという概念も一般的ではなく、顔も知らない人が自分のプロダクトの開発に参加してくれるなど予想外の出来事だったとおっしゃっていました。

Ruby初の英語で書かれた本、Programming Ruby: A Pragmatic Programmer's Guideが発売されると、ユーザー数は10,000人規模まで急速に伸び始めたそう。Dave Thomasが共同執筆者であることから彼とRubyとのつながりはここから始まったのが推測できますね。Rubyは後のRailsの発明のおかげもあり、そこからさらに加速し、現在では全世界で1,000,000人以上のユーザーを持つプログラミング言語へと成長した、というのがRubyのユーザー数の推移を基にした歴史の話でした。

(OSS)コミュニティについて

コミュニティが生き残るには、変化が大きすぎても小さすぎてもダメだというお話です。

例えばソフトウェアで言えば、互換性を保ちつつも新しい機能やパフォーマンスの改善をし続けていく必要がありますよね。

これは個人的な意見なのですが、Rubyコミュニティはこの「互換性」というのものを単なるプログラムの互換性以上のものと捉えていると考えています。それはプログラマの互換性です。Rubyプログラマに「なぜRubyなのか」という質問をした時に必ずと言っていいほど返ってくるのは、「書いていて心地いいから」ということなんですよね。この心地よさこそがRubyの最大の特徴でもあることから、RubyプログラマがRubyらしくプログラムをかけることはある種の「互換性」なんじゃないかなと思います。

Rubyによるたのしいユーザー基盤再構築 by 諸橋 恭介さん

楽しく開発し続けるには

諸橋さんは現在Cookpadでユーザー情報をコアプラットフォームとして提供するための開発プロジェクトに参加していて、彼のチームで「楽しい」開発を実現するために行ったことをお話してくださいました。

具体的には、楽しい開発を考えるための3つのステップとして、

  • コーディングするのが楽しい
  • チームで開発するのが楽しい
  • チームとチーム外の人とサービスリリースするのが楽しい

ということを挙げておられました。

コーディングするのが楽しい

Rubyはそもそも楽しくコードがかけるようにデザインされているのですが、しかし、そんなRubyを持ってしても、アプリケーションのコードが複雑になるにつれ、コーディングをするのが楽しくなくなってしまう、ということはありますよね。

複雑すぎてメンテンナンスが困難となったアプリケーションのメタファーとしてレガシーコードということがよく挙げられますが、我々はこのレガシーコードがお金を生むからこそ楽しくコーディングができる環境があることを認識しなくてはならない。なので、レガシーコードに真摯に向き合い、メンテナンス性を高める努力をすることで、これをまた楽しくコーディングできるようにしようと提案していました。

チームで開発するのが楽しい

ほとんどの開発プロジェクトに置いてはチームで開発することが前提となりますよね。

自分の考える「楽しい」の定義が他のメンバーのそれとは異なるので、チーム単位での「どうすれば楽しいか」という共通認識を持つことが最初のステップだそうです。そこからは振り返り、見積もり、計画づくりを軸としたイテレーションを回していき、どうすればより楽しい開発ができるチームになれるかを追求していくというプロセスがいいのだそう。

また、見える化はチームとしての「楽しい」を追求していく施策の効果的な施策の1つだそう。具体的には、バーダウンチャートでプロジェクトの進捗を見える化することで、プロジェクト完了をゴールとして、いま自分たちがどのステージにいるのかを明確にすることができたそうです。また、イテレーションの振り返りの中でtryとして上がった項目をいつでも意識できる場所に配置することも効果的だったようです。

チーム以外の人とサービスリリースするのが楽しい

チームが変われば「楽しい」の定義が変わる。「楽しい」の定義が変わればそれを基に発展してきたチーム文化も変わる。

自チーム以外のバックグラウンドが異なる人達と一緒に価値を届けることができるというのはそれだけで楽しさが味わえる一方で、その文化の違いから来る困難も多いそうです。その中でも私が一番なるほどと思ったのは、同じものを同じ名前で呼ぶことの重要さでした。

ある概念が抽象化されたものであればあるほど、チーム間でその認識にズレが発生する可能性が高くなる。そのため、それが具体的にどういうものを意味していて、何という名前で呼ばれるかを明確にしておくことは重要だそうです。

新しいメンバーがチームに入った時

これはトークの後で個人的に質問したことです。

新しいメンバーがチームに入った時に、その人が考える「楽しい」とチームが考える「楽しい」にギャップがあった場合にどうすればよいか?という質問に対して、

その人が考える「楽しい」を加味した上で、チームの「楽しい」を再定義する必要がある。変化が起こることは受け入れる。ただし、「楽しい」の定義が全く違うベクトルの人はチームに入れないようにするというのも選択肢として考えてよい。

という回答を頂きました。

自分の中ではチームの「楽しい」の定義はそのチームの文化になるものであり、変化させるべきではない。という考えを持っていたので、それを再定義し続けていくという意見は新鮮に感じました。チームの規模が大きくなるにしたがって、多様な考えを持った人が入ってくるということを考えれば、その方が持続可能なチームの発展が望めるのかもしれないと思いました。

f:id:grooves:20171101172607j:plain
Ruby PrizeはRubyコミュニティに大きく貢献した方に送られる賞。賞金付きのものは今ではこれだけらしい。

f:id:grooves:20171031202722j:plain
鰆を香りのある木の上で栗、まいたけ、そして「むかご」と呼ばれる植物の芽のようなものと一緒に焼いたもの。美味。

2日目

エンジニアの@talkto_meです。二日目を担当します。

Ruby Is Nice so We Are Nice by 角谷 信太郎さん

f:id:grooves:20171102101044j:plain

メディアとしてのRuby

Matzの最近のセッションで、"Matz is nice so we are nice" という表現が "Ruby is nice so we are nice" に変わったことをきっかけとして、Rubyのナイスさがどのように育まれてきたのかという話がありました。 Rubyist(Rubyに対して単なるお客さん以上の気持ちを持っている人)が持ち寄った"いい感じ"の成果が、Rubyのナイスさを育てていると受け止めており、"いい感じ"の一例としては、RubyKaigi 2017 のMatzの基調講演でのmoduleの使われ方の変遷に表れていると感じたとのことでした。

「Rubyをキメると気持ちいい!」というMatzの言葉がありますが、Rubyは書き手にプログラミングの楽しさを感じさせる言語としてデザインされています。書き手の想いや楽しいという気持ちをコードを介して読み手に感じさせることのできるRubyのメディアとしての側面についても言及していました。 最近、弊社では月に一度Railsのコードの歴史を辿っていく勉強会をしているのですが、初期のActiveRecordで登場したmethod missingの大胆なメソッドの呼び出しやhas_finderに始まったnamed scopeのシンプルさは、キメた時の気持ちよさを読み手が感じられる実装だと感じました。

ポエムとしての仕事

以前よりもビジネスとしてのRubyの利用は増えている一方で、仕事を通して"楽しさ"を共感できる職場はそれほど増えてはいないと感じているとのことでした。 ビジネスとしてのソフトウェア開発は、インターネットの成長とともに自然と発展した"野生のソフトウェア"であるRubyとは異なり、人工的な環境であるため"いい感じ"を再現させる必要があると考え、Rubyと同じメディアとしてアジャイル/リーンを通して、仕事の送り手の"楽しい"を受け手の心に再現できないかとおっしゃっていました。

QAで角谷さんがさりげなく発した「うまくいかなくてもいいです、また別のやり方探しましょう」という一言が、アジャイル/リーンをメディアとした"いい感じ"を再現するために必要な考えなのではないかと感じました。

f:id:grooves:20171102141439j:plain

Rubyプログラマが育つ仕組み−Rubyでの受託開発を10年回してみて by 大場寧子さん

有志による新入社員研修改善プロジェクト

実務でのOJTベースの研修は、新入社員と受け入れ側の両方で非効率と感じるシチュエーションが見受けられていました。 株式会社万葉ではホラクラシーな組織形態を採用しており、担当者が自律的に判断する環境を整えているそうです。現状の問題を解消するために有志による改善プロジェクトが発足したとのことでした。 新しい研修では、習得してほしいスキルをベースに24のステップになっている擬似プロジェクトを採用しており、要件をあえて緩くすることで、状況をより現実に近づけ、自分で仕様を検討して決める判断力やコミュニケーション能力を養うことができます設計になっているとのことです。

研修を軸に社員同士のコミュニケーションが活発になる

研修を画一化すると、メンター以外の社員も自然とレビューに参加する動きが見られるようになったそうです。変化するベストプラクティスやコーディングパターンの議論も活発になり新入社員以外でも知見を得られる良い機会になったとのことでした。

初めての人がチームに新メンバー入る時、スキルに応じた仕事の選択や文化的な擦り合わせには多少なりとも時間がかかります。開発をスピードアップさせるために必要なコストですが、一時的にチームに不安な状態が生まれるため、事前に解消・軽減することができる研修方法には魅力を感じました。研修を繰り返すことで、レビューする側の社員の負担も軽減されていき、チームを超えた横断的なコミュニケーションを生み出している点も複数チームの交流を考えている企業にはもってこいだと思います。

研修期間完了は人により異なり、その分のコストが発生する一方で、新入社員の得手不得手の共有、文化のすり合わせが行われ、実案件へアサイン後はスムーズに活躍できるようになったそうです。プロジェクトで育ったメンバーがメンターとなり研修内容が改善していく流れもエンジニアが会社を育てていく良い文だと感じました。

なお、 https://github.com/everyleaf/el-training に擬似プロジェクトの成果が公開されています。弊社でもエンジニアの教育の機会にはぜひ参考にしたいと思いました。

f:id:grooves:20171101181250j:plain f:id:grooves:20171102172336j:plain

エンジニア募集

株式会社groovesでは、エンジニアを採用しています。 私たちと働くことに興味ある方、気軽にご連絡ください。

jobs.forkwell.com

jobs.forkwell.com

開発合宿に島根県松江市がおすすめな理由

f:id:grooves:20171030193642j:plain

こんにちは、grooves の赤川です。 11/1、2 と島根県松江市にて RubyWorld Conference 2017 が開催されましたね。 実は株式会社groovesではエンジニアメンバーが一足早く現地に乗り込み、開発合宿を実施していました。

海と、山と、カニがおりなす秀麗無比なる島根の地に、メンバーの士気も終始高まりっぱなし。 皆さんにもぜひおすすめさせてください。

おすすめの理由その1 ー 非日常な空間

国の登録有形文化財であり、110年の歴史をもつ美保館を、一棟まるごと貸し切ることができました。 海を眺めながらのコーディング、畳に寝っ転がりながらのペアプロ、など、日常からの解放感を感じながら開発に集中することができます。

中央の大きな建物が旅館、左隣の黒い屋根の建物が今回の合宿所 美保館 f:id:grooves:20171031125735j:plain

中はまるで千と千尋の神隠しの舞台 f:id:grooves:20171031113012j:plain

f:id:grooves:20171031113437j:plain

とにかく広い合宿所 f:id:grooves:20171030134930j:plain

海を見ながらコーディング f:id:grooves:20171030151247j:plain

f:id:grooves:20171031095040j:plain

畳の上でペアプロ f:id:grooves:20171031094954j:plain

おすすめの理由その2 ー 開発意欲を妨げない設備

  • Wi-Fi完備
    • 合宿所の中は全てWi-Fiが飛んでおり、好きな場所で好きなように開発することができます(ただしたまに重くなるので個人でもネットにつなげる準備があると安心です)
  • 24時間利用できる合宿所
    • 合宿所は24時間利用することができ、深夜にコードが乗ってくるエンジニアの気持ちを止めません。ちなみに大浴場も24時間入ることが出来るので、いつでもリフレッシュが可能です。
  • トイレがきれい
    • 110年前の建物というとトイレや浴場が古いイメージがありますが、水回りはリフォームされかなりきれいになっていました。合宿中は何度も利用することになるので清潔さは意外と重要です。

おすすめの理由その3 ー 島根県松江市職員によるおもてなし

その3にして、最大の理由です。 今回の合宿企画、最初から最後まで松江市職員の方が徹底的にサポートしてくれました。

会社での合宿企画というのは、実は非常に手間のかかる作業なのですが、その大部分をご支援いただき、また、抜け漏れやすいポイントをご指摘していただけるので、スムーズに企画することができました。この安心感は、他のエリアでは絶対に味わえないでしょう。

具体的にご支援頂いたこととして、

  • 参加人数・予算に合わせた合宿所の選定と予約の手配
  • ホワイトボード、プロジェクター、電源タップなどの備品のご用意
  • 観光プランのご提案
  • なにより、あたたかな笑顔

などがありました。

ちなみに、今回groovesの開発合宿を担当していただいた福田さんは、ITリテラシーがめちゃくちゃ高く、Facebookメッセンジャー や appear.in などでスピード感を持って情報交換することができました。 失礼ながら勝手に抱いていた地方公務員のイメージ像が覆りました。

福田さん、この場を借りてお礼申し上げます。

もし島根県での開発合宿にご興味を持った方がいらっしゃいましたら、ぜひ福田さん(Mail:richi [at] city.matsue.lg.jp )にご連絡してみてください。

まとめ

島根県松江市、最高です。おすすめします。

エンジニア募集

株式会社groovesでは、エンジニアを採用しています。 私たちと同じチームでユーザーへの価値提供にこだわりたい方、ぜひご連絡ください。

jobs.forkwell.com

jobs.forkwell.com

おまけ

開発合宿の模様を写真で紹介します。

普段リモート中心で、オフラインで交流する機会の少ない Crowd Agent チーム。 この合宿を機に、もう一度チームビルディングに取り組みました。 f:id:grooves:20171030141312j:plain

f:id:grooves:20171030141624j:plain

休憩時間には、すぐ隣の美保神社へ参拝 f:id:grooves:20171030152900j:plain

f:id:grooves:20171030152837j:plain

f:id:grooves:20171030153022j:plain

歴史ある美保神社で ITエンジニアの活躍を祈りました f:id:grooves:20171030153049j:plain

だんだんは、ありがとう、という意味らしい f:id:grooves:20171031125350j:plain

海と山を眺めながら息抜き f:id:grooves:20171030155624j:plain

休憩を終えて再開 f:id:grooves:20171030151707j:plain

国内唯一の Ruby / Railsコミッターであり、grooves の取締役を務める松田明(@a_matsuda)氏も参加 f:id:grooves:20171030141225j:plain

f:id:grooves:20171031115108j:plain

夜はSwitchのゲーム、ヒューマンリソースマシンを使ってモブプログラミング f:id:grooves:20171030223350j:plain

大正ロマンあふれる合宿所 f:id:grooves:20171030141651j:plain

朝昼晩、料理には全て刺し身が f:id:grooves:20171031120430j:plain

イカを狙う猫 f:id:grooves:20171031124714j:plain

海の反対側 f:id:grooves:20171031090008j:plain

f:id:grooves:20171031125231j:plain

海の青、空の青 f:id:grooves:20171031125756j:plain

旅館の前で f:id:grooves:20171031224119j:plain

最後まで写真をご覧になった方へ

私たちと働きませんか?興味ある方は気軽にご連絡ください。

jobs.forkwell.com

jobs.forkwell.com