1.1　サークル参加方法

　この本を手にとっているということは、「同人誌」というものの定義、あるいは同人イベントについてはすでにご存知だと思います。ここでは、まだサークル参加はしたことがない、という方に向けてイベントへのサークル参加の概要について触れたいと思います。

　「サークル参加」を一言でいえば、一般参加者から見て机の向こう側、つまり本を売る側になる、ということです。

　まず、サークル参加の大きな流れとしては、

　　１．イベントに申し込みをする（サークルカットを描く、コミケの場合：参加費を支払う）

　　２．当選する（技術書典の場合：参加費を支払う）

　　３．本を作る

　　４．イベント当日に頒布する

といったものです。イベントによって参加規則や要領は若干異なるものの、申し込みにはサークルカットの作成と必要事項の記入が必要になります。必要事項には住所や連絡先の他、作る本のジャンルや持ち込み数、配布価格などを記入することが多いようです。つまり、「どんな本を作り、何部くらい持ち込むのか」については申し込みの段階である程度固めておく必要があります。

　主催者側は、それぞれのサークルカットと搬入予定数を見ながら、会場内での各サークルの配置を決めます。この時、似たような傾向のサークルがまとまって配置されます。コミケなどのカタログを見たことがある方は覚えがあると思いますが、同一ジャンルが固まって配置され、「～島」などと机の列を呼びます。したがって、申込時のデータと配布物が大きく異なると周りから浮く、といったことも起こりえます。

　もちろん、進捗やネタの流行りによって、申し込み時点から配布物が変わる可能性はありますし、浮いたとしても誰かに怒られるわけではありません。書きたいものを書く、その結果としてのサークルカット無視、というのもサークル主の自由ではあります。……とはいうものの、やはり原則として申込時の内容と配布物が全く異なるということはやめたほうがよいでしょう。

　また、搬入数が多いサークルや、これまでの実績から多数の購入者が見込まれ、一般参加者の待機列が長くなりそうな場合に、いわゆる「壁」や「お誕生日席」といった、スペース的に余裕のある場所に配置される可能性が増えます。お誕生日席は島の両端の席、壁は会場外周の席です。比較的大部数の搬入が可能であり、混雑対策が採りやすいことから人気サークルを割り当てることが多く、サークルの人気の指標の一つ、つまりステータスともなります。

　申し込みからしばらくすると当落が発表され、ここでサークル参加できるのかが決定します。当落基準は一般に非公開とされている場合が多いのですが、単純な抽選だけではなく配布物・サークル活動の内容や、そのジャンル全体のサークル数などを考慮して当選サークルが選ばれるようです。例えば同一ジャンルのサークルが多い場合は抽選となります。逆に、当該ジャンルの参加サークルが少なく、そのサークルが落選するとジャンル自体がなくなってしまう場合には当選率が上がる、といった可能性もあるようです。

　なお書類不備、つまり必要事項の記入がなされていない場合は問答無用で落選となる場合が多いようです。最近のイベントはほとんどWebからの申し込みだと思いますので、くれぐれも記入欄が空欄のまま、といったミスは避けましょう。

　当落発表後は、とにかく完成に向けて本を作ります。そして、できた本を頑張って売りましょう。

抽選に落ちたときどうするか

　サークル参加できなくても、友人・知人のサークルに委託するという方法があります。筆者は第一回技術書典の際、知人のサークルに自分の本を委託するついでに、そのサークルのお手伝いをするという形で参加しました。サークル参加した方が色々と都合が良いのは確かですが、サークル参加ではなくても同人誌は出せます。ただし、お金が絡む話ですからお互いの信頼関係は大切にしましょう。（Text:erukiti／佐々木俊介）

1.2　イベント参加のメリット

　イベントに参加する理由は人それぞれです。基本的には、「読者と直接交流できる」という点が大きいのではないかと思います。自分が書いた本が売れていく様をみるのは、やはり気持ちのよいものです。常連さんなどができてくると、本当に「ありがたい……」という気持ちになります。

　他のメリットとしては、出版社の目に留まった本が商業出版になる（この本もその一例ですが）可能性があります。ただこれはテーマ次第の面があります。とはいえ、この本も含まれるインプレスR&Dの「技術書典シリーズ」を始め、同人誌から商業化された書籍も本も増えているので、今後も一定の可能性はあります。

