『iOSアプリ設計パターン入門』を書き続けた約半年を振り返るエモブログ

おばんです、すごく遅れて話題のアニメを見ている田中です。メイドインアビスしんどいアニメですね...、楽しかったです、二期はよ。

さて、今回はPEAKSから出版された『iOSアプリ設計パターン入門』が、企画から半年以上続けてようやっと購入者の方々に届き始めるに至ったので、その期間で溜め込んだエモをぶち飛ばしていくぜ!!!🚀💥 (電子版は出ているなうです、製本版はもうしばしお待ちください🙏)

本を書いている期間は忙しくてあまり経過を書けなかったので、特に記憶に残った出来事を振り返ろうと思いました。 幸せも苦しみも全部詰め込みます。


peaks.cc

『iOSアプリ設計パターン入門』は技術書クラウドファンディングのPEAKSから出版された、iOSアプリの設計パターン本です。 現場で活躍するiOSエンジニア複数人で書き上げた生きた技術書です。

まずはじめに応援してくれたみなさま、ありがとうございます!そしてお待たせしてすみません! この本はありがたいことに、正式版リリースまでに1377人もの方に予約いただきました。 読者、企画、編集、執筆、様々な担当の方々によってこの数字を達成できたことを、とても喜んでいます。

技術書の始まりでやたら感謝しまくる海外の執筆者いるじゃないですか、今完全にあれです。今すべてに感謝しています。 あわよくば、「この本を書くにあたり、支えてくれたシンディへー」みたいな恋人に宛てたアレとか書けたらよかったんですが、あいにくーーー🤤

これは余談ですが、1377冊の購入って、技術書のくくりだとすごい数のようです。 小説だと「何万部突破!」とか目にしますが、一般的な書店に並ぶような技術書は、購入者の母数が多い入門者向けの本でも2〜3000部が初版でそれっきりということも少なくないということを風の噂に聞きました。 しかもクラウドファンディングでの達成。PEAKSの積み上げてきた圧倒的信頼を感じます。

このあとに一般販売もあるはずなので、お楽しみに!

すべてはここから始まった

PEAKSのながのさんとのTwitterでのやりとり。 完全にノリです。

f:id:ktanaka117:20181202164628p:plain

なんなら巻き込みも発生。

f:id:ktanaka117:20181202164644p:plain

ここから設計に心当たりのある、確実な執筆陣に声をかけていってプロジェクトはスタートしました。

キックオフミーティング

おかげさまで開始から半日ほどでクラウドファンディングは達成しました。爆速です。

ミーティングは執筆者それぞれで書きたい章構成を持ち寄って、つき合わせました。

  • 設計には多くの派生や誤解が存在しているので、全体をとりまとめる難しさがある
    • 初出に立ち返って情報を整理することで、オリジナルのアーキテクチャパターンのキモが、iOSではどう取り扱われるべきかをまとめる必要があった
  • 設計を学ぶ上で、コンセプトを追うだけでは正しい理解が難しく、コードを書くことでアーキテクチャパターンに対する認識が合う
  • いついかなる時でも通用する、絶対最強のアーキテクチャパターンは存在しないということを伝えていきたい

などの話し合いを元にして、思っていたよりもサクっと大枠は決まりました。 この時点で執筆陣全員がこの共通認識や課題感を持っていたのは、非常にプロジェクトを進めやすく、心強かったです。

合宿

  • 進捗どうですか?(圧
  • 改めて認識を合わせる
  • 一気にかき上げようゼ

などなどの目的から執筆合宿に行きました。 気分は文豪です。その時の様子は、以前のブログにまとめました。

tanakalivesinsendai.hatenablog.com

合宿では調べた内容を話し合ってつき合わせたり、理解に間違いがないか確認していきました。改めて当初の目標や課題に間違いがないことも確認できました。 執筆に対する意識やモチベーションも上り調子でした。

無

合宿で持ち上がったモチベーションでしたが、その後は安心からか無の期間が発生しました。 おおまかに書けていた部分は多かったですが、無になると筆も遅くなって出てくるものがなくなり、そこには無限の苦しみがありました。

書きたいものはあるんだけど、良い言葉に乗らない。 普段書き慣れたブログでは、起きないことでした。 ブログを書き始めた頃を思い出していました。

「助けて」を言う

あれよあれよと時間は過ぎて、もう本当にどうにかしなければいけなくなって、プロジェクト内で相談。 筆が進まない部分を整理して、鈴木さん、杉上さん、加藤さんを中心にヘルプを出しました。 担当章の中では一番慣れの少ないMVVMで多くの助言をいただいたり、スケジュールの調整などで助けていただきました。 ありがとうの言葉では足りないものですが、本当にありがとうございました。🙇‍♂️

そしてストレスで胃がマッハ。 燃えたプロジェクトとか、元カノとの別れ話とか、過去これまでに味わった様々な辛い状況がなぜかフラッシュバックして、脳死しながらもなんとか手を動かしました。

立て直し

気持ち面で死んで「なんで書くんだっけ」を見失っていたので、この本を書きたかった原体験を整理しました。 そのときEmo issueに貼っていたのがこちら。

f:id:ktanaka117:20181202181653p:plain

限られた業務時間の中できれいに整えられたコードが書けず、目標とする正しい形がわからないまま書き進めるプログラミングは、非常に苦しいものでした。 なんとか汚いものを組み上げれてやり過ごしたとしても、後の自分自身の首をしめました。 自分以外が担当することになっても、苦し紛れのコードは git blame という悲しみの連鎖をうみます。

いざ「設計」というものに出会い、その目的がなんとなく理解できても、概念的な解説が多くて理解できず苦しむ日々が続きました。

画像の「当時の自分」「昔の自分を助ける」というのは、このような状況を指します。 自分と同じように苦しんでいる人の助けになれてこそ、過去の自分を救うことに繋がるというのが、この本を書くモチベーションでした。

モチベーションを思い出して、なんとか筆を持ち続けました。 「イケる!」「無理...」の躁鬱を繰り返しながらも、イケる気持ちのときに足りていない情報を整理して、構成を立て直しました。 論文を読み返したり改めて説明が必要な部分を洗い直すと、良い筋道が見つかり、内容が濃く自分で納得できるものが書けました。

反省

立て直しはできたものの、プロジェクトは遅延してしまい、先行購入者のみなさまには大変ご迷惑をおかけしました。深く悔やんでいます。 遅延の報告ではPEAKSにかけてしまった迷惑も、申し訳ありませんでした。

もし次に本を書くとしたら、以下のことについて基準を設けて臨みます。

みんなで「おつかれさま」を言えた

自分はなんらかのプロジェクトをやると、その後連絡が途切れたり、迷惑をかけすぎて関係修復するのも申し訳なくなるようなことも過去には多く経験してきました。 正直プロジェクトを始める前から不安だったけれど、それを加味しても世に出すべきテーマの本だと思ったので、「おつかれさま」をみんなで言えたときは本当に泣きました。 (loveeさんのお疲れ様はタイミング合わなくて見つからなかったけど、仲良くやっていますw)

f:id:ktanaka117:20181202190326p:plain

f:id:ktanaka117:20181202190344p:plain

f:id:ktanaka117:20181202190533p:plain

f:id:ktanaka117:20181202190356p:plain

f:id:ktanaka117:20181202190546p:plain

さいごに

紆余曲折はありましたが、最高の本を仕上げられてとーにーかーく、嬉しいです。 これから読者のみなさまの元に届いて、参考に、そして楽しんでもらえる本になれば完全なるプロジェクト成功です、お楽しみに!!!

おまけ

f:id:ktanaka117:20181202191320p:plain