16
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

Github ProjectsのRoadmapでタスク管理してる話

16
Last updated at Posted at 2025-12-03

この記事は ウェブクルー Advent Calendar 2025の4日目の記事です。
昨日は @wc_nakaniwa さんの「Reactで使っていた &&|| の条件付きレンダリングの仕組みをちゃんと理解する」でした!
4日目は @wchikarusato が担当いたします。よろしくお願いします。


はじめに

ここ1年ほど、Github Projectsの Roadmapを使用して個人のタスク管理をしています。
Githubのアカウントを持ってる人なら誰でも使えます。
なかなか使い勝手が良かったため、以下に今の使い方を紹介します。
五月雨でやることが飛んでくる、やろうと思っていたことをすぐ忘れる、締切忘れてないか不安、といった問題の解決に役立てば幸いです。

具体例

イメージしやすいよう、Projects を新規作成し、いくつかタスクを追加しました。
画像における紫色でチェックマークが入っているものが完了タスクになります。
列挙してるタスクの実態は早い話が Githubの Issue で、この Issue を管理、追跡しやすくしてるのが Github Projectsのようなイメージです。
割愛しますので、詳細が気になる場合は公式を参照ください
https://docs.github.com/ja/issues/planning-and-tracking-with-projects/learning-about-projects/about-projects

Issueを close すると自動で Projectsに Done ステータスが入るので、それをフィルターにかけて完了/未対応を一望できるといった使い方ができます(やり方は後述)

画像. Roadmapサンプル
Pasted image 20251126165110.png

初期設定

Githubにログインすると、まず OverviewRepositories のタブが目に入ると思います。
その中に Projects という項目があるので、そこから新しい Projects を作成します。
テンプレートは迷ったら、とりあえず Roadmap で問題ないと思います。
いきなりPublicにする人はいないと思いますが、一応やろうと思えばできるようなので鍵マークがついてるか作成後に確認してください。

カスタムフィールドの追加

Roadmapでフィルターをかける際に Start DateTarget Date があると便利です。
Projects の Settings から追加できます。手順は簡単で、カスタムフィールド横の+を押し、Field name を入力、Field type で Date を選ぶだけです。

画像. カスタムフィールドサンプル
Pasted image 20251126152508.png

Roadmapの設定

まず、自動的に作られる「View1」の横の▼を押してRoadmapの表示設定を行います。
現在、私は Group By を Milestone、Sort by を 1.Status、次に 2.Target Date の順にしています。
最後に Save ボタンを押すことで、ビューがこの状態で常に表示されるようになります。
作成した Roadmapの urlをブクマに登録しておくと便利です。

画像. Roadmapの設定1
Pasted image 20251126153145.png

次にページ右側の Date Fields で、作成した Start date と Target date を選び、Save を押します。
これで、issue に設定した開始日と終了日がRoadmap上で棒状に表示されます。

画像. Roadmapの設定2
Pasted image 20251126160313.png

試しにタスクを追加してみる

「+ Add item」➔「Create new issue」を押すと issue 作成画面に移ります。
タイトルに test、Description に test を入力します。
見やすくするため、私は最初のタスクや親issueには必ず Label で Backlog を選択しています。
それ以外のものは Labelなしの割り切りです。

画像. タスク追加テスト
Pasted image 20251126154822.png

意味合い的には Backlog より issue tracker の方が正しいと思います が、こだわりだしたらきりがない もちろんLabelの編集もできるので凝り性の人は公式ドキュメントを参照ください。
https://docs.github.com/ja/issues/planning-and-tracking-with-projects

問題なければ、下記画像のように No Milestone のグループ内に test issue が追加されます。
この時点でRoadmapに棒が出てないのは気にしないでください(Issueの日にち設定をまだ何もしてないので)

画像. Roadmap(初期)
Pasted image 20251126155259.png

これで一先ず初期設定は完了です。
あとは同じ手順で気になったこと、やることを issue化して No Milestone に積み上げていきます。
やる・やらないは度外視して、思いついたことをとにかく放り込むのがポイントです。
忘れていたタスクも、このRoadmapを開けば一目瞭然なので、かなり気が楽になります。

具体例

ここからは、実際の私の運用の流れを具体例で説明します。
「タスクの作り方 → スケジュール設定 → Roadmapへの反映」まで一通り追えるようになります。

新しくタスクを追加する場合も、同じ手順で issue を作成し、Label に Backlog を選び、Write にメモや細かなやることリストを列挙します。
あとで修正もできるので、とりあえずこの段階では枠を抑えるくらいのつもりで良いと思います。
既に作った Issueを詰めてく場合はEditで編集に飛びます。

画像. 実際のIssueサンプル
Pasted image 20251126165201.png


💡 余談1:Obsidianを併用する理由
最初はIssueに作業履歴でやったことも全部残していたのですが、結局Obsidianと併用する形で落ち着きました。理由としては、

  • issueコメントに作業ログを溜めると検索時の邪魔になる
  • 今のところ個人でしか使用していないので、メモ・SQL・ログはすべてObsidianに集約した方が便利
  • GitHub上ではObsidianリンクが動かないため、コードフェンスで貼って対応