　ただ、同人誌で一山当ててお金を稼ぐ、ということはあまりおすすめできません。同人誌は、コミケでごく一部の大手サークルが頒布するケースを除いてそれほど儲かりません。詳細には後述のお金の項目で触れる内容にもなりますが、こと技術書という分野では一回のイベントでせいぜい100冊～200冊売った場合で5万～10万の売り上げに対し、印刷費、イベント参加費、その他経費を引くと利益はわずかです。さらに執筆時間を考えると、時間あたりの単価はとても低い金額になってしまいます。

　単純にお金を稼ぎたい、ということなら他の金儲けに注力するほうが効率的です。ただ、頒布数という面では、自作の技術書を100冊、200冊というレベルで実績を残すことができるイベントは、コミケと技術書典くらいではないでしょうか。

1.3　コミケと技術書典

　世の中には多数の同人誌即売会が存在します。こと技術書を配布するという観点からは、概ね2つのイベントがメインとなろうかと思います。それが、コミックマーケット（コミケ）¹と技術書典²です。

　コミックマーケットの説明は今更不要かとは思いますが、夏と冬に東京ビックサイトでそれぞれ3日間開催される、世界最大の同人誌即売会です。サークル数は3日間で約3万サークル、参加者は一日あたり約20万人、3日のべ50～60万人の参加者が集う巨大イベントです。

　一般的にコミケはいわゆる二次創作の「薄い本」、あるいはコスプレといったイメージが強いのは事実ですが、実は技術書を扱うサークルがかなりの数存在します。特に、一日目に配置されることが多い「同人ソフト」カテゴリのなかに、自主制作ハードやPC及びIT系評論情報というジャンルがあり、島1本～2本、数十サークルが活動しています。また、三日目になることが多い「評論情報」にも、IT系、あるいは数学や電子工作、その他の技術系のサークルが存在します。

　そしてもう一つのイベントが技術書典です。コミケで壁になることもある技術書の大手サークルTechbooster³が主催する、「技術書のオンリーイベント」（ジャンルが技術書に限定されているイベント）です。2016年6月、2017年4月、2017年10月と過去3回開催され、いずれも大盛況でした。技術書典4は2018年4月22日にサークル数をさらに増やした240サークルに拡大して開催されます。参加者は約3000人ですが、技術書典2と3についてはいずれも暴風雨のなかでのイベント開催ということで、天候に全く恵まれていません。その中での来場者数ですので、天候に恵まれればもっと増えるのではないでしょうか。

技術書典をお奨めします

　技術書を頒布する機会として、現時点ではコミケと技術書典が考えられます。ただ、コミケは会場が広すぎる、参加者が多すぎる、体力を使いすぎる……など、一般参加者、サークル参加者ともにハードルが高めに感じます（筆者の個人的感想です）。

　ですが、技術書典はそこまで体力を使うイベントではありません。また、技術書オンリーイベントであることから、ターゲットが絞られている分頒布しやすい環境です。今後コミケでの頒布を目指すにしても、最初は技術書典からスタートしてみるといいでしょう。コミケはコミケでお祭り感が強く、楽しくパワフルなイベントです。他ジャンルを目当てにした人が来てくれることもあります。サークルとしてのパワーができあがってから参加を考えてもいいでしょう。（Text:erukiti／佐々木俊介）

　さて、技術書典とコミケの参加者層は若干異なる傾向にあるようです。技術書典は基本的には「技術書を買いに」来る人が多いということで、本の値段には余り頓着せず買っていく印象があります。なぜなら、技術同人誌は類書のない（あるいは極めて少ない）最もエッジな内容の本が多いからです。逆にコミケは、自分の好きなジャンルを目当てに来たついでにざっと回る人が目に付きます。

　混雑の時間帯もかなり異なります。コミケでは最初から技術系サークルを狙ってくる人はあまり多くないため、開場直後は比較的暇です。ひとしきり買い物が終わった11時とか12時ごろから人が増え始め、そのまま15時ごろまで満遍なく忙しくなります。一方の技術書典では、開場からいきなり忙しくなり、それが昼過ぎまでずっと続きます。売り切れサークルも出始める中盤から後半になって、ふらっと秋葉原に来た人がイベントに立ち寄る、という雰囲気になります。

