Happy Elements株式会社カカリアスタジオ Advent Calendar 2016の17日目の記事です。
担当は「あんさんぶるスターズ！」グループの @kusakari です。

はじめに

Happy Elements株式会社では非常勤の学生エンジニアアルバイトも働いており、基本的に社員と同じ内容の業務に取り組んでもらっています。
ちなみに実際のエンジニアアルバイトの話は「1留したダメ人間が、学生エンジニアバイトとしてスマホゲーム会社で働いてみて思ったこと」でご覧頂けます（宣伝）。

入社試験

社長の新井¹による書類選考と面接があります。

この際、プログラミングが未経験である場合は、書籍を渡して勉強してもらった後で入社となります。
以前は「RailsによるアジャイルWebアプリケーション開発第4版」を渡していましたが、今はどの書籍なのでしょうか…²。ソーシャルゲームは、以前はウェブアプリだったものが、現在はネイティブアプリとなったので、UnityとRailsの書籍の二冊になったという話だったような気がします。

書籍で勉強

実は書籍を渡してもきちんと読んで再度連絡してくる人は割と少ないです。
プログラミングの基礎を勉強してもらいつつも、再度連絡があるかで、勤勉さも確認できるというわけです（たぶん）。

入社＆配属

どのチームに配属するは社長と各グループリーダーと相談して決まります。³

以下からは「あんさんぶるスターズ！」グループの場合です。

一番はじめにやること

「このQiita:Teamの記事を読みながら、開発環境構築をお願いします！」

支給されたPCに自分で開発環境を構築してもらいます。

今だとコマンド一発で構築できるようにすることも簡単で、そうしているグループもあると思うのですが、うちのグループではQiita:Teamの記事⁴を読みながら、自分で開発環境を構築してもらいます。

RailsやUnityと各種ミドルウェアなどを自分でインストールしてもらい、ローカル環境でアプリが動くところまで、基本的には一人で実施してもらいます。一応、メンターを指名して詰まったら相談できるようにはしています。この環境構築に早い人は1〜2時間、遅い人だと1週間程度かかることもあります。

尚、弊社ではアルバイトの試用期間が一ヶ月あり、戦力にならなそうな場合は試用期間で終了となります。採用となれば社員と同じやりがいのある仕事ができる反面、採用のハードルは他のアルバイトと比べると高いと思います。
試用期間については、初日に本当に終了になる場合もあるということを伝えて、後悔のないように頑張ってもらえるようにします。

環境構築は待ち時間も多いので、会社やチームのコーディングガイドラインや、チーム内の必読書としている「リーダブルコード」と「Team Geek」もこのくらいのタイミングで読んでもらうようにしています⁵。

環境構築できたら

「このIssueを割り当てたのでPull Request出してください！」

うちのグループではGitHub Issuesを使っているため、Issueを1つ割り当てて担当してもらいます。
Git、GitHubを使ったことない人、Pull Requestとは何かわからない人は自分で調べてもらいつつ、対応してもらいます。簡単に説明することはありますが、基本的に語句などを細かく教えることはありません。これはプログラマーという業務の性質上、わからないときに誰かに教えてもらうのではなく、自分で調べるという癖をつけて欲しいという理由からです。

また、最初のIssueは実際のアプリの動作とは関係のない、管理画面の機能を割り当てるようにしています。
こちらはいきなりユーザーデータを操作するようなプログラムは危険というのが最大の理由ですが、難易度的にも、まずは管理画面内の更新のない参照のみの画面で開発の流れになれていってもらうようにしています。同じ参照のみのプログラムでもユーザー画面は負荷対策なども含まれていて難易度が少し上がります。

Pull Requestが出せたら

レビュアーがコードレビューします。
こちらは今年8月くらい入社のアルバイトOくんの最初のPRです。このあたりのPRの出し方は前回の記事でも書きました。

このPRは最終的に15回ほどフィードバックがあった後、無事マージされました。
基本的に新しく入ったアルバイトのソースコードをレビューするレビュアーは（いろいろな方向性の指摘とならないように）一人に固定して、できるだけ丁寧にフィードバックするようにしています。

例えば、最初はスタイルガイドやRailsの流儀的な部分などで細かい指摘がたくさん入るのですが、最初にそのあたりになれてもらえば、少しずつ指摘が減っていき、比較的スムーズにいきやすいように感じています。
レビューでの指摘といえば、ActiveRecord関係では以下のようなソースコードが良くあるため、こういう部分をレビューする場合は、どこでSQLが発行されているかを聞いたりもしています。

@cards = Card.page(params[:page])
             .per(10)
             .order("id asc")
@cards = @cards.where(unit_id: unit_id) if unit_id
@cards.each do |card|
（省略）

ローカル環境だとアプリとデータベースが同じ筐体ですが、本番環境はもちろん別サーバーなので、プログラムのどこで何回通信が発生しているのかは、早い段階で理解してもらい意識して実装してもらうようにしています。

無事マージされたら

次のIssueを割り当てて対応していってもらいます。
管理画面が問題なくできるようになれば、ユーザー画面用のサーバーサイドプログラムや、クライアントサイドプログラムも対応してもらいます。

割り当て方のポイントとしては、その人がぎりぎりできる程度の難易度のタスクを継続して振ってあげることが大事だと思っていて、ある程度成長を実感させてあげられると良いと考えています。

あとはタスクを振る方のスタンスとしては、自分が作った方がうまく実装できるが、あえてチャレンジさせてみるというのが良いと思っています。そういう意味では自分が実装できない、あまりよくわかっていないものは基本的には振れないと考えた方が良いように思っています。
詰まって相談されても自分もゴールがわかっていないのでは、良い結果になる可能性は低いですし、非常勤アルバイトには、基本的にはゴールもそこへの道筋も明確なタスクを割り当てるのが良いと考えています。そういうこともあり、非常勤のアルバイトは新規アプリよりも運用中のアプリの方が向いていると思います。

おわりに

弊社の学生エンジニアは卒業生を含め非常に優秀な人が多いです（入社時はプログラミング未経験の人も！）。
そういう人たちにやりがいをもって取り組んでもらえる、成長が実感できる環境が用意できたら良いなと考えています。

Happy Elements株式会社カカリアスタジオではエンジニア社員、アルバイトを募集しています。こちらからご応募ください！

イラストについて

いらすとやさんのイラストを使わせて頂きました。ありがとうございます！

元エンジニアです。ここの画像よりだいぶ若いです（笑） ↩
僕はアルバイト採用には関わっていないため知りません。 ↩
画像はイメージで、実際は社員も全員私服です。 ↩
この記事自体もアルバイトが作ったものを更新していっています。 ↩
業務時間内に読んでもOKにしています。 ↩