小規模かつ高機能なソフトウェア開発の増加、環境のオープン化、ビジネス環境の変化など、近年増加する困難さから、BTS(障害管理ツール)を用いてタスクを管理するTiDD(チケット駆動開発)が注目されています。本発表ではこのTiDDの概要と体験談をお話しします。 　まずTiDDの概要として、普及の背景、歴史、事例、と共にTiDDとは何かを説明します。次にTiDDの体験談として総合文教ソリューションUniVisionのカスタマイズ開発での体験談を報告します。体験談のプロジェクトでは、リリースが近づくにつれ、細かな作業が増えて困っていました。そこで、TiDDを導入したところ、作業の抜けが少なくなっただけでなく、プロジェクトが元気になりました。

1. TiDD: Ticket Driven Development
- チケット駆動開発の概要と体験談 -
株式会社SRA
阪井 誠

2. TiDD普及の背景
• 小規模かつ高機能なソフトウェアの開発
• オープン化に伴う環境の流動化
• ユーザ(ビジネス)要求の不安定化
• 細かく大量の作業、変化への対応が必要となり、
プロセスの即時性・効率化が求められた
– 従来型開発のアジリティ向上
– アジャイル開発の支援
2

3. 目次
• チケット駆動開発(TiDD)の概要
– TiDD普及の背景
– TiDDの歴史
– TiDDの事例
– TiDDとは(BTS、アジャイル開発との関係、
TiDDによる改善、運用方式、管理方法)
• TiDDの体験談
• まとめと感想
3

4. TiDDの歴史
2007年 まちゅ, 「もうひとつのTDD」, ITpro Challenge のライトニングトーク
http://www.machu.jp/diary/20070907.html#p01
2008年 XPJUG関西 ビジネスモデリング研究会からTiDD勉強会発足
前田, 「入門Redmine Linux/Windows 対応」, 秀和システム
岡本, 「第1回Tracをオススメする，これだけの理由」, Trac で開発現場を交通整理
http://itpro.nikkeibp.co.jp/article/COLUMN/20080414/298973/
2009年 あきぴー , XP祭り関西2009「チケットファーストでアジャイル開発！」
http://forza.cocolog-nifty.com/blog/2009/02/xp2009-746a.html
阪井, 「TiDD ： チケット駆動によるアジャイル開発法」, FORCE2009.
http://sakaba.cocolog-nifty.com/PDF/TiDD_FORCE09.pdf
shun, 名古屋アジャイル勉強会 第13回「チケット駆動開発入門」
http://successdrills.com/modules/d3blog/details.php?bid=359
小川, 阪井, 「チケット駆動開発 - BTSでExtreme Programmingを改善する-」
http://forza.cocolog-nifty.com/blog/2009/11/spes2009sqip200.html
2010年 XPJUG, XP祭り関西2010「チケット駆動開発の体験談」ほか
http://w w w .xpjug.jp/

5. TiDDの事例
• 企業
多くの企業で、すでに実践されています。
企業名等は勝手に書けないので非公開としています。
申し訳ありません。
• 大学
授業で利用されることもあるようです。
• 関連コミュニティ
– XPJUG関西 TiDD勉強会
– Shibuya.trac
5

6. チケット駆動開発（TiDD）とは
• BTS（ITS)を使う
• チケットを用いて作業の管理をする
• チケットなしに（構成管理上の）更新をしない
No Ticket, No Commit!
• (ツール連携による自動化)
⇒ 厳密な定義はなく、様々な実施方法がある
個人的には、チケット駆動開発という名前の下に
様々な技術を整理・統合したいと思っています

7. BTS：Bug Tracking System
(ITS：issue tracking system)
• BTS(ITS)とは
– 障害(課題)を管理するツール
– Trac, Redmine, Mantis, Bugzilla, GNATS, 影舞
– 障害(課題)ごとにチケットを発行する
• チケットの属性ごとの一覧が可能
– 状態：報告、担当者決定、修正済、確認済、完了など
– 担当者、作業工数、完了予定、完了日
• 高機能化
– ワークフローの管理
– 構成管理ツール(色々), TestLink等との連携
– ガントチャート(線表)の作成
– 階層管理（WBSより詳細にできる)
– Wiki, メール, RSS機能
7

