未経験からエンジニアに転職したけど、
- 未経験者が現場に入って苦労することを知りたい
- 入社までにできることって何かあるの？
- 未経験からエンジニアになってリアルな声を聞きたい
という悩みについて僕の経験を全て晒し出します！
記事の信頼性
業務経験1年の僕がこれまでの仕事を振り返ることで、未経験エンジニアが実際の現場で苦労することの参考になるはずです！
本記事の内容
・未経験エンジニアの僕が現場に入り困ったこと
・チーム開発に慣れていない時の苦労
・人間関係の構築を最優先におこなうべき理由
目次
未経験エンジニアの僕が現場に入り困ったこと
未経験エンジニアにとって初現場は正直わからないことだらけです！
・環境構築に時間がかかった
・他人の書いたコードが読めない
・どう実装すれば良いのかわからない
・設計書が読めない
などが誰もが通る道なんじゃないかと思いますので、僕のリアルな経験を紹介していきます！
未経験は環境構築でつまずくことが多い
初現場にアサインし挨拶を済ませた後は、いよいよエンジニアデビューです！
作業PCを支給された後はほぼ確実に環境構築から始まるはずです。
僕は初日に作業PCを渡されて、Dockerインストールから起動までをやりました。
環境構築のマニュアルはあるのですが、細かい箇所や予期せぬエラーに遭遇した場合はマニュアルに載っていることが少ないので自分で調べながら構築する必要があります。
どうしてもわからない場合は、周りの人やリーダーに相談すれば速攻で解決すると思いますが、まずは自分で解決するという意識で取り組んでください。
自走力は後々に大きな財産になりますよ！
他人の書いたコードが理解できない
他人の書いたコードが理解できないことは未経験エンジニアにとってよくある悩みです。
例として、１つのcontrollerファイルに何千行とコードが書いてありコメントも残してはいるけど、そのコメントの意味さえわからず途方にくれることです。
アサイン直後は人間関係も良くわからないのでリーダー以外の誰に相談したらわからないし、絶望的な気持ちになります。
僕は出社2日目で改修作業を任されたのですが、メソッドが理解できず質問しようとしたのですが既に前任者が退職しており仕方なくコードを一行一行根気よく読むしかありませんでした。笑
設計書が読めない・わからない
個人開発の経験しかない未経験エンジニアで設計書を作れる人はいないと思います。
というよりも、アサインする前は設計書に触れる機会がありませんよね。
設計書は企業秘密の資料ですからインターネットで公開しているはずもないですしスクールなどで設計書の読み方について勉強することもないです。
僕もアサイン直後に設計書が読めずに苦労しました。
設計書には基本設計書と詳細設計書がありますが、その違いさえわからない状態でした。笑
設計書が読めないとどのように実装すれば良いか(リレーション関係やバリデーション等)がわかりませんし、せっかく実装したにも関わらず手戻りが発生してしまいます。(僕は設計書が読めず随分手戻りに苦しめられました。)
また、設計書の粒度が低く結局何もわからないことや、頻繁に仕様が変わり設計書の意味を成していない現場もあり戸惑うことが多いでしょう。
設計書については慣れるしかないです。
僕は毎日読み込んでわからなければ聞くという作業を繰り返しおこない理解しました。
どう実装(コーディング)すれば良いかわからない
前項とも関係するのですが、未経験エンジニアは設計書が読めないのでどう実装すれば良いのかわかりません。
ましてや、新規開発の場合は自分で１からコードを書く必要があるのでこれもまた絶望的な状況になります。
解決策として、汚いコードでも良いので何かしら自分で書いてみて、リーダーにコードレビューをしてもらう事です。
また、メソッド名や変数の定義の仕方など、その企業特有のコーディングルールを採用している可能性が高いです。
共有ファイル(wiki等)の中にコーディングルールがあれば良いのですが、無い場合はリーダーに確認する必要があります。
未経験エンジニアはチーム開発に戸惑う
個人アプリの開発しか経験のない未経験エンジニアにとっては現場にアサインしたら初めてのチーム開発を経験します。
企業・案件によってチーム開発のお作法というのがありますので、慣れる必要があります。
コーディング規約・コミットメッセージなどの標準規約を確認
コーディング規約はどこの現場でもあると思いますが、僕の職場ではGithubにコミットする時のコミットメッセージにもルールがあります。
ルールは簡単で、「コミットメッセージ内に振り分けられたタスク番号を必ず記入する」というルールです。
Gitコンフリクトの対応は慎重におこなう
Gitコンフリクトについての詳しい説明は省略しますが、簡単にいうと「変更内容をマージにより統合する際に、もし同じファイルの重複する部分が変更されていると、変更同士が衝突し「コンフリクト」と呼ばれる状態を引き起こす」ことです。(www.creatorsより引用)
つまり、もともとコードが書いてあった部分に重複して自分の変更を加えようとすると、「変更内容ダブってるけど、誰の変更を反映させるの？？」ってGitが問いかけてきます。
初めてコンフリクトを起こした時は正直かなり焦りましたね。なぜなら、下手な操作をするともともと書いてあったコードを消去してしまう可能性があるからです。
ですので、経験の浅いときはGit操作については特に慎重になり、コンフリクトを起こしたらすぐにチームの担当者へ共有しましょう！
僕は人間関係の構築を最優先した
前章では未経験エンジニアが初現場にアサインした場合によく起きる「困ったこと」について紹介しました。
正直、初現場はわからないことしかないので、頻繁にチームメンバーへ質問するはずです。
ここで大事なことはチームメンバーとの「人間関係」を構築すべきということです。
質問されるのを嫌うエンジニアがいる
ベテランエンジニアは質問されるのが嫌いな人が多い印象です。なぜなら、質問を受けることで自分の作業時間が奪われてしまうからです。
僕の職場でも自分のタイミングで質問するのに人に質問をされることを異常に嫌うめんどくさいエンジニアがいます。笑
初めはめんどくさいな〜って思っていたんですが、歓迎会でそのベテランエンジニアと話をしていつでも質問できる人間関係を築きました。
未経験エンジニアにとってコードを書けるスキルだけでなく、コミュニケーションを取れることも非常に重要なスキルなんだと実感しましたね。
結局、エンジニアであってもチームで仕事をする限りコミュニケーションは必須になります。
教えてもらう立場であり謙虚な姿勢を忘れない
これは精神論になりますが、未経験エンジニアは何もできない自分にベテランエンジニアがわざわざ工数を割いているという自覚を持って仕事するべきですね。
そのためにも素直に教えを実践し、教えてもらった事については休日に自分でもう１回勉強し直してみることで成長に繋がります。
【さいごに】初現場では自分で働きやすい環境を作る
初めての現場ではわからないことしかないです！！笑
すぐに馴染める人もいれば、中々馴染めることができずに退職してしまう人も僕は見てきました。
両者の違いは何か？という答えは簡単で、チームメンバーと普段からコミュニケーションを取っているかどうかの差です。
僕はチーム開発の利点は「わからないことをすぐにメンバーに質問できること」だと思っています。
そのためにもコミュニケーションをしっかりと取って、自分が働きやすい環境を作るようにして欲しいです！
今回はここまでにします！
エンジニアへの転職についてはこちらの記事を参考にしてください
[未経験もOK] Webエンジニアへ転職するために絶対に登録すべきエージェント3選！
コメントを残す