【新人エンジニア】辛いあるある9選と解決策

※本サイトはアフィリエイトリンクを掲載しています。
新人エンジニア

Web系エンジニアのカズです。エンジニア歴は7年ほどになります。

主にバックエンドエンジニアメイン+フロントエンド+チーム全体の進捗管理の業務を担当しています。

私が新人エンジニアの頃の失敗談や、業務で新人エンジニアさんと関わる中で感じることを元に記事を書きます。

この記事を読んでいただくことで悩んでいることの解決方法が提示できれば幸いです。

また、あるあるに共感いただくことで不安を払拭できればと思います。

主に新人プログラマーの方に向けて、書いた記事になります。

 

本記事の内容

・分からないと言えず、質問できない

・先輩に嫌われてしまう質問の仕方をしてしまう

・周りの人の立場や接し方が分からない

・タスクのゴールを明確にできない

・タスクの期限を確認しない

・タスクの細分化ができない

・タスクの見積もりをしない

・進捗報告を細かく共有できない

・既存のソースコードが理解できない・見ない

・【おさらい】新人エンジニアさんが意識するべきこと

 

分からないと言えず、質問できない

質問できない原因は、下記のような理由があるのではないでしょうか。

 

質問できない原因

①スキルがないと思われてしまう。実力がないと思われてしまうのではないか。

②誰に質問していいのか、分からない。

③質問の仕方が分からない

④自分一人で問題を解決したいから、質問しない。

 

①スキルがないと思われてしまう。実力がないと思われてしまうのではないか

新人の頃は不安で、このように考えてしまいがちだと思います。

ですが、一人で解決できないことは誰でもあります。

新人の方なら分からないことが多いのは当然です。

まず、自分で調べてみて理解していることと分からないことを整理しましょう。

人によるとは思いますが、「調べて解決する姿勢があって、どうしても分からない状況」であれば嫌な顔をする上司は少ないと思います。

新人エンジニアさんの場合は現在のスキルも重要ですが、「今後スキルアップが望めるか」を評価されている場合もあると思います。

積極的に問題に取り組み、スキルアップしていくことが重要だと思います。

 

②誰に質問していいのか、分からない

誰がどういう立場の方なのか、分からないこともあるかもしれません。

自分と役割が同じ、または近い人が誰なのかを事前に確認しておきましょう。

フロントエンドエンジニアであれば、フロントエンドエンジニアの先輩バックエンドエンジニアであれば、バックエンドエンジニアの先輩に質問しましょう。

 

③質問の仕方が分からない

どう質問すれば良いか分からず、結局質問できないことがあるのではないでしょうか。

解決できないことを放置していても納期が迫ってくるので、上手く質問をして作業を進めていきましょう。

質問する時に、おすすめなテンプレートがあります。下記は、あくまで参考です。

 

解決策:質問の仕方テンプレートを参考にする

質問テンプレート参考例(コーディング編)

①実現したいこと(期待値を示す)

②現状どのように、上手くいかないのか

③どの処理まで正常に動いているのか

④原因だと思われそうな箇所

1時間~3時間調べてみて、どうしても分からない場合は質問しましょう。(自分で調べる時間の目安は現場のスピード感によります。)

 

④自分一人で問題を解決したいから、質問しない。

自己解決しようとするのは良いことだと思います。

ですが、タスクの期限に間に合うかを考慮して、最終的には期限に間に合うように調整することが重要です。

 

先輩に嫌われてしまう質問の仕方をしてしまう

「自分が辛い状況だとやってしまう。」あるいは「楽をしたくてやってしまう。」こともあるかもしれません。(私も過去やってしまっていたかもしれません。)
下記の質問の仕方をしないように、注意すると良いでしょう。

 

嫌われてしまう質問の仕方3選

・本人が投げやりになってしまっている質問の仕方

・相手への負担を減らす配慮が見られない質問の仕方

・答えだけを求めていて、理解をしようとしない質問の仕方

3つに共通して言えることですが、自分が頑張っている姿勢が見えないと相手も答える気にならないということですね。

 

 本人が投げやりになってしまっている

どうしても上手く動かないときに、質問するのは問題ないです。
ただし質問するからといって、全てを相手にお任せするスタンスになってしまう事があるのではないでしょうか。
エラーと格闘して苦労したあまりに、そうなってしまいがちです。
私も初心者の頃はやってしまっていたかもしれません。
「自己解決したい」「ちゃんと理解したい」など前向きな姿勢が伝われば、相手はそんなに嫌な思いはしないかと思います。

 

相手への負担を減らす配慮が見られない

「質問をわかりやすく、まとめていない」「納期ギリギリに質問攻め」などですかね。

質問テンプレートを参考にしながら、なるべく相手にわかりやすい形で質問しましょう。

 

答えだけを求めていて、理解をしようとしない質問の仕方

理解より答えを優先してしまうと次に似たようなことが起きたときに、同じような質問をしてしまう可能性があります。

同じようなことが起きたら、次は自己解決できるようにプロセスを理解しながら質問しましょう。

 

