ソフトウェア開発のタスクはどのように管理するのが効率的なのか。ソフトウェアという目に見えないものを作るためにはタスクの見える化は進捗状況を図る重要な指標になります。ソフトウェア開発で発生するタスクを、バグ管理システム（BTS）や課題管理システム（ITS）を活用することで、タスクの状態とワークフローを管理しようというのがチケット駆動開発です。
ANDREW BIRD TICKETS / ginnerobotチケット駆動開発については、以前に記事を書いたので、そちらを参考にしてください。
チケット駆動開発のススメ〜No ticket! No commit
チケット駆動開発をうまく実践するためにはツールが不可欠です。不具合管理や障害管理で使うツールを応用して活用することも出来ますが、最近は専用のツールも出て来ています。ソニックガーデンでは、Pivotal Trackerというツールを使っています。Pivotal Trackerでは「ストーリー」と表記していますが、私たちは「チケット」と呼んでいます。
Pivotal Trackerの基本的な操作については、ソニックガーデンの西見がThinkITでの連載記事の中で紹介していますので、ぜひそちらもご参照ください。
youRoomとPivotalTrackerではじめる無駄のないコミュニケーション
この記事では、ソニックガーデンで2年ほどの間、Pivotal Trackerを使って来た経験から、上手にチケット駆動開発をするためのポイントを紹介します。Pivotal Tracker以外のツールも紹介した記事はこちらです。
目次
役割分担
Pivotal Trackerを使う役割はざっくり分けると２つです。一つは、開発のためのチケットを登録して、開発されたチケットを「Accept」して終わらせる役割と、もう一つは登録されたチケットを開発していく役割です。前者をプロダクトオーナー、後者をプログラマと呼んでいます。
とはいえ「チケットの登録」に関しては、それほど厳密ではなく、必ずプロダクトオーナーがしなければいけないと決めてはいなくて、プログラマが登録することもあります。
むしろ、プロダクトオーナーだけの特権として勝手にチケットを登録するというのはしない方が良いです。プログラマとの話し合いの結果としての約束事をチケットにする、という形の方が健全です。
ソニックガーデンの場合だと、youRoomを使って常時コミュニケーションをとれるようにしていて、youRoom上でのディスカッションの結果、チケット化することが多いです。私たちはチケット化することを「Pivo化」と呼んでいます。
ディスカッションの結果、プログラマが代理でPivo化することもありますし、自主的にチケットを登録しておくこともあります。
ポイントとしては、Pivotal Trackerを使う際に、Pivotal Trackerだけで仕事を完結させない、ということでしょう。お互いのコミュニケーションがとれていることが大前提にあって、その上で、やるべきことを忘れないようにするためにチケットがある、という感じです。
チケットの粒度
チケットの粒度をどうするかは、Pivotal Trackerを使いはじめておそらく多くの人が感じる疑問でしょう。
ソニックガーデンでの基本的なルールは、プロダクトオーナーにとって意味のある粒度にする、ということです。どんなチケットもプロダクトオーナーが最終的には「Accept」か「Reject」する訳なので、そこが判断できることがチケットの絶対条件になります。
なのでチケットを切る際のポイントは「Accept」の条件が何かを、プログラマと合意しておくということです。その上で、なるべくチケットの単位を小さくするようにします。
「Accept」する条件を細かく列挙して沢山にしてしまうと作るプログラマも難しいですし、確認するのも大変になります。小さくするといっても作業で切ってはいけません。確認のできる意味のある単位にすべきです。
そして一つのチケットの大きさは、最大でもプログラマが１日で出来る量を超えないようにしています。チケットを日をまたいで作業すると思い出すだけでも時間がかかり生産性を落とします。ソニックガーデンでは、どれだけ小さな意味の単位にしても一日に収まらない生産性のプログラマだとしたら、それはまだ一人前とみなされません。
この粒度でチケットを切って、確認していくとしたら、プロダクトオーナーは結構大変です。もっとざっくりと渡せば楽でしょうが、それではプログラマが迷う時間が増えて生産性が出ないのです。本当に速く開発したいと思うならば、それだけのコストをプロダクトオーナーが払うべきです。
このようにチケットの切り方は、プログラマの視点ではなくユーザの視点になります。どのクラスを書くとか、スキーマを用意する、といった作業のTODOはチケットになりません。それらの作業レベルのTODOは、手元のメモに書くか、Pivotal Trackerならば、ストーリーの中に「TASKS」という形で書いていくことができます。こちらを使えば消し込みができて便利です。
通常のチケットはプロダクトオーナーによるユーザ視点のものになりますが、ユーザに影響しないけれど、どうしても全体のアーキテクチャにかかわるようなチケットを切りたくなることがあります。例えば、フレームワークのバージョンアップなどです。
そういった場合は、Pivotal Trackerではストーリーのカテゴリーに「Chore」と呼ばれるものがあり、それを設定します。歯車のアイコンで記されたChoreのチケットは、アクセプトが不要のワークフローが設定されています。つまり、プロダクトオーナーには関係なく、プログラマの作業が終わったら、それで終了になります。
チケットを仕様にしない
ソニックガーデンでは仕様はソースコードだとしています。チケットを仕様にしていません。チケットはあくまでこれから作ろうとする作業について書かれているだけです。その瞬間は仕様かもしれませんが、ソースコードに落とし込んで、アクセプトされた瞬間に正しい仕様はソースコードになるというイメージです。
もし、仕様をソースコードとは別で管理したいというのであれば、それはチケットとは別の仕様書という形で別のドキュメントを用意すると良いでしょう。あくまでチケットは前に進めるためのもので、正しさや厳密さを求めるものではない、というスタンスでいます。
チケットをWBS（Work Breakdown Structure）のように扱いだすと、厳密さばかりが目についてしまい、開発のリズムは産まれなくなってしまいます。小さなチケットを少しずつこなして積み上げていくことでソフトウェアを作っていくというスタイルを目指します。
チケットを切る前にyouRoomでディスカッションするということを書きましたが、なぜそのチケットをするのか、というWhyの情報は、チケットになる前に決まることなので、ソニックガーデンの場合は、youRoomに書かれています。
そこで、Pivotal TrackerにPivo化する際に、ストーリーの「Description」の項目にはそのチケットが産まれたときのディスカッションをしていたyouRoom上のスレッドのURLを書き込むようにしています。そうすることで、実際に開発する直前に、なぜこれが必要だったか、を確認することが出来ます。
プログラマにとっては、書かれた通りに作ることよりも、なぜ必要なのかを知った上で実現方法を考えながら作る方がクリエイティブですし、実際に作られるものも、本質的に価値のあるものができあがります。チケットになる前のWhyが重要です。
厳密性とは少し異なりますが、どれだけのチケットをすることで全体像のうち、どこまでが進んでいるのかを知るための機能として、Pivotal Trackerには「EPICS」というものがあります。これは、最近追加された機能で、これまではラベルで表現していたものを一覧で見えるようにしたものです。
EPICSには大きめの機能群として登録しておき、そこにチケットを紐づけていくことで、それぞれの機能群がどれだけ進んでいるか、消化されたチケットと消化されていないチケットでわかるようになっています。
とにかく前に進める
チケット駆動開発の最大のポイントは開発のリズムだと思っています。テンポ良く次々と開発を進めていき、プログラマとプロダクトオーナーのキャッチボールをいかに速いスピードで行っていくか、ということに尽きると思っているのです。そうして切磋琢磨していくことで、開発速度はどんどんと上がっていきます。
ここでもチケットを厳密に管理しないことがポイントになります。プログラマが開発作業を終えて、動作確認出来る状態にすると、プロダクトオーナーのAccept待ちになります。このとき、プロダクトオーナーはバグを見つけるかもしれません。ちょっとしたことならRejectしてやり直しも良いですが、ソニックガーデンでは、なるべくRejectしないという方針にしています。
ひとつひとつのチケットで完全を目指しても良いのですが、それだとリズムが崩れるし、開発したプログラマもちょっとめげます。なので、何か直すところを見つけたら、改めて別のチケットとして登録するようにしています。結局、同じことなのですが、精神的に進めた方がお互いに気持ちが良いのです。気持ちの良さは生産性に影響します。
また、プログラマ側も完璧を目指すよりも前に進むことを重視します。チケットのWhyを理解して、その目的がほぼ達成できるのであれば、そのチケットの詳細にこだわって100%にするために時間をかけすぎなくて良いと判断します。80%くらいが着地点でしょう。
では残りの20%はどうするのか。これもまた別のチケットとして登録します。プログラマが自主的に分割して別のチケットにする訳です。分割したことをプロダクトオーナーと確認して、納得のいくレベルを目指して着地させる訳です。残りの20%のチケットはアイスボックスに入れておけばよくて、おそらく実装することはないでしょう。
Pivotal Trackerの特徴の一つは「アイスボックス」と呼ばれる一覧があることです。アイスボックスに何をいれるかというと、仕様が固まっていないものや、これから先やりたいと思っていることなど、つまり何でも入れていい訳です。逆に仕様が固まってもいないのにバックログに入れるのは良くないですね。プログラマが作業できないからです。
ソフトウェアを作っていれば、いくらでも新しいアイデアも要望も出てきます。それらを全て実現しようとするといくら時間があっても足りません。そして思いつきで作る機能は大抵の場合、あとから後悔することになります。あんな機能いらなかったな、と。機能やコードは負債です。なるべく作らないことが一番なのです。
とはいえ、新しいアイデアを何もしないでモヤモヤすることもプロダクトオーナーにとって精神的に負担ですし、それはプロダクトオーナーの生産性を下げることになってしまいます。そこで、アイスボックスに入れるのです。アイスボックスに入れておけば、プロダクトオーナーもプログラマも安心できます。プロダクトオーナーは定期的にアイスボックスを見直すと良いでしょう。なぜあの時はあんなに強く欲しがったんだろう、というチケットが見つかるはずです。そうしたら消してしまいましょう。
Pivotal Tracker をうまく使えば、自然とチケット駆動開発が出来るようになってくるはずです。そして、上記のようなノウハウを駆使することでよりスピードアップした開発を実現できると思います。
「チケット駆動開発」は、特定のツールに依存した方法ではありませんが、この記事ではPivotal Trackerに特化した内容で紹介しました。特定のツールに依存しない「チケット駆動開発」については、前述で紹介したRedmine本に続く２冊目のチケット駆動本が、近いうちに出版されるらしいので、それを待って読むと良いかもしれません。
