実務1週間で詰まない現場サバイバル術

Section 01

転職成功よりも怖かった「実務初日」という現実

未経験からエンジニアになった瞬間、不安は消えなかった

内定が出た夜、眠れましたか。私は眠れませんでした。やっと掴んだはずなのに、胸の奥がざわついていたからです。

転職活動中は、内定だけを見ていました。ポートフォリオを作り、面接で頭を下げ、結果を祈る日々。あの頃は、内定がすべてのゴールに見えていました。

ところが入社が近づくと、別の感情が顔を出します。「自分は本当に現場で通用するのか」という恐怖です。学習中の不安とは、まるで種類が違います。

勉強しているときは、わからなくても困るのは自分だけでした。でも実務は違います。自分のつまずきが、誰かの時間を奪うのです。その重さに、初めて気づきます。

私も同じでした。Laravelの案件に未経験で飛び込んだ初日です。開いたコードが、一文字も理解できませんでした。「この人、大丈夫?」と思われている気がして、心臓が痛かったです。

でも、安心してください。その不安は、真剣に向き合っている証拠です。不安を感じる人ほど、現場で伸びていきます。まずは、その気持ちを否定しないであげてください。

多くの学習記事が教えてくれないこと

ProgateやUdemyは、本当に優秀な教材です。基礎文法も、フレームワークの使い方も丁寧に教えてくれます。学習段階では、これ以上ない味方です。

でも、ひとつだけ教えてくれないことがあります。それは「現場での動き方」です。コードの書き方は学べても、チームでの立ち回りは学べません。

実務で評価されるのは、技術力だけではないからです。むしろ最初の数ヶ月は、技術以外で評価が決まります。質問の仕方、報告の仕方、詰まったときの動き方です。

これらは教材に載っていません。なぜなら、現場ごとに違うからです。だから未経験者は、入社後に大きなギャップを感じます。「こんなこと、誰も教えてくれなかった」と。

でも、知らないだけなら対策できます。現場のリアルを先に知れば、最初の1週間でつまずく確率は大きく下がります。

この記事は、その「教材が埋めない部分」を埋めるために書きました。今日読んで、明日から動ける内容にしています。読み終えたら、まず一つでいいので試してみてください。

この記事で伝えたいこと

この記事で伝えたいことは、3つです。すべて、私が実務で痛い目に遭って学んだことです。

1つ目は、未経験者が最初に知るべき現場のリアルです。どんな壁にぶつかるのか。先に知るだけで、心の準備ができます。知っているか否かで、初日の落ち着きが変わります。

2つ目は、実務1週間目から1ヶ月目までの生存戦略です。この時期の過ごし方で、その後の評価が大きく変わります。最初の印象は、思った以上に長く残るからです。

3つ目は、今日から準備できる具体策です。読んで終わりではなく、手を動かせる内容にしました。行動して初めて、不安は自信に変わります。

難しい話はしません。専門用語が出ても、必ずかみ砕いて説明します。学習中の人でも、最後まで読めるように書きました。

では、さっそく始めましょう。まずは、あなたがこれからぶつかる「5つの壁」を見ていきます。先に知れば、もう怖くありません。

Section 02

未経験エンジニアが最初にぶつかる5つの壁

壁① コードが読めない

入社して最初に感じるのは、たぶんこれです。「コードが、まったく読めない」という衝撃です。あなたが悪いわけではありません。誰もが通る道です。

学習教材のコードは、せいぜい数十行でした。一画面に収まり、流れも追えました。だから「もうコードは読める」と思っていたはずです。

ところが実務は、規模が違います。ファイルは何百個もあります。一つの処理が、複数のファイルにまたがります。どこから読むのか、見当もつきません。

私が初めて開いたLaravelの案件は、強烈でした。コントローラーだけで何十個もあったのです。ボタン一つの裏で何が動くのか。追うだけで一日が終わりました。

でも断言します。最初は理解できなくて当たり前です。ベテランでも、新しい案件では最初は読めません。違いは、読み方を知っているかどうかだけです。

大事なのは、全部を理解しようとしないことです。今日触る部分だけ追えば十分です。まずは「一つの処理の流れ」を、一本だけ追ってみましょう。それだけで、霧が少し晴れます。

壁② エラーが解決できない

次にぶつかるのが、エラーです。学習中もエラーは出ました。でも実務のエラーは、まったくの別物です。

