「よくわかるAuto Layout」を執筆した話

先日、私の執筆した「よくわかるAuto Layout」が発売されました。とても貴重な経験ができたと思うのでまとめようと思います。

経緯

はじまりは、2015年元日。新しいメモ帳に「本を書く」と目標を書いたことでした。他にも目標があって、ベンチプレスの自己記録更新や、シックスパックを手に入れるとかそのうちの1つです。

きっかけは、前職のGunosyで第13回potatotipsを開催したときに突然訪れました。懇親会で@tokoromさんにアイデアを話したところ、「お、いいね！」となり出版社の方を紹介してもらえることになりました。その後、出版社の方との顔合わせミーティング、企画の打ち合わせなどがあり、執筆することになりました。このときはまだ、これから待ち受ける困難には気付いていないのでした。

開発体制・フロー

著者（私）
監修(@tokorom)
出版社
編集の方々

マークダウンで記述し、1章ごとに、Github上でPull Requestを作るというスタイルでした。今考えましたが、通称GMSフロー（Github+Markdown執筆フロー）です。私にとって、はじめての執筆だったため、私が書く、編集がチェック、修正依頼を送るみたいなプロセスを複数回繰り返しゲラ*1ができ、その後赤入れ*2を繰り返しやるという形でした。*3

執筆中抱えた課題

どこから手をつけたらいいかわからず、過去のブログ記事と関連する第6章「実装基本パターン」から手をつけることに。この章は、Auto Layoutを用いたレイアウトをパターンに分けるという試みの章です。時間をかけて書いたブログ記事を元に書いたので上手くいくと思っていましたが、このファーストドラフトはひどいものでした。まず、長文を書くということができませんでした。また日本語や全体の設計にも問題がありました。*4

長文が書けない

最初の問題は、内容が表面的すぎたことです。十分な深掘りができておらず、結果的に最初に書いた章のドラフトは短すぎました。それでも、この時書いた量は、気合の入ったブログ記事位の長さでだったので、「俺頑張った」と思っていました。

日本語の問題

日本語らしい書き方ができていないこと。昔から国語が大の苦手だった私。中学の時、4分の1か4分の2と言いたくて、4分のちょっとって言ってたくらい、国語力は低いです。さらに、文章の書き方は留学中に学び*5、学術論文を通して学んだので、特徴的な文章となっていました。日本語は英語よりも接続詞をよく使うとか、主語をはっきりさせるとかいった、当たり前のレベルからはじめる必要がありました。

全体設計

200ページ以上あるので、全体を見てメッセージを発信するのが非常に難しかったです。私は、まず目次を作ることにしました。しかし、書き進めていくと、内容の追加、入れ替えが必要になったり、書籍の目的を考えなおすなんてこともありました。また、コンテクストがある程度共有されているブログと違って、前提条件から説明し、かつ深掘りする必要があります。苦手だからこの内容は飛ばそうみたいなこともできません。一歩引いて全体を見ながら、時には必要以上に近づいて対象技術を観察する必要がありました。

対策

これらの課題はエンジニア的思考で解決することができました。

長文が書けない

これは書くことでしか解決されませんでした。コードと一緒です。ただ、長文が書けないので、書きはじめることができません。「鶏が先か、卵が先か」です。そこで、私はまず口語で書くことにしました。例えばこんな感じ。

iOS 8 ではオリエンテーションという考え方がなくなった。むしろ考えないで欲しい。デザイナーと縦横で話すのはやめよう。sizeでやろうぜ。 UITraitCollectionを使おうよ。やばいんだって、こいつ。

口語で書くと、まだ書くことができたので、アウトプット量を増やすという意味と自分の思考を整理するという意味で、ひたすら書き続けました。

日本語の問題

小さい単位で、編集の方にレビューしてもらうというのを繰り返しました。Pull Requestは小さい単位で出し、早い段階でレビューをもらい修正してもらう。これもチーム開発と似ています。失敗を多く犯しながら、失敗を元に、少しずつ自分の日本語の問題を解決していきました。

全体設計

本を書いたことがなかったので、先に目次を作るなんてアプローチがまず間違っていました。プログラミングをしたことない人が、クラス設計から入るようなもんです。全体像をざっくり考えた後、プロトタイプをさっと作る、そのプロトタイプを元に全体を修正する、そんなアプローチが必要だったと今では思います（このトピックは中島聡さんの本がおすすめ）。

また、プログラミングと同様に、コードを書き、リファクタリングすることを繰り返し、ようやく良い設計に近づいていけるのだと思います。文章の書き直しもリファクタリングだと思うと、書くことや修正することに対する心理的障壁がぐっと下がります。ソフトウェアだと考えれば、一度動くものを作って、形を整え、必要があれば作りなおすなんてことも、できるようになりました。*6

その他

執筆は、困難が多かったですが、それによって得たことも大きいです。

まず、執筆を通してアウトプットを続けたので、文章に対する取り組み方が変わりました。未だに苦手意識が強いですが、日本語で長文を書くことへの抵抗感は減ったし、ある種のスタイルが確立したのは良かったです。また、技術要素についても網羅的に知識を整理することができたので、取り組み方、見え方が変わり、コードを書くときも少し抽象的な視点から物事を捉えられている気がします。

割りと辛かったのは、1年間、外部世界と切り離されていたことです。これは、アウトプットにエネルギーを注ぐため、自然とインプットの量が減るためです。時間を主に使う技術は執筆内容に関連したものになるため、新しい技術、注目されている技術をこれまで通り深掘りする時間を確保するのが非常に難しかったです。執筆をしている間は、情報の取捨選択、時間の効率化に気をつけていました。また、友人と遊ぶ機会も減るので、修行僧のような気持ちになることもありました。