GitHub の機能「Projects」に関する私の見解（ZenHubとの違いから）

# GitHub が新機能「Projects」を公開！

先日行われた [GitHub Universe conference](http://githubuniverse.com/) では
GitHub のアップデートについて、多くの発表がありました。

発表された新機能は[こちら](https://github.com/universe-2016)にまとめられていますが、
どれもワクワクするような内容ばかりですね！

今回はその中でも、[Projects](https://github.com/universe-2016#projects) について、
競合っぽいもの（特に ZenHub）との違いを考えたので、共有しておきます。

※私は GitHub とは何ら関わりの無い人であり、この内容は GitHub の考えを表すものではありません。
あくまで１ユーザーの考えとしてとらえて下さい。。

# Project の機能とは（前置き）

操作方法などは
「[GitHubのProjects機能を使ってみました](http://qiita.com/vivayashi/items/dea7abb94912f993a493)」
こちらのページで既に解説して下さっている方がおられますので、こちらをみてもらうとしまして。

簡単に、その機能をまとめると。

- issue や pull request 等を「カード」として扱い
- それぞれをルールに従って分類（一般的にはTODOやin-progress、done 等の進捗状況別に）し
- 特定の議題について、現状を視覚的に把握することができるようにするシステム

と言えるでしょう。

箇条書き三つについて、一つずつ見ていきましょう。

## issue や pull request 等を「カード」として扱う

Project の中では、 issue や pull request はカードとして扱います。

![スクリーンショット 2016-09-17 1.26.17.png](https://qiita-image-store.s3.amazonaws.com/0/92484/4bd46298-7d02-9838-0383-97b261b0bd4f.png)

画像の上から issue、pull request、 ノート(Project内専用の項目)となっています。
左上のアイコン以外は、基本的にほぼ同じ構造となっている事が分かります。
Projectsでは、このカードを取り扱います。


## （カードを）それぞれをルールに従って分類する

先ほど作ったカードを分類する。これがProjectsの主機能になります。
よくある分け方としては、

![スクリーンショット 2016-09-17 1.39.24.png](https://qiita-image-store.s3.amazonaws.com/0/92484/23e46961-1d5b-145e-0ab3-b1d03331205a.png)

- TODO(やること)
- In Progress(今やっていること)
- DONE(既に終わったこと)

のように進捗状況に応じて分類しますね。
これで、他の人が何をやっているのか、次にするべき事は何かが分かりやすく整理されます。


## 特定の議題について、現状を視覚的に把握する

このProjectsですが、各レポジトリに一つではなく、複数作る事が出来ます。

![スクリーンショット 2016-09-17 1.46.24.png](https://qiita-image-store.s3.amazonaws.com/0/92484/7fab3e0d-f476-5ff8-763f-f2425e61988a.png)

というよりは、issue や pull request と同様にタブの横に現在のプロジェクト数が表示されるようになっていますので、
同時に複数のプロジェクトが作られるような使い方が想定されているのでしょう。

議題ごとに（例えば新機能Aの実装と以前作られた機能Yのアップデートなど）プロジェクトも分けることで、
情報が混ざってしまうことを避けられるということですね。


# Projects 機能と ZenHub を比べて分かる事とは(本題)

ところで、Projects 機能と ZenHub の両者を少しいじってみると分かりますが、
GitHub の Projects は ZenHub に対してあまりにも貧弱なイメージです。

例えば、ZenHub にはバーンダウンチャートを書く機能がありますが、 Projectsにはない。
というかそもそも Projects ではストーリーポイント（見積作業量）の設定もできない。

ZenHub では最近エピックの設定ができるようになりましたが、それもProjectsにはありません。

ZenHub になくて Projects にある機能と言えば、プロジェクトを複数設定できること（ZenHubではレポジトリに一つ）と、
使い方の良く分からない、カードとして登録できるノートの機能くらい…

と思うわけです（私も最初は思いました）。

が、しかしそれは「スクラムを使ったアジャイル開発」を前提に考えているからこその思考です。

そもそもスクラムで行いたいのは進捗管理（つまり納期との戦い）です。
企業で進捗管理をするには効果的な方法ですが、オープンソースの開発では特に必要無いものになります。

## Projects 機能は情報のハブ

GitHub としては
「スクラムをしたければ各々で ZenHub とか、自分たちに合ったツールを入れてね」
って考えているのではと思うわけです。

それに対して、Projects 機能は
「単純に情報のハブとして使ってね」
と考えてていると思われます。
つまり、開発しているソフトウェアの細かい情報は、全てここにあつまるようにすると。

そう気付けば、使い道がなさそうだったノート機能についても、説明がつけられます。
特にソフトウェアのissueとして上げる内容ではないけども、管理しておきたい情報（○○日にツイッターで告知をしよう、とか）も、
全てここに入れられるようにするための手段だった訳、ですね。

また、Projectを作成したときにTODO等のカラムが一つもなく、自分で設定するところから始める必要があることも同様の理由ですね。
つまり、情報のハブとしてつかってもらう事を考えているので、カラムのタイトルが「TODO」「DONE」になるとは限らない、
例えば「Twitterで告知したこと」「Facebookで告知したこと」等の分け方をして、それぞれにノートを貼っていく使い方もあるでしょう。

Project 機能の立ち位置は、「プロジェクトに関わる情報が集まる場所」なのです。

## Wiki とかページとかとの関係は？

情報を集約するという意味では、既に GitHub には Wiki やページという機能があります。
それらと比べると、Projects 機能では簡単に書き込むことが出来る一方、多くて数行程度しか表示できないという点もあります。
また、後から検索することも難しそうですね。
これらの事を考えると、細かい、一時的な情報をまとめる場所になるのではないでしょうか。

# 結局言いたかったこと。まとめ。

GitHub の Projects 機能はスクラムをするためのものではない。
情報を集約するための、ハブである。

よって、ZenHub 等のスクラム用のソフトウェアとは見た目は近いが、役割は全く異なる。
もし、移行を考えられている方がいらっしゃったら、本当に移行してよいか十分検討された方が良いでしょう。

## 最後に

別に最初にも書きましたが、GitHubの人間でもないので間違っている部分があるかもしれません。
（自分では大筋間違ってないと思っているので記事にして公開しているのですが。）
もし指摘や疑問等ありましたらコメントお願いします。
間違った考えのまま垂れ流しておくのもイヤなので。ぜひ。