引用するために本を読む

専門書を読むということはいまだに学習において重要な役割を担っていますが, 多くの人が他人から教わったりググったりするよりも難しいと感じているでしょう. 書籍の場合は購入しなければならず, 本を読むという行為も一瞬で終わるとは言い難いです. ただ誰しも全ての本を巻頭から終わりまで読んでいるわけではありません. そこで本を使うことを目的とすることで, 本を読むということをより簡単に済ませてしまいましょう. 本を使うということはすなわち本を引用するということです.

どのように引用するか

さて引用というと, 論文を書き上げてから研究室に転がっていた本を拾い上げて一生懸命絞り出した文献のリストを思い浮かべるかたもいるでしょう. ここでは形式ばった引用以外だけでなく単に本を紹介するときの具体的なパターンについて挙げていきます.

意見の論拠とするため

通常引用と呼ばれるものとしての使い方です. この場合は本文から筆者の意見を引用することで, 自身の意見を補強することができます. 借りられるなら虎の威は借りたほうが良いです.

例えばテスト駆動開発の重要性については多くの書籍で語られています.

内側（実装）からではなく外側（テスト）から考える。これは問題解決に取り組む自然な方法だ。^[1]

仕様は、コードを書き終えてから書くものではありません。コードを書く前に必要なものです。そこで、コードを書く前に仕様（テスト）を書くことになります。^[2]

共通認識を得るため

これも一般的に引用として利用される方法です.

「鉄の三角形」^[1:1]や「荒ぶる四天王」^[3]のようなものは単純に言葉を定義するだけでは伝わらず, 考え方そのものを根拠になっています. このようなことを説明するには紙面が足りなくなってしまうため, 前提知識として置いておく必要があります. そのために参考文献を使ってどのような前提知識を必要かを示すことができます.

チーム内でも共通認識を得たい章だけ輪読会を開いたり, 勉強会などで軽く紹介することで共通認識を得ることができます. たとえ他の人が読んでいなくても「あの本ね」で通じるようになるためかなりの効果があります.

言葉を定義するため

言葉の意味が伝わりにくい場合には参考文献を挙げることで, 読み手に対して言葉の意味を理解してもらうことができます.

例えばアプリケーションの種類として「バッチ」と呼ばれるものがありますが, 用語として適切かどうかは議論の余地があります. しかし『Googleのソフトウェアエンジニアリング―持続可能なプログラミングを支える技術、文化、プロセス』^[4]に「バッチジョブ」と「提供ジョブ」という用語が定義されています. あとは引用元を提示すれば用語そのものに疑念の余地はありません.

また直交性という用語は幾何学から転用された用語のため, 単純に用語が伝わらない可能性があります. 『達人プログラマー（第2版）熟達に向けたあなたの旅』では以下のように直交性を簡潔に説明しています.

この用語はコンピューティングの分野では、ある種の独立性、あるいは結合度の低さを表しています。2つ以上のものごとで、片方を変更しても他方に影響を与えない場合、それらを直交していると呼ぶわけです。^[5]

先の共通認識を得るよりも, 要点を絞っているため簡単に理解してもらえるし, 後で参照して深い理解を得ることもできます.

読み手が参照可能にするため

本を読むときに参考文献からさらに別の文献を参照することができるということは私の学習の中でも大きな役割を担っています. 同様に私が目を通した文献を読み手が参照可能なように, そのため私が書く技術記事においてもなるべく多くの参考文献を挙げるようにしています. 技術記事のようなアウトプットを主体としたものだけではなく, コードレビューのコメントにも参考文献を挙げています. 例えば以下のようにコメントすることで, 読み手はコメントに対する表面的な理解だけではなく参考文献をもとに詳しい解説を得ることができます.

List 型を返すメソッドで null を返すのは避けるべきです. 『Effective Java 第3版』の「項目54 null ではなく、空コレクションか空配列を返す」を参照してください^[6].

どのように本を読むか

さてここまでで本を使う具体例を挙げてきましたが, 次に実際にどのように本を読めばよいか述べていきます.

目次を読む

専門書を読む場合はある程度分野などの目的を決めて選定しているはずです. 専門書の場合は特にその分野について学習したいという目的が少なからずあるはずです. このとき大事なのは, その分野に関する自分の理解度と本の内容がどの程度合致しているかということです. 目次を読むことでこれを素早く検証することができます.

例えばアジャイルについて新たに勉強してみます. Amazonで「アジャイル」と検索したところ『SCRUM BOOT CAMP THE BOOK【増補改訂版】 スクラムチームではじめるアジャイル開発』という本が一番先頭に出てきたのでこれを読んでみます. いま私はアジャイルについて何も知りません. 目次を見ると以下のような章立てになっています^[7].

• 基礎編 スクラムってなに？
  • アジャイル開発とは？
  • スクラムってなんだろう？
  • 機能や要求を並べ替える
  • プロダクトの責任者は誰？
  • 動作するプロダクトを開発する
  • 短く区切って繰り返す
  • 頻繁に計画する
  • スプリントごとに完成させていく
  • 毎日状況を確認する
  • 出来上がったプロダクトを確認する
  • もっとうまくできるはず
  • 縁の下の力持ち
  • まとめ

これだけでなんとなくアジャイル開発がどのようなものか理解することができます. このようにまずはその分野に対する知識地図を作るために目次だけでも読むのがよいです.

では次にある程度その分野に対して知識レベルが上がってきた場合を考えます. このときは狙いをつけて本を読むために目次を読みます.

ここでアジャイルについてある程度知識がついてきたとします. どうやら『アジャイルサムライ――達人開発者への道』という本が定番としてよく読まれているようです. 次はこの本を読むことにしましょう. いま特に関心があるのは見積もりについてです. 目次を見ると「第7章: 見積もり：当てずっぽうの奥義」という章があることがわかります. とりあえずこの章だけ読んでみることにしましょう.

