Zenn
⌚

2年2ヶ月のエンジニア人生の振り返り

2024/12/31に公開
Kotlin
React
TypeScript
振り返り
実務経験
idea

こんにちは、初めまして未経験でエンジニアに転職したとKuuuuuと申します。
私の経歴は以下の通り。

  • 中学校教員 3年6ヶ月
  • エンジニア 2年2ヶ月(2024年12月現在)

私のことについては、弊社の入社エントリ記事を見ていただくか、なぜエンジニアになったのかは、今年記事を書いたので見ていただけたら幸いです。
女性エンジニアとしてやりがいを感じた経験談をシェアしようというテーマでの記事なので、何を書くか本当に悩んだのですが、2年2ヶ月でどんなことをやってきたのかを振り返ってみようと思います。

入社~2.5ヶ月: 研修時代

弊社はありがたいことに研修がありました。内容は以下の2つです。

  • CS50
  • Railsチュートリアル→AWSでのデプロイ

CS50

CS50というのは、ハーバード大のコンピュータサイエンス入門講座になります。こちらが無料で公開されており、弊社ではこちらを用いてGithubのIssueで各Weekで学んだことをまとめ、それぞれのWeekでLabとProblem Setという問題を解いたコードをGithubのPRを作成し、コードレビューをしていただいていました。他にも弊社が作成している各Weekごとに学んだ内容を理解しているかのチェックシートを基に、質問に答えることができるかのチェックも行っていただいていました。
CS50の各項目は以下になっており、Week1~5はC言語についてになります。

  • Week0 Scratch
  • Week1 C
  • Week2 Arrays
  • Week3 Algorithms
  • Week4 Memory
  • Week5 Data Structures
  • Week6 Python
  • Week7 SQL
  • Week8 HTML, CSS, JavaScript
  • Week9 Flask
  • Week10 Ethics

感想

C言語を学んだことが今まで一度も無く、独学時代はRuby,Ruby on Rails,JavaScriptのみであったため最初はとても戸惑いました。コンパイルを自分で行わないといけないし、Rubyみたいにメソッドがあるわけではないので基本的に自分でメソッドを作成する必要があることにも驚きました。他にもポインタの概念が分からなかったり、型がRubyと違ったりなど戸惑うポイントは盛りだくさんでした。アルゴ式とかAtCorderをやっていたのがここで結構助かりました。正直競プロを勉強していなかったらかなり困っていたと思います。
でも実際にC言語を勉強してみて、この考え方を基にRubyは作られているんだなということとかも理解できたので、何かの言語を学んだ後にC言語を学ぶことは非常に役に立つと思います。写真を白黒にするとかもCS50ではあるので、画像の加工もこういう風にしてやるのか〜とすごい感動したのを今でも覚えています。

Railsチュートリアル + AWSデプロイ

Railsチュートリアルは最新版意外は無料で公開されており、Railsを学んでいる人としては存在は知っていました。ただ、私自身独学時には取り組んでいませんでした。こちらに関してもCS50と同様にGithubのIssueで各章で学んだことのまとめ+演習の答えをまとめ、それぞれの章での開発をGithubのPRを作成してコードレビューをしていただいていました。
Dockerを使って環境を構築し、AWSにRailsチュートリアルで作成するSample Appをデプロイしました。以下のような手順でデプロイしました。

  1. VPCの作成
  2. サブネットの作成
  3. インターネットゲートウェイの作成
  4. ルートテーブルの作成
  5. セキュリティグループの作成
    　　以下のインバウンドグループを作成しました。
    • Postgresqlのポート
    • SSH接続のポート
    • Pumaを接続するためのポート
  6. EC2インスタンスの作成
  7. SSH通信によるインスタンスへのログイン
  8. EC2インスタンスの環境構築
  9. gitとの連携・アプリのクローン
  10. master.keyの登録
  11. Postgresqlの設定
    　　 デフォルトで作成されるユーザーで設定しました。
    パスワードは再設定しました。
  12. Pumaの設定
  13. データベースを作成する
  14. S3の設定・連携

参考記事

感想

Railsチュートリアル自体はRails自体を入社前から学んでいたためそこまで初めて知る内容は少なかったです。ただログイン機能の作成に色々な方法があることをそこまで当時は完全に理解していなかったので、そこはとても勉強になりました。
一番勉強になったのはAWSでのデプロイです。当時はDockerを使ったこともなかったため、Dockerを使うのも難しかったです。特にデプロイ時に大変だったのが、EC2とRDSなどを使ってデプロイしている記事は多かったのですが、研修用のアプリのデプロイなのでEC2インスタンス内で完結させる方法を調べるのにすごく時間がかかりました。今でも完全にAWSを理解できているとは到底言えないのですが、最初から触る機会があったのは本当に良かったです。