所属する組織との関係について

　技術同人誌を執筆する場合、所属する組織で業務として扱っている技術分野を執筆する場合があります。この際、それぞれの所属先の諸規定との関係で所属する組織と調整が必要になる場合があります。

　同人誌を執筆するということは表現の自由に属する事柄のため、一概に「所属先の組織の承認を得るべきである」というわけではありません。

　ここで述べたいのは、「もしその組織が、業務外で執筆活動を行うことに理解がある組織であるなら、その環境を大事にするべき」ということです。

　これは、同人誌を執筆する上で、入稿の直前の時期は、時間外労働のペースを調整したり、場合によっては休暇を取得して作業を行ったりするなどの影響が出る場合があるからです。

　もちろん有給休暇を取得することは法律に定める当然の権利ですが、技術者としての知識・スキルは所属する組織の業務によって得る部分が大半である以上、執筆を行う上で同僚などと良好な関係を持つことが重要なことは言うまでもないでしょう。（Text：setoazusa／大中浩行)

1.4　なぜ本を書くのか

　イベントに参加するには、まず「本を書く」必要があります。同人誌といえば二次創作などが主流ですが、技術同人誌というジャンルに限れば、自分が持っている知見、本業または趣味に関する技術を1冊にまとめることで、技術書という形にします。自分が持っている技術に関する解説であれば、それをうまく切り取ることで世の中に類書のない本を作る元ネタになりえます。

　そして、本を買う側からすれば、どこにも売っていない技術書を手に入れるチャンス。購入する際の価格はあまり判断基準になりません。例えば、断片的にはWebに乗っている内容でも、書籍には載っていないハマりどころについて解説されているとか、「具体的な何かを実装した」など、技術のエッジな部分を探しているときに、それがマッチングできれば即座に購入することになります。また、商業出版に比較して執筆から発行までのスパンが短いため、最新情報を手に入れるチャンスにもなります。

　つまり、執筆者側から見ると、「具体的な何かを実装する」という点にフォーカスした本は参加者の誰かに刺さる可能性が高くなります。もちろんあまりに狭すぎると部数は出なくなりますが。

　個人的意見にはなりますが、商業出版の技術書のように全体を網羅し、抜けなくもれなく、あるいはいろんな環境について併記する必要がないのが同人誌の良いところです。一般的な手順を記載したうえで、「こんなところにハマった」という点を深掘りするほうが書きやすく、また読者に刺さる本ができると考えます。当たり前すぎて商業誌には載ってないけど自分はハマった、という内容は他の人も同じようにハマる可能性があり、解決方法がなかなかみつからないという事があります。「うちの環境ではこんなトラブルがあって、こうやったら解決した」という内容は、十分に同人誌足りえます。

　更に、出版までのタイムスパンが短いという点については、通常の商業出版では企画から出版まで短くて3ヶ月～半年というところを、同人誌は申し込みからイベントまで最長で半年、執筆期間が長くて2ヶ月、短ければ（コピー本など）では、1週間を切っても発行できるのが強みです。

技術同人誌のススメ

　出版業界が縮小傾向の時代なのに、なぜ技術同人誌なのでしょうか？

　それは、Google検索にノイズが溢れる現代において技術書の重要性は年々増す反面、これまでの商業出版では現代の技術の発展速度についていけないからです。技術書を求めるニーズは一定数あっても、発行のタイムスパンなどの問題もあり、商業出版でニーズを満たしきれていません。

　その矛盾を解決できるのが技術同人誌です。ブログよりもまとまった形でその時代にあったエッジを切り取る、そしてそれを求めている人がコミケや技術書典でそれを買うというWIN-WINなエコシステムが生まれています。

　最近はプリントオンデマンド⁴（POD）を商業出版でも取り入れる動きがあり、インプレスR&D⁵がPODと電子書籍で展開しているNextPulishing⁶では、さまざまな旬のエッジな本や、技術書典で頒布された同人誌を底本として商業化した「技術書典シリーズ」を精力的に発行しています。

　書くにせよ、読むにせよ、技術同人誌はIT・出版における最前線なのです。（Text:erukiti／佐々木俊介）