チュートリアルのエラーには、答えがありました。手順どおり直せば、たいてい解決しました。検索すれば、同じ事例がすぐ見つかりました。

ところが実務のエラーには、答えが存在しないことがあります。あなたの環境だけで起きる問題。社内独自のコードで起きる問題。検索しても、同じ事例は出てきません。

だから、自力で調べる力が求められます。メッセージを読み、原因を推測し、一つずつ試す。この作業は、教材では鍛えられない部分です。

私も最初は、エラーが出るたび固まりました。「もう無理だ」と思った夜も、何度もあります。でも調べ方を覚えてから、エラーが怖くなくなりました。

エラーは敵ではなく、ヒントです。メッセージは、原因をあなたに教えています。次にエラーが出たら、まず1行目を声に出して読んでみてください。そこに、答えの入り口があります。

こちらもチェック

未経験エンジニアの15分ルール｜エラー対処法

壁③ 開発環境が理解できない

3つ目の壁は、開発環境です。実務では、聞き慣れない単語が飛び交います。Docker、Git、AWS。どれも、独学では深く触れない領域です。

まずDockerです。これは、開発環境を箱に詰めて持ち運ぶ仕組みだと思ってください。自分のパソコンと同僚のパソコンで、同じ環境を再現できます。「私の環境では動くのに」を防ぐ道具です。

次にGitです。これは、コードの変更履歴を記録するタイムマシンです。誰がいつ何を変えたか、すべて残ります。失敗しても、過去に戻せます。チーム開発に欠かせません。

そしてAWSです。これは、Amazonが貸し出す巨大なサーバー群です。作ったアプリを、世界に公開する土台になります。難しく聞こえますが、要は「借りているコンピューター」です。

全部を今すぐ理解する必要はありません。名前と役割を、ざっくり知るだけで十分です。触りながら、少しずつ慣れていけば大丈夫です。

まずは「Docker・Git・AWS」が何の道具か、一言で言えるようにしておきましょう。それだけで、会話の解像度が変わります。

こちらもチェック

Gitは転職にどこまで必要？評価されるGitHubの整え方

壁④ 会話についていけない

4つ目の壁は、会話です。これは、地味につらい壁です。ミーティングで何を話しているのか、半分も理解できません。

「このPR、マージしていい?」「ステージングで確認した?」「あのチケット、誰がアサインされてる?」。専門用語が、当たり前に飛び交います。

つらいのは、わからないことが、わからない状態になることです。何を質問すればいいのかすら、わかりません。情報量が多すぎて、頭が真っ白になります。

私も最初のMTGでは、メモを取ることすらできませんでした。知らない単語が多すぎたからです。聞き取るだけで必死でした。終わったあと、どっと疲れたのを覚えています。

でも、これは時間が解決します。同じ単語を何度も耳にすれば、自然と慣れます。わからない単語は、こっそりメモしておけば大丈夫です。あとで調べれば、次は理解できます。

MTGで出た知らない単語を、毎回3つだけメモする習慣を作りましょう。1ヶ月後には、会話の景色が変わっています。

壁⑤ 質問ができない

5つ目の壁は、質問です。これが、実は一番やっかいかもしれません。多くの未経験者が、ここで時間を溶かします。

「こんなこと聞いていいのかな」。そう思って、質問をためらいます。忙しそうな先輩に、声をかけられません。気を遣って、ひとりで抱え込みます。

その結果、何時間も同じ場所で止まります。調べても解決せず、時間だけが過ぎます。気づけば半日、無駄にしていることもあります。

でも、ここで知ってほしいことがあります。実は、質問できる人の方が評価されます。遠慮して黙る人より、ずっと信頼されます。

なぜなら、抱え込みはチームにとって最も困るからです。進捗が止まっていることに、誰も気づけません。早く相談してくれた方が、よほど助かるのです。

もちろん、質問には良い聞き方があります。それは後の章で詳しく説明します。まずは「質問は迷惑ではない」と、自分に言い聞かせることから始めましょう。

Section 03

なぜ未経験者は実務で挫折するのか

原因① 学習と実務を別物だと思っていない

挫折する人には、共通する原因があります。ひとつ目は、学習と実務を同じものだと思っていることです。

学習は、答えがある世界です。教材には正解があり、解説があります。わからなければ、模範解答を見ればいい。ゴールが、最初から決まっています。

