今更ながらRedmineでチームのタスク管理した時の話（＋これからのタスク管理）

#はじめに
今更ですが、Redmineでタスク管理をやって見たので、その時のノウハウをなるべく具体的に書きます。（方針とか、ポイントとかを載せている記事は多く見かけますが、超具体的な設定まではなかなか見かけないので）
加えて、これから先、タスク管理ってどうなってくんだろうな・・・って調べた情報を最後に載せます。

なお、想定読者はRedmineでタスク管理始めたい人です。Redmineインストール後にいじりながら見てください。
既にRedmineな人は、こんなケースがあったのだなーと、参考にしていただければと、思います。

あ、いちおうそれなりに上手くいったと思うので、成功パターンとして見てもらって良いです。（どちらかと言えば程度かもですが）

#やったこと
前提
開発方式：ウォーターフォール
時期：2017年やで
プロパー：5名くらい
パートナーさん：3社で15名くらい
対象工程：アプリの内部設計〜単体テスト（自分がリーダーやってた期間）
プロジェクト概要：Java（画面もバッチもあるシステム）の案件
※結合テスト以降も使われていたっぽいですが、あまり押さえきれてないので、割愛します。

なお、部門の他のプロジェクトは、いずれもExcelでタスク管理していたので、そんな状況を打開したい思いもありつつ、Redmineでの管理始めました。

##Redmine設定
トラッカー/項目
以下のようなトラッカー/項目を用意しました。使い分けは「使い方」で説明します。

トラッカー	概要	実際の項目
中日程	別で作成した中日程の帯と紐付く	1
タスク（一般）	ドキュメント成果物以外のタスクに利用	2
タスク（ドキュメント成果物）	ドキュメント成果物に利用	3
課題	言わずもがな	4
不具合（単体テスト）	言わずもがな	5
不具合（結合テスト）	言わずもがな	6
仕様変更	言わずもがな7	8

上記以外に共通で保持していたフィールド
標準フィールド：担当者/親チケット/開始日/期日/進捗率
カスタムフィールド：現在ボールを持っている人

リスト系の項目について
推測がつくものは除外しています。（工程系とか/要否とか）
それ以外にも、オープンにしていい情報かどうか判断できない項目はふわっとした表現にしています。

カテゴリ：機能分類を当ててました。最終的に機能ごとの不具合とか集計する時に便利に使ってましたし、機能ごとの見積もりがどれくらいハマってたのかを見たかったため。
タスク分類：UTケース作成/ITケース作成/UT実施/IT実施/その他
責任分類：自責とか他責とか
原因分類：どの成果物が悪かったのか的なこと。（プログラム？設計書？）
影響範囲分類：機能内外？システム内外？的なこと

チケット関連イメージ
親通しに関係がある場合は「関連するチケット」を使ってました。

ワークフロー
※全て相互に遷移可能。使い勝手優先。

トラッカー	ステータス
中日程	新規/進行中/確認中/承認中/終了/却下
タスク	新規/進行中/確認中/承認中/終了/却下
不具合	新規/原因調査中/設計中/PG・UT中/IT中/終了/却下
課題	新規/対応中/終了/却下
仕様変更	新規/対応中/終了/却下

ロール
3種類のロールのみ：プロパー/パートナーリーダー/パートナーメンバー

権限制御
特定項目はパートナーに修正されるとまずいので、それだけ禁止。
※記事書いてて思いましたが、上記制御だけなので、2ロール（プロパー/パートナー）で良かったな。

##使い方
トラッカーの使い分け

トラッカー	更新していい人	起票単位/粒度	補足
中日程	プロパーのみ	機能×工程	9
タスク（一般）	誰でも	定義なし（無制限）	自由に使ってもらった。
タスク（ドキュメント成果物）	誰でも	納品する成果物一覧と同じだけ起票	10
課題	誰でも	定義なし（無制限）
不具合（単体テスト）	誰でも	定義なし（無制限）
不具合（結合テスト）	誰でも	定義なし（無制限）
仕様変更	誰でも	仕様変更の単位ごと	起票はプロパーのみ

