最近、ちょっと思ってたんだけど。ツールって、多すぎない？
Jira、Trello、Notion、Backlog… 気づいたらブラウザのタブがすごいことになってて。どれが最新の情報だっけ、みたいな。正直、仕事してる時間より、ツール間を移動してる時間の方が長いんじゃないかって思う時がある。マジで疲れる。
で、ある日、ほんと偶然。GitHub のリポジトリにある「Projects」っていうタブを、なんの気なしにクリックしてみたんだよね。今までずっと無視してたのに。
…それが、全部の始まりだった。もう、あのカオスな日々には戻れない。
もしチーム全員がすでにGitHubを使ってるなら、たぶん、他の高いツールはもう要らないかもしれない。シンプルで、見た目も分かりやすくて、驚くほどパワフル。今日はその話をちょっとしてみようかなって。
まずは「場」を作る感じ
いきなりだけど、セットアップは驚くほど簡単。大げさな準備はいらない。チームで使ってるメインのリポジトリを開くだけ。
そこの上の方に「Issues」とか「Pull requests」と並んで、「Projects」ってのがあるはず。大体の人はこれ、見て見ぬふりしてる。僕もそうだった。でも、ここをクリックするのが第一歩。
「New Project」ってボタンを押すと、いくつか選択肢が出てくる。「Table」とか「Roadmap」とか。個人的には、最初は「Kanban」がおすすめかな。ドラッグ＆ドロップで直感的だし、一番「プロジェクト進んでる感」が分かりやすい。
名前はなんでもいい。「チームのタスク」とか「スプリントボード」とか。僕はよく「作業場」みたいな名前にしてる。で、「Create」を押す。はい、これでもうあなたのチーム専用の掲示板ができた。
最初は「Todo」「In Progress」「Done」みたいな列（カラム）があるけど、これは絶対に変えた方がいい。チームの言葉に合わせるのが大事だから。僕らのチームだと、こんな感じ。
- 未着手 (Backlog)
- 作業中 (In Progress)
- レビュー待ち (In Review)
- 完了 (Done)
カラム名をクリックすればすぐ編集できる。この辺のシンプルさが、まず良い。
ここからが本番。ただのリストを「使えるタスク」に変える
さて、ボードができただけだと、ただのメモ帳だよね。ここからがGitHub Projectsの面白いところ。
各カラムの下にある「Add item」で、まずはタスクのタイトルを入力する。例えば「スマホ表示のナビゲーション崩れを修正」みたいに。Enterキーを押せば、カードが作られる。
でも、この時点ではまだただの「カード」。これを本物の「タスク」に進化させる必要がある。作ったカードの「…」をクリックして、「Convert to issue」を選ぶ。これ、すごく大事。
「Convert to issue」をすると、このカードがリポジトリの正式な「Issue（課題）」になるんだ。つまり、コードの変更と直接結びつけられるようになる。Jiraとかだと、この連携を自分で設定しなきゃいけなかったりするけど、GitHubなら最初から繋がってる。これが本当に楽。
Issueに変換されたカードをクリックすると、右側に詳細パネルが開く。ここで一気にタスクが具体的になる。
- Assignees: 誰が担当するのか。
- Labels:
bugとかfeatureとか、緊急みたいなラベルを貼る。 - Start date / Finish date: いつ始めて、いつまでに終わらせるかの目安。
- Custom fields: これが地味にすごい。僕らのチームでは「優先度（高・中・低）」とか「作業規模（S, M, L）」みたいなのを自分で作ってる。これで、何から手をつけるべきか一目瞭然になる。
このカスタムフィールドのおかげで、わざわざ別のツールでやってた見積もりとか優先度付けが、全部ここで完結するようになった。知ってる？GitHubの公式レポート「State of Octoverse」見ても、開発者が一番時間を使ってるのはエディタとGitHubだって言うし。だったらもう、タスク管理もそこでいいじゃんって話。
なんで僕がJiraやTrelloじゃなくて、これに落ち着いたか
Jiraの方が機能が多いのは知ってる。Trelloはもっと自由度が高いかもしれない。でもね、僕にとってはGitHub Projectsが「ちょうどいい」。
特に、日本の開発現場でよく使われるBacklogとかRedmineと比べても、メリットはあると思う。あっちも素晴らしいツールだけど、コードから少し距離がある。GitHub Projectsは、コードのすぐ隣にタスクがある感じ。この「距離感」が、エンジニアにとってはすごく大事なんだよね。
結局、ツールを選ぶ基準って、機能の多さじゃなくて「チームのリズムに合うかどうか」じゃないかな。僕なりに、どういう時にどれを選べばいいか、まとめてみた。
| こんなチームなら… | GitHub Projects がいいかも | Jira / Backlog など専門ツールの方がいいかも |
|---|---|---|
| チームの構成 | エンジニア中心で、全員がGitHubを使ってる。 | 企画、マーケ、営業とか、非エンジニアのメンバーが多い。 |
| プロジェクトの規模 | 中小規模。一つのリポジトリで完結するようなプロジェクト。 | 複数の部署やチームが絡む、超大規模なプロジェクト。 |
| 求めること | とにかくシンプルに。コードとタスクを近くに置きたい。ツールを増やしたくない。 | 細かい工数管理、ガントチャート、外部ツールとの高度な連携が必須。 |
| コスト感覚 | 追加コストはかけたくない。無料の範囲でやりくりしたい。 | 生産性向上のためなら、ツールのライセンス費用は惜しまない。 |
| 個人的な感想 | 「これで十分じゃん」って思える。むしろ、機能が少ない方が集中できる。 | 「あれもこれも管理したい」ってなると、やっぱり物足りなく感じるかも。 |
正直、GitHub Projectsが向いてないケースもある
もちろん、いいことばかりじゃない。完璧なツールなんてないし。GitHub Projectsも、正直言って向いてない場面はある。
一番大きいのは、さっきの表でも書いたけど、非エンジニアのメンバーが多いチームかな。デザイナーさんや企画担当の人に「GitHubにログインしてタスク確認してください」って言うのは、ちょっとハードルが高いかもしれない。そういう人が多いなら、やっぱり見た目がもっと親しみやすいTrelloとか、日本の会社ならBacklogの方がスムーズに進むと思う。
あと、超厳密な進捗管理とか、レポート作成機能が欲しい場合。例えば、経営層に提出するための綺麗なガントチャートとか、メンバーごとの作業時間レポートとか。そういうのを求められると、GitHub Projects単体ではちょっと厳しい。その場合は、やっぱりJiraみたいな「全部入り」のツールじゃないと対応できないかな。
要するに、自分たちのチームが何を一番大事にしてるか、だよね。僕のチームは「エンジニアが開発に集中できること」が最優先だったから、GitHubに全部まとめるのが正解だった。ただ、それだけ。
だから、もし今、たくさんのツールを行ったり来たりするのに疲れてて、チームのメインの活動場所がGitHubなら、一度試してみる価値は絶対あると思う。
完璧じゃないけど、タブを3つ閉じて、コードのすぐ横で仕事が進んでいく感覚は、思った以上に気持ちいいものだよ。
あなたのチームでは、タスク管理、どうしてる？もしGitHub Projectsを使ってる人がいたら、どんなカスタムフィールド作ってるか、逆にコメントで教えてくれると嬉しいな。