でも実務は、答えを探す世界です。正解は、誰も持っていません。仕様を読み、自分で考え、最適な形を作る。ゴールすら、自分で決めることがあります。

この違いに気づかないと、苦しくなります。「答えが見つからない自分はダメだ」と、責めてしまうからです。でも、それは勘違いです。答えがないのが、実務の普通です。

私もこの切り替えに、しばらく苦しみました。「正解を教えてほしい」と、心の中で叫んでいました。でも、探す側に回った瞬間、仕事が面白くなりました。

「答えを覚える」から「答えを作る」へ、頭を切り替えましょう。この一歩が、挫折と成長の分かれ道です。

原因② 技術力だけで評価されると思っている

2つ目の原因は、技術力だけで評価されると思い込むことです。これは、本当に多くの人がハマる罠です。

もちろん、技術力は大切です。でも現場で見られているのは、それだけではありません。むしろ最初の数ヶ月は、別のところを見られています。

それが「自走力」です。自走力とは、わからないことを自分で調べ、進める力のことです。完璧に解く力ではありません。詰まったときに、次の一手を打てる力です。

そしてもうひとつが、コミュニケーション力です。これは、話がうまいという意味ではありません。状況を正しく伝え、必要なときに助けを求める力です。

技術力が低くても、自走力と報告ができれば信頼されます。逆に、技術があっても黙って抱え込む人は、評価されません。

これは、不公平に聞こえるかもしれません。でも、チームで働く以上、当然のことです。「解ける力」より「進められる力」を意識しましょう。

原因③ 完璧主義になってしまう

3つ目の原因は、完璧主義です。真面目な人ほど、ここで足を止めます。当てはまっても、落ち込まないでください。

完璧主義の人は、調べ続けてしまいます。「もう少し自分で調べてから質問しよう」。その気持ちはわかります。でも、それが時間を溶かします。

納得いくまで調べないと、質問できない。その結果、何時間も止まります。本当は10分で済むことに、半日かけてしまうのです。

抱え込みは、最も危険です。なぜなら、進捗が見えなくなるからです。チームは「順調だ」と思い込み、気づいたときには手遅れになります。

私も、完璧主義で失敗しました。「こんな初歩的なこと聞けない」と抱え込み、半日を無駄にしました。あとで聞いたら、たった5分で解決しました。

完璧な質問より、早い相談の方が価値があります。「15分詰まったら質問する」というルールを、自分の中に作りましょう。

原因④ 「できる新人」を目指しすぎる

4つ目の原因は、「できる新人」を目指しすぎることです。意外かもしれませんが、これも挫折につながります。

頑張りたい気持ちは、素晴らしいことです。でも、最初から戦力になろうとすると、苦しくなります。期待値を、自分で上げすぎてしまうからです。

はっきり言います。未経験の新人に、即戦力は求められていません。会社も、最初から活躍できるとは思っていません。それは織り込み済みです。

では、何が求められているのか。それは「成長できる人かどうか」です。今できるかではなく、これから伸びるかを見られています。

だから、できないことに落ち込む必要はありません。むしろ、できないことを素直に認め、学ぶ姿勢が評価されます。背伸びは、かえって信頼を損ないます。

求められている期待値を、正しく理解しましょう。「できる新人」ではなく「伸びる新人」を目指せば、肩の力が抜けます。

Section 04

実務1週間目で評価される新人の共通点

わからないことを素直に認める

ここからは、評価される新人の共通点を紹介します。どれも、技術力とは関係ありません。今日から真似できることばかりです。

1つ目は、わからないことを素直に認めることです。当たり前に聞こえますが、これができない人が多いのです。

つい、知ったかぶりをしてしまいます。「わかりました」と言ってしまう。本当はわかっていないのに、その場をしのいでしまうのです。

でも、知ったかぶりは危険です。あとで「できていない」とわかった瞬間、信頼を一気に失います。「わかったふり」は、最も信頼を削る行動です。

わからないことは、恥ではありません。むしろ、認められる人ほど信頼されます。「すみません、そこがまだ理解できていません」と言える勇気を持ちましょう。

質問前に最低限の調査をしている

2つ目は、質問前の調査です。質問は大事ですが、丸投げは別です。最低限の調査をしてから聞く人が、評価されます。

では、何を調べればいいのか。順番があります。この順番を覚えるだけで、自走力が一気に上がります。

