新人としての心構え

前章では、学生と実務の前提の違いを見ました。 この章は、それを踏まえて日々どう行動するかです。

技術は後からいくらでも身につきます。しかし、 最初の数ヶ月で身につけた行動の習慣は、その後ずっと残ります。

ここに書くのは、たった1つのことの言い換えです。

分からないことを、分からないまま放置しない。

1. 「なんとなく分かった」で進めない

新人が最も損をするのが、これです。

先輩「この処理は冪等だから、リトライしても大丈夫」
新人（冪等……？ たぶん大丈夫って意味かな）「はい、分かりました」

この瞬間、その後の会話がすべて崩れます。 そして、聞き返すハードルは時間とともに上がっていきます。

その場で聞く    → 30秒で終わる
3日後に聞く      → 「なぜ今まで黙っていたのか」になる
半年後に聞く     → もう聞けない

「すみません、冪等ってどういう意味ですか」
「今の◯◯という言葉、初めて聞きました。教えてください」
「一度整理させてください。つまり〜という理解で合っていますか」

分からないことリストを作る

会話や作業の途中で出てきた「知らない言葉」を、その場でメモします。

□ 冪等性 …… ？（マイクロサービスの実務にあるらしい）
□ ステージング環境の URL は？
□ 「引当」って在庫の何？
□ なぜこのテーブルに status が2つある？

そして、

□ 調べれば分かるもの   → 後で自分で調べる
□ 社内固有のもの       → 次の1on1やSlackでまとめて聞く
□ 業務のルール         → 業務側の人に聞く（ドメインとは何か）

放置していい項目は1つもありません。 ただし、 全部をその場で聞く必要もありません。分類して、いつ解消するかを決めてください。

2. 同じことを2回聞かない工夫

聞くこと自体は歓迎されます。しかし、 同じことを3回聞くと、さすがに信頼に響きます。

原因はほぼ、メモの取り方です。

✕ 言われたことをそのまま書き写す
   → 後で読んでも意味が分からない

○ 自分の言葉に置き換えて書く
   → 書いている時点で、理解できているかが分かる

## ステージングにデプロイする手順（自分用メモ 2026-08-08）
1. main にマージされていることを確認
2. Actions の「Deploy to Staging」を実行
3. 5分待って https://... で確認
※ 失敗したら #dev-staging に投げる。だいたい権限の問題らしい

3. 素直に受け取る。ただし盲従はしない

指摘された → 落ち込む → 隠すようになる     ← 最悪の循環
指摘された → 直す → 理由を聞く → 次に活きる ← これ

指摘は、あなたではなくコードに向けられています（第0部）。

そして重要なのは、「はい」で終わらせないことです。

✕ 「はい、直します」（なぜ直すのか分かっていない）
○ 「直します。これは◯◯という理由で問題になる、という理解で合っていますか」

納得できなければ、聞いて構いません。 議論して構いません。 「言われたから直した」だけの人は、次も同じ指摘を受けます。

4. 事実で話す

✕ 「たぶん動いています」「だいたい終わりました」「なんかエラーが出ます」
○ 「ステージングで3回試して、3回とも成功しました」
○ 「実装は完了、テストが未着手です」
○ 「このエラーが出ます（全文を貼る）」

「たぶん」と言いたくなったら、確かめられるかを考えてください（ドキュメントを書く）。 確かめたなら事実を言えます。確かめていないなら「未確認です」と言えば十分です。

「デプロイは完了しています」（実際は CI が通っただけで、本番未反映）

□ 「終わりました」の前に、何をもって終わりかを確認する（開発の流れの DoD）
□ 確認していないことは「確認していません」と言う

5. 早く、小さく見せる

完璧にしてから見せる → 方向が違ったら全部やり直し
7割で見せる          → 5分の会話で修正できる

「まだ汚いんですけど」と前置きして見せて構いません（第0部）。

