下町柚子黄昏記 by @yuzutas0

したまち発・ゆずたそ作・試行錯誤の瓦礫の記録

トップ > 執筆しました > 『個人開発がやりたくなる本』を自費出版しました #技術書典

『個人開発がやりたくなる本』を自費出版しました #技術書典

執筆しました 個人開発

f:id:yuzutas0:20190909182530p:plain

ご挨拶

自称企画屋・コンセプトデザイナーの@yuzutas0です。

執筆者一同をはじめとして、 アンケートに回答してくださった皆様、各所で書籍を紹介してくださった皆様、 その他何らかの形でご協力いただいた皆様、本当にありがとうございました。

さて、発売から間が空きましたが、 裏話をツイートしたところ反響をいただけたので、ブログに制作秘話をまとめます。 個人開発者や技術書典参加者のヒントになれば幸いです。

もくじ

1. はじめに

1-1. 免責・謝罪・注意・お願い

  • 紛らわしいタイミングでごめんなさい。 「次の技術書典の開催までに振り返り記事を公開する」と宣言した結果、こうなってしまいました。 技術書典7は 9/22 10:00 開始。この記事は 9/22 03:30 公開。 はい。約束を守る人材です。
  • 13人のメンバーで作った本です。 公式のアナウンスはCrieitのみで、それ以外は全て各個人による発信です。 この記事もあくまで私1人の視点での見え方です。 メンバーごとに異なる見え方があります。 興味のある方はぜひ他の著者にもコンタクトを取ってみてください。
  • TwitterやCrieitで既に投稿した内容の補完です。 興味のある方はぜひ各ソーシャルアカウントをフォローしていただけると嬉しいです。
  • メイキング・エピソードです。 書籍読了済みでないと理解できない記述が多々あります。 また、ディズニーやピクサーやジブリのスタジオがまさにそうだと思いますが、 心暖まる優しい作品を世に届ける者たちは、冷徹で血みどろの戦いを経ているものです。 予めご了承いただけると幸いです。 不快に思われたらブラウザバックをお願いします。
  • 突貫で書き上げました。 イラッとした箇所があれば、こっそりDMで指摘いただけると嬉しいです。 しれっと修正します。
  • 人はなぜ長文を書くのか。

1-2. 書籍概要

『個人開発がやりたくなる本 - クリエイター13人の実録エッセイ』 / 紹介ページ

f:id:yuzutas0:20190909183121j:plain:h400

@mogya, @dala00, @nabettu, @hrz31, @macinjoke, @Meijin_garden, @rubys8arks, @tRaieZ1, @isbtty7, @ShiraAndroid, @morizyun, Tanem Apps との共著です。

初出典・サークル抽選落ち（委託販売）・1,500円（他より高い価格帯）という不利な状況ではありましたが、 応援してくださった方々のお陰で、販売部数は計1,000部を超えました！

自費出版は100〜200部でも上々と言われるので「個人開発」ジャンルの可能性を感じさせる結果でした。 『ハリー・ポッターと賢者の石』初版が自費出版で500部なので、倍の成果ということですね（？）。

ありがたいことに商業出版のお誘いもいただきました。 後述しますが、商業版はテイストと内容が変わるので、同好の士はぜひ同人版をお買い求めくださいませ。

1-3. この取り組みを始めた理由

私は個人開発で10のサービスを作ったあと、 1日でWebサービスを公開する、 隣の部屋の喘ぎ声が止むまでにサイトを作るなど、 アホな取り組みを細々とやっていました。 「もう一度きちんと挑戦したい」という気持ちは心の奥底にありました。

過去の経験からアイデア駆動では限界があると思い知った私は、様々な成功事例をリサーチしました。 他者の勝ちパターンを模倣・踏襲するのは戦いの王道です。 しかし、巷に溢れている正論・一般論は役に立ちません。 行動に必要なのは解像度の高い具体例です。 そこで「せっかくだから事例をまとめて本にしたら面白いのでは」と考えました。 その本を自分の手元に置いて何度でも読み返そう。 自分の血肉にして成功を掴み取ろう。 そう思いました。

「本」というインターフェイスに魅力を感じたのは3つの理由があります。

1：映像・ゲーム・執筆のような創作物に関心がありました。 IT・Web系の仕事が多かったので、新鮮な風を求めていました。 技術書典を偶然知って「これだ！」と思いました。 IT・Web系の知見・資産をコンテンツとして活かせるからです。

2：単純に人生で1冊くらい本を出してみたかったです。 過去に「Pythonによるデータ活用」本を執筆する話はありましたが、出版社と折り合いがつかず頓挫しました。 そこで思いました。 こうなったら自分で出版してしまおう！ これこそが個人開発だ！ 世に抗うクリエイターの姿だ！ 自ら道を切り開く探求者の魂だ！

3：何かを売る経験を積みたいと考えました。 「作ること」と「広めること」と「稼ぐこと」は、必ずしも一致しません。 だからこそ私は、個人開発で10のサービスを作ったあと 「本気でやるなら、1人ではなくチームでやる。サービス開発ではなく事業開発をやる。」 と述べました。 自費出版は「需要を想定し、資源を仕入れ、製品を作り、販売する」訓練になるだろうと考えました。

ということで、マーケット観点から色々と検討しました。 様々な情報媒体がある中で「本」を効果的に売るにはどうしたらいいか。 「知見」ではなく「勇気」を売るべきだという結論に至りました。 そして、勇気を与えてくれる「挑戦者」を集めました。 アウトプットが減った私に対して「お前最近だらしねぇなぁ」と叱ってくれるような人たちです。

1-4. この世界のどこかにいるあなたへ

最初から言語化できていたわけではないのですが、内心の動機がもう1つあります。 この世界のどこかにいるあなたへ、私がデータの世界で見たもの・感じたことを届けたかったからです。 デジタルワールドでほんの少しだけ大人になった私からの贈り物です。

私自身が個人開発に挑戦できたのは、"Rails Tutorial" や "酒と泪とRubyとRailsと" 、 "Webサービスのつくり方" など、 多くの先輩方がコンテンツを提供してくださったからこそです。 私は個人開発をきっかけにして、メディア掲載や仕事の依頼など、 様々な方々から身に余る光栄・チャンスを与えていただきました。 先輩から受け継いだものを後輩へと受け継ぐように、 今回の取り組みを通して何か1つでも世にお返しできていればと思っています。

また、世の中は本当に広くて、自分が全然知らないところで様々な個人開発の取り組みがなされています。 なんかさ、個人開発者のSlackとか勉強会とか、めっちゃいっぱいあるじゃないですか。 ちょっと寂しいと感じたり、内心悔しいと思ったり、「私も混ぜてくれよ！」という気持ちになったり、 毎日のように「うわあああ」と心で叫んでいます。 単にコミュニティに所属したいとか、メンションを飛ばし合いたいとかではなくて、 たとえ直接の関わりがなくても、世の中にアウトプットや価値を提供することで、 間接的に彼ら・彼女らに届けば嬉しいな、という感じです。

2. 企画を描く

2-1. この本で実現したいコンセプト

本書の「はじめに」に書きました。 全ての意思決定はこの内容にもとづいています。 全ての意思決定をこの内容に連動させたことが、企画屋・コンセプトデザイナーとしてのこだわりポイントです。

f:id:yuzutas0:20190910115856p:plain

2-2. 体験観点「世界一周旅行のような1冊」

読書体験として「色々なものが詰まっている！」という贅沢感・ワクワク感を演出しました。 人気のエンターテイメントにはこの要素があると思っています。

  • 『フロリダ・ディズニーワールド』（全てのファンタジー世界を再現しようとした試み）
  • 『大英博物館』（世界中のありとあらゆる遺物を収集しようとした試み）
  • 『君の名は。』（都会デビューのシーンもあれば、古い地方の伝承や自然を扱うシーンもある）
  • 『大乱闘スマッシュブラザーズ』（任天堂のキャラが集結する対戦ゲーム）
  • 『キングダムハーツ』（ディズニー作品の舞台を旅するアクションゲーム）

そのリアルな例が世界一周だと思っています。 写真とポエムを沢山載せればそれっぽくなるあの感じ！ ウユニ塩湖の登場率！ 個人的には結構好きなのです。

多くの人がこれらに惹かれるのは2つの理由があると思ってます。

1：「1つのコンテンツの量」と「満足度」の関係性です。 コンテンツ量がある程度多いほうが満足度は高くなります。 しかし、一定の量を超えると、だんだんと満足度は上がりにくくなります。 パスタを100食べるより、パスタ50とスープ50のほうが満足度が高くなります。 ミクロ経済学で「限界効用逓減の法則」と呼ばれます。 ゆえにエンターテイメントの勝ち筋は「つまみ食いできること」だと考えました。

2：分散投資と同じ理屈です。 1人の著者が書いた本に比べると、13人の原稿のほうがバリエーションがあるので、好みの内容が見つかりやすいはずです。 その1つが心に突き刺さるものであれば、買ってよかったと思ってもらえます。 また、フェーズや考え方が変わったときに「前はこっちが好きだったけど今はこっちがいいな」という体験も生まれます。 1つの株が落ちても他の株が上がれば儲かる。 長期投資の工夫と同じです。 寿命が長い1冊を作るために必要な考え方です。

世界一周旅行で様々な景色を楽しむように、多様な「個人開発」の面白さに触れる、心の旅。 読書とは著者との対話、著者の思索に触れる時間、著者の心の中に飛び込む体験です。 この "Dive to Hearts" を楽しめるような1冊にしたいと考えました。

2-3. 獲得観点「さっと手に取ってもらえる1冊」

無印良品のような「シンプルな本」「ベーシックな本」にしました。 このコンセプトは特に表紙とタイトルに影響を与えています。

表紙とタイトルを決めるだけでも1ヶ月くらいディスカッションしました。 かなり白熱して、後半はもはや喧嘩でした。 結果として、意思決定に繋がったクリティカル・クエスチョンは

多くの本と一緒に置かれたとき、その中から「さっと手に取ってもらえる1冊」と言えるか？

です。 Impressionを最優先に、だけど不快感を与えずに。 多数の本のなかで表紙を見てもらえるのは一瞬です。 そこでどう手に取ってもらえるか。

  • 本の表紙は鮮やかな黄色を押し出しています。 人の注意を引きつける警戒色で、かといって、鮮やかな赤ほど強すぎない程度の色です。
  • タイトルはシンプルにしました。 判断に時間が掛かると売れないだろうと考えました。 伝えるべき要素は最小文字数で詰め込めたと思っています。

