僕が新人の時に起こしたミス10選とそれぞれ解決案

はじめに

記事に興味を持っていただきありがとうございます！
この記事は、現在1年目の新人エンジニアの方とその新人を教育する立場となった方に向けて役に立てたらいいなと思って作成したものです。

新人エンジニアが新人研修を終えてキャリアをスタートする際、多くのことに悩み、不安を感じることもあるでしょう。私も例外ではありませんでした。
私は去年、SIer企業に入社し、新人エンジニアとしてのキャリアを歩み始めましたが、何もかもが初めてで、戸惑いと失敗の連続でした。

それでも、2人のOJT担当者や周りの先輩エンジニアの方々に助けてもらいながら、1年目から実案件のなかで、顧客と話し合い任されたタスク（要件定義からテスト工程まで）をやり遂げることができました。

今では、その新人時代の経験が私の成長の糧となり、業務を行う際の基盤となっています。現在は3つ目のプロジェクトに配属される中で、新人を指導する立場にもなり、私自身がOJT担当として新人の成長を支援しています。

自身の経験
- 入社前は応用化学専攻の大学院生、プログラミング経験なし
- AIやITに魅了され去年SIer企業に入社、現在は2年目
- 1,2つ目のプロジェクトでは、JavaやAWSを使ったバックエンド開発
- 現在3つ目のプロジェクトに配属し、ReactやReact Nativeを使ったフロントエンド開発

この記事を書こうと思ったきっかけ

この記事を書こうと思ったきっかけは、OJT担当に任命された際、「新人に何を教えたらいいのだろう」と悩んだことです。そこで新人に教える内容を整理するため、まずは自分が1年目の時と2年目の現在を比較し、成長のポイントを振り返ってみました。

私自身のエンジニアとしての経験はまだまだ浅いので、この記事では技術的なことではなく、マインドやヒューマンスキルに焦点を当てています。新人エンジニアにはここで述べるミスを回避・改善してスキルを早く身につけて活躍してもらいたい、そして自分も初心を忘れず、さらなるスキル向上を目指したいという思いで、この記事を執筆しました。

また、現在新人を教育する立場の方々にも、この記事が新人の育成に役立つ情報源となることを願っています。僭越ながら、所々OJT担当への一言を記載してます。新人だった頃にOJT担当にしてもらって良かったことなども反映してますので、参考程度に見ていただけると嬉しいです。新人がどのような点でつまづきやすいかを理解し、効果的な指導につながることに貢献できればもっと嬉しいです。

私がしてきたミス10個とその解決案

それぞれの詳細に入る前に、ミス10個の一覧まとめです。

1. コミュニケーション不足は誤解の元。最低限のことはしっかり確認しよう！
2. 計画やスケジュールを立てる。後戻りをなくそう！
3. 自己判断のみで進めるとリスク大。迷ったら必ず確認を取ろう！
4. 報告・連絡・相談（・雑談も）を大事に。問題が大きくなるぞ！
5. 課題の根本原因を解決する。同じエラーが再発するぞ！
6. ブログ記事だけは足りない。公式ドキュメントを確認しよう！
7. 一人で抱え込むのは禁物。相談するタイミングを決めて早めに助けを求めよう！
8. 完璧主義になって優先度の低いことに時間をかけすぎない。まずは60%の完成度を達成しよう！
9. 進捗状況を毎日チェック。進捗遅れは早めに報告して修正しよう！
10. 自分を振り返ろう。日々の業務に成長のポイントは隠れている！

それでは、詳細に入ります。少しだけストーリー性を持たせており、タスク開始前から始まり、タスク実行時、課題直面時、タスク完了時の順で紹介しています。

タスク開始前

1. コミュニケーション不足

まず、１つ目はコミュニケーション不足です。このミスは新人エンジニアだけでなく、意識しないと誰でも起こりうるものです。（私はよくします）

