はじめに

筆者は、ピクセルグリッドでディレクターとして動いており、社内プロジェクトや受託案件のアサインや進捗の管理などを行っています。そのため、なんらかのツールを用いて管理することになりますが、最近はGitHub Projectsを使っています。

これまでメインに使っていたツールはZenHubでした。その他、TrelloやBacklog、JIRA Software、monday.comなども使ったことがあります。その上で、最近はGitHub Projectsをメインで使用しています。

GitHubでは、以前から同名の管理ツールが存在しましたが、少し前に従来のものを「Projects (classic)」とし、それとは別に新しいGitHub Projectsとしてリリースしました。以前のものを試したときは、あまり筆者の用途には合わず使っていませんでした。しかし、新しいものになって良さそうに感じましたので、実際に業務に導入してみたところ、とても使いやすく感じています。

本シリーズでは、この新しいGitHub Projectsについて、良い点や使い方の一例などを交え、筆者の現時点での利用方法のご紹介をしたいと思います。

なぜGitHub Projectsなのか

「なぜGitHub Projectsが良いか」を話す前提として、ピクセルグリッドでは、ソースコードの置き場はGitHubであるということがあります。受託案件では先方都合により、先方のGitHubリポジトリを使うこともありますし、社内のリポジトリで作業が終わったあと、どこか別の場所にアップロードなどして納品とする場合もあります。しかし、基本的にはGitHubを利用して業務を行っているという点は変わりません。

最終的な成果物がソースコードなので、なにごともできるだけ、ソースコードとリンクしているほうがたどりやすいです。

たとえば、なにか問題が起きたときに原因を探るため、該当のソースコードを開いて、git blameすることでコード行の最終変更内容であるコミットを割り出して調べるといったことをすることもあるでしょう。そういった場合に、その作業の元になったタスクやバグ報告などと該当のソースコードをリンクしていれば、原因をたどっていきやすいです。そのため、GitHubに用意されているIssuesやPull requestsを使うと関連付けやすく便利です。

IssuesやPull requestsを管理しやすいビュー

しかし、これらのGitHubで用意されているビューは、詳細なフィルターこそあるものの、単純な検索結果一覧であり、進捗などのプロジェクト管理には向きません。また、LabelsやMilestoneなどは用意されているものの、これだけでは管理したい内容が足りなかったりします。

GitHub Projectsは、この問題を解決してくれます。GitHubで立てたIssuesをカードにして「かんばん」で表示し、カードには必要に応じて作った項目を入力するなど、カスタマイズして管理できます。たとえば、そのカード（タスク）を作業するための工数を入力する欄などを作って入力、表示することができるのです。

なお、筆者はあくまで実装が発生するようなのもの、つまり、コードの変更がありえるもののみをGitHub Projectsで進捗を管理しており、プロジェクト全体として次に行いたいこと、たとえば「それが今どんな状況なのか」などはGitHub Projectsでは管理していません。GitHub上での管理は、コードに関連してできることが利点と前述しましたが、逆に実装より大きな視点で見た場合はその限りではないと思っています。

ですので、本記事で（GitHub Projectsを使って）取り扱うプロジェクト管理とは、「実装フェーズの管理」とご認識いただければと思います。

GitHubの機能だからこその動作の軽さ

筆者は、GitHub Projectsを使う前には、同様の背景から、ZenHubを使っていました。GitHub Projectsで行いたい管理内容と同等のことはだいたいできますし、むしろ細かいところの機能としては、今はまだZenHubのほうができることが多いです。

しかし、ZenHubはGitHubにプラグインとして入れて拡張して使うものなので、GitHub上で確認するときに、GitHubの元の内容が描画されてから遅れてZenHubの内容が描画されるなど、やはりプラグインであるゆえの使いづらさ、ストレスがありました。

GitHub Projectsは、GitHub自体がもともと用意している機能ですので、こういった面での使いづらさやストレスがかなり軽減されます。

そのせいか、ZenHubで管理していたときはあまりステータスなどを更新してくれなかったメンバーも、GitHub Projectsにしてから積極的に更新してくれるようになったように感じています。

Trelloなどのその他のツールでも、用意されているプラグインやAPIなどを使えば、便利にGitHubと連携して使うことはできると思いますが、やはりGitHub自体に組み込まれているほうが快適さは勝るように思います。

また、「ZenHubが落ちていて作業できない」といったリスクも、外部ツールを使えば使うほど高まりますので、GitHubに集約できるならしたいという思いもありました。

