HuBoard - GitHub issues made awesome.
現在のプロダクトでは，今までタスク管理に Redmine + Backlogs
移行して1ヶ月経ったので，使ってみた正直な感想や Tips などを雑にまとめてみる．
専用リポジトリ
HuBoard は Gitter などと同じくリポジトリ単位で使うサービスになっている．
現在のプロダクトでは機能ごとにリポジトリを分けているけど，タスク管理はプロダクト全体で行いたかったので HuBoard 専用のリポジトリを用意した．
メリット
HuBoard のメリット（Redmine + Backlogs と比較したメリット）を挙げてみた．
挙げてみて思ったのは，まぁ HuBoard と言うより GitHub の機能がメリットになってるなーということ．
- ラベルやマイルストーンでメタ情報を付与できる
- マイルストーン単位で機能横串でタスクの状況を見ることができる
- API 経由でタスクを操作できる
- Filters の機能が便利
- オシャレ感（個人差がありますw）
デメリット
逆にデメリットを考えてみた．
最初に書いた件が1番ツラくて，Backlogs だったらストーリーに対してタスクを追加できてたのになーと思った．
- タスクを追加するときにストーリーが定まっていない
- 全体的に動作がモッサリしている
- 1画面で確認できるタスク数が少なく可視性が悪い
- タスク上でマイルストーンを確認できない
- タスク上でホバーしないとラベルを確認できない
運用 Tips
少し工夫して使っているので，紹介する．
1. 手動ラベル
デメリットにある通り，タスク上でマイルストーンを確認できないため，タスク名の接頭辞にマイルストーンの略称をラベルとして手動で付けている．例として以下のような感じ．
- [AAA] 開発タスク1
- [AAA] 開発タスク2
- [BBB] 開発タスク3
この運用のメリットとして，HuBoard のヘッダーにあるキーワード検索でカジュアルにタスクを絞り込めることで，タスクを追加するときは高コストだけど，その恩恵は受けられている気がする．
2. Stylebot
デザインを調整するために Stylebot でスタイルを公開した！と言っても変更点は主に2点だけで非常にシンプルだと思う．
- タスクに枠線を付けた
- ラベルを常時表示した
ただし，このスタイルだとマイルストーンビューのデザインが崩れてしまうので，そこは課題のまま残っている．
サンプルなので上で紹介した手動ラベルは使ってないけど，キャプチャはこんな感じ．
Before
After
あくまでツールだから！
もうホントに何度も言ってるけど，HuBoard は銀の弾丸じゃないし，Redmine + Backlogs でうまくタスク管理できていなかったのに HuBoard に移行するだけでうまくできるわけないじゃん！って．むしろタスクを追加する操作性だけで言えば Redmine + Backlogs の方が楽だったし．
僕もエンジニアだから，機能に大きな差がなくてもモダンな方を選びたくなるし，独自のツールに頼らずに全てのリソースを GitHub に集める方がトレンドだって言う話も共感できるし，それは積極的に推進するべきところだと思う．
ただし，最終的に重要なのはタスク管理の重要性を理解することだったり，適切にタスクを洗い出せるスキルだったり，継続的に状況をアップデートするモチベーションだったりする．
あとプロダクト全体で見ると，リリースする機能のフォーカスがブレてると結局何を開発したら良いのかわからずうまくタスクを洗い出せないので，イテレーションを回す前提だとしても「何を開発するか」がメンバー間で合意できていることが何よりも重要だと思う．
ラストマイルを意識する
タスク管理のスキルって何だろう？っていうのを考えたときに，個人的には前職の大規模 SI での経験が活きてる気がした．要件が追加されたら見積もりをして，進捗を確認して，リカバリ計画を立てて，っていうことを毎日やってた．だからこそ今でも細かくタスクを考えることができるし，ある程度の誤差で洗い出せている気がする．
あともう1点，以前にプロダクトで ThoughtWorks 本の読書会をやったときに，第1章に出てくる「ラストマイル」の話が目から鱗で何度も読み返した．第1章を読むためだけに買っても良いと思うほど．
ThoughtWorksアンソロジー ―アジャイルとオブジェクト指向によるソフトウェアイノベーション
- 作者: ThoughtWorks Inc.,株式会社オージス総研オブジェクトの広場編集部
- 出版社/メーカー: オライリージャパン
- 発売日: 2008/12/27
- メディア: 単行本（ソフトカバー）
- 購入: 14人 クリック: 323回
- この商品を含むブログ (81件) を見る
実際に現在のプロダクトで予定通りリリースできなかったケースを考えてみると，このラストマイル問題に苦戦した経験が多いように思う．
この「ラストマイル」というのは開発プロセスにおけるフェーズの1つであり、ソフトウェアが機能要求を満たすところまで完成していながら、まだ稼働に入らず、企業に対して価値を提供し始めていない段階に相当します。
本書にはラストマイル問題の解決案として以下のような話が書かれている．
- 非機能要求を意識すること
- 自動化を推進すること
- 環境間の違いを無くすこと
もう少し具体的に言うと，例えば以下のような技術的負債が残ったままなこともよくあると思う．
- STG 環境が無かったり，あっても PROD 環境と大幅に乖離がある
- PROD 環境にリリースして気付く問題がある
- テストコードがない
- CI 環境がない
- リリースのロールバックができなかったり，できたとしても再度ビルドからやり直す必要がある
- リリース手順に手作業や判断が多く介入する
タスクを洗い出すタイミングで，ちゃんとこのラストマイルを意識できるかが重要なポイントだと思ってるし，タスク管理が得意な人は無意識にここまで考えてるんじゃないかな．
まとめ
個人的には HuBoard は可もなく不可もなくって感じだけど，GitHub でタスク管理ができて柔軟性があるという意味で，良いかなとは思う．
あと GitHub でタスク管理できるならモチベーションが上がるっていうメンバーも少なからずいるようなので，その勢いに期待！って感じ．
ちなみに HuBoard は OSS として開発されてて，気になるところがあるならプルリクエストを出すこともできるので，将来性はありそう．