8. チケット一覧(例：Redmine)
タスクボードの代わりとして
担当者毎の進捗を確認できる
8
SQiP2009発表資料より ©小川明彦, 阪井誠

9. ガントチャート
SQiP2009発表資料より ©小川明彦, 阪井誠
9

10. ワークフロー設定(例：Redmine)
ソフトウェア開発のワークフローは
BTSのワークフロー機能で
制御できる
ユーザ権限と
チケット種類の単位で
ステータスの現在・移行先を
指定する
現 ステータスの移行先
在
の
ス
テ
ー
タ
ス
10
SQiP2009発表資料より ©小川明彦, 阪井誠

11. TiDDの効果
• ワークフローの管理
• 見える化
– プロジェクト状況把握
– 担当や重要度など様々な視点での作業管理
– コミュニケーション・納得性向上
• ソースのトレーサビリティ向上
• ツール連携による自動化
• アジリティの向上
11

12. アジャイル開発との関係
• アジャイル開発とは（良く聞く表現）
– 変化を前提に開発
– 繰り返し開発
– 期間を固定してスコープを変更
– 規律・ツールよりも人（プロジェクトファシリテーション)
⇒コミュニケーション、モチベーション
12

13. 変化
スクラム
スプリント(30日間)
要望
要望
スプリント
バックログ
優
先
順 日次スクラム
位 (朝会)
スプリント計画
ミーティング
プロダクト
バックログ
スプリントレビュー
リリース
ミーティング
13

14. XP(eXtream Programing)
イテレーション
変化
ストーリカード
要望 ストーリカード
ストーリカード
要望
イテレーション計画
計画ゲーム
ストーリカード
ストーリカード ToDo Doing Done
ストーリカード
ストーリカード
ストーリカード タスクカード タスクカード タスクカード
タスクカード タスクカード
優先順位を考慮し
てイテレーションを タスクカード
計画 タスクボード
14

15. TiDDによるアジャイル開発の支援
期間優先＆優先順位
によるスコープの変更
– 電子化による自由度向上 コミュニ
• スクラムのバックログ ケーション
• XPのタスクカード・タスクボード
– トレーサビリティ(コメント・議論、変更の履歴)
– 繰り返しリリースの支援
• ふりかえりが容易になりプロセスが洗練される
• 本番保守と開発の2重管理をワークフローで支援
– BTS中心にツールを統合(構成管理、テスト、継続
的インテグレーション、デプロイ)
– アジャイルの目指すところがわかる
⇒ 「アジャイルがわかった！」 15

16. アジャイル
に限らない TiDDによる改善(順不同)
＜レベル１＞ TiDD前夜
＜レベル2＞ 繰り返し作業に習熟する
– 個人のリズム：朝会、担当チケット確認、実施、チケット更新
– イテレーション：リリース計画、チケット登録・解決、リリース、ふりかえり
＜レベル3＞ プロセスの一般化と分類
– ワークフローを組織向けに分類・変更し、品質向上、効率化
– ソースのトレーサビリティが向上
＜レベル4＞ 見える化による定量的な管理
– コミュニケーション・納得性の改善、モチベーション向上
– スコープ(対象作業)管理によるアジリティ向上
＜レベル5＞ プロセスの進化
– ツールの導入や自動化など、試行と評価による改善
16

17. TiDDの運用方式
• 完全チケット方式(Redmineの本ほか)
o チケットですべての作業を管理する
o 管理が集約される
o プロセスを変更するので社内調整が必要
• 補完チケット方式（今回の体験談）
o 既存の管理は変更しない
o 計画外の作業をチケットで管理する
o こっそり開始できる(でも報告は必要<=後述)

