プログラミングも不確かな開発者が単著を出すまでに必要なこと ( ラボブログ )

スパイスラボ神部です。

発売日まであと１５日！となりました Amazon.co.jp： mixiアプリをつくろう!OpenSocialで学ぶソーシャルアプリ: 神部竜二: 本。前回は自分の感想ベースでをまとめてみましたが、今回は自分の経験を踏まえて、いち開発者がどうやって技術系単著を書くまでに至ったかをまとめてみたいと思います。

プログラミングも不確かな開発者が技術系単著を出すために必要なこと

１．ブログを書こう

書籍というのは、自分からのアウトプットを文字にするということです。それが説明の部分であってもコードの部分であっても、とにかく自分の頭の中から外に出すということを普段からやっておく必要があります。アウトプットも訓練ですので、できるだけ毎日やるようにしましょう。

ブログを書くこと自体については既にいろいろノウハウが転がっていると思いますが、やはり書きたい本のテーマ（ここでは技術系とうたっていますので、ソーシャルアプリでもjQueryでもTwitterでもなんでもよいでしょう）に沿って書くのが良いでしょう。毎日アウトプットする練習ならTwitterでもよいでしょうが、それだと人格は認識されていても、「一定の長さの文章を書ける人なのか」ということが認識されません。そういう意味では、Twitterよりもブログをおすすめします。

２．切り口を見やすくし、連絡先を明らかにしよう

漫然とブログを書いていても、それだけでは次につながらないかもしれません。自分が選んだテーマのなかでもどういう立ち位置なのかを考えておく必要があります。自分の場合は、ソーシャルアプリの中でも「自分でアプリを理解してつくれるようになること」「アプリの収益性よりも、ソーシャル性による広がり力を調査すること」がブログの隠れたテーマになっていました。

そうして毎日ブログを更新していると、一定の「テキストの貯金」ができ、それが検索エンジンに認知され、次に人に認知されるようになります。ミクシィの笠原社長もこのブログを読んでくれていると声をかけられたこともありますので、特定カテゴリで一定のポジションを保ったまま、半年や一年あるテーマを継続してやっておくのは大事でしょう。「今はこれが流行りだから」ということで毎週テーマを変えていては、やはりそういった認知にはつながらないでしょう。

また、連絡先を明らかにしておくことも、密かに重要かもしれません。今回私は幸運にもお声がけいただいた立場ですが、連絡をいただいたのは、スパムが来てもいいように公開しているメールアドレス宛でした。すごくいいことを書いているブロガー開発者がいても、連絡先がなかったためにせっかくのチャンスを逃す、ということもなきにもあらずなのかもしれません（※余談ですが公開メールアドレスがきっかけで好条件での転職が決まったこともありました）。

３．書籍の企画を考え、持ち込みしよう

書籍を書こう、というのにはやはり覚悟が必要になるものです。まず、出来るか出来ないか分からないし、売れるのか売れないのかという心配も出てくることでしょう。そのためには、やはり自分の中に企画を持っておくことが必要です。普段から営業しているならともかく、自分のことをアピールしたり自己紹介も兼ねたクレデンシャル資料や自分の書きたい内容を他の人にわかりやすい状態でまとめた企画書を持っておくことが必要です。

自分の場合はあまり大した企画書を用意する前に出版社さんの方から声がかかったので参考にお見せ出来るものはないのですが、既にアポまでとってプレゼンに行く直前だったりはしました。今の世情では新規の企画はなかなか通りにくいと聞いていますが、「あの企画がヒットしているから自分もそれを」という後追いの企画では、苦労の割に十分な成功を収められないかもしれません。そういう意味では、自分だけの企画を通していく方が、その後のモチベーションにもつながるはずです。

書籍のタイトルや表紙デザインについても、企画がとおったあとでよいのでしっかり考える必要があります。やっぱりタイトルや表紙で売れて行くということもありますし、今はAmazonによる事前予約やアフィリエイト展開もあるので、ここはじっくり考えて行きたいところです。書籍タイトルに付いては２０案くらい出したなかから今のものに決まって行ったように記憶しています。

４．書籍の構成を考えよう

かなり重要な「企画を通すこと」の部分を省略しちゃってアレなんですけど、ケースバイスケースという側面もありますので、ご容赦ください。企画が通ったら早速構成を考えましょう。書籍は頭から最後まで読むというのが一般的なので

総論⇒基本⇒応用⇒本格的な応用⇒参考資料

といった構成にするとよいでしょう。

・まず最初に総論でその技術の背景や必要性、未来の可能性などを述べます。ここで読者に逃げられないように、平易な言葉や図を用いて、伝えたいことの価値を理解してもらうことが必要です。

・次に基本部分で技術やサービスの基本部分について述べましょう。おそらく「Hello, World」的なサンプルを書くことになるのではないでしょうか。

・基本を踏まえた上で初めて可能になる応用部分を書いて行きましょう。ここで中だるみしないよう、説明にはアクセントを付けておくとよいかもしれません。

・そして最後に本格的な応用部分を述べましょう。ここには、本書を買った人が最終的に欲しいものについて書いておきましょう。この部分が存在しないと、購入してくれた人の期待を裏切ってしまうことになります。

・書籍の末尾には、参考資料や索引、謝辞などが収まることになります。こちらは出版社の方が作成する部分が多くなるかもしれませんが、読者がその後自分で道を開拓していくためにも、ここは多少集めの方がよいでしょう。索引がない技術書は使いづらいのはよくおわかりいただけると思います。