Google検索。エラーメッセージをそのまま貼り、検索します。多くの問題は、ここで解決します。同じことで悩んだ人が、必ずいるからです。
ChatGPT。エラーの意味がわからないときに使います。「このエラーはどういう意味?」と聞けば、かみ砕いて教えてくれます。ただし、鵜呑みは禁物です。
公式ドキュメント。これが一番、正確です。少し読みにくいですが、信頼できる情報源です。

公式を読める人は、長期的に強くなります。最初は難しくても、慣れれば手放せません。

質問の前に「検索→ChatGPT→公式」の3ステップを試す癖をつけましょう。それでも解決しなければ、堂々と質問していいのです。

進捗報告ができる

3つ目は、進捗報告です。これができるだけで、新人の評価は大きく変わります。地味ですが、最強のスキルです。

報連相という言葉を、聞いたことがあるはずです。報告・連絡・相談の頭文字です。古い言葉に聞こえますが、エンジニアにこそ必要です。

なぜなら、作業が見えにくいからです。コードを書いている間、進捗は外から見えません。だから、こちらから伝える必要があります。黙っていると、心配されます。

報告は、難しく考えなくて大丈夫です。「今ここまで進みました」「ここで詰まっています」。それだけで十分です。短くて構いません。

こまめに報告する人は、安心して仕事を任せられます。逆に、報告がない人には、不安で仕事を振れません。

一日の終わりに「今日やったこと」を一言、先輩に伝えてみましょう。それだけで、信頼が積み上がります。

メモを取る習慣がある

4つ目は、メモを取る習慣です。実務では、覚えることが膨大にあります。すべてを記憶するのは、無理です。

だから、メモが武器になります。教わったことをメモすれば、二度同じ質問をせずに済みます。同じことを二回聞く人は、信頼を失います。

ツールは、何でも構いません。Notionは、整理しやすく検索も得意です。Google Docsは、シンプルで誰でもすぐ使えます。

大事なのは、ツール選びではありません。続けられるものを選ぶことです。最初は、使い慣れたもので十分です。凝りすぎると、続きません。

メモを貯めると、自分専用のマニュアルができます。環境構築の手順、よく使うコマンド、つまずいたエラーと解決法。これが、あなたの財産になります。

今日から「教わったこと」と「詰まったこと」を、必ずメモに残しましょう。

小さな改善を続ける

5つ目は、小さな改善を続けることです。これは、長い目で見て一番大きな差になります。

「毎日1%成長」という考え方があります。一日の成長は、わずかでいいのです。1%なんて、ほとんど変化を感じません。でも、積み重なると別物になります。

1%の成長を一年続けると、約37倍になります。逆に、毎日1%サボると、ほぼゼロになります。日々の小さな差が、一年後に巨大な差を生みます。

だから、焦らなくて大丈夫です。今日、昨日より一つ詳しくなれば十分です。エラーを一つ解決した。コマンドを一つ覚えた。それでいいのです。

おすすめは、学習ログを残すことです。「今日学んだこと」を一行でいいので書きます。記録は、成長を見える化してくれます。落ち込んだ日に読み返すと、自信になります。

寝る前に「今日できるようになったこと」を一つ書き残しましょう。その一行が、明日のあなたを支えます。

Section 05

現場で嫌われない質問の仕方

NG質問①「わかりません」

質問は大事です。でも、聞き方を間違えると逆効果になります。まずは、やってはいけない質問から見ていきましょう。

1つ目のNGは、「わかりません」だけの質問です。これだけ言われても、相手は何も答えられません。

たとえば「この処理、わかりません」。これでは、情報が足りなすぎます。何がわからないのか、どこで詰まったのか、まったく伝わりません。

相手は、まず状況を聞き出すところから始めます。「どこがわからないの?」「何を試したの?」。質問に質問を重ねることになります。

これは、相手の時間を余計に奪います。情報不足の質問は、親切なつもりで相手を困らせます。本人は質問しているつもりでも、丸投げになっているのです。

質問するときは、状況をセットで伝えましょう。「何が」「どこで」わからないのかを、必ず添えてください。それだけで、相手の負担が激減します。

NG質問②「エラーが出ました」

2つ目のNGは、「エラーが出ました」だけの質問です。これも、非常によくあるパターンです。