周りの人の立場や接し方が分からない

チーム構成が良く分からず、「誰がどの立場の人のなのか分からない」「質問しにくい」という状況があるのではないでしょうか。

どのような立場の人が一緒に仕事をするのかを、例を挙げてみます。

 

チームメンバーの役割一覧サンプル

・チームリーダー
チーム全体の進捗管理、タスクの割り振りなどをおこない、プログラム構成にも詳しい方。・バックエンドエンジニア
設計、バックエンドのコーディングをする人

・フロントエンドエンジニア
フロントエンドのコーディングをする人

・SE
全体の仕様を決める人

・ディレクター
全体の仕様を決める人。スケジュール管理やその他諸々の業務をおこなう人

・デザイナー
 レイアウトを作成する人、デザインを決める人

※それぞれの立場の人の役割は、会社や現場によって異なります。(上記は参考例)
全ての立場の人がいる現場は少ないと思います。
大まかに言えば、この中のいずれかに該当する人がチームにいて仕事をすることになるでしょう。

 

【正社員の人】なのか【SES(客先常駐)の人】なのか

現場のチーム構成によりますが、正社員の人の方が詳しいこと、SES(客先常駐)の人の方が詳しいことがある場合があります。
質問のしやすさも、正社員の方が質問しやすい内容とSES(客先常駐)の人の方が質問しやすい内容があるかもしれません。
誰がどの雇用形態なのかも把握しておくと良いでしょう。

 

タスクのゴールを明確にできない

なんとなく、そのタスクに着手してしまう事があるのではないでしょうか。

タスクに着手する場合、タスクを完了することで何ができていれば良いのかを明確にする必要があります。

ゴールを明確にし、エビデンスを残すことが重要です。

そのタスク関連の不具合が後々に見つかった場合でも、そのタスグのゴールが明確であれば不備を指摘されることを防ぐことができます。

 

タスクの期限を確認しない

期限を確認せず、自分のペースで作業してしまう場合があるのではないでしょうか。

タスクについて期限が記載されていなくても、チーム全体では期限の認識が頭の中にある状態で、自分にだけ共有されていない状況もあり得るかもしれません。

タスクに着手する前に期限を確認しましょう。

 

タスクの細分化ができない

タスクの規模が大きいと作業工程が分からない。

何をどのように作業すればよいか分からない。という状況に陥ることもあるでしょう。

タスクの細分化ができていない状態で、作業を進めてしまっても設計が間違っていて作業を最初からやり直さなければいけない事になりかねません。

タスクの細分化ができてから作業に着手しましょう。

 

解決策①:タスクの細分化の参考例を真似る

例えば、新規登録画面の作成をする場合のタスクの細分化の一例を挙げます。

 

タスクの細分化の参考例

・画面設計をする(どの画面から遷移するか。どの画面が必要か。)

・DB設計をする

・テーブルを生成する

・モデルを生成し、必要な情報を定義する

・コントローラーを生成し、必要なロジックを洗い出す

・viewを生成する

・ルーティングを設定する

・エラーハンドリングを考える(ログをどのように残すか。バリデーションチェックは何が必要かなど。)

上記は新規案件の場合です。

新人の場合、もう少し軽微な改修内容のことが多いかもしれません。

ですが、現場によっては上記のように設計からタスクに含まれる場合も可能性としてはあり得ます。

タスクに着手する前に、何をどのように作業していくのかを明確にする必要があります。

 

解決策②:学習をする(成果物を0から作成してみる)

アプリや機能など成果物を0から実装することで、設計力や実装力が身に付きます。

結果タスクの細分化ができるようになるでしょう。

設計力については本で学習することも可能です。

「こんな設計はやってはいけない」ということが学べます。

 

解決策③:先輩に相談する

実装想定を先輩に相談し、問題ないかを確認してみましょう。

実装着手する前に、間違いを防ぐことができます。

実装想定ができない場合は、仕様や実装の仕方など理解できていない事があるはずです。

何が分かっていないのかを明確にして、相談してみましょう。

 

タスクの見積もりをしない

タスクの見積もりとは、「全体の工数がどのくらいかかるか。」

「タスクの細分化をおこない、それぞれの作業工程でどのくらい工数がかかるか。」を事前に計算しておくことです。

タスクについて細分化ができなかったり、何をどう作業すれば良いかが分からないと見積もりができないことがあるでしょう。

 

解決策①:タスクの細分化をする

タスクの細分化をして、どの工程にどのくらいの時間がかかるかを細かく計算しましょう。

慣れないうちは予定通りいかないかもしれませんが、何度も繰り返すことで精度を上げていきましょう。

 

解決策②:タスクの見積もりが難しい場合は先輩に相談しよう

タスクの規模が大きい場合は、見積もりから先輩や上司に相談する方が後々のトラブルを防ぐことができます。

タスクを細分化して、どの工程がどのくらい工数がかかるのか洗い出しましょう。

