GitHub が新機能「Projects」を公開！
先日行われた GitHub Universe conference では
GitHub のアップデートについて、多くの発表がありました。
発表された新機能はこちらにまとめられていますが、
どれもワクワクするような内容ばかりですね！
今回はその中でも、Projects について、
競合っぽいもの（特に ZenHub）との違いを考えたので、共有しておきます。
※私は GitHub とは何ら関わりの無い人であり、この内容は GitHub の考えを表すものではありません。
あくまで１ユーザーの考えとしてとらえて下さい。。
Project の機能とは（前置き）
操作方法などは
「GitHubのProjects機能を使ってみました」
こちらのページで既に解説して下さっている方がおられますので、こちらをみてもらうとしまして。
簡単に、その機能をまとめると。
- issue や pull request 等を「カード」として扱い
- それぞれをルールに従って分類（一般的にはTODOやin-progress、done 等の進捗状況別に）し
- 特定の議題について、現状を視覚的に把握することができるようにするシステム
と言えるでしょう。
箇条書き三つについて、一つずつ見ていきましょう。
issue や pull request 等を「カード」として扱う
Project の中では、 issue や pull request はカードとして扱います。
画像の上から issue、pull request、 ノート(Project内専用の項目)となっています。
左上のアイコン以外は、基本的にほぼ同じ構造となっている事が分かります。
Projectsでは、このカードを取り扱います。
（カードを）それぞれをルールに従って分類する
先ほど作ったカードを分類する。これがProjectsの主機能になります。
よくある分け方としては、
- TODO(やること)
- In Progress(今やっていること)
- DONE(既に終わったこと)
のように進捗状況に応じて分類しますね。
これで、他の人が何をやっているのか、次にするべき事は何かが分かりやすく整理されます。
特定の議題について、現状を視覚的に把握する
このProjectsですが、各レポジトリに一つではなく、複数作る事が出来ます。
というよりは、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の人間でもないので間違っている部分があるかもしれません。
（自分では大筋間違ってないと思っているので記事にして公開しているのですが。）
もし指摘や疑問等ありましたらコメントお願いします。
間違った考えのまま垂れ流しておくのもイヤなので。ぜひ。