18. チケットの管理方法
• ワークフロー型
o トップダウン組織的
o 起票や終了には権限が必要
o 仕様の一貫性を保障できる
• オープン型（今回の体験談）
o ネットワーク組織的
o 誰でも起票・終了できる
o 機敏さ、自由がある
18

19. 目次
• チケット駆動開発の概要（説明済）
• TiDDの体験談
– プロジェクト概要
– 導入時の工夫
– 結果、効果
– 注意点
• まとめと感想
19

20. 質問
Q: ソフトウェア開発が楽しいですか？
A: ものづくりだから楽しいはず
• しかし、不完全な人間が、間違いを犯さない計算
機と戦わないといけない
• ミスをしてはいけないというプレッシャーを感じるこ
とも多い
• しかもやることはたくさんある
★TiDDはそんなプロジェクトを元気にしました！

21. TiDDの体験談（概要）
• 文教パッケージのカスタマイズ(最大8人x1年)
o 短納期 ＆ 仕様の決定遅れ・変更
o スキルは高いが経験者が少ない(リーダは途中交代)
o 初めての組み合わせ（サブシステム、ミドルのバージョン）
o 義務感と不安、重苦しい雰囲気、閉塞感、、、
o 守りに入るので、コミュニケーションが悪い
システムテストの時期になると、計画外の環境構築やリリース
準備作業が明らかになった（環境に関連するバグも、、、）
⇒ そうだ！チケット駆動開発をしよう！
21

22. 総合文教ソリューション UniVision
UniVisionは入試管理、学籍管理、教務管理といった基幹事務機能を中心に学生
サービスに関する情報全般を統合的に管理する統合文教ソリューションです。
また、2009年度より、新たに法人系システム（学校会計、固定資産）もサービス開
始しております。システムコンサルティングから構築、運用支援にいたるトータルサ
ポートサービスを御提供しています。
履修管理
履修管理
学籍管理
学籍管理
成績管理
成績管理
入試管理
入試管理
SOA基盤
進級・卒業
進級・卒業
授業料・入学金
授業料・入学金 奨学金
奨学金 就職管理
就職管理
研究者Ｄ シラバス情報
研究者Ｄ 休講
卒業生管理
スクーリング管理 奨学金
奨学金 Ｂ 卒業生管理
課外活動 Ｂ 学生呼出
科目修了試験 課外活動
施設予約 レポート管理
配本管理 施設予約 評価ＤＢ
評価ＤＢ 教室変更
オンライン試験 保健管理
保健管理
アンケート
学校会計
学校会計 e-Learning
固定資産
固定資産
ＳＯＡによるシームレスな業務処理
【UniVision全体概念図】 22

23. 総合文教ソリューションUniVisionの特徴
• Strutsベースのパッケージ
o 複数のサブシステムを組み合わせて構成できます
o 個別要件にも柔軟に対応します
• オープンシステムにも対応
o お客様の規模、ご予算に合わせて、ハードウェアや
ミドルウェアの構成が選べます
UniVision
奨学金 健康 スクー
学籍 教務 就職 履修 教材管理
管理 管理 リング
図書館システム
Web Service
財務会計システム
UniVision Service BUS Web Service
人事給与システム
Web Service
教職員 ．．．
卒業生 施設予約 学費 入試
管理
• 2009 Software Research Associates, Inc

24. オープンなフレームワークだから、、、
長所
• 同じようなコードが減る
• 個別の業務要件に対する固有の開発だけでよい
短所
• お約束が多い複雑な作業で、気が抜けない
• 工夫できる余地が少ない
• 少人数で大規模なシステムが作れてしまう
• 実行環境の構成は日々変化
⇒ ややこしくて、大変！
24

25. TiDDの実施方式
• 補完チケット方式
• WBSと併用（と言っても更新作業は全てチケットあり）
• オープン型
• だれでもチケットが作成できる
• システムテスト以降
• システム全体
• メンバー全員
• trac（単独）
・・・ SRA共通開発環境（trac,subversion,mailmanの仮想環境）

