エンジニア転職2ヶ月目(2018/11)まとめ

エンジニアとして転職して2ヶ月が経ちました。

先月の終わりから社内ツール開発が本格的にスタートし、11月からRuby on Railsをガンガン書いています。他にもAWS、SendGridのAPIなど新しく触るものが多くあり飛ぶように過ぎた1ヶ月でした。

今月やったこと

1.社内ツール開発

Rails、API周り

先月はヒアリング、要件定義、ワイヤーフレームをしていたので、2週目くらいからコードを書き始めました。

使用しているのはVue.js、Ruby on Rails、jQueryですが、私が書いているのはRuby on RailsとjQueryのみです。

さらにメール機能が必要なのでSendGridの各種API(SMTP/Inbound Parse Webhook/Event Webhook)を使っています。メール機能の部分を全て担当することになりJSONやらAPIやらで苦しみました。

AWS

今回インフラ周辺はAWSを使うということで「Amazon Web Services 基礎からのネットワーク＆サーバー構築 改訂版」(日経BP社)を読みながら環境構築しました...

と言いたいところでしたが、私があまりにも手間取ったので、インスタンスやセキュリティグループの設定をしたところで「もうコード書き始めないと間に合わない」タイムリミットが来てしまいました。

環境構築は先輩にバトンタッチです。悔しいので勉強したはブログにまとめました。

- 新人エンジニアがAWSを触る前に知っておきたい基礎知識

- AWS　踏み台サーバー経由のSSH接続

思ったこと

コード書くの楽しいーー！！

11月の1週目はAWSを使うためにSSH接続やLinuxなど今までまったく勉強してこなかった部分を勉強しました。

インフラエンジニアでなくてもアプリのデプロイや設定のために最低限の知識は必要と頭では分かりつつも、フロントのように目に見える部分ではないので少し辛かったです。

その分Railsのコードを書く部分に入ってからは本当に楽しいです。

自分の書いたコードがアプリケーションの一部として日々積み重なっていくのが嬉しくて、初めて「エンジニアとして働けている」ことを実感しています(それを会社で口に出すのは完成させてからにしますが...)

初めてのチーム開発

私は入社以前は独学していたので、今回1年先輩のエンジニアと一緒に開発するのが初めてのチーム開発です。

先輩のコードは短くても分かりやすいので、どう書いたら良いだろう？と悩んだ時に参考にしたり、特に似たような動きをする部分は先輩の書き方に合わせて自分のコードを直すこともあります。

まだ「動く」コードを書くことに集中してしまいがちですが、読みやすさやサーバーへの負担も考えてこそ良いコードになると思うので「もっと良く出来ないだろうか？」という視点は大切にしなければいけないですね。

また、一緒に仕事をしているとコード以外でも「これいいな」と思う部分がたくさんありました。

例えば、先輩はよく使うコマンドやコード(CSSとか)は自分用のメモを作っているのでさっそく真似しました。

Railsのマイグレーションファイルの作成など調べればすぐに出てくるコマンドもどんどんメモしていますが、やっぱりこちらの方が毎回調べるよりスムーズです。GitHubも社内ルール(プルリク関連)とよく使うコマンドを一緒にまとめたらめちゃくちゃ便利!

もっと早くやればよかった。

もう一点いいな〜と思ったのは先輩がSassで基本色や基本パーツを変数などにまとめてくれていたこと。

フォントの色を変数から選び、基本パーツを@extendで継承しておけばアプリケーション全体のイメージが統一されます。もちろん時間短縮にもなる。

他の人の作業時間を減らす、複数人でコードを書いてもデザインに統一感を出す、コードを読みやすくする..など様々な面でメリットがあるし、チームで書くときにはこういう工夫がされるんだなと初めて知りました。

ちなみに先輩はデザインもできるエンジニアなので、元のCSSもしっかり見て書き方を学んでおかなければ...。

反省点

新人だからという理由で一歩引いてはいけない

実は開発スタート時、開発スケジュールの作成がされてませんでした。

タスクに分割して、工数振って、担当者を決める..までやって順番にタスクを潰す形で開発を進めていたのですが、これだともちろん進捗が進んでいるのか遅れているのかも分かりません。

正直疑問がまったく無かったわけではないのですが、こういうものかな〜と思いつつ実装に入っていました。そしてCTOに進捗を聞かれて、初めて「スケジュールが無いから遅れているかも分からない」状況がマズイと実感しました...。

先輩がやっているから正しい方法なのかな、と思ったのも良くなかったし、何より後から疑問を感じたのにそれを口に出さなかったのが一番良くなかったです。

私が働いている会社はスタートアップなのでエンジニアも多くないし、若い人が集まっています。

だからこそ新人とか年齢とか関係なく、出来ることは積極的にやって気づいた事は共有してフォローしあうことが必須です。

それを分かっていて自分でスタートアップを選んだのに、そこで一歩引いてしまっては今の会社を選んだ意味がないですよね。悪い意味で遠慮してしまったなと反省しました。

エンジニアの仕事はコードを書くだけじゃない

先程の「スケジュール作っていない」事故の後、すぐにスケジュールを作って先輩にも確認してもらい、今は時々自分と先輩の進捗を一緒に確認しています。

エンジニアの仕事はコードを書くだけではないと頭では分かっていましたが、実際にやってみると予想以上にコミュニケーションが大切だと感じています。

特に、チームでコードを書くならば

・自分とチームの進捗はまめに確認する

・自他問わず遅れそうと気づいたら確認、必要があればフォローしたり上の人に相談して解決を図る

が必要だと感じています。

あとは、当初予定していなかった機能を後からいくつか追加している(つまり仕様決定の時点で見落としている)ので、ここも次回の開発では改善が必要です...。リリース後に気づいたらちょっとマズイ部分もありました。

企画書を書いたときは要件定義にも関われてラッキー！と喜んでいましたが、さっそく当時の自分に苦しまされています。

まとめ

開発が本格的にスタートして楽しいですが、しんどい時もあります。

進捗がわりと普段のメンタルに影響するので、進捗悪いと夜寝る前に「明日は〇〇までやらなきゃ!」という気持ちで眠り、朝は「今日こそ〇〇実装したい!!やらなきゃ!!」という気持ちで起きています。

それでも機能を一つ追加する度に「自分できるじゃん!!」と嬉しくなるので、上がったり下がったりしつつも楽しんでいる感じです。

来月も頑張るぞ〜