プログラミングスクールと実務を経て感じたこと

# はじめに
この記事は[WEMEX株式会社 Advent Calendar 2023](https://qiita.com/advent-calendar/2023/wemex) 20日目の記事です



23卒の新卒エンジニアとして入社した私は、6月から10月にかけて、プログラミングスクールでの研修と実務でのOJT（On-the-Job Training）を並行して経験しました。この記事ではプログラミングスクールでの学びと実務経験を基に、新人エンジニアとして感じたことを共有したいと思います。

なんらかの形でみなさまのお役に立てれば幸いです。

# 筆者の開発歴について
背景として私の入社以前の開発歴について述べたいと思います。

私が学生時代に触れていた言語は主にPythonとC++です。

Pythonでは主に研究用のコードを書いていました。
研究室の専攻が自然言語処理だったので、コードとしても自然言語処理や機械学習等の内容がメインでした。

C++は所属の研究室とは別に行っていた、流体シミュレーションソフトのR&Dや可視化ソフトの開発（デスクトップアプリ）に使用していました。

Web開発についてはRailsやDjangoをほんの少しだけ(4年程前にUdemyを写経するぐらい)触っていましたが、入社当時はほとんど何も覚えていないという状態でした。

したがって弊社で携わることになるRuby,Ruby on RailsおよびWeb開発全般の知識についてはほぼ初学者でした。

# スクールについて
スクールは「現場の即戦力になれる」ということを目標に掲げていました。
そのため、チーム開発において必要なGitなどに加えて、フロントエンドからバックエンドまで様々なことを学ぶことができました。

具体的には以下の内容について学びました。
- Linux
- Git,GitHub
- HTML,CSS
- RDB
- Web,HTTP
- Ruby,Ruby on Rails

またスクールとはいっても講義形式ではなく、独学で学んでいきカリキュラムをこなしていく形式で完全オンラインでした。




# 感じたこと

## Git,GitHub
入社以前も個人範囲でのコード管理目的でGitの利用経験はありました。
しかしチーム開発におけるGit,GitHubの利用経験は全くと言っていいほどありませんでした。(add、commit、pushを使う程度)

スクールでは[サル先生のGit入門](https://backlog.com/ja/git-tutorial/)を用いて学習を行い,チーム開発に必須なbranch、pull requestなどの仕組みについて学びました。
また、後述するRubyプログラムの開発ではメンターとGitHub上でやりとりし、pull requestの作成やマージ等を行うことで、実務と近いやりとりを経験できました。

<!-- 一方、実際の現場では運用上のルール(例えばGit-flow)が存在したり、CICD、チーム開発ならではのconflict問題などを経験しました。 --> 

実務を通して非常に大きな学びだと感じたものに「pull requestの作成方法」がありました。
私のチームではpull requestのマージに２名のApproveが必須というルールがあります。
pull request作成において背景や目的を書く(slackのURL添付などでも可)ことで、レビュワーがその変更に至る経緯、議論を知れるためレビューがスムーズに行えます。
また、pull requestを適切な粒度に分割することでレビュー時に注目すべき観点を絞りやすくなるため、一つのタスクだとしてもそれを複数のpull requestに分割することも一つの手だと学べました。


<!-- CIが落ちている。mainブランチが先行している。コンフリクトが発生している。Revert（間違えてReleaseブランチにpushした）など --> 


## DB,SQL

スクールのカリキュラムでは
- [初めてのSQL](https://www.oreilly.co.jp/books/9784873119588/)
- [楽々ERDレッスン](https://www.shoeisha.co.jp/book/detail/9784798110660)
- [達人に学ぶDB設計 徹底指南書](https://www.shoeisha.co.jp/book/detail/9784798124704)
- [SQLアンチパターン](https://www.oreilly.co.jp/books/9784873115894/)
等の書籍を読み、SQLからRDB設計理論、アンチパターンまで幅広く学びました。

私の携わっていたプロダクトは[digicareアナリティクス](https://digicare.jp/)という、薬局向けのBIツールでした。そのためクエリの理解がプロダクトの理解であると言っても過言ではありませんでした。
しかし入社以前の私はSQLについての経験は全くなかったため、プロダクト内のクエリを初めて見た際はその長さに驚きを隠せませんでした。いままで書籍やWebで見てきたSQLとはレベルが違うと思い、読み解くのは不可能なんじゃないかと絶望しかけました。


- 何度も繰り返し読み、頭の中で小さい部品として整理すること
- ドメイン知識(調剤報酬など)について学ぶ

上記２点を意識することで、今では複雑なクエリでもなんとか読めるようになりました。




## Ruby,Ruby on Rails 
Rubyのカリキュラムでは[チェリー本](https://gihyo.jp/book/2021/978-4-297-12437-3)を読み進めながら、いくつかのプログラムを作りました。チェリー本の内容はRuby特有のイディオムなども説明されており、Ruby的な書き方を学ぶ際にも非常に役に立ちました。
プログラム作成時はGitHub上でpull requestを作成し、そこでスクールのメンターと直接やり取りしながら進めていきました。

特にRubyでの学びとして大きかったものは「テストコード」の考えでした。今までテストコードといったものを書いたことはなく、学生時代のソフト開発では手動テストでソフトをポチポチしていました。そのため一行のコマンドでテストが実行され、エラーが見つかるありがたみを感じることができました。



# さいごに
以上がプログラムスクール研修とOJTを経験した４ヶ月間を簡単に振り返ったものです。
この期間は書籍等での体系的な学び、実務を通しての学び、それぞれを並行して行っていましたが、12月現在は実務100%で取り組んでいる状態です。
それもあってか、最近は体系的な学びが減っているなと個人的に思っていました。
なので、今後は自分の学びの意味をこめてアウトプットの機会を増やしていきたいな〜と思いました。
以上、決意表明になります。

最後まで読んでいただきありがとうございました。

<!--- 書籍等で体系的に学ぶのと、現場で学ぶのそれぞれを並行して行ってきたのですが、12月現在は現場の業務で調べながらやっているのがほとんです。-->
<!---　そのような体系的な学びと現場での学び、どのぐらいの配分で行うと良いのかというのが自分の中でもわからないなーというのが悩みとしてあるかもしれません。(12月現在は現場で学びながらしているのがほとんど) -->