新人は上位者であるOJT担当や先輩、上司、プロジェクトメンバーからタスクをもらって、その下で業務をすることになると思いますが、そのタスクの紹介や話をする段階からコミュニケーション不足は起こりがちです。

新人エンジニアにとって、プロジェクト内の業務は初めてのことばかりで、何もかもがわからない状態です。そのため、上位者の話をすべて受け入れ、一旦話を聞いて、タスク実行時にわからないことがあれば後で聞けばいいと考えがちです。結果として、話の途中で上位者の説明が曖昧だったり、タスクの目的や具体的に何をすべきかがわからなくても、遠慮してしまい、疑問や自分の考えを言い出せないことがよくあります。

タスクの目的や内容を明確にできていないため、後々再度コミュニケーションが必要

疑問や自分の考えを伝えて、話の邪魔をしたくない・話を一発で理解できる人と思われたいという気持ちがあるのはわかります。しかし、コミュニケーション不足になることで上位者と自身との認識の違いが生まれてしまい、誤解や以降紹介するさらなるミスも起こってしまいがちです。結果的に、タスク開始後や課題に直面したときに、上位者と再度会話して助けてもらうことになります。また、認識の違いがあった場合にはそれまで進めてきた進捗から戻って作業をし直すことも出てきます（以降、後戻りといいます）。

解決案

タスク開始前に限らないですが、上位者とタスクの話をする際にはとにかく気になったことを遠慮せずに質問し、意見を出し、上位者と自身との認識を合わせることが重要です。

タスクの目的や内容、期限を明確にすると良いスタートを切ってタスクを実行できる

私は、タスク開始前に最低限以下のことを明確にするようにしています。

最低限確認すること

• 曖昧な用語・わからない用語
• タスクの具体的な目的・目標（why・for what）
  • 何のためにそのタスクをするのか、最終的な目標は何か
• 何を（what）
  • 具体的に何をするのか、タスクの内容
• いつまで（until when）
  • タスクを完了するまでの期限
• どこまで（what scope）
  • タスクの範囲、どこまで対応するのか
• どうやって（how）(不安があれば、「この方法で合ってますか」と確認してもいいと思う)
  • 具体的な進め方や手順など

私は効率的に仕事をする基本は、後戻りをしないことだと考えています。
タスク開始前にできるだけコミュニケーションを取って、認識違いや後戻りをなくし、正しいゴールに対して力を注ぎましょう！

OJT担当への一言
上記に記載した最低限確認することを新人に伝えるようにしてあげてください（Howを考えるのは新人がメイン、必要な場合は伝える）。新人が話を理解していなさそうであれば、わかりやすい表現に変えたり、「何かわからないことはある？」と気軽に質問できる雰囲気を作ってあげると、新人も理解しようと積極的になると思います。新人が効率的にタスクをこなすことは結果的に上位者である自身の業務負担軽減にもつながります。できる限り新人の成長をサポートする姿勢を大切にしましょう。

タスク実行時(前半)

上位者にタスクを任され、いよいよ新人の業務が始まります。

2. 計画やスケジュールを立てない

タスクを任された後、モチベーションが高くなり、「早く終わらせてやるぞ！」とすぐに取り掛かりたい気持ちがあるのはわかります。私は初めの頃は設計書をもらったら、すぐにコードを書き始めていました、、、

しかし、これは途中までうまくいってるように見えますが、後戻りする可能性が非常に高いです。なぜなら、全体像を把握して、目的や目標を実現するための計画を立ててないからです。コーティングを例にすると、私は頻繁に、途中で「やっぱこのコーディング良くないかも」「今何のために何してるんだっけ」と、立往生してしまいました。そのまま行くと、適当に目の前にある問題を解決しようとし、結局よくわからない状態のまま、詰まってしまうことになります。

先ほどにも記載した通り、効率的な作業をするための基本は後戻りをしないことです。そのために、タスクに取り掛かる前、目的/目標を見据え全体像を把握してからその目的/目標を達成するための道のりを考える必要があります。

