チケットドリブン開発でバグ削減！

チケットが中心の開発手法

「第2回：なぜTracの導入に失敗するのか？」では、Tracの中心機能となるチケットについて説明し、導入のポイントをまとめた。今回はチケットを開発の中心位置に持ってくる「チケットドリブン開発」について解説していこう。

チケットドリブン開発とは

チケットドリブン開発（チケット駆動開発：Ticket Driven Development）とは、チケットを書いてから開発を行うという手法だ。読者の皆さんもご存じのようにテストドリブン開発（Test Driven Development）をもじったものである。このチケットドリブン開発は「まちゅダイアリー（http://www.machu.jp/diary/）」のまちゅ氏がITpro Challenge!のライントニング・トークスで提唱したものだ。

チケットの中心の作業がバグを低減する！

開発におけるコミュニケーションは、口頭や会議、メール、チャットなど、さまざまな媒体を使って行われている。そのため情報が分散し、指示ミス や言った言わないなどの情報伝達ミスからバグを引き起こすことが多々ある。会議など大勢の場で決まったことでも、それを受け取った個々人で解釈が違うた め、結果としてバラバラな行動をとってしまうこともある。皆さんもこのような経験があるのではないだろうか。

通常このような状態を避けるために、指示を出す側がフォーマットに則った指示書を作り、それを基に作業を行うという形式をとる。しかし、迅速な開発が求められる昨今では「指示書が無いと動かない」では仕事が成り立たないことも多いのが実情だ。

さらに、「成果物であるソースコードとコミュニケーションの内容を同定しにくい」という問題もあげられる。

例えば、ユーザ登録のバグを直すために「User.rb」というソースを変更したとする。後日、他の開発者が見たときに変更されていることに気がついたが、なぜ変更されたのかについてソースを見ただけでは、理解することができないという状況だ。

確かに、変更内容をコメントに残すという方法もある。しかし、ソースに対してのコメントが膨大になってしまうと可読性が大きく下がるという欠点がある。また、別途エクセルなどで並行で管理する手法もあるが、管理するファイルが増えると管理が煩雑になりがちである。

これを解決するために、「作業に対する指示書のようなものとして、チケットを使おう」というのがチケットドリブン開発だ。

このチケットドリブン開発では、

作業はチケットを受け取ってから

チケットドリブン開発の名前の由来はココからきている。コードを書くなど、なんらかしら作業をするときには、まずTracのチケットを作り、それに基づいて行う。
 

チケット無しのコミット禁止

 

レビューコメントはチケットの履歴で行う

Subversionにソースをコミットするときには、必ずチケットの番号を書く。こうすることで、ソースの変更が、どのような目的で行われたかが明白だ。そのチケットに関するコミュニケーションは、「チケットの履歴」というコメント欄で行う。

の3つの約束事をあげている。これに従って、作業に関するすべての情報をチケットで管理するのである。チケットで管理することによって、コミュニケーションの齟齬をなくすことができ、結果としてバグの低減につながっていくのである。

この中で一番大切なのは「チケット無しのコミット禁止」だ。Subversionなどのリビジョン管理システムではソースコードの管理が可能だが、作業内容を管理することは難しい。それをチケットで補強するのが、このチケットドリブン開発なのである。

では実際のチケットドリブン開発の流れをみていこう。