Web系エンジニア3年目にやったこと

前前職？の方が去年のを読みましたと言ってくれたので、あまり覚えてない部分も多いが今年も書く。
※ 「~年目」は暦（こよみ）換算です。

去年のは[こちら](https://qiita.com/yokoto/items/4374cfc5f4fc1a481344)。

# 2021年振り返り
## 1月

* あまり記憶なし。仕事に疲れては酒を飲みという感じだったと思う。

## 2月

* 仮想通貨にお金入れる。1月に同じ。

## 3月

* 副業が契約終了になる。
    * サービスローンチを控え保守運用フェーズになるタイミングで終了となった。
        * 実際のところアウトプット不足だったかも。
            * Vue.jsの新規実装とか振ってもらったけどできなかったりした。今やったらできるだろうか。。
            * 大体月40hくらいの稼働だったが、本業もベロシティが高いチームと感じていた上での稼働だったこともあり、結構切羽詰まりっぱなしだったと感じる。
                * 副業って難しい。
    * 去年書いたこととも重複するが以下やったこと
        * DB設計やらリソース設計を0からガシガシ作る。
            * 新規サービスに携わることは個人開発以外であまりなかったので良い経験だった。
            * 参考にしたサイトをつらつら挙げてみる。個人的に良い知見だと思うのでここら辺も別記事として~~まとめたいかも~~リソース設計の方はまとめました。
                * リソース(ルーティングとコントローラ)設計について
                    * [RailsでREST API設計するときに知っておきたい集
](https://qiita.com/yokoto/items/30e11f28942c36f17187)
                * DB設計について
                    * [「SQLアンチパターン」を避けるためのチェックリスト①（DB論理設計編）](https://www.ketancho.net/entry/2018/03/07/080000)
                    * [SQLアンチパターン 幻の第26章「とりあえず削除フラグ」](https://www.slideshare.net/t_wada/ronsakucasual)
                    * [【Rails】ActiveRecord：単一テーブル継承(sti)とポリモーフィック関連を未だにぱっと思い出せないのでまとめ。](https://shirusu-ni-tarazu.hatenablog.jp/entry/2012/11/04/173742)
                    * [複数のテーブルに対して多対一で紐づくテーブルの設計アプローチ](https://spice-factory.co.jp/development/has-and-belongs-to-many-table/)
        * [GitHub Actions](https://github.co.jp/features/actions)の導入。
            * 最新のイメージを使い続けて、新しいバージョンのリリース後に動かなくなってハマったりした。
                * こういうやつ → [[GitHub Actions]Workflowに指定しているubuntu-latestが18.04から20.04に！あなたのWorkflowは大丈夫？[年末年始休暇前に要チェック]](https://dev.classmethod.jp/articles/check-runs-on-params-on-workflow/)
        * [rubocop](https://github.com/rubocop/rubocop-rails)の導入・CI化。
            * 入れたところでどうしても個人による書き方の差異は生じてしまったので、やはり理想的にはチームとしてのコーディング規約があるといいなとは振り返ってみて思う。
        * [RSpec](https://github.com/rspec/rspec-rails)の導入・CI化。
            * 誰かが書いたらバグが出てまともに開発が進められないというような状況から。
            * テストのカバレッジを意識して書くわけではない文化のチームにおいて、最小限のSytem SpecとRequest Specから書いた、というのは我ながらナイス決断だったと思う。
        * [brakeman](https://github.com/presidentbeef/brakeman)の導入・CI化、[Rails セキュリティガイド](https://railsguides.jp/security.html)の反映。
            * Railsセキュリティガイドを一通り読みながらコード直していったのはとても勉強になった気がする（あんまり覚えてないが）。

## 4月

* 駆け出しエンジニア時代から仲良くしていただいている友人と12月から毎週日曜に開催していたメタプログラミング勉強会完走。
    * https://github.com/yokoto/reading-metaprogramming-ruby
        * 元々[SmartHRで開催されていた勉強会](https://tech.smarthr.jp/entry/2020/03/13/123745)のfork。
            * 本業でも技術顧問の方が同じ関係で、自分の参画前に開催されていたらしい。
        * 実際自分は問題を自力では全然解けなかったので、元のリポジトリをforkした他の人のコードとかを読み解きながら進めてた。
            * 友人は解けてた...！
        * メタプログラミングに対する抵抗感や恐怖心的なものが消えたのと、つよつよRubyエンジニアの方々のコードをちゃんと読み解いたのが、とても勉強になったように思う。

## 5月

* ↑の経験を生かし、本業の方で社内LT。
    * [ひとりメタプログラミングRuby勉強会](https://speakerdeck.com/yokoto/hitorimetapuroguramingurubymian-qiang-hui)

## 6月

* あまり記憶なし。PancakeSwapとかやってた気がする。

## 7月

* 新しい副業が決まる。
    * モダンフロントエンドの知識を付けたいという狙いでOffersで探した。
    * 参画までにVue.jsの勉強しておこうと思い以下やった。感想としては、結局仕事でやらないと身に付いた感じはしない。。
        * [Vue.js公式ドキュメント](https://v3.ja.vuejs.org/guide/introduction.html)
            * つまみながらまとめた。
                * https://github.com/yokoto/VueOfficialDocument
        * [Vue.js/Vuexを使ってTrello風アプリを作成しよう！](https://www.techpit.jp/courses/24)
            * 分かりやすかった。
        * [Nuxt.js - Vue.js on Steroids](https://www.udemy.com/course/nuxtjs-vuejs-on-steroids/)
            * Nuxtを覚えた気がする。
                * https://github.com/yokoto/my-first-nuxt-app
        * [Vue.js + Firebaseで作るシングルページアプリケーション](https://www.udemy.com/course/vuejs-firebase/)
            * Vuetifyを少し覚えた。
                * https://github.com/yokoto/vue-address-book
        * [Vue JS 3: The Composition API
](https://www.udemy.com/course/vuejs-3-the-composition-api/)
            * Composition API、Jest（vue-test-util）、TypeScriptを覚えたつもりになった。
                * https://github.com/yokoto/vuejs-composition-api

    * なお、実際はこれまでと変わらずフロントjQueryベースの基本的なRailsアプリを担当することに。
        * 粛々と進めている。
        * 副業で参画する場合というのは新規(機能の)開発になることが多いように思う。これは本業で得た知識のアウトプットになる部分があると感じる。
        * 一方でフルコミットで働くのと比較した場合、コミュニケーションが非同期であることによるコミュニケーションコストが高い点が大変と感じる。

## ８月

* 本業の方で参画時から参加してた[JS Primer](https://jsprimer.net/)の輪読会が完走。
    * 正直内容的に結構難しい箇所もあった。
    * 非同期の部分がとくに勉強になった気がする。
        * https://jsprimer.net/basic/async/
        * でもスレッドがどう、という話がよくわからない。
        → 2022年入ってから[プロセスとスレッドについて調べた](https://qiita.com/yokoto/items/3b4bcc489d93bc57baf3)
    * 途中寝てしまっていたので抜けがだいぶある。

## 9月

* あんま記憶なし。

## 10月

* [Active Recordから考える次世代のRuby on Railsの方向性 / Directions for the next generation of Ruby on Rails: From the viewpoint of its Active Record](https://speakerdeck.com/yasaichi/directions-for-the-next-generation-of-ruby-on-rails-from-the-viewpoint-of-its-active-record) をすごっと思いながら聞いた。

## 11月

* 本業の方が丸一年となり、せっかくフリーランスなので他の案件も入ってみたいと思い退場することに。
    * 振り返ってみて、開発のメンバーが技術力もさることながら、まさに[HRTの原則](https://blog.toshimaru.net/team-geek/)が浸透していると言えるようなチーム・環境で、そう言った点での働きやすさ・学びがあった。
    * とくに勉強になったことは以下。
        * スクラムでの開発。
            * 自分としては1メンバーとしてスクラムの各イベントに参加していただけだが、以下みたいな用語が理解できるようになったなと思う。
                * デイリースクラム
                * バックログリファインメント
                    * プランニングポーカーを使用してストーリーポイントの見積もりを行ってた。
                * KPT（多分レトロスペクティブ相当。）
                    * 気軽な四方山が挙がることもありながらも、鋭い運用面の改善案が上がることもあり、とても良かった。
                * スプリントプランニング
                * デモ（スプリントレビュー）
            * エンジニアリングマネージャーの方がスクラムマスター相当の役割を担い、KPTで挙がった意見を漏れなく拾いアクションにつなげていただいてたのが、チームがワークしていた大きい要因に思える。
        * 技術的負債返済の取り組み。
            * リファクタリングやライブラリのアップデート等のエンジニア由来のタスクは、JIRAにおいて独立したプロジェクトとしてバックログに1日、1週間のような単位で工数づけして積まれ、各スプリントで1タスク乗せる、または月に1日に全員で取り組むようにされていた。
                * > JIRAにおいて独立したプロジェクトとしてバックログに工数付して積まれ
                    * これは良かったように思う。純粋なプロジェクトの方のベロシティがちゃんと計測できたりするので。
                * [freee 社のアクセシビリティガイドラインとチェックリストを丸ごと導入した](https://tech.hey.jp/entry/2021/12/24/112102)の記事に出てくる「大改善デー」の運用がこれとイメージ近いかも。（記事内容自体は関係なし）。
        * ChatOps
            * [Rollbar](https://rollbar.com/)で発生したエラーの対応担当やレビュアーのアサインは、Slack上のガチャで決定されるようになっていた。
        * 長めのActiveRecord
            * レビューで厳しく指摘される中で身に付いていったように思う。
            * ざっくりとではあるが自分なりの知見を記事にしてまとめてみた。
                * [RailsのN+1対策ガイド
](https://qiita.com/yokoto/items/983c1a63424915dcc34a)
                * [サブクエリと闘うActiveRecord](https://qiita.com/yokoto/items/f52a253f821fee38168d)
        * RSpec
            * ここより前の現場では正直あまりちゃんと書いていなかったが、テストが不足しているとレビューで指摘されるような環境だったおかげもあり、多少書けるようになった気がする。
            * flakey testにもはじめて向き合った。
            * RSpecもざっくりと自分用の記事作った。
                * [RSpec書くときに知っておきたい集](https://qiita.com/yokoto/items/c7973a4b222fe19a657a)
        * フロントエンド
            * 部分的にVue.jsが採用されていたので、Railsからの使い方覚えたり既存の似たようなコンポーネント書いたりバグ直したり。
            * [MutationObserver](https://ja.javascript.info/mutation-observer)を覚えたときはおお〜となった。
            * Jestもちょっと触った。


* レバテックフリーランスとFindyフリーランス経由で新しい案件探す。
    * 単価優先で探したかったので自分の中で経験年数が比較的長いRailsで探す。
        * 単価が同じ場合は技術的な環境で決めようと思っていたが、結果としては事業ドメインへの興味で決めた感じがする。
    * 大きい会社で働いたことがないなと思ったので、1社を除いて全て上場企業に絞って探した。割とどこもオファー貰えた感じがある。
    * 面談の技術質問は正直回答がいまいちなものもぽろぽろあった気がするが、1業務委託メンバーとしては及第点なのかなと思う。
        * 覚えてる質問と回答を残しておく。
            * スクラムでの開発経験はありますか？ある場合はどのように行っていましたか？
                * 上に書いたようなスクラムのイベントの話を何曜日行ってましたとか答えた。
            * APIを設計するときに気を付けていることは何ですか？
                * Restfulな感じですかねえ。。命名に気をつけたりGET, POST, PATCH, DELETEに相当するアクションを持つコントローラを作って、コントローラはFatにならないようにしました。みたいに答えた。（あまり良い回答できた自信なし。）
                今(2022/4/25)なら、[RailsでREST API設計するときに知っておきたい集](https://qiita.com/yokoto/items/30e11f28942c36f17187)を参考に、1 screen 1 API callとリソースベースのAPIの比較をしながら話すかも。
            * MVC以外ではどのようなレイヤーを使っていましたか？
                * [RailsのMVC以外(Service, Form, Decoratorなど)について考えるための読み物まとめ](https://qiita.com/yokoto/items/cd45e7b1d8b11bb9c29a)で書いたようなService, Form, Decoratorの話をした。
            * DB設計のときに気をつけていることは何ですか？
                * SQLアンチパターンを意識しながら検索でかけるカラムのみに適切にインデックスを貼ったりするなどです。（あまり良い回答できた自信なし。）
                今(2022/4/25)なら、[楽々ERDレッスンを読んだ
](https://qiita.com/yokoto/items/c51bfb0ef626acebe9af)や[RDBのデータモデリング・テーブル設計の際に参考にしている考え方と資料](https://zenn.dev/rebi/articles/28c7f1fee5730a)を参考に、データモデリングでイベント系（トランザクション系）のリソースを見落とさないこと、正規化された（= 重複なく疎結合な）テーブル設計を行うこと、[有効なINDEX](https://qiita.com/yokoto/items/9452ee2456b36c587bb2#index%E3%82%92%E5%88%A9%E7%94%A8%E3%81%99%E3%82%8B%E3%81%9F%E3%82%81%E3%81%AB%E5%BF%85%E8%A6%81%E3%81%AA%E6%9D%A1%E4%BB%B6)を貼ること、[実行計画](http://nippondanji.blogspot.com/2009/03/mysqlexplain.html)を読むこと、あたりを話すと良さそうに思う。
            * Railsの長所と短所を教えてください。
                * 長所は、ActiveRecordがデータベースとモデルを密結合にしてMVC一貫で開発できるので初期の生産性が高いことです。短所は、中長期的にMVCのレールを外れたときに設計が破綻するケースがよくあること、またSPAを実現するのが苦手なことです。
            * 好きな言語への想いみたいなものはありますか？
                * Railsの長所として回答したような話をした。
            * 開発において得意なことは何ですか？
                * リファクタリングや設計です。（MVC以外ではどのようなレイヤーを使っていましたか？の回答を絡めながら答えた。）
            * CIで実行時間を改善するためにはどのようにすれば良いですか？
                * 不必要なテスト・テストデータ(letで定義したもの)を削除したり、CIを実行するインスタンスのスペックを上げたり？です（やったことはない。並列(parallel)で実行するようにする、という手段もありますよねと言われた）。
            * インフラの経験はありますか？ある場合はどのような経験がありますか？
                * 開発に必要な範囲で、エラーの調査ではCloudWatchのログを見に行ったり、インスタンスのステータスを見に行ったりという程度はあります。また不要なインスタンス・EBSを削除してコスト削減に貢献したことがあります。（正直そんな大した経験ではないのでアピールになった自信はなし。）
                実際にインフラ設計をしたりterraformのコード書いたりの経験が積めていれば良かった気がするが、経験がなくても[オーソドックスなアーキテクチャ](https://qiita.com/g_ayushi/items/0e0f34d19813b8fdc2b8#%E3%82%AA%E3%83%BC%E3%82%BD%E3%83%89%E3%83%83%E3%82%AF%E3%82%B9%E3%81%AA%E3%82%A2%E3%83%BC%E3%82%AD%E3%83%86%E3%82%AF%E3%83%81%E3%83%A3)を理解していることの説明くらいはできた方が良いかも。
            * Dockerでの開発経験はありますか？
                * Dockerとdocker-composeで開発を行っていました。環境を作ったりはしたことありません。
            * gemのバージョンアップの経験はありますか？
                * 以前の現場でタスクとしてアサインされたことはありませんが、テストが十分に書かれているかや、bundle updateしてみて落ちるテストがあればどのgemが原因か、gemのどの実装が原因で落ちたかを見たり、実際に動かしてみたり、っていうような作業のイメージはあります。と答えた。

## 12月

* 新しい現場に参画。
    * メインで担当するリポジトリのファイルで、最後のコミットが8年前のものを見つけ、自己最高更新。
    * Railsメインだが、他JavaやらGoやらいろいろなサービスと連携したマイクロサービス。
        * 技術スタック的には前前職でやっていた感じに近いかも。
        * main(master)ブランチもCIが落ちてたり、各ライブラリのバージョンも古かったりするのでモダンって感じではない。
            * 基盤のサービスより上に関しては厳密な分業が行われていない分、インフラ周りやCSSやjQueryにも改めて向き合おう、改善していこうと気持ちを新たにし中。
        * 分かりづらい運用方法や開発を始める上で知っておくべきサービス（リポジトリ）が多いこともあり、キャッチアップも十分進んでおらずいまだに(1月4日時点)オンボーディング気分。。
            * 気持ちは初日にPR出すって感じだったが、中の人には最初はこんなもんと言われるなど。
    * 会社のエンジニアが多いこともあり（自分比）、Kibelaが宝の山感あるかも。貪欲に読む。

## まとめ

エンジニア3年目は、副業もやって本業もやって、自分の中では結構コードを書いた年だったかなと思う（ほぼRailsではあるが）。そういう点では自覚できていない部分で成長しているかも（願望込）。
一方でずっと伸ばしたいと思っていた（モダン）フロントエンドのスキルが顕著に伸びることはなかったかなーと思う。

まあ12月からの案件もそれ基準で選んではいないので、4年目も目の前の仕事に真摯に取り組む（使っているメソッドや文法や周辺技術をちゃんと調べたり、Slackや会話の中でわからない用語が出てきたらちゃんとキャッチアップしてタスクとして対応できるようにする）ことで引き続きスキルアップできれば良いかなと思う。過去携わったサービスと比較してもより大規模サービスになるので、とくにインフラ周りも付いていってよりできるようになると良いなと思う。

あと自分で記事を書くとそれをよく見返す（≒覚える）ことに気づいた。ので去年より（自分のために）もう少し記事を書くようにしようと思う。