こんばんは。よりデザイン の @ryo_pan です。

運が良いことに、自分はこれまで1冊の単著と2冊の共著を書かせて頂くという機会に恵まれました。もともと文章を書くのは好きでしたが、本を書いて出すという経験によって、ブログ記事とはまた違った知見を得ることができました。

https://yory.design/work/sketchbook/

昨年とあるイベントで「デザインツール系の書籍を書く時に知っておくといいこと」というLTをしたところ、一部の人にウケがよかったみたいなので少し内容を補足してご紹介します。デザインツールのみならず、文章を書くうえで自分が気をつけていることも折り混ぜていますので、執筆予定ないよ！な方でも何かしら参考になるのではと思います。

本を書く前に

なぜ出版するのか？
技術系の本の場合、紙の本で出すということには様々な制約が付きます。まずはアップデートの問題。校了直後に対象ソフトがメジャーアップデート、という悲劇は多くの著者さんが経験あると思います。電子書籍であれば継続的なアップデートも可能です。オンライン上であればGIFアニメや動画を使うことで理解しやすい構成で提供することも可能ですし、参考資料やリンクもその場でアクセスしてもらうことができます。なぜ、わざわざ紙の本なのか？については著者と編集者さんとの間でしっかり認識合わせができるとよいです。
ちなみにSketch本の場合は「まだ日本語で書かれた（紙の）書籍がないのでレファレンス本として需要がありそう。英語の情報を自分で集めて読んでる人も多数ではないし。アップデートについては仕方なし」といった感じだったと記憶しています。

目的を決める
これから書く本は何を目的とするのか、を決めるのはとても大切なことです。まずはざっくり、広く浅く・初学者向けなのか、狭く深く・経験者向けなのかだけでも決められるとよいでしょう。もう少し踏み込んで「この本を読み終えた人にどういう変化が起こるとよいか」まで設定できるとグッドです。Sketch本では初学者向けに、ほんとに基本の基本から丁寧に解説しつつ、後半にいくにしたがって実践的な内容を提供する、という、まぁありがちな流れを想定して書きました。あと個人的にやりたかったことの1つに「Sketchを導入したいけど上司の説得に苦労している人」の助けになれたらいいなという想いがあって、巻末に有名企業さんの導入事例コーナーを設けさせてもらいました。あれにはもちろん「他社事例について知ることができる」という役割もあったのですが、それ以上に「ヤフーや日産やメルカリもSketch使ってるんですよ！」という説得材料に使ってもらえたら、という想いを込めていました。

読者を決める
上述の「目的を決める」とほぼ同じですが、ターゲットとなる読者層の明文化はしたほうがよいです。興味はあるけどほとんど触ったことがない人なのか、使っているけど基本機能しか知らない人なのか、業務でバリバリ使っている人なのか。ディレクターなのかエンジニアなのかデザイナーなのか。目的と読者の像が定まってくると、構成やタイトル、あるいは売り方なども具体的に決められるようになります。

ここまでの内容は著者がゼロから考えるというよりは、編集さんから骨子の提案があって、それに著者側も肉付けをしながら形作っていくような流れになると思います。

執筆を進める時

あらかじめ章を分解しておく
自分の場合、章立ての作成と同時に各章で何を書くかをあらかじめ列記しておきます。Sketch本のもとになったWPJさんの連載では連載前に↓のメモを残しています。今の自分だったらそれぞれの内容についてもう少し細かく書くかな……。

用語を統一する
これはある程度書き進めてからでも大丈夫ですが、用語の統一を事前にやると後がラクです。特にSketchのようなインターフェイスが英語のソフトウェアの場合、オリジナルに則るべきか、日本の読者向けに翻訳するべきか悩みどころです。Sketch本では校了直前まで英語で統一していましたが、最終的にカタカナ語に変更しました。