解決案

事前に計画を立てることによって、タスクを開始した後に、必要な作業のみに取り掛かることができ、次に何をやればよいかも明確になります。また、計画を立てる時から、予想できる課題や不明点を事前に解消することで、計画を立てなかったときと比べてスムーズにタスクを進めることができます。

コーティングを例にすると、設計書を見ていきなりコードを書き始めるのではなく、実装計画や実装完成イメージをつくりましょうということです。また設計書を新規で作成することを例にするならば、既存の設計書を参考にしながら、誰が読んでも理解できるように設計書の構成やおおまかな内容を事前に考えましょうということです。

計画やスケジュールを立てたが、質が悪いこともあると思います。経験や学習によって、より正確な計画やスケジュールを立てられるようになるので、まずは質が悪くても作成してみましょう。また、作成した計画やスケジュールは（特に初めの頃は）可能であればぜひOJT担当に確認してもらうことをおすすめします。もしかしたら間違った計画を立てているかもしれないですし、計画を確認してもらう際にアドバイスをくれるかもしれません。

OJT担当への一言
新人が間違った計画やスケジュールを立てて、そのまま間違った方向に進んでしまったら後戻りにつながります。新人が計画を立てたらその計画やスケジュールをチェックするようにしてあげると余分な工数が減り、また新人の成長にもつながります。

3. 自己判断で進める

これ、私は頻繁にしてました。私のせいかもしれないですが、私が1年目の時のOJT担当者は、「新人と言えば自己判断で間違った方向に進むんだよなあ」と言うほど、起こりやすいミスです。
具体例を挙げると、勝手に設計や仕様の決定をする、指示されていないことをするなどです。私の場合は、自己判断のみで仕様を決定して設計書に記載されていないことをコードに反映させたり、テストケースを作成した後は勝手にテスト実施して完了にしました。

解決案

私は、自ら主体性を持って意思決定を行う自己判断自体は悪いことではなく、むしろ良いことだと思います。ただ、自己判断のみで突き進んでしまうことが良くないことであると学びました。自身の判断が100%正しいと思っていても、経験が豊富で視座の高い上位者やプロジェクトメンバーから見たら、他により良い方法があるかもしれません。もし判断が誤っていたら後戻りにつながってしまいます。

ですので、タスクに関して自身の考えや意見がある場合は、上位者に確認を取ることが必要です。もし断られたらその理由を聞くと、タスクやプロジェクトのさらなる理解が進み、自己成長にもつながります。ここでもう一つ覚えていただきたいことは、新人エンジニアがやることに対して上位者も同じ認識を持っていて承認していることです。それは結果的に上位者との信頼関係向上にもつながります。

OJT担当への一言
新人が自分の考えを持って行動することを尊重しつつも、その判断が適切かどうかを確認するよう促すと、新人も自己判断で進めることが少なくなります。毎日、定期的に新人と話す場を設け、彼らが抱えている疑問や仮説に対して聞き、意見を交換することで、プロジェクト新規者である新人だからこそ発見できる新しい視点に気が付くかもしれません。

4. 報告・連絡・相談が少ない

とにかく、何かあるときはすぐに上位者に話しましょう。
上位者にめんどくさいと思われないか、邪魔をしてしまうんじゃないか心配で遠慮したり、話すのが面倒な気持ちがあるのはわかります。しかし後回しにすると、後の自分に返ってきます。
私が1年目の時は、毎日9:00、14:00、17:00に20分間、固定でOJT担当者がミーティングを設定してくれました。9:00の回では、軽く挨拶、その日と14:00までにやることを確認。14:00の回では中間報告や質問、17:00の回で今日一日したことを報告してました。その時間以外でも何かあった際には、チャットやビデオ会議ですぐに報告、連絡、相談をしてました。当時はOJT担当と話すのが多いなあと思っていましたが、雑談もよくしてくれたので安心感や信頼感が増し、後々何かあった際には何でも報告、連絡、相談できました。