2.5~3.5ヶ月: 初案件の保守 修正必要

元々私が入る前からある案件のリファクタリングからやらせてもらえることになりました。この時に以下のフロントエンド,バックエンドのタスクを1つずつやらせてもらいました。

  1. useQueryのrefetchで検索機能を実装しているのを、useMutationのmutateに修正
  2. 結果画面で小数点がある場合に、スプレッドシートの表示が0になってしまう不具合の修正

ここから急に弊社で使うReact/TypeScriptやKotlinのタスクになるので、言語を理解するのも大変でしたが0→1でやるものではないので、先輩のコードを見ながらやっていればなんとかはなりました。

この経験で勉強になったのは、2の方の対応です。このサービスは研修に使うための簡易なゲームのようなサービスで、そのゲームの中で入力された値や、計算した値をスプレッドシートに出力しているサービスでした。今回の事象では、サービスの結果画面では小数点で表示されているにも関わらず、スプレッドシートでは「0」になってしまうという不具合が起きており、そちらの修正の対応でした。
先輩が最初のリファクタのタスクであったため、ほとんど〇〇のようにして下さいとチケット上で伝えて下さっていたのですが、私はろくに調べず言われたことをそのまましてしまいました。
しかし、実は言われたことをそのままやるだけでは駄目だったのです。
弊社のCTOにこの事象について問題が2つ介在しているから、ちゃんとそれぞれ分割して解決するべきだと教えていただきました。その際に未経験だからといって、言われたことをそのままやるのではいけないとも言われました。
この経験は結構私の中ですごく印象に残っています。自分が未経験で会社の中で誰よりも知識がないので、先輩から言われたことが正しいと思い込んでそのままろくに自分で調査もせずに開発をしていました。このことがあってから、これ以降の開発ではなんのために開発をし、何をゴールとしているのかを考えて開発をすることを心がけています。
本当にCTOには感謝しています。

3.5ヶ月~1年2ヶ月: 初の0→1案件の開発

エンジニアになる前にいつかは0→1の開発がしたいと思っていたのですが、最初の開発の案件から0→1の案件で本当に嬉しかった覚えがあります。また、私は過去に中学校の教員をしていたのですが、このサービスは高校3年生がユーザーの大学受験の進路や大学の情報を検索するものだったので、自分のドメイン知識が活かされる内容だったのもとても嬉しかったです。

大学検索サービスの1次リリース(5ヶ月間)

初めての案件であったため、開発が始まってからチームにアサインされました。0→1の案件であったため、主に以下のような作業を当時はやっていました。

フロントエンド

  • コンポーネントの作成
  • テストコード
  • 不具合修正: スタイルの修正

私はコンポーネントの作成を行い、それを使って先輩方が複雑な機能などは実装していただいたりをしていただいていました。Atomic Designの設計方針で開発を行なっており、MUIを用いておりました。
最初の頃は理解するのが大変でしたが、だんだん慣れてくるとどのディレクトリの分け方や、どこまでどのスタイルを当てたら良いのかの判断がとてもしやすくてやりやすかったです。
最初だったこともあって、主にスタイルの修正やコンポーネントの部品の開発が多かったです。

大学検索サービスの2次リリース+運用保守(1年2ヶ月間)

2次リリースからは要件定義/基本設計/詳細設計/開発/テスト/保守運用まで全て関わることができたので、すごく嬉しかったし楽しかったです。
主に以下のようなことをやっていました。

フロントエンド

  • 要件定義MTGで決まったことを元に不確定事項の洗い出し
  • カレンダー機能のライブラリ選定
  • 追加機能で必要なAPIのopenapi.yamlの作成
  • マイリスト機能の開発
  • テストコード
  • 不具合修正: 機能修正/不具合調査
  • リファクタ: 1次フェーズで積み残していたリファクタリングやテストコードの速度改善など

どんなことを学んでどんなことに引っ掛かっていたのかは、昨年に2023年わたしの発見！大発表会 （オンライン開催） - connpassで登壇した資料を見ていただいたら良いかと思います！

2人のバディ(1年間)

弊社では、新入社員にメンター1名とバディ1名をオンボーディング中につけます。入社半年で1名のバディを担当することになり、その後もすぐにもう1名のバディをやらせていただきました。
弊社ではバディは入社の際のPCの設定であったり、バディトークといって1on1を行なったりと基本的に「何か困ったことがあったら聞く相手」という感じです。
そこまで大したことはできていないですが、意識していたことは現在ある弊社のオンボーディング中の資料で分かりにくい点があれば、入社した方に更新してもらうことを最初の方に伝えていました。弊社ではドキュメントを更新する文化が非常に強いので、ドキュメントを更新しやすい環境であることや、更新することを癖付けてもらうようにこの部分は意識していました。
次やる時はエンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング | 広木 大地で読んだことを実践したいと思っています。

