ソフトウェアエンジニアのための文章技術目次出しをする編

こんにちは。りまりま団のもふもふです。

もう、申し込みはすみましたか？

申し込みされたあなた、本を書くにはまず「内容」を考えなければいけませんね。申し込み時は概要こそ決まっているものの、いざ筆を取ろうとすると「書けない…っ！」と固まってしまう人は多いものです。回避するためには書き始める前にどんな論理構成で書くか決める＝目次をだすが重要です。

まだ1月？早割で入稿して印刷費を抑えるためには大体3月の第3週あたりで入稿する必要があります。もう2ヶ月あるかないかですよ。原稿を書き慣れていない人、早めに動きましょう。

ちなみにもふもふちゃんは新刊を3つ出そうとしているので、もう原稿をはじめています。末期症状ですね。

いきなり結論

次の通りに進めれば、目次ができてゴールが見えてきます。

ブレインストーミングという技法をご存知でしょうか。

ブレインストーミング(brainstorming)とは、数名毎のチーム内で1つのテーマに対しお互いに意見を出し合う事で沢山のアイディアを生産し問題の解決に結び付ける創造性開発技法の事をいいます。

同人誌を作る際は、1人またはサークルのメンバーでやることになるかと思います。

専用のアプリケーションを使うもよし、ツールを使うもよし、箇条書きでMarkdownを作るもよしと何でも良いのですが、大事なことが1点あります。それは、思いついたことをしっかりと出すことです。

文章を書き出せない人は「このネタは別の人とかぶるかも」「正しくないかも」「こんなものみんな知っているからな」と、アイデアを捨ててしまう傾向があります。いますぐやめましょう。 正しい/正しくないは後で考える。これが重要です。

思いついたアイデアはあとで精査すれば良いからです。付箋を使ってアイデア出しをしておくと、精査がしやすいです。技術同人誌を書くのがはじめての人は付箋を使ってアイデア出しをすると良いでしょう。

仲間わけをする基準はあなたの書きたいことによりますが、一例をあげておきます。『Elastic Stackで作るBI環境』という本を書いたときを例にあげます（抜粋です）。

だいぶ目次っぽくなってきましたね？一旦言いたいことを出しておいて、並び替える。これだけで何を主張したいのか整理することができます。

仲間のかたまりを一言で表すとなんですか？と聞かれたら、と想像すると良いでしょう。これをそのまま目次として使ってしまうのです。

例えば、

- 環境構築
  - 参照するべきドキュメント
  - 構築手順
  - 動作確認方法

であれば、Elastic Stackの環境構築手順と表現できます。目次はその章の概要を示すことで、「これからどんな話がされますよ」と読者に伝えるためにあります。

「仲間のかたまりを一言で表す」と、目次と内容が違って読みづらい！という失敗を事前に防ぐことができるのです。

このタイミングで各かたまり内のアイデアに話す順番をつけてしまいましょう。こうしておくことでどこから書き始めても論理展開が崩れないのです。

話したいことだけ先にわーっと書いてしまうと、後から読み返したときに論理展開で矛盾が起きやすくなります。書き直しと推敲で時間がかかってしまうため、先に論理の骨組みを組んでおくことが重要です。締め切りがありますからね！

いいですか？できそうですか？

論理を組んだ後は、忘れないように何かに書き起こしておくと良いでしょう。もふもふちゃんは頭で覚えておいて原稿が書けるタイプ¹ですが、TrelloやGitHub issueなどを使って構成を書いておくと良いかもしれません。

ソフトウェアエンジニアのための文章技術では、Trelloを使っています。一例としてリンクを載せておきますので参考にしてみてください。もう少し細かくカードを切ってもいいかもしれませんね。

これで8割は原稿が終わったようなものです！サークル申し込み内容も充実させることができそうですね！