解決案

報告・連絡・相談はどこですればいいか聞き、必要であれば上位者との定期的なミーティングをお願いしてもよいと思います。後回しにしたくなったときは、「後の自分に返ってくるぞと」と自分を脅し、言い訳をしない覚悟ができないならば後回しせずにすぐに会話してください。

OJT担当への一言
忙しいためなかなか新人と話す時間を取れないかもしれませんが、毎日15分zoomなどビデオ会議で雑談するだけでも新人に安心感を与え信頼関係構築につながると思います。新人がタスクをうまくこなすことは先輩自身の業務も減らすためお互いのためにもできるだけ報告・連絡・相談をいつでもできる環境を整えること、雑談の時間を設けることを意識するとOJT教育がスムーズに進むと思います。

課題直面時

エンジニアならば、誰しもが課題に直面します。課題に直面することは成長の機会なのでとても良いことです。課題に対して、どのようにアプローチし、どうやって効率よく解決できるかが成長のポイントです。
以下、実装をしているときを例にして、新人エンジニアがよくしがちなミスを紹介します。

5. 課題の根本的な原因を解明しない

１人前のエンジニアでも、想定通りの挙動をし、エラーのないコーディングを１発で実装することは難しいです。エラーが発生した際に、エラーメッセージを読んでエラー原因の可能性があるところをすぐに修正しに行きたい気持ちはわかります。しかし、エラー内容が簡単でない限り、そのような解決法では、表面的なエラーを解決したに過ぎず、同じ問題が他の場所で再発する可能性があります。

具体例として、行数：100行目でNullPointerExceptionが発生していることがエラーメッセージからわかりました。その100行目に対して、nullチェックを追加することで一時的に問題が解決できるかもしれません。しかし、エラーの根本的な原因を解決しないならば、同じNullPointerExceptionや他の問題が、今度は行数：30行目や60行目など他の場所で再発する可能性がありますということです。重要なのは、なぜnullがそのような状況で行数：100行目において発生したのか、その根本的な原因を解明し、その原因に対して適切にアプローチをすることです。

解決案

エラーから原因を推測し、仮設を立ててから対処します。上の具体例に対してならば、「どの時点でオブジェクトがnullになっているのか」「なぜオブジェクトがnullになるのか」考えてから、原因を推測し、仮設を立ててから対処するようにしましょう。ここで役立つのが、どこかで聞いたはずのなぜなぜ分析です。「なぜ問題が起こったのか？」「それはなぜか？」と何度も掘り下げることで、真の原因を見つけ出し、効果的な解決策や再発防止策の策定が導かれます。

6. 一次情報を見ない

一次情報というのは、例えば使用しているプログラミング言語がJavaの場合、Javaを提供しているOracle社が作成したJavaの公式ドキュメントのことです。一方で、二次情報とは検索して出てくるブログなどの公式ドキュメント以外の情報のことです。今やネットには二次情報が豊富にあり、検索すれば問題への解決法はほとんど見つかるでしょう。それらはとても役に立つもので、効率的に問題を解決するかもしれません。しかし、一人前のエンジニアになるためには、二次情報を見るだけでは足りません。なぜなら、本当に信頼できる情報なのか定かではないからです。私たちは、二次情報に記載のある解決法を実行することで、自身の問題が解決され、その二次情報を信頼することになりますが、必ずしも解決されるとは限りません（例えば、バージョンが古いときの解決法、特定の状況に依存した解決法が記載されていた場合など）。また、二次情報に頼って曖昧な解釈をすると、今後も誤った解決策を選択する可能性があります。

解決案

一次情報である公式ドキュメントは英語で記載されていることもあり、また内容も多いため読むことを躊躇ってしまうと思いますが、一次情報を参照することを習慣化することで、よりその技術要素に関して理解が深まります。また、信頼できる情報源なので現在の問題を解決するだけでなく、今後の問題回避にもつながり、結果的にコーディング作業効率もあがります。

