メインコンテンツまでスキップ

Projects

link: https://docs.github.com/ja/issues/planning-and-tracking-with-projects/learning-about-projects/about-projects

Introduction​

GitHub における Projects は、リポジトリ内の作業やタスクの管理を支援するための機能です。通常、プロジェクトは、特定の機能、タスク、バグ修正、またはバージョンリリースに対応する複数の Issue や Pull Request をまとめて管理するために使用されます。

プロジェクトには、Kanban ボードのようなタスク管理システムが含まれており、作業フローを視覚的に表現できます。各カラムには、例えば「To do」「In progress」「Done」のようにラベルが付けられ、関連する Issue や Pull Request がそれぞれのステータスに移動することができます。

Projects 運用​

目的​

管理者
・ 期日を設定できることで、タスクごとの期日を記憶しておく必要がなくなる
・ 開発者と管理者だけが期日を知っているという状況がなくなり、案件全体で可視化できる
・ issue間の移動が楽
  -> 遷移が必要なく、編集も可能
・ 検索条件を複数保存
・ 確認したい内容に絞る表示ができる
・ 日毎の完了タスクを把握できる
  -> 1日の作業量を把握できることで、後スケジュールの見積もりがしやすくなる
開発者
・次のタスクの選択をしやすくする
  -> 案件でこの優先順位で進めてくださいといった共有があった場合に、種別でまとまるので選択がしやすい
・タスクの優先度をわかりやすくする
  -> 現在進行中のものよりも優先のものがある場合にキャッチアップがしやすい
・誰がどのタスクを担当しているかがわかる
  -> 優先度が高いものを複数持っている人がいる場合に引き継ぎなど開発者同士の協力がしやすい
・先取りで複雑なタスクを見つけやすい
  -> 複雑なタスクを先にやっておくことで、余裕をもったスケジュールとなり案件貢献ができる
  期日が迫った状態での複雑なタスクは、開発者側が十分な設計を行えなくなり品質が落ちることに繋がってしまう

全体機能​

① issue間の移動の際の遷移が必要なくなる
  -> 遷移が必要なく、モーダルのようなUI表示で編集もできる
② 検索条件を複数保存しておける
  -> ソート機能
③ 確認したい内容に応じて表示を切り替えられる
  -> タブ切り替え

実画面例
①の画面例
issue_open
②の画面例
sort
③の画面例
tab

観点別機能​

1. 期日
① 案件全体のタスクベースでのスケジュールが確認できる
② 開発者が期日が近いものを先にやることで、余裕をもったスケジュールとなり案件貢献ができる
③ 開発者が期日の意識をできることで責任感が生まれる
実画面例
deadline
2. 優先度
① タスク選択の際に悩む時間の短縮
  -> 管理者への確認などのやりとりが削減できる
② 同期日タスクに優先度を設けることで、タスクスケジュールの管理が容易になる
  -> 開発者側への優先度の共有が優先度ベースになるのでやりとりが不要にできる
実画面例
ラベル優先度の画面例
priority_label
タブ優先度の画面例
priority_tab
3. 紐付けPR
① issueに紐づけられたPRを探す手間を省く
  -> 直で遷移可能になるので、PRの確認がしやすくなる
② 該当タスクがPR作成まで至ったことが把握できる
実画面例
connect_pull_request
4. 作業量
① 日毎の完了タスクの量を把握できる
  -> 後のスケジュールの見積もりがしやすくなる
  -> 改善点の検討可能
② 開発者がどれぐらいタスクを完了したかを把握できる
  -> 滞っている作業がないかを把握
実画面例
daily_task_count

Workflow の活用​

① 自動化​

issue紐付け
・ workflow設定を編集することでissue起票時にprojectsに自動登録されるように設定が可能
  -> 手動での登録が不要になる
公式ドキュメント

link: https://docs.github.com/ja/issues/planning-and-tracking-with-projects/automating-your-project/adding-items-automatically

実画面例
workflow_auto_register
ステータス自動変更
・ issue起票時、PRマージ時、リクエストチェンジなどをトリガーとしてprojectsに表示されるステータスの自動変更設定が可能
  -> 手動でのステータス変更が不要になる
  -> タスクがどういった状況なのかを把握しやすくなる

  ステータス例: Todo(未着手), Progress(着手中), Done(完了)
公式ドキュメント

link: https://docs.github.com/ja/issues/planning-and-tracking-with-projects/automating-your-project/using-the-built-in-automations

実画面例
ステータス表示
status
ステータス自動変更設定
workflow_auto_status_change
アーカイブ
projectsに登録できるアイテム制限数
・1,200アイテム数制限
・アーカイブアイテムは10,000アイテム数制限

・特定のアーカイブ条件を指定しておくことでアイテム制限数の圧迫を防ぐ
※ アーカイブからの完全な削除は公式ドキュメント参照
公式ドキュメント

link: https://docs.github.com/ja/issues/planning-and-tracking-with-projects/automating-your-project/archiving-items-automatically

実画面例
workflow_auto_register

② 高度な処理​

GitHub Actionsによるカスタムカラム追加

ルートリポジトリに`.github/workflow`ディレクトリを作成し、`.github/workflow`配下にGitHub Actionsを記載した.ymlファイルを作成する

・ 案件独自カラムや日付などの追加をカスタマイズできる
  -> 管理において必要な項目など管理者の裁量で追加できる
公式ドキュメント

Workflow: https://docs.github.com/ja/actions/using-workflows/about-workflows

GitHub Actions: https://docs.github.com/ja/issues/planning-and-tracking-with-projects/automating-your-project/automating-projects-using-actions

実用例

※ .yml に project に追加する処理を記載している理由


-> github actions で issueやPR固有のid を取得するだけの処理がない。


projects に登録する(紐づける)処理を行うことで idを取得できるため使用している。



projectsに登録する処理は下記の処理になっている


  • 新規の場合は新しく作成された id を返す
  • 既に id が振られていたら、その id を返す

カヤック案件でのissueに関するyml



カヤック案件でのPRに関するyml