小説をタスク管理するときのイシューのラベルどうする問題

以前ちらっと書いたように、一気に書く時をのぞいて極力GitHubで小説データを管理しています。いまはプライベートリポジトリ（データが非公開）も無料アカウントでイケるのでお財布にも優しいGitHub。

過去何作かはデータがすべてGitHubに保存されている状態になりました。

編集者とはPDFの赤入れでやりとりしているのですが、その指摘をイシューとして登録し、自分が赤入れした部分はテキストファイルに書き写してコミットしています。ここめんどくさいのですが、出版社の編集者に「GitHubとはGitをベースにしたSNSのようなものであって〜」とか説明するのもめんどくさいので自分の将来のためと思ってやっています。この「完成稿がテキストデータで作家の手元に残らない問題」については円城塔さんがtwitterでよくボヤいてますよね。

で、本題です。

イシューとは？

GitHub（というか、普通のプロジェクト管理ツール）には「タスク」「イシュー」といった、細かい課題の単位が存在します。「静かすぎて〜」の例で言うと、こういう感じですね。

これらの課題を「イシュー」として登録していき、一つ一つ片付けていきます。終わったやつは「クローズ」してしまい、いま目の前に残っている課題にだけ集中していくプラグマティックなスタイルですね。

「マイルストーン」という機能を使うと、そのマイルストーンに関連する課題をまとめることができ、ちょっとしたスケジュール管理のようなことができます。GitHubはタイムリミットをあまり意識しないプロジェクト管理機能になっていますが、他のサービス（trelloとかBacklog）だとガントチャートとかありますね。

プログラムの仕事ではこうしたタスクベースの管理が当たり前になっているので、小説でもそうしている次第なのですが、この「イシュー」にはラベルをつけることができます。GitHubのデフォルトのラベルはこんな感じ。

たとえば “Bug” というのはプログラムだと「あ、これはバグに関する課題なのだな」とかわかりやすいのですが、小説だとバグはないですよね。自然言語はバグらないので。そうなると、たとえば「校正」とか「直し」とかそういうラベルの方がふさわしいよな、とかそういうことを考えるようになります。

小説用のGitHubラベル

で、いったん考えてみました。それがこちらです。

いちおうテキストに起こしてみると、こんな感じです。

Difficult

難しいよー困ったよー、という時につけるラベルです。このラベルがついたイシューがたくさんある状況はヤバイ状況です。

Question

疑問に思ったことにつけるラベルです。プログラムだと「バグ」に当たりますが、もしこのリポジトリを誰かと共有した時に「バグ」とかラベル付されたら殴ってしまうかもしれないので穏当な表現にしてあります。

Reserch

調査が必要な項目です。いま準備中の長編で言うと、「細菌の遺伝子変異の原理を調べる」とかですね。

Reusable

他のところでも使えそうな課題です。小説を書いているとよくあるのですが、結局本編では使わなかったけれども他でも使えそうだなネタというのがあります。そういう場合につけておいて、後から調べたりする用途です。

Revision

直しです。校正（誤字脱字）と推敲（内容および表現の変更を伴う）の違いはありますが、とりあえず「直し」という点で共通化させてあります。

Wontfix

これはGitHubのデフォルトと共通で、「直さない」という判断を下した課題です。たとえば編集者から「ここは差別的なので〇〇という表現に直しては」みたいな注文があったときに、それに対して「いや、この時代ではそのような差別的な表現こそが普通だったし〇〇と言う言葉はその時代にありませんでした」みたいなケースに使います。

Writing

とりあえず書くときの課題です。「1章まで書く」みたいなやつ。この課題が多い状態は完成度が低いと判断できます。

で、とりあえずこれらのラベルを毎回設定するのはめんどくさいので、コマンド一発で登録できるようにしておきました。

fumikito/labels-for-writing

使い方はリンク先をご覧ください。修正案なども受け付けているので、プルリクを送るか、技術的なことがよくわからない方はこの記事の下のコメント欄をご利用ください。

このラベルはあっているのか？

GitHubのイシューラベル、僕ははじめてみた時「へー、よく考えられてるじゃん」と思ったのですが、大規模なプロジェクトや歴戦の凄腕プログラマーからはそうは見えないようで、「クソでは？　もっとイケてるラベルがあるでしょ」という意見があります。

TLDR; the default GitHub labels kinda suck; use a sane labelling scheme instead; and use git-labelmaker to simplify GitHub label editing.

Sane GitHub Labels

上の記事では単純にラベル付けするのではなく、 カテゴリー：内容 みたいな感じでもう少し詳細度を上げていますね。Priority: Criticalみたいな。僕も最初 Urgent＝緊急みたいなラベルを考えたのですが、人によってはすべてに「優先度高！」みたいなラベル付けをする人（＝会議で声が大きい人、メールをとりあえずCCに入れてくる人）がいるので、意味ないかなと思ってやってません。

なんにせよ、まだ運用を開始したばかりなので、このラベル付けで完成だとは思っていません。ぜひ皆さんのフィードバックを得たいところです。そもそも地球上にGitHubで小説を管理している人間がそんなにたくさんいるとは思えないのですが、もしかしたら代案得られるかもしれないので期待は捨てずにいます。

というわけで、今回は単なる報告でした。ちなみに、GitHubドリブンで書かれた小説として商業原稿になっているのは「pとqには気をつけて」と「静かすぎて聞こえない」です。