　また、潜在的読者の数が少なく出版されにくい本があるのに対して、同人誌は責任を自分で追うことで、いかなる内容の本であろうと発行可能です。この面で技術同人誌が果たす役割は大きいと考えます。洋書や仕様書しか情報がない技術についての解説本は、とても有益です。そこに刺さる人たちに届けるんだ！という風に考えると執筆する意義を見いだせるかもしれません。

技術同人誌を知らなかった私が技術書典3に出展するまで

　私は技術書典3に出展し、「radiberry pi! 構築手順書」というRaspberry Pi絡みの技術同人誌を頒布しました。ほぼ個人的な話になりますが、そこに至るまでの経緯を記します。

　そもそも私は、技術同人誌というジャンルの本があることをつい最近まで知りませんでした。秋葉原でジャンクパーツを物色した帰り、ふとCOMIC ZINに立ち寄って色々眺めていたところ、棚の一角に技術同人誌が置かれているのを発見。「技術系の同人誌なんてあるんだ！」と驚き、気になったものを片っ端から購入したのが2017年2月の出来事でした。

　家で技術同人誌について調べているうちに、技術書典という即売会の存在を知り、4月に行われる技術書典2に行ってみることになりました。技術書典2に参加して感じたのは、技術同人誌を作成しているサークル参加者が思っているより遥かに多いということでした。イベント直後はRapsberry Piに関する本を中心に色々買えてただ満足していたのですが、色々なブースを巡って本を読んでいるうちに、こう考え始めました。

　「今Raspberry Pi使って遊んでる、ラジオに関する内容で本を書けたりしないかな…？」

　技術書典2の戦利品を消化し終わらないうちに、技術書典3の開催決定がアナウンスされました。参加登録の申込期限まではおよそ1ヶ月半。ただの一参加者でしかなかった私ですが、ここから参加登録を行うべきかどうかを申込期限ギリギリまで悩むことになります。果たして3、4ヶ月先の納期を守れるのかどうか。そもそも、同人誌即売会のお作法を全く知らない状態で参加して大丈夫なものか。

　色々考えた結果、最終的に参加する決め手となったのは、「もし似たテーマの本を別の人が作っているのを見たら絶対に後悔する」と考えたからでした。

　そう思った後に、これまで結構な時間を費やした結果溜まった知見をどうにか形にしたいという考えに至り、参加締め切りの1時間前にようやく参加申し込みを行いました。参加登録から本の作成まで様々なトラブルがありましたが、無事に間に合わせることが出来ました。イベント当日、自分が作った本の束に初めて触れた時の感動は忘れられません。

　この本を読んでいるあなたがもし、技術同人誌の作成に挑戦するか迷っているのであれば、ちょっと想像してみて下さい。「自分が詳しく知っている／前々から目をつけていたテーマを取り上げた技術同人誌を、別の誰かが即売会で頒布している」状況を。

　もし見過ごせないと思ったのなら、是非この本で技術同人誌作成の準備を進めましょう。きっと役に立つはずです。（Text：病葉／木田原 侑）

2.1　ブログだって立派なアウトプット

　エンジニアとして、日々の困ったことについてその解決方法をブログに書くのも、立派なアウトプットです。筆者は元々アウトプットが苦手だったのを克服する一環として技術系ブログを書き始めましたが、それらがたまりにたまっていつの間にか技術同人誌を出すに至りました。

　ちょっとしたブログなら、書くのは簡単です。もし名前を出すのが恥ずかしければ匿名アカウントでもなんでもいいのです。Qiita¹やMedium²やnote.mu³など、発表に適した場はいろいろとあります。Qiitaは技術に強いコミュニティです（技術的ではない記事は削除される可能性があります）。後者2つは技術系以外も多い総合サイトです。

　ブログを1本書けば「ブログを書いた」という実績が自分の中でアンロックされます。おめでとうございます！実績がアンロックされる前とは、きっと違うあなたになっているはずです。ブログを10本書けば「10本ブログを書いた」という実績です。最近のゲーム機では当たり前のように存在する実績システムですが、これは別に架空の概念でもなんでもありません。ブログという形で1つの記事を書き上げるということは、達成するだけで自分に大きな力として返ってくるのです。

