お久しぶりです。
21卒のエンジニアはもう入社して１年と３ヶ月経ちましたでしょうか。
いろんな場所で「入社して１年経って思ったこと」みたいな記事を見かけますが、完全に乗り遅れたけど僕も何かしら残しておきたいので「チームに配属されてから１年」ということで記事を書く理由とさせていただきます。
座談会などで色々アライドの事情を知ることはできると思いますが、新卒のエンジニアがどんな１年を過ごしていたのかというのはやはり時間の都合上全てを語ることはできないと思うので参考資料の１つとしてみていただければと思います。
ちなみに僕の大学は生物系の学部で、卒論は脳神経科学について書きました。なので内定が出た時点ではHTMLとCSSしか知らなくてJavaScriptなんて書いたことなかったです。なのでおそらく座談会にいらっしゃる就活生よりもスタートは遅いと思います。
研修内容に関しては既に同期の子が記事を書いているので書きません。
業務に関してアライドは手を挙げればいくらでも新しい事に挑戦することができるので共通の業務と僕しか行っていない業務？があります。
個人的にこの文化が一番好きな文化であり、僕がアライドで働いている理由です。
運用業務について（共通）
まず、配属されてから１年経つまでずっと運用を担当をしています。といっても運用だけをしているわけではなく、その他にもいろいろやっているのですが、やはり配属されてすぐやることと言えば運用業務なのかなとも思うのでこれから始めます。
letroに慣れる
初めは「letroを使って投稿を表示してみる」といったような簡単なチケットから始まりました。（タスクは基本チケットという単位で管理されていて、１つのタスクや質問に対して１チケットというような感じです。）
プレビュー作成
そしてその後に営業の方達が商談に使用するプレビューの作成というチケットの対応が追加されました。プレビューというのは実際にお客さんのページでletroを使用した時にどんなふうに表示されるのかを見せるためのもので、letroを使用して作成するので「letroの操作に慣れている」ことと表示を調整するためにCSSを書くことがあるので「CSSが書ける」という状態が求められます。
質問対応
これは実際に使用されているお客様がアライドのカスタマーサクセスに対して質問をされた場合に、技術的な質問に対する回答をエンジニアがサポートするという内容です。このチケットでは「letroの仕様を理解している」という状態が求められます。この場合の「仕様」というのは操作方法ではなく、裏側でどういった処理を行なっているかという解像度での理解が必要です。
トラブル対応
これはバグや設定ミスなどが発生した時に何が原因なのか、またどうすれば直るのかを調査するといったチケットです。ここでは上と同じように「letroの仕様を理解している」という状態が求められます。個人的には質問対応もトラブル対応も必要とされる知識・経験は同じだと思っています。
セキュリティ的にエンジニアが行った方がいい操作をする
これはsshでサーバーに接続して処理を実行したりデータの集計を行ったりなど、いろいろありますが、求められる技術は主にSQLかなと思います。もちろんですが、データベースの設計を理解しておく必要はあります。
最初のものは一時的なものなので除外しますが、１年を通してみると４種類しか運用業務はありません。なので運用業務だけを行っていると１日に８時間を消費するのは難しいです。
開発（共通）
なので、ある程度コードの理解ができるようになると開発タスクのチケットを振られるようになります。開発では管理画面（お客さんが触らない場所）の開発を行っていました。チケットの期限は結構長めに設定されていて最初は３週間とかだった気がします。
開発ではLaravelとVueを書く能力が求められます。フロントエンドエンジニアもいるのですが、新卒はバックエンドもフロントも両方書けるという状態です。個人的に仕事が細かく分かれているよりは両方できた方が進みが速いので嬉しいなと思います。
もちろんですが、リーダブルなコードを書くことも求められます。
そのほかにもRedashというツールでデータを表示するためのSQLを書いたり、Jenkinsで使うシェルスクリプトを書いたりしました。これは開発というのかわかりませんが、一応書いておきます。でも最近はJenkinsは使っていません。
KAIZEN（共通？）
これは今後配属される子たちも行うことになる業務かはわかりませんが、letroに配属された２人はKAIZENチームというチームにも属しています。
KAIZENチームではカスタマーサクセスの方達が提案する「もっとこうだったらいいのに」という機能を開発するという流れと、KAIZENチーム自体が「こうしたほうがいいんじゃないか」という感じで開発する流れがあります。
既にリリースされた機能に対して「この仕様は良くないでしょ」というような会話からすぐに改善の開発を行なったりという感じで、おそらく一番スピード感のあるチームだと思います。
どれくらいの速度感かというと、議論の次の日にMRを上げているということもあります。
チームの全員が議論に参加していて全員が開発を行える技術を持っているのでかなりイケてます。
ちなみにKAIZENチームはもともとあったわけではなく、僕がletroに配属された後に立ち上がったチームです。
業務効率化（共通？）
これもすでに効率化された業務をさらに効率化することはあまりないと思うので共通ではないのですが、運用業務のなかで「これエンジニアがやる仕事か？！」と思う業務を自動化したり効率化したりしています。
運用を担当している方はおそらく一度は思ったことがあるであろう「これエンジニアの仕事か？」ですが、人的リソースや知識の差の問題でどうしてもエンジニアがやらなくてはいけなくなってしまっている業務はあると思います。
そしてその業務のほとんどに対して「これエンジニアじゃなくても（誰でも）できるだろ」と思ってしまいます。
僕らはそんな業務を自動化したり効率化してます。
人的リソースの問題でエンジニアが行うことになっている単純作業に関しては自動化のアプローチが取れて、知識の差が問題でエンジニアが行うことになっている作業に関してはドキュメントや操作の単純化（APIや社内ツールの作成）によって効率化のアプローチが取れると思っています。
そして、できるだけ単純作業に時間を使うのではなくクリエイティブなことや自分のスキルを高めるために時間を使って欲しいと思っているのでこの業務？は個人的に力を入れています。
この対象はエンジニアのみではなく、営業やカスタマーサクセスの方たちも同様に会社全体で見たら単純作業をさせるには惜しい存在なのでどんどん効率化していきたいなとおもいます。
これができるのは開発でバックエンドもフロントエンドも書けるようになっていたおかげかなと思います。
まとめ
こんな感じでしょうか。エンジニア未経験で入社した上にアライドでしか働いたことがないので他社と比較することはできないのですが、成長する機会はかなりある方なのかなと思います。
アライドに入っていれば成長できるわけではありませんが、成長しようと思えば応援してくれるといった感じです。
僕は４年間塾講師をしていたので成長については自分なりの結論を持っているのですが、一言で言うと「成長する気がある子は放っておいても成長する」です。
逆に言えば「成長しようとしない子は成長させようとしても成長しない」だと思っています。
なのでどちらかというと放任主義なのですが、アライドも成長を強要することがないのでとても働きやすいなと思います。
（おまけ）プライベートと仕事とのつながり
ここでは、よく聞く「エンジニアは休日も勉強するべきか」という話題について話していこうと思います。
個人的にこの話って立場が上に行くほど話しづらくなると思うので今のうちに書いておこうと思います。
結論から言うと「自分が決めるべき」だと思います。
なんだよと思うかもしれませんが、僕は自分の成長について他人の意見で左右されるなら、そこまで本気で考えていないんだと思います。
もちろん成長したいなら人に訊く前にやるべきだと思います。
ですが、特に勉強しなくてもそのスキルに合った仕事が振られるので困らないとは思います。
なぜなら、簡単な業務をこなしていく中でその業務に関する知識は習得できるので、「１年経っても何もできない」ということにはならないからです。
さらに、チケットの難易度もその人の能力に対して適切にレベルアップしていくので確実に成長することはできると思います。
（成長速度は速くないと思いますが。）
個人的にはUdemyで動画をみて実際に作ってみたり、技術書を読んでみたりしましたが、業務で使用しているツールや技術について予習しているのとしていないのではキャッチアップの速度は全く違うなと思います。
また、自分で学習していると、実際に業務でその技術を使用する際に「ああこういうことだったのか」というような、１周目では気づかないようなことも気付くことができました。なので業務でのアウトプットの質も自然と高いものになると思います。
研修時には「なんとなくこう書いておけば動くだろう」とか「動いてるけどなんでかわからない」という状態でしたが、僕がその時の目標としていた「こういう処理をしたいからこう書く」や「このコードにはこういう意図がある」というような段階までこれたと思っています。
それも休日に個人開発を行っているからかなとは思います。
もしかしたらしていなくてもなっていた可能性もありますが、一人じゃ対照実験をすることができないので何とも言えないですね。
最近あった「勉強していてよかった」ということは、最近開発しているチームのアーキテクチャが大きく変わっているのですが、ゴールデンウィークくらいに『エリック・エヴァンスのドメイン駆動設計』を読んでいたので、「進研ゼミで見たことある！」となり、すぐに対応できたことです。
そして個人的に考えていたアーキテクチャよりも綺麗な構成だったので「やっぱCTOすげえ」となりました。
レベルが違いすぎる人って何がすごいか逆にわからないということがあると思うのですが、その人の凄さがわかるようになるというのも成長の証だと思っています。
設計とかは個人開発でしかしたことないので完全に趣味程度に思っていたのですが、意外と役に立ってよかったです。
こんな感じで、思いがけず「勉強しておいてよかった」ということがあるので、緩くですが、今後も勉強は続けていきたいと思います。
2021年新卒入社。letroの開発・運用業務を担当しています。