参考文献を読む

専門書では特に多くの書籍で参考文献が用意されています. これは上で述べたように, その書籍の中での定義や概念を補足する役割を担っています. そのため参考文献として挙げられている文献を読むことで, その書籍だけを読むよりも深い理解を得ることができます.

一般的に重要なことは多くの人が語っています. つまり同じような本には同じようなことが書かれているはずです.

同じようなことが書かれている部分は重要な内容である反面, 何度も似たような記述を目にするため読み飛ばせるようになるはずです. 同じような本を読むうちに分野に一貫した通説とその書籍だけがもつ筆者の主張を分けて読むことができるようになります. ここまでくれば本を頭から読んでいってもそれほど時間がかからなくなります.

参考文献を使った面白い読み方として, 引用数の多い文献を読まずに理解するという方法があります. その分野で定番とされている文献は多くの文献で引用されています. 引用している書籍を読むことで, 引用されている文献に対する筆者の理解を知ることができるため, 間接的に引用されている文献について理解することができます. 定番とされている文献を読んでみてもよくわからない場合はそれを引用している書籍を読むことで理解できるようになるかもしれません.

調べる

専門書の場合, 調べ物をしているときに本を参照することも多いでしょう. 調べ方にはいくつかパターンがあります.

単にググって出てきた書籍を読むというパターンが最も多いかもしれません. これだけでも十分効果的だと思います.

別のパターンとして一度読んだ書籍について, ある用語をもとに調べ直すということもあります.

具体例としてエラーの回復可能性について考えます. 思い当たるふしとして, 『Effective Java 第3版』があります. 実際に「項目 70 回復可能な状態にはチェックされる例外を、プログラミングエラーには実行時例外を使う」という項目がありました. エラーについては『Good Code, Bad Code ～持続可能な開発のためのソフトウェアエンジニア的思考』^[8]にもありました. その通り「4.1 回復可能性」という章があります. 例外については『ソフトウェア設計のトレードオフと誤り―プログラミングの際により良い選択をするには』^[9]にも書かれていた気がします. 「3章 例外 vs 他のエラーハンドリングパターン」という章がありました. 回復可能性についても一部書かれていますが, あくまでトレードオフを主題としているため他の書籍よりも少ないです. 先に挙げた2冊を参考にするのがよさそうです.

このように記憶を頼りに書籍を読み直すこともできますが, 全てを記憶しているわけではないため, 検索と組み合わせて記憶を補強しています.

これ以外にも最近ではLLMとRAGを利用して調べることができるようになってきました. 今後こういったツールが普及すればますます本を丸々読む必要がなくなるかもしれません. ただしエラーの回復可能性のような概念はそもそも知識として持っていなければ調べることはできません. 本を読むということに限らず包括的な知識の獲得が必要なことには変わりないでしょう.

本を読む

ときには腰を据えて頭から本を読んでいくことも大事です.

本をしっかりと読み込んでいるときは後で引用できるように, 筆者の主張となるようなキラーフレーズを抑えておくといいかもしれません. 国語力が試されるときです

---

私が本を読むのは本を読むのが好きだからです.

脚注

1. レガシーコードからの脱却―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス David Scott Bernstein, 吉羽 龍太郎, 永瀬 美穂, 原田 騎郎, 有野 雅士, オライリー・ジャパン, 2019 https://www.oreilly.co.jp/books/9784873118864/

2. 継続的デリバリーのソフトウェア工学　もっと早く、もっと良いソフトウェアを作るための秘訣, David Farley, 長尾 高弘, 榊原 彰, 日経BP, 2022 https://bookplus.nikkei.com/atcl/catalog/22/12/01/00531/

3. アジャイルサムライ――達人開発者への道, Jonathan Rasmusson, 西村直人, 角谷信太郎, 近藤修平, 角掛拓, オーム社, 2011 https://www.ohmsha.co.jp/book/9784274068560/

4. Googleのソフトウェアエンジニアリング―持続可能なプログラミングを支える技術、文化、プロセス, Titus Winters, Tom Manshreck, Hyrum Wright, 竹辺 靖昭, 久富木 隆一, オライリー・ジャパン, 2021 https://www.oreilly.co.jp/books/9784873119656/

5. 達人プログラマー（第2版）熟達に向けたあなたの旅, David Thomas, Andrew Hunt, 村上 雅章, オーム社, 2020 https://www.ohmsha.co.jp/book/9784274226298/

6. Effective Java 第3版, Joshua Bloch, 柴田 芳樹, 丸善出版, 2018 https://www.maruzen-publishing.co.jp/item/b303054.html

7. SCRUM BOOT CAMP THE BOOK【増補改訂版】 スクラムチームではじめるアジャイル開発, 西村 直人, 永瀬 美穂, 吉羽 龍太郎, 翔泳社, 2020

8. Good Code, Bad Code ～持続可能な開発のためのソフトウェアエンジニア的思考, Tom Long, 秋 勇紀, 高田 新山, 山本 大祐, 秀和システム, 2023 https://www.shuwasystem.co.jp/book/9784798068169.html

9. ソフトウェア設計のトレードオフと誤り―プログラミングの際により良い選択をするには, Tomasz Lelek, Jon Skeet, 渋川 よしき, 山田 智子, 本田 健悟, 辻 大志郎, 宮永 崇史, 小橋 昌明, 柏木 祥子, 岸本 卓也, 後藤 玲雄, 棚井 龍之介, 原木 翔, 山本 力世, オライリー・ジャパン, 2023 https://www.oreilly.co.jp//books/9784814400317/