　また、ブログ経由で執筆のスカウトメールが届くこともありますし、ライターを目指すなら手っ取り早い手段ではあります。イマドキの編集者は実際にnote.muやMediumをチェックして面白そうな文章を書ける人を探しているのです。

2.2　アウトプットで理解が深まる

　人に教えると理解が進む、という経験をした人はそれなりに多いでしょう。ブログを書くためには、自分の知識を他の人にも通じる共通の言語・概念・ルールを用いて形にしないといけません。最低でも言語化できていなければブログを書けません。人に説明するために、おそらく普通よりも頑張って調べ物をすることもあるでしょう。これらの行程は理解を深める為にはとても有益なものなのです。

　また、自分の書いた記事を未来の自分が参考にすることもあります。備忘録としても優秀です。

2.2.1　書かないと始まらない

作家の結城浩さんが語る「常に書け。現在の自分の最前線を書け」 - Togetterまとめ

https://togetter.com/li/1172094

そして思います。文章は、そのつど書かなきゃ駄目ということを。経験を積んでから、十分学んでから、時間ができてから書くのではない。断じて違う。そのつど書く。自分の不十分さをたっぷり自覚した状態で書く。そうでなければ、いつまでたっても書けやしない。

常に書け。現在の自分の最前線を書け。いまを逃せば、いまの自分は書けない。だから、いま、書くしかないのです。理解も不十分、経験も少ない、世の中もわからない、こんなこと書いたら恥ずかしい、批判がたくさん来るかも。という状態で書くしかない。いまを逃せば、チャンスはない。

　これはほんとにそう思います。下手な時には下手なりに自分の血肉となる何かを残す、というのは重要です。黒歴史を恐れる人もいますが、犯罪行為を除けば黒歴史なんて恥ずかしい（可能性がある）だけの取るに足らないものです。当時の自分の切り口を振り返るというのは、じつは後になって大きな資産になるものなのです。

　書くことに恥ずかしいとか遠慮とかを持っているならば、なんとかその呪縛を壊せばいいのです。よほど個人情報でも晒さない限りMediumとかQiitaでIDを取って記事を書くだけなら、恥ずかしさは少しでも軽減するのではないでしょうか？

2.3　インプット・コンピュート・アウトプットサイクルを刻む

　コンピュータの仕組みは「入力（インプット）」「演算（コンピュート）」「出力（アウトプット）」です。人間も同様ではないでしょうか？情報を入力して、その情報を処理（咀嚼）して、それらを文章やソースコード、あるいは他の作品の形でアウトプットするのです。

2.3.1　バランスが偏ると罠にハマりやすい

　入力に偏ると脳がパンクしてしまいませんか？十分に咀嚼しないと自分のものにはなりません。逆に入力が足りずに頑張ろうとすると、狭い知識で無理矢理ひねり出すような“縛りプレイ”になってしまうこともあります。アウトプットは、入力と咀嚼の両方がそろってはじめて出せるものです。

　入力と咀嚼が足りているとして、アウトプットを怠るとどうなるか？それは偏ったガラパゴス状態になりがちということです。せっかく咀嚼して自分の血肉にした技術でも、アウトプットしなければいつかは腐らせてしまいます。

　つまり、これらの要素はどれも重要なものなのです。

2.3.2　大きなジャンプより小さな一歩

　たとえばソースコードを変更したいとします。このとき、一気に大きな変更を施すと大変なことになりがちです。変更点の把握、それが正しいかどうかの確認、大人数開発であればコミュニケーションコストも馬鹿にできません。プロモーションなんかも絡んでくるでしょう。

　よくプログラミング言語では大きなジャンプをすることがあります。Ruby1.8から2.0, Python2から3, JavaScriptの言語仕様であるES5からECMAScript2015やPHPの5.2から5.3などです。この大きなジャンプの特徴として、互換性の破壊、開発期間の長期化、ユーザーの移行が手間取るなどの問題があります。時間をかければかけるほど大事になりやすいのです。

　個人の作業でもそうです。時間をめいっぱい掛けて大事にするより、小さな一歩を刻んでいく方が自分にとっても理解しやすく、心のハードルも低いものです。

　また大抵のケースでは、1つの大きなサイクルをまわすよりは、小さなサイクルをたくさん回す方が得られる経験値は段違いに多いものです。未完の大作よりはちゃんと完成したものを少しずつ作っていく方が力を得やすいのです。分割統治法とか二分探索とか、エンジニアなら好きな言葉だったりしませんか？

