チケット駆動開発でのチケット粒度と種類

仕事で、毎日 redmine を使っています。自分の立ち位置は、各 PJ の PM を束ねるような仕事なので、各 PJ が redmine を使ってくれると、状況把握がとても簡単になります。
実際には、チケット駆動開発の普及にはムラがあり、何もしなくても自分で工夫して進んでいく PJ もあれば、ちょっとスキを見せると運用が滞る PJ もあるし、導入が進まない PJ もある。
仕事の内容も違うし、制約事項もメンバも PM 自身も違う訳で、あう方法を選べばよいと言うのは簡単だけど、基本は同じだし、チケット駆動開発が向かない仕事ってのは、今のところ見たことがない。
仕事＝タスクを見える化し、誰がいつまでにやるか？を決めてチケット化するだけのことであり、PM としては当然の行動とも言える。もちろん、計画通りには進まないが、まずは「計画を立てる」という基本動作を各自が考えることが重要と思ってます。

しかし、ここで問題になるのはチケットの粒度。PJ で言えば「PJ の完遂」というチケットを切ることも出来るし、「ある日、朝コーヒーを淹れる」というチケットを作ることも可能。長いものは抽象的で、関係者も増えるが、PJ のゴールに対してブレがない表現になる。短いものは具体的で、誰がやるかも明確だが、何のためにやることなのか？が曖昧になる。これをどのような粒度にすればよいか？が悩みドコロである。

１．トップダウン
「PJ 完遂」は、間違いなく１つのタスクだが、抽象的すぎて何をしたら良いか分からない。ソフト開発で言えば、要件決めて、設計して、コーディングして、テストして、リリースするという工程があるので、まずはそれで分解する。更に成果物で細かくしたり、担当者毎に割り振ったりと下げていくと、最終的には各メンバの具体的な作業まで落とすことが出来る（いわゆるPJ計画そのもの）。redmine で言えば、バージョンのようなもの。
具体的には「今日、Aさんはあこのチケットとあのチケットの２つを終わらせてね」と言える所まで行けば、理想的。ただし、この粒度を下げることに時間がかかってしまい、かつ毎日の状況変化に対応できなくなると、管理が破綻します。やはり PM が全てこれを作るよりも、ある程度メンバが自分の大きな粒度のチケットに対して、自発的に計画を立てて行くことが必要となる。

２．ボトムアップ
朝、PCに向かって一日のざっくりした計画立てると思いますが、その粒度をすべてチケットに書く必要はあるでしょうか？多分、数日は可能かもしれませんが、続けることは出来ないでしょう（日記の三日坊主みたいなものですね）。しかし、毎週の報告レベルなら、自分の心の中にはザックリとした予定があり、それをチケットに起こすことはそう難しくないはずです。トップダウンから落ちてきた自分の責務の中をどう分解して、今日何をやろうか？明日までに何を終わらせるか？と言うことを自然に考えているはずなのです。その内容がリーダーや PM から見て妥当なのかどうか？を、週末の報告までチェックしないのは、やはり良くない。自分でチケットを切って、リーダーに見てもらって、話し合う事が重要です。

３．粒度
チケットを切るということは見える化であり、理由はチーム全員がそれを知ることにあります。それには前述したような、粒度の問題があります。粒度が大きければ、各チケットは情報倉庫の様なものとなり、各自の経験や作業／ノウハウを書く wiki に似たものになります。粒度が小さければ、各メンバ毎のタスクの総体となり、全体の見通しや進捗を示すものにはなりません。では、必ずこの粒度が良いというものがあるか？と言われると、どうもそういう物は無い様です。大きなものも、関わっているメンバがきちんと最新情報を書いて、状況を見定め、時にはエスカレーションが出れば、PM として有意義ですし、小さなものを個人のタスク管理で使い、それをリーダーが見ながらアドバイスする、という動きも重要です。
恐らく粒度には答えはなく、全体の目つきと個人のタスクの２つの粒度を一緒に管理するのが良いように思います。大きなチケットは小さな子チケット（あるいは関連チケット）を内在し、それらは個人タスクとして見える化し、全体感を把握できるようなイメージです。
また、粒度は変化することがあり、それを認めないと管理が上手く行かないように思います。

４．種類
大きな PJ の目標、今月ここまでやるという意思表示から、ノウハウの共有、情報の集積、外向けの約束事項や、内部の課題、各自のTODOまで、PJには実に様々な情報があり、ほとんどが PJ 全体で共有スべきものと思います。粒度とは別に、チケットには種類があるはずです。これは整理をかければ PJ 毎に決めていくのは可能と思われます。redmine で言えば「カテゴリ」になりますが、これも厳密に決められるか？というと難しい。種類も変化することがあり、こちらも柔軟に対応すべきと思います。

５．まとめ
結局、粒度と種類のパラメータは意識する必要があるが、固定的な分類や管理が望ましいかどうか？は微妙。固定的な作業の管理なら、工程表でもWBSでも書けば良いですが、昨今のソフト開発はそう簡単ではないと思います。しかしそれで管理を諦めるのも駄目で、柔軟に変化できるツールを選んで行くことが重要かと。
私自身、固まった答えはない課題ですが、今日の所の棚卸しとして書いてみました。