さらにありがちなのが、スクショだけを送ることです。画面の写真を貼って、「これ、どうすれば?」。一見、情報を渡しているようで、不十分です。

なぜなら、状況の説明がないからです。何をしようとして、どんな操作をしたのか。それがわからないと、原因を特定できません。

エラーは、起きた経緯がすべてです。同じメッセージでも、原因は何通りもあります。経緯がわからなければ、相手も推測するしかありません。

スクショは証拠であって、説明ではありません。写真を送るときも、必ず言葉を添えてください。

「何をしたら」「このエラーが出た」と、一言つけるだけで質問の質が変わります。次の章で、その型を紹介します。

評価される質問テンプレート

ここで、評価される質問の型を紹介します。これを覚えれば、もう質問で悩みません。コピーして、使ってください。

型は、4つの要素でできています。順番に埋めるだけで、伝わる質問になります。難しいことは、ひとつもありません。

要素	書く内容
① 何をしたか	どんな作業・目的だったか。背景が伝わる。
② 何が起きたか	エラーや想定と違う結果。事実をそのまま。
③ 何を調べたか	自分で試したこと。丸投げでない証拠になる。
④ どこまで理解したか	わかる所とわからない境界。説明の起点になる。

特に大事なのは、3つ目です。「調べたこと」があると、丸投げではないと伝わります。相手の印象が、まったく変わります。

「やったこと・起きたこと・調べたこと・理解した範囲」、この4つをメモに貼っておきましょう。

実際に使える質問例

テンプレートだけでは、イメージが湧きにくいかもしれません。そこで、実際の質問例を見てみましょう。よくある場面で紹介します。

まずGitエラーです。「ブランチをpushしたら、rejectedと出ました。リモートを取り込めばいいと調べ、pullしました。今度はconflictが出て、解消手順がわからず止まっています」。これなら、相手はすぐ答えられます。

次にフロントエンドのエラーです。「ボタンを押しても反応せず、コンソールにundefinedのエラーが出ます。変数名は確認済みで、データの取得タイミングが原因かと推測しています」。

DBエラーも同じです。「接続時にconnection refusedが出ました。Dockerのコンテナは起動済みで、ポート番号も確認しました。環境変数の設定が怪しいと思っています」。

どの例も、状況と仮説がセットになっています。この型さえ守れば、どんなエラーでも気持ちよく質問できます。

Section 06

技術力より先に身につけたい「エラー解決力」

実務で最も重要なのはググる力

意外に思うかもしれません。でも、実務で最も重要なのは「ググる力」です。技術力より先に、これを鍛えてください。

現役のエンジニアも、毎日のように検索しています。すべてを暗記している人など、いません。覚える力より、調べる力が問われる世界です。

では、ググる力とは何か。それは、適切なキーワードを作る力です。検索が下手な人は、キーワード選びでつまずいています。

コツは、エラーメッセージをそのまま使うことです。ただし、自分の環境に固有の部分は削ります。ファイル名やIDなど、自分だけの情報は検索の邪魔になります。

たとえば「Laravel SQLSTATE column not found」のように、汎用的な単語に絞ります。固有名詞を混ぜると、結果が出なくなります。引き算が、検索のコツです。

次に詰まったら、エラー文から「固有の部分」を削って検索してみましょう。ヒット率が、ぐっと上がります。

エラーログの読み方入門

検索の前に、もうひとつ大事なことがあります。エラーログを読むことです。多くの初心者は、ログを読まずに固まっています。

エラーメッセージは、コンピューターからの手紙です。「ここで、こういう問題が起きました」と教えてくれています。読まないのは、もったいないことです。

まず見るべきは、一行目です。たいてい、何が起きたかが書いてあります。英語でも、怖がらないでください。翻訳すれば、意味はわかります。

次に、スタックトレースです。これは、エラーが起きるまでの道のりを記録したものです。どのファイルの、何行目で起きたか。順番に並んでいます。

見るべきは、自分のコードが出てくる場所です。ライブラリの奥ではなく、自分が書いたファイル名を探すのが近道です。そこに、原因が潜んでいます。

エラーが出たら、まず「1行目」と「自分のファイル名がある行」を読みましょう。これだけで、解決速度が変わります。

ChatGPTを使った調査方法

今は、ChatGPTという強い味方がいます。使いこなせば、調査が一気に速くなります。ただし、使い方には注意が必要です。

