新人の時期は、覚えることが多すぎます。
言語、フレームワーク、Git、レビュー、設計、コミュニケーション。最近は AI ツールも学びの前提に入りつつあって、「何から身につければいいのか」がかえって見えにくくなりました。
だからこそ、最初から全部を覚えようとしないほうがいいのです。
個別技術を片っ端から増やす前に、先に持っておいたほうがいい土台があります。この記事では、それを 3 つに絞って整理します。
- 名前付け
- フィードバック
- 学び続ける力
1. まず大事なのは、全部を知ろうとしないこと
新人の頃は、「知るべきことが山のようにある」と感じます。これは気のせいではなく、本当にそうです。
だからこそ、最初に持っておきたい前提があります。
それは、「何でも知っている人」になろうとしないことです。
どれもこれも大切なことに思える。けれど、すべてをきちんと知るには、「知るべきこと」が多すぎます。
ここで大事なのは、今どれだけ知っているかより、これからどれだけ伸び続けられるかです。
いま高い場所にいるかどうかより、上がっていく傾きのほうが大事です。
新人の時期は特に、「何を知っているか」だけで自分を評価しがちです。でも本当に見るべきなのは、次の 1 週間、次の 1 か月で伸びる習慣を持てているかです。
焦る気持ちが出てきたら、こう考えると少し楽になります。
- 今日は全部分からなくていい
- でも、来週の自分が少し前に進める状態にはしておく
この感覚は、あとで出てくる「フィードバックを受ける姿勢」ともつながります。
2. 実装では「どう書くか」より先に「何を書くか」を考える
新人の頃は、どうしても「どうやって作るか」に意識が寄ります。
- この文法でいいのか
- この書き方は正しいのか
- この処理順で動くのか
もちろんそれも大事です。
ただ、実装が少しずつ分かってきたところで、もう一段上の視点が必要になります。それが「何を書いているのか」を言葉として表せているか、です。
「名前付け」は、プログラミングの細部ではなく設計の入口
プログラミングで、変数やメソッドなどの名前が曖昧だと考えていること自体が曖昧になります。
逆に言うと、名前が良くなるだけで、コードの見通しはかなり良くなります。難しい設計論を持ち出す前でも、名前付けはすぐ改善できます。
特に意識したいのは、「実装する側の都合」ではなく、「使う側から見て自然な語彙」になっているかです。
- 意図が読み取りにくい書き方 (手順は分かりやすいが、意図は分かりにくい)
if (name.GetLength() > 0 && name.GetLength() <= 50)
- 意図が読み取りやすい書き方 (IsValidName は別途サブルーチンやメソッドとして自作)
if (IsValidName(name))
たとえば、name.GetLength() > 0 && name.GetLength() <= 50 は間違いではありません。
でも、もし自分が本当に書きたいことが「有効な名前かどうか」なら、IsValidName のような語彙を持ったほうが、コードはぐっと読みやすくなります。
ここで大事なのは、短く書くことではありません。
意図が読めるように書くことです。
サブルーチンやメソッドは、処理手順の切り出し先ではなく、「この場面で何をしているか」を言葉にするための道具でもあります。
新人のうちにこの感覚を持てると、あとで設計を学ぶときにかなり効いてきます。
明日から試せること
今日書くコードで、次のどちらかを 1 つだけ試してみてください。
- 条件式を、意図が読める名前に置き換えられないか考える
- サブルーチン名やメソッド名が「何をしたいか」を表しているか見直す
たった 1 か所でも、読み手に伝わる語彙を増やす練習になります。
3. 分からないことは、解けないのではなく、まだ問題が見えていない
新人の頃に本当によく起きるのが、「いまいちうまくいかない」という状態です。
この言葉、すごく自然に出てきます。でも、実はここに大きなヒントがあります。
「いまいちうまくいかない」は、解決策がないのではなく、まだ問題の輪郭がはっきりしていないことが多いです。
つまり、詰まっている本体はコードではなく、問題の切り分けかもしれません。
問題を言葉にすると、前に進みやすくなる
何が起きているかを整理するだけで、半分くらい解けることがあります。
「いまいちうまくいかない」を、次の 4 つに分けるだけでかなり変わります。
「どこが問題なのか」が見えやすくなります。
フィードバックは、評価ではなく学びの材料
もう 1 つ大事なのが、フィードバックです。
理解そのものは、誰かが代わりにやってくれるものではありません。最終的に「分かる」のは自分です。
諺「馬を水の所に連れて行くことはできても、水を飲ますことはできない。」
“You can lead a horse to water, but you can‘t make him drink.”
でも、自分だけで考えていると、「何が分かっていないのか」が見えないことがあります。そこで効いてくるのが、レビュー、対話、ペア作業、説明する経験です。
フィードバックは、できていないところを責めるためのものではなく、見えていなかった差分を見つけるためのものです。
新人のうちは特に、フィードバックを避けないほうが伸びます。
もちろん、指摘を受けるのはしんどいです。
でも、しんどさの先にあるのは「自分がダメだ」という結論ではなく、「次にどこを直せば前に進めるか」という具体性です。
よい質問は、成長のための技術
質問するのが苦手な人は多いです。特に、「こんなこと聞いていいのかな」と止まってしまう人は少なくありません。
そんなときは、完璧な質問を作ろうとしなくて大丈夫です。まずは次の 3 つだけ揃えれば十分です。
- 何をしたいのか
- どこまで試したのか
- 何が分かっていて、何が分からないのか
これが言えるようになってくれば、質問力はかなり強くなります。
4. 補足: 先輩や教育担当にも役立つ視点
この記事の主な読者は新人本人ですが、先輩側にも役立つポイントがあります。
手本は、答えより強い
新人に何かを伝えるとき、答えだけ渡しても、うまく再利用できないことがあります。
それよりも効果が大きいのは、実際にどう考えたか、なぜそうしたかを見せることです。
- リファクタリングをどう進めるか
- テストをどう足すか
- 名前付けをどう判断するか
このあたりは、手本を見せるだけで理解の速度がかなり変わります。
教え、教わる場そのものに価値がある
学びは、教材だけでは完結しません。
教え、教わる場があると、そこにはコミュニケーション、フィードバック、勇気、尊重が生まれます。新人が伸びるかどうかは、個人の努力だけでなく、その環境にもかなり左右されます。
新人を育てる側の仕事は、正解をその場で渡すことだけではありません。どう考えるかを見せること、理由を言葉にすること、安心して学べる場を保つことが、まとめて成長の土台になります。
「授人以魚 不如授人以漁」by 老子
(「魚を与えるのではなく、釣り方を教えよ」、
“Give me a fish and I will eat today; teach me to fish and I will eat all my life.”)
実装技術を軽視しない
たまに、「動けばいい」「細かい書き方は後でいい」と言いたくなる場面があります。
もちろん、まず動かすこと自体は大事です。
ただ、だからといって実装技術を軽く見てよいわけではありません。外から見える品質だけでなく、内部の読みやすさや変更しやすさも、長い目で見ると大きな差になります。
5. 明日からの一歩
ここまでの話を 3 つの原則にまとめると、こうなります。
3 つの原則
- 名前を雑に扱わず、意図が読める語彙でコードを書く
- 分からないことを放置せず、問題を切り分けて言葉にする
- フィードバックを避けず、学びの速度を上げる材料として使う
そして、これを日々の行動に落とすなら、次の 3 つから始めるのが現実的です。
新人向けの 3 つの実践
- 今日書くコードで、1 つだけ名前を改善する
- 詰まったら、「症状」「試したこと」「詰まっている点」を 3 行で書く
- 毎週 1 回、自分が学んだことを誰かに説明する
どれも地味です。
でも、地味なことほど効きます。新人の時期は、とびきり派手な成長戦略より、続けられる習慣のほうが強いです。
おわりに
新人の時期に必要なのは、最初から全部できることではありません。
むしろ大事なのは、全部を覚えようとして止まらないことです。
名前を少し良くする。分からないことを言葉にする。フィードバックを受ける。そういう基礎を積み重ねると、あとから技術はいくらでも乗ってきます。
今の高さより、学び続ける傾きのほうが大事です。
もし今、覚えることが多すぎてしんどいなら、全部を背負わなくて大丈夫です。まずは今日のコードで 1 つ、名前を良くするところから始めてみてください。