他の個人開発者が本を出したときに備えて、最初は「合同誌ですよ」感のあるタイトルや表紙案でした。 もし隣で良さげな個人開発の本を売っていても「こっちは10人ですよ！」と言えば、まぁ見てはくれるんじゃないかなと。 特に類似本が出る気配はなかったので、メンバーに意見を募って、今の表紙・タイトルにしました。 複数人の事例集であることはサブタイトルで明記しています。

なお、最初はイラストを発注しようと思っていたのですが、結局止めました。 中途半端なイラストがあるとそっちに意識を向けてしまってメッセージが伝わりにくいからです。 コンセプトを踏まえた上で目的を満たすイラストをご提案いただけると理想なのですが そこまで優秀なイラストレーターは簡単には見つからないだろうと判断しました。

他にも、大量のレッドブルを積んだ表紙にして 「何が何でも個人開発リリースするんじゃい！」みたいな エッジの効いたメッセージを叩きつける案とか、色々ありました。

もし当選していたら、表紙の工夫がサークルチェック数に反映されて、もっと反響を得られたかもしれません。 どのくらいの数字になったか分からず終いなことが少し残念です。

2-4. 継続観点「クリエイターの手元に残してもらえる1冊」

本が簡単に消費されてしまう時代であることを念頭に置きました。 「本」という媒体について考えました。

というのも、ホテル暮らしに関心があって、身軽になろうと思い、 手持ちの本を全てPDFに自炊した直後だったからです。 そんな自分が「手元に置いておきたい」「何度も読み返したい」 「ページを捲りたい」と思える本とは何か？を考えました。 でなければ私自身が胸を張って紙媒体をセールスできません。

そして、手元に残すことの意味・必然性を以下のように定めました。

  • When：この本は「創作活動の合間の休憩時間で」読む本。
  • Where：この本は「部屋のベッドに寝転がって」読む本。
  • How：この本は「ペラペラとめくって好きなところを眺める」本。
  • Who：この本は「読者と同じ目線に立つ挑戦者たち」の本。
  • What：この本は「解像度の高い具体例が豊富に記されている」本。
  • Why：この本は「自分も負けないように頑張ろう！作業を再開しよう！と勇気をもらえる」本。

これが読者がこの本を手元に置く理由です。 紙の本を想定しましたが、タブレットと電子書籍でも同じです。 もちろん強制するものではないので、読者が自然とそういう体験・思考になるように、 製品をデザインしていこうという決意のようなものです。

2-5. 市場観点（売上編）「プログラミング初心者の話題にしてもらえる1冊」

長期売上は「単価」x「購買人数」x「今後の伸び」に要素分解できます。

1: 単価設定（1,500円）はギリギリのラインだったと思います。 内容面を考慮すると「やや安い」〜「妥当」の値段設定ですが、 技術書典の同人誌やBOOTHの電子書籍は1,000円での販売が多いため、相対的にやや高い印象を与えます。 また、マーケットの大多数であるライト層の購買傾向として、 3,000円の飲み会は気軽に参加する一方で、 2,000円の専門書は割高だと捉えられがちのように思います。

なお、単価を伸ばすために「本や紹介サイトに企業広告を載せる」収益モデルも検討しました。 「個人開発の自費出版に広告を載せた企業」「クリエイターを応援する企業」として プレスリリースの題材になれば、単体での広告効果を超えた副次的なリターンを スポンサー企業に提供できるのではないかと考えました。 何社か打診してミーティングを行いましたが、結果としては上手くいきませんでした。

2: プログラミング初心者の層が厚いと考えました。 英語学習に近いものがあると思っています。 実際「個人でWEBサービスをリリースしました」系の記事は、よくバズっています。

『リーダブルコード』は5万部超えだそうですが、間違いなく5万人以上のプログラミング初心者が、 全然リーダブルじゃないコードを書きなぐって、WEBサービスやアプリを作ろうとしています。 だからこそ先輩方が『リーダブルコード』を読んでくれと言いたくなるのでしょうけど。

具体的には「Maxで10万人の規模感」で読みました。 複数のWEBサイト・botを運営する中で「リーチできる上限はそのくらいかな」という肌感覚での数値です。 1,000部の販売だと、マーケットポテンシャルの1%にリーチできた、ということになります。

3: 今後もプログラミング学習者は増加するはずです。 そして、特定の技術要素をテーマにした書籍に比べると「個人開発」は寿命が長いテーマ設定と言えます。 「WEBサービスをリリースしました」系の記事は、10年以上に渡って定期的にバズっています。 大事なことなので2回目です。需要のあるジャンルで媒体だけを変えたのがポイントです。

未来の読者からすると、多少古臭く感じる内容があるかもしれませんが、 むしろ「当時のアイデアを」「今の(デバイス|ツール|テクノロジー)にしたら」「xxxできるじゃん！」と 創作活動のヒントにしてもらえるかもしれません。だからこそのエッセイ集・事例集です。

2-6. 市場観点（費用編）「既存のコンテンツを爆速でキュレーションした1冊」

製造コストは「人件費単価」x「執筆・編集の投下時間」に要素分解できます。 ブログやQiitaの既存記事をベースにすれば、大幅にコストを削減して、高いROIを実現できます。 同じような内容であっても、本にまとまっていることで、独自の顧客価値が生まれると考えました。 そこで浮いたコスト・時間をセールスやマーケティングの施策に投下することで、 増収・増益のサイクルを回せるはずだと期待しました。

2-7. 市場観点（10x編）「プログラミング教室の副読本に選んでもらえる1冊」

マーケットポテンシャルの1%にリーチできた

本当は！こいつを！10%にしたかった！

技術書籍はToBで売れる（＝研修教材に認定される）と生き残るのが定説だそうです。 ToBへのセールス施策が10x実現のキードライバーだと考えています。 色々なパターンを検討しましたが、マーケットサイズが最も大きいのは「プログラミング教室の副読本」でした。 「プログラミング初心者に売る」x「ToBで売る」を両方満たすならこれかなと。

私個人の体験を踏まえても「副読本」＝「個人開発の事例集」は腹落ちしています。 新入社員の研修講師やメンターを担当するとき、個々の技術は既存の教材や本で教えることができますが、 「とりあえず試しに何か作ってみたら？」と言いたくて仕方がないのです。 ずっとチュートリアルをやっても、予定調和のサンプルが完成するだけで、 スキルの伸びも実感しにくく、面白くないのではないかと思ってしまいます。

仮に自分が初心者向けにプログラミング教室を開くなら「サービス開発・運営」をカリキュラムの軸にします。 目的の曖昧な勉強を続けるより、実践ありきのほうが楽しいです。 全体感を学べるので学習効率が良いです。 目に見えるアウトプットがあったほうがその後の就職も斡旋しやすいです。

と思ってはいたのですが「試しに何か作ってみたら？」と提案するときに 「この本を読むと良いよ」と言える1冊はこれまで存在しませんでした。 人によって好みやスタイルが違うので「この個人開発者がすごいよ」というメッセージは言いにくいです。 「この中から合う人が見つかるといいね」と言って手渡せる「複数人の合同誌」であってほしいのです。

ということで、実は「初期バージョンの表紙」では 「プログラミング教室やプログラミング学習サービスへの営業施策」（＝ToBへの布石）として 「その会社のCEOにインタビューしてコンテンツに含めること」を提示していました。

2-8. オチ

高ROIの目論見は外れました。 めっちゃ頑張って書いて（高コスト）、マーケやセールス施策は打てず（低リターン）、真逆の結果になりましたとさ！

「せっかくなら書き下ろしを！」というメンバーの熱意はすごかったです。 まぁ、そりゃそう思いますよね。 「作ること」と「広めること」と「稼ぐこと」は、必ずしも一致しません。 今回集まったクリエイターは（他ならぬ私自身を含めて）特に「作る」ことが好きな人たちだったと解釈しています。 「より良いものを作りたい」と思っている人たちです。 そりゃコピペじゃ満足するわけがないですよね。

それはつまり、必ずしも高いROIの達成にこだわってきた人たちではない、ということでもあります。 しかし、だからこそ、私は「このメンバーが作るサービスは、ユーザーや仲間たちに愛されるんだな」と思いました。

そんなメンバーと一緒に作ったからこそ「自分も頑張ろう」と思える1冊にできたと思います。 同じようなクリエイター（を目指す人）の心に届く1冊になったのではないかと思っています。 少なくとも私は、この本を世界で一番多く読んでいる読者として、そう思っています。

それこそがこの本の提供価値です。 彼らのクリエイター精神だけは絶対に否定したくなかった。 そこを外したら、出来上がるのは、ただの紙クズでしかなかったでしょう。

これはマーケットの発想としても妥当だったと思っています。 メインで伸びているのは、あくまでプログラミング教室です。 デザイン教室やマーケティング教室やマネタイズ教室ではありません。 「作る」ことにこだわるクリエイターの本で、「作る」モチベーションに訴求したのは、間違っていないはずです。

なので、まぁ、なるべくしてこの結果になったのかなと思います。

でも、きっと何か工夫できる余地はあったはず、もっと高いROIを実現できたはず、とも思っています。 私が描く理想の私だったらもっと上手くやれたはずなんだぁぁぁぁああああ。うわあああああああああ。 人件費を考慮したら余裕で赤字なんですよ。私の完全敗北なんですよ。うううううううう。精進します。

3. 製品を作る

3-1. ジェットコースター構成 - 『君の名は。』

近年におけるエンターテイメントの金字塔『君の名は。』の構成を参考にしています。 迷ったときには『君の名は。』の構成が持つ意味（＝なぜこの順番で情報を提示したのか？）を考えました。 2つの例を紹介します。

1：導入部分。 本書の第1部では「個人開発」の代表的な流れを提示しています。 第1章は、初心者がサービスをリリースした振り返り。 ライトで読みやすいコンテンツです。 第2章は、解像度の高い開発譚。 具体的なエピソードを、細部まで生々しく描いています。

ここまで読んで「個人開発の一連の流れが分かる」「最低限の期待には応えている本だ」 「自分がサービスを作るときに読み返すと良さそうだ」という（ある種の）安心感を得られます。 その上で、第2部の「バズった話」が待っています。 多くの人がつい気になってしまうトピックです。 ここで一気に引き込みます。