やってはいけないのは、丸投げです。「このエラー直して」とコードを貼るだけ。これだと、自分の頭が育ちません。考える力が、どんどん落ちていきます。

しかも、答えが間違っていることもあります。ChatGPTは、もっともらしい嘘をつくことがあります。そのまま貼り付けると、別の問題を引き起こします。

では、どう使うか。効率的なのは、理解のために使うことです。「このエラーは、なぜ起きる?」と仕組みを聞きます。原因を理解すれば、応用が効きます。

もうひとつは、調べる方向を教わる使い方です。「何を確認すればいい?」と聞きます。答えではなく、ヒントをもらうのです。

ChatGPTには「答え」ではなく「考え方」を聞く癖をつけましょう。それが、長く伸びる人の使い方です。

解決までの基本フロー

最後に、エラー解決の基本フローをまとめます。この流れを身につければ、どんなエラーも怖くありません。4つのステップです。

状況整理。何をしたら、何が起きたのか。事実を落ち着いて書き出します。慌てて手を動かす前に、まず整理します。
仮説立て。「たぶん、ここが原因かも」と当たりをつけます。メッセージとログから、可能性を絞ります。当てずっぽうでも構いません。
検証。立てた仮説を、ひとつずつ試します。一度に複数いじると、何が効いたかわかりません。
再現確認。直ったら、もう一度同じ操作をします。本当に直ったのか、たまたまか。確かめて、初めて解決です。

変更は一つずつ、が鉄則です。このフローは、慣れれば自然にできるようになります。

次のエラーで「整理→仮説→検証→再現」を、口に出しながらやってみましょう。

Section 07

実務開始前に準備しておくべきこと

Git/GitHubの基本操作

ここからは、入社前にやっておく準備の話です。先に触れておくだけで、初日の安心感がまるで違います。

まず最優先は、GitとGitHubです。これは、エンジニアにとって呼吸のようなものです。毎日、必ず使います。慣れていないと、毎日つまずきます。

覚えるべき操作は、5つだけで大丈夫です。順番に手を動かせば、自然と流れがつかめます。

clone。リモートのコードを、自分のパソコンに複製する操作です。最初に一度だけ行います。
branch。作業用の枝を作る操作です。本流を汚さずに、自分の作業ができます。
commit。変更に名前をつけて記録する操作です。セーブポイントのようなものです。
push。自分の変更を、リモートに送る操作です。
pull request。「この変更を取り込んで」と依頼する仕組みです。チーム開発の中心です。

この5つの流れを、自分の手で一度通すことが大切です。入社前に、自分のリポジトリで「clone→branch→commit→push→PR」を一周してみましょう。

最低限触っておきたい開発環境

次に、開発環境です。実務で使う道具に、先に慣れておきましょう。初日に初めて触ると、それだけで一日が終わります。

1つ目はDockerです。先ほども触れた、環境を箱に詰める道具です。完璧に理解する必要はありません。「コンテナを起動する」「停止する」。この基本操作だけ、触れておけば十分です。

2つ目はターミナルです。黒い画面に、文字でコマンドを打つあれです。最初は怖く見えますが、慣れれば手放せません。cd、ls、mkdirなど、基本コマンドに触れておきましょう。

3つ目はVSCodeです。コードを書くためのエディタです。多くの現場で使われています。拡張機能の入れ方や、ファイルの開き方に慣れておくと安心です。

道具に慣れているだけで、初日の余裕がまるで変わります。内容より先に、道具で疲れてしまうのを防げます。

入社前の1週間で、ターミナルとVSCodeを毎日10分だけ触ってみましょう。手が覚えてくれます。

実務でよく使われるツール

開発環境のほかにも、現場で使うツールがあります。コミュニケーションや、タスク管理の道具です。名前だけでも、知っておきましょう。

まずSlackです。チームの会話は、ほぼここで行われます。メールより気軽で、速いのが特徴です。スレッドの使い方や、メンションの付け方を知っておくと安心です。

次にタスク管理ツールです。BacklogやJiraが、よく使われます。自分のやるべき作業が、チケットという単位で管理されています。「チケット」とは、一つの作業のことだと覚えてください。

そしてNotionです。社内の情報がまとまっている場所として使われます。マニュアルや議事録が、ここに集まっていることが多いです。検索のやり方を知れば、自分で情報を見つけられます。

