20歳の18新卒がPerlエンジニアとして働くまで
この記事はミクシィグループ Advent Calendar 2018 16日目の記事です．
こんにちは．らりょす ( @raryosu ) です．
私は2018年4月にミクシィに新卒エンジニアとして入社し，minimoのサーバサイドエンジニアとして働いています．主にminimoのWeb版サービスの開発を担当しています．
この記事で書くこと
- ミクシィの新卒研修について
- Perlを書くようになるまでどのような教えを乞うてきたか
- どのような環境で仕事をしているか
この記事では書かないこと
- Perlという言語の良し悪し
- Perlの文法に関する細かいこと
※ なお，記事中に研修や配属の内容がありますが，それらはその年の新入社員の人数やレベル感，エンジニア組織の体制を鑑みて最適な方法やスケジュールを毎年検討しているため，必ずしも今後このような内容であるとは限りません⚠
さて，ここからは入社〜現在までにどんな教えを乞うてきたのか，どんなことをしてきたのかざっくりお話します．
ミクシィへの入社と入社時研修
私，1997年生まれの21歳で，入社当時は20歳でした．
入社時点でのプログラミングスキルはそう高くなくて，すでにあるコードを読むことはできる，なんとかちょっとだけPythonを書くことができる，というレベルでした．
オブジェクト指向だとか，MVCだとか，「ふ〜ん，なるほどね」程度の理解で，他人に満足に説明することができるレベルではなかった…といえばなんとなく私のレベル感は理解していただけるでしょうか．
高専卒業後，そのまま入社したので同期の中では最年少という環境でした．
さて，弊社の入社時研修は3週間に渡り，大きく3つの内容に分けられます．
- 会社・サービス・諸ルールの説明
- 職種別研修
- 社会人基礎合宿（1泊2日）
職種別研修は具体的には以下の内容でした（リンク先は，弊社オウンドメディア「ミクシル」や2017年の研修を紹介した記事です）．
これらの研修は「どの部署でも使える」ような実践的な知識・技術を網羅的に学べるような内容で，具体的な技術にフィーチャーした研修というよりは，重要となる概念や知識がベースとなっていました．
これまでふわっとした理解だった概念や，開発手法についてガッツリ教えてもらえてとても良い研修だったと思っています．
ちなみにこのときのデータベース研修の資料はスライド140枚程度なのですが，未だに見返すことがあります．業務を振り返りながら見ると更に理解が深まるのを感じています．
配属面談と配属決定と
配属先は何段階かの面談・アンケートを通じて決定されました．
- 弊社技術領域執行役員・人事との2on1
- 技術領域執行役員・人事の推薦および配属希望先のいくつかの部署のエンジニアとの面談
- 各部署とのマッチング度を自己評価するアンケート
- 技術領域執行役員・人事によって，各部署や本人からのアンケートを元に配属先を決定
私は「minimo」や「みてね」，「Find Job!」といったサービスのエンジニアと面談をさせていただいて，最終的に「minimo」への配属となりました．
配属先の希望は「Web系のサービスであること」「Webフロントエンドにも関わることができること」「エンジニアリングにこだわらない仕事をすることができること」という3点を軸としていて，今思うとminimoではその3点すべてを満たすことができていて，よいマッチング・配属をしてもらえたと思っています．
また，技術領域の執行役員との面談があったことも非常に良かったと感じています．普段自ら話しかける機会はなかなかないですし，このタイミングでお話できて，覚えていただけたのは大きなことでした．昨年までに新卒で入社された先輩方にも羨ましがられました(*1)．
*1 冒頭にも記載したとおり，配属の決定方法や研修内容は毎年アップデートされているので，今年の新卒と去年の新卒とでは方法が異なっていたようです．
私とPerlとコンテキスト
配属にまつわる余談ですが，minimoのエンジニアのマネージャ（いまの上長）と1度配属面談をしたあと，もう1度面談予定が入っていました．「前回なにか伝えきれないことがあったかな…」と不安になりながら面談が実施される会議室をノックしたら，マネージャに「Perlも少し書くんだけど大丈夫？」と聞かれ，「インターンでも書いたことがある(*2)から大丈夫！」と思い，「まったく問題ございません！」と元気よく回答しました．
*2: 18歳の夏にミクシィでインターンをしていた際にFind Job!で1ヶ月間Perlを書いていたことがあります．が，たかだか1ヶ月だったのでPerlのことは忘れてしまいました…．
そんなこんなで，minimoへの配属直後は先輩エンジニアに毎朝Perlについて語ってもらい，それに食らいついていました．
class->sub_module(hoge)と class::sub_module(class, hoge) の挙動が同一である（アロー演算子でサブルーチンを呼ぶ（メソッド呼び出し）とそのサブルーチンの第一引数にレシーバがセットされる）ということをSlackと口頭で説明してもらっていました．
Perlのスカラコンテキスト・リストコンテキストの話もガッツリ教えていただきました．
my @array = (0, 1, 2, 3);
my $arrayref = \@array;
for (@{$arrayref}) {
print "$_\n";
}配列はリストなので，スカラを期待しているところではバックスラッシュをつけてそのリファレンスを渡す．そして，それをリストとして扱いたいところではデリファレンスする…という形で，Perlを書くときにはコンテキストを（自然と）意識するということを教わりました．
最初の頃は，デリファレンスし忘れて期待通りに動作しないコードを量産していましたが，今となってはだいぶそういうミスも減ってきました．
いま実際に開発に関わりながら改めて当時の説明を読んだり，業務でコードを書くなかで「あのとき先輩が言ってたのはこういうことか」と理解することが多くあります．
最初からすべてを教えるわけではなく，形だけ教わる，そして実際に業務をしながら理解を深めていくというやりかたはとてもやりやすいと感じています．
業務
minimoではWeb版サービスのエンジニアとして働いています．入社してからこれまでたくさんのものを作ってきました．以下は大きい施策の例です．
これらは「これやっといて」という感じで依頼が来るわけではなく，「これやりませんか？」とか「こういう施策はどうでしょうか」という提案・相談ベースで進んでいきます．
というのも，Web版サービスをメインで担当するチームは4人程度で，そのうちエンジニアは私一人なので，自分で「その施策を実施することが可能か」「どの程度の工数がかかって，それに見合った効果が出るのか」を判断しなければなりません（当然アプリなどを担当しているサーバサイドエンジニアにも相談をしますが）．
そういう意味ではプレッシャーのある環境(*3)なので「できる・できない」ではなく「やる・やらない」という選択肢のみを自分に与えられて，やると決めたら必死に勉強して手を動かしてレビューしてもらってリリースするしかありません．
*3 minimoのWeb版サービスを作るエンジニアとしてのプレッシャーはありますが，職場自体はすごく和気あいあいとしているし，プレッシャーをかけられることは基本的にはありません．サーバエンジニアは全員席が近いのでよく雑談しています．なぜかキルヒホッフの法則の話題で盛り上がったこともあります．
まとめ
私は入社してから「エンジニアとして必要な知識」「Perlの文法」を学び，「責任をもって仕事を任せてもらえる環境」を作ってもらいました．
「とりあえず自走できる環境」を整えてもらった（というより，「自走しなければならない環境」かも？）ので，あとは適宜必要となる知識を補給したりだとか，周りのエンジニアに助けを求めることで，なんとか一人のエンジニアとして仕事をすることができていると思っています．
キャッチーなタイトルにしようと思って「20歳の18新卒がPerlエンジニアとして〜」とか書いちゃいましたが，Perlだろうとなんだろうと，同じような方法で成長することができるのではないかと思っています．
次の私のステップは，知識や技術の幅を広げていくことだと思っています．業務でたくさんのことを経験して，個人的にもたくさんのことを勉強して，何らかのアウトプットをどんどん増やしていきます💪
明日は Kaki_Shoichi さんがElixerについて書いてくださるようです！
余談ですが入社前に Kaki_Shoichi さんの記事を読んだことがあることを思い出しました．