項目の使い分け
似たような項目について言及します。
【担当/現在ボールを持っている人】
担当：そのチケットを完了まで推進する責任がある人
現在ボールを持っている人：現時点で作業を担当している人

現場では、「現在ボールを持っている人」を打ち返しあってる感じですね。
レビュー依頼とかもこれでやってました。

実績報告
月次で作業報告をあげてもらう必要があったので、もし使いたいなら、実際に作業したチケットに報告をあげてもらって良いよ。と言うことにしていた。
もし上げる際は、パートナーさんにおいては、代表者に一括で計上してもらうようにしていた。
結果的には、3社ともに毎日入れていただけてました。

##運用
EVM
Earned Value Managementを、この機会に試してみた。
実際のEVMグラフ

縦横の目盛りや、どの線がPV/EV/ACなのかってのはあえて明示していません。

PVは、お客様に提示した「見積もり」を「中日程」に当てはめた場合で算出しています。
Redmineにも、「予定工数」と言う項目がありますが、子チケットから算出する設定にしていたので、ここからは取得しませんでした。
各「中日程」トラッカーは、見積もり上の数字で、いくらだってのを、別途管理していました。

EVについては、Redmineの進捗率を、上記の数字と掛け合わして算出していました。
進捗率は、メンバーに指標を設けていて、着手したら10%/担当作業完了なら60%/レビューも含めて完全完了なら100%みたいな感じで、各自に入力してもらっていました。
当時別のプロジェクトも使っていて、そちらが手入力で進捗使っていたっぽいので、ステータスとの連動を諦めちゃいました。
今思えば、交渉して、連動させる方に倒せば良かった・・・

ACについては、Redmineの各チケットに計上してもらっているので、それを集計するのみです。
この時、「中日程トラッカー」に紐づかないチケットもちゃんと集計します。

これらのインプットをもとに、Redmineのcsv出力からのExcel関数で、グラフ化してました。
パートナー各社ごとに出したりしてたので、困っているチームが早期に分かるようになりました。
おすすめ。

チケットの棚卸し
棚卸しは避けられない。
【週次】
棚下ろすのは、「課題」「不具合」。
どちらも、情報共有して、すぐ解決できるものあれば、その場で解決しちゃうために、棚卸してました。

【それ以外タイミング】
「タスク」については、親チケットをクローズするタイミングで、チェックしていました。
また、なかなかクローズしない親チケットの、「タスク」は・・・？って感じで、週次進捗で確認していました。

【棚卸しない】
「中日程」「仕様変更」は、プロパーで制御しているので、いちいち棚卸はしませんでした。

負荷分散
パートナーさんは明確に見積もれたタスクをお願いしているので、そこまでブレない。
問題はプロパー。不透明なタスクにアサインすることが多いので、なかなか先が見れない。
チケットは、タスクが見えたタイミングですぐに発行していたので、未来に何をすれば良いのかは分かっている状態でした。

1チケットずつ見積もるってのも手ではあるのですが、それだと時間がかかり過ぎるし、単純にやりたくなかったので、その選択肢はとりませんでした。
代わりに「チケット数」で会話しました。
Aくん担当のチケットの数が多いから分担しようとか、私の担当チケット少ないのでもらいますとか、ってのを、毎日夕会で会話してました。

正確さにはかけますが、大体の負荷分散はできたかな・・・という感じです。

#振り返り
##プラスに働いたポイント
パートナーが習熟済み
Redmineを使っての開発/タスク管理自体はパートナーさんの方が慣れており、事前に相談して本運用を詰めていきました。
一緒に運用検討できた＆パートナーさんが慣れていたので、導入のハードルを感じずに、スッと導入できました。
もろもろ、パートナーさんのおかげだと思います。
（入れる！って決めて1〜2週間で上記の諸々詰めて、導入できました。）

ツールの集約（過去の失敗からの学び）
実は一度Redmineでタスク管理しようとして失敗した時がありました。（2015年くらい。5年目くらいで初リーダーしてました。）
当時はさらに細かい実績報告を、別途Excelに書いて部門に報告しており、両方に実績入れるなんて・・・となり、廃れていきました。。。
ツールが分散するのは、悪手だとこの時に学びました。

