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

Railsエンジニアの採用と教育について私とAiming（所属会社）が考えてやっている事のお話

Transcript

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