実務未経験プログラミングスクール出身者を採用したら最高だった
こんにちは。
サウナ好きしか入社できない会社「アサブロ」代表 & 東東京サウナ実験室室長の池田(@ikedanoda)です。
本日は「実務未経験プログラミングスクール卒エンジニア」についてのお話です。
実務未経験プログラミングスクール卒エンジニア
悲しいかな恐らくこの言葉を聞いてポジティブなイメージを浮かべる採用側の人はいないのではないでしょうか?
今回は最高だったシリーズ第二弾としてエンジニア採用業界で悪名高くなってしまった「実務未経験プログラミングスクール卒」をアサブロ社で採用した結果最高だったことについて振り返りも兼ねて記載します。
文末にアサブロ社エンジニア求人の情報へのリンクも掲載していますので、
・「実務未経験プログラミングスクール卒」で就職先が見つかっていないサウナ好きの方
・就職先がまだ見つかっていないサウナ好きの卒業生がいるプログラミングスクールを運営されている方
は是非御覧ください。
以下、採用した社員をMとします。
「実務未経験プログラミングスクール卒」で採用した社員の現在
採用が2019年3月頃でこの記事を書いている2021年1月時点で1年半ほど立っています。
自社の社員なので手前味噌ですがクライアントのウケが良く、また非常に高い評価を頂いております。
具体的には
・仕様考慮漏れのものに対するフォローや提案などが適切で結果、成果物に対してもPMとの想定アウトプットと齟齬なく喜ばれている
・その結果、仕様が複雑だったり難易度高めのタスク、各種施策に合わせて締め切りが厳しいタスクの依頼に最初に声がかかりやすい
といった状態です。
入社してから1年ちょっとくらいの段階でこのような状態になっていたと思います。
クライアントにMが「実務未経験プログラミングスクール卒」だったと伝えたら恐らくびっくりされると思います。
※ 多分伝わっていないはず。
ちなみに
・応募時のスキル自体が他の応募者と比べてめちゃくちゃ高かったわけではない
・通っていたスクールカリキュラムが特別優れていたわけではなさそう(実際にカリキュラムを見たわけではなく、同じプログラミングスクールに通っていた他の応募者のスキルを見る限りですが。)
ということは付け加えておきます。
※ 応募時に飛び抜けていたのはサウナ狂いだった点です。
なぜ実務未経験プログラミングスクール卒がこのように成長できたのか?
これはこの記事公開した後本人にも聞いてみたい点ですが、この記事では採用側目線で。
本人の資質が全てというとそれまでなのですが、振り返るとこれをやってよかったなーというポイントがありました。
大きくは
・採用選考時に行ったこと
・採用後の弊社の育成方針
です。
採用選考時に行ったこと
提出してもらったサービスに対してこちらから課題提示
応募時に自身で作ったサービスのURLとリポジトリURLを添えてもらっていたのですが、そのサービスに対して機能追加の要望を課題として提示しました。
例えば
・「カテゴリ」という概念をいれて、この画面のフォームで紐付けできるようにしてみてください
といった簡単なもの(だけどコピペしかできない人は対応できない)
・既存のロジックで処理がグチャっとしているところにヒントを与えてリファクタできるか?
・そのサービスで利用されていない鉄板のgemがあればそれを入れてサービスに取り入れてもらう
などなど。
極力実際の現場で有り得そうな形式でgithub issueの中身を書き、それに対してPRを投げて貰う形にしました。
それらを通じて
・コピペができないタスクに対応ができるか?
・現在知らないことに対しても調べて対応をしていけるか?
・タスクで不明点があった時の質問スキル
などをチェックしました。
ここで見たのはもちろん結果として上がってくるコード自体もなのですが、テキストコミニュケーションの質のチェックやテキストの温度感も見れたのがよかったな〜と思っています。
採用後の育成で気をつけたこと
当時は言語化うまくできていなかった(今もまだ怪しい・・)のですが、振り返るとこの辺意識していたな〜という点が以下です。
課題と期待されるアウトプットを見誤らないようにする
アサブロ社では基本タスクの発生から実装までは以下になっていると考えています。
1. 解決したい課題がある
2. 1を解決するための方法(機能だったり)を考える → タスク化
3. 2でタスク化されたものを実装で実現する
4. 3を満たした上で質の良いコードを書く
エンジニアにアサインされるのは2でタスク化された後が多いと思います。
この時に
・1の課題は何なのか?
・2のタスクの実装でちゃんと1の課題が解決されるのか? (他にコスパ良い方法があるのではないか?等の模索含む)
を徹底して意識してもらうようにしています。
僕はこの部分を見誤るといくら質の良いコードを書いたとしても意味が無いと考えています。
また3の実装のアウトプットが期待するものとずれないように
・タスクの実装にあたってタスク作成者との間で認識齟齬が生まれそうな箇所が無いか?
・タスクには記載がないが、決めなければいけないこぼれ落ちている仕様は無いか?
こちらも意識してもらい、適時タスク担当者とすり合わせをしてFIXしてから進めてもらうようにしています。
こちらに関して振り返るとコードを書くスキルももちろん気をつけて育成したのですが、他社と比べて特徴的だったかも?と思うのはこのようなPM的な視点を意識・強化させた点かなと思っています。
結果PMに寄り添い、サポートをしつつ実装できるようになったのが良かったと思っています。
タスクを小さく分割する
こちらはタスクの実装時に行ったことです。
最初は池田側でタスクを小さく分割して渡して、徐々にタスクを自身で細かく分割してもらうという形で行ってきました。
この狙いは大きくは以下です。
・1タスクを小さくすることで達成感(タスク消化数と比例しやすいと思っている)を感じてもらいやすくする
・タスクのゴールを小さく明確にすることで意図したものと違うアウトプットになることを避ける
・タスクのゴールが意図したものと違った場合も大きな手戻りになりにくくする
・コードレビューをしやすくする(コード差分も少なくなるのでレビュアーの負担減になる)
この「タスクを小さく分割する」ということについては育成側面以外にもメリットたくさんあったのですが、そこは長くなりそうなのでまた別記事にてまとめて書きたいな〜と思います。
ちなみに
内定から稼働開始までに外部の信頼できる会社に1~2ヶ月ほどのRailsトレーニングを行っていただきました。
※ 会社設立したてでリソース不足なのもあり。。。行っていただいた会社様には感謝・・・!
Mやもう一名のメンバーが育ってきたのもあり今後は稼働開始までのトレーニングは自社で行う想定です。
アサブロ社エンジニア募集開始します!
こういった成功体験がある & Mの育成を通して自信も持てたので今後もアサブロ社は積極的に実務未経験のエンジニアの採用窓口を用意していこうと思います。
そしてRailsエンジニアの募集開始しました!!
※ 枠1名の予定
この記事を見たサウナ好きの「実務未経験プログラミングスクール卒」の方いましたら是非以下の記事をご覧ください!
長文ご拝読ありがとうございました!
以下おまけです!
おまけ1: 前回採用時にお見送りした人
多かったのはコードがはっきりと分かるレベルでコピペベースだった人です。
※ その後のこちらからの課題タスクの実装が難しそうだなという判断でお見送りさせていただきました。
最初は僕もよくわからず見ていたのですが、複数人がほぼほぼ同じ構造や同一model名になっているコードを提出してきたので「ん?」となり調べたらRailsチュートリアルで使われているmodelがそのまま入っている、という状態でした。
作る過程でRailsチュートリアルで作ったものをコピーしてきて改変したのか、通っていたスクールのカリキュラムがそうなっているのかはわからないのですが、そのようなコードだった方はこちらからの課題提示前にお見送りとさせていただきました。
他には応募時に送ってもらうものが足りていない等、明らかに募集要項を読んでいないな?という方はお見送りさせていただきました。
現場のタスクは基本テキストベースで降りてくることが多いので、募集要項をちゃんと読んでいないという点からちょっと不安があったという背景です。
後は課題提示後にギブアップした方が数名いらっしゃいましたが、基本課題を消化してくれた方は面談までさせていただいたと記憶しております。
※ Mの採用が決まった時点で他の選考をストップさせていただいたというのはあり。
おまけ2:サウナ好き採用のメリット
M採用時の募集要項にはサウナ好き歓迎!くらいのノリで掲載していたのですがサウナ好きを雇えたことは本当に良かったな〜と思っています。
大きく
・共通の趣味・話題ができる
・肉体・精神ともにリフレッシュできる方法を手にしている
の2点かなと。
前者は会社への最初の溶け込みやその後の雑談などのコミニュケーションにおいてとても良く。
後者はサウナである必要ないのですが、こういったリフレッシュできる方法をわかっている人は仕事でちょっとつらいことがあっても立ち直りやすいのかな〜と思っています。
というわけで引き続きアサブロ社ではサウナ好きのみを採用していこうと考えています。
以上、おまけまでご拝読ありがとうございました!