『君の名は。』の導入部も同じ仕組みだと私は解釈しています。 CMの雰囲気を追体験しながら、舞台背景を説明するところから始まります。 CMの視聴で観客の脳内に湧いた「こういう話なのだろうな」というイメージ（＝期待）を最初に満足させる。 もやもやさせない。まずはすっきりさせる。その上で事件（＝展開）へと引き込んでいく。

2：読み手のテンションが上下する構成。 「やる気が出る！」（エピソード）と「これ参考になる！」（ナレッジ）を交互に配置しました。 「面白い！読みやすい！」（ライト・エンジョイ）と 「すげぇな！たしかにな！」（シリアス・ガチ）を交互に配置しました。

同じフォーマットや似た内容が続くのではなく、変化に富むことで飽きさせない構成にしています。 静と動を繰り返すのは2000年代の人気アニメーション邦画『千と千尋の神隠し』も同じ構成だと解釈しています。 いわゆる『ハリウッド脚本術』に比べて、クライマックスの山谷が頻繁に訪れ、 視聴者の心理状態が頻繁に切り替わるデザインです。 IPT（時間あたりの情報凝縮量）が高くなるので、普段から大量の情報を捌いている現代人を飽きさせません。

なお、具体的な構成は全員の原稿を集めた後に決めました。 ある程度は脳内でも絵を描いていましたが、全員から構成案を募った上で、 議論を重ねて、現実的な落とし所を擦り合わせました。

アドリブを重視したのには理由があります。 内容（What）だけを事前に決めても、書き方（How）が分からないと、ジェットコースターにマッピングできません。 仮にテーマが重い章でも、細部の切り口や見せ方、言葉遣いが軽やかだと、読者はライトな印象を受けます。 かといって、書き方（How）を指定したところで、プロのライターでもない人間が、要件を満たすのは難しいでしょう。

構成ありきで執筆を依頼すると、かえってクオリティが下がるのではないか。 我々のような素人がお題やフォーマットに沿って文章を書いても、ただ項目が揃っているだけで、 たいして面白くないものができるのではないか。 もし構成が明確に決まっているなら、むしろ自分1人で書くか、 プロのライターを雇ったほうが、全体の整合性は取りやすいのではないか。 そう懸念しました。

逆に言うと、チームでやることの意味がここにあると思っています。 素材が良いのなら、素材をもとに料理を考えるほうが、美味しいものができます。 素材の味を楽しめます。 ゆえに、出たとこ勝負こそが、総合的にベストなのです。

3-2. 寄せ書き方式 - One for All, All for One

付録コンテンツ「141人の個人開発者へのアンケート結果」を無料公開しています。 このアンケートの最後の質問は「あなたにとって個人開発とは何か？」です。 そして、ネタバレになりますが、本書のラストは以下のように締めています。

f:id:yuzutas0:20190910115813p:plain

これは強烈な読後感を与えるための仕掛けです。 読み終えたときにSNSでつい一言呟きたくなる。 最後の最後で「あぁ、いい本だったな」と思っていただく。 そのための工夫です。

名作に相応しい結末は何か？ 世界一周の旅の果てに見えるのはどんな景色か？ ディズニーのような、魔法のような、最高の体験をどう提供するか？ これらのクエスチョンに対するアンサーが、この寄せ書き方式です。

これは私が得意とするスタイルで、大規模カンファレンスの登壇スライドでは必ず「スタッフロール」を掲載します。 たとえどんなに僅かな貢献であったとしても、関わってくれた1人1人こそが、物語を織り成す大切な登場人物である。 スタッフロールにそう明記します。 名作には名作に相応しい終わり方があると、多くの観客は無意識のうちに思っています。 だから私は「これは名作ですよ」と伝えて、感動を生み出すのです。 また、名前が載った人を起点としてリファラルが生まれ、さらに周囲を巻き込みます。

一般的な「寄せ書き」も同様です。 「寄せ書き」には独特の魅力があります。 1つ1つは些細な短文であっても、10人分集まることで、確かな感動を生み出します。 繋がる心が力になるわけです。

f:id:yuzutas0:20190922020539p:plain

この「寄せ書き」もとい「個人開発者141人へのアンケート」ですが、 最高の読後感を演出するだけでなく、以下3つの背景もありました。

1：偏った内容にしないための工夫です。 この本では、著者13人の意見や事例が紹介されていますが、これでもだいぶ偏ったなと思いました。 本当はもっと色々な考え方や選択肢があるということを示したかったです。

私の原稿が最初に完成して、その原稿を他メンバーが執筆前に読んだことで、 他の原稿も影響を受けてしまったのではないか、と悩みました。 「参考原稿がないと書くに書けない」という意見が多かったため、やむを得なかったとは思います。 ただ、多様性というコンセプトからはズレてしまいました。 原稿を読んでいない方々が、先入観なしに、好き勝手に、アンケートに回答することが重要でした。

2：読者参加型コンテンツを1つ設けたいと考えました。 今は共創の時代です。 Webは双方向に影響を与え合うプラットフォームです。 この本はWebで活躍するクリエイターたちの本です。 ゆえにWebの双方向性を活かしたコンテンツを含めたいと考えました。

双方向だからこそマーケティング施策になりうるという側面もあります。 「自分のアンケート回答が掲載されている本」ならば拡散もしてもらいやすいだろうという期待はありました。 この本は、全員で作り上げ、全員で売っているのです。

3：他の個人開発者が書く本と明確に差別化する意図もあります。 実力のある個人開発者が本を書こうとすると 「すごいクリエイターが何かを教える本」になりがちだと感じています。 それはそれで価値のある本です。

ですが、1人の言葉では作り出せない感動もまた、たしかに存在します。 多くの仲間がいると実感できるからこそ、自分も頑張ろうと思えるはずです。 この本はそういった独自のポジションを張っています。 そのことを明確にするための施策です。

※なお、アンケートとは別の付録として 大手プログラミング教室の運営者に「個人開発が未来を作る」と語ってもらおうと思っていました。 10xを狙うには必要なコンテンツでした。 この案を含めて、私自身がもっとセールス・マーケティングにコミットしたかった…… のですが、プロジェクト炎上に伴って断念しました。

結果的には「挑戦している本人たちが書いたもの」だけが載って 「第三者の声」「ありがたい言葉」「偉そうな解説」が載らない本になったとも言えます。 これはこれで同人誌っぽくていいじゃないか。 コンセプトに準拠した本になったじゃないか。 今ではそう思っています。

3-3. 編集・推敲・校正　- この1文字はコンセプトに沿っているか？

一般論ではなく

f:id:yuzutas0:20190914191243p:plain

自分がどうだったか

f:id:yuzutas0:20190914191257p:plain

「はじめに」に書いたように「読んだ人がポジティブに頑張りたくなる本」を目指しました。 「一般論を語らない」「偉そうに解説しない」「ネガティブにしない」といった観点で編集しています。 コンセプトや全体の流れを踏まえて、かなり手を加えました。

f:id:yuzutas0:20190914191324p:plain

いくつか編集で意識したことを紹介します。

1：ポエムや一般論の比率は、多くとも20-30%を目安に抑えました。 「本を書くからには何か良いことを言わなければ」と肩に力が入ると、ポエムや一般論が多くなってしまいます。 私自身も@ITで記事を連載した時に、社内外の編集担当から同じ添削を受けました。 ついやってしまう気持ちは分かります。

赤の他人のポエムや一般論はSNS上に飽和しています。 だからこそリアルな体験談が求められているのではないでしょうか。 エピソードの合間にちょっとしたポエムや一般論が入るからこそ突き刺さるのであって、 主従が逆転するのはナンセンスです。

2：リスクは徹底的に削りました。 例えば、アンケート結果では「性別」（回答欄：男・女）をカットしています。 もしLGBT向けのサービスを作っている個人開発者がそのアンケート結果を見たら良い顔はしないでしょう。

男女比率のバランスがよかったら「がんばろう」と思うか？ 男性が多くて女性が少なかったら「がんばろう」と思うか？ 女性が多くて男性が少なかったら「がんばろう」と思うか？ どんな結果を見たらどう行動が変わるか？ その結果を見てモチベーションが下がる人はいないか？ その結果を見ることにポジティブな意味があるか？ クリエイターの背中を押す本として、最高のコンテンツを提供していると言えるか？

そう考えました。 同様の理由で「年齢」もカットしています。 こういったリスクは片っ端から消して 「誰が読んでもそれなりに心地よい読後感」 となるようにコンテンツを調整しました。

3：語尾（です・だ）や一人称（私・俺・自分）は各章で意図的に変えました。 「それぞれ違う人たちが好きに書いている」 「多様な選択肢から好きなものを選べる」ことを明確に伝えるためです。

  • 私自身の「HileSearch」パート：1人称「私」
  • TanemApps との居酒屋談義を私がテキストにしたパート：1人称「俺」
  • @isbtty7 との居酒屋談義を私がテキストにしたパート：1人称「自分」

ただし、1冊の本として最低限の一貫性は損なわないように、 私が読み直して不自然に感じた部分は手直ししています。

チーム内で原稿をプレビューしたところ、 ある人は「全体的には良い」「でもA章の書き方は気に食わない」 「B章がすごく好きなのでこっちに揃えられないか」と提案してくれました。 一方で、別の人は「全体的には良い」「A章が最高なのでこれに揃えたい」 「B章だけは絶対に違うと思う」という感想を寄せてくれました。 読み手によって刺さる書き方が違うわけです。

（絶妙なクオリティコントロールが必要ではありますが）「このスタイルは行ける」と確信しました。 少なくとも「全体的には良い」かつ「これは好き」と言えるパートがあるくらいには、1冊の本として仕上げたのですから。

