こんにちは、Good Labの羽田です。
「エンジニアって、どうやって勉強してるんですか?」
面談などで、よく聞かれる質問です。
僕たちエンジニアの仕事は、日々勉強の連続です。
新しい言語、新しい現場、新しい技術。
学んでクリアしたら、また次の壁が出てくる。
その繰り返しなんですよね。
今回は、二部構成でお話しします。
前半は、うちで現場に入っている現役エンジニアが、
普段どんなふうに勉強しているのか。
後半は、社長でもあり現役でもある僕自身が、
これまでどう学んできたのか。
その"事例"を、正直に話していきます。

目 次
まずは、うちのメンバーの話から。
現場でしっかり成果を出しているエンジニアが、
どんなふうに学んでいるのか。
聞いてみると、すごく地に足のついたやり方でした。
現場でコーディングをしていると、
分からないことや、うまく動かないことが出てきます。
そういうとき。
とりあえず動く形にする、で終わらせない。
「なんで動かなかったんだろう?」
まずは、そこを自分で調べにいく。
同じところで悩んでいる人の記事を探すと、
だいたい似たような事例が見つかります。
そこで、おおよその原因の見当をつける。
そのうえで、公式ドキュメントにあたる。
「どういう理由で動かなかったのか」
「逆に、どういう理由で動いているのか」
そこまで理解できる形で学んでいく。
まずは疑問をピンポイントで解消する。
そのあと、ドキュメントでしっかり理解する。
この順番でやると、
自分の”体験”として学べるんです。
自分の失敗から、
「本当はどうすべきだったのか」を考える。
遠回りに見えて、これがいちばん身につく。
彼と話していて、そう感じました。
「今までは別の言語だったけど、次の案件ではJavaをやります」
こういう場面でも、やり方は基本的に同じだそうです。
まずは、現場にある”動いているもの”を見る。
すでに作られているものを読んで、理解していく。
やったことがないと、
「何から気をつければいいんだ」となりますよね。
でも、まずは自分で動かしてみる。
そして、うまくいかないところを1個ずつ潰していく。
動いているものを理解するときは、
細かくログを入れてみたりして、関係性を掴んでいく。
「何が渡ってきて、何がどう返るのか」
そこを地道に追っていくと、
全体像が見えてきます。
言語が変わっても、
“動くものから理解する”という軸は変わらない。
シンプルですが、本質だと思います。
ここからは、僕自身の話です。
進め方の軸は、実はメンバーとほとんど同じ。
まず”動くもの”をベースに、
どういう作りになっているのかを見て、全体像を把握する。
細かいところは、設計書があればそれを見て、
システム全体を掴んでいく。
そのうえで、今の時代ならではの話も含めて、
僕の”事例”を3つ話していきます。
最近はChatGPTのような生成AIも出てきました。
うまく使えば、学習のスピードも質も上がります。
これは、間違いなく有効です。
ただ、使い方には気をつけています。
ChatGPTが出してくれた答えを、
そのまま100%信用するわけにはいきません。
だからこそ、
最終的には公式ドキュメントにあたる。
そこが100%正しい、という前提で確認する。
AIに聞いて、
そこから詳しいところは公式ドキュメントで理解する。
生成AIが吐き出してくれたコードを見て、
「どういう作りになっているのか」をまず理解する。
そこから始めるようにしています。
あくまで、AIは補助。
自分の頭で落とし込む。
ここだけは崩さない。
これが、今の時代ならではの進め方だと思っています。
自分で勉強していくことは、もちろん必要です。
でも、システムは他のメンバーと一緒に作っていくもの。
だからこそ、
他の人からのレビューが、すごく重要になってきます。
自分ならこう書く、というコードに対して、
「もっと効率よく、もっと綺麗に書けるよ」
そういう観点で教えてもらえる。
自分の知識を、深めて、広げていける。
ロジックの部分は、
ChatGPTだけでは100%にならないことも多いです。
経験者のレビューには、価値があります。
その人がこれまで培ってきたものを、
教えてもらえるわけですから。
指摘してもらえることで、学びがさらに深まる。
コードレビューは、
情報だけじゃなく”考え方”まで教えてもらえる場。
僕自身、ここで一気に伸びた感覚があります。
最後は、僕の恥ずかしい話です。
プログラミングを始めて間もない頃。
「行動量が多いほどいい」と、本気で思っていました。
何百行、何千行と、
かなり非効率な状態で書いていたんです。
でも、当時はそれで達成感があった。
「これだけ書いた」「こんなロジックが書けた」
やりきった感があって、正直、気持ちよかった。
でも、他の人からレビューされて気づきました。
コードの量も、綺麗さも、全然違う。
大事なのは、量じゃなかったんです。
読みやすさや、
その場面(TPO)に合ったコーディングができているか。
正解は、ひとつではありません。
でも、その場面に合ったものを作れている。
それが、いいエンジニアだと思うようになりました。
たくさん書くのではなく、
いかに少なく、見やすく、可読性を上げて作れるか。
そこに”美しさ”がある。
最近は、そう感じることが多いです。
もちろん、
まずは自分で何かしら形にしてみることも大事です。
作ってみて、
そこに他の人の指摘や、調べて知った書き方が加わる。
そうやって学んでいくと、
かなり自分の中に落とし込めます。
今回は、僕たちの学習方法について、
現役エンジニアと社長、両方の視点から話してみました。
学んで、クリアして、また次の壁が出てくる。
それを繰り返していくのが、
エンジニアという仕事なのかなと思います。
「自分はこういう形で壁を超えた」
「こんなふうに学習しています」
そういうのがあれば、
ぜひコメントで教えてもらえると嬉しいです。
そして、
「今の自分の学び方に不安がある」
「これからどうスキルを伸ばせばいいか分からない」
そんな方は、お気軽にご相談ください。
現役エンジニア兼社長の僕が、
直接お話を伺います。