冴えてるRailsエンジニアの育て方

by KUROKI Shinsuke

Embed

Start on current slide

Slide 1

Slide 1 text

冴えてるRailsエンジニアの育て方 2018/03/25 株式会社Aiming webエンジニア黒木慎介（なかま）

Slide 2

Slide 2 text

もくじ • 第0部：前置き – 自己紹介など • 第1部：採用編 • 第2部：育成編

Slide 3

Slide 3 text

もくじ • 第0部：前置き – 自己紹介など • 第1部：採用編 • 第2部：育成編

Slide 4

Slide 4 text

自己紹介 • Aimingのwebエンジニア（2011-） – 東京本社（2011-2015） – 大阪スタジオ（2015−） • Rails歴は8年くらい • 現在は新規開発中のプロジェクトでwebエンジニア班のリーダーをしています

Slide 5

Slide 5 text

提供（大阪からの交通費出してもらってます）

Slide 6

Slide 6 text

注意書き発表内容は個人の見解です、と言いたいところですが採用や育成は会社組織で行っていることなので、会社の方針と完全に切り離して語ることはできませんまた、同僚から影響を受けた内容も少なくありませんなので「個人の見解でない部分はそうとわかるようにお話する」とさせてください

Slide 7

Slide 7 text

本日の発表の意図 • 何か普遍的に使えるような知識を提供するとかではなく、あくまで事例発表 – あなたの回答は、あなたの状況を踏まえて自分で導き出すしかないと思います • 前提と行動をセットでお話するので、前提が同じなら試せることはあるかも • 「うちではこうしてる」という話でtwitterとかで盛り上がってくれると嬉しい – 私も聞きたい

Slide 8

Slide 8 text

前提：会社依存のもの • Aimingの開発・運営するタイトルの数は増え続けている – 開発を途中で打ち切る事は少ない • スマホの運営型ゲームのレッドオーシャン化 – 最初からあるべき機能の量が多い→リリースまでの工数の肥大化 • これらの理由で、web(Rails)エンジニアはほぼ常時ほしい状態

Slide 9

Slide 9 text

前提：転職市場 • Railsエンジニアの採用は難しい – 十分なスキルを持っている人はなかなか見つからない • 大阪でも難しい – コミュニティとかで見ている感じ、「Ruby使いたいけど仕事では使えてない」という感じの人が多く見えている

Slide 10

Slide 10 text

行動：（業務）経験者以外の採用 • 大阪スタジオに中途入社したwebエンジニアの約半数はRailsでの業務経験なし – PHP歴は長いとか – 別業種（Railsは趣味でやってた）とか

Slide 11

Slide 11 text

前置き終わり • 第0部：前置き – 自己紹介など • 第1部：採用編 – どうやって「入ってもらう」か • 第2部：育成編 – どうやって「モノになってもらう」か

Slide 12

Slide 12 text

ここから第1部 • 第0部：前置き – 自己紹介など • 第1部：採用編 – どうやって「入ってもらう」か • 第2部：育成編 – どうやって「モノになってもらう」か

Slide 13

Slide 13 text

第1部：採用編 • 応募してもらうまで • 書類審査 • 面接

Slide 14

Slide 14 text

第1部：採用編 • 応募してもらうまで • 書類審査 • 面接

Slide 15

Slide 15 text

応募してもらうまで • 「コミュニティへの露出をして採用に繋がらなくてもめげない」ことが大事だと思っています

Slide 16

Slide 16 text

前提：採用ルート • Aiming公式サイトからの応募 • 紹介会社さんからの紹介

Slide 17

Slide 17 text

前提：採用ルート • Aiming公式サイトからの応募 – 意欲が高い可能性が高く、マッチングしている可能性も高い – 数は少ない – 社員からの紹介、イベントなどでのつながり、過去の仕事の縁で、などを含む

Slide 18

Slide 18 text

前提：採用ルート • 紹介会社さんからの紹介 – 数がかなり多い – マッチングしているかどうかはバラバラ • 非エンジニアを何人か介するため、人材像がうまく伝わりにくい – 他社さんの選考が進んでいる場合が多く、その場合はスピードが求められる – 紹介料などで追加コストが発生する