その他、一般的な編集作業を行いました。

  • 無関係な内容。「趣味のボルダリングの写真です」 → カット。
  • セルフツッコミ。「だからなんだって話ですけど」 → カット。
  • 言い訳・予防線。「これは人によって好みもありますけど」 → 「自分はこうしました」に修正。
  • 修飾表現。「割とまぁこういうことって少ないとは言えないんじゃないかなぁと思います」 → 「多い」に修正。
  • 後出し。「こういうことが伝わってほしくてこの記事を書いています」（章の途中） → 冒頭に移植。
  • 権威に頼る。「xxxさんもこう言っています」 → カット。 xxxさんを紹介する記事なのか？自分の事例を紹介する記事であってくれ！
  • キャプチャ画像。画像を拡大して細かく確認しました。アカウント名や人物写真にはモザイクを掛けました。
  • 本文中の自己PR。扉ページ（自己紹介）に移しました。読者のメリットを考慮しないと逆効果になりかねない！
  • So What / Why。 「この段落やセンテンスは要するに何が言いたいのでしょう」と思ったところは、自分なりに解釈して文章を補完しました。 最終レビュー時に「俺が書いたときより分かりやすくなっている！笑」とコメントいただきました。
  • 言及しているサイトの規約確認。 特にQiitaの利用規約やスクレイピング系に関しては、頭では分かっていても、 文章の書き方として、誤解を招きかねない表現になってしまいがちです。 各々の著者が良かれと思って書いた文章であっても、第三者的にチェックして修正しました。
  • 一時的・内輪向けの表現。「最近よく聞きますよね」 → カット。 未来の読者からすると「最近っていつの話？」となるでしょう。 著者と同じコミュニティに属していない読者からすると「聞かないけど」となるでしょう。 10年以上の経験を持つベテランからすると「それ昔から言われているけど」となるでしょう。 ツッコミどころがあると気になってしまう人もいるので、基本的にはカットです。
  • ネガティブワード。「こうしないとxxxみたいなダサいデザインになってしまいます」 → カット！ この文章をxxxの担当者が見たらどう思うでしょうか？ というかxxxの担当者は低リテラシーな利用者のためにあえてそうデザインしているのではないでしょうか？ 当事者ではない素人からの批判は、当事者の事情・背景を組んでいないため、的外れになりやすいと思っています。 勝手に他人を評価しない！他人の評論ではなく、自分の個人開発について話す本であってほしい！

ということで、最終的には100回以上読み直して、1文字1句まで修正を繰り返しました。 また、印刷費を抑えるために、170ページの原稿を、文言調整だけで140ページに圧縮しました。

プロの編集者が見たら残念な出来栄えかもしれません。 しかし「読者を不快にさせない」「書籍のコンセプトを体現する」という目的はある程度達成したと思います。 文章が正しいだけの本にするつもりはありませんでした。 国語のテストではありませんからね。

にもかかわらず！表紙に！誤植があるというオチ！！

3-4. 印刷所への発注内容

実物のプロダクト（紙の本）を見た知人・友人達からは 「思ったよりしっかりしているやんけ！」「これめっちゃいいな！」と好評いただきました。

印刷・製本は日光企画さんにご対応いただきました。 初めての自費出版でしたので、御茶ノ水の店舗でレクチャーしていただきました。 ヨーロッパ横断旅行と入稿スケジュールがバッティングしたのですが、 その旨を店舗＆別途メールでも相談したところ、丁寧にご対応いただき、 無事にオンラインで入稿できました。

f:id:yuzutas0:20190922021430p:plain

発注内容は以下です。

  • 【ご使用のセットまたは仕様】オンデマンド平トジ基本セット
  • 【ご使用のOSとソフト】MacOSX、その他（備考に記載）
  • 【サイズ】B5
  • 【表紙込みページ数】144（本文140 + 表紙4）
  • 【冊数】200
  • 【本のトジ方向】左
  • 【本のトジ種類】平トジ
  • 【表紙用紙】NPホワイト200kg（PP貼りの基本用紙）
  • 【表紙印刷】RGBオンデマンドフルカラー印刷
  • 【オプション】マットPP（1日本は不可）、4色オプションマットPP貼り変更(@5円)
  • 【本文用紙】上質90kg
  • 【本文印刷】オンデマンドスミ刷り
  • 【本文始まりページ（ノンブル）】1
  • 【遊び紙】無し
  • 【納品日（イベント開催日）】4/14
  • 【納品先】イベント名：技術書典6、開催会場：池袋サンシャインシティ2F 展示ホールD（文化会館ビル2F）
  • 【納品数】200
  • 【スペースNo/サークル名】スペースNo：か65、サークル名：ザ・シメサバズ（委託）
  • 【入金方法】銀行振り込み
  • 【事前予約や見積もりは取っていますか？】取っている（電話）
  • 【当社ご利用は初めてですか？】初めて
  • 【pixivプレミアム会員割引】プレミアム会員（ノベルティ有り）
  • 【備考】
    • <お願い> 初の利用となりますので、提出したファイルのフォーマットや登録事項など、これであっているのか自信がありません。 お手数ですがご確認いただくことは可能でしょうか。 問題があれば修正・対応いたしますので、お気軽にお申し付けください。
    • <連絡について> 現在xxxに滞在中で、xx/xxに帰国予定です。 誠に申し訳ありませんが、それまではメールでのやりとりをメインとさせていただけますか。
    • <使用ツール> Re:ViewでPDF出力。 一部KeynoteからPDF出力したページに差し替え。 ノンブルは調整済み。 サイズはおそらく一致しているはずですが、 ビューアーによっては表示が1pixel変わってしまうようで、よく分かっていません。 特に1pixelの表現にこだわるつもりはありませんので、印刷上問題がなければこれでお願いしたいです。
    • <事前予約や見積もり> 一度店頭で相談させていただいて見積もりをいただきました。 選択肢がなかったので、便宜上「取っている（電話）」でフォームを登録しています。 そのときの金額が、オンデマンドで基本xxx,xxx円 → 40%オフでxx,xxx円 → pixivの5%割引でxx,xxx円と伺いました。 表紙マット加工を希望するので200冊x5円＝1,000円割増となり、 合計xx,xxx円をお支払いすることになる、と解釈しています。
    • <表紙印刷> 「RGBオンデマンドフルカラー印刷」のほうが色が綺麗だというブログ記事を見かけたので入力しました。 特にこだわりや知識があるわけではないので、表紙のデザインに適したオススメが他にあればご指導いただけると幸いです。
    • <マットPP> マットPP（1日本は不可）、4色オプションマットPP貼り変更(@5円) の両方を入力しました。 どちらの項目が該当するのか、これらの2つの項目がどう違うのか分かっていません。 表紙をマット加工すると手触りが良いですよ、というブログ記事を見かけたので、ぜひ希望したいと考えています。 もし他に適切な選択肢があれば、ご案内いただけると助かります。
    • <添付ファイル> PDFはフルカラーを添付しますが、本文は白黒印刷の想定です。
    • <ポストカード> 「ポストカード無料印刷サービス」を希望します。 「希望の用紙」はNPホワイト200でお願いします。 添付ファイル「xxx.eps」が該当のものとなります。

何点か手元のメモを以下に掲載します。

1：部数について。 200部は少なすぎたと思っています。 多めに発注したほうが絶対に良いです。 売り切れたあとの残念な感じは、なんというか、残念でした（語彙力）。 売れ残る分には各所で配布できます。 足りないと確実にチャンスを逃します。 せいぜい10万円前後のコストであれば、払っておいたほうが良かったと思っています。

2：締切スケジュールについて。 128ページ以上だと繰り上がります。 私の場合は3月23日18:00（オンデマンド印刷時）がデッドラインでした。 早い段階で確認して正解でした。

3：マットPP加工について。 「創作活動の合間の休憩時間にベッドで寝っ転がりながらペラペラとめくる本」なので 1冊5円なら頼むほうが良さそうだということで意思決定しました。

4：遠隔地にいる共著者への郵送について。 印刷所から直接送っていただけないか相談したところ、 かなり割高の郵送費を支払う必要があるとのことでした。 一度自分で受け取ってから別の業者に依頼しました。 ただ、手間を考えるとどっちもどっちだったかなと思います。

5：PDFデータの受け渡しについて。 頻出トラブルを伺ったところPDFファイルにフォントが含まれていないケースを挙げていただきました。 想定外の印刷結果になるそうです。 PDFで保存するときに、埋め込みサブセット（フォント）を確認しました。 また、 $ pdffonts {pdfファイル} で、emb結果が全てyesであることをテストしました。 pdffontコマンドについては この記事を参考にしました。

6：ダウンロードカードについて。 このカードをどうデザインすると顧客価値を最大化できるのか、もっとマジメに考えても良かったと思っています。 イベント会場では「せっかくの参加記念だから」「撮影してSNSに上げるから」 「本に比べると持ち帰りがラクだから」というモチベーションが買い手にありました。 問題は売れ残ったときで、紙媒体（物がある）や電子版（気軽に買える）と同じ値段で今後売るには、 「カードを持っていること自体に意味がある」デザインのほうが何かと好ましいなぁと思います。

以前「本の栞にしたくなる名刺」のプロトタイプをデザインしたことがあります。 スキャンして終わりではなく「手元に残して使いたくなる名刺とは何か？」と考えた結果です。 ただ、今回は「栞」作戦は使えません。 紙の本ではなくDLカードを買っているわけですから！ 本を挟むための栞！栞を挟むための本！あべこべです。 IT系のクリエイターにとって「つい手元に残したくなる」カード・名刺サイズのものとは、何でしょうか。 私はまだ答えを得ていません。

7：印刷費について。以下は店頭でベース金額を比較したときのメモです。 合っているかは自信がありません。直接問い合わせたほうが確実です。

  • オフセット 9.9万円
    • 本文のみ40%割引
    • 上質90kg、すばる（白で優しめ）ニュークリーム（目に優しそう）で値段は同じ
    • 表紙・本文の20%割引が別にあってそちらのほうが締切が後なのに安い（＝オンデマンドより僅かに高価）
  • オンデマンド 8.6万円
    • 表紙・本文の両方とも40%割引
    • 上質90kg、ニュークリーム
    • pixivプレミアムの5%割引で7.9万まで減らせる → これが最安値【採用】

ということで、10万円以下で本を出せてしまうわけです。 すごいですよね。

4. 顧客に売る

4-1. 販路確保

技術書典：抽選落ちでした！ とはいえ、捨てる神あれば拾う神あり。 共著者の @nabettu さんが救いの手を差し伸べてくれました。

Booth：登録 →　PDFアップロード → 販売！ お手軽でした。これは最高ですね。革命ですね。 DLカード版はローカルでzipコマンドを打ってパスワード付きフォルダを生成しました。 なお、1つ致命的なミスがありまして、テスト用ドメインのまま出版してしまいました。 いつかBoothの機能追加でドメインを変更できるようになったら修正します。

