「現場のためのSwift4」が出版されるまで著者としてやったことまとめ

活動報告 このページをあとで読む

「現場のためのSwift4」が出版されてから約1ヶ月ほど経ちましたが「企画・要件定義・リリース後の運用のことまで書かれているSwift技術本は今までになかった」という、好意的な評価を見聞きする機会が多くありまして、大変嬉しく思っています。やったね！

プログラミングだけではなくて「開発とは何か、プロジェクト管理とは何か・・・みたいな、全体像を捉えたい方もいるはずだよね」という考えでこの本に携わっていたので、とてもありがたい反響だなぁと思っています。

「現場のためのSwift4」については、以下のページをご参考ください。

5/22発売「現場のためのSwift4 実務で『本当』に通用する開発者になるための教科書」は、フィルター加工機能付きカメラアプリやWeb APIを使ったニュースアプリの作成を通じて「開発の全体像」が学べる一冊ですこのページをみる

出版までに経験したことをまとめました

ところで「現場のためのSwift4」が出版されるまでに得た知識や技術はとても勉強になることも多くて、今後に活かせそうなことばかりでした。いい機会なので、私が出版までに経験したことをこのページにまとめました。

とはいえ、本の内容はもちろん出版社さんによって進行のルールは違うと思いますので「これが正解だ！」というのではなく、あくまで「私の場合はこんな感じで出版までたどり着いたよ〜」という一例として書いています。

もし「本が出版されるまでにどんなことをするんだろ？」という、興味をお持ちの方がいらっしゃいましたら、ご覧いただけますと幸いです。

企画がスタート

たぶん、よくある流れなら「こんな本を出版しよう」という「企画」が出版社さんなり、著者が直接持ち込むなり、何らかの形で浮上するのではないかと想像しますが、ある日、筋肉自慢をする人から「Swiftに関する本を書いてみませんか」というお話をいただきました。なので「企画はある程度固まっている」という状態ですね。

「どう関わることができるか」を考えました

当時、私のSwiftに関する知識や技術と言えば、入門書を読んで外部APIを使ってサンプルアプリを作れる程度でした。私はウェブサイト制作やシステム開発のマネジメントやディレクションなどを日々業務として行なっているため「開発の全体像について」や「プロジェクトの進行管理」などは、現場や言語を越えて共有できる知識や技術があるはず・・・ということで、出版の企画に参加させていただきました。

対象読者層を意識しながら「章立て」する

巷の技術書では、本の内容ごとにいくつかの章にわけて書かれていることが多いと思います。「現場のためのSwift4」も例にならって「具体的に書く内容」を決めて「章立て」することになりました。

もちろん、書く内容を決める際には、対象となる読者を想像しながら、

  • 開発現場に入らないと知り得ることができない知識や技術
  • プログラミング以外の工程
  • 開発の全体像

を中心に、書く内容を洗い出して「章立て」をしました。

テスト原稿の作成

「章立て」が済んだ後は「テスト原稿を書きましょう！」という出版社さんの進行に従い、1章から原稿を書き始めました。

テスト原稿とは？

原稿を全て書き終えることを、一般的に「脱稿」と呼びますが、テスト原稿とは「脱稿前の仮の原稿」のことです。テスト原稿は出版社さんに提出して、以下のようなチェックや指示をいただきます。

  • 各種フォーマット（章、節、イラスト、表、注釈、コード など）
  • 各章の文章量のバランス

上記の中でも「文章量のバランス」については少し悩みました。他の章と比べて「多すぎる文章は他の章に分ける」「少ない文章は膨らましたり、他の章に含めてしまう」など、文章量に気をつける必要があることを、この時初めて知りました。

原稿のクオリティを上げる

テスト原稿を書き終えたら、次は「脱稿」に向けて原稿のクオリティを上げる必要がありました。

