POLプロダクト Advent Calendar 2020 の12日目担当、プロダクト部でエンジニア／エンジニア広報をしている @sho-kanamaru です！
エンジニア広報するにあたってTwitter運用し始めました！こちらでございます。
POLのこと、技術に関することをどんどん発信していくのでぜひぜひフォローお願いします！
11日目担当のモンティー @kohei-shinden からバトンを受けました。Neo4jの記事面白かったですね！
今回はタイトルの通り、流行りまくっていた鬼滅の刃ではなく技術書を読んできた半年間のお話をしたいと思います。
6月から11月まで週1冊技術書を読んできたので、読んだ本の紹介やおすすめ本、インプットの極意を共有したいと思います！
ちなみに鬼滅の刃では義勇さんが好きです。拾壱ノ型 凪がかっこよすぎます（読んでるやん）
背景
株式会社POLではOKRを用いて目標管理をしているのですが、全社・部署ごとだけでなく、メンバーも個人OKRを設定して個人の成長にもコミットしています。個人OKRは業務に紐づくものを置いている人もいれば、全く紐づかないものを置いている人もいます。
ちなみに、目標設定する月末に退職が決まっていたメンバーの個人OKRはこちら
退職直前にも関わらず個人OKRを設定する姿勢が素晴らしいなと思いました。笑
というのはさておき。
僕の個人OKRの1つが
「毎週1冊技術書を読んで、読んだ内容をプロダクトチームにてアウトプットする」
というものでした。
今まであまり技術書を読んでこなかった僕が半年間インプットをしてみて感じたことやおすすめの技術書を紹介できたらなと思います！
読んだ本
6月から11月の半年間で読んだ本を紹介していきたいと思います。
たまーに技術書じゃないやつも混ざっていますが気にしないでください。笑
6月
7月
体調不良により1週間分読めず。。
8月
- 関数型プログラミングの基礎 JavaScriptを使って学ぶ
- 超速！ Webページ速度改善ガイド ── 使いやすさは「速さ」から始まる
- カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで
- 3分間HTTP&メールプロトコル基礎講座
9月
10月
- わかる！ドメイン駆動設計 ～もちこちゃんの大冒険～
- The DevOps ハンドブック 理論・原則・実践のすべて
- SRE サイトリライアビリティエンジニアリング
- シン・ニホン AI×データ時代における日本の再生と人材育成
11月
おすすめ技術書
上記の中から特に読んで良かったと思うものを簡単に紹介していきます。
ちなみに僕はエンジニア歴（実務経験歴）が約2年（バックエンド1年、フロントエンド1年）で、今まではほとんど技術書を読んだことがなく、OJTで勉強してきました。
似たような経歴だったり、今まで技術書で体系的に勉強したことがない方はぜひ参考にしてください！
オブジェクト指向設計実践ガイド
- サンプルコードがrubyなので誰でも理解しやすい
- 難しすぎないので初めて設計について勉強する人にもおすすめ
- デザインパターンの勉強もできる
達人プログラマー 職人から名匠への道
- 開発以外のこともたくさん学べる
- 心得的な要素が多く、モチベーション上げたい・危機感持ちたい人におすすめ
- それぞれの章にTipsがありネクストに繋げやすい
SRE サイトリライアビリティエンジニアリング
- DevOpsの知識0でも読める
- 情報量が多く網羅的に勉強できるし、かなり細分化されてるので部分的にも勉強できる
- Googleの実例が知れる
インプットの極意
必ずしも全部読む必要はない
何も考えずに全部読んでいる人は、本を読むことが目的になってしまっていると思います。
本を読むことはあくまで手段なので、手段が目的化しないように注意しましょう。
なので読む前にまず目次を見て、自分が興味ある部分、知識が足りない部分、勉強したいと思う部分だけを読むのが良いと思います。
「せっかく買ったのにもったいない！」と言う方、自分が興味のない部分を読んだって1週間後には間違いなく忘れてます。人間は忘れる生き物です。
時間は有限なのでしっかり取捨選択して読むようにしましょう。
もう1つ細かい読み方としては、具体例も読む必要がないことが多いです。
基本的には抽象→具体の順で書かれていることが多くて、抽象的な概念だと理解しづらい部分があるから具体例を用いてわかりやすく書かれています。
なので僕は抽象の部分で理解ができたら具体例は飛ばしちゃってます。
具体から読むって読み方もあるかもしれませんが、自分は抽象概念でしっかり理解するべきかなと思います。抽象概念はさまざまなことに応用できるので。
暗記せずに理解する
暗記するに越したことはないかもしれませんが、上記の通り1度読んだとしても1週間後にはほとんど忘れています。なので暗記する必要は一切ないと思います。
しっかり理解をしておけば、何か同じようなことに直面したときに、「あの本で同じようなこと言ってたな」と思い出すことができます。
内容を覚えてなくても、この本に書いてあったということさえ覚えておけばいつでも辞書的に調べられるからです。
自分の頭の中のデータベースにインデックスを貼っておくイメージですかね。0から調べるのは大変でもその記憶されあればパッと調べることができます。
本の選び方に注意する
大量に本がある中でどの本を読むべきかは非常に重要です。
本を選ぶうえで重要な観点は2つあるかなと。
1. 評判の良い本を選ぶ
これは当たり前かもしれませんがやっぱり大事です。
たくさんの人がいろいろな形で本の評価をしているので、必ず参考にしましょう。
amazonでも見れるし、Qiitaにまとまった記事もたくさんあります。
ただネットに転がっている情報をそのまま鵜呑みにするのは良くないので、**「一番大切なのは信頼できるソースの友人を見つけること」**です。
美味しいご飯屋さんを見つけるときと同じです。食べログで評価が高いのも大事ですが、信頼できる友人がおすすめしてくれたお店だったら安心して行けますよね。
2. 本のネットワーク構造を理解する
本には本を生み出した別の本があります。そして、その本を生み出したまた別の本もあり、それから同時に生み出された兄弟の本もあります。
これらの本たちがどういうネットワーク構造になっているかを理解できれば、今の自分に合った最適な本を見つけることができます。
ただこれは難易度が高く、ネットワーク構造を理解するのにめちゃくちゃ時間がかかることもあるので、それぞれの本の関係性を意識するくらいで最初はいいかなと思います。
1つでもいいから実行に移す
「暗記するのではなく理解する」という話をしましたが、理解するだけでもまだ足りません。
理解したものをアウトプットする必要があります。それはなぜか。
1. 知識として定着させるため
その場で理解をしただけではいずれ忘れてしまいます。
インプットしたものをしっかりアウトプットすることで定着していきます。
理解するために本を読んでいるのはなく、何かに活かすために本を読んでいると思います。
本を読む前に「何のためにこの本を読むのか？」を明文化することでアプトプットに繋がりやすくなるかもしれないですね。
2. 知ってると使えるは違うため
理解できたから使える訳ではありません。
自動車の運転もいくら座学で完璧にルールや仕組みを理解したとしても運転がいきなりできる訳ではないのと同じです。それにほとんどの場合完璧になんて理解できていません。
でもそれは実践してみて初めてわかることなので、理解で止めてしまうのはもったいないです。
さらに、現在さまざまな規模、体制、働き方のチームがある中で、本に書いてあったことをそのまま使える場合はほとんどありません。本に書いてあったことをベースに、いかに自分たちのチームに最適化し、試行錯誤していくかが重要になります。
継続させる仕組みを作る
読書ってやろうと思ってもなかなか続かないですよね。
いくら頑張ろうと思っていてもその熱はだんだんと下がっていってしまうので、仕組み作りが非常に重要です。
僕の場合はチームに宣言をすることで、継続せざるを得ない環境を作りました。
その他にもメンバーと読書の時間を作ったり、読書会に申し込んでしまうなどなど、いろいろな仕組み化があると思うので、継続が苦手な方はぜひ参考にしてください！
さいごに
今回はおすすめ技術本とインプットの極意を紹介しました。
体系的に勉強してみて点と点が繋がる瞬間があったり、背景的なことが知れて今まで以上にプログラミングが楽しくなりました！
インプットが苦手な方もまずは1節、1章からでも始めてみてはいかがでしょうか。
ぜひぜひ皆さんのおすすめ本も教えてください！
明日13日目は、たっちゃんさん（@tatsunori_t）です！お楽しみに！