□ 設計を始める前に、方針を一言で共有する
□ 実装の途中で、一度画面共有して見てもらう
□ PR は小さく、こまめに出す（開発の流れ）

6. 時間を測る

□ 「これは30分で終わる」と見積もってから始める
□ 実際にかかった時間を記録する
□ ずれた理由を振り返る

見積もりが外れるのは当然です。ずれの傾向を知ることに意味があります。

「調査に時間がかかる傾向がある」
「テストを書く時間を計算に入れ忘れる」
「レビュー待ちの時間を見積もっていない」

3ヶ月続けると、見積もりの精度が明らかに上がります。 そして、これはアジャイルとチーム開発のスプリント計画で直接役に立ちます。

7. やったことがなくても手を挙げる

「誰かこれやってくれる人」
→ 誰も手を挙げない数秒
→ ここで手を挙げると、経験が手に入る

「できます」ではなく「やってみたいです。教えてもらえますか」 でよいのです。

新人に対して、最初からできることを期待している人はいません。 やる意思があるかどうかだけを見ています。

□ 既に抱えているタスクが遅れそう  → 優先順位を確認する
□ 明らかに時間が足りない          → 状況を伝えて相談する

8. 記録を残す

□ 詰まったこと・解決した方法（自分用のログ）
□ 教えてもらったこと
□ 「なぜそうしたか」の判断（ドキュメントを書く）

3ヶ月後の自分は、今の自分の苦労を覚えていません。 そして、その記録は次の新人にそのまま渡せます。

9. 学び続ける。ただし業務時間内で

□ 分からなかったことを、その日のうちに1つ調べる
□ 業務で使う技術の公式ドキュメントを、少しずつ読む（新しい言語をどう学ぶか）
□ 先輩の PR を読む（レビューしなくても、読むだけで学べる）

□ 業務に必要な学習は、業務時間内でやってよい（そう明示している会社は多い）
□ 学習の時間が取れないなら、それはチームに相談すべき状況
□ 疲れている時に無理をしても、身につきません

10. 他人と比べない

□ 同期のほうが進んでいるように見える
□ 先輩は5分で終わることに、自分は3時間かかる

当たり前です。 先輩は同じことを100回やっています。

比べるなら、1ヶ月前の自分とだけ比べてください。

□ 1ヶ月前に分からなかった言葉が、今は分かるか
□ 1ヶ月前より、聞く前に自分で調べられているか
□ 1ヶ月前に3時間かかったことが、今は1時間で終わるか

心が折れそうな時

最初の数ヶ月、ほぼ全員が「自分は向いていないのでは」と思います。

□ 周りが何を話しているか分からない
□ 簡単そうなタスクに3日かかる
□ 迷惑をかけている気がする

これは能力の問題ではなく、単に経験していないだけです（第0部）。

□ メンター以外にも相談先があることを、初日に確認しておく
□ 体調と睡眠を優先する。判断力から落ちます
□ 一人で抱え込まない。これはこの本で最も繰り返している言葉です

まとめ

• すべては1つのことの言い換え——分からないことを放置しない
• 「なんとなく分かった」で進めない。その場で止めるのは失礼ではない
• 分からないことリストを作り、いつ解消するかを決める
• 同じことを2回聞かないために、自分の言葉でメモを取り直す。 それはそのまま次の新人のドキュメントになる
• 指摘は素直に受け取る。ただし理由を聞く
• 「たぶん」を減らす。確かめたなら事実を、確かめていないなら「未確認」と言う
• 7割で見せる。早いほど修正が安い
• 見積もりと実績を記録する。ずれの傾向を知ることに価値がある
• やったことがなくても手を挙げる。ただし抱えすぎたら優先順位を相談する
• 業務時間内で学ぶ。長く続けられることが最も価値が高い
• 比べるのは1ヶ月前の自分とだけ

参考資料

次の章では、技術以前の——社会人としての基本を扱います。 「そんなこと」と思うかもしれませんが、ここが崩れると技術は見てもらえません。