『Ansible構築・運用ガイドブック』が発売されました

どうも、ひよこ大佐です。

11月27日に、拙著『Ansible構築・運用ガイドブック　インフラ自動化のための現場のノウハウ』が出版されました。Amazonやその他書店でお買い求めいただけます。

この本を書いてみて思ったこと

今回、はじめて技術書を、しかも単著で書くことになり、書き始めた当初は想像もしなかったさまざまな苦労や学びがありました。いろいろな方にご迷惑をおかけし、もしかしたら今の自分の能力では書き上げることは無理かもしれないと何度も心が折れそうになりましたが、なんとか実際に本の形となりました。

自分が書き上げたものが、本として皆様のお手元に届けられるようになったことは大変嬉しく思います。今回の記事では、そんな技術書を書き上げるという経験から得られたものを皆様にフィードバックできればと思います。

技術書をどのように書くか

「技術書」と一口に言っても、その内容はさまざまです。製品の使い方を説明したものや、『Infrastructure as Code』のような概念を説明したもの、どちらかというと自己啓発に近い本まで、多種多様なIT技術書が毎月たくさん出版されています。最近では技術書典などで同人誌として技術書を書く方もたくさんいますので、従来の「商業における技術書」と異なる新しい形態の「技術書」もどんどん生み出されています。そのなかで、「どういった技術書にするべきか」は作者の一存に委ねられています。

「Ansible」というトピックにフォーカスしても、「Ansibleそのものの使い方の説明」「Ansibleを組織に導入するための課題の解決」など、いくつもの切り口があります。その中から「どういう本にしたいのか」をしっかりと意識していないと、本当に書きたいものが書けなくなってしまいます。「自分がこの本で何を読者に伝えたいのか」ということを、常に執筆中は意識しておく必要があります。

華美な日本語ではなく、わかりやすさに徹する

もともと大学で4年間クリエイティブライティングという学問を専攻し、「書くこと」について人より向き合ってきたという自負がありましたが、今回1冊の技術書を書くにあたってあらたに学ぶことが沢山ありました。特に「わかりやすい文を書く」という難しさは、技術書を書くうえで何度も直面しました。

※気がついたら大学のページでも私が本を出版したことが紹介されているようです。大学の先生方には在学中大変お世話になりました。 www.tais.ac.jp

日本語は曖昧な言語であるとよく言われますが、曖昧な表現で書き進めていても、書いている本人はそれが曖昧な表現だということに気づけません。筆者の頭の中には書くべき「全体像」があり、それを文章として落とし込む作業をしています。多少意味が通らないような表現や何を指しているかわからない表現があったとしても、自分の書いた文章であれば無意識に補完して読み進めることができてしまいます。私が査読で指摘されるまで全く違和感がないまま書いてしまった曖昧な表現は多々ありました。

小説でももちろん悪文はありますが、ある程度の決まりごとを守っていれば自由に記述することができます。ただ、技術書のような「情報を正確に読み手に伝えるための文章」では、華美なレトリックや独特の言い回しで個性を出そうとするよりも、「読みやすさ」を重視した平易な表現を中心にするほうがより多くの読者に受け入れられやすいものになります。

これはブログなどでも同様で、無意味に思わせぶりな表現だったり、少しかっこつけた文章よりも、誰でも理解できるような文章で書いたもののほうがスッと頭の中に入ってきます。もちろん、どのような表現を使っても筆者の自由ではあるのですが、読みにくい文章はそれだけで「作品」の価値を毀損してしまいます。

技術的な文章をわかりやすく説明するには、「誰がこの文章を読むのか」「何も知らない人がこの文章を読んだ時に、迷うような箇所はないか」というポイントを、原稿を書き終わって一息ついたあとにチェックすることのが重要です。これは自分でチェックするのももちろん有効ですが、もし周りに査読してもらえるようなエンジニアがいれば、他人に一度読んでもらうことで自分では気が付かなかった「不親切」な部分に気づくことができます。

幸い商業出版では日本語のプロフェッショナルである「編集者」の方の協力を得ることができますので、どうしても表現したいことがうまく書けない場合は、編集者と相談しながら進めるのもよいでしょう。

技術書を書くのは、トピックに対する知識も大事なのですが、「わかりやすく書く能力」というのも実は非常に重要です。

技術書における「ストーリー」

技術書はブログ記事と違い、ひとつひとつの章は分離しているようで完全には別れておらず、最初から最後まで繋がっているひとつの「作品」のようなものです。多くの読者が頭から読み始め、最後まで読みすすめていくことを考えると、「本の起承転結」は小説だけでなく技術書であっても重要だと気づかされました。

単純なトピックごとで章を分けるのではなく、前半の問題提起、それに対する「Ansible」という解決策の提示、といった本そのもののストーリーの流れを考えつつ執筆する必要性に気がついたのは、執筆を始めてからしばらく時間が経ってからでした。これは前述した「技術書をどのように書くか」という部分にも繋がってくるのですが、誰かに何かを伝えるには、「伝えたい内容」を明確にしたうえで、それをストーリーとして構築したものを提起しないと、ただ情報を羅列しただけのものになっています。

時間に余裕などない

初めての技術書ですし、できるだけ詳しいものを書こうとしていたのですが、とにかく時間がありませんでした。よりよいものを作ろうとするあまり締切に終われ、結果編集の方や査読に協力いただいた方にも多大なご迷惑をかけてしまいました。今回の執筆でもっとも反省するべきところです。

「もっと時間があれば」と今でも考えますが、仮にもう1年あったとしても、まったく同じことを思うでしょう。出版までの時間は有限で、趣味で書いているものではない以上、どこかのポイントで「完成」とすべきなのです。ですので、「限られた期限でどこまで書けるか」という想定を書き始める前から持っておかないと、延々と完成しない文章をひたすら書き続けることになってしまいます。

最後に

技術書典などが盛り上がりを見せる昨今、「技術書を書く」ことは特別なものではなくなってきました。多くの人がより技術について文章で説明する能力を求められることが多くなってくるでしょう。ただ、技術書を書くのは本当に楽しいことです。私もあれだけしんどいと思いながら原稿を書いていたのですが、一息ついたらまたなにか本を書きたいと思うようになっていました(出版社の方、ご連絡お待ちしております)。

来年の「技術書典８」もエントリーしていますので、こういった「技術を文章で説明する」ことをライフワークとして継続的にやっていければいいなと思っています。