Slide 19

Slide 19 text

前提：採用ルート • どちらのルートからの採用もある • 入社後の活躍度合いも明確に優劣ついてる感じではない • だが理想的には公式サイトからの直接の応募を増やしたい

Slide 20

Slide 20 text

行動：技術者コミュニティへの露出 • 採用に繋げることをかなり意識してます – Aimingのエンジニアリングについて知っている人を増やす • あんまりがっつかない • 職を探してる感じの人には「うちも採用やってます」という話はしておく – 私個人のスタンス • 目的は多いほうがモチベ上がるので • 社内にもいろんな考えの人がいます

Slide 21

Slide 21 text

行動：技術者コミュニティへの露出 • 発表できればGood – すごい技術の話であるとか、新奇性があるとかにこだらわない • 我々の常識は彼らの非常識 • 会話のきっかけづくり • 発表だけじゃない – スポンサー – 会場提供

Slide 22

Slide 22 text

露出をしても…… • そんなに簡単に応募につながるわけではない • めげそう • でもある日いい話があった

Slide 23

Slide 23 text

ある人との面接にて「紹介会社さんからの紹介ですが、うちを選んでくれた理由とかってありますか？」「前に関西Ruby会議でスポンサーしてたのを覚えてて、紹介リストにあったのを見て良いなと思って」

Slide 24

Slide 24 text

ポイントは２つ • 露出から応募（の意思決定）までには大きいタイムラグがある場合がある – 「関西Ruby会議でスポンサー」したのはこの面接の時点で既に2年前の話だった • 紹介会社さんからの紹介の場合でも、応募者の意思決定のタイミングがある – 先の例では紹介リストからの選択

Slide 25

Slide 25 text

なので • 結果にすぐつながらなくてもめげずに行きましょう

Slide 26

Slide 26 text

第1部：採用編 • 応募してもらうまで • 書類審査 • 面接

Slide 27

Slide 27 text

書類審査 • 「少しでも多く、その人の今のアウトプットを見るようにする」ようにしています – 状況によるのでいくつかやり方を用意しています – 面接にもつながります

Slide 28

Slide 28 text

書類審査 • その人が書いたコードを見るのが基本（会社の方針） – スキルを見る – 「興味がある」ならコード書いてるはずでしょ？ – 形式はgithubでもzipでも

Slide 29

Slide 29 text

コードじゃなくても • 技術力がわかるアウトプットを見る – Qiitaとかblogとか

Slide 30

Slide 30 text

それもなかったら？ • 基本的にはNG • …にしたいんだけど、そうも言ってられない程度に人がほしい状況もある • アウトプットがなくても、職務経歴からある程度戦力になってもらえる事を期待できる場合がある • ではその場合にどうするか

Slide 31

Slide 31 text

コーディング課題の提案 • お題を渡して、コードを書いてもらう • Rails経験者ならRails、そうでなければ任意の言語・フレームワークで • コードと、開発計画の予実を提出してもらう – 調べたことなども書いてもらう – 段取りの付け方や、未知の問題への取り組み方などを見る

Slide 32

Slide 32 text

課題も難しい場合 • 応募者がデスマとか • 課題をやってもらってるうちに他所に決まってしまうリスクが高い場合とか • 面接で評価する（後述）

Slide 33

Slide 33 text

コード評価の視点 • チームでの開発への適応力、その素質を見ている – 動作検証がし易い提出がされているか – オブジェクト指向（MVC、SOLIDなど）のコードが書けているか – インデントなどが雑でないか – 名前付けを考えているか – セキュリティを考慮しているか

Slide 34

Slide 34 text

他に書いてもらっているもの • スキルヒアリングシート – 技術要素に関して自己評価を段階で • ゲームプレイヒアリングシート – プレー経験と一言感想 • ともに会社の方針 – 採用ページからダウンロードできます • 面接でこれらのシートから質問することが多い

Slide 35

Slide 35 text

第1部：採用編 • 応募してもらうまで • 書類審査 • 面接

