1. 挑戦の道具としての
チケット駆動開発
株式会社SRA
阪井 誠

2. 自己紹介
• 阪井誠（さかば、Twitter: @sakaba37）
• ソフトウェアプロセス、チケット駆動開発(ＴｉＤＤ)、
アジャイルに興味を持つ「プロセスプログラマー」
• 研究開発から現場まで、論文、書籍、雑誌など
2

3. 本の内容と発表内容
ＴｉＤＤの基本、 障害管理、
構成管理、 Mantisの運用例、
障害管理からTiDDへ、
プロジェクトを成功に導く、
アジリティの向上、 アダプタブルWF開発、
アジャイルブームを超えて、 高度な運用方法、
FAQとアンチパターン集、 テーラリング、
3

4. ソフトウェア業界のパラダイムシフト
• 1990年代に始まった
• ネオダマという標語によってソフトウェアハウスは
ＳＩ ｅｒに変わった
• 高機能ソフトの開発が容易になり、自由度が増し
た反面、リスクが増えた
• 技術者の守備範囲はソフトからシステムになり、
今、ビジネスに広がりつつある
• 常に新しい分野へのチャレンジが求められるよう
になった
4

5. 1995年の発表より
阪井，松本，鳥居, "ダウンサイジング時代のプロセス改善モデル", ソフトウェアシンポジウム'95論文集，1995.

6. 技術者の責任範囲
• 開発の効率化とともに責任範囲は広がった
– ビジネスは広がったが純粋なソフトウェア開発が
減少した
ビジネス
ソフトウェア
ハードウェア
ネットワーク
ネオダマ Ｗｅｂ クラウド
6

7. 要求の不安定さ
• ハンフリーは機能・インタフェース・環境の変更は
管理されないと開発は不安定になるとした
• Watts S. Humphrey, ソフトウェアプロセス成熟度の改善, 日科技連, 1991.
不安定な要求 誤解された要求 未知の要求
大体わかっているか 実現するために必 知っているつもりが、
もしれないが、詳細 要な詳細を理解して 使ってみて違いに気
は流動的 いない づく
• プロトタイプ、分離、段階的な開発など、アジャイル
やオブジェクト指向につながる提案をしているが
どのように管理して解決するかを示していない

8. パラダイムシフトを生き抜くには
• 環境、フレームワーク、ユーザーインタフェース、
ビジネスは日々変化している
• ソフトウェア開発は、常に挑戦！
• 開発中にノウハウやアイデア、気づきを蓄積し、
共有し、活用しないといけない
解決法の一つとして、チケット駆動開発を挑戦の
道具として活用する方法を提案します
8

9. 挑戦の道具としてのチケット駆動開発
ハーケン(釘)
カラビナ(止め具)
ザイル(ロープ)
• 挑戦時の履歴をその後の開発につなげます
• 開発者の気付きをチケットに記録します
• 協調作業を支援してプロジェクトを活性化します
9

10. 発表内容
• ソフトウェア業界のパラダイムシフト
– 技術者の責任範囲
– 要求の不安定性
• チケット駆動開発
– チケットによる管理
– ツール連携による自動化
– チケットによるコミュニケーション
• 挑戦の道具としてのチケット駆動開発
– 挑戦の道具に必要なもの
– チケット駆動開発のテーラリング
– 課題と可能性
– 事例
10

11. ＴｉＤＤのはじまり Ｔｒａｃブーム
• masuidrive的プロジェクトの方針(2007)
http://blog.masuidrive.jp/index.php/2007/07/11/masuidrive-working-style/
• まちゅ, 「もうひとつのTDD」, ITpro Challenge のライト
ニングトーク http://www.machu.jp/diary/20070907.html#p01
• Ｓｈｉｂｕｙａ.Ｔｒａｃキックオフ チケット駆動開発
誕生
• XPJUG関西 TiDD勉強会発足 (2008)
• 「Redmineによるタスクマネジメント実践技法」(2010)
• RxTstudy、Ｓｈｉｎａｇａｗａ.Ｒｅｄｍｉｎｅ(2011)
• 「チケット駆動開発」(2012)
：
11

12. チケット駆動開発
• ＩＴＳ（ＢＴＳ）のチケットで障害、課題、タスクを
管理して個人のタスクとプロジェクトを管理する
• 構成管理、Ｗｉｋｉ、継続的統合などツールを
チケットに連携させて自動化する
• プロジェクトの情報をチケットに関連付けて
管理することで、コミュニケーションを支援する
12

13. チケットによる管理
チケットシステム（ITS） プロジェクト
親チケット
障害・課題・タスク
ステータス
継続チケット
種類とロール毎のワークフロー
レポート、カスタムクエリ、
関連チケット ロードマップ、ガントチャート
等で参照できる

14. チケット一覧(例：Redmine)
SQiP2009発表資料より ©小川明彦, 阪井誠
14

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

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

17. ツール連携
作業、担当、
ステータス、進捗
開始、終了
refs #チケット番号
fixes #チケット番号
コメント
バージョン管理
ＩＴＳ ツール
17

18. ツール連携とチケット
チケットシステム（ITS）
CIツール
実行結果 親プロジェクト
参照 チケット
連携 プロジェクト
親タスク／ストーリー
バージョン管理
タスク
参照
リビジョン
リビジョン ステータス
リビジョン 連携
リビジョン
チケットの種類とロール毎のワークフロー
継続タスク
構成管理、Ｗｉｋｉ、 参照
ＣＩツールなどを Wiki 関連タスク
チケットに連携

