本業のFDE（企業のAI導入支援）に加え、storeforge・aerial-earth-studio・afflow・民泊の複業4事業を並行運営していると、必ずぶつかる壁がある。「タスクがどこに何個あるか、自分でも把握しきれなくなる」問題だ。私はこれを、事業ごとにissue管理ツールを分けるのではなく、GitHub Projectsのボード1枚に全事業のタスクを一元化することで解決した。今回は、その具体的な仕組みと、実際に運用してみて分かった注意点を書く。
目次
なぜ事業ごとにツールを分けなかったか
複業を始めた当初、事業ごとに管理場所を分けることも検討した。storeforgeはスプレッドシート、aerial-earth-studioはNotion、afflowはTrello、というように。だが子育てのすきま時間で事業を切り替える運用（詳しくは前回記事の時間割を参照）をしていると、ツールを切り替えるコスト自体が無視できないことにすぐ気づいた。
10分の隙間時間で「今日は何をやるか」を確認するのに、複数のツールを開いて回るのは非効率すぎる。しかも各リポジトリのコードもGitHubで管理している以上、コードと紐づくタスクだけ別ツールに置くと、コードとタスクの結び付きがその都度切れる。そこで、コードもタスクも共通の基盤に乗せる方針に決め、タスク管理は「lifeリポジトリ」という個人管理用のリポジトリに一元化し、GitHub Projectsのボード1枚で全事業を横断的に見る構成にした。
実際の運用構造
具体的な構造は次のようになっている。
- issueの置き場所は必ずlifeリポジトリ: 事業ごとに専用リポジトリ（storeforge、aerial-earth-studio、afflowなど）はコードのために存在するが、issueはコードリポジトリに作らず、すべてlifeリポジトリに集約する。コードリポジトリにissueが散ると、確認する場所が事業の数だけ増えてしまうためだ
- ラベルで事業を色分け: 各issueに事業名のラベル（storeforge、aerial-earth-studio、afflow、minpaku、fdeなど）を付け、ボード上で一目で事業を判別できるようにしている。ラベルの色は事業ごとに固定し、視覚的な塊で認識できるようにした
- Projectsのビューを目的別に分ける: 「全事業横断のカンバン」に加えて、事業別にフィルタしたビューを作り、1つの事業に集中したいときはそのビューだけを見る。逆に週次の棚卸しでは横断ビューを使う、というように使い分けている
- Statusは実態に合わせてこまめに更新: Todo / In progress / Done程度のシンプルな区分だが、着手したらIn progressに動かすことを徹底している。ここが崩れると「ボードを見ても今何が動いているか分からない」状態になり、一元化した意味が薄れる
この構造にしてから、隙間時間に「今どの事業のどのタスクをやるべきか」をボード1枚で判断できるようになった。
一元化しても解決しない問題
正直に書くと、GitHub Projectsに一元化したからといって、タスクの総量が減るわけではない。むしろ全事業のタスクが1つのボードに並ぶことで、積み上がったタスクの多さを直視させられる場面も増えた。
また、ラベルとビューの整備はそれ自体が管理コストであり、放置するとラベルが実態とズレていく。例えば、事業の優先度が変わったのにラベルの色分けや並び順を更新し忘れて、しばらく古い分類のままボードを眺めていたことがあった。一元化の仕組みは「作って終わり」ではなく、事業の状況が変わるたびに軽くメンテナンスする前提で運用している。
もう1つ、GitHub Projectsは元々ソフトウェア開発のタスク管理を想定したツールなので、民泊の清掃スケジュールのような「開発タスクではないもの」を無理やりissue化すると、多少の違和感が出る場面もある。それでも、ツールを分けるコストの方が大きいと判断し、多少の違和感には目をつぶって全部issueに寄せている。
隙間時間で回すための最低限のルール
複数ツールを行き来しないという以外に、隙間時間での運用を成立させるために決めているルールが3つある。
- 1issueに複数事業のタスクを混ぜない: 後から検索・フィルタするときに事業単位で追えなくなるため、issueは必ず1事業1タスクの粒度にする
- タイトルだけ見て何をすべきか分かる粒度にする: 隙間時間ではissue本文をじっくり読む余裕がないことが多い。タイトルだけで着手判断ができる粒度に分解しておく
- 着手前に必ずStatusをIn progressに動かす: 「動かし忘れ」がボードの信頼性を最も損なう。着手のタイミングでの更新を、タスク自体の作業より先にやる
まとめ
- 事業ごとにツールを分けず、issueはlifeリポジトリに一元化し、GitHub Projectsのボード1枚で全事業を横断管理している
- ラベルで事業を色分けし、横断ビューと事業別ビューを目的に応じて使い分けている
- 一元化してもタスク量は減らず、ラベルやビューのメンテナンスという別の管理コストが発生する
- 隙間時間で機能させるには「1issue1タスク」「タイトルだけで着手判断できる粒度」「着手時のStatus更新の徹底」が最低条件
次回は、複数事業のタスクが並ぶボードの中で、実際にどう優先順位をつけて「今週どの事業に時間を割くか」を判断しているかを書く。