ただ、テスト原稿の時点では、出版社さんから文章の「内容」についての指摘はほぼありませんでした。出版社さんからの指摘がないのも当然で「現場のためのSwift4」は技術本なので、開発全体のことやSwiftの知識や技術などがわからないと指摘のしようがありませんね。そりゃそうだ・・・

というわけで「クオリティを上げる」作業のほとんどは著者側で行う必要がありました。

「クオリティを上げる」とは

ここで「クオリティを上げる」ことについて定義したいと思います。

とても単純なことですが「クオリティを上げる」とは、主に「より正確に、伝わりやすく仕上げること」ではないかと思います。具体的に書くと、

  • 章、節
  • 文章
  • コード
  • イラスト

などの正確さ、伝わりやすさの向上を図ることが、クオリティを上げることにつながると考えました。

クオリティを上げるための「編集」

「クオリティを上げる」の定義も確認したところで、以下に挙げたような「編集」を数回繰り返しました。

章、節の編集

脱稿に向けて原稿を見直していくうちに「ちょっと内容を変えたいなぁ」という箇所がいくつかでてきました。その際、原稿の内容に合わせるため、章や節を編集しました。

また、目次をパッと見たときに、章や節だけである程度書かれている内容を把握できるように編集しました。

文章の編集

・「文章のつながりがない書き方」を編集

文章の前後関係って大事ですよね。「『A』の話題で読み進めていたのに、いきなり『B』の話題に変わってしまった」など、急に話題が変わると読者に疑問を与えてしまいますね。「この文章、前後の文章と何か関連があるのかな」という、本の内容とは別のところで考え込んでしまい、頭に入ってこない状況もあると思います。

そのような状況を解消するため、文章のつながりを入れるよう編集を行いました。「そんなこと、学生時代に習う基本的なことだよ」と思われるかもしれませんが、全くその通りだと思います。

ですので、つながりが「ある」文章と「ない」文章とでは、読みやすさが全然違うということは広く知れ渡っている事実のはずなので、つながりが「ない」文章のよみづらさを極力減らすことに努めました。

・「ブログっぽい書き方」を編集

「書くのはブログではなく、本だよね」という原点に立ち返って、言い回しなどを見直しました。ブログっぽい書き方を活かす形で、あえて出版する本もあると思いますが「現場のためのSwift4」の対象読者を想像すると、一般的な技術書にならった書き方のほうがいいだろう、という考えのもと編集しました。

・「こそあど言葉」を編集

こそあど言葉って、便利なのでついつい使ってしまいがちなのですが「何を指しているのか」をぼんやりとさせてしまう傾向があります。ですので、

  • これ
  • それ
  • あれ
  • どれ

という指示代名詞を極力つかわないように、具体的な文章に置き換えました。

・「曖昧な表現」は可能な限り言い切る

  • だと思う
  • かもしれない

など曖昧な表現は「正解が1つしかない物事」に対してつかう言葉としては適切ではないので、読者の方に不安感を与えてしまいますね。曖昧な表現は、可能な限り言い切るように編集しました。

ただ、すべて言い切る必要はなく、例えば、未来の予測について書くのであれば「だと思う」や「かもしれない」などの曖昧な表現を使ってもいい、というルールを設けて編集しました。

・カコミに見出しをつける

本書中には「設定手順」や「チェックリスト」など、リスト形式で解説している箇所がいくつかあります。この箇所を、パッと本を開いた瞬間に「何について書かれているのか」わかりやすくするため、見出しを入れました。

コードの編集

本書中にサンプルコードを載せているのですが、コードを読みやすくするため、コメントを入れたり色分けをしました。

また、本に掲載してあるコードを「そのままコピペして」動くかどうか、シミュレーターと実機それぞれで確認しました。

本書にも解説がありますが、カメラ機能などシミュレーターで動かない機能もあるため、実機での確認は必須ですね。

イラストの編集

本書中のビジネスロードマップなどの表や挿絵などは、出版社さんにイラストの作成をお願いしました。お願いする際には、下の画像のようにラフで絵を描き「こんな感じで作成してほしい」という要望も添えました。

