エンジニア１年目として考えていたこと

#はじめに

この記事は、[トラストバンク Advent Calendar 2021の14日目](https://qiita.com/advent-calendar/2021/trustbank)です。

はじめまして、トラストバンクのAPI開発担当チーム所属の石川です。

私は今年の8月からトラストバンクにジョインし、エンジニア1年目として現在5ヶ月程開発業務を行っています。

本記事では、私がTBに入社してからどんなことをしてきたか、また、1年目のエンジニアとしてどういったことを意識してきたか、最後にはその感想についてまとめています。

本記事はこんな方にオススメしたいです。

* 趣味でプログラミングした経験がありこれから実業務に入る方
* 大学で情報処理を専攻していてこれから実業務に入る方
* ITの知識はあるがこれから初めてエンジニアになる方

なお、私はAPI開発チームであるため、バックエンドの内容が多めになりますが、フロントエンドでもバックエンドでも共通箇所はあると思いますので、どこか参考にしていただける部分があれば幸いです。

# TBに入社してからの業務
ここからは、私がトラストバンクに入社してから、現在に至るまでの大まかな業務の流れになります。

各セクションで、どういったことを意識して取り組んできたかについても記載しているので、少しでも参考になれば幸いです。

##トレーニング編

まず、初めに私がAPI開発チームにジョインしてから行ったのは3週間のトレーニングでした。

トラストバンクのエンジニアは基本的には中途採用のため、新卒向けのトレーニングメニューはありませでしたが、チームの上長が私向けにトレーニングメニューを作成してくれました。

### まずProgateをしました
最初の1週間程度はProgateを利用して、全体的にWeb開発の初歩的なスキルを抑えつつ、PHPやSQLを中心としたバックエンドスキルのトレーニングを行いました。

こういったトレーニングは早く終わらせようと思えば、いくらでも早く終わらせることができますが、
このときに私が意識していたことは「なるべく思い出しながらコーディングする」ということでした。

具体的にどういうことかと言うと、Progateでは各セクションの初めに、インプットとなるスライドが表示されるのですが、コーディングン中、答えがわからなくなった際でも、なるべく思い出す努力をして本当にわからなくなった時だけ確認するというやり方をとっていました。

実際これにどれほどの効果があるかはわかりませんが、個人的にはサッと確認してサッとコーディングしてしまうと頭に残らないので、このやり方は合っていました。

また、ここで行った超初歩的なトレーニングが、後に実業務へ入る敷居をかなり下げてくれていた気がします。

※参考に、下記が実際に私が行ったトレーニングの一覧です。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/127286/3b4ab034-9b09-4b00-3918-3f51f4c5a3a2.png)



### お試しLaravel開発
次に行ったトレーニングは、メンターのお題にそって、実際にLaravelで試しに何か作ってみようという内容でした。

お題はざっくりこんな感じ

* Laravelを使ってMySQLのテーブル情報をWebビューに出力する
* Jsonファイルをアップロードして、ダウンロード/閲覧/削除ができる簡易なサイトを作成する

こういった開発トレーニングを2週間程度行い、基本的なGitHubの操作方法を学んだり、メンターの方にレビューを頂きながらPHPのお作法を学んだりしました。

この時意識していたことは、もちろんコーディングのお作法を吸収することも重要なのですが、
Laravelがどういうロジックでユーザからのリクエストに対し、レスポンスを返しているのか、その一連のフローを理解することでした。

大まかには、
Request→Routing→Validation→Controller(↔Model)→View→Response
という流れなわけですが、これまでバックエンドの処理を書いたことがなかった自分には、この流れを理解しただけでも大きな収穫になりました。

## 実業務編
トレーニング終了後はいよいよ実業務開始です。

実業務では主に、API開発とPush通知サーバ開発を行いました。

### API開発編
トレーニングを終えて、まず一番最初に私が携わった実業務は、アプリ向けのAPI開発でした。

これまでバックエンドにほぼ触れたことがなかった自分でも、このAPI開発では様々なことを学びました。

* 既存のチョイスのコードから理解するバックエンドの動き
* チョイスに複数あるシステムの役割と関わり
* SQLを叩く際の注意点
* 結合テストの仕様書を作成する際の勘所、ポイント
* etc ...

と、もちろんこれらはあくまで触り程度の理解ですが、それでも、これまで漠然と「なんか後ろでよしなに動いているもの」という、バックリとしたバックエンドのイメージは自分の中でかなり明確にロジックとして理解できるようになりました。

このとき私が意識していたことは、「とにかく既存のコードを確認しながら全体の処理の流れを追うこと」でした。

当たり前の話ではありますが、まずは自社のシステムを理解することが、チーム貢献へ繋がる一番の近道ではないかと思います。

### Push通知サーバ　工数見積り編
次に私が携わった業務は、アプリ向けのPush通知サーバの開発工数見積りでした。