どのツールも、使いながら覚えれば大丈夫です。完璧に準備する必要はありません。「こういう道具がある」と知るだけで、初日の戸惑いが減ります。

入社が決まったら、SlackとNotionの無料版を触っておきましょう。操作の雰囲気を、つかんでおけます。

私が実務で失敗したこと、そして学んだこと

質問を遠慮して半日溶かした話

ここからは、私自身の失敗談です。かっこ悪い話ですが、あなたの役に立つと思って正直に書きます。

入社して、まだ2週目のことでした。ある機能の実装中に、環境構築でつまずきました。Dockerのコンテナが、どうしても起動しなかったのです。

でも、私は質問できませんでした。「こんな初歩的なこと、聞いたら呆れられる」。そう思って、ひたすら一人で調べ続けました。先輩は、忙しそうに見えました。

結局、午前中いっぱい固まりました。昼が過ぎても、解決しません。気づけば、半日が消えていました。意を決して質問したら、答えはたった5分で出ました。

原因は、環境変数の小さな設定ミスでした。先輩は、嫌な顔ひとつしませんでした。むしろ「もっと早く聞いてよ」と、笑ってくれました。

あのとき学んだのは、遠慮は親切ではない、ということです。抱え込みは、チームの時間を奪います。詰まったら、勇気を出して早めに聞きましょう。

コードレビューでボコボコにされた話

次は、コードレビューの話です。これは、多くの新人が心を折られるポイントです。

コードレビューとは、書いたコードを先輩にチェックしてもらう文化です。問題がないか、もっと良い書き方がないか。第三者の目で、確認してもらいます。

私の初めてのレビューは、指摘の嵐でした。真っ赤になったコメント欄を見て、正直、心が折れかけました。「自分には向いていないのかも」と落ち込みました。

でも、ある先輩の一言で見方が変わりました。「指摘は、君を否定してるんじゃない。コードを良くしてるんだ」。その言葉に、救われました。

レビューは、否定ではなく成長の機会です。指摘の数だけ、学べることがあります。丁寧に見てもらえるのは、期待されている証拠でもあります。

今では、レビューがありがたいと感じます。一人では気づけないことを、教えてもらえるからです。指摘されたら、落ち込む前に一つメモしましょう。

それでも成長できた理由

こんなに失敗ばかりの私が、なぜ続けてこられたのか。理由を、正直にお話しします。

1つは、小さな改善を積み重ねたことです。一度に大きく変わろうとは、しませんでした。昨日できなかったことを、今日ひとつできるようにする。それだけを続けました。

失敗した日も、必ず学びを一つメモしました。失敗を、次の行動に変えていったのです。失敗は、記録すれば財産になります。

もうひとつは、メンタルの保ち方です。落ち込んだとき、自分を責めすぎないようにしました。「未経験なんだから、できなくて当たり前」。そう、自分に言い聞かせました。

大切なのは、他人と比べないことです。比べる相手は、昨日の自分だけで十分です。半年前の自分を思い出せば、確実に成長しています。

あなたも、必ず成長できます。今つらいのは、ちゃんと前に進んでいる証拠です。うまくいかない日こそ、自分に優しくしてあげてください。

Section 09

実務1ヶ月目の目標は「戦力」ではなく「信頼獲得」

新人に期待されている本当の役割

ここで、改めて期待値の話をします。これを理解すると、肩の荷がぐっと軽くなります。

多くの新人が、勘違いしています。「早く戦力にならなきゃ」と、自分を追い込んでしまうのです。でも、それは大きな誤解です。

未経験の新人に、即戦力は期待されていません。会社は、最初の数ヶ月で活躍できるとは思っていません。むしろ、教える前提で採用しています。

では、何が期待されているのか。それは「成長できる人かどうか」です。今の実力ではなく、伸びしろを見られています。素直さや、学ぶ姿勢が問われます。

だから、できないことに焦る必要はありません。今できないのは、当たり前なのです。大事なのは、昨日より今日、少しでも前に進んでいることです。

期待値を、正しく持ちましょう。最初の1ヶ月の目標は「活躍」ではなく「成長する姿を見せること」です。

信頼はどうやって積み上がるのか

では、信頼はどうやって積み上がるのでしょうか。実は、特別な才能はいりません。3つの行動の、積み重ねです。

1つ目は、報告です。こまめに進捗を伝える。詰まったら、すぐ共有する。報告がある人は、安心して仕事を任せられます。状況が見えると、人は信頼します。