2.3.3　脳みそのはなし

　「やる気」ってどういうものでしょうか？何もやる気が起こらない。よくある現象です。筆者が考える「やる気」は、「何かをやりはじめた時」に出やすいものだと感じています。まずは「何か」きっかけになることに手を付けましょう。エディタを立ち上げる。１行でも書き始める。書きたい記事に必要な要素をリストアップする、などなど何でもいいからはじめてみましょう。始めないと始まりません。やらないとやる気は出ません。少しでも物理的な行動を始めてから考えればいいのです。

　始めるときにお勧めのライフハックがあります。まずプライベートなノート、紙でも電子データでもいいので、そこに自分の考えを話し言葉で書き出してみましょう。ネタは何でもいいです。技術のこと、設計論、人とのコミュニケーションのやりかた、あるいはこれは恥ずかしい、人に見せられない、それらの理由、思ってること、感じたこと、なんでもいいので言葉として書き出してみてください。それだけで少し位心が楽になるものです。いったん書いて形にする事で、脳内に溜まったままのものに決着を付けやすくなります。

　そうしたら、次はどうやって自分の得た技術を本にするかをノートに書き出しながら考えてみてください。きっと次の一歩を踏めるはずです。

2.4　技術同人誌はコストパフォーマンスのよいアウトプット方法である

　一番見返りの大きな「アウトプット」はおそらく商業で本をガッツリ書くことでしょう。編集者の方に色々手伝ってもらいながら一冊の本を書き上げるというのは、得られる経験や知名度、収入などさまざまなメリットがあります。ただ、当然のことながら敷居の高いものではあります。

　そこで同人誌です。技術同人誌は誰でも作って誰でも頒布できます。

　サークルとして参加する際には当落があるので、必ずしもサークルとして参加できるとはかぎりません。でもいざとなれば友人知人のサークルに委託するという手もありますし、BOOTHのようなオンライン販売サイト、ComicZINのような委託可能な書店に委託もできます。

初めて同人誌を書くには

　ネタはある。書く気もある。でもサークル申し込みしていない。さあどうしよう。

　そんなときは、友人知人を捕まえて、委託させてくれ、寄稿させてくれ、と言ってみましょう。うちのサークルの例では、3回ほど寄稿で執筆してくれた人が、今は自分のサークルを持って活動しています。サークル参加している知人がいなければ、ちょっとハードルは上がりますが、もくもく会⁴等で委託・寄稿させてくれる人を探すのもアリです。

　そしていっそのこと、コミケや技術書典に申し込みをするのが一番の近道です。技術書典は、全サークルの2割が初参加（本を書くのが初めて）だそうです。200サークルのうち実に40サークルです。さあ！さあ！さあ！（Text：親方）

2.5　モチベーション

　アウトプットのモチベーションですが、筆者は「欲望」が大きいと思っています。JavaScriptの同人誌を出していますが、これはウェブ上での情報汚染がひどかったので、自分なりにまとめなおしたかったからです。例えば技術書典2で出したModern JavaScriptという本では、ES5という古びた技術が未だにウェブ上では散見される現状に我慢できなかったのです。技術書典3で出した簡単JavaScript AST入門という本は、JavaScriptのもつポテンシャルを高める技術について、どこにも本が出ていなかったことと、ウェブ上でも情報が限られていたからです。

2.5.1　真人間のアドバイスは無視していい

　創作、執筆、そういったものにおいて、足を引っ張るのは（自称）真人間のアドバイスです。執筆にかぎりません。「そんなの金にならない」「まっとうな社会人なら」「年甲斐も無く」「車輪の再発明をするやつは馬鹿だ」「◯◯なんて馬鹿のつかうものだ」など色々な言葉がありますが、そういうたぐいの言葉はほぼ100%無責任で、経験や感情を押しつけるだけのものです。

　あなたが書きたいと思った欲望（モチベーション）を止める人の言葉は、あなたの創作意欲をつぶそうとする有害なものです。

