いものやま。

雑多な知識の寄せ集め

Githubプロジェクトボードで同人誌制作のタスク管理をやってみた。

同人誌制作 マネジメント 技術

f:id:yamaimo0625:20190125223301j:plain

今日も技術書典7で頒布する『Math Poker Girl』の作成に関する振り返り。

今日はタスク管理をGithubプロジェクトボードでやってみたという話。

Githubプロジェクトボードとは

GithubプロジェクトボードはGithubが提供するタスクボード。
タスクボードアプリとしてはTrelloやMicrosoft Planner（Teamsで使える）、あるいはKanbanFlowなどがあるけど、Githubが提供しているタスクボードなので特に設定することなくリポジトリと連携できるのがいい。

タスクボードとは

タスクボードでは作業をタスクとしてボードに貼り付けて、例えば「計画済み」→「実施中」→「完了」みたいにタスクの位置を移動していくことでタスクの状態を把握する。

f:id:yamaimo0625:20190917105311p:plain

Githubプロジェクトボードでは、各リポジトリのissueやプルリクエストをカードとして貼り付けられる他、ノートという形でメモを貼り付けたり出来るようになっている。
また、ノートをissueに変換したり、issueの状態変化に合わせてカードを移動したり出来る。

これにより、以下のようなワークフローでタスクを進められる：

  1. やるべきことをリポジトリのissueに登録
  2. プロジェクトボードを用意
  3. issueをカードとしてプロジェクトボードに追加
  4. カードでタスクの状態を管理（計画済みか、進行中か、終わったのか）
  5. 雑多なタスクはノートで追加（必要ならissueに変換する）
  6. タスクを実施
  7. タスクがコミットで終了するならclose #<issue番号>としてコミット（これでissueがcloseされる）
  8. issueがcloseされるとカードも完了の場所に移動。

やる必要のあるタスクが脳内からボードに移動して見える化されるので、タスクのやり忘れを防げるし、その期間でのタスクの進捗具合も見れる。
自分は個人で利用してたけど、チームなら各個人のタスクの進捗具合も見えるようになるのでサポートしたりも可能になると思う。

Githubプロジェクトボードの種類

Githubプロジェクトボードには実は3種類ある：

  1. リポジトリ所有のプロジェクトボード
  2. 個人所有のプロジェクトボード
  3. 組織（Organization）所有のプロジェクトボード

1.は各リポジトリで利用できるプロジェクトボード。
リポジトリの"Projects"タブをクリックすると利用できる。
「1リポジトリ-多ユーザ」の場合はこのプロジェクトボードを利用するといいと思う。

2.と3.は複数リポジトリに渡って計画をできるプロジェクトボードになっていて、2.は個人で使えるプロジェクトボード、3.は組織（Organization）で使えるプロジェクトボードになっている。
「多リポジトリ-1ユーザ」なら2.を使えばいいし、「多リポジトリ-多ユーザ」なら3.を使う感じになる。

自分は複数のリポジトリを使いたくて1人での利用だったので個人所有のプロジェクトボードを利用した。
個人所有のプロジェクトボードはプロフィールページを開いて"Projects"タブをクリックするか、右上のドロップメニューから"Your projects"を選択すれば利用できる。

どう運用したか

リポジトリの準備

まずリポジトリ（全部private）は複数用意していた：

そして、それぞれのリポジトリにタスクをissueで追加。

ちなみに、BlogリポジトリやStudyリポジトリは『Math Poker Girl』とは関係ないけど、同じ期間に並行して実施しているので同じプロジェクトボードから参照できるようにしている。

1スプリント1プロジェクトボード

1つのプロジェクトボードをずっと使い続けてもよかったんだけど、細く区切って使った方がカードの数も抑えられていいかなと思ったので、1スプリントごとにプロジェクトボードを用意して使うことにした。
ちなみに1スプリントは一週間にしていた。
いや、一週間ごとにリリースとかいうわけではないんだけど、固定長のタイムボックスがあった方がメリハリがあっていいと思うので。

