😎

アラサー・文系・エンジニア実務未経験・正社員未経験・ニート経験有の人間がエンジニアに転職して3ヶ月経ったので感じたことを書いていく

2022/08/07に公開

プログラミング

自己紹介

初めまして、yakisobaと申します。年齢は20代後半です。
今年の5月に実務未経験からエンジニアに転職し、現在は受託開発として、ある会社のサービスの開発/運用に関わらせてもらっています。

プログラミングの勉強は2020年の7月ごろからスタートしたので、約1年半ほどかけてエンジニアに転職することができました。（この辺りのことはまた別の記事で書きたいと思います。）

タイトルにある通り、自分は完全な超文系（ほとんど勉強せずにスポーツしかやってこなかった）で、そもそも正社員の経験もしたことがないですし、ニートだった時もありました。もちろんエンジニアの実務も経験したことがありませんでした。
そんな自分がエンジニアに転職して3ヶ月が経ったので、感じたことをつらつらと書き記していきたいと思います。
初めての記事なので、拙い文章になるかもしれませんが、ぜひ多くの方に読んでいただきたいです。
よろしくお願いします🙇‍♂️

この記事を読んで欲しい対象者

実務未経験からエンジニア転職を目指している方
実務未経験からエンジニア転職が決まってこれから実務に入る方
実務未経験から転職したエンジニアと仕事をしている（もしくはする予定のある）エンジニアの方

特に、2と3に当てはまる方にはぜひ読んでいただきたいなと思っています！

この記事を読んでわかること

実務未経験からエンジニア転職した経験に基づく、リアルな感想がわかる
実務未経験からエンジニア転職した時（したばかりの時）の悩みや不安に対する対策がわかる
実務未経験からエンジニア転職した方に対してどのように接していけばよいかがわかる

現在の自分の開発状況

まずは転職してから現在の自分の開発状況をまとめておきたいと思います。
現在関わっているサービス開発の構成/運用方法（一部省略しています）は下記になります。

機能など	サービス名など
フロントエンド	Nuxt.js
バックエンド	Firebase Functions
Database	Firebase Firestore
Storage	Firebase Storage
Hosting	Firebase Hosting
ソースコード管理	Github
CIツール	Cloud Build(GCP)
UIフレームワーク	Vuetify
チケット管理	Github/Zenhub
開発体制	スクラム

基本的には、自分ともう一人エンジニアの方の二人体制で日々開発を行なっています。
少ない人数で開発をしているので、転職してからはちゃんとした研修のような感じはなく、すぐに実務に入った感じです。
また仕事の環境はフルリモートで、MTGなどはSlackのhuddleやGoogleMeetを使って行なっています。
就業/終業時間は自分で管理、1週間のスプリント内で作業する時間も自分で管理して開発をしています。

3ヶ月経っての振り返り

それでは、本題に入っていきたいと思います。
ここでは実務未経験からエンジニアに転職して実際に実務をしながら思ったことなどを自由にゆるく書き出していきたいと思います。

いきなりフルリモートで開発するという環境に最初は慣れなかった

自分は前職までは、出社して仕事をする、というごく普通の仕事環境で仕事をしていました。
なので、転職してから完全フルリモートになった当初は「家で仕事をする」「誰とも喋らずに仕事をする（質問もSlackでテキストで）」といったことに慣れない部分がありました。（リモートで仕事するのが初めだったので当然ですが。。）
特に自分は未経験から転職して初めての実務でいきなりフルリモートだったので尚更慣れなかったのかもしれません。。

「見積もり時間通りにチケットを完了させなければ」という謎のプレッシャーを自分で勝手にかけて焦っていた

Zenhubを使ってチケットの管理をしているのですが、どのチケットを担当するかを割り振られた時に「どのくらいでチケットを完了できそうか？？」という見積もり時間を設定しています。
特に最初は「必ず見積もり時間通りに終わらさなければならない」「「早く成果を出さなければいけない」という謎のプレッシャーを自分自身が勝手に作って自分にかけていました。
こういう心理状況になると、余裕がない状態で開発をすることになってしまい、何一ついいことがありません。

見積もり時間と実際の作業時間の乖離が大きいので、落ち込むこともある

これは上に書いたものと関連しているのですが、特に最初は見積もり通りにチケットが完了するなんてことはまずありませんでした。
そもそも最初は、初めての実務で色々と勝手がわかっていないこともあり、精度の高い見積もりを立てることが難しかったです。（もちろん今も難しいし、できていないですが。。）
この現象が続くと、人によっては落ち込んだりして負のループに陥る可能性もあると思います。