Kindle Direct Publishing：登録 →　PDFアップロード → 販売！ 米国の納税関係（ですかね？）で登録項目が多かったです。 また、1,500円の本だと「手数料で7割を取られる」方式しか選択できません。 Apple税やGoogle税（3割）が可愛いくらいです。 流通面のメリット（Kindleで手軽に買える・読める）と天秤に掛けて 「Boothより高い値段で売る」方式で意思決定しました。

また、暗黒通信団に紹介いただく話も挙がりましたが、委託先サークルが見つかったこともあり 「とりあえずはイベントを楽しみましょう」ということで流れました。

4-2. メンバーによる宣伝・販売促進

正直なところ、私はプロダクト開発に手一杯で、マーケティング施策まで見ることができませんでした。 他メンバーの主体的な発信によるところが大きかったと思っています。

プロジェクト前半では @rubys8arks さんの尽力が大きかったと思っています。 技術書典の関連イベントへの参加や、ご自身のブログや各種Slackでの発信など、積極的に行動してくださいました。 特に141人のアンケート結果を得ることができたのは、間違いなく彼女のお陰でした。

プロジェクト後半では @mogya さん & @dala00 さん & @hrz31 さんの尽力が大きかったと思っています。 本書について言及しているツイートに片っ端からRT・Favを押していました。

身内の数人が反応するだけでも「なんか盛り上がっているっぽいぞ」感が溢れ出るわけです。 盛り上がっているので、Twitterで上位表示されやすくなります。ちょっとずるいでけどね。 特にオペレーション設計をしていたわけではなく、自発的にこうなりました。

@mogya さん & @dala00 さん & @hrz31 さんが愛情を持ってプロダクトと向き合ってくれたことが一番良かったと思っています。 そのポジティブな姿勢は、周りの人たちに伝わっているはずです。 そして少しでも「面白そうだ」と言及すると、3人のFavが確実に付きます。 「この本を応援するとポジティブな反応がもらえる」という報酬フィードバックをマーケットに叩き込みました。

余談：私はメルカリという会社がすごいと思っていて、あの会社の社員はSNSでこれを常日頃やっています。 そこに発信力がついてくるのだと思っています。

結論をまとめると、メンバーが積極的に楽しんでくれた → 「個人開発が好きな人たち」がSlackやTwitterで盛り上げてくれた。 これに尽きると思います。 つまるところ、一番楽しんでいる人が、一番強いのではないかと。

4-3. 最小限の集客施策（作業）

私がプロダクト開発の合間に、できる範囲で打った施策（作業）は以下です。

  • 13人のメンバーを集めたこと自体がマーケ施策の1つです。拡散力の確保のため、起案・推進しました。
  • 141人のアンケートを集めたこと自体がマーケ施策の1つです。拡散力の確保のため、起案・支援しました。
  • 案内ページや無料コンテンツを公開しました。
  • Togetterでの読者感想まとめを作成しました。Togetter公式に取り上げていただきました。
  • 過去に1度でも本書についてTwitterで言及した人に片っ端から「販売開始しました」リプを送りました。手動CRMです。
  • Twitterで「購入を迷っている」「どうなんだろう」と言及した人に片っ端から案内を送りました。手動CRMです。
  • 人気のハッシュタグや時節ネタ（新元号など）を交えたツイートで、繋がりのない人へのImpressionを発生させました。
  • 寝技：DMやSlackやオフラインで個別に話して回り、SNSやブログで感想を書いてもらいました。

余談：私が使っているエゴサの検索ワードは #個人開発がやりたくなる本 OR 個人開発がやりたくなる本 OR #IndieCoderJP OR https://booth.pm/ja/items/1313332 です。 ネガティブコメントでなければFav、なおかつ3以上のFavがついている場合はRTします。 反響の多いであろう時間帯にRTするとか、対象投稿が複数ある場合はフォロワーのツイートを優先するとか、 細かい運用ルールは多々ありますが、ぜひハックしてくださいませ。

4-4. 読者還元キャンペーン

ささやかではありますがキャンペーンを行いました。 本書の感想をブログに書くと1,000円分のAmazonギフト券を読者に還元する企画です。

この施策の意図は3つあります。 1つは後述するので、ここでは2つを説明します。

1：ハッシュタグを追ってくれたり、著者をフォローしてくれるような、 ロイヤリティの高いユーザーに対する感謝を示したかったからです。 私は私自身や私の企画を応援してくれる人に対して、 そうでない人よりお得な体験を提供したいと思っています。 ファン（あえてこの言い方をします）を尊重することは、 後のリファラルを生む、費用対効果の高い施策だと認識しています。

2：ブログ記事（ストック）は、有料広告（フロー）に比べて、確度の高い集客装置だからです。 1,500円の書籍は、LTVが最大で1,500円で、さらに手数料が差し引かれます。 打てる集客施策は限られます。 購入CPAが1,500円を超えたらアウトです。 逆に言うと、1,000円を払って、誰か1人でもコンバージョンしてくれるなら、施策としては投資分を回収できます。 また、良質なリンクが増えることで、SEO観点でも望ましいだろうと思いました。 いちおう最低限「1人の購入にも繋がらないような悪質な記事」は弾きたいので、そのための規約を設けました。

なお、応募フォームの認知率が低く「ブログを書いたのに応募していない」問題が起きました。 こちら今からでも対応しますので、心当たりのある方はぜひご連絡ください。

4-5. イベント会場での販売 - 「2秒・30秒」の法則

店頭セールスにおけるファネル＆オペレーションは以下の通りです。 委託にも関わらずポスター（上記ツイート画像）のトップに本書を掲載いただけた前提があります。

1：ブースの前を人が流れます。 歩きながら、ちらっと、こちらの看板を見ます。 「看板を見てちょうど2秒の人」に声を掛けます。 その人物は顧客の候補です。 1秒だと早すぎます。 まだ看板を読み終わっていません。 「えっ」「突然話しかけられた」となります。 3秒だと遅すぎます。 もう看板は見終わって通り過ぎようとしています。 「あー」「すいません」となります。 2秒がベストです。

2：こちらに関心を持って、一瞬足が止まったら、 すかさず「よかったら見本の試し読みどうですか？」と声を掛けます。 2秒ルールだと中途半端な逡巡は発生しません。 断る人は即座に断ります。来る人は来ます。 ブースで試し読みをしていただきます。 WEBサービスだとLP流入に相当するフェーズです。 @nabettu さんの接客を隣で観察して模倣したのが、ここまでのオペレーションです。

3：試し読みから30秒で「いかがですか？」（＝買いませんか？）と声を掛けます。 買うなら買う。買わないなら買わない。意思決定をしていただきます。 悩んでいたら「どういった点を気にされていますか？」と質問します。 明確なブロッカーがある場合はそこでQ&A対応をします。 それなりにこだわったプロダクトなので、自分でQ&Aをすると高確率で購入してもらえました。 明らかに想定読者でない場合は「いらないや」とすぐに決めてもらえます。

なお「明確なブロッカーはないけど購入を悩んでいる」場合は、いわゆる長考タイプだと思います。 長い時間を掛けて読んだ上で「ちょっと考えます」と結局離れてしまうことが多かったです。 その後しばらくしてから戻ってきて、買ってくださる方もいました。 本の内容や読む時間の量とは関係なく、本人が納得するために時間を必要としているようです。 接客空間と見本が占領されてしまうので、売り手には毀損が生じます。 早めにブースから離れていただき、また興味があったら戻ってきてもらうほうが、お互いに良いかなと思います。

売上 = ブースでの対応者数 x 購入率 x 単価 です。 今回の場合だと単価は固定で、ありがたいことに購入率は高い（＝上げにくい）ため、 唯一伸ばせる変数は「ブースでの対応者数」でした。 つまり「いかに回転率を上げるか」のゲームです。 色々試した肌感覚だと30秒がベストかなと思います。

余談1：この経営指標は、SONYの「マネジメントゲーム研修」 （Softbankの孫さんが携帯ショップの立ち上げ・経営で愛用したツール）を体験したときに腹落ちしました。

余談2：他サークルのブースをお借りする立場だったので 「買います」と言ってくださった方には「良かったらこちらの本もどうですか？」 「Webサービスを開発するならVue.jsとFirebaseがオススメですよ！」と クロスセルで書籍をレコメンドして、 何件か受注に繋げました。

余談3：子供の頃に夏祭りで毎年かき氷を売っていたので、その時の感覚を思い出しながら接客しました。 人生は何事も経験ですね。

4-6. 実行できなかったマーケティング施策を供養します

ここに供養します。 未来の私が何らかの形でリベンジしてくれることを祈っています。

  • 既に品質が担保されたコンテンツの大量アグリゲーション。 ブログを拝見する → 「この記事は最高では！」 → URLを張って「これ寄稿していただけませんか」DM。 その延長で著名人のコンテンツを大量に突っ込む。

  • オウンドメディア。 「個人開発のやばいやつ10選」など切り口を変えた記事を毎週打ち出す。 「個人開発サイトがきっかけで就職できた」など切り口を変えたインタビューを毎週打ち出す。 メディア自体が単体でアクセスを稼ぐ（＝プログラミング教室のオススメURLに認定される）状態にしてから 書籍にコンバージョンしてもらう。

  • プロモーションサイトに情報を小出しにする。 人気ゲームのサイトが「東京ゲームショウ2019で流したPV」を載せるようなイメージ。 勉強会や再販イベントなどでLTをして、書籍の情報を小出しにする。 「この手のイベントに行くと話が聞けるぞ」という状態にして、イベントに集客する。 イベント運営者の集客を手伝う。 何回も繰り返すうちに「このサークルはこういう感じだよね」という雰囲気を定着させる。 その上で満を持して売り出す。 事前にロイヤリティを高めてファンを囲った上で初速を出す。

  • プログラミング教室の講師や、プログラミング学習サービスの運営者にフィードバックを貰いながら、 ToBで大量発注できる製品へと磨き込む。ド本命の施策というかプロセス。

まぁこうして見ると筋の良い打ち手ばかりではありませんね。 アイデアから始めるのではなく、KPI構造から分解して施策に落とし込まないと、 担当者が疲れるだけで効果が出なさそうです。

ぶっちゃけると、信頼できるプロのマーケターにお金を払って助けてもらう。 これが最善手だと思っています。 私のような素人がいくら妄想だけで施策を打っても、ある程度以上を目指すのはちょっと無理があります。 余計なプライドは捨て、プロに弟子入りして、色々と盗ませてもらうのが、一番手っ取り早いだろうなと。

