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

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

現在製作中の社内ツールは12月中の完成の予定だったので、12月は期限も気にしつつ11月以上にドキドキしつつ働いていました。

今月やったこと

1. 社内ツール開発

Ruby on Rails

12月前半は11月に作ったメール機能にさらに機能を付け足していきました。

画像の添付、BCC、テンプレート機能など、普段のメールソフトでは当たり前のようについている機能ですが、自分で作ると実装方法の想像もつかず手探りで進む気持ちです。

それでも、自分で実装すれば自社での使い方に合わせてアレンジできるので嬉しいです。

今回は、ログインしたユーザーの署名を新規作成メール自動で挿入したり、誤送防止にBCCは社内担当者のアドレスのみを選択可能にしてみました。

機能のほんの一部でも、自分が考えた事が少しでも反映されると「やったー！」という気持ちになります。

ただ一方で、ユーザーが本当に必要としているか?限られた工数でその機能を今実装する必要はあるのか?という事は常に立ち止まって考える必要があります。

お仕事なので作ることが楽しい!で終わらせず、これで誰をどう手助けできるかという視点を持ち続けていたいと感じます。

Amazon S3

画像を保存するためにAmazon S3を使いました。

AWSは11月もめちゃめちゃ苦戦しましたが、今月も設定がうまく行かず、かなり工数使ってしまいました(バイトの子に教えてもらい解決)。

DBやデプロイ周りも同じなんですが、設定周りのファイルがとにかく読めない...。知識が足りなすぎて、何が間違っているのかも分からない、調べようにも何を調べたら良いのかが分からないことが多いです。場数を踏むしかないのか...。

Vue.js

社内ツールは基本的にRailsで、一部Vue.jsを使っています。Vue.jsの部分は先輩が書いてましたが、メールに関連する部分も一部Vue.jsで書くことになり12月後半はVue.jsも触りました。

独学していた時はReact.jsを書いていたので、dataやコンポーネントに関する考え方は割とすんなり入ってきましたが、実際に書くのは難しい...。React.jsよりもシンプルに書ける印象ですが、一方で先輩が書いたコードを読んでもすぐに意図が掴めない部分もあります。

「年明けからは本格的にVue.jsです！」とCTOから予告されているのでせっせと書かねば。

とりあえず年末年始は積んでたUdemyのVue.jsコースで勉強して、今は自分で小さなアプリケーション作っています。

2.社内イベント

忘年会

大学生の時も絶対に終電で帰る人だったので、この会社に入って初めて「飲んで終電逃して人の家に(突然)泊まる」という事をやらかしました。

とても楽しかったので他の人達が終電逃して遊ぶ理由がよく分かりました。20代後半になって結婚もしたのにこういう遊び方が許されるのは夫の理解があってこそ...ありがたや...。

でも突然人の家に泊まるのは迷惑なので止めるようにします。

納会

納会という言葉を初めて聞きました。この業界では割と使われるのかな？

感じたこと

自分が作ったサービスにもっと愛情を持つということ

そもそもサービスに対して愛情を持つって何という話ですが、

- そのサービスをずっと使ってもらいたい

- そのサービスをより良くしたい

という気持ちを持てるかという話だと思います。

これってとても大事なんだなということに先月初めて気づきました。

私が関わっている社内ツールはまだ開発中で、今は仕様書に書いてある機能をひとつひとつ実装していくことで必死です。

しかし、12月中旬に実際にサービスを使う担当者さんに画面を見てもらう機会があり、その時初めて「本当にこの人がサービスを使うんだな」とを実感しました(遅い..)。

完成させることがゴールのような気持ちがありましたが、本当は使われ始めてからがスタートです。そして、その時に浮かんだ疑問が「このサービス本当に使い続けてもらえるかな?」でした。

仕様書の機能を満たすようには作っているけど、欠けている部分がないだろうか。エラーが起きる可能性が高い部分が放置されてないだろうか。大きなエラーが起きて丸一日そのツールが使えなくなったら、担当者の人は今まで使っていたツールに戻るかもしれない..。

