matobaの備忘録

和歌山と東京を往復しつつ活動するエンジニアの記録

トップ > 技術書執筆 > 技術同人誌を書こうと粛々と活動してる話

技術同人誌を書こうと粛々と活動してる話

技術書執筆 技術書典 ソフトウェア開発 執筆活動

技術同人誌を書こうと思っています。

そして、ここでは現状の進捗とか今考えていることを書いておこうと思います。

書こうと思っていること

書こうと思っているのは、仕事をやっている中で僕のやっていた失敗の話。

先日、社内の勉強会で発表した時に評判が良かったのと、「技術書典に出したら？」と言ってくれる人がいた。それで、「なるほどー。失敗談とかを書くのもありなのか」と思った。それがきっかけ。

あとは、Twitterでこんな調査もしてみた。(失敗談というところがウケているのかを知りたかった）

技術書典では、社内で共有した失敗談に対して、同じ軸で項目を追加し、その時の行動や理由、対策や今思うことをまとめようと思っている。

現時点で、目次はとりあえず作ってる。

執筆の計画をした

具体的な執筆に取り掛かる前に計画を行なった。

とりあえず、何時頃に仕上げたいか、仕上げる必要があるか、質を上げるために何をしたいか、必要な調査はあるか、とか考えながら計画した。

あと、これまでの経験上、何も考えずに突っ込んでいくと途中で燃え尽きるのがわかっているので、できるだけそれを避けたいという意図がある。

計画の中でやったこと

計画の中でやったことの話をします。

計画の中でやったことを紹介するのは、意味があると思う。

僕が次に、計画する時に、前は何をやったっけ？というのを思い出すトリガーになるし、他の人に「こんなことを考えながらやってたよ」という風に進められるので。

というわけで、今の所、考えていることをざっくり書いてみます。

執筆活動の価値を整理した

執筆活動の価値を整理した。

なぜ、そんなことをしたかを説明する。

整理した理由

僕の場合、プライベートである程度長い期間が必要なプロジェクトを一人でやると、大抵途中で終わる。

途中で終わる理由は、どんどん夢が膨らんでいって、「なんで、僕はこれやってるんだろ？」と思うことにある。

始めた時は、無駄にモチベーションが高いし、手を動かすのが楽しいので前に進むんだけど、時間が経つにつれてモチベーションが下がる。

僕の経験上、プライベートの活動は、モチベーションを保つのが難しい。

だから、途中で「なんで、僕はこれやってるんだろ？」と思わないように、やる意味（活動の価値）を整理した。

価値整理の方法

こちらの本を参考にして、「価値分析モデル」「要求分析ツリー」というのを考えた。

匠Method: 〜新たな価値観でプロジェクトをデザインするために〜

匠Method: 〜新たな価値観でプロジェクトをデザインするために〜

詳細は書籍を参考にすると良いと思うけど、素早く網羅的に自分がぼんやり考えている活動の価値とその具体的なアクションを洗い出すことができる。

その中で本にして技術書典に出すだけが価値なんじゃなくて、個人の執筆活動で何を考えているかを発信することも価値になる気がする。と思った。

その結果、以下のようなツイートに繋がってる。

いいね、してもらえたということは、多少なり他の人に価値を提供できたのかな、と勝手に思ってる。

そして、もらった「いいね」でモチベーションを回復させながら、前に進んでる。（いいねもらえるのありがたい）

執筆に関する調査

具体的に執筆を進めていく前に、執筆について調査を行なっている。 これは今、取り掛かっているところ。

なぜ、執筆に関する調査をしているかを説明する。

執筆に関する調査をしている理由

調査の一番の目的は、途中で執筆活動に挫折しないため。

というのも僕の個人プロジェクトでモチベーションが下がる一つの要因に調査不足、というのあったことに気づいてきた。（最近ようやく）

調査不足というのが、どういうことかというと、事前に詳しく調査せずに、とりあえず初めてみる、という話。

確かに、事前に調査せずにとりあえず手を動かしてみると、とりあえず何なのかを把握するのは早い。

でも、僕の場合、無謀にも前に進み続ければ何とかなる。みたいな戦略で個人プロジェクトを始めてしまったりしてた。 そうすると、何が起きるかというと、途中で知らないことがどんどん出てくる。

そりゃそうだ。だって、どれくらいそれが難しいのか、どれくらいコストがかかりそうなのか、を調べたり考えずに着手してるから。

要は、覚悟無く着手しているという話であって、途中で挫折しないためには、苦難を乗り越える心の準備が必要。

だから最初の段階で、思い描いているものがどれくらい難しそうか、どんな障壁がありそうか、どれくらい時間がかかりそうか、を把握するのが重要。

そういう話を学んだのを以下の記事に書いた。

blog.mtb-production.info

というわけで、とりあえず、執筆に関する調査をしている。

調査内容

で、とりあえず、下調べしようと思って、関連する本をざっと眺めた。

技術同人誌の話としては、こちら。

技術同人誌を書こう! アウトプットのススメ (技術書典シリーズ(NextPublishing))

技術同人誌を書こう! アウトプットのススメ (技術書典シリーズ(NextPublishing))

技術書のライティングとして、こちら。

はじめての技術書ライティング―IT系技術書を書く前に読む本 (NextPublishing)

はじめての技術書ライティング―IT系技術書を書く前に読む本 (NextPublishing)

それから、ついでに気になったので出版関係の話としてこちら。

ネットと共に成長する出版へ NextPublishingのすすめ

ネットと共に成長する出版へ NextPublishingのすすめ

一つ目だけでもいい気がするけど、僕は色々気になるタイプの人なので、周辺の情報も集めました。

執筆環境の検討

並行して、執筆環境を検討しています。

Sphinxで書いてみたらPDF出力までサクッと行けたので、それで行こうかなと思ってます。

参考にしたのはこちら。

www.oreilly.co.jp

一応、この辺りとかリポジトリとか上記の書籍を参考にしながら、Re:VIEWも検討しました。

note103.hateblo.jp

最初は、RE:VIEWが有名という話を聞いて、そっちの方がいいのかなと思ってたんですが、ネットで検索したところ、RE:VIEWだとしてもハマってる人はいるし、RE:VIEWはRubyベースだからハマったら辛そうだと思いました。（Rubyがどうというより、僕がRubyに慣れていない）

それなら、PythonベースのSphinxの方が自分で解消できそうな気がするなと。 あと、reSTに慣れてるし、結局latexに出力した後はlatexの世界で何とかすることになるような気がしてます。（僕は仕事でPythonを使っている&仕事のドキュメントはreSTで書いている）

終わり

現状の進捗は、こんな感じです。

実際に執筆を開始したらどうなることかわかりませんが...

途中でも書きましたが、を生暖かく見守っていただけるとありがたいです。

あと、そのうちレビューしてもらいたい気持ちになると思うので、レビューしていただける方をゆるく募集しています。

ありがとうございました。