Redmineでチケット駆動形開発を行ってみて

# はじめに

フリーランスになって3ヶ月が経ちましたが、どうにか生きて行けてます。
今月は確定申告とかいうボス級のが待ち構えてますが、どうにか生き延びていきたい。

前の会社で、4人チームのリーダーさせてもらったときにそれまでのプロジェクトの慣習を壊してみたいなと思ってチケット駆動形開発を導入してました。
前プロジェクトから引き継ぎたくなかったのは以下。

- エクセルで作ったWBSでの進捗管理
- バグ管理にしか使われないRedmine
- テキスト、エクセル ...etcのフォーマットで残される検討メモ（残されないことも多々。。。）
- 誰がなんのタスクをやってるのか不明な状況
- レビューを投げたけど上司が忘れてるパターン

Redmineを導入してプロジェクトを回し、残業をほぼすることなく納期通りに納品できたので、やってよかったこと、悪かったことなど書いていきます。

# Redmineを導入した結果

- エクセルで作ったWBSでの進捗管理<br>
→チケットを作れば自動で作成される、調整するのも簡単
- バグ管理にしか使われないRedmine<br>
→できる限りの情報をRedmineに集約
- テキスト、エクセル ...etcのフォーマットで残される検討メモ（残されないことも多々。。。）<br>
→チケットに検討の過程、結果が記録される。何か知りたければとりあえずRedmineを検索することで情報が得られる
- 誰がなんのタスクをやってるのか不明な状況<br>
→チケットにより誰がどれだけタスクを抱えてるのか明確に。進捗度などもわかりやすい
- レビューを投げたけど上司が忘れてるパターン<br>
→自分がボールを持っているチケットの一覧を確認することで、レビュー依頼がどれだけ来ているか一目瞭然

# よかったこと

## Dockerの導入

