エンジニアの本の読み方
はい、どうもこんにちは佐藤です！
先日、後輩くんから聞かれました。
「なんの本がおすすめですか？」
エンジニアなら一度は聞いたことのある質問ですよね。私も昔さんざん聞きました。
で、私が返した答えはこれです。
「今持ってる本を読み返すことかな」
期待外れの回答だったと思います。新しい 1 冊を教えてもらえると思っていたでしょうから。
でも本気で言っています。エンジニアの本は、1 回読んで終わりにするのが一番もったいない。
その理由を書いていきますね！
エンジニアの本は、文系のビジネス書とは読み方が違う
まず前提の話をさせてください。
書店に行くと、ビジネス書の棚には「1 冊 10 分で読める」「要点だけ押さえる」みたいな読書術の本が並んでいます。速く読んで、要点を抜いて、次に行く。そういう読み方ですよね。
ビジネス書ならそれで正しいと思います。主張が 1 つあって、事例で補強されている構造なので、要点を抜けば役目は終わります。
でも、エンジニアの本は違います。
私たちがやっているのは情報工学です。数学や化学と同じ、科学なのですよ。
科学の本というのは、そもそも要点を抜いて終わりにできる作りをしていません。定義があって、その上に定理が乗って、さらにその上に応用が乗る。積み上がった構造そのものが中身なのです。
高校で数学の教科書を「要点だけ」読んだ人がどうなったか、みなさん覚えていますよね？
公式は暗記できるけれど、応用問題が解けない。あれと同じことが技術書でも起きます。
高校数学の教科書を読み返したら、全部つながっていた
私はもともと教員をやっていました。そのとき、高校数学の教科書を読み返すことになったのです。
自分が生徒として通ってきた内容ですよ。当然、知っているつもりでした。
その時の衝撃ときたら……。
何が衝撃だったかというと、全てがつながって見えたのです。
学生時代の私にとって、数学は単元の集まりでした。文字式の単元、展開の単元、確率の単元。テストの範囲で区切られた断片でしかなかったのですね。
ところが教える立場になって読み返すと、こう見えます。
中学の文字式から始まる。そこから式の計算に進み、展開ができるようになる。その展開が二項定理になり、二項分布につながる。そして二項分布は、確率統計の土台になっている。
一本の道だったのです。
もっと言うと、道は数学の外にも伸びていました。微分は、そのまま物理の力学の解き方になります。数学の単元だと思っていたものが、隣の教科の道具として立ち上がってくる。
学問は、**抽象化と具体化を繰り返しながら成長していきます。**具体的な計算から抽象的な概念が生まれ、その抽象概念がまた別の領域で具体的な道具になる。時には他の概念に飛んでいくこともあります。
同じ教科書なのに、読む側が変われば見えるものが変わる。これが再読の威力です。
技術書でも、まったく同じことが起きます。
リーダブルコードを読み返したら、名前が「距離」を表していた
具体的な話をしましょう。
先日、後輩くんとの雑談がリーダブルコードの話になりました。名前の付け方の本、として読んでいる人が多いですよね。私も最初はそう読みました。
でも、ある案件をやったあとに読み返したら、まったく違うものが見えてきたのです。
きっかけは、ユースケースのレビュー中のこんな会話でした。
後輩くん「ドメインサービス.findAll って、なんのドメインのデータを検索したいのか明確でわかりやすいですよねー」
そうですね。ドメインという名前空間で、何を対象にしているのかがわかりますから。
後輩くん「でも、リポジトリ層は SQL 直書きで、しかもメソッド名は同じ findAll なんだ？ find〇〇エンティティand〇〇エンティティ の方が丁寧なのでは？ メソッドに分けていないんだ？」
いい質問です。ここが面白いところで。
それは、オブジェクト同士の距離があるからだよ。
違うドメイン同士は離れています。だからメソッドを分けて、混ざらないようにしているのですね。もしここで 1 本の SQL でまとめて引いてきてしまったらどうなるでしょうか。大きな案件になるほど、メンテが難しくなります。
逆に、あるドメイン同士が 1 本の SQL でつながっているなら、それは距離が近いという宣言なのです。正規化しているとはいえ、こっちのテーブルに修正が入ったら、ほぼあっちにも修正が入るでしょう？
つまり、どのくらいモデルが離れているかで、名前の付け方も変わってくるわけです。
もう一度リーダブルコードを開いてみてください。名前の話は、名前だけの話ではありません。
- 名前が責務の分離を表している
- 名前が契約の有無を表している
- 名前がシステム間の距離すら表している
初読のときの私は、「わかりやすい名前を付けましょう」という本として読んでいました。実践を挟んで読み返したら、アーキテクチャの本になっていたのです。
本が変わったわけではありません。変わったのは私の方でした。
実践と理論を往復すると、行間が読めるようになる
なぜ再読でここまで変わるのでしょうか。
答えは単純で、1 回目には行間が読めていないからです。
技術書は、紙面の都合で書かれていないことが山ほどあります。著者が「当然の前提」として飛ばした部分、経験がないと意味がわからない一文、そういうものが行間に詰まっています。
初読の自分には、その行間が空白に見えます。空白なので、読み飛ばしたことにすら気づきません。
そこに実践が入るとどうなるか。案件で痛い目を見て、設計で悩んで、レビューで詰まる。その経験を持ってページに戻ると、空白だったところに文字が浮かんできます。「あ、これあのときのやつだ」と。
だから順番はこうです。
読む → 実践する → 読み返す → また実践する。
理論だけでも足りず、実践だけでも足りません。往復させることで、行間が埋まっていくのですね。
そして行間が読めるようになると、近接領域の知識も学習しやすくなります。
数学の微分が物理で使えたのと同じです。設計の話がわかると、データベースの正規化の意味が変わって見える。正規化がわかると、トランザクション境界の切り方に説明がつく。1 つの領域で深く掘った理解は、隣の領域に持ち出せる形をしているのです。
新しい本を 1 冊買うより、持っている本を読み返す方が効くのは、このためです。
知の統合、コンシリエンス
さて、ここまでの話を並べてみます。
高校数学の教科書は、単元の寄せ集めではなく一本の道でした。リーダブルコードは、名前の本ではなくアーキテクチャとドメインの本でした。
どちらも、具体から抽象に登って、また別の具体に降りている構造をしています。
リーダブルコードで言えば、扱っているのは変数名やメソッド名といった、コードベースの極めて具体的な事象です。それを実践を通して読み返すと、責務、契約、距離といった抽象概念に登っていく。そして登った先から、アーキテクチャやドメインの設計という別の具体に降りてくるのですよ。
知の統合、コンシリエンスとでも言うべきでしょうか。
バラバラに覚えた知識が、あるとき「同じことを言っている」と気づく瞬間があります。あの瞬間のために、私たちは本を読んでいるようなものだと思っています。
そして、その瞬間は**初読ではまず来ません。**知識がまだ点だからです。点をいくつか打って、実践で線を引いて、読み返して面にする。この手順が必要なのですね。
積んである本、ありますよね？
その本、たぶんもう一段深く読めますよ。
まとめ
というわけで、おすすめの本は「あなたが持っている本」だよ！ って話でした！
新しい本を買うなとは言いません。でも、買って 1 回読むだけで終わらせるのはもったいない。
エンジニアの本は科学の本です。積み上がった構造そのものが中身なので、読む側の高さが変われば見えるものが変わります。実践して、読み返して、行間を埋めて、近接領域とつなげる。そうやって少しずつ、エンジニアリングの根源に近づいていくのだと思っています。
本棚から 1 冊、抜いてみてください。当時わからなかったページが、今なら読めるはずです。
繰り返し読んで、エンジニアリングの根源を目指していきましょう！