もちろん、これらは、筆者の用途での話です。GitHub Projectsもまだ成長段階でしょうし、読者の方がやりたいことができないということもあるとは思います。ただ、GitHubを使っていてソースコードと関連付けて管理したいという場合には、現段階でもこの快適さはおすすめできます。

カスタマイズできるビュー

GitHub Projectsは、少し前からよく見かける、スプレッドシート的にデータを入力して表示形式は自分の用途に合わせて使う、というタイプの管理ツールです。

Table／Board／Roadmapといったレイアウトを選んだうえで、独自の項目を追加したり、それらの表示／非表示、グルーピング、フィルタなど、アイテムを見つけやすくするためにさまざまな設定ができます。また、それらを「ビュー」として保存しておくこともできます。

筆者も用途に合わせていくつかのビューを用意しています。

以降、実際にどんなものかわかりやすいよう、キャプチャを交えて紹介したいと思います。

実際の案件で使っているものをお見せすることはかなわないので、本記事用に作成したサンプルになりますが、設定や利用方法はなるべく同じとなるように用意しました。

Mainビュー（Boardレイアウト）

まず、筆者がメインで使っているビューは次のキャプチャのようなかたちです。

このビューは、「Boardレイアウト」を設定し、いわゆる「かんばん」で運用しやすいようにカスタマイズしています。ここに表示されているカードは、基本的にはGitHub Issuesです。とりあえず「Backlog」にカードをためて、進行状況によって「Todo」「In Progress」「Review」「Done」など、他のリストに移動して使います。

かんばん

「かんばん」はカードをリストで並べて状況に応じてカードを動かしていきますが、これについては、過去のCodeGrid記事がありますので、詳しく知りたいかたはぜひご参考ください。

• かんばんボードを利用した開発効率の向上 | Trelloを使った業務管理

GitHub Issuesにある「Assignees」や「Label」などの項目をカード上に表示するかどうか、個々に設定できるのに加え、それぞれのproject（GitHub Projectの単位）独自の項目「カスタムフィールド」を設けることが可能です。私の場合は、いくつかのissueをグルーピングするための「Epic」という項目と、「工数」、それから工数をどの月の分として計上するかを指定する「対応月」を追加して使っています。

カードの特定項目をクリックすることで、同じ値がつけられたカードに絞り込むこともできます。以下は、1つ前のキャプチャの状態からEpicが「ツールチップ機能追加」となっている部分をクリックした様子です。

工数集計用ビュー（Tableレイアウト）

筆者は、月ごとに誰がどれだけの工数分稼働したかを管理する必要があるため、このビューを用意しています。

レイアウトは「Table」で、次のキャプチャのように表示されます。

このレイアウトでは一覧性が高くなり、Boardレイアウト時には詳細を開かなければできない、各フィールド値の変更をリスト上で行うことができます。

グルーピングして表示することも可能で、AssigneesごとやStatusごと、カスタムフィールドごとなどでまとめることができます。また、まとめたグループごとに開閉もできます。

フィールドが数値であれば、それを合計した値をグループごとに表示することができるのも便利です。筆者は、月ごとにグルーピングして工数の合計値を表示するように設定しています。

誰かの工数が知りたいときは、このビュー上でさらにフィルタを掛けて表示すると、月ごとの合計値もフィルタ結果のみの合計値になります。

Roadmapレイアウト

もうひとつ、「Roadmap」というレイアウトがあります。本記事執筆中に追加されたようで、現時点で筆者はまだこの機能、表示形式について、詳しく試したりはしていないので、本シリーズでは深く触れることはしません。

簡単に紹介だけすると、アイテムに対して開始日と終了予定日を設定し、それを軸に表示することができるというレイアウトです。

グルーピングするフィールドを設定すると、グループごとの期間も表示されます。

ざっくりと、予定を立てたり調整するのに使えるかもしれません。

Organization配下に作られるGitHub Projects

GitHub上でリポジトリを閲覧すると、「Issues」と「Projects」は同列のメニュー上に表示されています。

しかし、GitHub Issuesはそのリポジトリ配下の機能で、GitHub ProjectsはユーザーもしくはOrganization配下の機能です（この後、随所で「ユーザーもしくはOrganization配下」などと言うのはくどいので、「Organization配下」とします）。

つまり、projectを作成すると、Organizaitionが持ついちprojectとして作られ、Organizaitionの「Projects」のページに並びます。

このシリーズでの表記

