はじめに
Qiitaの投稿は初なので、ちょいと緊張しています^^;
簡単に僕のプロフィールを紹介します！（2022年5月現在）
- 28歳・男性
- 某地方国立大学大学院卒（情報系ではなく化学系）
- 大学在学中に長期インターン経験あり
- ネイティブ系の経験（C# PostgreSQL/半年）
- フロントエンドの経験（Typescript × React/1年）
- バックエンドの経験（Ruby on Rails/7ヶ月）
- インフラの経験（AWS Terraform/9ヶ月）
この記事では、主にエンジニア初心者の頃の自分が先輩エンジニアに教わったこと/怒られたこと/感じたこと、現在エンジニアとして少し成長した自分目線で過去を振り返ろうと思います。
仕事中や勉強中の合間の息抜きがてら読んでいただけたら幸いです！
エンジニア1年生の頃
まえがき
僕は大学時代にITのベンチャー企業で長期のインターン活動をしていました。
そこまでプログラミングをガッツリとしていた訳ではなく、簡単なページを作成したりデザインの修正をしたりしていました。
また、1社目の9ヶ月間はQAエンジニア（テスター）として働いていたのでここもプログラミングはしていません。
よって、「0知識」でエンジニアとしてスタートした訳ではありませんが、かなりレベルの低いところからのスタートであることは確かです笑
ここから本題
1社目の9ヶ月間が終わった後に部長と今後について色々話す機会があり、その流れで部署を変更して「開発部」に異動しました。（ここからエンジニアとしてスタート）
最初の数ヶ月は「プログラミングの基礎学習(C#, Javascript) + DB(SQL)の基礎学習」をCodecademyというサイトで学習しました。（※全部英語なのですこ〜し苦戦しました。）
そこまで難しい感じではありませんでしたし、プログラミングの学習サイトで勉強するのは本で勉強するのと違って環境構築とかもなく、簡単に始められたので楽しかったのを覚えています。
そして、進捗を毎日上司に報告するといった感じで進めていました。
ここの部分に関しては、初心者でプログラミングを仕事終わりに確保しなければいけない学習時間を業務の時間内にできたということでラッキーでしたね。
そして、1つ目のプロジェクトにアサインされ、C#（.NET Framework） を使用したネイティブアプリの保守・運用業務が始まりました。この業務では主にお客さんからあがった不具合の修正や機能の一部を改修するといったことをやっていました。
「やっと実務に入れるぜ〜！」と意気揚々と取り組んでいましたが、以下の問題点がありました。
- コードがやたらと膨大
- コメントがほとんどない
- 仕様がかなり複雑（物流系）
- DBの構造が複雑
- 基礎学習しただけじゃそもそもコードが追えない
- 色々なツールを使用していたので頭の中がぐちゃぐちゃ
実務のプログラミングを甘くみていました。
特に苦戦したのは オブジェクト指向の考え方 型定義 デバッグ方法 あたりですね。
基礎学習でなんとな〜く分かった気になっていた部分で躓きまくりました。
また、ソースコードの読み方（追い方）について、分からない部分を上司に聞いては「〇〇の用語の理解が甘い」「バグの原因の根拠は？」「このメソッドの処理はしっかり分かって使ってる？」「なんでデバッグしてちゃんと追わないの？」「〇〇型について公式ドキュメントで確認した？」「ここの処理条件分岐する意味ある？」などなど言われたりしてましたね...(辛い)
上記のような言われ方をされていた訳ですが、なんだかんだソースコードの追い方や用語の意味、メソッドの使い方などを教えていただきました（その節はありがとうございました🙇♂️）
また、Redmineの書き方、DBやGit等のクライアントツールの使い方、Visual Studio(エディタ)でビルドする方法やデバッグ方法もこの時に教えていただきました。
ここで、ただ受け身になって教えてもらうだけではなく、教えてもらった後に自分で実際に色々と試したり、メモを取って同じことを2度聞かないようにする、後輩ができた時にスッと教えてあげられるように手順化したドキュメントを作成したりすることを意識していましたね。（過去の自分ナイス！）
逆に、この時の自分の反省点として自宅学習をあまりやらなかったことですね。
エンジニアになって最初の1〜2年程度はプライベートの時間も学習にあてると成長は段違いに早くなると思います。（過去の自分アホぽーん！！）
そんなこんなで半年経った後に、次はモダンな技術である Typescript × React と AWS を使用したプロジェクトにアサインされました。正直なところ、C#（.NET Framework） を使用したレガシーな技術を使う業務はあまりテンションが上がらなかったので、このプロジェクトにアサインされた時は「学習欲」が爆上がりでした。
ただし、ここからまたまた辛い半年間が待っていました...orz
前回の反省を活かし、新しいプロジェクトにアサインされてからは自宅学習も結構するようになりました。
ともいうのも、新しいプロジェクトの上司が厳しく、期限やコードの書き方についてめちゃくちゃ指摘してくる（してくれる）タイプだったので「ヒーヒー」言いながらやっていたのを覚えています。
また、同時にAWSの構築関連の業務もあり、これも初めてのことだったので何がなんだか分からず調査しつつ、ベストプラクティスな設定をしてリソースを作成し、自分たちが作るサービスに合うかどうかの検討をしたりもしていました。
この時期は非常に辛く、何が辛いのかというと「技術力のなさ」「仕事が期限内に終わらない」「メンバーに信用されていない感がある」「勉強しても点と点がなかなか繋がらない感じ」でした。
ついていくだけで精一杯という1年間を過ごしましたが、幾分エンジニアとして基礎的な知識がつき、かつ業務の進め方だったり、よく使用するツールの使い方だったりを学べた良い1年でした。
1年やってみての所感としては、
- かなり勉強しても次から次へと分からないことが出てくる
- 技術力がないと信用がなかなか得られない
- メソッドや用語の使い方が間違ってたりすると激詰めされる
- 基本的に辛い時間の方が長いが、解決法が分かった瞬間や動いた瞬間の気持ち良さは格別
- なんだかんだ面白い
といった具合ですね！笑
エンジニア2年生の今
転職
「エンジニア1年生」を卒業するのと同時に、プライベートな理由で転職をしました。
2社目は フルリモート フレックス 年俸制 モダンな技術を使用している 自社開発 みたいな僕にとってはかなり好条件の企業に決まりました。
入社して最初の頃は仕様に慣れてもらうという目的で「運用系タスク」を割り振ってもらい、同時に担当業務は僕の希望にも沿ってサーバーサイドを任せてもらいました。
サーバーサイドでは Ruby on Rails を使用していて、インターン時代に若干やったことはありましたが全然覚えておらず、自宅学習で Ruby on Rails チュートリアル を進めつつ業務に活かすということをしていました。
この時期は特に難しいこともあまりなく、他の人が書いたソースコードを参考にしたりして修正していました。
またも試練
「運用系タスク」を数ヶ月こなした後、仕様にも慣れてきたのと人的リソース不足のプロジェクトがあったのでそちらにアサインされました。（ここまではOK）
しかし、ここでいくつかの問題がまた起こりました。
1. 色々なドキュメントを確認して能動的に情報を取りにいかなければいけない
2. API設計とかやったことないし、そもそもRailsを深く理解していないから実装方法が分からない
3. 工数見積もりをしなくてはいけない
4. 1〜3がよく分からなくて不安状態
(1) 前職では実装すべき仕様の部分はすでに仕様が決まっていて、「ここに気をつけてこういう風に実装して」という感じだったので、言われた部分をただコードに起こす作業をしていただけだったので最初戸惑いました。この点に関しては、つい誰かが自分に実装に関して説明してくれて自分はその通りにやればいいだけという自分の考え方も甘かったのですが、前職では色々と面倒見てくれていたんだな〜と感じました笑
この点については、①仕様が書かれているドキュメントを読み込んで、②やるべきタスクをリスト化し、③ソースコードを読んでどこにどう書いていくのかを決める という作業の流れを実行することで解決しました。
(2) これはやったことがなかったのでかなり悩みましたが、①APIの設計方法をググって学習し、②Railsのお作法を学習し、③フロント側で欲しいパラメータを抽出して、④実装（既存の流用できるものがあったのでラッキー）という感じで最初は進めました。その後はコツが掴めたので時間はかかっていますが実装はできています。
(3) ここについて、普通のエンジニアなら「何当たり前のことを？」と感じるかもしれませんが、僕にとっては当たり前ではなかったのです。と言うのも、前職では工数の見積もり自体先輩エンジニアがやってくれていて自分でやったことがなかったので、これもどうすればいいか悩みました笑
工数の見積もりに関しては、完璧に見積もることはほぼできないと思っていて、「いかに精度を上げられるか」が重要になりますね。手順としては ①着手するタスクの優先順位をつけて、②仕様や設計からソースコードを読んで「この期間なら絶対に終わらせられるという最短の時間」を算出し、③作業量とリスクを考慮して適切なバッファーを積み、④プロジェクトの期限と照らし合わせてギリギリまで工数をもぎ取る という風にしています笑
ちなみにこれは上記の1と2ができること前提になります！
(4) 1〜3がある程度できるようになってきたら特に不安もなくなってきました。「その不安はどこからくるのか？」と上司の方に聞かれたことがあって、「そもそもやったことがないので言葉では表現できない漠然とした不安です」と回答して、その後詰められました笑
問題は 言語化できなかったこと にありました。
自分の不安要素を言語化し、不安要素を細かく分けていくと案外簡単だった！って感じになり、不安が払拭されました。なので、皆さんももし初めてやるから分からないこと、不安なことがあったりしたらまずは 不安要素を言語化 してみて、その後タスクを細分化してみることをオススメします！
これをやってみると、一見難しいと感じるタスクも簡単なタスクの集合体であることに気づきます！
そうなったら、もう勝ちですね👍
色々と語ってきましたが、普通のエンジニアになるまでに意外と躓きまくってきましたね^^;
僕自身、技術面はまだまだですが、指摘されたことに対して地道に試行錯誤してきました。ぶっちゃけ企業が経験者を欲しがる理由って技術面も多少はありそうですが、どちらかと言うとエンジニアとしての業務を遂行する考え方を持っている人が欲しいという気がします。
さらに言うならば、技術的にはまだまだでも「未知なタスクにチャレンジする」という気概と問題点から逆算して問題解決できる能力があることが望ましいと思います。
今後について
これからの目標は「強いエンジニアになる」というのはカッコつけすぎなので、純粋に自分の市場価値を上げることですかね。 結果として「強いエンジニア」に近づいてればまぁOKといった感じです笑
そのためにこれからやることとして、個人開発をやろうかなと。
市場調査→設計→実装→運用 と一通りサービスを作る経験をしてみようと思います。
ちなみにですが、「できれば収益化」みたいな弱い感じではなく、やるからにはガチで収益化を狙いにいこうと思います。技術的な勉強以外の部分でも知見が得られそうなのと、まぁ暇なので！笑
副業ブームが騒がれる昨今ですが、実際に副業で大きな収益化を狙うのには結構な時間と運が必要になると個人的には思っています。
それよりも、本業収入を上げることに時間と労力を投下し、生活費以外の浮いたお金を投資関連に振り分ける方が賢い選択なのかな〜と。まぁインフルエンサー業やYoutuber向きな人もいるとは思うので、全員が全員そうではないと思いますが、僕自身の自己分析をしてみた結果としてはそういう結論に至りました。
なので、今後はプログラミング、設計、インフラやセキュリティといった分野へのコミットを8割、投資やトレードなどの取り組みを2割くらいのペースで数年間過ごしていこうかなと思います。
引き続き、Qiitaへのアウトプットも緩く続けれればな〜と思います👍