そんな感じで1週間ごとに1つのプロジェクトボードを使っていたので、プロジェクトボードの名前は「yyyy-mm-wN」（例えば2019年の9月第3週なら2019-09-w3）としていた。

おそらくだけど、プロジェクトボードは期間の長さを固定にして、期間の長さが可変な締め切りはマイルストーン機能を使って管理するのがいいと思う。
（タスクの進捗テンポを守るためのプロジェクトボードと、プロダクトの期待を守るためのマイルストーンという使い分け）

4つの列

一番シンプルなタスクボードは「To do」「In progress」「Done」という3列を用意するけど、自分は「To do」を2つに分けて次の4列を用意して使っていた：

  1. Plan（今週やる作業）
  2. Today（今日やる作業）
  3. Working（作業中）
  4. Done（完了）

これは毎朝その日の計画を行いたかったから。

運用の流れ

そして、以下のような流れで運用していた：

  1. 週初め
    1. 新しいプロジェクトボードを作成
    2. 作業に関連するリポジトリをプロジェクトボードに連携
    3. 各日付の日付ノート（後述）をPlan列に追加
    4. 予定のノートをPlan列に追加
    5. その週に行うissueをタスクとしてPlan列に追加
  2. 毎朝
    1. その日の日付ノートをToday列に移動
    2. その日の予定のノートをToday列に移動
    3. その日行うタスクをToday列に移動
    4. 日付ノートをWorking列に移動し、各タスクの見積もり時間を記入
  3. 作業開始
    1. タスクをWorking列に移動
  4. 作業完了
    1. タスクをDone列に移動（issueならcloseすれば勝手に移動する）
    2. タスクの実績時間を日付ノートに記入
  5. 毎晩
    1. その日の振り返りを日付ノートに記入
    2. 日付ノートをDone列に移動
  6. 週終わり
    1. Done列を見返してその週の振り返り
    2. 来週以降のアクションや目標、予定を検討
    3. プロジェクトボードをclose

つまり「週初めに計画→週終わりに振り返り」という大きな枠があって、その中で毎日「朝に計画→夜に振り返り」を繰り返すようにして、その中でタスクをTodayからWorkingさらにはDoneへと進めていく感じにしていた。

実際のプロジェクトボードの様子はこんな感じ：

f:id:yamaimo0625:20190917121932p:plain

ちなみに、同人誌制作に限らずに一般のタスク管理に使えると思う。
それこそ普通の開発にも。
（その場合、リポジトリ所有のプロジェクトボードか組織所有のプロジェクトボードをチームで使い、加えて個人の雑多なタスクを個人所有のプロジェクトボードで管理する感じになるはず）

工夫したこと

実際に運用する中で、振り返りで気づいたことなどから以下のような工夫を行なってみた。

予定をノートで入れた

予定はカレンダーアプリで管理してるけど、プロジェクトボードにも追加するようにした。
これにより、

  • 週初めに今週の予定を確認する習慣がつく
  • 予定を考慮した計画を立てられる
  • いちいちカレンダーアプリを開かなくても今日の予定が分かる

というメリットが。

ノートにはURLなどもメモっておけるので、勉強会の場合はURLを貼っておけばプロジェクトボードから直接勉強会の詳細を確認しに行けて便利。

あと、途中からプールに泳ぎに行く予定もノートで追加しておくようにした。
するとToday列を見て「プール」とあるので「泳ぎに行かなきゃ」となるし、終わってDone列に移動すると一仕事終えた気分になるのでとてもいい。
ジムに行くとかそういう「やらなきゃいけないけどやらなくてもいい」系のものは、明示的なタスクにしてしまった方が続けられると思う。

週終わりの振り返り開始時間を書いた

週終わりの振り返りはノートにして計画していたのだけど、最初は「週終わり作業」とだけしていたので、ついつい気づいたら寝る時間になってて振り返りが出来ず、週の初めに起きてからやることが多かった。
そこで、「週終わり作業 21:00〜」と明示的にやる時間を決めて書いておくようにした。