このシリーズでは、GitHubのProjectsという機能全体を「GitHub Projects」、この機能の中の個々のプロジェクトを「project」と表記します。また区別のため、いわゆる一連の何かを達成するための開発計画としての「プロジェクト」のことを「案件」と呼ぶことにします。

リポジトリ側の「Projects」のページには、たとえそのリポジトリのissueをprojectに登録していても、この段階では表示されません。projectとリポジトリをリンクさせることで、リポジトリ側のページで一覧されます。

リポジトリ側の「Projects」ページから新しいprojectを作成することもできますが、その場合でもあくまでOrganization配下にprojectが作られ、この場合は自動でそのリポジトリとリンクします。

Organizationの「Projects」ページで作成するのと、リポジトリ側の「Projects」ページで作成するのとは、projectを作ってからリンクさせたいリポジトリを選ぶか、リンクさせたいリポジトリを決めてからリポジトリを作成するかの違いでしかありません。

issueのprojectへの登録は手動が基本

projectを特定のリポジトリとリンクさせても、そのリポジトリのissueすべてがprojectで自動で登録されるわけではありません。リンクさせてから新しくissueを作っても、リンクしているprojectに自動で登録されることもデフォルトではありません。

そのため、前述のキャプチャのproject内でissueが表示されているのは、作ったprojectで管理したいissueを一つずつ選んで登録しています。もしくは、作ったissueからそのOrganization配下の特定のprojectに関連付けます。

手動で登録しなければならないのは、面倒ですし、抜け漏れが心配です。その場合でも、たとえば、必ずproject側からissue化するようにするなどすればさほど気にならないと思います。projectが関連付けられていないissueをフィルターして確認するなどの方法もあります。特定のリポジトリで作成したissueはすべて特定のprojectに自動で登録するようにすることもできますが、筆者は使っていません。手動で登録しなければならないというのは、逆に、管理したい単位では入ってくる必要がないissueが勝手に入ってこないとも言えます。

自動でproject保存

本文中で触れた、「自動でprojectに登録する方法」も気になる方はいらっしゃるかと思いますが、現時点では筆者は利用していないので、本記事では以降で詳しい説明をすることはありません。今後筆者も利用してこの使い方が便利といった所感を得たら、改めて別の記事として紹介するかもしれません。公式ドキュメントとしては、以下が用意されているようです。

• projectの自動化について

リポジトリをまたいだissueの登録が可能

GitHub ProjectsはOrganization配下の機能なので、Organizationが持つリポジトリのissueであれば、複数のリポジトリをまたいで登録することができます。

そのため、たとえば「プロジェクト（案件）は1つだがリポジトリはいくつか分けてありまとめて管理したい」といった場合や、逆に、「1つのリポジトリで運用しているが『子プロジェクト』ごとに分けて管理したい」といったことが可能です。

1つのissueに複数のprojectを関連付けることもできます。この場合、「issueのclose」はGitHub Issues側の機能なので、closeされればすべてのprojectでclose状態として表示されます。

たとえば、管理者用projectで「アサイン済み」からなにもしなくても、作業者側のprojectで進めた結果issueがcloseになれば、管理者用projectでも「Done」のStatusに移ります。

Workflowsで自動化

close時に自動でStatusが「Done」になるのは、GitHub Projectsの「Workflows」によるものです。現時点では、オンオフの切り替えや、簡単な設定変更程度しかできませんが、この機能が充実すると便利になりそうです。

issue側での表示とproject上での詳細表示

issue側では、右袖に「Projects」という欄があり、登録されているprojectがここに表示されます。複数のprojectに登録されている場合は、ここに並んで表示されます。また、ここから登録したいprojectを追加することも可能です。

登録されたprojectそれぞれで設けられているフィールドに入力していくこともできます。初期表示では、関連付けたproject名とStatusだけが表示されていますが、ここは開閉でき、その他のフィールドもここから入力可能です。

project上からは、アイテム内のタイトルをクリックすると、詳細が横から開いて表示されます。

開いた詳細パネル上のタイトルをクリックなどから、リポジトリ内のissue本体を開けます。開かずにリストから直接issue本体を開きたい場合は、アイテムのタイトルをミドルクリック（ホイールクリック）など普段の別タブで開く操作をすれば開けます（タイトル部分はa要素でhref属性にissue本体のURLが入っています）。

まとめ

今回は、GitHub Projectsがどんなものなのかを紹介をしました。次回は、実際に筆者が使っている設定や運用方法、便利な機能など、使い方についてより掘り下げて紹介する予定です。