少し別の話になるかもしれませんが、コーディングをするときに仕様や設計で不明点があれば、必ず要件定義書や設計書を確認する習慣をつけましょう。それでもわからない場合は聞いた方がいいです。

7. 課題を一人で抱え込む

実装で詰まっている部分に対して、頑張って調べてもなかなか解決しないこともありますよね。自分の成長のために先輩や上位者に頼まないで、自分だけで解決したいと思う気持ちはとても分かります。ですが、タスクにかけられる時間は無限ではありません。限られた時間の中でまずは成果を出すことの方が優先度が高いのです。

解決案

上位者の業務を邪魔したくない、めんどくさがられたくないという気持ちもわかりますが、タスクが遅れれば後にもっと迷惑をかけることになります。ですので、お互いのためにもある程度自身で努力してできなかったら、すぐに上位者に聞きましょう。上位者も忙しそうであれば、空いている時間を聞き、そこで相談するとよいでしょう。また、上位者に自身のOJT教育にかかる工数はどれくらいかを聞くと、1日あたりに相談できる時間がわかりますので、知っておくと相談することに遠慮しにくくなると思います。

では、どこまで自身で努力すればよいのか。これは状況や人によって異なると思いますが、以下にいくつか参考例を記載します。

自身で頑張るか相談するかの境目(例)

• 時間の目安で決める
  • 最初の15分は自分で解決を試みる、15分後も同じ問題にハマっていたら聞く、など
    • これは「15分ルール」というもので、Googleの人工知能チームでも採用されているらしいです
• 調査の深さで決める
  • 1次情報や2次情報を参照して、ここまでわかったがこの点からわからないという状態になったら聞く
• タスクの優先度で決める
  • そのタスクが他の人の作業に影響を与える場合や期限が迫っている場合、詰まったらすぐ聞く

タスク実行時(後半)

8. 完璧主義による遅延

完璧主義は一見良い性質のように見えるかもしれません、しかしほとんどの場合タスクの進捗に悪影響を及ぼします。上位者やプロジェクトメンバーからの期待に応えたい、褒められたいという気持ちがあり、成果物の質を上げるために過度な確認をしたり見た目を綺麗にしたりしてしまうことがあると思います。例をあげると、設計書やテスト仕様書の見た目を良くすることやテストケースを過剰に作成することです。

しかし、それは本当に今やるべきことでしょうか？？

解決案

重要なことは期限内に任されたタスクをこなすことです。

私が設計書を新規で書く場合、まずは構成を練り、必要な項目や情報を整理し記載、自己レビューを軽く行い、一旦60%くらいの質で設計書を作成します。（不安なときはここでまず上位者に確認してもらっていました）その後、期限まで余裕があり、他に優先度の高いタスクがなければ、作成した設計書を何度も読み返して、よりわかりやすい表現にしたり、図を入れたり見た目をよくする、他の人からのレビューで質を60%から90%以上まで上げていきます。

つまり、作成する初めから完璧な状態を目指さないで、一旦作成してしまってから2周目3周目で質を上げることをおすすめします。

9. 全体進捗を意識してない

計画やスケジュールを立てても、進捗が遅れてしまうことはありますよね（特に新しいプロジェクトに参加したときなど）。私の場合、気合いだけはあったので、「遅れても最後の期間で取り戻せる」と本気で信じてました。しかし、想定外の課題に直面したり、予期しない小タスクに時間を取られ、気がつけば締め切り直前に「やっべえぞ」となってしまうことがありました。

上位者やプロジェクトメンバーに迷惑をかけたくない、仕事ができると思われたいという気持ちから、進捗の遅れを隠してしまうこともあるかもしれません。しかし、これでは最終的に遅れが深刻化し、取り返しのつかない状況になってしまい、結果的に周囲に大きな迷惑をかけることになります。（私はリリース日を2日伸ばした経験ありです）