Slide 36

Slide 36 text

面接 • 人柄を見る→人柄って何さ？ • コミュニケーション能力を見る→コミュニケーション能力って何さ？ • エンジニア魂を見る • 技術力を見る

Slide 37

Slide 37 text

自分が見ている「人柄」 • 仕事に関係する何かの事について持っているテンションが高くあってほしい – それはコードを書くこととは限らなくてよい • 「仕事でテンションが上った瞬間は？」

Slide 38

Slide 38 text

「人柄」を問う設問 • 「仕事でテンションが上った瞬間は？」 – きれいなコードを書けた時 – 難しい問題を短時間で解決できた時 – 同僚に感謝された時 – 自分の作ったものが世間で良い評価を貰っていた時

Slide 39

Slide 39 text

「コミュニケーション能力」 • 重要度高い：説明力 – エンジニア間の問題点の共有 – コンテクストの異なる他職種の人と情報を適切に翻訳して意思疎通できるか • プランナー、デザイナー、運営、など – 「あなたがプレー経験のあるこのゲームについて、それを知らない私のために面白い点を説明してください」

Slide 40

Slide 40 text

「コミュニケーション能力」 • 重要度低い：愛想が良い – 相対的に重要度が低いというだけで、評価の対象でないわけではない – 攻撃的な言葉や態度はチームの生産性を下げる可能性がある • Teamwork OP

Slide 41

Slide 41 text

「エンジニア魂」を問う設問 • 「今まで読んだ技術書の中で最もライフチェンジングだったものは？」 – 私は「リファクタリング」です • 「Ruby（あるいは応募者が知っている言語）の良いところと悪いところ」 – 良いところだけではだめ • 「最近気になっている技術は？」 – 「それに関連して何か手を動かしましたか？」

Slide 42

Slide 42 text

提出してもらったコードから • 「ドヤ顔したいところは？」 • 「恥ずかしいところは？」 • 「あとn時間あったらどうしたい？」

Slide 43

Slide 43 text

技術面接 • コードを見れていない場合はここが重要 • 設計力・着眼点などを見る • ゲームプレイヒアリングシートから「あなたがこのゲームのシステムを実装するとしたらどういう構成にしますか？」 – ホワイトボードに書いてもらう – 「リスクになりそうなところはどこですか」などと掘り下げていく

Slide 44

Slide 44 text

技術面接 • 事前に課題を用意して置く場合もある – 実際に社内で起きたトラブルなどをモチーフに • コードを書いてもらったこともある – 開発環境の用意や適切な課題の用意など、難しいところが多い • このへんは皆さんの知見を伺いたいところ

Slide 45

Slide 45 text

ここから第2部 • 第0部：前置き – 自己紹介など • 第1部：採用編 – どうやって「入ってもらう」か • 第2部：育成編 – どうやって「モノになってもらう」か

Slide 46

Slide 46 text

第2部：育成編 • 入社してすぐ – パイロットプロジェクト • プロジェクト配属後 – コードレビュー – ペアプログラミング

Slide 47

Slide 47 text

第2部：育成編 • 入社してすぐ – パイロットプロジェクト • プロジェクト配属後 – コードレビュー – ペアプログラミング

Slide 48

Slide 48 text

入社してすぐ • Rails未経験者→Railsチュートリアルの写経から – 終わったらor並行して↓に移行 • Rails経験者→パイロットプロジェクト

Slide 49

Slide 49 text

パイロットプロジェクト • 会社or所属予定のプロジェクトで困っている事を何か1つ解決するものを作る – お題は入社までに募集・決定して渡す – プロダクトオーナーを立てる • 1週間スプリント✕4 • レビューは会社のwebエンジニアみんなでやる

Slide 50

Slide 50 text

第2部：育成編 • 入社してすぐ – パイロットプロジェクト • プロジェクト配属後 – コードレビュー – ペアプログラミング

Slide 51

Slide 51 text

コードレビュー • 「具体的にどう困るか」に落として言う • カッとなって本人のところに行く • 習熟を意識する • 褒める（過去発表「伝わるコードレビューのために」も見てもらえると良いです