割り振られたチケットをどういうステップで進めればいいのか分からない

チケットには「〇〇のXXが表示できるようにする」「〇〇の機能を追加する」のように、必ず実現したいゴールが設定されています。
ゴールはあるのですが、そのゴールを実現するためにどういうステップを踏めば良いかを考えても分からないことがありました。「これをすれば良いな」みたいにイメージができるステップもあるのですが、そもそも何をするべきががわかっていなかったり、ステップを考えても抜けているところがあって後から気づくみたいなこともありました。（今もありますが。。）

エラー出たら焦ってしまう

特に最初は、上にも書いた通り「見積もり時間通りに完了させなければならない」という謎の思い込みをしていたので、エラーが出た時は結構焦っていました。
こうなると、エラー解決する時の頭の中が「やばいやばい」になってしまって、解決するための思考をする余裕がない状態になります。
今思えばエラーが出るなんてすごく当たり前のことなんですけどね。。

どこが分からないかも分からない

結構あるあるなのではないでしょうか？？
どこが分からないのかが「分からない」という現象です。（今ももちろんありますが。。）
特に最初はサービス全体の把握もあまりできていなかったり、ソースコードを読み込めていなかったりで
「どこか分からないことがありますか？？」と聞かれても、「そもそもどこが分からないかも分からない😱」
といった感じが結構ありましたね。。

どう質問すれば良いか分からない

僕が開発に入った時には、質問方法のテンプレートみたいなものはなかったので、自分でエラーが解決できずに質問する時などは「どう質問すれば良いか」「何を書けばいいか」みたいなことを考えることが多く、質問する以前に無駄な時間がかかってしまう、ということがありました。

ライブコーディングはめっちゃ緊張するけど気づける点も多い

たまにライブコーディングをする時間をとってもらうのですが、それは今でもめちゃくちゃ緊張します。
自分がコードを書いているところをリアルタイムで見られているので、もうそれはめちゃくちゃ緊張します。
ですが、自分が書いているところを見られることで、「このショートカットキー使ったらもっと開発速度が上がるよ」「これは何でこのコード書いたの？？」などアドバイスをもらえたり、コードを書いた理由を考えられるので自分の成長にためには必要な時間だと思っています。

分からないことが多く自分の未熟さにへこむ

どんなことにも共通すると思うのですが、やはり最初は分からないことが多く、1つのことを調べて解決できても、分からないことが10個出てくる、みたいな感じの繰り返しです。
もうこれに関しては、一つずつ乗り越えていくしかないと思います。

コードレビューは色々突っ込まれる

普段コードレビューはPRを出した後にしてもらっています。PR出してからレビューをもらうまでの間の時間は結構緊張します。
コードレビューでは、「このコードを書いたのはなぜ？？」「この書き方はこっちの方がいいのでは？？」といったツッコミもありつつ「このコードの書き方良いね👍」といったレビューももらえるので非常に重要な時間だと思います。
ただコードレビューは、思っている以上に難しい作業で一歩間違えると人格攻撃にもなりかねない事態になるので、受ける側/行う側でコードレビューについて共通の認識を持っておくことが大事になってくると思います。

初めてmergeする時の緊張感が凄い

初めてチケットを完了して、本番環境にmergeする時は手汗が出るくらいにめちゃくちゃ緊張しましたね。。

実務未経験からエンジニア転職してこれから実務に入る方へ

ここまで自分の感じたことを自由に書きましたが、ここでは未経験からエンジニア転職する予定の方（したばかりの方）に向けて、実務に入る時に少しでも不安が和らぐようなことや注意点を書いていければと思います。

質問に関すること

前提として、リモートで作業する予定かつ下記のようなルールがない開発チームに入る方に向けて書こうと思います。

開発チーム内で質問方法が共有されていない
〇〇分たったら質問するみたい決まりが特にない

僕が参考にした質問テンプレート
どう質問すれば良いか、どういう書き方で質問すれば良いか、などを考えて時間を取られるのはあまり良いことではないと思っています。基本的なところはググったものを参考にしつつ、少しずつ慣れてきたら自分用にアレンジしてみたりするのが良いと思います。

僕が最初に参考にしたのが下記のQiitaの記事でした。まずはこのテンプレートに当てはめて質問してみる感じで良いと思います。

