技術書と上手く付き合う4つの方法

記事から移動しました。

はじめに
技術書って魅力的なものが多く、読むスピードより買うスピードの方が速くなって、ついつい積読しがちですよね。(私だけ?)
書店に入る度に見たことのない技術書が溢れていて、変化のスピードに驚いてしまいます。
しかしながら、すべての本を読んでいる時間はないわけで、、
そんな魔の技術書たちとうまく付き合う方法が分かってきたので、記事にしようと思いました。
業務に関係する本が最優先
ジャンルが豊富すぎて、どれも興味深く魅力的に見える技術書ですが、自分の業務に関係する技術書を読むことが一番大切だと思います。
結局のところ、自分の担当業務で使っている技術に最も多くの時間を使うことになるわけで、深く考える機会も必然と増えますよね。
そのような状態において、関係する技術書を読むことは良いインプットのお供となるはずです。
技術書で学んだことをその場でアウトプットすることができ、効率よく技術に関する知見を身につけることができるなと感じます。
やっぱり、どんなことでも「今やっていることに本気で取り組む」のが一番自分の糧になるということですね。
理解できなくても良い
書いてあることがちんぷんかんぷんで、まったく内容を理解できないこともあると思いますが、大丈夫です。
それは、まだその技術書を読むべきタイミングではないだけです。
技術書には最適な読むタイミングがあり、「自分の技術レベル+1のことを教えてくれるとき」と「自分が持つ経験が技術書によって言語化され整理されるとき」が最適なタイミングだと思います。
つまり、技術書を読んで理解できるだけの技術が身についている必要があるんですよね。
内容を読んでも何を言っているのか理解できないときは、自分の技術レベル+15くらいの、レベルが離れすぎている内容に挑戦してるときだと思います。
そんな状態で頑張って読んでも頭には入らないし、身にならないし、何より苦痛で続きません。
そんな時は軽く読み流し、こんな内容があるんだなぁというインデックスを張るにとどめて、そっと本を閉じましょう。
必ず、その本を読むべき時がやってきます。そのときに再び読み返して、「分かる…分かるぞ!」と自分の成長を噛み締めましょう。
不満がチャンス。心に正直に
業務やプライベート開発において不満に思っていることがあれば、それを解決するための技術書を読むチャンスです。
例えば
- 「自分のコードが汚くて終わっている!」
→ クラス設計やリファクタに関する本を読むチャンス - 「開発プロセスが気に食わない!」
→ 組織開発や開発プロセスに関する本を読むチャンス
といった感じです。
不満を解決したい!というモチベーションに基づいていますし、学んだ内容をすぐに実践することができるので、効率よく学べます。
アウトプットが大切
これまでも「アウトプット」という言葉が出てきていますが、やはりアウトプットは大切です。
技術書を目で追うだけでは、読んだ気になっているものの実はあまり頭に入っていなかったりするものです。どんな形でも良いので、アウトプットしていきましょう。
- 章ごとに紙に要約を書く
- 実践する(コードを書くなど)
- ZennやQiitaの記事を書く
- ツイートする
- 職場の同僚に軽く話す
何でもありです。
読んだものを噛み砕き、自分の言葉として使うことで、ようやく自身の血肉とすることができます。
自分程度がZennに書くなんて恐れ多い…と思わず、拙くてもいいのでアウトプットをしましょう。
まとめ
技術書とうまく付き合うための自分なりの方法です。
技術書を自己啓発みたいに「なんとなくわかった→1週間後には忘れてる」な状態にしないために、
- 業務関係の本を最優先に読む
- 読むべきタイミングがあることを理解する
- 不満に思っている内容の本を読む
- アウトプットする
の4つのことを意識すると、うまく行くんじゃないかなと思います。