ITエンジニアの読書について。本の選び方・読み方が気になって聞いてみました
同僚やクラスメートがどんな本を読んでいるのか気になることはありませんか？社内で読書に励むメンバーの様子から、エンジニアがどんな本に親しんでいるのか気になりました。どんな本を・なぜ・どのように読むのか、役に立った本や、おすすめの本も聞いてみました。
本がたくさんありすぎて
自分の仕事の質をアップデートしたい、新しいこと・知らないことを自分のモノにしたいときに、できることとして本を探して読んでみようと思うことがあります。また、先輩や上司から本を読んでみるように勧められることもあります。
そんなこんなで、いざ書店にいくとたくさんの本を目にします。事前に調べるために検索すると、たくさんの書評が出てきます。それで、私にはいつも本を読む前の探す段階から悩みのタネがあります。
「どう探すのが一番いいんだろう？」
「どの本を読めばいいんだろう？」
本を読むメンバーに聞いてみたくなりました
23年8月ごろ、今の業務をしていくのに少し違った視点はないだろうかと感じるようになって本を探し始めた時に「そもそも、会社のメンバーはどんな本を読んでいて、その本をどうやって見つけているんだろう」と思うようになりました。
社内のSlackでは仕事に役立つ情報を交換するために用意されたチャンネル#devtipsがあり、頻繁に利用されています。#devtipsを調べてみると、ここ数年はQiitaやZennなどのWeb記事の引用以外に、メンバーが読んだ本や、読んでみようと思う本についての投稿が増えていました。技術本に加えて、仕事のやり方、マネージメント、マーケティングなど幅広い本が紹介されています。
Web記事やSNSから必要な情報にすぐアクセスできる今、なぜ本を読むんでしょうか。また、一般書は没入して読めても、技術書は同じようには読めないと感じることがあります。どんな読み方をしているんでしょうか。
そのようなわけで、読書するメンバー5人にお願いして、読書についてそれぞれのストーリーを聞いてみることにしました。読書するメンバーの背景に合わせてプラスαの質問もしてみました。
なぜ読むのか
どのように選んでいるのか
どのように読んでいるのか
それぞれの本紹介（おすすめの本、今または過去に読んでよかった本など）
技術書だけでなく一般の書籍の読書についても触れてくれたメンバーもいます。
ぜひ続けてご覧ください。
読書から整理整頓を学ぶ-人と技術の関わりに興味あり
小さい頃から本を読むのが好きで、小学生の頃は図書館に通って本を読んでいました。
当時読んでいた本でパッと出てくるのは「ズッコケ三人組」とかです。
なぜ本を読むのか教えてください。
どんな本を選ぶかにも通じることですが、本を通して人や人の暮らしを知ることができるからです。自分にとって知らない世界を知ることができます。自分にはない発想に気づかされたり、発想を得られることにつながると感じています。苦手な分野から逃げたくないことも本を読む動機の1つです。
どのように本を選んでいるのか教えてください。
自分が読みたい内容に沿って探します。自分に足りないとか、これから鍛えたい分野、苦手な分野から選ぶことが多いです。Kindleで探しますが、書店で探すこともあります。選ぶときは書き出しを読んだ時の印象で決めます。表紙に惹かれるかどうかもポイントが高いです。レビューをチェックすることはありますが、選ぶかどうかの条件にはなっていません。
読む本の傾向として「人」が中心になっていると思います。自分が経験していない人や人の暮らし、技術と人の関わりなどです。SFチックに描かれる人と技術も好きなジャンルです。
どのように本を読んでいるのかを教えてください。
技術書、一般書で読む時に違いはありますか？
本の先頭から読んでいます。その読み方に慣れていますし、文脈や考えの流れを意識して読みたいです。筆者もそれを期待しているのではと思います。技術書の場合、既に知っていることもあるのでその場合は考え方の部分のみをサラっと読んでいます。
読み方が違うように見えて、実際には似ているところがあると思います。一般書では頭の中に登場人物や場面が出てきてセリフが聞こえてくるように読んでいます。技術書の場合は、プレゼンターや話し手を想像しています。そこが似ていると思うところです。
読書してきて感じていることを教えてください。
本を読んできて、何をするにしても、整理整頓することが基本だと改めて感じるようになりました。バラすこと、整理して積み上げることです。知っていること、知らないこと、できること、できないこと、これからしなければいけないこと、次にすることについて整理整頓が出来れば、正しく相手に質問することもできるようになります。それは仕事や他の事にも役立つことだと思います。
本紹介
4つの基本原則でデザインが説明されているため、デザイナーでなくても理解しやすいく、図解もあるので、イメージが湧きやすいです。4版になって日本語フォントについても説明が追加されたのも嬉しい点です。
元記者の方が書かれている漫画です。AIがもっと身近なものになった世界を描いています。いわゆるマザーコンピューター型AIが世界を緩やかに管理しているが、ディストピアではありません。
・人と同一の権利を持つヒューマノイドと産業用ロボットが明確に分けられていること、
・AIには人間を脅かさない程度の性能を発揮しないように制限をかけられていること、
・ヒューマノイドにも脳機能の低下による寿命が設定されていることなど、
現実味のある設定が興味深いです。人工的な知性を通して、人の価値観や人生観を俯瞰的に観察できる点が面白いと思います。
ITエンジニア本を読んでいると、大概の本で明言されている法則や中心的な考え方が見えてきますが、読み手や筆者の好みや流行によってブレが生じることがあると思います。管理会計という世界の中では、公式によって明確に定義された用語や考え方をほぼそのまま用いるところが新鮮でした。素人が初めて管理会計にふれて、こういう世界もあるんだなと理解するにはよいと思いました。
実際の事業者にインタビューする内容で、現場の生々しい声が聞けて良かったです。人によっては頭が痛くなるのかも…技術力と行動力のある人間は物事を動かすので強い（信頼関係も大事）ことが分かります。
目的にかなう読書に価値あり
本を読むのは昔から好きです。学生時代は毎月数冊の本を読んでいました。
紙の本を買わなくなってからはペースが落ちてきており、年数冊程度です。
なぜ本を読むのか教えてください。
仕事に関係して技術向上のために本を選ぶこともあります。主な目的は暇つぶしです。直面している問題に対処するための本でないと役に立たないと思っていますし、インターネットで調べる情報に比べると情報の鮮度が低いため読んでみても参考にならないことが多いためです。
どうやって読む本を選んでいるのか教えてください。
技術書の場合、ある程度知識がある内容のものを選び、記憶の整理と定着を狙って選びます。後は、本屋さんで平積みになっているものを見てから、Kindleで販売しているものを選びます。
学習に向けての場合は、その時にかかわっている案件に関連する技術分野の本を読みます。暇つぶしだとミステリー系をメインに読みます。
どのように本を読んでいるのかを教えてください。
技術書、一般書で読む時に違いはありますか？
一般書の場合は、最初から最後まで読みますが、技術書の場合は、目次を見て必要な箇所だけを読みます。本の内容によりますが、序章とまとめを読み、後は流し読みすることもあります。
読書することと、
本以外のインプットとの切り分けについて感じていることを教えてください。
技術書の場合、本によっては情報が古くて役に立たなくなっていることが多くあります。特にAWSやAzureなどサービスを利用する前提のものは公式ウェブサイトを読む方が参考になります。そのため、最近ではWebサイトからの情報が、基本的な技術情報の入手先になっています。また講座のオンラインビデオなども参考にしています。
本は整理された情報ではあるものの、著者の思想を学んだり興味を高めたり、集中して情報に触れるためのツールになっています。そのためIT業界縛りかもしれませんが、本は著者への寄付もしくは趣味の領域と感じています。
本紹介
命名に関するこだわりを持つ必要性を理解するのに役立ちました。
ポッドキャストを活用して本探し-読んだことをよく考えることが大切
子供の頃はいろんな情報を取り入れるのが好きで本を読んでいたのではと思います。
技術本は10代の頃に、Cマガジン、ベーシックマガジンなど、
いろんな実装について書いている本というのが面白くて結構読んでいました。
20代、30代に関しては、ほとんど趣味で本を読んでいないという気がします。
なぜ本を読むのか教えてください。
自分の独自理論で一人でプログラムを書いてると問題ないですが、チーム開発になると皆が自分と同じようにできるわけではないことや、自分のやってきたことよりも良いコードを書いてる人がいるのにも気づくことがあります。自己理論でやってきて限界を感じたり、問題に当たることもあるので、本による体系的な知識を学んで、プログラミングに生かしていきたいという動機が出てきています。それで、ここ数年はかなり本を読んでいます。チームでやることが増えてきている会社の状況そのままの通りです。
どうやって読む本を選んでいるのか教えてください。
会社もしくは自分の必要な技術に関して戦略的に選ぶのと、あとは他の人のＸ（ツイッター）とかを見て書評が面白かった本で、面白そうだから読むというのもあります。特にプログラミング関係で読む本に関しては、自分もしくは会社に必要だと思われる技術に関して評判の良い本を読んでいます。ポッドキャストのパーソナリティーがすすめている本は候補に入ってきます。「この本が好きだ」という熱意を持って語っているのを聞いていると、読んでみようかなという気持ちになります。
自分や会社に必要な分野以外にも、好みで読む分野もあります。例えば最近好んで読んでいるのは、関数型プログラミングに関する本です。
どのように本を読んでいるのかを教えてください。
まず目次読みをして、パラパラめくって面白そうなところで止まってそこをしっかり読むことが多いです。それで本が気に入ったらはじめから全部読むパターンが多いです。
最近輪読会に参加するようになりました。そのための読み方がとても良いと感じています。輪読会では、難しい本の1章もしくは2章がピックアップされて、それを2週間に1回話し合います。1回に読む範囲はそれほど多くなく、範囲の内容について語り合う前提でしっかり読んでコメントを書き込んで共有するので、結果非常に残ると感じています。
読書することと、
本以外のインプットとの切り分けについて感じていることを教えてください。
大事なのは読んだことを考えることだと思います。そのことについて考えて、役に立つこと、読んだことからできるかもしれないことを考える時間を作ると、読んだものが実になっていっていくと感じます。自分にとっての長期的な利益、本にある失敗例から学ぶことを考えて読んでいくようになってから、読むのが面白くなってきたと感じています。
長く役に立つ情報は、ポッドキャストやパーソナリティが勧めてくれた本から得られることが多いです。技術的なことについては、今話題になっている中に大切なものがあります。その話題を見つけるには、今でいうとまだX（ツイッター）が見つけやすいと思います。リストを活用してアップデートして、関心のある項目について一番面白い情報を言う人たちを100人ぐらいピックアップできると、パッと見たときに、「これは面白い！」という情報が得られるようになります。
しっかり読む情報と、手早く最新の情報を得るのは両方大事なことだと思います。
本紹介
私たちの会社で主にC#が使われているということも理由としてありますが、この本は私たちのC#のバックエンドにおける単体テストに関して具体的な説明と理由が両方クリアに述べられていたので、腑に落ちました。またテストを書くことを目的とするのではなく、退行（リグレッション）を防ぐことやリファクタリング耐性などもっと重要なソフトウェア開発の目的に関してもわかりやすく説明されていました。C#であるため、具体的に使えるコードもわかりやすかったです。C#を使わないプロジェクトもそうですが、使うプロジェクトに関わる方には特におすすめと思います。
キャリア前半では体系的な知識を説明する本を読むのが苦手であまり読んでこなかったのですが、学生の時にこの3つの月刊誌はよく購入していました。サンプルコードが載っていてそれを写せば動くものができ、調整をそこからできたというのと、Cに関しても新しい技術や考え方が少しずつ説明されるているので、作るときのアイディアになりました。仕事を始めてからはWeb+DB Pressで、新しい技術の背景と概要を知り、採用する技術の方向などの道しるべとすることができました。
仕事をより良く果たすための読書-読書メモを活用
子供のころは本ばかり読んでいました。
宇宙とか人体とかの図鑑が特に好きでした。
好きなウイルスはバクテリオファージです。
なぜ本を読むのか教えてください。
与えられている仕事をより良く果たすために、そして流行りの本は流行っている理由が気になるので読むことがあります。仕事と関係ないですが、流行っていたので「すばらしい人体」という本を読みました。いまでも人体が好きなようです。
どうやって読む本を選んでいるのか教えてください。
Amazonのレビュー、有名な人の書評はとても参考にしています。また、社内で勧められた本は議論の共通の土台にもなりますしマストで読むようにしています。
自分の役割に合わせた本を中心に、一般書はたまに読む程度です。「エンジニアのマネジメント」という今の立場にピンポイントなジャンルの本がたくさんあるのでそういった本が中心です。あとはシステムのインフラに関心があるので「監視」「運用設計」とかも読みます。
どのように本を読んでいるのかを教えてください。
本の種類によりますが、技術書であれば各章の１ページ目を読んで関心が無ければちょっと雑に読む、関心があればじっくり読むという読み方をしています。関心が無い部分は、関心が無いなと感じながらじっくり読んでも頭に入ってこないので、何が書いてあるかをなんとなく把握するだけにしています。
あとはNotionに読書メモを書くようにしています。自分に役立つと思った点や、こういう時はここを見返すというようなことを書いています。
読書することと、
本以外のインプットとの切り分けについて感じていることを教えてください。
情報収集は私たちの文化的な活動に必要なインプットだと思います。十分なインプットが無ければ十分なアウトプットはできません。読書はインプットの量、質を担保するものだと思います。もちろん読んでみて時間の無駄だったと感じるものもありますが、仕方ないと思います。読書は身近なものであるべきで、身近にできていてよかったと感じます。
ネットからも情報取得はできますが、やはり出版されている本の方が体系的な情報が比較的信頼できるレベルで得られると感じています。基本はネットから情報取得し、じっくり向き合いたいテーマは書籍から得るのが良いと感じています。
本紹介
プログラマ２年目くらいで読んだ本だったのですが、とても影響され、これを機にデザインパターンを使いたくてしょうがなくなり（それ自体は良し悪しあるものの）「同じ動作をするプログラムでもより良いコードで書きたい」という情熱を持てるようになったのが良かったと考えています。
プロジェクトマネージャとしての本をいくつか読みましたが、一番良い本でした。
良くも悪くも、アジャイル型というタイトルと内容があまり合っていないように思います。アジャイルかどうかに関わらず、プロジェクトマネージャとして行うべきこと、考えるべきことがしっかり網羅されており、たまに読み返したくなる本でした。
キャリアを支える読書-流行に左右されない良著探し
本は昔から読んできました。
なぜ本を読むのか教えてください。
仕事に必要なインプットを得るためです。特に「良著」を読むのがインプットとして一番の近道と考えています。
どうやって読む本を選んでいるのか教えてください。
「良著」であるかを重視しています。読む価値があるか、流行りを追っていないかなどです。そのうえで、Amazonのリコメンドや、オライリーの書籍は必ずチェックします。特に業界で定評のある方の本にも注目します。そうした方がその分野について一番説明できる方だからです。
エンジニアリング、マネージメント、クライアントに関わる業務に関する内容です。個人的な興味と言うよりは、必要なこと、最新のことを知るために常にチェックしています。
どのように本を読んでいるのかを教えてください。
まずは前書きを読みます。前書きを読むと、最初から読むか、途中から読むか、著者の意図が分かります。
読書することと、
本以外のインプットとの切り分けについて感じていることを教えてください。
自分で学ぶ必要がある環境にいたこともあり、自分のキャリアは読書によって築かれたと感じています。最近のビジネス系のマンガはとても良いと思います。特にドラッカーなど、マンガはよく編集されているため、ポイントが押さえられていると思います。疲れている時にも読みやすいと思います。
情報を断片的に得るのか、体系的に学ぶのかで切り分けています。
本紹介
かれこれ25年も前の本となってしまいましたが、今となっては懐かしい当時のDDJ（ドクター・ドブズ・ジャーナル）日本版の連載記事が単行本化されたこの本は、私のエンジニア人生において大きな影響を与えた1冊です。当時とても難解に感じられ自分には会得できないと考えていたオブジェクト指向が、この本の具体的で非常に明確な説明により「オブジェクト指向とはこういうことだったのか！」と初めて理解できた感動と興奮を今でも思い出します。現在2023年の時点では、OOPを学ぶための良書は色々と出そろっていますが、当時情報が少なかった国内の状況を考えると語り継がれるべき名著の一つと思います。
今でこそ定着した感のあるアジャイルムーブメントの走りとも言える、XP（エクストリーム・プログラミング）についてKent Beckが初めて書き記した本です。2000年に出版後すぐに出会い、興奮と強い共感をもって一気に読み切ったことを思い出します。4つの価値（コミュニケーション、シンプル、フィードバック、勇気）と導き出される基本原則は、当時から今に至まで私自身のエンジニアとしての信念やスタンスに強い影響を与えています。2023年現在なら、Kent Beckによる第2版が出ていますので、こちらがお勧めです。
今や絶版であり、かつあまり知られていない本のように思いますが、私のエンジニア人生において大きな影響を与えた1冊です。1999年当時、Visual Basic 6.0を使用して、複雑な要件が関係した業務アプリケーションの設計開発に携わっており、VBでも何とかオブジェクト指向で構築できないかと色々と悩み試行錯誤していた時に出会ったのがこの本でした。実際にこの本で説明されているアーキテクチャや開発手法を参考にした結果、プロジェクトも無事成功し、私の手から離れた後も役割を終えるまで10年近く運用され続けたシステムとなったと聞いています。2023年現在改めて見直してみても、この本で説明されているビジネスオブジェクトの分析、設計、VBによる実装の手法は、その後のドメイン駆動設計（DDD）にもよく通じる非常にしっかりと書かれた読み応えのある本となっています。
信頼できる情報がほしい-技術書は探すのも読むのも苦手
小さい頃からいろいろな本を読んでいました。
技術書を読んだのは、工業高校の実習レポートを書く時に読んだのが初めてです。
なぜ本を読むのか教えてください。
業務に関する知識が少ないので勉強のために読みます。また、自分の仕事のやり方をアップデートすること以外に、しっかりとした裏付けを得るために読んでいると思います。
どうやって読む本を選んでいるのか教えてください。
知りたい内容について調べて、Kindleで探します。購入して読んでみて正直なところ外れたかなと思うことも多々あります。社内で勧められる本はかなりの確率で自分に必要なことが得られると思っています。
最近はほとんど一般書は読んでいません。自分の業務に関わる技術の内容に加えて、今はマーケティング分野が興味深く読んでいるジャンルです。
どのように本を読んでいるのかを教えてください。
技術書、一般書で読む時に違いはありますか？
一般書の場合は没入できる感覚がある一方、技術書を読む時にはそれが無いので読みにくく感じます。
自分の知りたい内容を考えて、最初から読んで外堀を埋めるのが先か、ピンポイントで知りたい内容を読んで内堀を埋めるのが先かで、読み方を変えていると思います。
読書することと、
本以外のインプットとの切り分けについて感じていることを教えてください。
仕事上の決定や話すことの裏付けは客観的で裏付けのあるものが欲しいと思います。読書をすることで、しっかりとした裏付けが得られることが良いと思います。
技術の実践的な部分は、Webで調べたほうが有効と感じています。ですので、本からは概念や理論的な部分を体系的に知ることができれば良いかなと思います。最近社内でポッドキャストを活用している人がいるので、私も倣ってみようかと思っています。
本紹介
20代のころ、「業務」だったプログラミングがより身近になったきっかけの言語の本です。この本片手に業務をサポートする便利ツールを作っていました。
「チームジャーニー」「カイゼンジャーニー」と読んで、この本も読みました。仕事をよりよくするために取り組みたいことを後押ししてくれて、読み終わりに爽やかささえ感じます。読み返したくなる本です。
より良いコード、コメントなど、もう少し早く出会っておきたかった本です。こちらも読み返し必須の本です。
聞いてみて整理できたこと
メンバーそれぞれの読書についてのストーリーを聞いてみて、読書するモチベーションや探し方、読み方にも個性があることが分かりました。ビジネス系のマンガがおすすめというのも新鮮でした。
読んでみて時間の無駄だったと感じることもある、と教えてくれたメンバーがいました。同じような経験をしていることが分かり少し安心しました。このことから分かったのは、本選びに失敗したと思ったとしても、読書が身近であることのほうが大切ということでしょうか。
それでも、できることなら本選びは毎回当たりがいいと思います！
それで、今回「なぜ読むのか」「どのように選んで」「どのように読んでいるのか」を聞いてみて、特に仕事に関連して本を探すときのことを自分なりに少し整理できたので下記にまとめてみます。
■自分の知りたい情報について、実践的なことがすぐに必要か、体系的に学ぶ必要があるのか考えてみる
→自分の現在地を理解する。情報を本で得るのか、WebやSNSで探すのかに影響あり
■知りたい分野について定評のある人や、関心をもって発信している人を探してみる。発信している人の情報は分かりやすく言語化されている場合が多く、そのなかにおすすめ本が含まれていることもある
→本の探し方に影響がある
■読んだ後に考えたり思い出せるようする
→どんな読み方をしたとしても、内容を考えたりメモなどで言語化しておくと定着しやすい
整理できたことを意識するようにしたら、必要なときに信頼できる情報に達しやすくなるのではと考えています！
皆さんの読書はいかがでしょうか。もし機会がありましたら教えてください。
長い記事になりましたが、最後まで読んでくださりありがとうございました。
追記： 読書についてのストーリーを教えてくれたメンバーの皆さんありがとうございました！（それぞれの顔は似顔絵ではなくイメージです。ご承知おきください）
おまけ：社内で始まったBook Club（輪読会）
最近、社内では「Book Club」と題した輪読会が始まりました。事前に指定された範囲を読んで、感想を共有しておきます。当日は30分以内で参加者と感想を含めて話し合うスタイルです。
第一弾として選ばれた本は「読みやすいコードのガイドラインー持続可能なソフトウェア開発のために」です。
開発を始めたばかりのメンバーから、10年以上行っているメンバーまでわかりやすく、開発のための指針が載せられている本です。
約２週間に一度開催して1章ずつ読むことで、参加メンバーの負担にならないように進めることができ、書かれていることをベースに皆でディスカッションをする助けになっています。
予習復習しながら読めることと、他の人の考え方を聞くことでより内容を理解しやすいという利点があると思います。このBook Clubの取り組みを利用することで、技術書を読みにくいと感じることを克服できるようになる？かもしれません。
この記事が気に入ったらサポートをしてみませんか？