そりゃ私だって「マーケティング得意ですけど？」（キリッ）とか言いたいですけど、今回このザマだったからなぁ。 できなかったってことは、つまり、できなかったってことだからなぁ。ああああああああ。悲しみなのだが！

5. 収益を稼ぐ

5-1. 利益について / 自費出版（合同誌）の後始末

4月末時点の売上を希望者で山分けしました。 作業貢献度合いが大きい人・自腹での出費がある人には、多めに支払っています。

その後、当初想定よりロングテールで4月以降に儲けが出ました。 全員で山分けするには少なく、 次の共同プロジェクトの資本にするには少なく、 かといって私1人が取ると周囲に良い顔をされないであろう程度には多い。 絶妙な金額です。

そこで積極的に還元したいと考えています。 1つ目の施策は前述の読者還元キャンペーンです。 2つ目の施策は「寄付」です。

もともと「金で揉めるくらいなら全額寄付に回そう」と話していました。 リリース実績のある個人開発者の集まりです。 揉める暇があるなら、その時間で開発案件を1つ受注したほうが、 取り合う金額よりも明らかに多く稼げます。 案件を通して実績・信用・スキルも得られます。 次の案件を引き寄せる資産になります。 金で揉めるような相手・案件と関わり続けるより、遥かにお得です。 速やかに損切りしたほうがROIは高いでしょう。 何よりも、時間は不可逆なので、不毛な時間を費やすことは、お互いの人生に対して失礼だと思うわけです。 要するに揉めた時点で負けです。 だったら全額寄付したほうがまだマシです。

ところが問題がありまして、以下の条件を満たす寄付先が未だに見つかっていません。 心当たりのある方がいましたら、ぜひご紹介いただきたいです。

  • 社会性・コンセプトマッチ： この寄付を通して「日本のクリエイターの育成・活躍」に貢献したいです。 すぐに見つかるのは「女性向け」「学生向け」などのセグメントで区切られた団体・イベントですが、 本書のコンセプトから乖離するので対象外です。
  • 宣伝・コラボレーション： 一方的な振込で完結するのではなくコラボに繋げたいです。 結果として広告宣伝費に経費計上できる形が望ましいです。私の寄付控除が既に上限のため……。 『個人開発がやりたくなる本』執筆者一同、といった名前を掲載していただける寄付先を探しています。
  • 時期・タイミング： 継続的な枠であってほしいです。 "ハッカー協会 > Coinhive事件" は候補先でしたが、一瞬で埋まってしまいました。 悲しいことに13人と合意形成するには時間が掛かるのです。
  • 金額・プラン： 利益の範囲内であってほしいです。 "Let's Encrypt" は候補先でしたが、名前が掲載されるプランは、少々お値段が張りまして……。
  • 信頼性・リファラル： パブリックなプランが用意されていない場合、私が信頼している知人・友人の推薦があると、 お互いに安心できるのではないかと考えています。

うーむ。我ながら面倒臭い条件だなぁと思います。 だけど！！！！必要な条件を書き出したら！！！！こうなってしまうのだが！？！？

逆に言うと、将来もし自分が寄付を募る側になったときは、せめて寄付者の名前を掲載しようと思いました。

5-2. 経理について / 自費出版（合同誌）の仕訳処理

おそらくこれで問題ないとは思いますが、 もしお気付きの点があればご指摘いただけると幸いです。

  • 委託販売での売上（委託先サークル主である @nabettu さんと連携）
    • 現金払いの分 > イベント終了後に現金で受け取る
      • 借方：現金
      • 貸方：売上高
    • 現金払いの分 > 翌日に事業用口座へ入金
    • 後払い決済の分 > 金額確定後に請求書を出す
    • 後払い決済の分 > 請求書を元に振り込んでもらう
      • 借方：普通預金、振込手数料（お願いする立場なので手数料はこちらが負担）
      • 貸方：売掛金
  • Boothでの売上
    • 月末に販売数と金額が確定する
      • 借方：売掛金、販売手数料（BOOTHの取り分）
      • 貸方：売上高
    • 販売手数料はWEBコンソール「売上管理」＞「アイテム別」で確認できるので証跡としてキャプチャを取る
    • 翌月下旬に口座に振り込まれる
    • 振込手数料は毎月のメールで確認できるので証跡として保存する
  • Kindleでの売上
    • 月末に販売数と金額が確定する
    • 翌々月末に口座に振り込まれる
    • 振込時期にコンソールの支払い情報が埋まるので証跡としてキャプチャを取る
  • 執筆者への山分け（源泉徴収対象外事業者）
    • Amazonギフト券での支払い（人数分処理する）
      • 「印刷前の原稿凍結時＝最終納品」と判断（書籍奥付に記載）
        • 借方：支払報酬料
        • 貸方：買掛金
      • 事業用クレジットカードでAmazonギフト券を購入（謝礼である旨をメッセージに記載）
        • 借方：買掛金
        • 貸方：未払金
      • 翌月に事業用クレジットカードの銀行引き落とし
    • 口座への振り込み（人数分処理する）
      • 「印刷前の原稿凍結時＝最終納品」と判断（書籍奥付に記載）
        • 借方：支払報酬料
        • 貸方：買掛金
      • Misocaで請求書を発行してもらう（証跡記録用）
      • 事業用口座から執筆者の指定口座に振り込む
        • 借方：買掛金、支払手数料
        • 貸方：普通預金
  • 執筆者同士で打ち上げ＆今後の相談
    • 事業用クレジットカードで居酒屋の支払い
      • 借方：接待交際費
      • 貸方：未払金
    • 翌月に事業用クレジットカードの銀行引き落とし
  • 書籍の印刷・郵送
    • ローソンのプリンター for MVP
      • 借方：消耗品費
      • 貸方：事業主借（事業用の財布を持っていないため）
    • 割引用にPixivの有料登録（印刷終了後に解約）
      • 事業用クレジットカードで支払い
        • 借方：支払手数料
        • 貸方：未払金
      • 翌月に事業用クレジットカードの銀行引き落とし
    • 日光企画への銀行振込
      • 借方：印刷製本費、前払金（支払い後に「この割引も適用されるのでは？」→「ほんまや！」→「余剰金は次回繰越で！」）
      • 貸方：事業主借（諸事情で事業用口座のWEB振込機能が一時的に使えなかったので私用口座から振込）
    • 書籍の郵送
      • 借方：通信費
      • 貸方：事業主借（事業用の財布を持っていないため）
  • 読者還元キャンペーン（ブログで本書を紹介するとAmazonギフト券をプレゼント）
    • 事業用クレジットカードでAmazonギフト券を購入
      • 借方：広告宣伝費
      • 貸方：未払金
    • 翌月に事業用クレジットカードの銀行引き落とし
  • 在庫の管理（三分法を採用）
    • 製本時の原価を計上する
      • 借方：仕入高
      • 貸方：支払報酬料、印刷製本費
    • 関係者への献本
      • 借方：広告宣伝費（＝配布した本の冊数 * 印刷した冊数 / 製本時の仕入高）
      • 貸方：仕入高（＝配布した本の冊数 * 印刷した冊数 / 製本時の仕入高）
    • 在庫と販売数記録が合わない
      • 借方：棚卸減耗費（＝紛失した本の冊数 * 印刷した冊数 / 製本時の仕入高）
      • 貸方：商品（＝紛失した本の冊数 * 印刷した冊数 / 製本時の仕入高）
    • 決算整理
      • 借方：期首商品棚卸高（＝0）、商品（＝残っている本の冊数 * 印刷した冊数 / 製本時の仕入高）
      • 貸方：商品（＝0）、期末商品棚卸高（＝残っている本の冊数 * 印刷した冊数 / 製本時の仕入高）

こうやって振り返って思うのですが、複式簿記は便利な道具ですよね。 正確に帳簿を付けさえすれば、正確に事業活動を可視化できる。 こういう仕訳の実例がもっと世に出ると良いなぁと思いました。

6. 仲間と歩む

6-1. チーム：採用（知見）

最初はSlackやTwitterで呼び掛けました。 「いまサービスを作っています」「これからサービスを作ろうとしています」という方はお断りしました。 リリース経験のない人は、本を書くよりも、まずリリースに専念してもらうのが一番だと考えたからです。

また、イベントでLTをしたり、交流会で声を掛けたりもしたのですが、 そういった場所ではポジティブな反応は得られませんでした。 「そんなの売れるんですか？」「そういう合同誌は失敗しやすいですよ」とか言われました。 ベテランの皆様は手厳しいですね。

各種SNSのDMで以前から知っている人に相談するのが、最もコンバージョンしました。 知人スカウトが効いた理由は2つあると思っています。

1：お互いを知っているのでワークしやすい。 既に信頼貯金があるので、関係構築の工程をスキップできました。 相手がどういうタイプか把握しているので、最短のコミュニケーションを取ることができました。 めちゃくちゃやりやすかったです。

2：相手に対する期待を明確にしやすい。 理由なしに声を掛けたのではなく 「自分は今こういうことに困っている」「あなたのこういう点をすごいと思っている」 「だからこういう点で力を貸してほしい」のフォーマットで相談しました。 この期待に答えてくださったと思っています。 この期待に答えてくださるような方々だと知っていたからこそ、相談したのです。

なお、人数面では、当初「10人の合同誌」を想定しました。 日常生活で10進数を扱うことが多い私たちにとっては、違和感なく受け入れられる数字です。 2桁なので「合同誌」であることを強調できます。

ただ、人数はコンセプトを投影できるポイントなので、最終的には「13人」という数字にしました。 不吉な数字。「1」と「自分」を除けば、何者にも割り切れない数字。 反骨心溢れるクリエイターたちに相応しい数字。 世に抗いながら生きる、闇の探求者たちの数字。 だけど、あくまでも「1」ではない。 このプロダクトのコンセプトにこれ以上なく適した数字だと思いませんか。

6-2. チーム：活躍（感謝）

各メンバーが、それぞれの得意なフェーズに、それぞれの得意な形で活躍していたなぁと思います。 私はひたすら「どうしよう」「つらい」「こうしたい」「うううう」しか言っていなかった気がします。

