DuplexBook

http://martinfowler.com/bliki/DuplexBook.html

2007/6/13

先週、私のシグニチャシリーズの新刊が出た。 Gerard Meszarosによる『xUnit Test Patterns』だ。 Gerardとは数年間この件についてやり取りをしてきたので、内容についてはよく知っているのだが、実際の本を見てかなりショックを受けた。なにこの厚さ。883ページて。シグニチャシリーズのなかでダントツの厚さだ。

私は厚い本があまり好きじゃない。『UMLモデリングのエッセンス』が薄いのには誇りを持っているくらいだ。厚い本は怖い。一体いつ読めるっつーんだ？

だが、『xUnit Test Patterns』は見た目ほど怖くはない。なぜなら、これは2冊の本が1冊になったものだからだ。私が『PofEAA』で使ったやり方でもある。 1冊目は物語（narrative）で、「隅から隅まで」読んでもらい部分だ。物語は要約を載せたものなので、あまりページ数は必要ない。『xUnit Test Patterns』では181ページまで、『PofEAA』では106ページまでとなっている。 2冊目はリファレンスで、こちらは隅から隅まで読む必要はなく（たまに読む奴もいるけど）、必要なときに読んでもらえればよい。つまり、物語を読んで全体的な理解をして本棚に置いておけば、リファレンスを探る必要のあるときに簡単に手に取ることができる、というわけだ。

私は歴史書をよく読むのだが、歴史書もデュプレックス本にしてもらいたいと常々思っている。歴史書はある事柄の詳細やそう考えた証拠を説明する必要があるので、厚い本になってしまうことが多い。私の大好きな『銃・病原菌・鉄』*1もそうだ。本書は非常に楽しいしすごくオススメなのだが、死ぬほど長いので、デュプレックス本だったらどんなにいいかと思っている。

『How to Read a Book』には、本を最初に読むときは飛ばし読みをするとよいと書かれている。私は本を非常に早く読めるし、役に立ってはいるのだが、飛ばし読みはもっと役に立つ。本がそういうふうにデザインされていてもいいと思う。私の個人的なルールでは、技術書における物語は200ページが限界だ。結局、みんなが楽にコアとなる情報を取得できる方法が必要なのだ。デュプレックス本が唯一の方法ではない。『時を越えた建築の道』のような★選ばれた目立つ段落★のような方法もある。これは私にとって非常に具合がいい。まだ私がお目にかかっていない方法もあるに違いない。だが今のところ、デュプレックス方式がベストな方法だと思っている。

デュプレックス本は、徐々に章を進めながら本を構成するという一般原則の特殊ケースである。 ピッケル本はよい例だ。最初の2章では、rubyの概要を24ページで説明している。続いて、280ページのチュートリアル。それから、500ページのリファレンスだ。『Enterprise Integration Patterns』では、最初の数章が概要（95ページ）で、残りがリファレンスとなっている（500ページ）。ただし、このような本は、話のつながりがそれほど明確ではない。

デュプレックス本は本当に便利なのかという疑問もあるだろう。多くの人が『xUnit Test Patterns』はデュプレックス本だと思っておらず、一冊の厚い本だと思っている（背表紙には3冊と書かれている。リファレンスが2冊に分かれているのだ）。物理的に2冊にして2巻ものにすることはできるだろうか？私は、2冊別々に売ると両者が密接に関係していることが分からなくなってしまうと思う。

我々はオンラインアクセスのことも考えている。リファレンスはWebに適しているため、リファレンスをWebオンリー（あるいは物理的な本にCDなどを添付）して、物語部分だけ売ることができるかもしれない。これは売り上げにどう影響するだろうか？

つまり言いたいのは、厚い本の著者は200ページで読めるような構成を考えろってこった。