新人エンジニアさんの場合、そのタスクの規模が良く分からずに何となく作業して見積もりが大きくズレてしまう場合があります。

 

注意しなければいけないこと

一番怖いのは自分で見積もった内容が根本的に間違っていて、最初から作業をやり直すことになり納期に間に合わなくなることです。

見積もりの段階で不明確なことは、なるべく解決していきましょう。

参考までに本もご紹介します。

 

進捗報告を細かく共有できない

先ほどのタスクの細分化や見積もりに関連することですが、何をどのように作業するか理解していない場合に起こりやすいでしょう。

また、作業に行き詰って解決できないことを報告することで、「評価が下がってしまうのではないか。」と考えてしまうことがあるのではないでしょうか。

新人エンジニアさんだけではなく、ベテランエンジニアさんでも作業に行き詰まることは良くあります。

不安に思わず、そのままの状況を進捗報告しましょう。

 

解決策:進捗報告の仕方の例を参考にする

進捗報告の仕方の参考例

・タスクの細分化をし、タスク全体の作業内容を全て共有する

・タスク全体の作業内容の中で、どの工程がどのくらい進んだのかを報告する

・行き詰っている箇所や困っていることを隠さず伝える

もし行き詰っている場合は、先輩エンジニアさんが手助けしてくれる場合があります。

または、納期を延ばすなど調整をする場合もあるでしょう。

納期ギリギリに進捗が悪いことが発覚した場合は、それらの対応が難しくなるので注意しましょう。

 

既存のソースコードが理解できない・見ない

「既存のソースコードが理解できない・見ない」原因は下記があるのではないでしょうか。

 

「既存のソースコードが理解できない・見ない」原因

・学習が個人開発中心だったため、チーム開発に慣れていない

・チーム開発に慣れていない結果、他人のコードを読むことに慣れていない

・コーディングの仕方が、自分の書き方でなければ書けない

・既存のソースコードがヒントになることに気付いていない

既存のソースコードに答えがあることは、実は結構あります。

過去に似たようなタスクを誰かがやっていて、それを複製または再利用すれば完了できる場合です。

まずは既存のソースコードをじっくり読み理解することから、始めましょう。

チーム開発すると、既存のソースコードの量に圧倒される場合があります。(私も過去経験しました。)

 

解決策:既存のソースコードの読み方を鍛える(バックエンドエンジニア編)

バックエンドエンジニアの場合は、まず下記の点を大まかに把握したいです。(Laravel前提)

①DBの構成を見る。テーブルの親子関係など

②各テーブルのデータが、どの画面に使われているか把握する

③CRUD処理をしているソースを見る

あくまで参考ですが、これらが把握できると大まかな流れは掴みやすいです。

 

①DBの構成を見る。テーブルの親子関係など

DBツールなどを使用して、DB全体の内容を把握しましょう。

Laravel前提の話になりますが、親子関係などテーブルの関係を見たい場合は、対象のModel(モデル)ファイルを見て確認できます。

 

②各テーブルのデータが、どの画面に使われているか把握する

Laravel前提の話になりますが、モデル名やテーブル名と似た名称で、controllerが生成されているはずです。

ルーティングファイルを見て、そのcontrollerを読み込んでいるurlの画面を見ることで確認が可能です。

③CRUD処理をしているソースを見る

Laravel前提の話になりますが、controllerかrepositoryにロジックが記載されているはずです。

大まかな処理の流れを見ると良いでしょう。

 

解決策:既存のソースコードの読み方を鍛える(フロントエンドエンジニア編)

フロントエンドエンジニアの場合は、まず下記の点を大まかに把握したいです。

①レイアウトの共通ファイルを把握する

②プラグインの把握をする

③バックエンドエンドとのデータの受け渡し方法を把握する

④どのviewファイルがどの画面に適用されているのか確認する
(どのフレームワークを使用するかによって確認方法が異なる)

あくまで参考ですが、これらが把握できると大まかな流れは掴みやすいです。

 

①レイアウトの共通ファイルを把握する

大抵は、レイアウトの共通化処理はされているはずです。

レイアウトに限らずですが共通ファイルにどんな処理が書いてあるかは把握しておく必要があります。

 

②プラグインの把握をする

例えばdatepickerなどのカレンダー機能など、プラグインやライブラリを使用している場合は良くあります。

それらを把握することで効率良く実装することが出来るでしょう

 

③バックエンドとのデータの受け渡し方法を把握する

フロントエンドエンジニアの場合フロントエンドの事しか理解していないことが、あるかもしれません。

ですが、画面に表示するデータはバックエンドの処理を通過して表示する場合が多々あります。

受け渡し方法の把握は必要でしょう。

また本で学習をすることも、おすすめです、

 

 

【おさらい】新人エンジニアさんが意識するべきこと

・分からない事は質問して、コミュニケーションを取る

・タスクの期限・仕様(タスクのゴール)を明確にする

・タスクの見積もりをする。タスクの細分化をする。

・進捗報告を正確にする

・ソースコードの読み方のコツを掴む

コメント