Redmineを使ってチケット駆動開発で作業管理をする方法

前提

前提条件

  • いわゆるウォーターフォール的な案件
    • ただし、期間全体で要件定義、設計、実装、テストをするのではなく、要件定義に1ヶ月、設計に1ヶ月、実装に1ヶ月、テストに1ヶ月といったサブシステムが幾つかまとまって一つの大きな案件になっている
  • ルールを厳密に適用しようとはしていない
    • 以下のスライドを見てもらえば私の基本スタンスが分かる通り、基本的にルールをチームに伝えるが、目的がルールを守ることにならないようにしている。例えば、チケット駆動開発のルールに違反をしたからといってそれについて追求したり、注意したりしない

TFSをきっかけに始まった自己組織化

使用システム

  • Redmine

今回Redmineを使用したのは元々Redmineを使用している環境だったからであり、他のシステムだとできないということではありません。特に今回の方法ではRedmineのpluginを入れておらず、使用したモジュールもガントチャートくらいです。

チケット駆動開発で作業管理をする方法

作業計画にチケットを使う

まず1つ目は“作業計画にチケットを使う”です。よくBTS/ITS以外にWBSなどを元にしたガントチャートによる管理をすると良いという話を聞きますが、BTS/ITS、少なくともRedmineはチケットを元にガントチャートを表示する機能を持っています。わざわざビジネス価値を生み出さないものを増やす必要はありません。

trac ガントチャート – Google 検索

上記のように検索するとヒットするので、Redmine以外でも大丈夫でしょう。

チケット同士を関連付けする機能を使えば、チケット同士の前後関係や依存関係を容易に視覚化できますし、タスクを組み替える場合にどういった影響があるのか一目で把握できます。そうすることで、1つのチケットの進捗がずれても、「このチケットに先行/後続」の関連付けをしておけば自動的に関連付けているチケットの期日がずれるので簡単に把握できます。

進捗はUndone(未完了、0%)かDone(完了、100%)のみ

2つ目は“進捗はUndone(0%)かDone(100%)のみ”です。Redmineの親チケットと子チケットで作業計画/チケット駆動開発をしていると、親チケットの進捗率が子チケットの数に依存してしまいます。以下のスライドを見てもらえば分かる通り、進捗率はあまり意味がありません。個々のチケット(タスク)の進捗は未完了(Undone)なのか、完了(Done)なのかだけで判断し、進捗率の数字はムシします。

今日から始めるTOC-CCPM

もし、期日までにチケットが終わらなければ後何日必要か確認して、期日をそれだけ後ろに伸ばします。

また、チケットすべてに開始日と期日を入れると大変です。いわゆる大項目となる親チケットのみ入れるようにします。

実践しての所感

多くの人が何かについて先回りして心配して、原則許可ではなく、原則禁止にしますよね。「作業計画にチケットを使うな」とか「個人のタスクはBTSにいれるな」というのはその典型例だと思います。

以下のスライドでも分かる通り、私は先回りして心配して、原則禁止するようなことはしません。

TFSをきっかけに始まった自己組織化

とりあえず、これはうまくいきそうだなと思ったら、実際に自分でそれを“実践”してみて、実践していく中でこういうことするとうまくいかないという事象を明確にしていきます。評論家気質にオプトインの考え方で他人を縛ったり、やりもせずにできない言い訳を並び立てるより、“どうすればできるだろう?”と考えて“実践”した方が良いと思います。マニュアルやルールで縛ってしまってはその人が持つ実力を完全に発揮できる環境ではなくなります。

著名な方が何か言った際に、多くの人が真偽を自分で確かめず、盲目的にそれに従います。それはとても簡単で、一見効率良いように思えるものです。特に「○○するな」というオプトインの考え方だと今までやり慣れた従来の方法から脱却しなくてすみます。今までやり慣れた従来の方法の方が簡単だし、手慣れているのは分かりますが、そこに安住していて、良いんでしょうか?皆さん、本当にそれで良いのか今一度考えてみた方が良いんじゃないでしょうか。

参考資料