🔰

SES未経験エンジニアの心得

2023/07/27に公開

初心者

超簡単な自己紹介

未経験でSESに入社して2023年6月から現場に入ったエンジニアです。
メイン言語はJavaですが、未経験時代にJavaScript、Python、C++などを勉強して動かしていたので割と色々知っている…と思いたいです。

経緯

初めてエンジニア的な記事を書くので何書こうかな～と考えた結果、とりあえず自分はこんな事意識しながら初現場に入ったよ～って事を書くことにしました。なので心得ってタイトルですが、心得って言うほどかと言われると我ながら怪しいです。
~~でもクソデカ主語のタイトルの方がやっぱ目を引くよね~~

それはさておき、エンジニア未経験で実際現場に入るとなると、やはり色々不安な面があると思います。（技術面、どんな事やるのか、分からない事あったら etc…）
この記事でまとめたことを読んで頂けることで、その不安を出来るだけ解消して多くの人がエンジニアとしてやっていけるようになったら嬉しいなーと思います。

※あくまで個人的な心がけなので参考程度に捉えてください

心がけたこと

質問する時は、試したこと、エラーメッセージ、質問によって解決したいことをまとめてから質問をする
分からないことは分からないとはっきり言う
最初はシステムの全容をざっくりとした範囲で見る
ドキュメントは新しいのか古いのかを確認する
引き際は決めておく
気楽にやる

質問する時は、試したこと、エラーメッセージ、質問によって解決したいことをまとめてから質問をする

質問をする人の時間を極力奪わない

エラーの原因だったり業務上で分からない事があった時に質問をする時は、簡単でもいいのでまとめてから質問すると質問する相手の時間を奪わずに済みます。

どういう事かと言うと、例えば単に「○○が分からないです」と質問すると、質問された側は「それってつまりどういうこと？」「○○ってことは△△ってこと？」という感じで、どういった事を聞きたいのかを探ることから始めないといけなくなります。つまりアキネーターにならざるを得なくなってしまいます。

なので、聞く前にある程度は自分でも調べてみましょう。エラーメッセージをそのままGoogleに貼り付けたり、「Java 配列　順番に取り出す」みたいな感じで言語名とやりたいことで調べてみたりすると結構色んな情報が出てきます。

また、英語ばっかりで訳分かんないって人はDeepL翻訳という翻訳サイトにメッセージをそのまま貼り付けてどういう意味なのかを調べてみたり、今ならChatGPTに聞いてみたりしても情報が得られると思います。

そして、集めた情報を元にエラーの解決を試みましょう。出来なかったら、試したことと調べた内容をまとめて質問をすると、質問された側も質問内容が察しやすくなって質問を返しやすくなり、質問をする側としても知りたかったことが聞けてスマートな質問が出来ると思います。

ちなみにこの手の話でよく挙げられる話なのですが、15分～30分程自分で考えてそれでも分からなかったら質問をすると良いらしいです。
経験談なのですが、分からなかったことをいつまでも自分で悩んで時間を無駄に使ってしまい質問したらすぐに解消された、といったことが結構あったのでマジで助かりました。

分からないことは分からないとはっきり言う

分からなくて良い、皆分からんって言いながら仕事してる

本当は分からない事を「分かります！」って言って、いざタスクを振られると全然成果を出せない…ってなると、チームメンバーに迷惑がかかるだけではなく、自分も何も分からない状態でただ苦しい環境で仕事することになります。

なので基本的にはあまり虚勢を張らない方が良いかと。結果的にはその方が得するのではないでしょうか。（というか虚勢張ってまで仕事する必要、経歴詐称したときぐらいしかないと思うけど…）

現場の人は分からないので教えてくださいと言えば、結構教えてくれると思います。相手が未経験エンジニアだったり経験が浅いエンジニアと分かっているなら尚更、新しく現場に入ったエンジニアを右も左も分からない状態で放置することは余程の状況でない限りないと思います。

後で調べるなり聞くなりしておいおい理解していきましょう。

最初はシステムの全容をざっくりとした範囲で見る

全体像を簡単に把握する、最初から全部知るのはキツイ

参画する案件にもよるとは思うのですが、基本的にシステムの規模、とりわけソースコードやドキュメントといったものは想像よりも膨大であると思った方がいいです。
（案件にもよります、何度も言いますが）

もしかしたら現場に参画する前に研修でシステムの開発とか、WEBアプリの開発とかをやるかもしれませんが、現場のソースコードやドキュメントを見てみると面食らうかもしれません。
最初からシステムの細かい処理や一つ一つのメソッドの中身を理解しようとすると、多分マジで訳分かんなくなる可能性が高いです。

まずはどんな事をするシステムなのか、どんな処理をするのかをざっくり確認、そして実際に動かしてみてどんな動作をするシステムなのかを徐々に把握していくと、システムに対する理解が深まっていくでしょう。

ドキュメントは新しいのか古いのかを確認する

バージョン管理はソースもドキュメントも大事

研修や今の現場でもあったのですが、既存のシステムの改修がメインの案件とかだと昔のドキュメントと新しく作ったドキュメントが混ざっていることが結構あります。
しかもバージョン表記があって更新状況を管理しているなら兎も角、同じような名前で古いものをそのままにしている場合が多いので、新しいドキュメントであることを確認していないと無駄なことをして時間を浪費する恐れがあります。

ドキュメント内で記載してある日付やエクスプローラーの更新日時を確認しておくと、今も読まれているドキュメントなのか判断がしやすいと思います。
後は、プロジェクトの先輩方に聞くのが早いですね、やっぱり。

引き際は決めておく

無理な時は逃げるが勝ち

プロジェクトがヤバくなってそれがいつまでも続くようなら逃げましょう。

ていうか出来ればヤバくなった時点で逃げることを考えましょう。（ちなみにヤバいというのは俗に言うプロジェクトの炎上だとかそれに近い状況のことです）
私は逃げます。~~マジで付き合ってられん~~

言っては何ですが、準委任か請負か何かしらの契約を結んだだけの他社の人間とわざわざ一緒に地獄に落ちる必要はないと思うので、ヤバくなるかヤバくなる前兆が見えた時点で自社の営業に相談した方が良いかと思います。
（でも現場のエンジニアは炎上する前兆ってどうやって把握するんだろう…）

気楽にやる

気楽にやろう、それが一番

自分が失敗すると他の人に迷惑がかかる…
プロジェクトに遅れが出る…
等々、仕事を任される中で色んな責任が生まれると思います。

しかしだからといって心身ともに全力で打ち込んだ結果、潰れてしまっては元も子もありません。
体や心に限界が来そうになったり辛くなったりしたら、まとまった休みを取るなり現場を変えるなり転職をするなりして環境を変えましょう。メンターがいるのであればメンターに相談してもいいかもしれませんね。

自分の体を大切にしよう。

まとめ

あくまで私の考えでしたが、いかがでしょうか。
この記事がこれからエンジニアになりたいという方やエンジニア未経験の方にとって心の支えになってくれるとありがたいです。
未経験エンジニアに幸あれ。