1 - 立ち上げ期：過去に一緒に仕事をしたことのあるメンバーに助けられました。 特に @macinjoke は迅速に原稿を書き上げてくれました。 その原稿がなければ、あっという間に私の心が折れていたでしょう。 自分以外の誰か1人でも共感してコントリビュートしてくれたというだけで心強いものです。

また、 @isbtty7 と Tanem Apps が 快く協力してくれました。 カルチャーが同じでお互いを良く知ってる人。スピード感がある人。 早い段階でコンテンツが集まったからこそ、スムーズに走り出せたと思います。 新しいことを始めるときは、アウトプットこそが正義です。 アウトプットが遅いと、アウトプットしないから経験値が少なく、 経験値が少ないから知見を持たず、知見を持たないから議論が的外れになる。 行動に繋がらない議論が続いてばかりだと、私にできるのは 「とりあえず原稿を書いてみましょうか^^」botになることだけです。

2 - 混乱期：「いやいやここは決めないとダメでしょ」で大議論になりました。 主に @tRaieZ1 さんがメインになって声を上げてくれました。 言いにくい中ではっきり言ってくれたのはありがたかったです。 タックマン・モデルにおける「混乱期」を突破しないと、チームは機能しません。 13人もいるのに混乱が起きなかったらそれこそ不自然です。 水面下で不満を言うか、テーブルの上でぶつかるか、2つに1つです。 ここで遠慮なく意見を言ってくださる人がいたことは、 チームの進化において意味があったと思います。

3 - 広報発信期：対外的な動きを活性化させたいが、手が回らないという状況でした。 @rubys8arks さんの推進力に助けられました。 私がプロダクト（書籍内容）のブラッシュアップ作業を人に振ることができず、 マーケティング・セールス・対外広報が何もできていないという危機感がありました。 当時の私の焦りっぷりは自分でもひどかったなぁと思っています。 そんな状況の中で、一歩踏み出して、ボールを拾ってもらえました。 本当にありがたかったです。 一方、ここで私が根本原因を解消できなかったことが、今回最大のミスでした。

4 - エンハンス期：着々とプロダクト改善を進めていただきました。 安定感のある方々、@ShiraAndroid さん、 @hrz31 さん、 @morizyun さんが、 コツコツと担当原稿をアップデートしてくれました。 毎週リリースの度に、3人のうち誰かしらが原稿を更新していました。 差分があるというのは大事なことで「あの人が頑張っているなら自分も頑張ろう」と勇気をもらえます。 そうした勇気を与え合えるからこそ、最後までやり抜けるのだと思っています。

5 - 炎上＆追い上げ：経験豊富な10年選手たちが粘り強く付き合ってくれました。 @mogya さん、 @dala00 さん、 @nabettu さんがサポートに入ってくれました。 それぞれ広報・印刷・会場のタスクを進める傍らで、 私が呪いの言葉をSlackに吐きながら作業しているのを見ては 「うんうん」「わかるわかる」「そうだね」「がんばれ」「あとちょっと」とひたすら励ましてくれました。 ここは幼稚園かな？恩は忘れません。

炎上の原因ですが、マーケティング（広報）とプロダクト（本）にギャップが生じました。 対外的には「こうします！」と言っているけど「本の内容は全然違うじゃん！」という状態です。 いわゆる営業とエンジニアの対立みたいな感じですね。 それはそれで健全ではあります。 異なる視点がぶつかり合うからこそより良いものができるはずです。 が、最終意思決定者が存在しない合議制だったので、全てが泥沼になりました。

時間が経過して「もう猶予はありませんよ」という状態になったことを全体に伝えたあと、 本当は打ちたかったプロダクト施策＆マーケティング施策の多くを諦めて、さまざまな調整を掛けました。 意識が朦朧としながらひたすら怒涛の50時間編集。 Crieitに軸足を置いて対外広報メッセージを軌道修正。 同時並行で印刷やイベント参加の手続きを進めました。

6 - 販売・打ち上げ：終わりよければ全て良し！ @Meijin_garden さんが大活躍でした。 実は最初のキックオフでも盛り上げてくれていて、完全にイベント大臣のブランドを築き上げています。 当日は委託先サークルの @_hyme_ さんにもお世話になりました。

6-3. 利用したシステム・ツール

GitHub + md2review + ReVIEW： TechBoosterのリポジトリをCloneして、md2reviewで変換するスクリプトを追加しました。 マークダウンで原稿を書いて、GitHubで管理して、md2review → ReVIEW → PDFファイルを出力します。 ビルドについては私が突貫で作った仕組みがずっと動き続けることになりました。 @mogya さんがGitHubとSlackを連携してくださって、一気に盛り上がりました。 もっと色々とハックしたら楽しい執筆体験を実現できたのではないかとは思います。 TechLeadというかシステム整備担当を1人設けたほうが良かったかもしれません。

Keynote： 表紙・目次・各部の扉ページ・アンケートの見開きなど、 ReVIEWで表現できないレイアウトはKeynoteで作りました。

Adobe Photoshop： 印刷所への入稿に当たって利用しました。 @mogya さんが最後の仕上げで一役買ってくださいました。

Slack： フロー情報のやり取りに使いました。 課題ごとにチャンネルを作り、完了したらクローズしました。 @rubys8arks さんがスタンプを一括インポート → コミュニケーションを盛り上げてくれました。

Facebookメッセンジャー： Slackでの議論がカオスになりました。私の責任でもあります。 「今その議論をしても生産性ないからアウトプットを早く出そうよ」と思いながらも、上手く促せなかった。 で、後半に誘ったメンバーは議論に巻き込まないように、メッセンジャーで私が個別にやり取りしました。 改めて言語化すると、かなり evil だ。 正論で解決するならそりゃそれがベストだけれども！

Scrapbox： ストック情報の管理に使おうとしたのですが、残念ながらすぐに使わなくなりました。 私自身をはじめとして、メンバーは誰も使いこなせていませんでした。 「有名な人が良いって言ってたから」という理由で慣れないツールを使うのは本当に良くないですね。 ツール導入の基本です。 まずは自分が試しに小さく使う。 ワークする確信が持てたらチームに導入する。 このステップを踏んだかどうか確認してから承認する。 会社で当たり前にやっていたことを、なぜ私は自主活動だとできなかったのだろうか。 余計な問題が起きるくらいなら G Suite だけで良いのではないかと最近は思っています。

6-4. プロセス：アウトプット（初稿提出）を重視

執筆初心者向けに以下のように伝えています。 Slackからコピペします。

特に「ポエムやノウハウを書こうとして筆が進まず悩んでいる」という方がいたら、ぜひ参考にしてください。

・やったことを淡々と書くだけでもそれなりの内容になる
・感動する文章や役に立つ文章をがんばって書こうとしなくていい
・むしろケーススタディとして貴重な内容になる
・同じことを言っていても運営するサービスが違うとニュアンスも違ってくる
・だから具体的なサービスやエピソードがあると分かりやすいし、その人ならではの個性や魅力が出てくる
・こういうのがいっぱい集まるだけで本の価値になる
・だからブログやQiitaのコピペで何も問題ない
・「がんばって書くこと」（手段）じゃなくて「良い本を作ること」（目的）にフォーカスしたら、ラクな方法はいくらでもある

こういったことに気付けると、筆が進みやすくなるのかなと思います。

書籍の奥付に記載した「Joined」は（一部の例外を除き）参加表明日ではなく初稿納品日にしています。 この手の自主活動ではフェードアウトする人がいるので、宣言ではなく成果物だけを「正」としました。 途中からは「初稿提出済みメンバー」で相談事項を会話して 「未提出者」には「まずは初稿執筆に専念してください」と案内しました。

というのも、最初に議論するだけ議論して、ルールを決めた張本人が真っ先に消えて、 どうでもいいルールだけが残る、といった悲劇を懸念したからです。 関係者全員が疲弊するだけで、アウトプットがゼロだと最悪です。 「成長だけが痛みを癒やす」とはグロースハックの根本原則です。 グロースハックに携わる個人開発者なら、グロースにコミットする存在であってほしいと願っています。

アウトプットに貢献するのは、予防線を張ることにエネルギーを費やす人間ではなく、 アウトプットの創出にエネルギーを費やす人間だと思っています。 ゆえにアウトプットを重視しました。

「議論はもういいから早くアウトプットを出そうぜ！」と、 あの手この手で伝えようとし続けた、私のSlack発言集をご覧ください。

いただいたアドバイス： 製本とか販売はどうとでもなるから、執筆に意識を傾けよう。 とにかく書き出そう。まずはアウトラインを書いてみたらどうか。書き出してみると発見がある。 他にも細かい話は色々とありましたが、ざっくりこんな感じでした。

書きづらい人は、ブログやQiitaの内容をベースにしたら良いのでは？

xxxやxxxの編集者の方と話すと 「多めに書く分には後からカットや編集しやすいけど、 少ないものを付け足すのは大変なので、 執筆者は変に体裁や文字数を意識せずどんどん書いてくれるのが一番助かる」 というのは皆さん口を揃えて仰っていました！ 執筆の王道パターンだそうです！ 個人開発で言うところの「環境構築に時間を掛けてリリースできない」 みたいな状態になるのがモチベーション的にも一番辛いので、まずは中身を埋めたいっす！

20分の突貫工事ですがPDFを出力してみました！ドヤ！

書き出しやネタが思いつかない人：ターゲットやメッセージを考えてみる。ブレスト的にここで会話する。 既に思いついている人：書き出してみる。他の人の意見は参考にしつつも、無理に引きずられなくても良い。 という形で、まずは走り出してはいかがでしょうか？

『はじめての技術書ライティング』という本だと「です・ます」を推奨していますね。 ですが、まずは書きやすい形で20点版を書き出す → 本に反映してみる → 推敲を重ねていく （そこで文体や記号の使い方などチェックする / 他の原稿と合わせたときの違和感などを確認する） で良いかと思います！

とりあえずコンビニで印刷してみました！本だー！

みなさま、形だけでも埋めたいのですが（目次欄の雰囲気を出すためにも）、 Qiitaやブログのコピペをマークダウン形式でいただくことって可能でしょうか？？？ 「本を書くぞ！」「執筆するぞ！」って考えると、作業着手のハードルが上がって辛いだけなので、 むしろぜひ「作業時間5分のコピペ集」をバージョン1にしたいです！