これまでの人生で開発工数の見積りなどは一度もしたことがなかったため、かなり頭を悩ませつつも、

* なるべくシステム開発の工程を細分化し
* どこにどの程度実装時間が掛かりそうか
* どの辺りに躓きポイントがありそうか

等々を考慮に入れながら工数を算出し、最終的に上長からレビューを頂き、修正→確定という流れで、工数の見積りは完了しました。

しかし、この時は右も左も分からずに工数見積りをしていたため、後々開発を行う中でこの工数だと足りないな・・・と思う箇所もありました。

ここでの反省ポイントとしては、まだ設計段階前ではあるものの、ある程度は頭の中で開発工程を思い浮かべ、開発工程に不明瞭な部分がある場合には、勘所を掴んでいる上長等により細かく相談したほうが良かったな思います。

### Push通知サーバ設計編

次に行ったのは、アプリ向けのPush通知サーバの設計でした。
このPush通知サーバの開発については、私個人にかなりの裁量が与えられているので責任重大です。

もちろん私一人ではなく、適宜上長にレビュー頂きながらの設計でしたが、基本的には事前にインプットされた要件を基に、自身が主体となって設計を行いました。

設計の中では、実際にシステムを利用する社内メンバーに適宜レビューを頂きながら、画面設計、テーブル設計、API設計等々、必要な機能の洗い出しや、実際のシステムのロジックの組み立てなどを行いました。

ここについては、正直まだまだ経験不足であまり語れることはないのですが、その上で、１年目のエンジニアとして意識していたことは、他の誰よりも自身が設計しているシステムのロジックについて深く考えることでした。

もちろん、設計のレビュワーはいますが、自身が設計するシステムのロジックについては誰よりも理解している必要があります。
レビュワーももちろん見てくれてはいますが、あくまでレビューです。

１年目だからといって他人任せにしてしまうと、
ふわふわとした状態で設計が終わってしまう可能性も大いにあります、
詰めきれていないところがあり、実装フェーズで躓く可能性もあります。

こういったことを防ぐためにも、設計段階から自身が一番考え抜いていることが重要だと思います。

### Push通知サーバ実装編

それでは、実装編です。
この実装の中では、様々なことを行いました

* View作成（tailwind css & blade）
* MySQLの操作（Eloquent操作）
* MVCでの開発（FatControllerを避ける）
* バッチ機能の開発
* API開発
* etc ...

と、バックエンドで必要な要素がかなりてんこ盛りでした。

実装の中では、網羅的に多くのことを学んだので一括には語れませんが、
ここで重要だったのはとにかく、
考える考える考える、
調べる調べる調べる、
それでもわからない所は素直に聞くを徹底することだと思っています。

# エンジニアになってみて思ったこと
ここからは、これまでエンジニア１年目として業務に関わってきた中での、
私自身の感想を少し書きたいと思います。

## エンジニアになってよかったこと
とにかく仕事が面白いです。
設計を考えたり、コーディングしたりと、考えることが好きな人にはやはり向いている仕事だなと思います。
また、自分の長所を生かして、チームから信頼される、頼られるというのはとても幸せなことだなと思います。

## 他の仕事と同じところ
私は新卒１年目の頃、ITコンサルタントとして働いていましたので、あくまでそことの共通点にはなるのですが、
基本的にスケジュールに沿って仕事したり、チームと連携しながら課題解決を行ったりするという、仕事のベーシックな要素に変わりはありませんでした。

## 他の仕事と違うところ
私が他の仕事との違いを一番感じたところは、プログラマは実務経験が浅くても知識やロジックでカバーできる部分が多いということです。

これはあくまで、趣味でそれなりにプログラミング経験を積んでいる人に限られるかもしれませんが、他の業種よりも、実務経験が浅くてもロジックや知識でカバーできる部分が多いと感じています。

ソースコードや社内の資料を読めば現状のシステムについてもある程度は理解できますし、
さらにネット上にも様々なTipsが転がっており、経験が浅くとも対応できる部分は多くあるように感じます。

しかしこれに矛盾するようですが、実際の現場では経験値もかなり重要であり、
踏んじゃいけない場所や、やってはいけない設計など、体系的に勉強をしているだけでは対応できない部分も多くあると感じています。

# 最後に、これからエンジニアになる方/なりたい方へ
知らないことを知れる喜び、
自分ができないと思っていたことができるようになる喜びは大きいです。

私の場合は学生時代から漠然と「バックエンドは自分には難しい」と自分自身で壁を作っていたところがありましたが、
今のようにバックエンドに触れてみるととてもおもしろい世界が広がっていて、
まだまだ面白いこと、知らないことでいっぱいなんだなと毎日実感しています。

なので、これからエンジニアになる方には、自分がやったことない領域にもどんどんチャレンジして、
もっと面白い世界を見ていただけたらなと思います。