26. はじめの一歩
• 宣言と実行
「 バグだけではなく、ソースを触るときや、WBSにない作業をするときは、
チケットを登録してください！」
• 環境の準備
o レポート(チケットの一覧)の作成
 bugのみ、 taskのみ、 その他、など
 抽出条件(WHERE句)や表示項目(前に"_"があると表示されない)
は自由に変更できる
o 権限の追加
 tracの権限の設定は堅いので、チケットを修正できるように
memberにTICKET_ADMINの権限を与えた
（リスクを考慮して設定してください)
26

27. 結果
• チケットの数(BUG以外)
o システムテスト：３１
o 本番環境構築：４２
 データの準備、環境準備、BUG関連で増えた作業、
細かな仕様変更など、手順書にない1回だけの作業
• 作業漏れ減少！納期までに作業が完了！
(知らないこと、気付かないことはできませんでした、、、orz)
それ以外にも、メンバーに変化が、、、
27

28. 目が輝いた！
サブリーダ(クラス)なのに遠慮をしていたメンバー
が、生き生きしだした
• 「チケットを切ってもいいですか？」
⇒ 義務的な作業からの解放
• 「チケットを切っておかないと忘れてしまう！」
⇒ すくに使いこなしていた
• 「ちゃんとクローズしてね」
⇒ 他の人に指導をしていた！
• 「残っているチケットが多くてわかりにくいから整理
しますね」
⇒ 今後のことも考えている

29. 失敗！
• 上司への説明をしていなかった
o 通知メールが多いので、不具合が多いのかと心配
された

30. 注意すべき点
• チケットの登録忘れ
o チケットがルーチンワークになっていないと忘れがち
• チケットの実施忘れ
o 他のチケットがないときにチェックを忘れる
⇒ 粒度の大きいチケットの後で発生
⇒ 粒度が小さいとリズムが生まれて、発生しにくい
(リーダが管理すれば防げますが、自主性も大切)
• 上司への連絡 (^_^;
30

31. TiDDの効果(XP的な表現)
• 変化を抱擁できる
o 当初想定しなかった作業を管理できた
• コミュニケーション
o 見える化され全員が状況を把握
o 他の人のチケットも自由に登録
o それまではサブシステム間の連絡はリーダが担当
o お互いに相談・協力するようになった

32. TiDDの効果(スクラムの価値 *で)
• コミットすること
– 自主的にチケットを発行し、実施した
• 集中すること
– 担当チケットの作業に集中できた
• オープンであること
– 通知メールやレポートで、プロジェクト全体を見渡せた
• 敬意を払うこと
– 守りに入らず、助け合うようになっていた
• 勇気を出すこと
– リズムが生まれて、前向きになる勇気が得られた！
* K. Schwaber, M. Beedle, アジャイルソフトウェア開発スクラム, ピアソン・エデュケーション, pp.165-174.
32

33. まとめと感想
• システムテスト以降にTiDDを導入
• 計画されていなかった作業を管理できた
• コミュニケーションが向上し、プロジェクトが元気になっ
た
• 感想
– 意外と簡単！(備忘録のつもりで)
– もう少し上流でも使ってみたい
– Redmineが便利そう
– 大学のH君を思い出した
33

34. 大学の友人H
• 切符をどこに入れたのかを忘れてしまうからと
「ズボンのポケットに入れたから覚えといて！」
⇒ 「それぐらい覚えておけよ！」と内心思っていた
今から思うと
– 何かのトラウマがあったのかもしれない
– 本当に覚えるのが、苦手なのかもしれない
– 人に話すと覚えるという記憶法なのかもしれない
実はチケット駆動開発に似ている
34

35. みんなで協力すれば楽しい！
• 忘れそうなことをみんなと共有することで
– 緊張から開放されて安心できた
– 忘れていたときは、教えてもらえた
– もしものときは助け合った
– トラブルは起きなかった
「楽しいし、元気が出た」
★ソフトウェア開発が、そういう仕事であってほしいです。
ぜひ、みなさんもTiDDを実践してください！
35

36. TiDD: Ticket Driven Development
-チケット駆動開発の概要と体験談 -
おわり