1年~1年7ヶ月: 色々なことをやる

この期間はとても色々なことを満遍なくやる期間でした。また上記の案件もやりながら行なっていたので、初複数案件にアサインされていました。

既存のECサービスの運用・保守/追加開発(7ヶ月間)

元々ある案件のお問い合わせ対応ができる人員を増やすためにアサインされました。
元々のサービスの一部改修のフロントの開発を本当に少しと、ほとんどはお問い合わせ対応を行なっていました。このサービスは一部ShopifyとPrismatixが使われていたためそのAPIを叩くためにPostmanを使っていました。それぞれのことを未経験の時は知らなかったためすごく勉強になったのと、実際に本番データを触ることになるのでとても緊張感をもって対応していました。データを見て、何が起きているのかを考えて対応することが大分できるようになったかなと思います。

AWSコスト削減(6ヶ月間)

弊社のAWSのコスト削減チームが発足され、立候補して活動しておりました。AWSの知識がほとんどない状態からのスタートであったため、かなりチャレンジングでしたが結果的に参加してとても良かったなと思います。今までAWSコスト削減をされたことが無かったそうなので、過去のリソースの現状把握を行うことが主な作業になりました。
主に以下の内容を行なっていました。

  • コスト削減方法の調査
  • 現在のコスト,状況の調査
  • タグ付けルールの見直し,社内での周知
  • タグがついていないリソースへのタグ付け
  • 不必要なリソースの削除
    • EC2インスタンス削除候補/常に稼働が必要でないものの洗い出し
    • EC2インスタンスの削除候補をバックアップ取得/削除
    • AMIの削除候補を洗い出し/削除
    • EBSのタイプをgp2からgp3に変更
    • EBSの削除候補洗い出し/削除
    • S3の削除候補洗い出し/削除
    • VPCの削除候補洗い出し/削除

この取り組みを行なって、月のコストを元々の10%削減することができました。元々はコストの可視化が完全にできていないところから、少しそちらも改善していきました。コスト削減中にCostExploerでコストを確認していくとどんどん減っていくのが確認できて、とても達成感がありました。
また、調査していくことで以下の内容に気が付くことができ、社内でアラートをあげ対応をチーム全体ですることができました。

  • Global Acceleratorの消し忘れがあったことが発覚
  • バックアップのSnapshot取得方法が間違って費用が増えていたことが発覚
  • RDSのMySQLの5.7のサポートが終了によって費用が増大していることが発覚

まだまだAWSについて完全に理解できていないことも多いですが、コスト削減を考えながらそれぞれのリソースについて理解するとても良い機会になったと思います。

エイプリルフール企画(2ヶ月間)

弊社では毎年エイプリルフール企画を行なっており、やってみないかと声をかけていただくことができました。そして2023年のエイプリルフール企画では、リーダーをやらせていただきました。リーダーと言っても社内のプロジェクトなので、そこまで大したことはしていないのですが、主に以下のことを行なっていました。

  • 企画案作成,進捗確認,チケット作成,チケット割り振り
  • 既存の弊社のHPをエイプルフールの内容にするため開発
  • p5.jsを用いてお問い合わせボタンを押すと砂が落ちるように機能を追加
  • AIによる画像生成ツールにて画像の作成,画像の編集,動画撮影

今年は弊社では地方で働く人が増えたこともあり、「鳥取支社を設立しました！」というテーマで色々行いました！
詳しくは、以下を見ていただけると幸いです！

実際にリーダーをやってみて感じたのは、とても難しいと思いました。普通の開発ではないので、何をゴールにするのか何が良いのかを考えるのがとても難しかったです。また、私自身決断するのが苦手だということを再認識させられました。これは今後養っていきたいです。人に何かを移譲したり、決めるって本当に難しい...でもこれを社内のプロジェクトで経験しておいて良かったなと思います。

複数案件の要件定義(2ヶ月間)

以下のそれぞれのサービスの要件定義に関わることができました。

  • 教育系のコンテンツ配信サービス
  • 別会社の大学検索サービス
  • フリーランス求人サービス

お客様のお話を聞いたり、議事録などを元に以下のことを行なっていました。

  • 競合他社の調査
  • 機能一覧作成
  • 必要な機能のパターンを作成
  • 質問事項/不確定事項洗い出し
  • 画面一覧作成
  • 画面遷移図の作成