ベターにやるなら原稿のやりとりはGoogleドキュメント
WPJさんの時におすすめされたのもあり、Sketch本の原稿のやりとりはGoogleドキュメント上でおこないました。コメントと提案機能のおかげで編集さんとのやりとりはかなりスムーズになりました。もちろんもっと高度で効率的なやり方もあると思いますが、お互い慣れてないと学習コストもかかるので、まずはGoogleドキュメントを試すとよいと思いました。↓は実際に編集さんから提案があった時のスクショ。

自分の言葉癖を見つける
1章〜2章ほど書いて編集さんとやりとりすると、修正提案の傾向が分かってきます。自分の場合、特に言葉遣いに譲れないものはないので、それまでの提案傾向をベースに次章以降はなるべく修正が出ないテキストを目指しました（できたとは言っていない）。
あと、2章くらい書くと文字数が2万字近くになるので自分自身の言葉の癖がわかってきます。自分の場合は

・〜することができます。
・〜です。 or 〜でした。を3回以上連続で使う
・〜思います。
・という〜
・ものです。
・ことです。

を極力避けたほうが読みやすいテキストになると気付いてから、以後気をつけるようにしています。
さてここでネタばらし。実はこの記事、ここまでの文体をわざと↑の傾向が出るように手を加えて書いていました。どうでしょう、読みづらかったですか？笑

特に「もの」「こと」が残っている時は他の言い回しができたり削除できるサインだと思いながらチェックするように心がけています。「という」も冗長なのでよく削ります。それでも出る時は出ちゃいますが。「〜です or 〜でした の連続」は完全に自分の好みで、黙読しててリズムが気持ち悪いので、です と でしたの使いどころに気をつけつつ2〜3種類の文末表現を混ぜています。

そのほか自分の癖としては

・「ですが」を使いがち
・「少し」「ちょっと」が多い
・括弧で補足しすぎ

の傾向があるなーと感じていて、ブログ書く時はなるべき出さないように気をつけています。とは言え全部チェックして修正すると、それはそれで平易な言葉になってしまう可能性もあるため、どこまでを個性と設定するかは難しいところですね。

できるだけ言い切りで。必要に応じて調査も。
先日こばかなさんのツイートを見て「わかる〜〜〜」と心の中で100回くらい頷きましたが、言い切りではない文章には不安感が宿ってしまいます。

特にツール系は著者の想像ではなく実際にモノがありますから、基本は言い切りで終えられるとよいです。私見を述べる時は「思います」をたくさん使いたくなりますが、そういう場合は最初に「今から書くのは自分の経験則であって全ての状況に適合するわけじゃないからね」と断りを入れてから言い切り型を使えると、違和感の少ない文章になります。

Sketch本ではあまり苦労はなかったのですが、むかーし書いたWindows 8本やiOS 7本ではタイポグラフィや色彩への言及をしていたので関連資料をたくさん買い込んだ思い出があります。軽い気持ちで「ミニマルなWebデザインは昔から存在しており〜〜〜」と書いてしまったがためにWeb Designingを創刊号から買い集め、いつからミニマルデザインぽいWebサイトが載っているかを調べた、なんてこともありました。あれは大変だったけど楽しかった……

調査段階でアクセスしたWebページのURLは必ず保管する
執筆前の調査段階で資料になりそうなWebページを見て回る場合、とりあえずURLをメモに残すことをおすすめします。いつどこで見返すかわかりませんし、特に検索から偶然辿り着いたページはどういう単語で検索したか忘れてるので、再び見つけるのが難しいです。
参考URLがまとまったリストってそれだけで価値があるので、記事のネタに使えたりもします。

原稿用のデータを作る時

フォルダで管理
わざわざ書くほどのことでもありませんが、画像データは章・節でフォルダを分けて管理するとラクです。

スクリーンショットの撮り方
まず基本的な設定として、ウィンドウの影は非表示にしておきます。

https://book.mynavi.jp/macfan/detail_summary/id=78208

あとマウスオーバー時のスクショを撮れるように、時間差の撮影ができるようにしておくと便利です。自分はAutomatorを使ってキーボードショートカットに割り当てています。