そのため、毎日進捗を見直し、自分の現状を把握し、上位者やチームに共有することが大切です。これにより、適切な修正計画を立てて、遅れを最小限に抑えることができます。

解決案

毎日、1日の終わりや週末にタスクの進捗状況を確認し、計画通りに進んでいるかチェックしましょう。もし遅れている場合は、OJT担当やプロジェクトメンバーに素直に報告することで、アドバイスを得られたり、遅れを取り戻すための修正計画を立てることができます。以前、進捗が計画通りのときは黄色信号とプロダクトオーナーに教えてもらいました。何か想定していない課題が入ってきたら進捗が遅れてしまうからです。なので、計画と比べて進捗が少し進んでいる状態を目指して日々計画を見直しましょう。

タスク完了時

10. 振り返りをしない

最後は振り返りをしましょうです。
やっとタスクが終わり、達成感を味わい、次のタスクはもっと上手くこなすぞという気持ちがあるかもしれませんが、一旦完了したタスクを振り返って、自身が良かったところ・改善するべきところを整理する時間を設けることをおすすめします。なぜならばタスクの中ではたくさんの課題に直面し、タスク完了後、今度はうまくやるとその時は思っていてもいつのまにか忘れておりまた同じミスをしてしまうからです。せっかくの成長の機会を逃してしまうのは非常にもったいないです。

解決案

私は、タスク完了時に関係なく毎週末に30分ほど時間を取ってKPT分析で１週間を振り返るということをしています。私は1年目の頃にOJT担当に指摘や感じたことがあれば何でも伝えて欲しいと事前に伝え、初めてのプロジェクト配属以降、現在でも週末に自身の振り返りを実施しています。

自身が考える振り返りのメリットは以下の通りです。

振り返りのメリット

• 自己成長の促進
  • 振り返りを実施して、自身のどの部分が良くて、どこを改善する必要があるか把握できます。これにより、次回の行動を改善し、成長のスピードが上がります
• 過去のミスを繰り返さない
  • 過去の失敗から学び、同じミスを再び繰り返すことを防げます
• 後に見返すことで成長を実感できる
  • 1年目から毎週振り返りを行っていたことで成長のポイントを言語化できこの記事を書くことができました

例として以下に実際に私が記載した1週間分のKPT分析結果を簡単に記載します。

Keep（良かったこと）
- 設計書がわかりやすく読みやすいと言われた
    - 要件を設計に上手く落とし込めた
        - プロジェクトの背景にある課題とその原因を明確にし、その解決のために何が必要か仮説をたてながら設計を行った
    - 論理的でわかりやすい記載をした
        - どのように記載したらわかりやすく論理的な文章になるか構成を考えた
        - 記載すべき内容を整理し、優先順位をつけながら簡潔にまとめた

Problem（改善すべきこと）
- コーディングでエラーが起こった際に原因をあてずっぽうにしてしまった
    - めんどくさく、多分ここが原因だろうで進んでしまった
        - 本当の原因でないならば後戻りの可能性がある。最初に原因特定のステップを踏めばより効率的に問題を解決できる

Try（次から意識すること）
- エラーが出た際や問題が起こった際はその本質的な原因を解明する
- 書籍「考える技術・書く技術」を読んで、論理的でわかりやすい文書作成の方法を体系的に理解する

皆さんも定期的に振り返りを実施してみてください。自身のみで深堀りをすることは意外と難しいと思うので、OJT担当やChatGPTなど対話型生成AIに深堀りを頼んでみるのもいいと思います。

おわりに

ここまで読んでいただきありがとうございます。
ここに挙げたことは、私が1年間自身の振り返りを実施して気が付いたことを記載しています。まだまだ社会人・エンジニアとしての経験が浅いので、「それは違うね」みたいな部分があればご指摘いただきたいです。

今後も日々学んだことや振り返りを通して、この記事もアップグレードしていこうと思います。

記事紹介

以下、新人の時に読んで参考になった記事です。