最近では少しアレンジした自分用のテンプレートを使って質問するようにしています。

もしテキストで質問するのが難しい！！と感じた場合
出ているエラーを解決できずに質問する際に、テキストにして質問することが難しい時があります。
確かに言語化して伝えることはすごく大事なことだと思うのですが、テキストでどう伝えようかを考えていたらいつの間にか時間が経っていた、ということも必ず出てくると思います。
そんな時は、何かしらのツール（Slack、Zoom、Meetなど）を使って画面共有しながらどういうエラーが出ているかを相手に伝えることで、相手もエラーの内容をすぐに理解してくれてスムーズに問題解決まで行うことができます。
なので事前に、チーム内で「テキストで質問するのが難しい時は画面共有しながらエラー内容を再現する」みたいなことを共通認識として持っておくことも大事だと思います。

どのタイミングで質問をするか？？
もし開発チーム内で、〇〇分でエラーが解決できなかったら質問する、みたいな決まりがなかった場合は、必ず最初に入ったタイミングでそこを決めてもらうようにしましょう。
ちなみにGoogleでは15分使って解決できなければ、他の人に聞く決まりがあるみたいです。
〇〇分については、各開発チーム内の事情などもあると思うのでそういったものを話し合って決めるのがいいと思います。

質問する上で大事なこと
質問する上で大事ことはいくつかあると思いますが、その中の一つに 「聞き方」 があると思っています。
例えば自分は最初、「〜が分からなかったので解決方法を教えてください」というような聞き方をしてしまってました。要するに「答えを教えて」って聞いているようなもんですね。
これでは仮に回答を得られたとしても、自分の成長には繋がりません。どこが原因でどういう過程で答えに至ったがわかっていないからですね。

なので最近では「~というエラーが出て、自分はこれが原因だと思って、これとこれを試したけどエラーが解決できなかった。このエラーの原因は何だと思いますか？？」というような聞き方をするようにしています。

開発速度に関すること

最初はとにかく開発速度が上がらないので、一つのタスクを完了するまでに時間がかかります。
前述した通り、「成果を出さないといけない」「見積もり通りに終わらせないといけない」みたいな謎のプレッシャーを自分自身にかけてしまうかもしれません。

まず一つ言えるのは、「誰もあなたに期待していない」 ということです。冷静に考えると、未経験から入ってきた人に対して、周りの人はいきなり成果が出せるとも思っていないでしょうし、期待もしていないと思います。
なのでそのことに関しては安心してほしいと思いつつ、でも実際はプレッシャーを勝手に感じてしまったりするんですよね。（誰からもかけられていないのに） 少なくとも自分はそうでした。ある程度の慣れは必要なんだと思いますが、せめて「誰も自分に期待していないんだ」というのだけは頭の中に持っておいてほしいと思います。

そして似たようなことなのですが、「自分で自分の期待値を上げすぎない」 ようにするのも一つだと思います。
自分は、他のエンジニアの方がどんどんタスクを完了していくのを目にして、自分も同じようにしないといけない、みたいなことを思ってしまい、自分で期待値を上げてしまっていました。こうなると現実の自分と理想の自分のギャップに大きな開きができてしまって、その差の大きさに落ち込んでしまいます。特に最初は期待値を上げすぎると現実と理想のギャップに苦しんでしまうので、理想は理想として持ちつつも、しっかりと今の現実を見つめることが大切だと思います。

突然ですが、ここで一つ記事を紹介させてください。
LAPRAS株式会社でフロントエンドエンジニアをされている川俣涼さんの記事です。
特に未経験からエンジニアを目指している方（目指していた方）はこの方が書かれているQiitaやZennの記事を何度も見たことがあると思います。
下記の記事では、今書いたようなことがわかりやすく書かれているので、是非皆さんに読んでほしいです。。
https://job.newspicks.com/articles/849

開発をする前に

もし開発をする前に時間が取れるのであれば、ソースコードをじっくりと読んでキャッチアップしたり、サービス全体がどういう動きをしているか、などを確認するのは必須の作業だと思います。
またデータベースがどのようなデータの持ち方をしているのか、コードを書く上での命名規則など、開発チーム内での決まりなどもしっかり確認できると良いと思います。
もし時間が取れなかった場合は、業務外の時間を使ってでもある程度の理解をするためにキャッチアップはしておいた方が良いと思います。

見積もりに関すること