Slide 52

Slide 52 text

「具体的にどう困るか」 • ふわっと「読みにくい」みたいな事を言っても、習熟度の低い人には伝わりにくい – 「Rubyっぽさ」「Railsっぽさ」「驚き最小」みたいなのがひっかかりやすい • 「ここはこういう風に書くとこういう事を気にせずに読めるので云々」

Slide 53

Slide 53 text

カッとなって本人のところに行く • 文字はナローバンド、直接の会話はブロードバンド • 文字だけで何往復もするより早い • ペアプロにもつながる

Slide 54

Slide 54 text

習熟を意識する • 人間が1つの事に対して行える思考の量には限界がある – 私はこれをMPと呼んでます • 同じことを考えたり意識するのにかかるMP は、繰り返すことにより低減していく • そうして余剰するようになるMPで新たに追加で考えることができるようになる • でもこの低減はすぐには起きない – 繰り返すことが必要

Slide 55

Slide 55 text

習熟を意識する • 相手の最大MP以上のことを教えても頭に入らないし、やってもらおうとしてもできない – ベテランは自分が消費MP少なくなってるので、その前提で考えがち • 低減が十分に進んでいない場合、前に言ったことをまた考えられず、同じミスをしてくる事がある • そういう状態なんだと思って、辛抱強くやるのが大事 • （学ぶ側としては素振りが大事みたいな話し）

Slide 56

Slide 56 text

褒める • 良くないことの指摘だけしてると雰囲気が悪くなってくる場合がある • 開発のテンション維持は大事 • フィードバックは正負両方有効 – 良い行動は強化したい • 前言った事ができるようになってたらそれはちゃんと言いたい

Slide 57

Slide 57 text

第2部：育成編 • 入社してすぐ – パイロットプロジェクト • プロジェクト配属後 – コードレビュー – ペアプログラミング

Slide 58

Slide 58 text

ペアプログラミング • ここで1つ、昔バイト先の張り紙で見た言葉を紹介させてください

Slide 59

Slide 59 text

• やってみせ

Slide 60

Slide 60 text

• やってみせ • 言って聞かせて

Slide 61

Slide 61 text

• やってみせ • 言って聞かせて • させてみて

Slide 62

Slide 62 text

• やってみせ • 言って聞かせて • させてみて • 褒めてやらねば

Slide 63

Slide 63 text

• やってみせ • 言って聞かせて • させてみて • 褒めてやらねば • 人は動かじ

Slide 64

Slide 64 text

五十六メソッド • やってみせ • 言って聞かせて • させてみて • 褒めてやらねば • 人は動かじ

Slide 65

Slide 65 text

ペアで作業をしよう • 五十六メソッドの実践としてのペアプログラミング – プログラミング以外でも応用可能 • 作業・思考の過程の共有 – 同じ情報からでも考えることが違っていたりするので、度々すりあわせていく

Slide 66

Slide 66 text

ペアプロの分量 • 入りたての時は1個の機能を作るまで100% ペアプロ • そのあとは毎日決まった時間にペアプロ – 1日に1-2時間程度やるとリズムができて良い • 苦手な人もいるので相手によって調整しましょう – ペアプロは「最初は苦手」な人も多いのでまずやってみようというのも大事

Slide 67

Slide 67 text

手離れを意識する • ここまで言ってきたことって大事だけどめっちゃコストかかる – 任せられることは任せましょう – 表明するのも大事 • 「今この人はどこまで任せて大丈夫になったか」を常に意識する – それで手厚さを強めたり弱めたりする – まずそうだったら一旦引き返したりもする

Slide 68

Slide 68 text

ここまで第2部 • 第0部：前置き – 自己紹介など • 第1部：採用編 – どうやって「入ってもらう」か • 第2部：育成編 – どうやって「モノになってもらう」か

Slide 69

Slide 69 text

おしまい • あくまで事例の紹介です • 自分の答えを自分で見つける必要がありますが、他の人の答えはヒントにはなる可能性があります • なので、私も「他の人の答え」を知りたいです – twitterなどで書いてくれると嬉しいです