　批判もそうです。現代ではSNSによって批判にあふれかえっています。本や記事を書いたら批判を耳にすることもあるでしょう。そういったものには有用なものもありますが、批判に支配されてはいけません。批判をどう受け止めるのかはあなたの選択です。大抵の場合はスルーすればいいでしょう。どうしても気になる批判であれば、自分の中で咀嚼するか、マインドフルネスするか、まぁ何らかの対処をしましょう。

　あなたが生み出すものを邪魔する権利は他人にはありません。あなたが生み出すはずだったものについて責任を取ってくれる人はこの世に誰一人いません。

2.6　本を書きたくなったら最初に目指すこと

　それは目次の作成です。ある編集者⁵の持論としては「目次が完成したら、その本の半分以上ができたようなものだ」というものです。特に理系の論文の組み立て方やロジカルライティングに通じるものですが、大きなテーマがあって、それを伝えるためにはこれを伝えて、というのを目次という形にします。この目次がしっかりした構成であれば、後はもう中身を書くだけなのです。

　目次が出来たら誰かに見せてみましょう。一番いいのは技術書執筆系の勉強会に参加して、そこらへんにいる編集者を捕まえて「こういう本を書きたいと思って目次を書いてみたんですがどうでしょう？」と聞いてみることです。アドバイスしたがりの人が多いので、きっと本に繋がる有益なアドバイスを受けられるとおもいます。

レビューをお願いしよう

　原稿がだいたいできあがったら、誰かにレビューをお願いしてみましょう。自分では気づきづらい論理構成の破綻、流れが分かりづらいところ、誤解、誤植等を見つけてもらうことができます。

　Twitter等で「こういう本を書いたー。レビュー募集中！お願いします！」とつぶやけば、手を上げてくれる人がいるでしょう。PDFを出力し、Google Document等で共有するのが簡単です。

　レビューに協力してくれる人は、自分の本を心待ちにしている人です。そして、レビューした人は、「こんな面白い本がある。買いに行くぜー」と告知してくれる場合もあるでしょう。

　レビューのお礼は、謝辞に載せる、完成した本を進呈する、等が良いでしょう。

　ただし、レビューをお願いして、その結果を本に反映させるには、入稿締め切りまでに余裕をもたせておく必要があります。レビューをお願いするにあたっての最難関は、その数日の余裕かもしれませんね。（Text:親方）

3.1　全ての事象はネタたりうる

　そもそもネタとは何者なのでしょうか。ここでのネタとは、同人誌の内容そのもののことです。

　同人誌を作ろうと思ったのはいいけれど、何を書いたらいいのかわからない！というあなた。難しく考える必要はありません。自分が持っている技術のタネをうまく切り取り、育てることでネタはいくつも作れます。

　このとき、ネタというのはソフトウェア技術には限りません。技術書典もコミケも、少なからず電子工作勢や、デザイナー勢もいます。技術的な何かでさえあればいいのです。

　ネタはいくつかの区分に分けることができるのです。1つずつ紹介します。

3.1.1　ネタ案その1:技術の紹介

　よく使っていてお気に入りの技術はありませんか？誰かに話したくてたまらないような技術があるならちょうどいい機会です。ぜひとも布教しましょう。その思いをそのまま同人誌にぶつけてください。みんなそういうネタが大好きです。具体例としては、

　　・ある言語のライブラリ紹介

　　・ミドルウェアの使用法とユースケース紹介

　　・運用時に便利なLinuxコマンド集

　　・あまり知られてないけど自分が好きなプログラミング言語の解説

　　・ユニットテスト技法、設計技法、アジャイルテクニック

　　・電子工作・IoTの解説

　などが挙げられます。

　このネタの良いところは、「好き駆動」で同人誌を書き進めることができるという点です。「好き駆動執筆」に勝るものは何もありません。話したいことを全て詰め込めば、それなりのボリュームになるはずです。読んでいる側としても読み応えがあり、新しい分野の知見を深めることができます。

　ただし、紹介系のネタは技術用語と解説の羅列になりやすく、文章が単調になりがちです。技術の紹介とユースケースを織り交ぜて説明することで、読者は自分が使うことを想像しやすくなります。もしかすると、あなたの同人誌のおかげで紹介した技術のユーザーが1人増えるかもしれませんよ。

