News / blogお知らせ / ブログ

ホーム お知らせ / ブログ ChatGPT時代に、伸びるエンジニアがやっている学習法
2026.09.25

ChatGPT時代に、伸びるエンジニアがやっている学習法

こんにちは、Good Labの羽田です。

「エンジニアって、どうやって勉強してるんですか?」

面談などで、よく聞かれる質問です。

僕たちエンジニアの仕事は、日々勉強の連続です。
新しい言語、新しい現場、新しい技術。

学んでクリアしたら、また次の壁が出てくる。
その繰り返しなんですよね。

今回は、二部構成でお話しします。

前半は、うちで現場に入っている現役エンジニアが、
普段どんなふうに勉強しているのか。

後半は、社長でもあり現役でもある僕自身が、
これまでどう学んできたのか。

その"事例"を、正直に話していきます。

【前半】現役エンジニアの勉強法

まずは、うちのメンバーの話から。

現場でしっかり成果を出しているエンジニアが、
どんなふうに学んでいるのか。

聞いてみると、すごく地に足のついたやり方でした。

まずは「なぜ動かないのか」を自分で潰す

現場でコーディングをしていると、
分からないことや、うまく動かないことが出てきます。

そういうとき。

とりあえず動く形にする、で終わらせない。

「なんで動かなかったんだろう?」

まずは、そこを自分で調べにいく。

同じところで悩んでいる人の記事を探すと、
だいたい似たような事例が見つかります。

そこで、おおよその原因の見当をつける。

そのうえで、公式ドキュメントにあたる。

「どういう理由で動かなかったのか」
「逆に、どういう理由で動いているのか」

そこまで理解できる形で学んでいく。

まずは疑問をピンポイントで解消する。
そのあと、ドキュメントでしっかり理解する。

この順番でやると、
自分の”体験”として学べるんです。

自分の失敗から、
「本当はどうすべきだったのか」を考える。

遠回りに見えて、これがいちばん身につく。

彼と話していて、そう感じました。

新しい言語も、やり方は同じ

「今までは別の言語だったけど、次の案件ではJavaをやります」

こういう場面でも、やり方は基本的に同じだそうです。

まずは、現場にある”動いているもの”を見る。

すでに作られているものを読んで、理解していく。

やったことがないと、
「何から気をつければいいんだ」となりますよね。

でも、まずは自分で動かしてみる。

そして、うまくいかないところを1個ずつ潰していく。

動いているものを理解するときは、
細かくログを入れてみたりして、関係性を掴んでいく。

「何が渡ってきて、何がどう返るのか」

そこを地道に追っていくと、
全体像が見えてきます。

言語が変わっても、
“動くものから理解する”という軸は変わらない。

シンプルですが、本質だと思います。


【後半】僕(社長)の場合

ここからは、僕自身の話です。

進め方の軸は、実はメンバーとほとんど同じ。

まず”動くもの”をベースに、
どういう作りになっているのかを見て、全体像を把握する。

細かいところは、設計書があればそれを見て、
システム全体を掴んでいく。

そのうえで、今の時代ならではの話も含めて、
僕の”事例”を3つ話していきます。

ChatGPTは”補助”。落とし込むのは自分の頭で

最近はChatGPTのような生成AIも出てきました。

うまく使えば、学習のスピードも質も上がります。

これは、間違いなく有効です。

ただ、使い方には気をつけています。

ChatGPTが出してくれた答えを、
そのまま100%信用するわけにはいきません。

だからこそ、
最終的には公式ドキュメントにあたる。

そこが100%正しい、という前提で確認する。

AIに聞いて、
そこから詳しいところは公式ドキュメントで理解する。

生成AIが吐き出してくれたコードを見て、
「どういう作りになっているのか」をまず理解する。

そこから始めるようにしています。

あくまで、AIは補助。

自分の頭で落とし込む。

ここだけは崩さない。

これが、今の時代ならではの進め方だと思っています。

コードレビューで、学びは一気に深まった

自分で勉強していくことは、もちろん必要です。

でも、システムは他のメンバーと一緒に作っていくもの。

だからこそ、
他の人からのレビューが、すごく重要になってきます。

自分ならこう書く、というコードに対して、
「もっと効率よく、もっと綺麗に書けるよ」

そういう観点で教えてもらえる。

自分の知識を、深めて、広げていける。

ロジックの部分は、
ChatGPTだけでは100%にならないことも多いです。

経験者のレビューには、価値があります。

その人がこれまで培ってきたものを、
教えてもらえるわけですから。

指摘してもらえることで、学びがさらに深まる。

コードレビューは、
情報だけじゃなく”考え方”まで教えてもらえる場。

僕自身、ここで一気に伸びた感覚があります。

「たくさん書く」ことが正解だと思っていた

最後は、僕の恥ずかしい話です。

プログラミングを始めて間もない頃。

「行動量が多いほどいい」と、本気で思っていました。

何百行、何千行と、
かなり非効率な状態で書いていたんです。

でも、当時はそれで達成感があった。

「これだけ書いた」「こんなロジックが書けた」

やりきった感があって、正直、気持ちよかった。

でも、他の人からレビューされて気づきました。

コードの量も、綺麗さも、全然違う。

大事なのは、量じゃなかったんです。

読みやすさや、
その場面(TPO)に合ったコーディングができているか。

正解は、ひとつではありません。

でも、その場面に合ったものを作れている。

それが、いいエンジニアだと思うようになりました。

たくさん書くのではなく、
いかに少なく、見やすく、可読性を上げて作れるか。

そこに”美しさ”がある。

最近は、そう感じることが多いです。

もちろん、
まずは自分で何かしら形にしてみることも大事です。

作ってみて、
そこに他の人の指摘や、調べて知った書き方が加わる。

そうやって学んでいくと、
かなり自分の中に落とし込めます。

最後に

今回は、僕たちの学習方法について、
現役エンジニアと社長、両方の視点から話してみました。

学んで、クリアして、また次の壁が出てくる。

それを繰り返していくのが、
エンジニアという仕事なのかなと思います。

「自分はこういう形で壁を超えた」
「こんなふうに学習しています」

そういうのがあれば、
ぜひコメントで教えてもらえると嬉しいです。

そして、
「今の自分の学び方に不安がある」
「これからどうスキルを伸ばせばいいか分からない」

そんな方は、お気軽にご相談ください。

現役エンジニア兼社長の僕が、
直接お話を伺います。