GitHubを使って複数人での原稿管理するときのコツ
🔧008 ごりゅごファミリーから新しい本『iPad Workers Apple Pencilで使いこなす次世代型ノートアプリ』が発売されます
12月2日に、ごりゅごファミリーから新しい本『iPad Workers Apple Pencilで使いこなす次世代型ノートアプリ』が発売されます。
この本は、2021年5月に公開した『iPad Workers ノートアプリとApple Pencilの活用』に継ぐシリーズ2作目の本です。
著者「五藤晴菜」で、ごりゅごは"ゴーストライター"として「晴菜さんに話を聞いてテキストをまとめる」というお仕事をこなしました。
どんな内容の本なのかについてはiPad Workers Newsletterに書かれているので、お時間あればそちらをご覧いただけたら幸いです。
iPad Workers Newsletter | はるな👠iPad Worker | Substack
今回は、ナレッジスタック的な目線で本のプロモーションを行うべく、本の内容紹介ではなく、本を作る過程で学んだことをまとめてみようと思います。
「チームでの本作り」を通して「チームで仕事をすること」の難しさを知り、同時にチームで仕事をこなすことの重要性なども改めてよくわかりました。夫婦で何冊か本を作ってき増したが、今回ついにようやく安定してうまく進められる方法が見いだせたような気がします。
共同作業の難しさとGitHubの難しさをごっちゃにしない
今回の執筆で一番役に立ったのは、ほぼ間違いなく「GitHub」です。
GitHubを使った書籍原稿の共有も通算3回目となり、ようやく運用のルールが一通り整って、これまでの反省点も上手くいかした「チームでの執筆」を進めることができました。
Gitに慣れない段階でGitHubを使うと、その難しさが「チームで一緒に仕事をすること」に関係する難しさ（ルールが不十分）なのか、Gitの使い方的に慣れないことが原因で起こる「難しさ」なのかを見極めるのが非常に難しいです。まず、この原因の切り分けが非常に重要。
そもそもGitは「複数人でLinuxのソースコードを開発するために作られた」もの。元来の目的がチーム運営をスムーズにすることではありますが、だからといってGitの機能を全部知っていたら完璧な協同作業ができるというわけではありません。
複数のいろいろな考えを持った人間が情報を扱う限り、全員が「俺のやり方」を貫き通していたらどんなツールを使おうが協同作業は成り立ちません。
あくまでもシステムはシステムであり、それを使う人間同士が「うまく協調して行動する」必要があります。
自分たちの場合で言うと「協調する意思」はあったんだけど、協調して行動できるようにするシステムの整備が足りなかった、という印象です。
プログラミングでの協同作業には多くのお手本がありますが、本を書く場合での手本は非常に少ない。さらに自分たちの場合、一般的な著者と編集者という形式とも異なります。
そういう環境でいかにうまくやっていくか。見つけ出した協同作業ルールの中で、今後も続けたい重要なルールは以下の3つにまとめることができました。
全体責任者の明確化
ToDoリスト付きの目次ページ
コメント機能の活用
全体責任者の明確化
まずなによりも重要だったのは、夫婦という二人のチームでも「フラットな関係」ではなく責任者を決めること。その責任者が全体を統括して、パートナーに指示を出す、という形式にしたこと。
今回の本は「五藤晴菜」名義の本なので、責任者は五藤晴菜です。
主な役割として、ごりゅごは「原稿を投稿する」仕事に専念し、残りの必要な作業などはすべてが責任者が管理する。
ある意味で、書籍の執筆でよくある「著者と編集者」のポジションとほとんど同じ形式に落ち着きました。
受け取った原稿を確認、修正するのも晴菜さんの仕事で、原稿からepubを作ったり、KDPへの登録作業も晴菜さんの仕事。
また、こうした編集者的な役割の他に、晴菜さんは「表紙デザイナー」「イラストレーター」な役割も兼務しています。これらも「五藤晴菜」の管理です。
この「責任者」という役割は、GitHubの運用にも活用されています。具体的に言うと、原稿の最終版が扱われる「main」のブランチを編集していいのは責任者のみ。
原稿を投稿する役割のごりゅごは、別途ブランチを作って「プルリクエストを送る」というルールにしました。（基本的に、1日1回のペースで中途半端でもプルリクを送ることにした）
この「GitHubに毎日プルリクを送る」というやり方にしたのが今回一番の成功要因だったかもしれません。
ごりゅごとしては「できるだけ毎日手を付ける」ようになるし、晴菜側からも「毎日プルリクを受け入れる」ことを通じて進捗の管理が行いやすい。
自分の場合、GitHubのコミットはどうしても雑な記録になってしまいますが、毎日「プルリクを送る」というルールにしたことで「今日はここまでやった」ということをまとめる必要が出てきます。
きちんとプルリクを送るというのは面倒くさいのは事実ですが、1日1回くらいなら手数としては多くないし、長い目で見ると結局「毎日きちんと記録を残す」方が全体的な効率はアップしているように感じています。
要するにこの「プルリクを送る」という行為が一般的な業務での日報、日誌に相当するもの。これをきちんと「他人に向けて書く」ことの価値を改めて思い知り、日報の重要性をこれまでとは異なった視点で思い知ることができました。
ToDoリスト付きの目次ページ
責任者を作ると同時にもう一つ、次に何をするのか、という「やることリスト」を「必ず見る場所」に明文化すること。
やることリストを作ることが重要なのはわかっているし、それぞれ週1回の進捗会議において「次に何をするか」というのは決めていました。
ただ、ごりゅごの「タスクマネジメント能力」には致命的な欠陥が複数あり、まず、会議で決めた「やること」を自分が普段使うタスクリストに書き込むということができない。それができたとしても、悪気なく書いてあることを平気で次回の会議まで忘れる。
そこで対策として実行されたのが（ごりゅごが普段執筆するときに必ず見る）書籍の目次ページにやることリストを設定すること。そして、このやることリストは「進捗会議中」にその場で作って双方が確認するということ。
ごりゅごは、ここまでしてもまだ忘れる（無意識で書いてあることをスルーする）ような人間ですが、それでもかなり忘れる確率は減りました。
コメント機能の活用
そして最後に、もう一つの別の方向から予防線としての「やることリスト」も作成しています。
それは、原稿に「安全な形で」気になることを残しておく、という方法。その方法としてHTMLの「コメント機能」を使います。
各自絵文字でアイコンを決めて<!-- 🐷初代iPadの発売時期を確認する -->なんていう感じで原稿の中に直接コメントを書いていきます。
KDPの原稿はマークダウンファイルを使って、それをPandocでepubにするという方法を採用しているので、HTMLで使えるコメント機能が本の原稿でもそのままコメントとして機能するのです。
書いてる最中は見えるけど、パブリッシュをすると見えない。
もちろん、執筆が終わる段階ですべてきちんと確認して消すことが基本ルールなんですが、これまた「自分の文章の校正」にも致命的な欠陥を持つごりゅごがミスをしても「致命的なエラー」にならないようにするための予防線としても機能するのです。
このやり方は、文章校正の後半でも生きてきます。原稿全体から<!--を検索することで、原稿の中にある「確認事項」が一覧できるようになります。
わりとアナログな手法ですが、これは終盤ではかなり役に立ちました。
ライフハックと呼ばれるような小さなテクニックですが、執筆の過程では実はこれが一番重宝したテクニックかもしれません。
と、こんな手法を駆使して、以下の本を作りました。
どうぞよろしくお願いします。Kindle Unlimitedでも今すぐご覧いただくことが可能です！