Railsエンジニアの採用と教育について私とAiming（所属会社）が考えてやっている事のお話
冴えてるRailsエンジニアの育て方2018/03/25株式会社Aiming webエンジニア黒木慎介（なかま）
View Slide
もくじ• 第0部：前置き– 自己紹介など• 第1部：採用編• 第2部：育成編
自己紹介• Aimingのwebエンジニア（2011-）– 東京本社（2011-2015）– 大阪スタジオ（2015−）• Rails歴は8年くらい• 現在は新規開発中のプロジェクトでwebエンジニア班のリーダーをしています
提供（大阪からの交通費出してもらってます）
注意書き発表内容は個人の見解です、と言いたいところですが採用や育成は会社組織で行っていることなので、会社の方針と完全に切り離して語ることはできませんまた、同僚から影響を受けた内容も少なくありませんなので「個人の見解でない部分はそうとわかるようにお話する」とさせてください
本日の発表の意図• 何か普遍的に使えるような知識を提供するとかではなく、あくまで事例発表– あなたの回答は、あなたの状況を踏まえて自分で導き出すしかないと思います• 前提と行動をセットでお話するので、前提が同じなら試せることはあるかも• 「うちではこうしてる」という話でtwitterとかで盛り上がってくれると嬉しい– 私も聞きたい
前提：会社依存のもの• Aimingの開発・運営するタイトルの数は増え続けている– 開発を途中で打ち切る事は少ない• スマホの運営型ゲームのレッドオーシャン化– 最初からあるべき機能の量が多い→リリースまでの工数の肥大化• これらの理由で、web(Rails)エンジニアはほぼ常時ほしい状態
前提：転職市場• Railsエンジニアの採用は難しい– 十分なスキルを持っている人はなかなか見つからない• 大阪でも難しい– コミュニティとかで見ている感じ、「Ruby使いたいけど仕事では使えてない」という感じの人が多く見えている
行動：（業務）経験者以外の採用• 大阪スタジオに中途入社したwebエンジニアの約半数はRailsでの業務経験なし– PHP歴は長いとか– 別業種（Railsは趣味でやってた）とか
前置き終わり• 第0部：前置き– 自己紹介など• 第1部：採用編– どうやって「入ってもらう」か• 第2部：育成編– どうやって「モノになってもらう」か
ここから第1部• 第0部：前置き– 自己紹介など• 第1部：採用編– どうやって「入ってもらう」か• 第2部：育成編– どうやって「モノになってもらう」か
第1部：採用編• 応募してもらうまで• 書類審査• 面接
応募してもらうまで• 「コミュニティへの露出をして採用に繋がらなくてもめげない」ことが大事だと思っています
前提：採用ルート• Aiming公式サイトからの応募• 紹介会社さんからの紹介
前提：採用ルート• Aiming公式サイトからの応募– 意欲が高い可能性が高く、マッチングしている可能性も高い– 数は少ない– 社員からの紹介、イベントなどでのつながり、過去の仕事の縁で、などを含む
前提：採用ルート• 紹介会社さんからの紹介– 数がかなり多い– マッチングしているかどうかはバラバラ• 非エンジニアを何人か介するため、人材像がうまく伝わりにくい– 他社さんの選考が進んでいる場合が多く、その場合はスピードが求められる– 紹介料などで追加コストが発生する
前提：採用ルート• どちらのルートからの採用もある• 入社後の活躍度合いも明確に優劣ついてる感じではない• だが理想的には公式サイトからの直接の応募を増やしたい
行動：技術者コミュニティへの露出• 採用に繋げることをかなり意識してます– Aimingのエンジニアリングについて知っている人を増やす• あんまりがっつかない• 職を探してる感じの人には「うちも採用やってます」という話はしておく– 私個人のスタンス• 目的は多いほうがモチベ上がるので• 社内にもいろんな考えの人がいます
行動：技術者コミュニティへの露出• 発表できればGood– すごい技術の話であるとか、新奇性があるとかにこだらわない• 我々の常識は彼らの非常識• 会話のきっかけづくり• 発表だけじゃない– スポンサー– 会場提供
露出をしても……• そんなに簡単に応募につながるわけではない• めげそう• でもある日いい話があった
ある人との面接にて「紹介会社さんからの紹介ですが、うちを選んでくれた理由とかってありますか？」「前に関西Ruby会議でスポンサーしてたのを覚えてて、紹介リストにあったのを見て良いなと思って」
ポイントは２つ• 露出から応募（の意思決定）までには大きいタイムラグがある場合がある– 「関西Ruby会議でスポンサー」したのはこの面接の時点で既に2年前の話だった• 紹介会社さんからの紹介の場合でも、応募者の意思決定のタイミングがある– 先の例では紹介リストからの選択
なので• 結果にすぐつながらなくてもめげずに行きましょう
書類審査• 「少しでも多く、その人の今のアウトプットを見るようにする」ようにしています– 状況によるのでいくつかやり方を用意しています– 面接にもつながります
書類審査• その人が書いたコードを見るのが基本（会社の方針）– スキルを見る– 「興味がある」ならコード書いてるはずでしょ？– 形式はgithubでもzipでも
コードじゃなくても• 技術力がわかるアウトプットを見る– Qiitaとかblogとか
それもなかったら？• 基本的にはNG• …にしたいんだけど、そうも言ってられない程度に人がほしい状況もある• アウトプットがなくても、職務経歴からある程度戦力になってもらえる事を期待できる場合がある• ではその場合にどうするか
コーディング課題の提案• お題を渡して、コードを書いてもらう• Rails経験者ならRails、そうでなければ任意の言語・フレームワークで• コードと、開発計画の予実を提出してもらう– 調べたことなども書いてもらう– 段取りの付け方や、未知の問題への取り組み方などを見る
課題も難しい場合• 応募者がデスマとか• 課題をやってもらってるうちに他所に決まってしまうリスクが高い場合とか• 面接で評価する（後述）
コード評価の視点• チームでの開発への適応力、その素質を見ている– 動作検証がし易い提出がされているか– オブジェクト指向（MVC、SOLIDなど）のコードが書けているか– インデントなどが雑でないか– 名前付けを考えているか– セキュリティを考慮しているか
他に書いてもらっているもの• スキルヒアリングシート– 技術要素に関して自己評価を段階で• ゲームプレイヒアリングシート– プレー経験と一言感想• ともに会社の方針– 採用ページからダウンロードできます• 面接でこれらのシートから質問することが多い
面接• 人柄を見る→人柄って何さ？• コミュニケーション能力を見る→コミュニケーション能力って何さ？• エンジニア魂を見る• 技術力を見る
自分が見ている「人柄」• 仕事に関係する何かの事について持っているテンションが高くあってほしい– それはコードを書くこととは限らなくてよい• 「仕事でテンションが上った瞬間は？」
「人柄」を問う設問• 「仕事でテンションが上った瞬間は？」– きれいなコードを書けた時– 難しい問題を短時間で解決できた時– 同僚に感謝された時– 自分の作ったものが世間で良い評価を貰っていた時
「コミュニケーション能力」• 重要度高い：説明力– エンジニア間の問題点の共有– コンテクストの異なる他職種の人と情報を適切に翻訳して意思疎通できるか• プランナー、デザイナー、運営、など– 「あなたがプレー経験のあるこのゲームについて、それを知らない私のために面白い点を説明してください」
「コミュニケーション能力」• 重要度低い：愛想が良い– 相対的に重要度が低いというだけで、評価の対象でないわけではない– 攻撃的な言葉や態度はチームの生産性を下げる可能性がある• Teamwork OP
「エンジニア魂」を問う設問• 「今まで読んだ技術書の中で最もライフチェンジングだったものは？」– 私は「リファクタリング」です• 「Ruby（あるいは応募者が知っている言語）の良いところと悪いところ」– 良いところだけではだめ• 「最近気になっている技術は？」– 「それに関連して何か手を動かしましたか？」
提出してもらったコードから• 「ドヤ顔したいところは？」• 「恥ずかしいところは？」• 「あとn時間あったらどうしたい？」
技術面接• コードを見れていない場合はここが重要• 設計力・着眼点などを見る• ゲームプレイヒアリングシートから「あなたがこのゲームのシステムを実装するとしたらどういう構成にしますか？」– ホワイトボードに書いてもらう– 「リスクになりそうなところはどこですか」などと掘り下げていく
技術面接• 事前に課題を用意して置く場合もある– 実際に社内で起きたトラブルなどをモチーフに• コードを書いてもらったこともある– 開発環境の用意や適切な課題の用意など、難しいところが多い• このへんは皆さんの知見を伺いたいところ
ここから第2部• 第0部：前置き– 自己紹介など• 第1部：採用編– どうやって「入ってもらう」か• 第2部：育成編– どうやって「モノになってもらう」か
第2部：育成編• 入社してすぐ– パイロットプロジェクト• プロジェクト配属後– コードレビュー– ペアプログラミング
入社してすぐ• Rails未経験者→Railsチュートリアルの写経から– 終わったらor並行して↓に移行• Rails経験者→パイロットプロジェクト
パイロットプロジェクト• 会社or所属予定のプロジェクトで困っている事を何か1つ解決するものを作る– お題は入社までに募集・決定して渡す– プロダクトオーナーを立てる• 1週間スプリント✕4• レビューは会社のwebエンジニアみんなでやる
コードレビュー• 「具体的にどう困るか」に落として言う• カッとなって本人のところに行く• 習熟を意識する• 褒める（過去発表「伝わるコードレビューのために」も見てもらえると良いです
「具体的にどう困るか」• ふわっと「読みにくい」みたいな事を言っても、習熟度の低い人には伝わりにくい– 「Rubyっぽさ」「Railsっぽさ」「驚き最小」みたいなのがひっかかりやすい• 「ここはこういう風に書くとこういう事を気にせずに読めるので云々」
カッとなって本人のところに行く• 文字はナローバンド、直接の会話はブロードバンド• 文字だけで何往復もするより早い• ペアプロにもつながる
習熟を意識する• 人間が1つの事に対して行える思考の量には限界がある– 私はこれをMPと呼んでます• 同じことを考えたり意識するのにかかるMPは、繰り返すことにより低減していく• そうして余剰するようになるMPで新たに追加で考えることができるようになる• でもこの低減はすぐには起きない– 繰り返すことが必要
習熟を意識する• 相手の最大MP以上のことを教えても頭に入らないし、やってもらおうとしてもできない– ベテランは自分が消費MP少なくなってるので、その前提で考えがち• 低減が十分に進んでいない場合、前に言ったことをまた考えられず、同じミスをしてくる事がある• そういう状態なんだと思って、辛抱強くやるのが大事• （学ぶ側としては素振りが大事みたいな話し）
褒める• 良くないことの指摘だけしてると雰囲気が悪くなってくる場合がある• 開発のテンション維持は大事• フィードバックは正負両方有効– 良い行動は強化したい• 前言った事ができるようになってたらそれはちゃんと言いたい
ペアプログラミング• ここで1つ、昔バイト先の張り紙で見た言葉を紹介させてください
• やってみせ
• やってみせ• 言って聞かせて
• やってみせ• 言って聞かせて• させてみて
• やってみせ• 言って聞かせて• させてみて• 褒めてやらねば
• やってみせ• 言って聞かせて• させてみて• 褒めてやらねば• 人は動かじ
五十六メソッド• やってみせ• 言って聞かせて• させてみて• 褒めてやらねば• 人は動かじ
ペアで作業をしよう• 五十六メソッドの実践としてのペアプログラミング– プログラミング以外でも応用可能• 作業・思考の過程の共有– 同じ情報からでも考えることが違っていたりするので、度々すりあわせていく
ペアプロの分量• 入りたての時は1個の機能を作るまで100%ペアプロ• そのあとは毎日決まった時間にペアプロ– 1日に1-2時間程度やるとリズムができて良い• 苦手な人もいるので相手によって調整しましょう– ペアプロは「最初は苦手」な人も多いのでまずやってみようというのも大事
手離れを意識する• ここまで言ってきたことって大事だけどめっちゃコストかかる– 任せられることは任せましょう– 表明するのも大事• 「今この人はどこまで任せて大丈夫になったか」を常に意識する– それで手厚さを強めたり弱めたりする– まずそうだったら一旦引き返したりもする
ここまで第2部• 第0部：前置き– 自己紹介など• 第1部：採用編– どうやって「入ってもらう」か• 第2部：育成編– どうやって「モノになってもらう」か
おしまい• あくまで事例の紹介です• 自分の答えを自分で見つける必要がありますが、他の人の答えはヒントにはなる可能性があります• なので、私も「他の人の答え」を知りたいです– twitterなどで書いてくれると嬉しいです
skuroki
dalinaum
fornewid
pyama86
ivargrimstad
shinmiy
masatoshiitoh
77web
nsuz
yui_knk
umizaru
syumai
ryu_hu03
danielanewman
reverentgeek
morganepeng
michaelherold
smashingmag
lara
chrisshort
vanstee
chriscoyier
samlambert
62gerente
skipperchong