続・電子書籍の校閲編集作業にGitを利用してみる試み
前回：funny-creative.hatenablog.com
先日、「電子書籍の編集作業をgitでやってみよう」という思いつきの試みをぶちあげてみたところエンジニアサイドの方々から様々な反応を頂いてしまいました。
僕みたいな「htmlとcssは打てるけどjavaやphpはからっきし」な非エンジニアには恐れ多くて萎縮してしまいそうです（していない）
協力して頂ける方の募集を行ってみたところ、業務で分散管理のなんたるかを身につけておられるエンジニアの知り合いの方にコミットしていただくことができました。
おかげさまで、編集規約や作業手順、ブランチの運用など、大まかなシステムの枠組みはひとまず確定してきています。
ただ、文章を読んだり修正してくれる肝心の作業人員が確保できない、というよくある炎上パターンに突入しかかってます。
「下読みだけなら手伝えるけど、原稿に手を出すとか、使ったことないシステムに手を出すのはちょっと・・・」という障壁が、たぶん一番分厚い問題です。
- 「俺も手伝うから代わりに手伝ってほしい」という電子書籍界隈の方
- 「スペルミスや誤字脱字を見つけたくて仕方無い」という校閲マン
- 「本をいちはやく世に出すための手伝いがしたい」という有り難い読者の方
- etc
などなど、参加申し出ていただけたら嬉しいです。
クライアントの導入方法から使用方法まで、こちらでサポートさせていただくので、何の前知識も無くて大丈夫です。
（というか前知識がないと使えないシステムを作り上げてもしゃーないので）
とりあえず現状の作業の進め方について簡単にまとめてみます
現状のワークフロー
1. 作者が初稿テキストをアップロード。これを「v0.5」としてタグ付けを行う。
- 作者がα版として初稿を公開し、デモプレビュー用のEPUBを同時にダウンロードに置く。
- 編集チーム参加者は各々ダウンロードして下読みを行ってもらう。
2. 「感想」と「誤脱修正」として2種類の課題（issue）を発行する。
- 「感想」については課題に対して直接コメントを投稿していく。デバッグとレビューの要領。
- 「誤脱」については直接原稿に修正を行い、各人にコミットしてもらう。こちらはスペルミスの修正の要領。
3. 充分にレビューが集まったところで作者は「改稿ブランチ」を派生させ、レビュー反映した改稿を行いリリース可能な「v1.0」の状態を目指す。
- masterブランチには継続して「誤脱修正」を行ってもらい、改稿作業と校閲作業を並行作業化できる。
- この間にもスタイルcssの変更をして「体裁組み」作業などを並列して処理できる。
- 果たして「校閲済みmaster」と「作者改稿ブランチ」のマージが上手く行くか否か、やってみなければわからない。
現状の利点と欠点
利点
- 作者が校閲者が何度も読み返して行うべき「誤脱修正」作業を、複数人が一回ずつ行うだけで済むので、gitの利点である作業分散の恩恵を受けられる。
- 「感想」をissueとしてコメントでまとめることで、誰がいつどんな指摘をしたか履歴が残り、作者が反映を行いやすい。
- いつだれがどこを変更したかがログとして残り、作者もdiffを確認するだけで変更が見渡せるため無断改変のような問題に対するクリティカルな解決策になりうる。
- 必要な作業をissue化しておくことで、作者自身にとっても「あとリリースまで行うべき作業が何か」を明示化して潰すことができる。
- また課題がオープンになることで、編集側からアドバイスや解決策を提案してもらえるので、作業負担が軽くなる。
最後の点に関しては、お手伝いしてもらってるエンジニアさんから、適切な解決策を次々提案してもらえてるので、ほんと助けられています（小並感）
まとめ
とりあえず「10人ぐらいの編集作業にも耐えうる理想的な編集規約」の策定については、おおむね概計が見えてきたと思います。
一極集中していた編集作業のフローを分散管理の形式へいかに落とし込むか、という思考実験とその実施としてはかなり上手く行った感触があります。
ですが現状の問題は、やはり習得コストと人員の確保です。
こういった作業を業務レベルで行える人間をどうやって10人確保するんだよ、という（笑）
僕自身のマネージメントスキルの問題になってくるので、人を集めるのも編集作業のうちと考えれば良い経験です。
ただ作業行っていくうえで、「なぜ無断改変のような事態が編集過程において常態化してしまうのか」という問題について、自分なりに気づくところがありました。
この点については別途、記事としてまとめてみようと思っています。