すると、出版社さんがいい感じに作成してくれます。

編集は大事な作業

細かく書けばもっとたくさんあるのですが、上記の編集作業を数回繰り返すことでクオリティを徐々に上げていきました。

どれも1つずつ見れば単純な作業ですが、600ページものボリュームに対して繰り返し作業を行ったので、かなりの作業量がありました。

そのため、上記の編集作業を経て「脱稿しました！」と言いたいところですが「現場のためのSwift4」は、作業の進行上の都合で次の工程のゲラチェックまで編集作業を一部持ち込むことになりました（出版社の秀和システムさん、本当にありがとうございました）。

ゲラチェック

脱稿した原稿は、ゲラ（または「校正紙」とも呼ばれる）となって著者に渡されます。

この時、著者側でゲラのチェックを行い、誤字・脱字などがあれば修正を出版社さんに依頼します。そして修正されたゲラを受け取り、再度チェック・・・という作業を数回繰り返して原稿を完成させます。ゲラチェックの回数は、出版社さんや進行状況によって変動すると思います。

先ほども書きましたが、ゲラチェックの段階で編集作業が一部残っていたので、編集とゲラチェックを並行して行う必要がありました。

ページ調整

ページ数や本のサイズなどは「章立て」をした段階で出版社さん側でおおよそ決められます。そしてゲラチェックの工程に差し掛かるあたりで最終的な本のページ数が見えてくるので、決められたページ数を超えてしまった場合は、章や節の一部をカットする必要があります。

「現場のためのSwift4」も、カットした章や節がいくつかあります（カットしても500ページ超えの大変なボリュームの本になりました）。

その他の原稿の作成

はじめに、あとがき、著者紹介の文章を書きました。

下の画像は「はじめに」の一部です。「こんなことを考えながら本を読んで欲しいな」と思って書きました〜。

もし書店で本書を見つけた際には、パラパラっとめくって見ていただけると嬉しいです。

配布用サンプルプログラムの作成

本書中に載せているサンプルコードをダウンロードして読者の方が動作確認ができるよう、配布用のサンプルプログラムを作成しました。

また、サンプルプログラムを動作させる際に必要な設定などを解説したReadmeファイルも作成しました。

正誤表の作成

大変申し訳ないのですが、ゲラチェックの時点では見つけられなかった誤字や間違いがありましたので、正誤表を作成し、出版社さんのサポートサイトで閲覧できるようにしました。

もちろん、本来は「正誤表なんて存在しない方がいい」ことは十分理解していますので、もし本書が増刷になったら、正誤表として掲載している箇所も改訂版として反映できるはずですので・・・なにとぞ、なにとぞ増刷を・・・

販促用ポップの作成

本書の販促用にポップを作成しました。特に私は「気持ちのこもったポップにしたいな〜」と思い、手書きと印刷用の2パターンを作成しました。ポップについては以下のページに詳細を書きましたので、ご参考ください。

5/24より「現場のためのSwift4 実務で『本当』に通用する開発者になるための教科書」の「イラスト入りPOP」を書店にお願いして置いてもらう旅に行ってきますこのページをみる

書店へ挨拶

ポップを持って、例の筋肉自慢の人と数店舗周ってレクチャーしてもらい、あとは一人で池袋、渋谷、新宿などの都内、私の地元の富山、出張先の大阪の大型書店を中心に周りました。

まとめ

「現場のためのSwift4」に携わることで、出版までの流れはおおよそ掴むことができました。だだーっと勢いで大まかに覚えていることを書いたので、今後は随時このページを更新して、細かい付け足しなどをしながら「ああ、こんなことやったよね」と、振り返られる資料にしておこうと思います。なんせ、次の本の話もいただいてますし！

もしこのページを読んで「こんな本を出版したいんだけど・・・書いてくれそうな人を探している」などの企画をお持ちの出版社さんがいらっしゃいましたら、ぜひお問い合わせください。

参考リンク

著者:bouya Imamura