ブログやQiitaのコピペを中心に、低コストで作成したかったですね。 仮にWordPressをmarkdownに変えるのに手間取ったとしても、 1週間あれば全員の原稿が集まるだろうと思っていました。 後工程でやりたいセールス・マーケティング施策が山程あったので、初稿をいかに早く集めるかが鍵でしたね。 中途半端に遠慮して遠回しな伝え方をしたのはミスでしたね。 うぐぐぐぐぐぐぐ。

6-5. プロセス：ブラッシュアップ（改善）を重視

CanaryReleaseで！かなりリリース！（ドッ

『文章を整える技術』『超スピード文章術』を読んで思いました。 文章は「書き上げて終わり」ではなく推敲あってこそです。 プロダクト開発と同じです。 リリース後が本番です。 磨き込みにこそ価値があります。 せめてサイトを運営する個人開発者には分かってもらいたかった！！！

毎週PDFをアップデートしてメンバーに配りました。 いわゆるCanaly Release（カナリアリリース）です。 身内やチームメイトにPDFを読んでもらって、著者本人が何度もPDFを読み直して、 気になったところを手直しする、という座組みです。 書籍を販売して、あとで読み直してから「あそこを直せば良かった」みたいなことを言いたくなかったです。 私は100回以上読みました。 にもかかわらずTypoがあった！！！

少なくとも納期ギリギリに提出するような進め方だけは回避したかったです。 回避したかったです……。 百害あって一利なし。 お手本として自分の原稿は初日に仕上げました。 これで勢いをつけたかった。 そこから全員の原稿が出揃うまで4ヶ月。 初稿から全面的に書き直された第二稿が、最後の最後で突然提出される。 Canary Release の意味とは。 「素早く出そう」って個人開発では散々言うとるやないですか……。

くぅ〜〜〜。難しい。一筋縄じゃいかないものですね。 逆に言うと、ここを上手く仕組み化できれば、今後の複数人プロジェクトでは、 可能性が一気に広がるということ！！！

（と言いつつ、私も人のことを言えませんけどね。 商業版の編集が！遅延しまくりんこ！ 頭ではね！分かっているんですけどね！）

6-6. チーム：運営（反省）

チーム運営はお世辞にも上手くいったとは言えません。 お恥ずかしい話ではありますが、少々強引な手を使って、無理やり話を前に進める場面もありました。 私の至らなさだと反省しています。

1：そもそも13人もいると合意形成が極めて困難でした。

「こういうポリシーで進めます」「こういう哲学を大切にします」というマニフェストを最初に作るべきでした。 ただ、「そのポリシーや哲学やロードマップを13人で合意する」（＝大変）という循環参照が生じないように、 最初は私の仕事の進め方を知っている人と一緒に草案を作って、共感してくれる人だけを歓迎する。 その方が余計な擦り合わせをしなくて済むのではないかと思います。

また、最終的な意思決定者については握るべきでした。 ハード（決まり）がなくても、自分のソフトパワー（影響力の行使）だけで、上手くやれる自信がありました。 一応無事に終わりましたが、かなり無駄な時間とエネルギーの使い方をしたと思っています。 意思決定者が明確なだけで多くの問題を回避できたはずでした。

2：メンバー1人に1ロール以上をお願いするのは無理がありました。

「原稿を書く人」「編集する人」「対外広報する人」「進行管理する人」など、 明確にロールを分けたほうが良かったと思っています。

でなければ、1冊の本を仕上げるだけでも、難易度はそこそこ高くなります。 ただでさえ仕事の合間に貴重な時間を確保してもらっているのに、 あれもこれもと全員を議論に巻き込んで、1ロール以上を押し付けてしまいました。 いつまでたっても各自の担当原稿が進まないのは当然のことでした。

「むしろこの状況で投げ出さずに良く書き上げてくれたよなぁ」と、 今になって、改めて、感謝の気持ちが湧いてきました。

ロール分割はマーケティング・セールス施策の改善にも繋がるでしょう。 エグゼキューション面での敗因は「プロダクト側のタスクを自分が抱えてしまった」からだと思っています。 例えば「プロダクトのリード1人」「マーケティングのリード1人」を立て、私が全体を見たら、 もう少し上手く動けたのではないかなとか妄想しています。

でもなぁ〜〜〜、こういうの、振り返りで「こうすべきだった」と言うのは簡単なんだけど、 じゃあ実際にやるとしたら、誰に何をどうお願いしたらワークするんじゃい！ってのはありますね。

7. 自分を導く

7-1. 最初こそモメンタム（勢い）を重視

本を作ろうと決めて、即座に自分の原稿を書き上げて、ローソンで印刷した「MVP」がこちらです。

見てくださいよ。この手作り感。このスタートアップ感。最高じゃないですか。 このMVPを持ち歩きながら企画について何人か壁打ちをさせてもらいました。

「実際に手に取れるもの」「実際に見えるプロダクト」があると、論点がシャープになります。 空想ベースで筋の悪い議論を進めるよりも生産性が高いと思っています。

7-2. Googleカレンダーで「作業時間」と「場所」を確保

モチベーションに身を委ねていては（私の場合）なかなか進捗が出ません。 未来の自分が「モチベーションが上がらなかったのでxxxできませんでした」と言い訳する姿を想像すると 「気持ちは分かるがお前の人生それで本当に良いのか」と言いたくなります。

なので「いつ」「どこで」「何をするのか」を決めるように心掛けています。 私の場合、作業が前に進まないとしたら、最大の理由は「着手していないから」です。 着手さえすれば何かしら前進するはずです。

『天才たちの日課』『なぜあなたの論文は進まないのか』にも似たことが書かれています。 執筆を生業にする人たちは、一気に書き上げるように思われがちです。 しかし、実際は違っていて、毎日コツコツと書くのが有効だそうです。 特別な理由がないのなら、プロのやり方・デファクトスタンダードを模倣するのが、妥当だと思います。

7-3. 最後は自分で帳尻を合わせる

50時間以上を費やして、怒涛の原稿編集を行いました。 発狂するかと思いました。 というか発狂しました。 最後はだいぶ荒れていた気がします。 反省しています。 まぁ、その甲斐あって、最低限のクオリティは担保できたと思うので、勘弁してください。

合同誌に限らず、最後に帳尻を合わせられる人がいるかどうかで、 共同プロジェクトの完成度は変わるだろうと思います。 辛いのは分かっているけど、そこで文句を言いながらでも、躊躇せずに貧乏くじを引く。 私の思う「強い現場」というのは、そういう人たちのことです。

もともと、これができる自信と実績があったからこそ、合同誌で行こうと決めました。 PyConJP（ベストトークアワード受賞）の資料は一週間前に白紙に戻してそこから150ページを作ったので。 翌年のデブサミ（ベストスピーカー受賞）の資料は前日で一気に白紙から280ページまでまとめ上げたので。

ただ、こういうのは、できることなら、もう二度とやりたくない、とは思います。 プロフェッショナルなチームで安定して高いパフォーマンスを出したいですね。 そういうチームが自然と形成されるような進め方・促し方を、私自身が身に付けていきたいですね。

終わりに

商業版について

ありがたいことに、出版社から刊行の話をいただいています。

  • 商業版のタイトルは変更する予定です。 本の表紙を見た人が思わずニヤッとしてくれると嬉しいなぁと思っています。
  • 同人版そのままではなく別バージョンにする予定です。 レイトマジョリティ向けで、商業版のほうが全体的にリッチな内容になります。
  • 現在発売中の本は、良くも悪くも同人誌です。 筆者と読者が同じ目線に立って、お互いに語り合うための本です。 「クリエイターを鼓舞する本」だと認識しています。 アーリーアダプター向けです。
  • 両者の内容は8割方は同じですが「同人版でしか読めないコンテンツ」と 「商業版でしか読めないコンテンツ」を設けます。 ポケモンの赤と緑のようなものです。 商業版を買った人の一部が「同人版も買おうかな」と思うようなフックは仕掛けたいと思っています。 思ってはいますが、仕掛けられないかもしれません。

何が言いたいかというと、このブログの読者に関しては、商業版を待つくらいなら、ぜひ同人版を買ってください。 そして、できれば商業版も買って、二度楽しんでください！笑

商業版の出版時期は未定です。 Twitterで告知しますので、興味のある方はぜひフォローよろしくお願いします。

もし話が白紙に戻ったとしたら、それは私の作業が遅すぎたせいだと思ってください。 私の負担を軽くしてくれるような素敵なビジネスパートナーたちに出会いたいなぁと願いながら、 私は今日も元気に生きています。

成功だったか？失敗だったか？

成功でした。最高の1冊になったと思っています。 この企画を否定した人たち ―― 分かっていないやつら ―― を、 知恵と工夫で出し抜いたのは、企画屋冥利に尽きるというものです。 世の反逆者というか、闇の探求者というか、こういうのは「個人開発」っぽくて好きです。

そして、失敗でした。私の心の中は敗北感と焦燥感だらけです。 1冊の形にまとめるだけで手一杯でした。 広義の企画力を伸ばしたいと思いました。 この記事を読み返すとプロダクトデザインばかりに目が向いています。 最初の狙いに比べると、数ヶ月掛かって（＝高コスト）、10xを逃した（＝低リターン）という失態。 もっと上手くやれたはずでした。

正直なところ、マーケティング（特に「勝ち筋を模索する分析業務」と「高速にPDSサイクルを回す業務」）を やらせてもらえる会社があれば、今すぐにでもジョインしたいくらいです。

また、もっとクリエイターとして挑戦したいと思いました。 編集の過程で、この本を100回以上読み返して、他ならぬ私自身が一番背中を押されました。 私のやりたいことリストには1,000個以上のアイデアがあります。 この本の出版でようやく1つを達成しました。 まだまだ実現したい企画だらけです。

Reconnected ...

プロジェクトが炎上して大変でした。 良くも悪くも自分は「1つの会社での働き方」が染み付いていて、 外でやるとこんなにも違うのかと痛感しました。 これはまずいぞ。 個人で活躍していきたいなら、さっさと外に出たほうがいいぞ。 そう思いました。

そして、それ以上に、めちゃくちゃ楽しかったんですね。 他の執筆者と交流したり、彼らの原稿を読んだり、 ディスカッションしたり、自分の企画が人を動かしたり、 描いたアイデアが形になっていったり。 こんな楽しいことを思い出してしまったら、もう止められないですよね。 「もっとチャレンジしたい」「自分の企画を次々と世に出したい」という欲望が溢れてきました。