環境の話ですがDocker版のRedmineを導入しました。
[【CentOS 7.3】dockerをインストールしてredmineを起動する。easy_ganttも入れてみる。](https://qiita.com/kaneuchi_0202/items/1e9de73effd24a774726)

自前でインストールすることなくDBとRedmineを導入できるし、コマンド1つでバックアップ・リストアもできて非常に楽でした。
バックアップコマンドをシェル化、cronでの定期実行によって週に1回取得したバックアップファイルがSVNにコミットされるようにしてました。

## [Easy Gantt](https://www.easyredmine.jp/en/redmine-gantt-plugin)の導入

WBSを手で書きたくなかったのでチケットから自動で線を引いてくれて、ガントチャート上で期限を変更できるので便利でした。
表示するチケットを絞り込みできるので、以下のようなトラッカーを用意してWBSを作ってました。

- 【WBS】機能
 - 【WBS】設計
 - 【WBS】製造
 - 【WBS】試験

きれいにWBSは引いてくれるので良かったですが、エクスポートがいまいちでした。
表示してるままで出力してほしかったんですが、PDF出力するとかなり微妙な感じに。。。
仕方ないのでFirefoxの機能でスクショ撮って、顧客に提出してました。

## 「ボールを持ってる人」フィールドを追加

全チケットにカスタムフィールドで追加してました。
ネットで見かけて真似したんですが、今誰が担当なのかを明確にできるのでタスクが宙に浮くことがなくなりました。
担当者とはこんな感じで使い分けてました。

- 担当者：そのチケットを完遂する責任を持った人
- ボール：今そのタスクに関する作業の責任を持った人

例えばレビューを依頼するときに、担当者を変えてしまうとレビューアがレビュー後に誰に回せばいいかわからなくなる可能性があるのと、担当者がどれだけのタスクを抱えてるかの見通しが効かなくなるので、かなり有用でした。

## [View Customizer](https://github.com/onozaty/redmine-view-customize)の使用

どこかの記事でも見かけましたが、将来的な互換性の問題なども考えてプラグインを入れるのは最終手段としてました。
そこでView Customizerを入れておくと、細かいところに手が届く感じにカスタムできてチケット駆動型開発がスムーズに進行できました。
以下カスタム例。

- ヘッダカスタマイズ
 - トップなどのデフォルトで存在する不要な項目を削除
 - 自分がボールを持っているチケット一覧へのリンク追加
 - WBSへのリンク
- チケット新規作成時の初期値指定
- プロジェクトごとにヘッダの色を変える
- チケットのトラッカーに応じてデフォルト値を変更する
 - 擬似的にテンプレとして使えて便利
- WBSに祝日を追加

などなど、jsで何でもできるので、jsに詳しい人ならゴリゴリのカスタマイズも可能。

## 情報の[Knowledgebase](https://github.com/alexbevi/redmine_knowledgebase)への集約

検討資料、注意点、環境情報などはエクセルなどに記載して様々なフォルダに配置されてましたが、全てRedmineに集約しました。これによって、とりあえずRedmineを検索しておけば情報が得られるようになります。
Wikiだと記事を作成した後に、リンクを別の記事に追加したりするのが面倒でやめました。
Knowledgebaseだと記事にタグを付けたりもできるので、後から探しやすくてよかったです。
もう少しダッシュボードをカスタマイズできると、なお使いやすいですね。

## メンバーへの定期的な声掛け

他よりもダントツで大事でした！！！！！！
やはりチケット駆動に慣れてないメンバは、

- チケットのステータスを更新してくれない
- 個々人でタスク管理する
- 自分に割り振られているチケットを見る習慣がない
- 閉じられることのないゾンビチケットが産まれる

などなどどうしても発生してしまうので、毎日チケットをチェックして口を酸っぱくして言うようにしてました。
口うるさくしてたおかげで、2,3ヶ月もしてプロジェクト後半になるとメンバもスムーズにチケット駆動してくれるようになった気がします。
結局の所、ツールはツールでしかなくていかに上手く使えるかが大事ってことを痛感しました。

# やってたけど途中でやめたこと

## 厳しいチケット管理

よくアンチテーゼとして上がってるのを見ますが、Redmineはかなり細かく制限できるのでやりたくなって理想のフローとか作ってましたが、途中でめんどくさくなったり例外ケースがよく起こったりしたのでやめました。
制限の例。

- ステータスフローを一方通行にする
    - 差し戻したりできない
    - 間違えてステータスを進めてしまった場合に戻せない
    - 工程を1つずつしか進められなくしたが、複数先のステータスに更新できない
- トラッカーを修正できるロールを制限する
    - 他人に自分の代わりのチケット作成、更新を依頼できなくなる

結局例外ケースがちょいちょい発生してめんどくさくなるだけなので、自由にしてある程度運用で縛るのが現実的かなと感じました。
WBS用のチケットだけはリーダーしか、修正できないようにしてましたが。

## 個人でローカルタスク管理

割り振られたタスクを別途自分用のツールなりで管理してるメンバもいましたが、やりづらかったら戻していいからと一旦はやめてもらいました。
個人で管理するのもいいとは思いますが、どうしても二度手間になるためチケットの更新が遅れがちになる傾向になってました。

- チケットに進捗率が反映されない
    - 管理者側からは進捗が0か100でしかわからない
- 検討の過程がローカルにしか残されず、後から読み返すことができない
    - メンバが何かで詰まっていても気づきことができない
    - バグが発生したときに検討結果を見返せない
- 体調不良などでメンバが休んでも、状況が不明なので誰も巻き取れない

人間どうしても二度手間になると、反映が遅れがちになるので、いっそRedmineだけで管理してもらうようにしました。

# 最後に

とりあえず思いついたものをつらつらと書いてみました。
試験導入して初回からそれなりに成果を出せたのは良かったですが、改善点も色々見えたのでどんどんブラッシュアップしていってほしいですね（私は退職したので関われませんが。。。笑）

とにかく初期導入時は運用をあまりガチガチにせず、柔軟に使いやすいように対応していくことが大事だと感じました。
あとはメンバに浸透させることが重要なので、あまり使ってくれないメンバがいたらなぜ使わないのかを聞いて、ツール側を対応させることも大事だと思いました。

今後も便利そうなツールはガンガン導入して、快適に仕事できるようにしたいと思います！