Q&A
過去質問は参考にならなかったのでしょうか。
技術書を用いた学習方法について悩んでいます。
自分は今学生であり、エンジニアとしては初心者です。それゆえ、いろいろな技術書を読み漁りながら知識をつける機会が多いです。最近、自分の技術書の読み方よりも吸収効率がより良くなる読み方があるのではないかと思っています。もちろん、人によって適した読み方・勉強方法があることは理解しています。その上で、エンジニアとしての先輩の方々の技術書を用いた勉強方法を知りたいと思います。教えていただいた方法の中から自分にも適していそうなものがあれば、その方法を試しに使わせていただきたいです。
現在の自分の技術書の読み進め方
技術書によって勉強方法が変わるので、すごくざっくりで3種類に大別させていただきました。
- ハンズオン形式の技術書
参考書を読み進めながら手を動かして実装をしています。読み終わった後は、気になる箇所のみを自分のプロダクトに反映させてみるなどのことをしています。
- 知識が文章形式で書かれた技術書(内容浅め or 難易度低め)
特にメモを取ることもなく、一気に読んでしまいます。
- 知識が文章形式で書かれた技術書(内容深め or 難易度高め)
各章ごと(章のボリュームが大きければ節ごと)にまとめを作り、自分のメモにまとめています。
学習の目的
自分が学習を通して満たしたい最大の目的は、学んだ知識が定着して、自分で好きに使えることになります。そのために復習が大切だとも思っているので、復讐の頻度なども同時に教えていただけると嬉しいです。
初心者ということもあり、そもそもの部分で間違えている部分などもあるかもしれません。その点も指摘していただければ幸いです。
御回答のほど、よろしくお願いします。
> 自分は今学生であり、エンジニアとしては初心者です。
学校での専攻と技術書で学習していることは同じですか？
どうでもいいけど質問書いた後校正程度はした方が良いんじゃない？
復讐→復習 とか。
んで技術書ってどういう物をターゲットにしてるのかよくわかんないっすね。
私は殆ど読まないので例ぐらいは挙げて欲しかったところ。
「技術書」とありますが質問内容として今のままだと技術に特化した感じがあまりしないので、「学校での教科書や参考書を使った勉強方法」とほとんど変わらないと思いますよ。
学んだ知識が自分で好きに使えること自体が目的ではなく、知識を使ってその先の何かをすることが真の目的ではないのでしょうか。もしそうなら、そこを書いてみてください。
回答7件
0
そもそもの部分で間違えている部分
技術書を読めば実力が身に付くという考え方があるように見える。読むのはあくまで知識のインプット。適切なアウトプットができないと何の意味もない。
正直、技術書なんてものはある程度読めるようになれば「どの情報がどこに書いてあり、どんな場面で使えそうなのか」を知っているぐらいでいい。実際にモノを作るときにはどうせ調べながらやる。
経験の中で適切な技術を組み合わせるための試行錯誤をした方が、実践的な知識は早く定着する。
本に書いてあることを自分が作りたいモノに役立つかどうか、その優先順位もわからない中で全部覚えようとするのは、英語の勉強で辞書をAから順番に暗記するようなもん。
ここでいう「技術書」は「入門書」を含まないので、入門レベルは当然ちゃんとやってる事が前提だけども。
投稿2021/07/15 02:23
編集2021/07/15 05:06
総合スコア8947
0
自分が学習を通して満たしたい最大の目的は、学んだ知識が定着して、自分で好きに使えることになります。そのために復習が大切だとも思っているので、復讐の頻度なども同時に教えていただけると嬉しいです。
使ってたら → そのうち定着
という結果論で良いんじゃないでしょうか．
よって，復習の頻度とは「使うとき」ということになるのでは．
投稿2021/07/15 03:09
総合スコア11996
覚える為の読んでの復習だと試験対策にはなりこそすれ実用にならないことが多いので、まさに「使うとき」で良いですね。いかに多く実際に使う（＝コードを書く）か。
テストを受けたりクイズ番組に出たりするわけじゃないので，
「いかに覚えるか」じゃなくて「いかに覚えなくてよくするか」という方向でも良いのではないかと．
自分の頭の記憶容量の少なさと揮発性には多少の自信があるので，
「外部記憶装置に頼れるようにすること」を重要視しますね．
自分の頭だけでやれるときというのは，せいぜい「キャッシュに残ってた」的な感じ．
使用頻度が高い情報はキャッシュヒット率が高くなる，というだけだなぁ．
私にとって，学生時代にやっていた「ノートを取る」という行為は，なんというか「書いて覚える」的な手段でしかなくて，それを後から見返すようなことは考えてなかったし，見返したという記憶もほとんどない．
対して，今現在，ノートなりメモを残すとしたら，それは記録用であり，後でそこから情報を引き出すことが目的になってる．
だからそのときには，そこに書き記す情報をわざわざ覚えようとは意識しない．
（だって，覚えられないから記録するんだもの）
余談だけど，「理解/把握 する」も「覚える」と同じ感じ．
あるまとまった技術的な話なりを 理解/把握 しておける期間というのも有限で，どんどん部分的に欠落していっちゃう．
例えば，「Aだから→Bであり→Cなので→Dだ」という話があったとして，
これの左側(A側)ほど基礎的な話で右側(D側)ほど基礎の上にある（応用的な）話だとすると，
Dという結論だけ何か覚えてるけど，当時は楽勝で把握していたはずのA～Cあたりの話があやふやになってしまってDを自分では導出できなくなったりする．
だから，記録を残す時点で「んなもん，言わなくてもわかるだろｗ 前提すぎるｗ」とか思ってるAやBあたりの話もなるべく省略せずに一緒に記録すると後で助かる．
こういうのはプログラムを相手にしていると良く起きる．
何か「プログラムコード自体が処理の内容を全て物語っているのだからコメントは書かなく良いのだ」みたいな話を稀に見ることがある気がするけど，
私に言わせれば，そんなことを言えるやつは単に頭が良すぎるだけだと思う．
確かに そこにあるコード＝処理内容 なんだから，「やってること」はコードを読み解けばわかるハズで，その意味では正しいんだけど，
「何でその処理をやってる（やることになった）の？」
「本当にその処理を行うことが正しいの？ ベストな形なの？」
みたいなことは背景事情無しにはわからない．
＃何か書いてるうちに自分が痴呆なんじゃないかと思えてくるけど，
人のコードについてその辺を尋ねると大抵は「そんなのもう覚えてない」って冷たく言われるから，
私だけが極端に頭がダメというわけでもないと思う．
（「自分のメモがどうの…」いう点において，少しでも参考になれば．）
> 自分の頭の記憶容量の少なさと揮発性には多少の自信
上手い!! (脳の機能とコンピュータの機能をかけている)
確かにそうですよね。
0
- 本は大事ではない
資格試験を目指すのであれば別ですが、プログラムのできるプログラマーになるためには、本を読んで覚えることは時間の無駄である場合が多いと思います。
私はPython歴5年(それ以前は一日だけ使ったことがあります)で、pandas歴8ヶ月ですがPythonやpandasについて、市販の書籍や電子書籍を読んだことはありません。これはそれまでの他言語での知識と経験がベースになっているので一般的に言えるとは思いません。
その経験では、いくつかの言語をちゃんと習得していれば特定の言語の入門書は読む必要がない場合が多いです。
ただし、最初三個ぐらいまでの言語は、あまり似ていないものを選んで入門書を通読しておくことは大事です。
- 覚えない方法を覚えましょう。
理解すべきものと記憶すべきものは区別して、必要に応じて調べことのできるものは覚える必要がありません。覚えておくことは、機能の存在とそれを調べる方法です。
言語を学ぶ場合、文法、データ構造と制御構造、実行論理、ライブラリの四つが大事です。
入門書は、プログラムの一般論、データ構造と制御構造の一部、ライブラリの一部を適当にまとめたものが多く中途半端です。
個々の言語の文法はわからなくなったら調べればよいので覚える必要はありません。
文法をしっかり理解するために学生の間にはBNFをちゃんと覚えておきましょう。これがわかるようになれば、あらゆるコンピュータ言語について公式ページとかにある文法定義が読めるようになります。
つまり、学生時代の間は、単なる知識ではなく、知識を理解・獲得するためのメタ知識を身につけましょう。
データ構造と制御構造は、全てを覚える必要はありませんが、良く使われるもの(1～3割)は覚えておいた方が良いです。残りは必要に応じて調べればよいので覚える必要はありません。
実行論理は通常の書籍には書いていないものが多いです。一番良いのはその言語処理系のソースファイルを読むことですが、一般のプログラマになるためにはそこまで必要はないでしょう。C言語などであればオブジェクトの属性、静的リンクと動的リンク、OSインタフェースぐらいがわかっていれば十分です。Pythonのような言語だと、バイトコードとその処理ぐらいがわかっていた方が応用が利きます。
ライブラリは重要ですが覚える必要はありません。調べることができるWebサイトを知っていて必要に応じて調べればよいでしょう。
- 良いソースコードたくさんを読みましょう。
市販本に書かれているソースコードは玉石混交です。
言語処理系やそのライブラリのソースコードがオープンになっているものがたくさんあるので、そういうものを読みましょう。
- 自身のパッションを維持しましょう。
やりたいことをやり、プログラミングを楽しみましょう。仕事に就くと楽しくないプログラミングをしなければならないこともあるでしょう。そのときに、昔やった楽しいプログラムはあなたを支えてくれるでしょう。
投稿2021/07/16 00:29
総合スコア24670
0
目的をもっと明確にしてみましょう。
「学んだ知識が定着して、自分で好きに使えること」という文面だけを見ると、プログラミング界の全知全能を目指しているようなものにしか見えません。
全知全能を目指すということはすなわち無限大の知識が必要ですが、それでは心身が疲弊するほど物事を覚えなくてはいけなくなります。
そもそも、プログラミングの勉強方法を知る必要はあるのでしょうか。その必要があるということは、覚えなければいけない知識がたくさん存在するということです。
そもそも、それほどの量の知識を覚える必要はあるのでしょうか。いえ、大抵の場合その必要はないでしょう。
例えば、プログラミングを覚える目的が「Webサイトを作ること」なのであれば、Webに関連する技術やWeb上で動作する言語に関する知識だけを得れば良いのです。「ゲームを作ること」なのであれば、ゲームを作れる言語やツールが何かを洗い出して、選定して、それだけを覚えれば良いのです。
そのようにして目的に沿った知識だけを覚えれば、目的が漠然としたままの状態と比較して覚えるスピードが段違いに変化します。
また、知識自体を無理に覚える必要はありません。それよりは知識が書かれている場所を覚えることが重要です。
例えば JavaScript を学習したいのであれば、JavaScript の言語仕様自体を覚えるよりも JavaScript の言語仕様が書かれた信頼のできるドキュメントがどこにあるかを覚えておくことです。
そうしておけば、知識自体を覚えていなくてもその場所を見ながらプログラミングすることができます。
長々と書いてきましたが、つまり、必要な情報だけに絞ればプログラミングで覚えておくことなんて実はあまり存在しないということです。
そのように考えの方向性を変えてみると、効率良く(楽しく)プログラミングを覚えることができますよ。
投稿2021/07/15 04:06
編集2021/07/15 07:37総合スコア2663
ないとは思いますが、もしプログラミング界の全知全能を本当に目指しているのでしたら、プログラミングの質問をするのではなく、人の限界を目指して記憶力のトレーニングから始めましょう。
趣旨は概ね同意ですけども、勉強＝努力しないもの、というのは納得がいかないなぁ。
勉強は「理解できないから」とか「押し付けられるから」楽しくないのであって、自ら進んでやる勉強は基本的に楽しいものだと思うけど。（そうじゃないと学者とかやってられんと思う）
「勉強」という言葉自体に悪いイメージしかなく、あまり良い風に「勉強」という言葉を使いたくなかったということでこのような表現になりました。確かに極端な表現だったかもしれません。
※指摘されてふと思ったのですが、プログラミングが好きな方々はプログラミングの知識を身につけるとき「勉強している」と思っているんでしょうか
回答中の「必要な物事を覚えること」は gentaro さんの仰る「自ら進んで勉強すること」ことと同じイメージです。
確かに最後の文は誤解を招きそうなので、編集しました。
指摘してくださり、ありがとうございます。
横槍失礼します。
入門するレベルの学ぶことだと「勉強」という表現が正しいかもしれないけど
既にそれをある程度修めた人が更なる何かを求めて学ぶことは「研究」って表現が正しいような
気はします。
例えば技術系の講演とか聞いた時、「今日は勉強になった」という感想はあっても「今日は研究になった」という表現はしないなぁ、と思うと別に「勉強」で良い気が。
「研究」を推してる訳では無いのですが、個人的には分けたい気はします。
どちらかというと「勉強」って受動的に使われる方が多い気がするので能動的な
表現を出来る何か良い言葉があれば良いんですけど･･･。
この回答の趣旨は「目的が漠然とした勉強はしないこと」で、言葉が勉強ではなく研究であったとしても趣旨自体は同じですね。
目的がある勉強であれば、響きは楽しくなさげですが、学習効率的にはまったく問題ないと思います。
確かにあくまで私の感覚の話になりますが、勉強よりは研究という言葉の方が楽しそうです。
（「探究」 ← かっこいい感じ！）
そう、私（我々？）は探究者です！厨二病的で素晴らしいですね。
言葉の表現について色々議論してくださったので後でこっそり回答直してみます。
探究は「ある物事の意義・本質などを探って明らかにしようとする事」らしいので
「技術の探求者」って書くと余計に厨二病的な響きがしますね。
言葉遊びの世界だけど、個人的な経験では学生時代も得意科目の勉強は苦に思った事がなく、ゲームの攻略と同じ感覚でテストに挑んでハイスコア目指したり模試でランク上げをしたりという感じだったんで、「勉強」って言葉に抵抗がないんですよね。
苦手科目は苦痛でしかなかったから「悪いイメージの勉強」はもちろんありましたけど、エンジニアにとっての技術なんて「得意科目の勉強」じゃない事がほぼありえない（苦手ならやめといと方が良い）し。
（真面目に修正していたら勉強のくだりがほとんど消えてしまいました）
0
学んだ知識が定着して、自分で好きに使えることになります。
う～ん、目的が漠然としているのが良くない気がします。他の方のアドバイスと重複しますが、なにか作ったり、実践するのが一番の近道だと思います。手を動かしてみて分からないことがあれば書籍なりWebサイトで調べたりするのが一番定着すると思います。
学生さんなのであればインターンに参加してみるのも良いかもしれません。もしくはプログラミング関係のアルバイトを初めて見るとか。
「実践する」というのを念頭に頑張ってみてください。
投稿2021/07/25 01:28
総合スコア55
0
これを参考にしてください。
上記ページにも書いたように、『プログラミングは単に、人間が手作業でやっていることをシミュレーションしているだけ』です。
歴史を考えるとわかるはずです。
という事は、『実際に仕様書を書く』とか『実際にソフトを作る』とかのような実践が必要なはずです。
というか、そもそもそういう問題( 暗号解読とか ) をやるために、機械にさせるために命令するのがプログラミングですから。
なので入門書や技術書だけを読んだだけでは意味がありません。
実際に仕様書を作ったり、プログラムを組んだりとかしてやってみないと意味を成しません。
おそらく質問者さんのやっていることは、
『逆上がりができる本』とかみたいなのを読んで習得した気になっているだけじゃないかなと。
普通、相当な運動センス(一目見ただけでオリンピック選手のトリッキーなプレイを再現できるとかのようあ) が無いと無理なはずです。
普通の人や私みたいな凡人以下だと、実際に鉄棒を使ってコツをつかむとかみたいなことをしないと覚えられません。
私の場合は、とりあえず基礎部分をサラッとやって、『どういう概念があるか』とかを理解する。
これをしないとそもそもどんな道具があるかさえわからないからです。
かといって入門書とかを何周もする必要はありません。
名称や概念を理解して、『調べれば使える』程度でいいです。
そして実際に設計からやっていく。
仕様書の書き方に関する技術書であれば、ざっと読んで実際に作ってみるとかですかね。
実践あるのみ。
投稿2021/07/15 08:10
総合スコア4962
0
知識を定着して使いこなせるようにするには実践していくのが一番ですよ。
インターンやアルバイトで働くか、自分でソフトウェアを書いて試していくのがオススメです。
投稿2021/07/15 02:41
総合スコア874
あなたの回答
tips
プレビュー
