LoginSignup
3
3

More than 1 year has passed since last update.

@yokoto

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

Last updated at Posted at 2022-01-04

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

去年のはこちら。

2021年振り返り

1月

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

2月

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

3月

4月

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

5月

6月

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

7月

８月

9月

  • あんま記憶なし。

10月

11月

  • 本業の方が丸一年となり、せっかくフリーランスなので他の案件も入ってみたいと思い退場することに。

    • 振り返ってみて、開発のメンバーが技術力もさることながら、まさにHRTの原則が浸透していると言えるようなチーム・環境で、そう言った点での働きやすさ・学びがあった。
    • とくに勉強になったことは以下。
      • スクラムでの開発。
        • 自分としては1メンバーとしてスクラムの各イベントに参加していただけだが、以下みたいな用語が理解できるようになったなと思う。
          • デイリースクラム
          • バックログリファインメント
            • プランニングポーカーを使用してストーリーポイントの見積もりを行ってた。
          • KPT（多分レトロスペクティブ相当。）
            • 気軽な四方山が挙がることもありながらも、鋭い運用面の改善案が上がることもあり、とても良かった。
          • スプリントプランニング
          • デモ（スプリントレビュー）
        • エンジニアリングマネージャーの方がスクラムマスター相当の役割を担い、KPTで挙がった意見を漏れなく拾いアクションにつなげていただいてたのが、チームがワークしていた大きい要因に思える。
      • 技術的負債返済の取り組み。
        • リファクタリングやライブラリのアップデート等のエンジニア由来のタスクは、JIRAにおいて独立したプロジェクトとしてバックログに1日、1週間のような単位で工数づけして積まれ、各スプリントで1タスク乗せる、または月に1日に全員で取り組むようにされていた。
      • ChatOps
        • Rollbarで発生したエラーの対応担当やレビュアーのアサインは、Slack上のガチャで決定されるようになっていた。
      • 長めのActiveRecord
      • RSpec
        • ここより前の現場では正直あまりちゃんと書いていなかったが、テストが不足しているとレビューで指摘されるような環境だったおかげもあり、多少書けるようになった気がする。
        • flakey testにもはじめて向き合った。
        • RSpecもざっくりと自分用の記事作った。
      • フロントエンド
        • 部分的にVue.jsが採用されていたので、Railsからの使い方覚えたり既存の似たようなコンポーネント書いたりバグ直したり。
        • MutationObserverを覚えたときはおお〜となった。
        • Jestもちょっと触った。

  • レバテックフリーランスとFindyフリーランス経由で新しい案件探す。

    • 単価優先で探したかったので自分の中で経験年数が比較的長いRailsで探す。
      • 単価が同じ場合は技術的な環境で決めようと思っていたが、結果としては事業ドメインへの興味で決めた感じがする。
    • 大きい会社で働いたことがないなと思ったので、1社を除いて全て上場企業に絞って探した。割とどこもオファー貰えた感じがある。
    • 面談の技術質問は正直回答がいまいちなものもぽろぽろあった気がするが、1業務委託メンバーとしては及第点なのかなと思う。
      • 覚えてる質問と回答を残しておく。
        • スクラムでの開発経験はありますか？ある場合はどのように行っていましたか？
          • 上に書いたようなスクラムのイベントの話を何曜日行ってましたとか答えた。
        • APIを設計するときに気を付けていることは何ですか？
          • Restfulな感じですかねえ。。命名に気をつけたりGET, POST, PATCH, DELETEに相当するアクションを持つコントローラを作って、コントローラはFatにならないようにしました。みたいに答えた。（あまり良い回答できた自信なし。）
            今(2022/4/25)なら、RailsでREST API設計するときに知っておきたい集を参考に、1 screen 1 API callとリソースベースのAPIの比較をしながら話すかも。
        • MVC以外ではどのようなレイヤーを使っていましたか？
        • DB設計のときに気をつけていることは何ですか？
        • Railsの長所と短所を教えてください。
          • 長所は、ActiveRecordがデータベースとモデルを密結合にしてMVC一貫で開発できるので初期の生産性が高いことです。短所は、中長期的にMVCのレールを外れたときに設計が破綻するケースがよくあること、またSPAを実現するのが苦手なことです。
        • 好きな言語への想いみたいなものはありますか？
          • Railsの長所として回答したような話をした。
        • 開発において得意なことは何ですか？
          • リファクタリングや設計です。（MVC以外ではどのようなレイヤーを使っていましたか？の回答を絡めながら答えた。）
        • CIで実行時間を改善するためにはどのようにすれば良いですか？
          • 不必要なテスト・テストデータ(letで定義したもの)を削除したり、CIを実行するインスタンスのスペックを上げたり？です（やったことはない。並列(parallel)で実行するようにする、という手段もありますよねと言われた）。
        • インフラの経験はありますか？ある場合はどのような経験がありますか？
          • 開発に必要な範囲で、エラーの調査ではCloudWatchのログを見に行ったり、インスタンスのステータスを見に行ったりという程度はあります。また不要なインスタンス・EBSを削除してコスト削減に貢献したことがあります。（正直そんな大した経験ではないのでアピールになった自信はなし。）
            実際にインフラ設計をしたりterraformのコード書いたりの経験が積めていれば良かった気がするが、経験がなくてもオーソドックスなアーキテクチャを理解していることの説明くらいはできた方が良いかも。
        • 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や会話の中でわからない用語が出てきたらちゃんとキャッチアップしてタスクとして対応できるようにする）ことで引き続きスキルアップできれば良いかなと思う。過去携わったサービスと比較してもより大規模サービスになるので、とくにインフラ周りも付いていってよりできるようになると良いなと思う。

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

3
3
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
3
3