プログラマの思索

RedmineJapanの懇親会で友人たちと議論しているとき、「タスク分割は親子チケットにすべきか、それともチェックリストにすべきか」というテーマで盛り上がった。
考えたことをメモ。
結論のないラフなメモ。

【参考】
ActivityとTaskはどう違うか ? ガントチャートと課題管理表から考える : タイム・コンサルタントの日誌から

akipiiさんはTwitterを使っています 「懇親会は人数が少ないのに、Redmineの濃い話で盛り上がる。Redmineでは、親子チケットを切る基準と1チケット内でチェックリストを作る基準の違いは何か？進捗率はどう決めるべきか？面白すぎw #RedmineJapan」 / Twitter

【1】Redmineでチケット駆動開発を実践すると、チケットの粒度に悩む。

タスクの粒度が大きすぎるチケットは、完了までの期間が長くなるので、進捗を管理しにくい。
肥満児チケットも言う。
こういう肥満児チケットは、完了条件が曖昧なので、作業していくと次から次へと問題が噴出して、進捗率が90％のまま停滞しがち。
たとえば、1本のプログラム開発のチケットでも、エラー処理のメッセージが決まっていなかったと後で判明して保留になったり、実際に作り込んでみるとSQLチューニングしないと使えない代物だった、とか。

一方、タスクの粒度が小さすぎるチケットは、作業しやすいが、大量のチケット保守に苦労する。
経験的には、1チームで管理できるチケット枚数には上限があると思う。
それ以上のチケット枚数になると、チケットが放置されて、今日は何をやればいいのか、今後どの順番でチケットをやっていけばいいのか、混乱しがちになる。

管理者も担当者も、細かくチケットを切って、チケットを1個ずつこなしていくようにしたい。
では、どのように細かいタスクをチケット管理すべきなのか？

【2】タスクの粒度の解決方法としては、親子チケットにすべきか、それともチェックリストにすべきか、という問題に落ち着くのではないか。

1個のタスクを親子チケットで階層化し、細かく切った子チケットを親チケットでグルーピングして、親チケットでステータスや進捗率を把握する。
一方、1枚のチケットの中にチェックリストを設けて、チェックリストの1項目ずつ消し込んでいくことで、どこまでやり切ったのか、後は何が残っているのか、を把握する。

どちらが良いのだろうか？

【3】チェックリストを使いたい場面は、担当者が1人で決まっていて、自分のタスクを作業の順序や作業の詳細ごとにチェックリストに落とし込んで、作業をこなしてはチェックリストを消し込んでいきたい時だろう。
つまり、自分だけのToDo管理に近い作業になる。

たとえば、こういうToDo管理は、研究者が道の問題解決の時に使う手法でもあるし、すでに手順化された作業をチェックリストにして使う時もあるだろう。
たぶん、担当者1人だけの作業に閉じている時、1枚のチケットにチェックリストを書く方がいい。
お手軽だし、チェックリストを考えること自体が、作業分割に繋がり、作業のクリティカルパスを考えることにも役立つ。

しかし、チェックリストのデメリットもある。
チェックリストの進捗を把握するには、1枚のチケットを開きっぱなしにしておく必要がある。
タスクボードやチケット一覧では、チェックリストの中身は見えないし、残項目数がどれだけあるか分からない。
つまり、チェックリストはチケット集計機能に向かない。

【4】親子チケットを使いたい場面は、1つの作業を複数人で分担して並行作業したり、課題の解決方針から複数のアクションタスクが派生してそれらを管理したい時に使いたいだろう。

一般に、WF型開発であれば、1つの工程の中で複数人が作業分担して、作業を逐次実行したり、並行作業で行う。
たとえば、コーディングして、コードレビューを受けて、ビルドを通すという一連の作業では、プログラマとレビューア、ビルド職人で担当者が切り替わる。
あるいは、1つの機能を複数人が分担してプログラム開発を並行作業し、最後に統合してビルドする時もあろうだろう。

そんな時は、各人のタスクを子チケットにして、親チケットでグルーピングして、親チケットでロールアップする方が進捗管理しやすい。
親チケットで進捗やステータスが分かるからだ。
また、チケット一覧やタスクボードで、子チケットを集計すれば、ガントチャートやEVMなど色んな集計機能でPJ全体の情報を把握できる。