作ったら使ってもらえる、というのは大間違いだということを認識した途端に「使ってもらえなくなったらどうしよう」という不安が出てきました。

今月までは開発が主でしたが、リリース後は新しく機能を加えたりサービスを育てる段階に入ります。

この先、開発者である自分がサービスに愛情を持って「良くしていこう」という気持ちが無くなったら、いつの間にか使われなくなってしまうんだろうなと想像してしまいました。

この社内ツールは、私がエンジニアになって初めて関わったサービスになるので、今後も多くの人に使ってもらいたいです。

そのためには、開発者である私が一番「そのサービスをずっと使ってもらいたい」「そのサービスをより良くしたい」という気持ちを持ち続けて、サービスを気にかけ続けることが必要だなと感じました。

先月の記事で「新人だからと言って一歩引いていてはいけない」と書きましたが、先月から社内でも色々な事があって、このサービスについては自分が引っ張っていかなきゃという気持ちが求められることになりました。

まだ技術も知識も全然ですが、それを言い訳にせず、自分がこの立場に立ったからには必要な技術も知識はどんどん吸収するぞ!という前のめりな気持ちで行きます。

3ヶ月の振り返り

そういえば、転職した月に3ヶ月後の目標を決めていたので振り返ります。

仕事の流れを覚える

タスク確認→実装→プルリク→修正もしくは次のタスク

といった基本的な流れは何度も繰り返して慣れることができました。

しかし、スケジュール管理については、仕様書に無かった機能がどんどん追加になったので遅れてしまったり(仕様書での見落としが多かった)、逆に予想の半分くらいで完成した機能もあったり、スケジュールが結構ガバガバです。

スケジュールを立てるには「実装にはどれくらいの時間が必要なのか?」を知る必要があるかと思いますが、それを調べるところから毎回作業が始まるので難しい部分です。初めての作業ってみんなどうやってスケジュール立てるんだろう。

上手に相談できるようになる

私には「質問するのが苦手で自分の中で抱えてしまう」という悪い癖があるので、それを意識して治そう!と心がけていました。

その結果、3ヶ月前よりは困ったときに早めに助けが求められるようになったと思います。

- 今のチームに慣れた

- 自分が何をしようとしていて何が分からないか、を少し言語化できるようになった

ことでかなり心理的なハードルが下がりました。

一方で困ったのは「自分が調べていた事が全然違ったパターン」です。

欲しい機能を実装したい方法を調べる→○○の方法で出来る(かも)と分かる→詳細な方法を調べる→詰まる

の流れを踏んだ後に質問すると、「〇〇よりも□□の方がいいよ」と言われ、そもそも3,4番目のステップは不要だったということが何度かありました。

ここで難しいのは、単純にわからない時は「質問しよう」という気持ちになるのですが、「〇〇の方法で出来るかも」と思って調べている時はスムーズに進んでいる気分になっているので、なかなか質問に至らないんですよね。

時間を無駄にしないために、いくつか選択肢が出てきた時点で「〇〇の方法でやったことありますか?」と聞いてみたり、両方のやり方を調べた上で「〇〇と□□という方法があって違いは✕✕ですがどちらが良いでしょうか?」と相談するという手段があるかとは思います。

他のエンジニアさんで「こう質問している」というアドバイスがあればぜひ教えてください。

まとめ

先月までは「開発たのしー！！」な気持ちでやっていましたが、入社3ヶ月でそろそろ「たのしー！」だけで仕事していてはいけないという気持ちになりました。

もちろん楽しいという気持ちは大切ですが、自分が何をしてどう貢献できるのか?を考えて伝えて実行する段階が来るのかなと感じています。

いつまで「新人」なのかについては人によって異なると思うけど、自分で「新人」を言い訳のように使えるのはそんなに長くない...。