本を読むときに、理解のための要約はしないし使わないと決めている

身近な人何人かに聞いたがあまり賛同は得られなかったので、この話が役に立つ場面は少ないかもしれません。悪しからず。

本を読んで学びを得ようとするとき、要約されている文章を読んだり自分で要約をしたりする人がいる。最近だと ChatGPT をはじめとする生成 AI が当たり前のものになっていて、全文にじっくり目を通す人はますます減っているのでは。

一方で僕は本の要約について、

  • 理解の促進のために自分で要約を作る

  • 理解の補助のために誰かが作った要約を読む

のいずれもしないと決めている。「要約をすることによって抜け落ちた情報」や「要約を使うことによって得られなくなった情報」があって、それこそ重要だと考えているから。

例えばソフトウェアの開発生産性に関する話でこんな話が出てきたとする:

  • ソフトウェア開発において、生産性を高めることは重要である。

  • 生産性の定義は様々あるが、例えば DORA が提唱した「Four Keys」メトリクスについて考えてみる。

  • その中の「デプロイ頻度」や「変更のリードタイム」といった指標を改善するためには、小さな変更をより頻繁に届けるようにするのが効果的。

  • 変更を小さくするためにプルリクエストを小さくしよう、特に 500 行を超えるようなものは複数に分割をしよう。

こういう趣旨の文章を読んだときに、しばしばこういう要約がされることがある:

ソフトウェアの開発において、生産性の観点からプルリクエストの大きさを 500 行に収めることは重要である。

「確かにそう」という内容なのだが... 要約をする前には残っていた背景情報や論理構成がごっそり抜け落ちてしまっている。そうした情報と身の回りの状況とを照らし合わせないと、自分たちが実践するのに効果的かどうか想像できないにも関わらず。

「それなら背景知識や論理構成を失わない形で要約を作ったらどうか?」となるが、そうして出来上がったものは要約といえるのだろうか。元の文章から削ぎ落とされる部分はどこなのだろうか。そんなことを昔考えたことがあって、要約を作るのをもうやめてしまった。

書籍に載っている事柄をそのまま適用できる場面は少ない。自分が置かれている状況を踏まえて応用できるようにするためにも、まずは本の内容をそのまま理解する(その上で解釈をして自分の血肉にする)ように努めている、という話。

(この文章だと、最後の段落だけ読んでおけばいい気もしますね)

@yamat47
ソフトウェアエンジニアやったりマネージャーやったり。 @yamat47