Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

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

C94b14a077358ef2706819c62063bbc2?s=128

KUROKI Shinsuke

March 25, 2018
Tweet

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. ポイントは2つ • 露出から応募(の意思決定)までには大きい タイムラグがある場合がある – 「関西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などで書いてくれると嬉しいです