始めに
こんにちは〜まんじです。
今回はプログラミングの勉強法で、「明らかにこれは効率が良いだろ」てきなやつをご紹介したいと思います。
この記事の内容は大体こんなんです。
- プログラミング入門レベルの勉強法の場合
- とりあえず入門レベルの文法は真似をする
- 真似て作っていって改良する
- 何かの手段としてググる or AIに聞きながら目的を果たす（入門レベルの後）
- 個人開発で何かを作る
- 実務のタスクをこなす
- 実務のコードや使ってる技術やドメイン知識などを調べる
- 実務で使ってる技術を勉強する
- インプット系（なんとなく知ってることは増えるぐらい）
- 技術書を買って読む
- Kindle Unlimitedの技術書を使う
- Qiitaを読む
- Zennを読む
- Youtubeを見る
- Mediumを読む
- Devを読む
プログラミングの効率が良さげな勉強方法に関して超シンプルに言うと、
アウトプットベースでインプットしてれば伸びるんじゃね？
説が自分の中では強めというか確信に至ってます。
プログラミング使って働いたり、何か作ったりすることをベースに必要な知識をインプットをしていく、みたいな手順です。
逆にインプットベースだとアウトプットがないので、なんか知ってる風だけど、いざ使えるか使えないかで言うと使えないみたいな状態になりがちかなーと思います。（あと、インプットベースだと技術老害っぽくなりがち）
ということで、詳しく書いてみたいと思います。
プログラミング入門レベルの勉強法の場合
とりあえず入門レベルの文法は真似をする
プログラミングに入門したての頃の勉強方法としては、ドットインストールあたりを使って文法を書くのも真似してとりあえず動かすのがおすすめの勉強スタイルです。
例えば、forループを回すのも動画とかでインプットしたらそこから自分も実際にそれを真似して動かしてみる、、、みたいなことを定番のプログラミングの文法の項目で繰り返します。
- 変数を学んだ
- 変数を定義して代入してprintやらconsole.logやらをして表示する
- 関数を学んだ
- 関数を定義して使ってみる
- 関数から関数を呼んでみる
- 配列を学んだ
- 配列を定義してみる
- 配列から要素を取り出してみる
- etc…
このフェーズで大事なのは使ってる入門レベルの教材を1~2周ぐらいちゃっちゃと2~3週間以内には終えて次にいくことです。
プログラミングの文法とかって文法を書く練習するからできるようになるんじゃなくて、実際に何を作って試行錯誤していく過程で理解がより深まっていきます。
例えば、JavaScriptの関数型の処理(map, some, reduce, filter)とかって練習するから処理がすぐに書けるようになるんじゃななくて、配列の処理をやる必要性に何度も迫られて何度もやってるから徐々に脳死でできるようになるみたいな感じです。（関数型の処理とか知らねーよって人は無視してください）
実際に使う必要があるから仕方なく使いまくる、、、みたいなスタンスで入門レベルの文法は馴染んできます。
真似て作っていって改良する
入門レベルの文法の勉強が終わったら次はなんか真似して作っていってそれを改良するのがナイスなプログラミング勉強法になります。
1冊本をチョイスしてから（Todoアプリを作るみたいな定番のやつ）、そういった題材のアプリを真似てそれ通り作っていって、そこから自分好みに改良します。
例えば、UIがしょぼかったらUIをcssとかjs使って良くしたり、独自のロジックを追加してみたり、、、という具合にです。
自分で機能とかを考えて実装方法を考えて調べて試行錯誤しながら実装していくのが、すごく勉強になるというか、普通に効率が良いです。
その作業を気合いでやることでポートフォリオが作れるので、そっからは会社に応募して実務ゾーンに入っていって実務で作ることをベースにインプット（勉強）をしていけます。
入門レベルの文法を軽くやったら、とりあえずなんかのハンズオン系（実際に手を動かす系）の本とかで何かしら作っていくのがおすすめです。
逆に言うと、何かしらのもの（アプリとか）を手を動かして作っていかないとプログラミングはまじでできるようになりません。
何かの手段としてググる or AIに聞きながら目的を果たす（入門レベルの後）
*こっからはわりと実務入ってからのゾーンです
「目的のための手段としてプログラミングをやる」ってのが一応、ナイスな勉強法の抽象化した表現です。
具体例を書いてみます。
個人開発で何かを作る
ポートフォリオ作りも個人開発で何かを作ることの1つなんですが、個人開発でなんかしらのアプリやらシステムを作るのはプログラミングの勉強としてかなり良いと思います。
自分も今まで4~5個ぐらい作ってきましたけど、「作る」もしくは「稼ぐために作る」という目的があってそのために必要な技術を全体的に勉強できたので今振り返ると技術力向上に役立ったと思ってます。
ただ、個人開発で勉強するデメリットとしては、「自分のできる範囲で妥協しがち」というのがあります。
例えば、実務だったら微妙な実装とか意味不明な実装（コードが微妙だけど動くみたいな）の場合は、コードレビューが通らないので改善が必要になります。
一方で個人で開発して勉強していると、そこらへんが適当でも問題ないので、全体的に勉強にはなってもいわゆる「実務レベルのコード」にはならないことが多かったりします。
ただそういったデメリットはあっても、個人開発でゴリゴリに手を動かしまくってると仮に適当なコードが多かったとしても、インプット＆アウトプットが繰り返されるので、やっぱり技術力は伸びます。
実務しながら個人開発もすると、実務で学んだことを個人開発で使えたり逆も然りってなるので、技術力がモリモリと上がりがちです。
ちなみに実務しながら個人開発もごりごりやると、実際にやってみると分かるんですが、すごく疲れます…🥲
実務のタスクをこなす
なんだかんだでプログラミングの勉強法として1番効率が良いんじゃね？と思われる方法が、「実務のタスクをこなす」です。
個人的には「実務のタスクをこなしながら、個人開発で同じ技術を使う」ってのが今振り返ってみるとすごく効率が良かったというか技術力が伸びたなって思うシーンです。
実務でタスクをやっていると上司とか同僚からレビューをもらいながらで開発できたり、実務レベルのコードじゃないと受け入れられない体勢になるので嫌でも技術レベルが上がります。
あとは良くも悪くも評価にさらされることになるので、本気具合も実務のが高くなってそういう部分も良いところです。
実務だと、、、
- コードの書き方
- ナイスなコード、バッドなコード
- ナイスな実装、バッドな実装
- 環境（linterがあるとか, Dockerとか, AWSとか）
- アーキテクチャ
こういった実際に仕事してみないと分からない感じの部分も向上しますし、何より肌感で「何年ぐらいの人はこんぐらいできるんだな〜」とか「メガベンチャー出身のこの人はこれぐらいか…」みたいなコードやらコンテキストやらの部分が実は1番勉強になります。
プログラミング自体もそうだし、プログラミング周辺環境も含めて勉強になるって感じでございます。
ぶっちゃけ、脳死で大量に労働しまくってインプットも適宜するのが、技術力はおそらく最も伸びる気がします。
準委任契約とかでいっぱい働いてれば時給4000円なら月100万円とかのお金も稼げるし、技術力を伸ばしたいなら一石二鳥です。
実務のコードとか実務で使ってる技術やドメイン知識などを調べる
実務で開発をしていると、プロダクトのコードやその周辺技術などの設定やらデータベース設計やらが見れます。
そのコードを使って、使用しているライブラリを見たり調べたり、データベースの設計やらを見たり、アーキテクチャ見たり、苦手な箇所を調べたりAIに聞いたりすることも、効率良い勉強方法の1つだと思います。
この方法を使うと仕事している現場での評価も上がりやすくなりますし、実務レベルの技術力が爆上げされるので、なんていうかいろいろと本当に良いです。
実装タスクなどをプライベートな時間でこなしつつ、普段よく分からないけどなんとなくやっている部分を改めて落ち着いて調べてみるとかもかなり効率が良いんじゃないかな〜って思います。（セルフブラックだけど、自分のためになる）
あとは実務入ってから勉強するなら全く関係ないところじゃなくて、使われてる技術領域を真っ先にカバーしちゃうほうが、仕事してる時間もそれに強制的にふれるのでめちゃくちゃ効率が良いです。
なぜか仕事の遂行レベルも低い段階から謎に他の領域を勉強したくなっちゃったりしますが、まずは実務で抑えきれていない部分から抑えていくこと（目の前のことを必死にやること）が効率が良いなってのは思います。
あと、個人的にインターンしてる頃とかにReactが全然できないのになぜかnginxとかJavaの勉強をしていた時期があって、振り返ってみると謎行為でした。
実務で使われてて全然理解できてなかったReactをやればよかったと今は思います。なぜ逃げていたのか。。。
ということで、実務周辺の知識から勉強していくのはすごく効率が良いのでおすすめです。
実務で使ってる技術を勉強する
若干上とかぶるんですけど、実務で使ってる技術を勉強するのも効率が良いです。
実務で使っている技術を勉強する: インプット
実務で使う: アウトプット
このサイクルが確立されるので、より効率良く勉強できます。
一方で実務で使ってない技術とかを日々勉強しても、あんまり定着しない感というか、実際に使わないとあんまり定着しない可能性が高いです。
例えば、実務でDockerが使われてて「Docker全然わからん！」とかなら、とりあえずDockerを勉強しつつ実務のDockerfileとかdocker-compose.ymlとかと見比べたりして勉強していくような感じ。
ここで繰り返していることを強調すると…
「アウトプットのためのインプット」
ができれば、プログラミングの勉強法としてはかなりよさげです。
完全にアウトプットだけになるとあんまり伸びませんが、ちょいちょい調べたり勉強する必要がある状態でアウトプットができている状態はかなり良さげです。
ただ、完全にアウトプットだけになる状態って、特定の領域でかなりできる状態なのでそれはそれで全く問題がないというか、この記事の文字を読む必要性は皆無です。
インプット系（なんとなく知ってることは増える）
インプット系は少し扱いが難しくて、ただひたすらインプットしまくってもプログラミングというか技術力はあんまり上がりません。（と自分は思っています。）
知ってることは増えるんだけど、いざ実装とかそれをなんらかのアウトプットにしようとした時にスピードが異様に遅いとか、知ってるだけで役に立ってないとか、自分の稼ぎに全然直結してないとか、そういう現象が起こりがちです。
例えば、「AWSのlambdaがサーバーレスでサーバーを気にしないでコードを実行できる、lambda関数はレイヤー層からライブラリとかインポートできてClould Watchでログが見れる」みたいなこと（本とか読めば書いてある）を知っていたところで、実装できるかっていうとまた別の話だったりします。
なので、インプットはあくまでインプットって感じではあります。
必要ではあるけどそれでは十分じゃないです。
（実装で必要になれば嫌でもインプット含めてアウトプットできるので、それがやっぱり何度考えてもベストだと思う）
インプット勉強法①: 技術書を買って読む
技術書には2種類ぐらいあって、1つ目が体系的に網羅されて解説されてる系、2つ目がハンズオン系で手を動かしてやってみよう系です。
体系的に網羅されて解説されてる系はネットで無料で調べて情報をインプットするよりも多少効率が良いような気がする（気がするだけ）のと、なんとなく勉強してる感が出て少しモチベが上がるかもしれません。
ハンズオン系はその通り動かせば入門的な内容はそれなりに知れるので、入門の時にすごく効率が良いです。
技術書は1冊3000~4000円ぐらいすることが多くて「高えええええ！！！」って思っていた時期がぼくにもあったんですけど、月1万円ぐらいまでの読書費用（自己投資費用）って考えてお金を使うと高く感じなくなるのと、月1万円本買って読み切るのはかなりキツイのでそういうマインドで買うといいのかなって思います。
あとは開業してお金稼ぐと（フリーランスやら副業ッスナ）経費につっこめるので、なんだかお得に買えてる気持ちになります。
という余談も含みましたが、本はどっちでもいいと思います。
別に技術書は買わなくてもそこまで問題ないです。
少なくとも自分ぐらいのフリーランスエンジニアで年収700後半~800万円ぐらいのレンジまでであれば本なんてなくてもまだ勉強できる範囲はあほほどあるので全くもって問題ないです。
インプット勉強法②: Kindle Unlimitedの技術書を使う
本と同じなんですけど、Kindle Unlimitedに紙では出版されてないけど、登録されてる系の本を使うのも結構良いっちゃ良いです。
小さいトピックごとにハンズオン形式が多いので、ぼくはプログラミング入門時に使いました。
プログラミング入門シーズンとかには値段的にもコスパが普通に良いと思ってます。
オライリーとかの技術書はすごいちゃんとしてるんだけど1個が重い一方で、Kindle Unlimitedとかは良くも悪くもライトなものが多いので、ハードルが低いって感じ。
ポートフォリオ作りとか、なんかしらの言語とか技術に入門する時とかの取っ掛かりは、Kindle Unlimitedで十分です。
（あと、最初の部分さえ突破しちゃえば、そっからはネットとかAIに聞いていけば余裕。）
インプット勉強法③: Qiitaを読む
Qiitaに関しては移動中とかの隙間時間とかに、メインで勉強してるテーマを調べたり、エンジニア界隈のトレンドを知るって意味だと勉強に良いと思います。
リアルとかだと「Qiitaに記事を書くやつはきもいし間違ってる」みたく言う人もいるんですけど、個人的には間違ってても80%ぐらいあってれば良いと思うのし間違ってると後で気づくので、良いと思ってます。
特に特定のトピックをQiita内の記事読みまくるとかは、技術書買って読む代わりになるので、結構おすすめです。
例えば、Docker勉強しようと思った時にわざわざDockerの基本がわかるウンタラ3000円の本じゃなくて、Qiitaで記事をいっぱい読んで手を動かし始めれば理解できる、てきな感じです。
どのみちそれなりに使えるレベルにするには手を動かしてハマってググったりAIに聞いたりして解決するしかないので、その最初のステップとしてはQiitaはすごく使えます。
インプット勉強法④: Zennを読む
Qiitaとほぼ同じなんですけど、Zennのがなんか全体的に少しレベルが高いというか記事の内容含めてモダンでちゃんとエンジニアやってる人が書いてる雰囲気はあります。
Qiita: 駆け出しエンジニアポエムと入門系の記事が多い
Zenn: ちゃんと働いてるエンジニアの人が純粋に技術記事を書いてる雰囲気
Zennも同じように知りたいトピックを調べたりすればいいのと、トップページに出てくる記事が結構イマドキなトピックが多いのでトレンドを知る的な意味合いの勉強としても良いと思われます。
インプット勉強法⑤: Youtubeを見る
Youtubeもめちゃくちゃいろいろインプット系からハンズオン系のリソースがあります。
- 3分ぐらいで解説する系の短い解説系
- 普通に解説系
- ハンズオン系、一緒に手を動かそう系
日本語に限らず英語にも広げると、無料でハイクオリティかつほぼ無限のリソースが使えます。
移動中に見て勉強するとかそういう使い方もできますし、英語で見て英語も一緒に勉強するとかもできます。
英語の勉強にもなるので、めっちゃいい。
インプット勉強法⑥: Mediumを読む
英語なんですけど、日本よりもなんていうか1歩進んでる感が微妙にあります。（英語のが人数多いし、そもそも最新のTech系は英語だし）
特定のジャンル？カテゴリ？トピックを定期購読することもできるので、それをメインのメールとかにやっておくと、世界のTech系の人がどんなことに関心を持ってるのかってのが微妙に分かります。
The reason you should stop rely on using react.
みたいなテイストのなんかエンジニアっぽい記事がよく出てきます。
（個人的にまじで興味がないのでフーンってチラッと見たりするぐらい）
インプット勉強法⑦: Devを読む
レイアウト的にもQiitaの英語版というか、Qiitaが多分Devの日本語版です。
使い方はQiitaとほぼ同じで、なんとなくトップページを見てトレンドを把握したり、知りたいトピックについて検索かければその手の記事がいっぱい出てきます。
まとめ
長々を書いてしまったんですけど、プログラミングの勉強で効率が良い感じのは「実務やりながら周辺技術を調べたりしつつ実務やりまくる」「実務で使ってる技術を個人開発でも使う」とかそこらへんだと思います。
実務に入る前なら、何かを作りながらその周辺技術で使う技術を勉強してそれを実際に使うイメージです。
あとは寝る前とか移動中とかにちょびっとインプットメインの勉強（技術書読むとかYoutubeで勉強したい技術系見るとか）をすると知ってる範囲が広がるので、アウトプットの範囲が広げられます。
とりあえず手を動かしてなんか作っていくこと（仕事するか、個人で何か作るか）ってことがプログラミングの勉強法というか入門シーズンも実務シーズンでも大事です。