主体はRedmineに絞っていたので、運用が上手く回ったように感じます。
（Redmineだけだと伝わらない場合もあるので、補助的にチャットやメールの利用もしてました。）

事前にどう振り返るのかを決めておく
色々決めておいたので、情報収集ちゃんとできて、振り返りにも活用できました。

• 機能ごとの見積もりがどれくらい当たっているのか/外れているのかを評価したい
  • 機能分類ごとに実績がわかるようにしよう＝カテゴリの活用
• EVMやりたい
  • PV/EV/ACは何からどう取得するのか決めておく

プロジェクトを始める際に、「このプロジェクトはどういう振り返りをして、どう次に活かすのか？」まで意識できると、良いなぁと感じております。

##次は改善したいポイント
遅延の検知と対処
EVM管理のおかげで、一部パートナーさんがヤバイ状態にあるのは、結構早期に気づくことができました。
ただ、検知してからも、なかなか原因がつかめず、根本対策が打てるまでに時間がかかってしまいました。
結局、原因はコミュニケーションロス（お願いした以上にやってくれていた）で、やること整理して、人を一時的に足して、なんとかなりました。

ツールは検知までは結構しっかりやってくれますが、検知した後の原因特定/対処ってのは、スキル/ノウハウ/経験に依存するなと強く感じました。

開始日と期限
「開始日」/「期限」は、子チケットから自動で設定されるようにしていたので、割とコロコロ変わります。
ベースラインとしての情報を保持しておきたかったので別項目を用意したら良かったな・・・と。

Excelで中日程を作ってはあったので、そちらと比べて遅れてる/遅れてないって評価はしてました。
ただ、その評価のためにワンクッションとは言え、計算とかの作業をしないと行けなかったのは、いまいちだったなぁ・・・と思ってます。
ツール上でリアルタイムに見れるようにしておけば、現場も日頃から意識できるようになるので、きっともっと気持ちよく運営できたのでは・・・と思っています。（想像の域を出ませんが）

素のRedmineの限界
素のRedmineが得意とするのは、実績管理だな・・・と感じました。
色んなプラグインを導入すれば、ベースラインを含んでガントチャートを見える化できるのは知ってました。
ただ、もうPJが走り始めている状態だったので、そのプラグインの購入手続きに二の足を踏んでしまいました。上申して買えば良かった気がする。反省しております。

レビューボトルネック
Redmineとは関係ないのですが、プロパーレビューを必須にしてしまったせいで、レビューがボトルネックになってしまいました。
事前にレビュー計画は立てていたのですが、人によって解釈が分かれてしまう表現になっていました。
結果、一部レビュー観点が重複しており、余計に時間がかかるようになってました。

問題発覚後は、改めてレビュー観点を擦り合わせして、ちょっと残業増やしつつで、カバーした感じでした。
あれ、これもコミュニケーションロスやんけ。頼むぜリーダー（自分）。

#Excelと比較
##結論
まぁExcel使うくらいなら、Redmineのが断然良いっすわ。

##メリット
Redmineの良いところ。

Redmineは壊れない
Excelを共有して、いっぱい更新すると・・・よく壊れますね。
復旧したりなんだりとチョー大変な思いをしてました。
Redmineでそんなしんどい状況にはなりませんでした。¹¹

Redmineは重くない
Excel君は過去のレコードが増えるに連れて、書式情報も増え、どんどんファットになっていきます。
開くのに1分近くかかるようになったら、「壊れそうだな・・・」という、なんの役にも立たない覚悟すら生まれます。

重いと、そもそも開きたくなくなるので、更新も滞ります。これが一番辛い。
進捗会の時に、「まだ更新してないので・・・」が頻発し、とうとう限界になった時に「もうどうしようも無いくらい遅延しています」と言う報告が生まれます。

Redmineは分身しない
Excelくんはよく分身する。彼はニンジャなのだ。
「WBS.xls」「WBS_20171209.xls」「WBS_old.xls」「WBS_最新.xls」「WBS_最新が開けなかったので一時的に.xls」「WBS_最新_改.xls」
Redmineは唯一無二だ。