最初から精度の高い見積もりをすることは不可能だと思います。
一番してはいけないミスが先ほどの「成果を出さないといけない」みたいなことを考えてしまい、ぎりぎりの時間で見積もりを設定することです。 とにかく最初は余裕を持って設定して良いと思うし、周りも必ず許容してくれるはずです。おすすめは 「これくらいでできそう」と思った時間を更に1.5倍くらいした時間 で見積もることです。
見積もりをきつく設定した場合、その時間で達成できないことが続くと、チーム全体の計画に変更が生じてしまいます。 なので、ある程度余裕を持った時間を最初から見積もることで、時間内で達成できる可能性も上がり、チーム全体の計画もうまくいくと思います。

コードは動いたからOKではいけない

当たり前ですが、コードを書く時は必ず自分で意味を理解して書くようにしましょう。
恥ずかしながら、自分は意味の分からないままコードを書いてしまうことが何回かありました。。。
意味を理解してコードを書かないと、そのコードが原因でアクシデントが起こった時になぜそのコードを書いたかの理由が説明できないですよね。。
ということはなぜそのアクシデントが起こったかの原因も分からないことになってしまいます。
コードは必ず意味を理解して書くようにしましょう。

下記のQiitaの記事が参考になります。

コードレビューを受ける心構えについて

下記の記事が非常に参考になります。

実務未経験から転職したエンジニアと仕事をしている（もしくはする予定のある）エンジニアの方へ

ここでは、実務未経験から転職したエンジニアと仕事をしている（もしくはする予定のある）エンジニアの方向けにどのように接すれば良いか？？みたいなことを、未経験者側の視点から書いていければと思います。

コードレビューする時の心構えについて

これを見ている皆さんはコードレビューをする側になると思います。
コードレビューはする側の人次第で全てが決まると言っても過言ではないと思うので、是非下記の記事を見てほしいです。
コードレビューをする前に、コードレビューに関しての共通認識を持つことが大切だと思うので、下記の記事をレビューイと一緒に見てほしいです。
ただ記事を共有するではダメで一緒に読みながら見ることがポイントだと思います！！

開発ドキュメントは用意しておく

もし開発ドキュメントがない。。みたいな状態であれば、必ず用意しておいた方良いでしょう。
開発チーム内での決め事や命名規則、コードに関すること、　新しく入ったエンジニア向けの資料などなど。
あらゆるものを用意しておくことが大切だと思います。

めちゃくちゃ質問Welcomeです！！という雰囲気を出しまくる

いつでも質問Welcomeです！！みたいな雰囲気を出しまくってほしいと思います。
大事なのはその雰囲気作りなので、いろんなシーンで新しく入ってきた人に伝えてほしいなと思っています。
実際には質問する側は緊張しているので、いくら雰囲気が良くても最初は質問しづらかったりするかと思います。でもその雰囲気を常に作っておくことで、いつかのタイミングから積極的に質問できたりすると思うので、雰囲気作りはしておいて損はないと思います。

たまにライブコーティングをして自分が書いている様子を見てもらったり、逆に見る機会を設ける

もしライブコーティングできる時間があれば、是非行ってほしいと思います。
自分が書いているコードを見てもらっている場合は、今どのようなことを考えてコードを書いているのかなどを、独り言みたいな感覚で声に出しながらしてもらえると、見る側は結構勉強になったりします。
逆に書いているコードを見る場合は、ショートカットキーやコマンド操作に慣れていない場合もあるので、開発速度を上げるためにそういった操作を覚えてもらったり、なぜそのコードを書いたのかなどを聞いてみて、理由を考えてもらったりするのも良いかもしれません。

最後に...

かなり長い記事になってしまいましたが、今回の記事はいかがだったでしょうか？？
この記事を読んで良かったなと思ってくださる方が一人でもいると嬉しいです！！
いいねやツイートをしてもらえると更に嬉しいです👍
内容は随時アップデートしていく予定です。
自分と同じような境遇の人で、もっとこういうことも書いてほしい！！みたいなことがあればどんどん教えてほしいです🙏

最後に記事とは関係ないのですが、一点お願いです🙇‍♂️
自分は現在、福岡在住なのですが普段がフルリモートということもあり、他のエンジニアの方と交流する機会が全くありません。。。
もしこの記事を読まれている方の中に福岡在住（もしくは近県に住まれている方）でエンジニアの方がいらっしゃいましたら是非交流したいなと思っています。会ってもいいよ！という方はコメントやTwitterの方で教えていただけると助かります。よろしくお願いします！！