こんにちは(U・ω・U)
AWS事業部の深澤です。

表題の通り、社内勉強会にて「書く技術」というタイトルで登壇しましたので、資料を公開します。

資料

どんな勉強会だったか

こちらの勉強会は先日、自分が「AWSの知識地図」という本を出版しましたので、それに併せて社内で開催いただいた勉強会で著者が本書の内容や執筆時に意識したポイントについて話しました。自分はクラスメソッドに入社してから本書を含め5冊の執筆をさせていただきましたので、そんな執筆活動を応援いただいた関係者の皆様への感謝も込めて、「書く技術」というタイトルで発表しました。

書く技術

自分が執筆をする際に意識しているポイントは以下の4つです。

• ストーリーを意識する
• なるべく幅広く触れる
• 他の章との連携を意識する
• 毎日書く

ストーリーを意識する

執筆を始めるときに一番最初に行う作業がこちらです。今回の執筆を通して読者に何を伝えたいか、どんなストーリーで語りたいかをイメージします。イメージは箇条書きで書いたり、こちらの資料のようにブロックのようにして書いたりしても大丈夫です。ぼんやりとしたイメージで執筆だけに没頭してしまうと、途中で自分が何を書いているのか分からなくなってしまうのでこの方法で自分はいつも執筆を始めています。

なるべく幅広く触れる

執筆ではテーマがある程度絞られていますが、その中でもなるべく幅広いコンテンツ（技術）に触れて読者に多くの情報を伝えられるようにというのを自分は意識しています。例えば、AWSの知識地図では2章を執筆させていただいたのですが、2章ではAWS CLIでのハンズオンがメインとなっています。淡々とAWS CLIのコマンドを紹介するだけではなく、それにまつわる幅広い技術に触れることを意識しました。場合によっては説明が嵩んでしまって、ハンズオンの流れを遮ってしまいそうなものに関しては詳しく紹介しているブログのURLを紹介したり、余談のようなものはコラムに回すことを意識しました。

他の章との連携を意識する

自分の執筆している章に集中してしまうと他の章との連携は疎かになってしまいがちです。しかし読者からすると、全体が成果物となるので他の章との連携は意識しましょう。例えばAWSの知識地図では2章では紹介しきれない内容や2章を読み進める前提を他の章にカバーしていただいたりしました。

毎日書く

これは本当に大切です。週末にまとめて書こうという発想になってしまいがちなのですが、執筆は本当に体力を消耗するので一度に書ける量は個人差はあれど限界があります。また、個人的な経験ではありますが膨大な量の執筆をしていると当初紹介したストーリーがブレはじめます。書いている途中で、重複している内容を書いていることに気がついたり、前段で紹介したものをうまく踏襲できずに進めてしまうということがありました。執筆を始めて気がつくようなこともあり手戻りになることもよくあります。執筆は最低でも1万文字は執筆するので計画的な執筆をするのが吉です。目安としては1日1000文字を目安にすると良いと思います。

この1日1000字を目指すにあたり、順番はあまり意識しなくていいかなというのが個人的な考えです。文のまとまりごとにブロックに分けて、先ほど紹介したストーリーにブロックを当てはめていくのがいいと思います。もし共同執筆者がいる場合にはこうしたブロックに分けることで作業分担もやりやすくなります。AWSの知識地図の2章では洲崎さんと執筆したのですが、お互いに執筆箇所を分担することによってかなり進めやすかったです。

最後に

まさか自分のエンジニア人生でこんなにも執筆をさせていただく機会に恵まれるとは思いませんでした。こういう機会に今までの執筆経験で培ったノウハウをアウトプットできて本当によかったと思います。最後に、今までの執筆で自分の力だけで成し遂げたものは一つもなかったです。一緒に書いてくれたり、レビューしてくれたメンバー、貴重な機会をいただいた出版社の皆様、応援してくれるクラスメソッドに感謝し、今後も精進していきたいと思います！！！

以上、深澤（@shun_quartet）でした！