第1章で思案中

先週に引き続いて、この週末もドトールに行ってきた。で、早速コーヒー回数券を使おうと思ったが、なんと家に置いてきてしまっていた。ま、自分に限って10回やそこらで原稿が書き終わるはずはないので、別にどうってことはない。

今日は書籍全体の構想を考えた。今回書くのはレッスン本なので、自宅にあった類似の本をひと抱えドトールに持ち込んで眺めてみた。眺めたのは以下の4冊である。
1) 論理トレーニング101題
2) マッキンゼー流 図解の技術 ワークブック
3) 将棋ワークブック―将棋を覚える人のためのやさしい詰みと必至
4) すらすらと手が動くようになるSQL書き方ドリル

どの本も練習問題に入る前の説明が少ないのが共通の特徴である。前書きはそこそこにしてすぐに問題を提示し、答えを説明しながらノウハウを解説している。3)だけは盤面の構成や駒の動かし方など将棋のルールを説明しているが、それでも必要最低限にとどめている。また1)や2)では最初の説明で悪い例を提示し、読者にモチベーションを与えていた。そういえば『リファクタリング』も最初に悪いコードを出して、それを改善する例を提示する方法をとっていた。うまくやれると効果的だが、最初に大きなUMLモデルを提示するのはかえって抵抗感を大きくしてしまうかもしれない。

自分が書くテーマは要件定義段階で行うUMLモデリングである。この分野の本はそこそこあるものの、実際に開発の現場でモデリングをやっている場面を見ることはそれほど多くない。したがってモデリングのノウハウを身につける効果を読者にきちんと伝えるために、ある程度は最初に能書きを書いておく必要があるだろう。しかし抽象的あるいは浮き世離れしたモデリング話を冒頭から書いて読者を煙に巻くのは、現実派を標榜する自分としては避けたい。冒頭の解説をどうするかが今回の悩みどころのひとつである。

本は一度しか書いたことがないが、第1章は特に難しいと思う。前回の本の時も第1章はだいぶ苦労した。最初に3〜4ヶ月ぐらいかけてドラフト版を書いたものの、本全体の半分強まで書き進んだ頃に書き直したため、結局当初の原稿はほとんど捨ててしまったことを思い出す。

一日いろいろ考えた末、前回の経験を生かして第1章は後回ししようと思う。ということで今週も進捗はゼロである(笑)。