第302回 ３冊目の本を出版する話２ ～執筆から出版まで～
こんにちは、キャリアコンサルタント高橋です。
2/25に私の３冊目の本『日本でいちばんわかりやすいプログラミングのドリル』が出版されました！ 先週よりこの本の紹介をさせてもらっていますが、今回は前回の続きで執筆から出版までの裏側をご紹介いたします。
■執筆活動～産みの苦しみ～
当初、この本の出版時期は昨年10月頃に設定されていました。そのため、逆算をすると執筆活動は８月頃までに完了しておかなければなりませんでしたし、私もそのつもりで執筆をしていました。
いろいろと議論を重ねていく中で、この本は問題を解きながら理解を深めてもらう方向性ができていました。また、読者層を考えると本のページ数は厚くしない方が良いと考え、問題数は80～100問に設定されました。
そうして一通り100問の問題をつくってみて分かったのですが、私の中でどうもシックリ来ませんでした。プログラミングの問題ということもあると思いますが、問題が無機質に感じてしまうのです。問題を解いていく作業が淡々としており、楽しくないのです。。。そのための対策はいろいろと考えてみたのですが、これだ！ という解決策が浮かびませんでした。そこで、再度編集者さんとブレストをして、本の方向性を検討し直すことにしました。その結果、以下のような方針が決まりました。
- プログラミングを絵で表現する
- 問題にはいくつかのストーリーを持たせ、過去の問題の続きで新しい問題が出てくるようにして、読者の興味を惹くような問題にする
これを受け、再度100問を作り直すことにしました。ちょうど70問程度できたところで振り返ってみたのですが、確かに今度は絵でストーリーを表現しているので読みやすくはなりました。しかし、同時に「プログラミングの本」ではなくなっていました。絵とプログラミングの紐づけがうまくできないのです。こうなると何の本か分からず本末転倒です。その後、フローチャートを使う、ソースファイルと絵を混在させて表現するなどいろんな方法を模索しましたが、結局絵でプログラムを表現する方法は本質から外れてしまう可能性があると判断し、この方法を断念することになりました。
余談ですが、子ども向けにつくられているスクラッチ（Scratch）というプログラミング言語の方法もブレストの中で出てきました。スクラッチはプログラムを絵で表現することに成功しており、この方向に方向転換しそうになったことがありました。しかし、そうしてしまうとスクラッチの模倣になるのでその方法は採用しませんでしたが、改めてスクラッチは優れたプログラミング言語であることを感じました。
そんな訳で、三度初心に帰り、もう一度ゼロベースで問題を作成し直すことになりました。このときは原点回帰をして、
- 極力説明を省き、問題から答えを推測する
- 前の問題が後の問題のヒントになる
を実現できるようにまたもや問題をつくり直しました。この段階では最低問題数のラインを80問に設定していたので、まずはここまでの問題を作成しました。そうして、一度出版社さんに確認していただくことになりました。
その結果、「難しい」と言われてしまいました。。。
問題にはIf文やFor文などが出てくるのですが、十分な説明がなされていないので理解ができないままページが進むことになります。それは後々の問題で解決できるようなつくりにしていたつもりですが、疑問を抱いたまま読み進めていくことにストレスがたまり、どんどんモチベーションが下がっていくとのことでした。また、そもそもIf文やFor文をなぜ知らなければならないのか？ といったことが分からないので、動機づけされないという意見もありました。こうなってしまうと、この本が狙ったところに向いていないと結論付けなければなりませんでした。...ということで、四度問題をつくり直すことになりました。。。
今度は問題の構成を見直し、以下のような方針を立てました。
- すべての問題に対し、読者にプログラムをつくっていることをイメージしてもらい、問題に向かっていくことの動機づけをする
- 次の問題は前の問題のプログラムを踏襲するようなつくりにすることで、何度も類似するプログラムを何度も見ることになり、自然とプログラムの理解を深めるように配慮する
- 問題の答えで処理の解説を極力なくし、その分、ヒントを厚くすることで、読者自らがプログラムをイメージし、考えられるような構成にする
などを盛り込み、また問題を作成し直しました。そうして、再度出版社さんに感想をいただき、何とかOKをいただくことができました。ちょうど、８月の終わり頃でした。
■校正～産みの苦しみ、再び～
その後、約２カ月ほど少し時間が空くことになります。というのも、この段階で出版計画が見直されることになり、来年１月の出版にずれ込むことになりました。そのため、原稿執筆後の校正作業は11月頃からスタートすることになりました。通常、本の校正作業は２～３回程度校正を行い原稿を完成させます。しかし、今回の本はちょっと特殊なのであらかじめその校正も時間がかかる見込みをしていました。それでも、実際に校正作業をやってみると、都合４回も校正することになってしまいました。
最初の校正では本の形態に落とした状態での原稿の見直しがメインになりました。今回の本は問題を解く形になっているので、ページレイアウトが重要になります。また、１ページの行数制限もあるので、これらを調整しながらほぼすべての問題を加筆修正することになりました。さらに、この段階で前付（まえがきや本文の説明）、後付（あとがきや補足説明など）の原稿も仕上げていきました。
一応、ここまではある程度順調に進んでいたのですが、ここに来て大きな問題が出てきました。それはページ数を増やしてほしいという要望が出版社さんから出てきたのです。この段階では約160ページ程度に仕上がる予定で進めていたのですが、200ページまで増量してほしいとのことでした。この段階でのページ増は本全体の構成をやり直さなければならないインパクトになるので、正直どのようにすればよいか迷いました。しかし、新たな問題を追加し、前付、後付などを拡充させることで、何とかこのこの要望も実現させることができました。
その後、仕上がった原稿をもとに２回目の校正（二校）が行われました。ここでもまた問題が起こりました（汗）それは読者特典として用意していたコンテンツの整合が取れていないことに気づいたのです。読者特典の詳細はここでは割愛させていただきますが、このことが原因でほぼ全部の問題の加筆、修正が必要になりました。また、各問題の整合性が合わない部分の見直しも行ったため、結構大掛かりな修正になりました。
そうしてできた原稿をもとに３回目の校正（三校）が行われました。ここでもまたまた問題が起こりました（汗）それは出版社さんでレビューをしていただいた方（全くプログラミングの経験がない方）から「本を読んでも分からない」と言われてしまったのです。例えば、「『a=1』のような変数への代入の必要性が理解できない」といった、この本の根本的な部分にかかわる内容でした。ただ、この段階になると出版まで１カ月を切っており、納期のデッドライン近くまで来ています。そのため、出版社さん側も対応は任せると言われました。しかし、こういった意見が出ている以上ほおっておくことはできないと考え、この段階でまたもや全部の問題をつくり直すことにしました。無事数日でつくり直すことができましたが、今にして思うと相当無謀なことをやったと思います。。。
こうやってできた原稿をもとに最後の校正（念校）を行い、なんとか校正作業を終わらせることができました。時期は２月の初め、出版の２～３週間前になっていました。
■そして出版へ
執筆中や校正中はそのときに最善のことを尽くそうとしか考えていなかったのですが、こうやって振り返ってみると、ずっとトライ＆エラーで試行錯誤を繰り返していたような感じがします。でも、その分納得の行く本ができたと思っております。
このコラムがアップされる頃には全国の書店さんで並んでいると思います。もし、見かけられた際はぜひお手に取ってご覧ください！