Redmineに集約できる
Excelくんの場合、「不具合一覧」「WBS」「課題一覧」それぞれ別ファイルだ。
しかも、別のフォルダにあることが多い。
新規参入者にとっては少し辛い。
その点、Redmineは全てを集約しているので、あれこれ探さないで済む。

##デメリット
Redmineはユーザ管理が必要
Excelくんは、みんなが見えるところに置いておけばいい。
Redmineはそうはいかない。ユーザ登録してあげて、ロールを付与してプロジェクトに参画させなきゃいかん。
これはちょっと手間だ。

Redmineアレルギー
Redmineに限らないが、Excel以外にアレルギー反応を示す人もいる。
たまたまうちのメンバーにはいなかったけど、いたら何ができたんだろうか・・・
数の暴力で使うことを決定して、慣れてってもらうしか無い気がする。

Redmine構築
Redmineは構築しなきゃならんのが、単純に手間。
BitnamiRedmineなどがインストーラーを出しているので、活用していきたい。

Redmine職人
どうしてもRedmne職人が生まれてしまいがち。
これはちょっと打開策を思いついてない。

そもそも、自分がツール触るのが好きなので、率先して職人になってまう。。。
反省すべきポイントなのですが、触ってる時が楽しくて楽しくて・・・

#これからのタスク管理
##海外のQAサイト抜粋
一番voteの多かった回答を意訳して記載してます。

• What tools do software project managers use the most and would recommend to manage development projects?：2014/2/11：15vote：アジャイルなら「Yodiz」がええで。
• How do I manage the development of software project management?：2015/6/2：1vote：そもそもどういうプロジェクトタイプやねん。回答できんがな。
• What are the most popular tools do you use to manage software development projects?：2016/4/25：11vote：ProjectPierか、Project HQかCollabtiveかFeng Officeやね。
• Which is the most popular software development project management tool?:2017/4/21：11vote：67%がMS Projectやで

上記はほんの一例ですが、「アジャイルなら良いツールあるぜ・・・」みたいなノリが多かったです。
そして、本当に「アジャイル」を推している人が多い。

##アジャイル/リーンというトレンド
ツールとかそれ以前に、そもそも開発方式自体が変わってきていて、世界的なブームはもうアジャイルになっているように見えます。
WBS引いて、ガントチャートで見えるようにして・・・見たいなのは、ウォーターフォールだからこそできる話¹²です。
Redmineは割とウォーターフォール全盛期に生まれている子なので、標準で「ガントチャート」や、エンドレスで「子チケット」を作り続けて超深い階層にできたりします。

最近Jiraを使ってプロジェクトを回しているのですが、標準では、「ガントチャート」は無いし、「子チケット」に当たるものは、1階層分しか作れません。（子の子とかは作れない）
その代わり標準で「カンバン」が用意されていたりと、アジャイル/リーンに寄った作りになっています。

※JiraもRedmineも、アドオンやプラグインを入れたら「ガントチャート」も「カンバン」もできます。ただ、標準搭載されていないってのは、ツールの根本思想が違うって受け取って良いと思っています。

##ウォーターフォールは？
世界的なブームはあれど、周りの案件の大半は「ウォーターフォール」なのが事実。どっちが良い/悪いとかじゃなく、特徴の違いだと思います。¹³

ウォーターフォール向けだと、MS ProjectをQAの回答では多く見かけた気がします。
自分自身使ったことないので、MS Projectが良いかどうかのアドバイスはできません。すみません。

ただ、Excelよりは絶対に良いぞ。

##結局どういうツールを使えば？
手前が持っている情報¹⁴だけで言うなら、以下な感じです。
ウォーターフォール：

1. MS Project・・・自分が使ってみたい＆ネット上ではよく見かける
2. Redmine・・・ウォーターフォールとは比較的相性が良いと思う。（実際ちゃんと回せたし）
3. Jira・・・アドオンを入れればウォーターフォールでも使える。

アジャイル

1. Jira・・・できれば、Confluence/Bitbucketなども含めてコラボレーションを促進したい。
2. Redmine・・・プラグインあるので、できる！

