技術書を読むのは好きなんだけど、内容が頭に入らない、、。せっかく読むからには、読んだ知識を血肉と化して自分のスキル向上に生かしたいな。どんな風に読めば効率よくスキルアップにつながるんだろう？
こういった疑問に答えます。
この記事を書いているぼくはエンジニア歴１年、未経験から従業員300名以上の自社開発企業に転職し、Railsエンジニアとして働いています。
この1年、死に物狂いで勉強してきましたし、技術書もたくさん読んできました。
ただ読むだけでなく、いろんな読み方を試してきたと自負しています。
受験勉強で培った勉強方法を技術書のインプットに応用させたりもしました。
この記事では、自分の経験をもとに、スキルアップにつなげるための技術書の読み方を5つ紹介していきます。
最後まで読めば、あなたに合った技術書の読み方が1つくらいは見つかるかなと思います。
記事の信頼性
- 独学で未経験から従業員300名以上の自社開発企業へ転職しました。
- 実務ではVue.jsとRailsを毎日書いています。
- 初心者や駆け出しエンジニアがつまづくポイントも身をもってよく理解しています。
技術書の読み方5選
- 写経
- 7回読み
- フラッシュカード作り
- Xで読書実況
- アクションプランを考える
順番に解説していきます。
①写経
写経は新しい言語やフレームワークを技術書から学ぶ際におすすめです。
手を動かすボリュームが稼げるので、自然と理解が進みます。
ぼくの場合、『プロを目指す人のためのRuby入門（通称チェリー本）』を読むときに写経を試しました。
チェリー本を読んだのは今の会社の内定をもらってからです。
未経験からRailsの開発に携わるには手を動かす経験が圧倒的に不足していたので、身体に馴染ませる意味も込めて写経していました。
「写経って効率悪いんじゃない？」という意見もあるかと思いますし、実際効率は悪いです。
なので、何でもかんでも写経すべきではないですが、効率が悪くても着実な理解を優先したい場合や、「不慣れだからとりあえず手に馴染ませたい」という場合に適切かなと思います。
具体的なやり方
ぼくは以下のXの投稿を参考に、写経を進めていました。
技術書の「写経」の方法。 1.ローカルで使える SCM を用意 2.「ほんたった」などで対象の本を固定 3.ひたすらサンプルコードを写して実行 4.実行するたびにコミット(コミットログにページ番号を含める) 5.疑問点があったらコミットログや本に書き込む 6.章ごとにタグを打つ— Takuto Wada (@t_wada) February 12, 2010
gitで管理し毎日ひたすらコミットを積んでいく感じです。
どうせやるなら、どんなにカンタンな構文であっても飛ばさずに進めるのがおすすめです。
②7回読み
大学受験時代に『東大首席弁護士が教える超速「7回読み」勉強法』という本を読んだんですが、それを技術書に応用させて試しました。
7回読みはその名の通り、同じ書籍を7回読むだけの方法です。
1～3回目で全体像を感じ、4～5回目でキーワードを意識して要旨をつかみ、6～7回目で内容を把握するという流れで1冊の本を読むのが「7回読み勉強法」です。
東大首席弁護士が教える超速「7回読み」勉強法
全体像をざっと網羅的に把握したいケースでは有効だと感じました。
ぼくの場合、『SQLアンチパターン』という書籍を読む時にこの勉強方法を試したんですが、今でもアンチパターンにどのようなものがあったか、概要レベルではざっくり覚えています。
逆に、「本を一切見なくても自分の言葉で説明できるようになりたい」という場合には不向きかもしれません。
過去に、ネットワークの知識がゼロだった状況で『マスタリングTCP/IP』の7回読みを試したんですが、どんな単語が登場したかは把握できたものの、具体的な内容、たとえば「OSI参照モデルの各層の役割は何か？」といった質問に何も見ずに答えられる状態にはなりませんでした。
とりあえず頭の中に強力なインデックスを作りたい場合に採用すべき勉強法だと思います。
具体的なやり方
基本的には↑のとおりなんですが、ぼくは1週間で1冊を7回読む、というスパンで実践していました。
月曜日が1回目、火曜日が2回目、といった具合です。
この方法だと短期間で進められる分、いくら1回あたりはあっさり読むとはいえ、1日で1冊を読むとなると結構ボリュームが大きかったです。
スケジュールとの相談ではありますが、『東大首席弁護士が教える超速「7回読み」勉強法』でも短期集中が推奨されていたので、短い期間で7回くり返すのがよいでしょう。
③フラッシュカード作り
フラッシュカードを作りながら技術書を読み進める方法です。
『プログラマー脳 ～優れたプログラマーになるための認知科学に基づくアプローチ』という書籍の中でフラッシュカードによる学習が推奨されていたため、実践してみました。
この方法が最もコスパの良い勉強方法かなと思います。
問題と解答を自分の言葉でまとめながら読み進めるので言語化のプロセスが求められますし、作り終わったフラッシュカードでいつでも気軽に復習できるので記憶の定着度も高いです。
『マスタリングTCP/IP』の内容は他人に説明できるレベルで理解したかったので、フラッシュカードを作りながら読んでいました。
「メモを取りながら読むのと何が違うの？」と思うかもしれません。
メモだと印象に残った文章を丸写ししがちになってしまうのに対し、フラッシュカードだとQ&A形式になるので、「自分で問いを立てて自分で解答を考える」という点で良かったです。
具体的なやり方
ぼくはWordHolicというスマホアプリを使ってフラッシュカードを作りながら読んでいます。
このアプリが特に優れているかはわからないので、お好きなアプリでやってみるのが良いと思います。
④Xで実況中継
これは「勉強法の勉強会」イベントの「技術書を集中して読むために新たに始めた方法が自分にクリティカルヒットした話（44:00〜）」というLTで紹介されていました。
読んでいる内容をXで実況中継のようにつぶやきながら読む方法です。
技術書を読みながら、「へ〜」と思ったこと・よくわからなかったこと・疑問・感想など、頭に浮かんだことをそのままXに投稿していくことで、通常よりも高い集中力で読書ができます。
気軽にできるので毎日確実に質の高いインプットの時間を確保したい人におすすめです。
ぼくは『良いコード・悪いコードで学ぶ設計入門』という書籍を読む際にこの方法を試しましたが、たしかにかなり集中できました。
また過去の投稿を見返せるので、復習の観点でも優れています。
一方で投稿の量が多くなるのでタイムライン荒らしになってしまう点に注意してください。
読書用のアカウントを作ってそこでやるのが良さそうです。
具体的なやり方
ぼくはLTで紹介されているように毎朝30分つづけていました。
ふつうの読書よりも集中できるので、2週間かからずに1冊読み終えた気がします。
ただし、ぼくは元々SNSをやっておらず、Xでの投稿がそこまで身近な存在ではないため、長続きませんでした。
⑤アクションプランを考える
「明日からすぐにできそうなこと（＝アクションプラン）」を探しながら読む、という読み方です。
マコなり社長のYouTubeにアップされていた「ただの読書」は時間の無駄。100人に1人の人材になる読書法。という動画の内容を自分なりに応用させました。
この動画では「価値ある読書 = その日から行動が変わること」と定義されています。
これを技術書のインプットに当てはめて「価値あるインプット = 明日からすぐに実践できること」と考えたんです。
この読み方はかなり効果的でした。
実践できそうなことを探しながら読むため、読書のスピードアップにもつながりますし、インプットした知識をすぐに使えるため、即効性のある方法です。
自分のやり方
ぼくはこのブログで読んだ本の感想や印象に残った話をメモしているんですが、そこでアクションプランも設定してみるようにしました。
たとえば↓の感じです。
「ブログだとハードルが高い」という人は、技術書を読んだら巻末にアクションプランをメモしておくだけで十分です。
とにかく「明日からできそうなことを探そう」と思いながら読むと目的意識が生まれるため、インプットの質もスピードも向上するはずです。
技術書の読み方で本質的に大切なこと
実際に自分で試した中で効果のあった技術書の読み方を5つ紹介しました。
この経験を抽象化し、技術書を読むときに大切なことを考えてみると「反復」と「言語化」なのかなと思います。
↑で紹介した読み方はいずれも、「反復」や「言語化」のプロセスを含んでいます。
この2つのプロセスを日々のインプットに組み込むことで、技術書から得た知識を日々の業務で使いこなし、エンジニアとしてのスキルアップに直結させられるようになるでしょう。
おわりに
この記事ではぼくの体験をもとに技術書の読み方を5つ紹介しました。
- 写経
- 7回読み
- フラッシュカード作り
- Xで読書実況
- アクションプランを考える
技術書を読むときはぜひこの5つを試すなり、「反復」と「言語化」のプロセスを組み込むようにしてみてほしいです。
今まで以上に効率の良いスキルアップが可能になるはずです。
コメント