これで21:00になったら「振り返りやらなきゃ」となって振り返りし忘れることがなくなった。

ノートにしたけどやり忘れるということが多い場合、この開始時間を決めて書いておくというのはいいと思った。

休息日を用意した

時間を好きに使えるので、ついつい頑張りすぎることが多かった。
療養中なので、体調の管理がけっこう重要なのに・・・
そこで意図的に休むように休息日を用意するようにした。

フリーランスとかだとこういった休みの管理も重要っぽい。
働きづくめでもパフォーマンス落ちるからね・・・
（とはいえ焦るんだよなぁ・・・）

以前、このブログでも紹介したHaLakeさんで作業を行なっていたのだけど、HaLakeさんは水曜日が定休日なので水曜日と日曜日は休息日として休むようにした。

とはいえやはり焦るので、水曜日は完全な休みではなく部屋の片付けをしたり本を読んで勉強したりするインプット日という扱いにしてみた。

まぁ、入稿直前は結局あまり休めなかったけど・・・

日付ノートを用意した

上記と関連して、日付を書いたノートを用意するようにした。
例えば「9/9 作業」とか「9/11 インプット」とか「9/15 休息」とか。

このノートの役割は3つ：

  1. その日が作業日なのかインプット日なのか休息日なのかを明示する
  2. 各タスクの見積もり時間と実績時間を記録する
  3. その日の振り返りを記録する

1.については前述した通り。

2.については、振り返りをするときにタスクを実施するのにどれくらい時間かかったのが分かった方がいいと思ったので途中から行うようにした。
昨日の記事の実績時間はこの記録がベースになっている。

プロジェクトボードの嬉しいことで、列を移動したりした時間はプロジェクトボードの"Menu"から"Activity"で確認できる。
なので、作業開始時にWorking列に移動しておけば、何時から始めたのかが分かるので記録は比較的簡単に出来る。
（あとで一気にやろうとすると大変なので、記録自体はその都度やっておいた方がいい）

3.については週終わりの振り返りをやろうとしたときにけっこう忘れてることが多かったので、その日のうちに軽く振り返りをしておいた方がいいと思って始めた。
週終わりの振り返りで日付ノートを見返すと「あーそういえば」となってよかった。

あと、副次的な効果で、日付ノートをDone列に移すことで「今日はこれでおしまい！」と区切りをつけれるようになったのがよかった。
それがないとダラダラと作業が続いてしまう感じがあったので。
それと、日付ノートの間に挟まったcloseになったタスクを見ることで、その日に終わらせたタスクの量が感覚的に分かるのもいい感じ。

これも出来たかも

他に、これも出来たかもという点に関して。

マイルストーンの活用

昨日も少し書いたけど、マイルストーンをもう少し使えればよかったかも。
初めてだったので締め切りがいつ頃だといいのか分からず、ちょっと使えなかった。

ラベルの活用

issueにはラベルをつけることが出来るのだけど、今回はちょっと使えなかった。

考えたいのが、大きすぎるタスクをどうするか。
issueに親子関係をつけたり出来れば分解したタスクを子タスクにすればいいんだけど、そういうことは出来ないはず・・・

今回は「タスク分解する」みたいなタスクを追加しておいて、分解した各issueを追加したらそのタスクはcloseするとしてたけど、ちょっと微妙な感じ。

Issueと一口に言っても実際にはいろんなレベルに分かれるので、ラベルを使うことでそういったレベルを分けられればよかったかなと思う。
まだうまくまとまってないし試せてもいないけど。

おそらく、ユーザ目線での価値単位であるFeatureやBugfixと開発者の作業単位であるTaskにラベルを使って分けて、前者はリリースと結びついたマイルストーンで管理し、後者はスプリントと結びついたプロジェクトボードで管理。
そして、それらの結びつけは一方のissueから他方のissueに言及しておこなう感じなのかな。
その作業コストがどんなもんかを確認してみないとだけど。

宣伝です。
気になった人はチェックをお願いします！

今日はここまで！