　マイナーな技術の情報も、求めている人が意外にいるものです。資料がウェブ上で見当たらない、英語の情報しか無い、英語ですら無いような情報。ソースコードを読めば実はわかりやすい、仲間内の暗黙知だけど文章になっていないもの、というような技術はよくあります。それらをあなたの言葉で記事にするだけで十分に同人誌として成立するのです。あなたにとっての当たり前も、他の人にとっては喉から手が出るほどほしいものだったりすることは、よくあります。

3.1.2　ネタ案その2:「困った」を解決した系

　ある技術を使っていた/使おうとしたら“はまって”しまったことや、作った成果物が壊れてしまい慌てて直した経験はありませんか？その苦い知見を共有することで、同じ轍を踏んでしまう人を少なくすることができるかもしれません。これは世界に対する貢献であり、世界平和への第一歩なのです！

　……と大げさに書いてしまいましたが、実はトラブルシュート系のネタを扱う技術同人誌はあまり多くありません。自分が困ったことは、120%他の人も同じように困っています。あなたの知見を世界は待っているのです。

　例えば、

　　・インフラ系の運用知識やトラブルに対する対処法

　　・プログラミング中にエラーが出ても慌てないようにするための知見

　　・Gitトラブルあるあると対処法

　　・ミドルウェアをいかにチューニングして落ちないようにするか

　　・あるAPIにまつわるバッドノウハウ

など、はまりそうなものをトピックとして挙げればキリがありません。でもそれがいいのです。

　自分の体験を元に書くことができるので、オリジナリティを出しやすいのがこのネタの良いところです。さらに同人誌を書くことで、自分自身の行動を冷静に振り返ることができます。

　しかし、いきなりトラブルの事例と対処法だけを説明されても読者は困ってしまいます。文脈としてわかりやすくするため、出てくる単語は全て丁寧に定義し、最低限の説明は怠らないようにしましょう。文章量も稼ぐことができ、一石二鳥です。

3.1.3　ネタ案その3:〇〇やってみた系

　まるでYouTubeやニコニコ動画にありそうなネタですね。これは先に具体例を紹介します。

　　・気になるフレームワークを使ってWebアプリ作ってみた

　　・初心者がUnityでゲーム作ってみた

　　・スマートフォンアプリを作って公開したら、赤字になった

　　・電子工作でアート作品作ってみた

　　・秋葉原で部品を買ってPC作ってみた

　いかがでしょうか？あまり普段はやらないけど、ちょっと興味あることはありませんか？それ、同人誌のネタになりますよ。

全部書くのススメ

　技術同人誌を書く場合、初歩的なことこそ丁寧に書くことをおすすめします。インストールや環境設定、使い方でハマりやすいところ（より具体的には自分がつまずいたところ）は確実に他の人もつまずきます。

　このライブラリを入れないとこんなエラーが出るとか、最新バージョンでやったらダメで一個前のバージョンでないと動かない、とかいった情報は前提知識がないと脱出までに時間もかかります。問題の本質ではないところであるからこそ、つまずいた挙げ句にモチベーションを下げ、もうやーめた、と思うことになります。だからこそ一から十まで丁寧にかくことで、「本のとおりにやったのに動かない」という事態を避けることができます。

　コードの書き方を例に示したいと思います。自分が一般的なレベル、と思っているような“おまじない”でも、初心者はハマります。ですから、最初は本当のコードレベルの冗長さは必要です。2回目以降は、理解によって（あるいは想定する読者のレベルによって）調整すればよいのです。

図3.1: 本当のコードと本に書いてあるコード

　「本のとおりにやったのに動かない」は、初心者のモチベーションを最も下げる要因ですから、注意したいものです。

　おまけに、本文の分量も稼げます。技術書において、厚いは正義です。（Text：親方）

　このネタは初心者であればあるほど輝きます。というのも、このネタを求めている読者は同じ初心者である可能性が高いからです。初心者にしかわからないつまずきや、面白いと感じた感想は同類を勇気付けることができます。ありがたい！

　ネタの精度を上げるためには、実施した記録が全て再現できるかきちんと確認しておくと良いでしょう。初心者は何から手をつけて良いかわからないからこそ、あなたの知見を欲しているのです。その欲求に誠実に答えるのであれば、きちんと動くコードやプロパティが紹介されているかしっかり確認しましょう。操作手順を画面キャプチャし、本文に挿入するのもおすすめです。