チケット駆動開発 Ticket Driven Development

SQiPシンポジウム2009
チケット駆動開発
- BTS で Extreme Programming を改善する-
Ticket Driven Development
- An Improvement Method for Extreme Programming using BTS (株)NRI ネットワークコミュニケーションズ
NRI Network Communications, LTD.
○小川明彦 1)
○Akihiko Ogawa1)
(株)SRA
Software Research Associates, Inc.
阪井誠 2)
Makoto Sakai2)
Abstract
In this paper we report the result of a project in which we improved problems of extreme programming (XP)
using ticket driven development(TiDD).
In the project, we used tickets of BTS ( Bug Tracking System ) as task cards. The result of interviews showed
the followings: (1) using TiDD, we could manage a lot of work much more easily and could manage works of
each member separately, (2) by defining and enforcing work flows, we could precisely control configurations of
source code which are managed doubly, (3) using the BTS and the configuration management tool in
combinations we could trace changes of specifications easily. We report in this paper the result of a project in
which we improved problems of extreme programming (XP) using ticket driven development (TiDD).
1.
はじめに
本報告では多機能化が進む障害管理ツール(Bug Tracking System，以下 BTS と呼ぶ)を用いた
XP(Extreme Programming)[1]のプロセス改善について述べる．
BTS は障害報告書を電子化したもので，近年は多機能化が進んでいることからテスト工程や保
守工程での利用範囲が広がっている．比較的多機能なオープンソース BTS である Redmine[7]には，
(1)障害(問題)管理，(2)障害情報の共有(RSS / email)，(3)入力項目のカスタマイズ，(4)データ
参照(可視化)のような基本機能がある．
更により進んだ機能として，(5)ワークフロー管理，(6)構成管理ツールとの連携，があり更に，
(7)プロジェクト情報の共有機能などが付加されている．ワークフロー管理は，認証機能によって
チケットと呼ばれる障害票の状態の変更を担当によってアクセス制御することで実現されている．
一方，XP をはじめとするアジャイルソフトウェア開発(以下，アジャイル開発と呼ぶ)は繰り返
し開発を行うので，変化する顧客の要望を取り入れることが可能である．「データ白書 2008」で
日本の大手ベンダーから集められたデータに占める繰り返し型開発は 2.9%に過ぎないが[6]，XP
などで採用されている軽快なプロセスが注目され，ユーザ中心により正しいものが作れることか
ら[2]，徐々に普及しつつある．
アジャイル開発のプラクティスには，さまざまな効果がある[3]，しかしその反面，(1)タスク
管理が困難，(2)本番運用と開発のソースの２重管理が必要，(3)継続的に機能が追加されるので
仕様変更と連携した構成管理が必要，という難しさがある．
1)株式会社 NRI ネットワークコミュニケーションズ
NRI Network Communications, LTD.
〒530-0004 大阪市北区堂島浜 1-4-16 Tel: 06-4797-2810
1-4-16, Dojimahama, Kita-ku, Osaka Japan
Tel: 06-4797-2810
2) 株式会社 SRA 関西事業部
Software Research Associates, Inc.
〒550-0011 大阪府大阪市西区阿波座 2-1-1 大阪本町西第一ビルディング 5F Tel: 06-6536-2331
Osaka Honmachi-nishi Daiichi Bldg. 5F, 2-1-1 Awaza Nishi-ku, Osaka 550-0011 Japan Tel: 06-6536-2331
SQiPシンポジウム2009
本論文では，XP におけるタスクカードを BTS のチケットに置き換えることで，これらの問題の
解決を試みたプロジェクトの結果について述べる．
2.
XP(Extreme Programming)運用時の問題点
アジャイル開発の一つである XP は，短期間での繰り返し開発が行われ，複数回のリリースが行
われる．
XP では「Embrace Change (変化を抱擁せよ)」[1]と言われ，イテレーションと呼ばれる短期間
で繰り返して開発し，開発中に明確になっていく顧客の要望を順次取り入れる．各イテレーショ
ンでは，実装する機能が書かれたストーリーカードを更に作業に分解してタスクカードを作成す
る．XP では，作業を管理する目的で，タスクカードをタスクボードという掲示板に貼って進捗を
可視化する．
タスクカードとタスクボードには物理的な制約による管理の困難さがある．タスクボードの大
きさに制約があり，そこに貼ることが可能なタスクカードの枚数に上限がある．また，タスクカ
ードを個人ごとに集計することが困難なので，日々の個人タスクの状況を簡単に把握できないと
いう問題がある．
また，XP のようなアジャイル開発では，イテレーションが繰り返される間に，ユーザに対して
複数回のリリースが行われることが多い．これは，段階的な正式リリースとして行う場合がある
ほか，ユーザによる評価が目的の場合もある．
ユーザにリリースした後も継続してソフトウェア開発が行われるので，リリース済みの本番運
用のソースコードと，開発中のソースコードを同時に管理しなければならない．もし，何らかの
障害が発生すると，その対策を同時に複数のソースコードに対して実施しなければいけないので，
その管理が困難である．このため，すべてのソースコードの修正を抜けが生じないように，手順
を確立しなければならない．また，継続的に機能が追加されるので，仕様変更と連携した構成管
理が必要である．
このように XP には以下のような難しさがある．
(1)タスク管理が困難
(2)本番運用と開発のソースの２重管理
(3)変更管理と構成管理の連携
3.
チケット駆動開発(TiDD : Ticket Driven Development)
TiDD は Redmine や Trac のような BTS の障害管理機能を，開発時の作業管理に用いる開発法で
ある．
BTS をリリース後の障害管理に用いる場合，発生した障害を管理することはもちろんである．
しかし，それだけではなくユーザからの問い合わせについては，要望も障害も全て記録しておき，
その後の開発に生かすということが行われてきた．このような BTS の利用方法は，一般に Issue
tracking と呼ばれている[Nikkei]．
近年では，BTS にワークフロー管理機能
が追加されるようになっており(図 1)，チ
ケットのステータスを変更できる担当者
を制限したり，各ステータスの遷移ごとに
行う確認作業を定義できる(図 1)．更に，
BTS のチケットで本来の機能である障害
修正だけでなく，機能追加やブランチ間の
マージ作業など，ソースに関する全ての作
業をチケットで管理することで，変更管理
と構成管理の連携を図ることができる[4]．
TiDD は，このようなチケットによる作業
図 1 Redmine のワークフロー設定
管理をソフトウェア開発全般の作業に拡
SQiPシンポジウム2009
張するものである．
TiDD では，チケットがなけなければソースの更新を認めないというルールを定めて設計・実装・
試験をチケットで管理する．障害管理ツール上にはチケット集計機能があるので，それを用いて
進捗の管理をするのである[5]．このように TiDD では機能拡張が進む BTS を用いて方法論が作ら
れてきた．このため，導入に特別なツールは不要である．
本論文では，XP の問題の解決を目指して，TiDD をアジャイル開発に適用したプロジェクトにつ
いて報告する．TiDD によって，多数のタスクの管理，複雑な構成管理，変更管理と構成管理の連
携，の改善を目指したのである．
4.
TiDD の適用とその評価
下記に示す商用開発プロジェクトで TiDD を適用した．
(1)開発対象：Web ベースの業務システム
(2)開発期間：1 年
(3)開発者：2 人
(4)BTS：Redmine [7]
(5)チケット総数：622 枚
(6)バージョン管理：Subversion [8]
(7)テスト管理：TestLink [9]
(8)ビルド管理：Hudson [10]
本プロジェクトでは Redmine を用いて TiDD を実施した．Redmine のロードマップ機能でリリー
ス予定のバージョンを指定することで，イテレーションの計画と管理が行われた．また，イテレ
ーション作業をタスクに分割してチケットに対応付けることで，作業のワークフローの自動化と
進捗管理を行った．なお，ストーリーカードは使用せず，機能仕様書をその代用とした．
プロジェクト期間中に行われたふりかえりの記録とインタビューから，TiDD に関する以下のコ
メントを得た(PL はプロジェクトリーダ，PG はプログラマを示す)．
(1)多くの作業が容易に管理できた
・プロジェクト全体の見通しがつきやすくなった(PL)
・ロードマップ画面からタスクを見ることが多く，全体の進捗を容易に意識できた(PL，PG)
・ベンダー問合せや仕様確認などのインシデント管理などの際に，新しいワークフローを作れた
ので便利だった(PL)
(2)個人毎の作業が一覧できるので日々の作業が計画的に行えた
・開発者が積極的に作業するようになった(PL)
・バグ発見時，開発者が自発的にチケットへ登録するようになった(PL)
・PL 不在でも開発作業に支障がなかった(PL)
・チケットを見ることで，効率的に朝会や仕様確認ができた(PG)
・障害修正や仕様変更などの素早い対応が可能になったので納品を前倒しでき，ユーザの評価が
高まった(PL)
(3)複雑な構成管理作業の抜けがなかった
・保守/新規開発の切り替えが分かりやすかった(PG)
・タスクとしてチケットに登録していたから branch から trunk へのマージが確実にできた(PG)
・初めて作業 branch を上手に使えた(PL)
(4)テスト管理ツール TestLink の併用で，進捗管理が容易になった
・TestLink でテスト作業の進捗，Redmine でバグ修正までの進捗，を管理できた(PL)
・システムテストが以前よりもスムーズだった(PG)
SQiPシンポジウム2009
(5)チケットと構成管理ツール Subversion の連携で変更理由の特定が容易になった
・チケットとリポジトリが関連付けられているので，ソースの変更理由が探しやすかった(PG)
・チケットを元に，ソースのリバースエンジニアリングが容易になった(PL)
・Redmine チケット，Subversion リビジョン，ビルド管理ツール Hudson のビルド番号を相互リン
クすることで，検索が容易になった(PG)
・客先の質問をフォーラムで管理しようとしたが、チケットにすべきだった(PL)
このように TiDD によって，(1)多くの作業がロードマップによって容易に管理でき，個人毎の
作業が一覧できるので日々の作業が計画的に行えた，(2) 複雑な構成管理作業の抜けが生じなか
った，(3)変更理由の特定が容易になった，など開発者の負担を軽減することがわかった．また，
テスト管理ツールとの連携の有効性や開発者が協力的なことも確認できた．
5.
おわりに
本報告では，BTS を用いたチケット駆動開発(TiDD)をアジャイル開発に適用した．アジャイル
開発は高度な作業の管理が必要であり，TiDD はその問題を解決するものであった．つまり，(1)
チケットにタスクを割り当てることで，多くの作業や個人毎の作業の管理が容易になった．(2)
ワークフロー管理によって２重に管理されるソースの構成管理も容易になった．(3)BTS と構成管
理ツールとの連携によって、仕様変更の追跡が容易になった．
TiDD は BTS の多機能化と普及の中で生まれた．従来のように方法論に合わせてツールを作るの
ではなく，ツールの便利な利用法として発展したので，現時点ではツール開発のコストがかから
ない方法論である．また，TiDD ではタスクカードを貼るための掲示板が必要なく，アジャイル開
発の導入も容易にする方法だと考えられる．
今後は，現場で更に TiDD を実践して，ツールの連携や具体的な実施方法を更に強化していく予
定である．具体的には，チケットの粒度と運用方法，ストーリーカードの運用などをプラクティ
スとしてまとめると共に，TiDD によって XP がどの程度の規模まで適用範囲が広がるかなど、TiDD
を実施する上で生じる問題点を明らかにしていく予定である．
6.
謝辞
TiDD の名付け親のえと～さんはじめ，XPJUG 関西の皆さん，(株)SRA 小林さんに感謝します．
7.
参考文献
[1] K. Beck, C. Andres, Extreme Programming Explained: Embrace Change (Xp), Addison-Wesley,
2004.
[2] A. De'silets, The Agile Physician, pp. 8-9, IEEE Software 24-3, 2007.
[3] O. Kobayashi, M. Kawabata, M. Sakai, E. Parkinson, Analysis of the interaction between
practices for introducing XP effectively, Proc. ICSE'06, pp.544-550, 2006.
[4] 前田剛, 入門 Redmine, p76, 秀和システム, 2008.
[5] まちゅ, チケット駆動開発 … ITpro Challenge のライトニングトーク (4), まちゅダイア
リー, http://www.machu.jp/diary/20070907.html#p01, 2007.
[6] 独立行政法人情報処理推進機構(IPA) ソフトウェア・エンジニアリング・センター, ソフト
ウェアデータ白書 2008, p.35, 日経 BP 社, 2008.
[7] Jean-Philippe Lang, Redmine, http://www.redmine.org/, 2009.
[8] Subversion, http://subversion.tigris.org/, 2009.
[9] TestLink, http://testlinkjp.org/, 2009.
[10] Hudson, https://hudson.dev.java.net/, 2009.

Download Report