リリース後の運用のことまで書かれているSwift技術本は今までになかった」という、好意的な評価を見聞きする機会が多くありまして、大変嬉しく思っています。やったね!プログラミングだけではなくて「開発とは何か、プロジェクト管理とは何か・・・みたいな、全体像を捉えたい方もいるはずだよね」という考えでこの本に携わっていたので、とてもありがたい反響だなぁと思っています。「現場のためのSwift4」については、以下のページをご参考ください。APIを使ったニュースアプリの作成を通じて「開発の全体像」が学べる一冊ですこのページをみる出版までに経験したことをまとめましたところで「現場のためのSwift4」が出版されるまでに得た知識や技術はとても勉強になることも多くて、今後に活かせそうなことばかりでした。いい機会なので、私が出版までに経験したことをこのページにまとめました。いえ、本の内容はもちろん出版社さんによって進行のルールは違うと思いますので「これが正解だ!」というのではなく、あくまで「私の場合はこんな感じで出版までたどり着いたよ〜」という一例として書いています。「本が出版されるまでにどんなことをするんだろ?」という、興味をお持ちの方がいらっしゃいましたら、ご覧いただけますと幸いです。企画がスタートたぶん、よくある流れなら「こんな本を出版しよう」という「企画」が出版社さんなり、著者が直接持ち込むなり、何らかの形で浮上するのではないかと想像しますが、ある日、筋肉自慢をする人から「Swiftに関する本を書いてみませんか」というお話をいただきました。「企画はある程度固まっている」という状態ですね。「どう関わることができるか」を考えました当時、私のSwiftに関する知識や技術と言えば、入門書を読んで外部APIを使ってサンプルアプリを作れる程度でした。私はウェブサイト制作やシステム開発のマネジメントやディレクションなどを日々業務として行なっているため「開発の全体像について」や「プロジェクトの進行管理」などは、現場や言語を越えて共有できる知識や技術があるはず・・・ということで、出版の企画に参加させていただきました。対象読者層を意識しながら「章立て」する巷の技術書では、本の内容ごとにいくつかの章にわけて書かれていることが多いと思います。「現場のためのSwift4」も例にならって「具体的に書く内容」を決めて「章立て」することになりました。開発の全体像を中心に、書く内容を洗い出して「章立て」をしました。「章立て」が済んだ後は「テスト原稿を書きましょう!」という出版社さんの進行に従い、1章から原稿を書き始めました。テスト原稿とは?原稿を全て書き終えることを、一般的に「脱稿」と呼びますが、テスト原稿とは「脱稿前の仮の原稿」のことです。テスト原稿は出版社さんに提出して、以下のようなチェックや指示をいただきます。)各章の文章量のバランス上記の中でも「文章量のバランス」については少し悩みました。他の章と比べて「多すぎる文章は他の章に分ける」「少ない文章は膨らましたり、他の章に含めてしまう」など、文章量に気をつける必要があることを、この時初めて知りました。原稿のクオリティを上げるテスト原稿を書き終えたら、次は「脱稿」に向けて原稿のクオリティを上げる必要がありました。テスト原稿の時点では、出版社さんから文章の「内容」についての指摘はほぼありませんでした。出版社さんからの指摘がないのも当然で「現場のためのSwift4」は技術本なので、開発全体のことやSwiftの知識や技術などがわからないと指摘のしようがありませんね。そりゃそうだ・・・というわけで「クオリティを上げる」作業のほとんどは著者側で行う必要がありました。「クオリティを上げる」とはここで「クオリティを上げる」ことについて定義したいと思います。単純なことですが「クオリティを上げる」とは、主に「より正確に、伝わりやすく仕上げること」ではないかと思います。文章コードイラストなどの正確さ、伝わりやすさの向上を図ることが、クオリティを上げることにつながると考えました。「クオリティを上げる」の定義も確認したところで、以下に挙げたような「編集」を数回繰り返しました。脱稿に向けて原稿を見直していくうちに「ちょっと内容を変えたいなぁ」という箇所がいくつかでてきました。その際、原稿の内容に合わせるため、章や節を編集しました。目次をパッと見たときに、章や節だけである程度書かれている内容を把握できるように編集しました。文章の前後関係って大事ですよね。「『A』の話題で読み進めていたのに、いきなり『B』の話題に変わってしまった」など、急に話題が変わると読者に疑問を与えてしまいますね。「この文章、前後の文章と何か関連があるのかな」という、本の内容とは別のところで考え込んでしまい、頭に入ってこない状況もあると思います。そのような状況を解消するため、文章のつながりを入れるよう編集を行いました。「そんなこと、学生時代に習う基本的なことだよ」と思われるかもしれませんが、全くその通りだと思います。つながりが「ある」文章と「ない」文章とでは、読みやすさが全然違うということは広く知れ渡っている事実のはずなので、つながりが「ない」文章のよみづらさを極力減らすことに努めました。「書くのはブログではなく、本だよね」という原点に立ち返って、言い回しなどを見直しました。ブログっぽい書き方を活かす形で、あえて出版する本もあると思いますが「現場のためのSwift4」の対象読者を想像すると、一般的な技術書にならった書き方のほうがいいだろう、という考えのもと編集しました。・「こそあど言葉」を編集こそあど言葉って、便利なのでついつい使ってしまいがちなのですが「何を指しているのか」をぼんやりとさせてしまう傾向があります。これそれあれどれという指示代名詞を極力つかわないように、具体的な文章に置き換えました。・「曖昧な表現」は可能な限り言い切るだと思うかもしれないなど曖昧な表現は「正解が1つしかない物事」に対してつかう言葉としては適切ではないので、読者の方に不安感を与えてしまいますね。曖昧な表現は、可能な限り言い切るように編集しました。すべて言い切る必要はなく、例えば、未来の予測について書くのであれば「だと思う」や「かもしれない」などの曖昧な表現を使ってもいい、というルールを設けて編集しました。・カコミに見出しをつける本書中には「設定手順」や「チェックリスト」など、リスト形式で解説している箇所がいくつかあります。この箇所を、パッと本を開いた瞬間に「何について書かれているのか」わかりやすくするため、見出しを入れました。本書中にサンプルコードを載せているのですが、コードを読みやすくするため、コメントを入れたり色分けをしました。本に掲載してあるコードを「そのままコピペして」動くかどうか、シミュレーターと実機それぞれで確認しました。本書にも解説がありますが、カメラ機能などシミュレーターで動かない機能もあるため、実機での確認は必須ですね。本書中のビジネスロードマップなどの表や挿絵などは、出版社さんにイラストの作成をお願いしました。お願いする際には、下の画像のようにラフで絵を描き「こんな感じで作成してほしい」という要望も添えました。すると、出版社さんがいい感じに作成してくれます。細かく書けばもっとたくさんあるのですが、上記の編集作業を数回繰り返すことでクオリティを徐々に上げていきました。どれも1つずつ見れば単純な作業ですが、600ページものボリュームに対して繰り返し作業を行ったので、かなりの作業量がありました。そのため、上記の編集作業を経て「脱稿しました!」と言いたいところですが「現場のためのSwift4」は、作業の進行上の都合で次の工程のゲラチェックまで編集作業を一部持ち込むことになりました(出版社の秀和システムさん、本当にありがとうございました)。ゲラチェック脱稿した原稿は、ゲラ(または「校正紙」とも呼ばれる)となって著者に渡されます。この時、著者側でゲラのチェックを行い、誤字・脱字などがあれば修正を出版社さんに依頼します。修正されたゲラを受け取り、再度チェック・・・という作業を数回繰り返して原稿を完成させます。ゲラチェックの回数は、出版社さんや進行状況によって変動すると思います。先ほども書きましたが、ゲラチェックの段階で編集作業が一部残っていたので、編集とゲラチェックを並行して行う必要がありました。ページ調整ページ数や本のサイズなどは「章立て」をした段階で出版社さん側でおおよそ決められます。ゲラチェックの工程に差し掛かるあたりで最終的な本のページ数が見えてくるので、決められたページ数を超えてしまった場合は、章や節の一部をカットする必要があります。「現場のためのSwift4」も、カットした章や節がいくつかあります(カットしても500ページ超えの大変なボリュームの本になりました)。その他の原稿の作成はじめに、あとがき、著者紹介の文章を書きました。下の画像は「はじめに」の一部です。「こんなことを考えながら本を読んで欲しいな」と思って書きました〜。書店で本書を見つけた際には、パラパラっとめくって見ていただけると嬉しいです。本書中に載せているサンプルコードをダウンロードして読者の方が動作確認ができるよう、配布用のサンプルプログラムを作成しました。サンプルプログラムを動作させる際に必要な設定などを解説したReadmeファイルも作成しました。申し訳ないのですが、ゲラチェックの時点では見つけられなかった誤字や間違いがありましたので、正誤表を作成し、出版社さんのサポートサイトで閲覧できるようにしました。本書の販促用にポップを作成しました。私は「気持ちのこもったポップにしたいな〜」と思い、手書きと印刷用の2パターンを作成しました。ポップについては以下のページに詳細を書きましたので、ご参考ください。実務で『本当』に通用する開発者になるための教科書」の「イラスト入りPOP」を書店にお願いして置いてもらう旅に行ってきますこのページをみる書店へ挨拶ポップを持って、例の筋肉自慢の人と数店舗周ってレクチャーしてもらい、あとは一人で池袋、渋谷、新宿などの都内、私の地元の富山、出張先の大阪の大型書店を中心に周りました。ブックファースト新宿店に来ました〜。2018年5月24日まとめ「現場のためのSwift4」に携わることで、出版までの流れはおおよそ掴むことができました。勢いで大まかに覚えていることを書いたので、今後は随時このページを更新して、細かい付け足しなどをしながら「ああ、こんなことやったよね」と、振り返られる資料にしておこうと思います。次の本の話もいただいてますし!もしこのページを読んで「こんな本を出版したいんだけど・・・書いてくれそうな人を探している」などの企画をお持ちの出版社さんがいらっしゃいましたら、ぜひお問い合わせください。2016年から株式会社AnimaGateの代表をやっています。ついての話題を中心にこのブログを書いています。ブログの更新情報はFacebook,RSS,Feedly,メールマガジンで配信しています。ウェブサイト制作などのご相談・ご依頼はお問い合わせページよりお寄せください。ブロックエディターの基本的な使い方、イベントでの登壇&参加した感想などを動画で随時公開しています。始めたばかりですが、ぜひご覧いただけますと幸いです。テーマの販売を開始しました。コードを書かずに「コンテンツ作成」に集中できる、見た目のかっこよさにもこだわったテーマです。NishikiWordPressはブログだけではなく、様々なジャンルのウェブサイトに使うことができます。公式サイトで無料配布中です。パソコン操作が苦手な方、ウェブに関する知識・経験が少ない方でも、直感的に操作してウェブサイトを作ることができます。使用して「コードを全く書かずに運営してみよう」ということで「コード書かない縛り」で好きなゲームを題材にしたウェブサイト「ゲームスパイダー」を作りました。ウェブサイトをみる「月額制+チケット制」でサポートする会員制サービスがオープンしました。WordPressテーマやプラグインなど、作ったものをサポートをするための会員制ウェブサイト「サポトピア」を公開しました。使い方がわからない場合は、ぜひ活用してください。質問も受け付けています。トップページ最近の投稿が物足りない方は最新記事の隣にアイキャッチ(サムネイル)をつけられるWordPressプラグインをWordPress.orgで無料で配布中です。画像は人の目につきやすいですね。導入方法は、専用ページをご参考ください。プラグイン専用ページ※バージョン1.3.1より、PHP5.3以上で動作するように変更しました。動かない!という方は専用ページで解決方法をご案内しています。目次コメントこのページについてコメントする返信をキャンセルする。コメントをキャンセルメールアドレスが公開されることはありません。processed.お名前,メールアドレスが仮のものですとコメントが反映されない場合があります検索ワード入力IndexWeb全般Web制作/Webサービス/効率化などに関するページです。日常生活でおもしろい、おいしいなど感じたことを書いているページです。活動報告Web制作実績/自作サービスの紹介に関するページです。ソーシャルメディアTwitter/Facebook/Google+などに関するページです。サーバー構築このブログを始めるきっかけになったサーバー構築に関するページです。行ってきた美術館に関するページです。TシャツかっこいいTシャツはデザインの参考になります。昔集めていたTシャツに関するページです。地元富山や現在住んでいる東京都北区周辺の地域情報に関するページです。今村だけがよくわかるブログお問い合わせ。