言わずもがな、Excelは圏外です。
※ただ、ツールはどちらかというと実績を取得するのが得意なので、予定を描いたりとかは、別のツール使ったほうが良いかもです。（MS Projectは知らないので、ベースラインとしての予定も管理できるかも・・・？）

#最後に
こういったツール系の話って、ゴールのない話なので、「絶対これにすべきだ！」って言い難いところはあります。一方で、「これは間違ってる！」ってのは結構言われるので、余計悩むのですが。。。

本記事が、「脱Excelしたいのに・・・」って思っている人のきっかけになったら良いなと思います。まぁたぶん、どのツール使っても、Excelよりは全然良いです。
ツールは使わなきゃ慣れないので、思い切って飛び込んでみましょう。

以上です。

---

1. カテゴリ/対象バージョン/予定工数/各予定日と実績日（担当着手/担当完了/レビュー着手/レビュー完了/顧客承認着手/顧客承認完了） ↩

2. カテゴリ/対象バージョン/予定工数/各予定日と実績日（着手/完了）/実施工程/タスク分類 ↩

3. カテゴリ/対象バージョン/予定工数/各予定日と実績日（担当着手/担当完了/レビュー着手/レビュー完了/顧客承認着手/顧客承認完了）/実施工程 ↩

4. 検出工程/原因工程/対処工程/対応が間に合わない場合の影響/対応状況/各予定日と実績日（着手/完了）/顧客共有要否 ↩

5. カテゴリ/対象バージョン/予定工数/検出工程/原因工程/本来検出されるべき工程/混入した工程/検知ケース番号/検知事象分類/影響範囲分類/影響内容/同件不具合番号/横展開要否/横展開内容と結果/直接原因/根本原因/原因分類/責任分類/対処分類/再テスト(UT)完了日/設計書修正完了日 ↩

6. カテゴリ/対象バージョン/予定工数/検出工程/原因工程/本来検出されるべき工程/混入した工程/検知ケース番号/検知事象分類/影響範囲分類/影響内容/同件不具合番号/横展開要否/横展開内容と結果/直接原因/根本原因/原因分類/責任分類/対処分類/再テスト(UT)完了日/IT環境リリース予定日/IT環境リリース実績日/再テスト(IT)完了予定日/再テスト(IT)完了実績日/設計書修正完了日 ↩

7. このPJではUT完了時点を起点として仕変受付開始しました ↩

8. 要件/対応内容/影響範囲/概算見積/PG・UT完了予定日/PG・UT完了実績日/IT環境リリース予定日/IT環境リリース実績日/設計書顧客承認完了実績日 ↩

9. 運用ルールのみで定義しており、ロールでの操作可否制御などのシステム制御はしてない。やろうと思えば誰でもいじれてしまう状態だが、みんな守ってくれた。 ↩

10. 納品対象は契約時に確定しているので、最初の頃に一気にインポート。中間成果物とかレビューしないものは、「タスク（一般）」。 ↩

11. ウチのプロジェクトじゃないですが、「プラグイン導入をミスって、全部データ消えた・・・」ってのは聞きました。無事復旧できたそうですが、壊れる可能性はゼロではないですね。。。Excelと比べたら格段に低い確率でしょうが。 ↩

12. アジャイル/リーン側から見た時、「ウォーターフォールだからできてしまう」が近いニュアンスかもしれません。細かくしよう/管理しようと思うと、どこまでもできてしまうのが、ウォーターフォールだと個人的に思います。そんなことより、さっさと動くもん作ろうぜ！がアジャイル/リーンなイメージ。細かいこと考えるくらいなら、作りながらイテレーション回して、開発チームを洗練させていこうってスタンス。 ↩

13. ただ、自分が開発者なら「アジャイル」が嬉しい。お客さんも納得して仕事できるのが一番嬉しい。それに、業務量自体をお客さんと調整できるし。 ↩

14. Jira/Redmine/Excel/Trelloを使ったことがあります。Trelloは個人のタスク管理には便利だなと感じてますが、チームで使うイメージが湧かない・・・。あ、カンバン的な感じなら使えるか。 ↩