しかし、親子チケットのデメリットはある。
何でもかんでも親子チケットにすると、チケット枚数が増えて、一瞥して管理しにくい。
大量のチケットであふれると、チケットは乱発され放置されて、誰も保守しなくなる。
だから、普通は毎日棚卸しタイムを設けるなどしなければ、PJの現状がチケットに反映されないだろう。
それだけの手間を惜しまない気力が必要と思う。

【5】親子チケットが特に重要と思う場面は、課題管理だろうと思う。

プロジェクト運営では、ゴールに向けた作業が全て洗い出されて、タスクがチケットに落とし込まれれば、その時点でほぼコントロールできる可能性が高まる。
作業に落とし込めるということは、ある程度標準化された作業、想定される作業に落とし込めることなので、ほとんど未知のリスクはない。
定常作業がそういう部類だろう。

しかし、一般には初めてのプロジェクトでは、どんな作業があるか分からない時もある。
むしろ、作業を進めていくうちに、今まで経験しなかった課題が噴出して、それらをもぐら叩きのように丁寧に潰し込んでいかざるを得ない。

すると、それら課題を発生の都度チケットにして、課題チケットを一つずつステータス管理していく必要がある。
僕は、プロジェクトマネジメントのほとんどは課題管理、もっと言えば、リスク管理に尽きると思っている。
なぜならば、未知のリスクに遭遇した時、それらの問題を課題に置き換えて、それら課題を潰し込んでいきながらゴールへ近づいていくというイメージが強いからだ。

【6】では、課題管理では何が重要なのか？
一つは、課題のステータス管理。
もう一つは、課題の解決方針から導出されるタスク群のステータス管理だ。
つまり、課題は親チケットにして、それに子チケットのタスクがぶら下がるイメージだ。

課題を調査して、試行錯誤して解決方針を決定し、タスクに落とし込んで、それらタスクが完遂されて初めて、課題は完了する。
すると、課題は今はどのステータスで滞留しているのか、を知りたくなってくる。
大抵の場合、課題の解決方針を決定するまで持ち込むのが割と大変ではないか。

そもそも、課題の解決方針がすぐに分かるようならば、それは課題ではなく、タスクであるべきだ。
なぜならば、タスクとはやるべき作業の具体的内容と完了条件が分かっているものであるが、課題はその解決方針すらも分かっていないのでどんな作業内容すらも分からないからだ。

課題を解決するには、技術情報を調査したり、集めた情報を分析したり、経験者からアドバイスをもらう、などいろんな手段があるだろう。

課題を解決する時に重要なのは、何を持って課題を解決できたとするのか、課題の完了条件を決めることだろう。
課題の方針が決まれば完了とするなら、課題チケットだけで、子チケットにタスクチケットは必要ではない。

一方、課題の方針を決めてそれらをタスクに落とし込んで、それらタスクを実践して結果をさらに分析してみて評価する、という方法もあるだろう。
つまり、課題は親チケットにして、解決方針の内容を子チケットのタスクで詳細化していくイメージだ。

能力のあるプロジェクトマネージャは、課題管理やリスク管理に敏感で、落とし穴にはまらないように未然防止策を立てていたり、落とし穴にはまり込んだ時のコストやスケジュールをバッファとして保持するなど、リスク対策をよく考えている人が多い。

【7】「親子チケットにすべきか、それともチェックリストにすべきか」という問いは、タスク管理よりも課題管理のほうが重要ではないか、と思う。
最初は、いきなり課題チケットからタスクチケットに分割できる訳ではない。
試行錯誤しながら課題を解決する必要があるから、チェックリストでまずはラフでもいいので書き込んで、それらを一つずつ潰していきながら、解決方針を探り当てる。

チケット管理の面白さは、こういうプロジェクト管理の技法を実際にチケットの中で色々試せることだ。
どういう場面でチケット管理のどの技法を使うと有効なのか？

それを手順に落とし込むことができたら、チケット管理という意思決定は、単純な条件分岐だけの意思決定まで落とせるるはずだ。
なぜならば、場面ごとのIF文ごとにチケット管理の技法を実行する、というSwitch文に置き換えられるからだ。

プロジェクトマネジメントとは、最終的には、単純な条件分岐だけの意思決定まで落とし込んで、プロジェクト運営の問題を具体化して分割することに過ぎないのではないか、と思っている。