お客様とのMTGに参加するのが初めてだったので、とても良い経験になりました。お客様が求められているものが何で、どのような機能や画面が必要かを最初に一覧を作成する役割をすることが今までなかったので、とても勉強になりましたし、とても楽しかったですし、とてもやりがいがありました。

1年8ヶ月~現在

エンタメサービスのポイント/ランク基盤の開発(8ヶ月間)

こちらの開発は、フロントエンドの開発はなかったため、完全にバックエンドのみを行なっていました。こちらの案件も要件定義/基本設計/詳細設計/開発/テスト/保守運用まで関わることができました。特に最初の大学検索サービスの案件とは違って、0→1開発かつお客様のMTGに参加し議事録を記載し、要件定義にも最初から関わることができました。1つのサービスが何もないところからできるところを本当の意味で見ることができたのはこの開発になります。
主に行なったことは以下になります。

  • ユビキタス言語表の作成
  • 議事録の作成
  • MTGで出す一部資料の作成
  • 環境構築
  • Basic認証の実装
  • APIの作成
  • 不具合修正: バッチの修正/APIの修正/不具合の調査
  • テストケースの作成/テストの実施

この開発からがっつりKotlinを記載することになります。分からないことが多い中、環境構築もさせてもらい、APIも作成しました。不具合修正では初めてバッチの修正も行い、バッチというものがどういう構造でできているかも少しは理解できました。またこのサービスではCSVからデータを取り込みやCSVへの出力することがあったため、CSVを用いた開発の経験もすることができました。テストケースを作ることも行なっており、テストするために大量のCSVデータを作成したり、色々新しいことに挑戦させていただきました。

大学検索サービスの3次リリース(7ヶ月間)

今年の5月くらいからこのサービスのバックエンドの不具合修正もやらせてもらえるようになりました。そこから3次リリースに向けて以下のような追加開発を行なっていました。

バックエンド

  • 不具合修正: 機能の修正/不具合調査
  • 詳細画面の項目追加
  • 詳細画面の情報の2ヵ年表示
  • 検索の項目追加

バックエンドも開発を携わることになり、不具合が起きた際もデータベース、バックエンド、フロントエンドのどこで問題が起きているのかを理解することができるようになりました。また、開発する際もどこにどこまでの責務があるのかを考えながら開発することもできるようになってきました。
3次リリースにもなってくると、機能を追加する際に既存の機能に影響はないかを考えながら開発していく必要があるので、そこもとても勉強になりました。

教育系のコンテンツ配信サービス(1.5ヶ月間)

複数案件の要件定義の時に最初だけ要件定義に関わっていたのですが、開発は別の案件を担当していたため元々はアサインされていませんでした。しかしリリースまでにスタイルの修正を行う箇所が多いため、短い期間だけアサインさせていただきました。
弊社のデザイナーの方がデザインしたサービスのスタイルを修正していく　かつ サービスがカスタムされたWordpressで構築されている　の2点が今までと違う案件でした。
最初はWordpressでの開発を携わったことがなかったので、開発環境を整えるのにとても時間がかかりました。また、Wordpressの様々なプラグインを用いてカスタムしているので、CSSで当てているスタイルではなく、Wordpressのプラグインによる当てられているCSSなどがあったりと気が付くまで時間がかかることが色々ありました。
ここまでCSSに向き合うこともなかったので、短い期間でしたが今まで知らないことをたくさん知ることがありました。特にGoogle Chromeではうまくいくのに、Safariでうまくいかないことが多くて大変でした。
参考: SafariのCSS対策

またデザインは当たり前ですが、すべての画面幅を考慮しているわけではないので、ブレイクポイント周辺でスタイルがデザイン通りでは全くない場合に、どのようにするかなどを考えて提案することに力を注いでいました。
これは、一番最初の案件でフロントエンドの開発をしていた際に先輩方がすべての画面幅、対応ブラウザすべてで上手くいっているかの確認を入念にしていたのを見ていたので、違う案件でも違和感なく行うことができました。
おかでなんとかリリースすることができました！

まとめ

書いてみて感じたのは、意外と2年2ヶ月で色々することができたな〜と。
弊社ではエンジニアとしては女性は私だけですが、エンジニア以外の職種であれば女性の方はいますし、スクールで出会った人の中には女性もたくさんいます。
イベントに出ると確かに圧倒的に女性は少ないですが、IT業界は女性であるとか、学歴とかは比較的他の業界に比べて関係なく、会社で活躍ができると思います。
私は圧倒的に教員時代よりもエンジニア時代の方が幸せに仕事をすることができています。ですので、女性だからや、男性だからとか関係なく人のためになるサービスを作りたい！っと思っている方は是非一緒にエンジニアになって良いサービス一緒に作りましょう！！！
この記事が、誰かの何かのためになると幸いです。

Discussion