さて、issueを追加した後、Roadmapで issue を開くと GitHub の issue 画面に移動します。
私がここで主に編集するのは右側の Start date と Target date、Milestone になります。
着手前に必ずここを埋めます。
開始と終了の日にちは埋めやすいと思いますが、Milestoneはなかなかに迷います。
私はMilestonでグルーピングしているので、迷ったらとりあえずその週中にやることでまとめるようにしています。

画像. 開始日、終了予定日、マイルストーンのサンプル
Pasted image 20251126165406.png

Roadmapに戻ると、作成した issue が反映されます。
フィルターに -status:Done を入れると、未実施のものだけを表示できます。
なので、issue を close すると自動で Done が付くため、これでやった/やってないが自動的に判別できるようになります。
あとはやること/課題内容/依頼内容を書き出しては issueを消化していく作業になります。
細かなタスクはここまで作成した親issueから Sub issueをぶら下げる形で作っています。
というかここまでタスクと書いてるものは全部 Sub issueです。
Githubでは Sub issueに Sub issueをぶら下げることも出来るので、最初はものすごく細かいレベルにまでタスクを落とし込んで使ってました。
Githubで検索をかければ issueがヒットするので、忘れそうなことや後々検索かけそうなキーワードを埋め込んでおくと便利です。
ただし、過剰にやりすぎると検索のノイズになるので、色々試してどこまで書くのかバランスを見極める必要があります。
もちろん Githubなので PRと連動させれることもできます。
「この対応で何した」が一目瞭然で簡単に追えます。これもかなり重宝しています。

画像. Roadmapサンプル(未対応のIssue一覧)
Pasted image 20251126163845.png

そしてlabel:Backlog をフィルターに入れると、Backlogをラベルに設定した issue、つまりこの運用では 親issue のみ一覧表示になります。
両方組み合わせた label:Backlog -status:Done で未完了の親 issue のみを表示、という使い方も可能です。
このおかげで、細かいタスクを列挙してもRoadmapはスッキリ見渡せます。
週の振り返りや週報作成にもなかなかに便利です。

画像. Roadmapサンプル(未対応の親Issue一覧)
Pasted image 20251126164012.png

翌週にやること

以上の通り、私の使い方は基本的にその週でやることをマイルストーンとしてまとめた形になっています。
なので、翌週でまずやることは未実施の issue を開き、マイルストーンを翌週分に移すことから始まります。
マイルストーンが未作成の場合はこのタイミングで金曜日の日付を探して作ります。

尚、ずっと翌週分に毎回残るようなタスク場合は、スケジュール調整の合図です。場合によっては「No Milestone」に戻して、ペンディングにすることもあります。
あるいは、大掛かり過ぎて手を付けるのが億劫になっている可能性もあります。この場合は小分けにわけることで、意外と進んだりします。
最後に、前週分のマイルストーンの三点を押して「Archive all」を選択します。
こうすることで、かなりスッキリとした見た目になります。
あとは日々これらの繰り返しになります。

画像. マイルストーンのアーカイブ化サンプル
Pasted image 20251126170137.png


💡 余談2:グルーピングについて
この記事ではマイルストーンでグルーピングという使い方をしていますが、タスク管理する上で一覧表示で一番見やすいのは「なに待ち」ごとにまとめることなのではないかと個人的には思っていたりします。
例えば、明日中にやらないといけないなら「[明日の日付]待ち」、誰かの返事待ちなら「[その人の名前]返事待ち」など。
途中で違うタスク挟んでからいざ再開する時にこのタスクどこまでやったっけ?がこれなら改善できるかもです。


Roadmapに反映してからやること(要点まとめ)

  • Issue開くまたは作成
  • 編集画面で Start dateTarget date を設定する
  • Milestoneに週次タスクをまとめる
  • -status:Done で未実施タスクを可視化
  • Backlogラベルで親Issueだけ抽出
  • Sub issueで粒度を調整

まとめ

ひとまずの流れとしては以上になります。
月曜の朝30分にこれをやるだけでも1週間全体の見通しがかなりスッキリするのでオススメです。

実際の仕事では、issue 作成時に task 列挙したものをすべて sub issue 化し、専用のマイルストーンでまとめています。
Backlogラベル にしている Issue のみ、その週のマイルストーンに放り込むという運用です。
こうすることで、その週に何をやったか、何をやらなければならないかが一目瞭然になります。
また、終わりが見えない長いプロジェクトを進めている場合も、上記運用をすることで何かしらのタスクは必ずその日に消しているので確実に進んでる感じが気持ちします。
逆に何もその日消せなかった場合はIssueの粒度が相当荒いというサインなので、その場合はタスクを更に細分化して Sub Issueや別Issue化をすると良いかもしれません。
私は最大で Sub Issueの Sub Issueの Sub Issueな4段構成までやりました。
この記事が何かの参考になれれば幸いです!


明日は、 @shoshi-maruyama さんです。よろしくお願いします。

ウェブクルーでは一緒に働いていただける方を随時募集しております。
お気軽にエントリーくださいませ。
https://www.webcrew.co.jp/recruit/

16
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
16
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?