https://do-zan.com/mac-screenshot-timer/

ちょっとやっかいなのが、スクショを撮る時のウィンドウの状態。例えばメニューバーを含む・含まないを考えないまま進めてしまうと、ページ間での整合性が取れなくなり不格好になってしまいます。また、撮影するサイズが固定で楽だからという理由でフルスクリーンモードにしていると、メニューバーを表示したい時にツールバーが下がってしまい、見えに違いが出てしまいます。

個人的にはメニューバーとアプリケーションウィンドウ間の溝があまり好きではないので、基本はアプリケーションウィンドウのみとしました。

その他の注意点としては、パネルなど幅を変えられる部分を無闇に触るとページごとにバラバラになる、メニューバーを含む時は右側の情報の内容に気を使う（自分はBartenderで隠しました）、などがあります。

データは上書きせずに全過程を残す&しっかり整理
例えばAからBへの状態変化を作りたい時、ついつい「Aの状態で画面書き出し→そのままBの状態に変えて画面書き出し」とやってしまいがちですが、それではBの状態しか残らないため、あとあと修正が発生した時に泣きを見ます。また、とりあえずで画面を作ってしまうとデータがカオスになり、これもまた泣きを見ます。自分は泣きを見ました。

ちゃんと章ごとにページを分けてデータを整理しておけばこんなことには……

その後に作り始めたデータが上記。いちおう章ごとにページを分けてはいるがアートボードが汚い……

あと、不可抗力パターンとして執筆中にソフトウェアがメジャーアップデートしてインターフェイスが一新、データ全部作り直し・スクショ撮り直しという事態も起こり得ます。これはもうどうしようもないので、がんばって作り直すしかないです。

完成に向けて

自分の考えをどこまで入れるか
ついつい筆が乗ると自分の思いの丈を熱く書いちゃうこと、ありますよね。ツール系の書籍だと、さじ加減をどうしようか迷ってしまいます。できることなら自分の考えも述べたい。でもバランスを間違えるとエゴイスティックなツール本になってしまう。
そんな時は……まずは全部書ききって、最終的には編集さんにジャッジしてもらうのも1つのやり方だと思います。実際、Sketch本でもAtomic Designに関連する節はいち個人の意見としての側面が強かったため、ページ数を削減する段階でまるっと消そうとしたのですが、編集さんからの助言もあって残すことになりました。自分で書いたものを客観的に判断するのも難しいので、そういった意見は助かります。

自分だけの楽しみを持つ
今は慣れてきましたが、執筆を始めた頃は〆切に追われ必要な文字数も多く、しかも業務と兼務だし……となかなかしんどかったです。そのしんどさを少しでも埋めようと自分なりに工夫したのが「自分にだけ分かる小ネタを仕込む」でした。具体的には、我が家の家主🐱に登場してもらったのです。

この工夫により、執筆中のしんどさを和らげることに成功しました。猫は偉大。
ほかにもサンプルアプリを自分の趣味全開にしたりとか。やりすぎない程度に、自分が書いてて楽しくなる仕掛けを考えるのも大切だと思います。

SNSの力を借りる
Sketch本のサポートサイトは最初からFacebookページを考えていました。ある程度バージョンアップに対応したサポートは提供したいと考えていましたし、発売前から情報を小出しにすることで興味を持ち続けてもらうにはFBページが最適だと考えていたからです。

https://www.facebook.com/bnn.sketch/

おかげさまで、一時期はAmazonのデザインカテゴリやグラフィックスアプリケーションカテゴリで1位になりました。嬉しい。

というわけで、以上、自分が執筆を経験して学んだことでした。使えそうなテクニックや考え方があれば、ぜひ使ってやってください。自分もまだまだ勉強中の身なので、ほかの方の工夫している点など知れたら嬉しいです。

次は執筆だけじゃなくて装丁もやってみたいな。。