私事ではあるのですが、社内異動によって4月から職場環境が変わりました。
職種自体はエンジニアのままではあるのですが、
前の部署 Web系(JavaScript) → 今の部署 iOSアプリがメイン
となり、同じ会社とはいえ業務内容がガラリと変わりました。

異動してから4ヶ月が経ち、新しい環境にもすこーしずつ慣れてきました。
その「慣れる」にあたっての考え方や姿勢について改めて感じることがあったのでこの記事ではそれを書き留めようと思います。

戦力になれてない感に負けない

いきなり当たり前の話ですが異動直後は何も分からず、マジで無力です。
インプットの量が多く、聞いたことをたまに忘れて同じことを2回聞いちゃったり、
しょうもないミスをしたり、
いざアウトプットを出してもすごい小さかったり、
「やばいおれ全然戦力になってない」感がすごいです。

たとえそうなっても悲観せず

新しい知識は貪欲に学びにいく
地味で小さい仕事でも自分でできそうなものは取りに行く

これを繰り返して少しずつ自分の存在感を上げていきます。
しんどいときは気持ちの持ち方次第で結構変わってくるものです。

実際今もそこまで戦力になってる感はないのですが、とりあえず↑の２つを今後も続けられるように頑張っていきます。

(なんか当たり前のことを言ってるだけだ)

GitHub見よう

今日ではソースコード管理にGitHubを利用している企業はとても多いと思います。
「ここを直したいとき、どのファイルのどの辺りを修正すればいいか」を把握するにはGitHubのプルリクエストを見るのが最も手っ取り早いと感じました。これに加えてレビューの雰囲気とかも掴めます。
時間の余裕があればソースコードを一から読むのが最も確実ですが、自分の案件をこなすことも必要になってくる以上、プロダクトの作りを効率的に把握しましょう。

アウトプットはできるだけ細かく

↑で書いたように過去のプルリクエストを見ることでシステム構成をある程度把握することができますが
やっぱり最初の頃は「た、たぶんこれで合ってるはず・・・！」となってしまうことが多いです。
そこを確実にレビューしてもらうために、プルリクエストを出す際はできるだけ粒度を細かくしましょう。
一つのPRの差分が大きいと、本来間違ってしまっている箇所を見逃されてしまう可能性が上がってしまいます。
※PRを投げる前に口頭等で有識者に確認することもアリですが、今後自分以外に新しく入ってきた人がそのPRを見たときに気付けるように間違いの指摘もPRの中に残しておくべきだと思います。

以前の環境の方が良いと思ったものは取り入れる

以前の職場と比較して、「ここは前の方が良かったなー」、「でもこっちは今の方がいいなー」と感じることは多少なりとも出てきます。
以前の方が良いと思ったことは現環境にも提案して積極的に取り入れていきましょう。それが採用されて上手く回れば自分が戦力になった感も得られてメンタル的にも良いです。
また、もし可能なのであれば今の環境の方が良いと感じたことは前の環境にも伝えてあげましょう。
良いことは何でもオープンに。