2つ目は、質問です。わからないことを、適切に聞く。抱え込まずに、早めに相談する。良い質問ができる人は、伸びる人だと判断されます。

3つ目は、行動です。教わったことを、すぐ試す。指摘されたことを、次に活かす。行動の速い人は、それだけで信頼されます。

この3つは、技術力とは関係ありません。今日から、誰でもできることです。だからこそ、未経験者にとって大きな武器になります。

信頼は、一日では積み上がりません。でも、毎日の小さな行動で確実に貯まります。「報告・質問・行動」の3つを、毎日意識してみましょう。

半年後に差がつく人の特徴

最後に、半年後の話をします。同じスタートでも、半年後には大きな差がつきます。その差は、どこから生まれるのでしょうか。

1つ目は、学習習慣です。業務後や休日に、少しでも学び続ける人。その積み重ねが、半年で大きな差になります。1日30分でも、続ければ別物です。

2つ目は、情報収集です。技術の世界は、変化が速いです。新しい情報を、自分から取りにいく人が伸びます。受け身では、すぐに置いていかれます。

3つ目は、自己改善です。失敗や指摘を、次に活かせる人です。同じミスを繰り返さない。改善を続ける人は、複利で成長します。

これらは、才能ではありません。すべて、習慣です。誰でも、今日から始められます。だからこそ、やるかやらないかで差がつきます。

半年後、振り返って驚くはずです。「あんなに不安だった自分が、ここまで来た」と。今日の小さな一歩が、半年後の大きな差を作ります。

Section 10

まとめ｜未経験エンジニアが最初に目指すべきゴール

技術力より大切なこと

長い記事を、ここまで読んでくれてありがとうございます。最後に、一番伝えたいことをまとめます。

未経験エンジニアが最初に目指すべきは、技術力の高さではありません。もっと大切なものがあります。それは、3つの力です。

1つ目は、自走力です。わからないことを、自分で調べて進める力。完璧に解く力ではなく、次の一手を打てる力です。この力が、すべての土台になります。

2つ目は、調査力です。検索し、ログを読み、原因を探る力。エラーを、怖がらずに向き合う力です。これがあれば、どんな壁も乗り越えられます。

3つ目は、報告力です。状況を正しく伝え、助けを求める力。チームの中で、信頼を積み上げる力です。地味ですが、最強のスキルです。

この3つは、技術力よりも先に身につきます。そして、ずっとあなたを支え続けます。まずは「自走・調査・報告」の3つを、意識することから始めましょう。

この記事の要点まとめ

ここで、記事全体の要点を振り返ります。長かったので、ポイントだけおさらいしましょう。

まず、実務でぶつかる壁です。コードが読めない、エラーが解決できない、開発環境がわからない。会話についていけない、質問ができない。この5つは、誰もが通る道です。

次に、挫折する原因です。学習と実務を同じだと思う、技術力だけで評価されると思う。完璧主義になる、できる新人を目指しすぎる。原因を知れば、避けられます。

そして、生き残るための行動です。わからないことを認める、質問前に調べる、こまめに報告する。メモを取る、小さな改善を続ける。どれも、今日からできることばかりです。

大切なのは、最初から完璧を目指さないことです。求められているのは、即戦力ではなく、成長する姿です。信頼は、毎日の小さな行動で積み上がります。

あなたが感じている不安は、真剣に向き合っている証拠です。その不安ごと、前に進んでいきましょう。

今すぐやるべき最初のアクション

最後に、今日からできる4つのアクションを紹介します。読んで終わりにしないでください。行動して、初めて意味があります。

GitHubアカウントを作る。まだなら、今すぐ作りましょう。エンジニアの名刺のようなものです。5分でできます。
学習記録を残し始める。NotionでもGoogle Docsでも構いません。「今日学んだこと」を一行、書くだけです。
毎日1つエラーを調べる。検索し、ログを読み、原因を探る。この習慣が、エラー解決力を育てます。
質問テンプレートをメモする。「やったこと・起きたこと・調べたこと・理解した範囲」。すぐ見える場所に貼ります。

どれも、5分あればできることです。完璧でなくて、構いません。大事なのは、今日始めることです。

この4つのうち、まず一つだけでいいので、今やってみてください。その一歩が、あなたを「使える新人」に変えていきます。応援しています。