19. チケットによるコミュニケーションの支援
チケットシステム（ITS）
CIツール
実行結果 親プロジェクト
参照 チケット
連携 プロジェクト
親タスク／ストーリー
バージョン管理
タスク
参照
リビジョン
リビジョン ステータス
リビジョン 連携
リビジョン
チケットの種類とロール毎のワークフロー
継続タスク
議論や更新を 参照
メール、RSS、 Wiki 関連タスク
プラグインで
通知できる

20. チケット駆動開発の効果
ツールを有効活用してプロジェクトの負担を減らす
• ツールが想定するプロジェクトに近づく
• 過去：
– 履歴の蓄積(経緯の確認、ノウハウの利用)
• 現在：
– 障害、課題、タスク、実行結果の管理
– 情報共有、自動化、コミュニケーション
• 未来：
– 計画、備忘録、リスクの見える化
20

21. 発表内容
• ソフトウェア業界のパラダイムシフト
– 技術者の責任範囲
– 要求の不安定性
• チケット駆動開発
– チケットによる管理
– ツール連携による自動化
– チケットによるコミュニケーション
• 挑戦の道具としてのチケット駆動開発
– 挑戦の道具に必要なもの
– チケット駆動開発のテーラリング
– 課題と可能性
– 事例
21

22. 挑戦の道具に必要なもの
• 新しい環境、実装方法、アプリケーションに挑戦
するには、以下の点を考慮しないといけない
– 気づいたことが共有されること
– 少ない経験が蓄積されること
– 蓄積した経験が生かせること
ふさわしいチケット駆動開発の運用方法が必要
22

23. テーラリング１：
気づいたことが共有されること
• チケットが容易に起票できるようにする
– 起票の権限をメンバーに与える
– ワークフローの制限を少なくする
• チケットの種類や属性を増やしすぎない
– 考えなくてよいようにする
– 記入項目を減らす
• リアルタイムに共有してモチベーションを高める
– メール、RSS、Eclipse 用のMylynプラグイン
– コミュニケーションのタイムラグ減ると利用が増える
23

24. テーラリング２：
少ない経験が蓄積されること
• チケット駆動を習慣づける
– 基本的な教育
– メリットを感じさせる
– 備忘録としての利用
ハーケン(釘)
• 利用に向けた支援 カラビナ(止め具)
ザイル(ロープ)
– カスタムレポートの用意など環境整備
– アドバイスのための棚卸し
– ルールの整備
(“No Ticket, No, Commit!!”をどこまで守るか、など)
24

25. テーラリング３：
蓄積した経験が生かされること
• 経験の種類に応じて整理する
– 一度だけの作業はチケットを起票する
– 手順やチェックリストはＷｉｋｉにまとめる
• 書きっぱなしのチケットを防ぐ
– 完了条件を明確にする
– 適切な棚卸しをする
• 発想力・提案力の向上
– 棚卸しの頻度を増やしすぎない
– 自律的なチーム
25

26. 自律的なチーム
• サーバントリーダーシップ
– コマンドコントロールをやめ、
メンバーが能力を生かせるように支援する
• マクロマネジメント
– マイクロマネジメントをすると依存するようになり、
自律性が失われる
• 濡れぞうきんはしぼらない
– 本田宗一郎氏がＩＩＪ鈴木幸一社長に送った言葉
– ガチガチの管理からは柔軟な発想は生まれない
26

27. 課題と可能性
• CBR(Case Based Reasoning)の経験による問題
解決する際にはインデックスが重要とされている
– 現状では日々の情報整理が必要
– チケット駆動開発の事例報告が少ない
– より多くの事例を集めて整理したい
• 挑戦の道具としての活用でリスクが低減できる可
能性がある
– ソフトウェア開発は常に挑戦だと認識する
– チケット駆動開発を活用する
– 発想力・提案力のあるチーム作りをする
27

28. ＴｉＤＤの
事例
そこには山がありました！
28

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

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

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

32. チケット駆動開発の導入
• 宣言と実行
「 バグだけではなく、ソースを触るときや、WBSにない作業をするときは、
チケットを登録してください！」
ハーケン(釘)
• 環境の準備
カラビナ(止め具)
o レポート(チケットの一覧)の作成
 bugのみ、 taskのみ、 その他、など ザイル(ロープ)
o 権限の追加
 tracの権限の設定は堅いので、チケットを修正できるようにmember
にTICKET_ADMINの権限を与えた
（リスクを考慮して設定してください)
• 教育
• パッケージチームとのＱＡの経験はあった
32

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

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

35. 事例のまとめ
• システムテスト以降にTiDDを導入
• 備忘録のつもりで気づいたことをチケット化した
• 手順はＷｉｋｉにまとめた
• 計画外の作業を管理できた
• 作業を見える化することで
コミュニケーションが向上した
• メンバーが前向きになり、
プロジェクトが元気になった
35

36. 注意すべき点
o チケットがルーチンワークでないと登録を忘れがち
o 他のチケットがないときにチェックを忘れて実施漏れ
⇒ 粒度の大きいチケットの後で発生
⇒ 粒度が小さいとリズムが生まれて、発生しにくい
• 棚卸のバランス
⇒ 防げるが自主性も大切！「チケット見てる？」
• クローズしにくいもの (担当がない、チェックリスト的)
⇒課題、リスクに多い。棚卸し、 Wikiを利用する
• 気が付かないことは実施できない
⇒ 自由な雰囲気、経験者への依頼、情報収集
36

37. おわりに
• パラダイムシフトは続いている
– リスクは増え続け、ソフト開発は常に挑戦である
• チケット駆動開発
– プロジェクトの情報を集中管理
– 自動化やコミュニケーションの支援ができる
• 挑戦の道具としての利用
– 気づきや経験を蓄積して活用
– 自由で自律的なチーム作りが重要
=> ぜひ皆さんも活用してください
37

38. おわり
挑戦の道具としての
チケット駆動開発