うまいチケット駆動でのプロジェクト管理を見たのは、20年ほど前のアジャイル協議会のTLだったと思う。ライントレーサーのロボットを作るのに、チケット駆動とPSP（パーソナル・ソフトウェア・プロセス）を組み合わせて、Excelで進捗チェックをするひとりプロジェクトだ。
複数名のチケット駆動というと、壁に付箋を貼るか、チケット駆動のツール（Redmineとか、Backlogとか）を使うことが多いのだろうが、何もツールの全ての機能を使わなくてもよい。というか、全ての機能を使おうとすると何かしらうまくいかないことが多い。最大公約数で機能を詰め込んであるのでオーバースペックなのだ。
で、
チケット駆動の最大の難点なのは、最終的にプロジェクトがいつ終わるのか？が見えないことだ。スクラムのバックログ方式も同じだけど、アジャイル方式で開発を行うとどうも終わりが見えなくて困る。当然のことながら終わりが見えないからアジャイル方式を使うのだけど、じゃあ、いつ終わるのか？という概算的な時間見積もり≒納期はどのあたりに定めればよいのだろうか？
プロジェクトが終わった時点から見れば、チケット駆動であれスクラムのバックログであれ、消化したチケット数／タスク数は決定的である。当たり前だ。プロジェクトは完成して終わったのだから、目の前にできたものに費やした時間は「記録さえしてあれば」計算できることになる。
なので、実はチケット駆動でも概算的な規模見積もりは可能であったりする。
ソフトウェア見積り 人月の暗黙知を解き明かす
https://www.amazon.co.jp/dp/B00KR96M6K
FP とかも含めて、いろいろと試してきたけれど、私の場合マコネル氏のこの本に同意する。マコネル氏はこの前後に計量的にタスクの時間見積もりをするツールを売っている（今はなくなっている…はず）けど、細かなタスクあるいはチケットを確率的に求めなくても、もっと概算で十分だろう、ってところに今の私は落ち着いている。年初あたりに確率統計を使って計算する試みをしてみたのだが、正確なシミュレーションをしたとしても途中のタスクの増減の影響が大きいのでプロジェクトを進める間は、その正確さは重要ではなくなってくる。大規模プロジェクトの計画段階（予算と期間を決めるという意味で）は重要になっているのだが、高々数百万のプロジェクト、期間が４か月程度のものに最初の正確さを求めても意味がないことが多い。それよりも、プロジェクトを運営する上での「やりくり＝本当の意味でのマネジメント」を考えたほうが安全にプロジェクトを終わらせることが可能である。
期間を概算する
会社にいた頃は、機能を洗い出して機能ごとに時間単位あるいは日単位で見積もりを出して積み上げていたものだが、今はやっていない。超概算見積もりで人月を計算した後に、Excelで機能に割り振る、あるいはチケットに割り振ってしまう。
正確に言えば、
- 超概算見積もりで、人月で算出する
- 顧客の懐具合で、予算を算出する
- 機能の数で、人月で算出する
と３つの人月を出す。大体において、派遣なり契約社員なり社員なりに支払うお金は「月単位」になることが多いので、週単位で出してもあまり意味はない。細かい単位でずれを修正しても仕方がないし、そもそもスポンサー≒お客の懐具合に予算を合わせないといけない。
ならば、月単位の単価をベースにして、超概算してしまうのがよい。細かいところはプロジェクトを進めながら合わせていく。
チケット数を概算する
期間と人数が決まれば、おのずと動いている時間が決まってくる。当然だが、20日/月、160h/月で考える。22日で計算すると祝日や別な割り込みの分を勘定できないし、そもそも計算が面倒くさい。2日≒10%程度の余裕が最初からあるほうがよい。
1日で消化するチケットする数は3つ程度と決めておく。期間が長ければ1日1チケットでもよい。しかし、1週間1チケットみたいなのは駄目。スクラムのスプリント期間に近くなってしまうし、1つのチケットが1日よりも長くなる場合は、チケットを分割するか、複数のチケットに同じタイトルで割り当てたほうが良い。いつまでも進行中のまま終わらないからだ。
チケットの作業時間の粒をできるだけ揃えておくのがよい。そうするとバーンダウンチャートで先行きが見えやすくなる。
プロジェクトの開発期間と人数が分かれば、全体のチケット数が概算できる。
既知の開発をチケットに割り振る
プロジェクトの開始時点（規模見積もりをしている時点）で、ある程度の既知の開発チケットがあるはずだ。そうじゃないと、どうやって規模/金額見積もりをしたんだ？という話になる。大まかな機能と、おおまかな時間（1日なのか３日なのか）を適当に決めて、チケットに割り当てる。
見積もったチケット数をすべて書き込む必要はない。いや、むしろ書き込んではいけない。プロジェクト開始時のチケット数はあとから増える可能性が大なので、空白のチケットを残しておく。これは保険だ。あるいは、未知なるチケットだ。
あるいは、チケットが全て埋まってしまう状態になったら、それはそもそもが全体のチケット数が足りない → プロジェクト期間が短すぎる、ことを意味している。先の超概算に戻って、再確認する。
残チケットを消化する
プロジェクトが進む中で、さまざまな要望が増えていくる。チケットを消化しつつも、チケットが増えてしまうのがチケット駆動の難点ではあるが、あらかじめ全体のチケット数が分かっていれば≒概算してあれば、プロジェクトが進んだとして大幅にチケット数が増えることはないだろう（それでも予想を超えて増えてしまうのが常なんだけど）。
私の場合、チケットの消化記録は、Excel か Redmine を使っている。先に書いた通り、Redmine を全ての機能を使うと多機能すぎてオーバースペックになる。なので、
- チケットは新規/進行中/終了しか使わない。進捗率は使わない
- 作業時間はいらない
- ガントチャートも使わない
- 優先度も使わない
- チケットはあらかじめ概算時点で大量に置いておく。順々に消化する。
という非常にシンプルな使い方をする。
ひとりプロジェクトだと Excel ベースで十分なのだけど、2名以上だとファイル競合がでるので Redmine を使う。最初に大量のチケットを投入する必要があるので、現在ツールを作って投入中。ClosedXML を使って、Excel へのマージを作っている。これ、Redmine の CSV のインポート機能でいいんじゃないだろうか？と気づいたのだがどうだろう。あとで試してみる。
追記
CSV からインポートすると常に新規になるので、二重にチケットができてしまう。更新版を自作しないと駄目。初期チケットの大量投入は CSV を使うと便利。