５．執筆しよう

さて、いよいよ本番の執筆ですが、これに関しては覚悟を決めて走るしかないです。自分の書いているコードが本当に正しいのか？という疑問が常につきまといますが、それを議論するにもまずは土台がないといけませんので、とにかく書いてしまいましょう。

書籍ですのでコードと一緒に文章や図も書いていかなければなりません。自分の作成した構成図にしたがって文章を書き、図を書き、サンプルコードを書き、それを動かしてみて実証し・・・という作業がここから延々と続きます。本の規模にもよりますが、少なくとも１～２ヶ月はかかることでしょう。ここの時間を動やって確保するかというのも執筆にあたっては重要な課題となります。

そして気を付けたいのが著作権の問題です。文章はもとより、プログラミングの部分でも「Googleで検索したものをコピペしてアレンジ」などということはまずできません。たとえばドキュメントそのものに記載されている基本的なライブラリの利用方法があって「これより他に書き方はない」というものであればそれを使わざるを得ませんが、応用部分に関して難しいところほど自分の書き方でやっていく必要があります。

思ったように文章やコードが収まらなかった場合や、結局何箇所かで内容が重複してしまった場合には、構成自体を見直していくことも必要です。さらに、収録内容について商標にかかわるものがあったりなにかしらのサービスに書くことがあれば、その主体と事前に相談をしていくことも必須になります。

６．レビュー・検討をしよう

さて、長期間の執筆が一段落したら、今度はそれをレビューしていくことになります。テキスト面でのチェックや戻しは編集サイドに、コードの検討は必ずしも出版社側でできるとは限らないので、どこかの段階で友人・知人に声かけをしてコードレビューをしてもらう必要があります。この場合、基本的なコード規約や、言語であれば「この言語であればこうあるべき」がわかっている人にお願いをするとよいでしょう。

この際気を付けたいのが情報公開の範囲です。渡しの場合はAmazonに掲載されたときが情報公開のタイミングと一緒になりましたが、それまでは基本的にパブリックにしないよう気を付けていました。ゆーすけべーさんのように執筆段階で宣言される場合もありますし、そのほうがモチベーションに繋がることもありますが、それは出版社サイドの考え方であったり、発表したときのインパクトなどにも影響していきますので、冷静に判断していきましょう。

７．最終的な校正に協力しよう

最後の方になると、PDF などで実際の原稿に近い形での校正原稿があがってきます。この段階では紀保的には著者サイドからの意見ベースではなく、編集サイドでの再構築、最終校正の決定となります。この段階では著者サイドから出来ることはあまりなくなってくるのですが、もし編集サイドからスクリーンショットの取り直しや内容に関する問い合わせなどがあったら即座に対応するようにしましょう。自分の執筆が終わったからといってプライオリティを下げてしまったせいでクオリティも下がってしまったのでは、そこまでの苦労の大部分が水の泡になってしまいます。

また、トピックによっては言語やサービスのバージョンがどんどん上がっていったり、とりあえげている対象に大きな変化が起こってしまうことがあります。どこまで認められるかは不明ですが、そういったことは編集サイドと積極的にシェアしておくことが大事です。場合によっては、最終稿をどうするかということについて合理的な判断につながることもあるかもしれません。

８．書籍のPRをしよう

編集サイドで最終稿が通れば、無事に脱稿です。著者の仕事はほぼ終わりです。まえがきやあとがき、謝辞のスペースががあればこれまでにご協力いただいた皆様について書きましょう。ここ、結構うるうる来てしまう作業です。

出版社サイドではさまざまな販売ルートがありますが、ウェブに関してはAmazonを皮切りに主にソーシャルメディアを通じた展開になります（新刊を出すのでバナー広告や新聞広告を出す、ということはおそらくほとんどないはずです）。それなので、ブログやツイッターなどを通じて、いろいろな施策をやっていくことが必要です。

自分の場合はいままさにこの段階で、はっきりいって右も左もわからない状態です。でも、まずは執筆時と同じように、ひたすらがむしゃらにやってみようと思います。

本に知識をまとめよう

あらためて感じるのは、本を書くということは自分のなかでふわふわしていた知識の雲を、ひとつの知の体系としてしたためることにほかなりません。「今はウェブだけで用が足りるから」と思っている人も多いですし、自分もどちらかとそう思ってしまいがちなのですが、自分の価値観で数百頁をまとめ、それを校正を通じて反復し、より厳密にしていくことは自分の中の知識そのものを磨くことなのだと感じました。

受け取る側もそうやって磨かれた知識の方が実はしっかり受け止めて自分の知見にしていくことができるのではないかと思います。もちろん、ブログでもものすごく質の高いものを書かれる方も多くいますが、それは物書きとしての素性が既に出来上がっているからできることなのかもしれまえん。

単著であるかどうかはこの際関係なく、なんらかの機会で書籍の企画あたれることがあれば、ぜひ執筆に参加されることをおすすめします。ウェブをやっていればやっているほど、自分の知識がリアルな物体にコピーされてたくさん存在するということには、圧倒的な存在感と充実感を感じるはずです。

自分はまだ現物をみたわけではないのでそういった感覚を味わえてはいないのですが、それはおそらくとてもエキサイティングなことなのではないかと思います。