第2回 RxTstudyの講演資料 チケット駆動開発はアジャイル開発と親和性が高い一方で、従来法の開発中に生じる想定外の問題を管理・解決する際にも有効です。チケット駆動開発を導入することでプロジェクトの危機的な状況から抜け出して、メンバーが積極的に、プロジェクトが元気になり、プロジェクトを成功に導いた事例をご紹介します。

1. アダプタブル・ウォーター
フォール開発の事例
～ 想定外の作業は
チケットで補完せよ! ～
阪井 誠
＠sakaba37

2. 自己紹介
あきぴーさんとチケット駆動開発
(TiDD)の本を書いてます
阪井 誠
（さかば）
2

3. ウォーターフォール開発の苦悩
トップダウンなプロセス
・文書コミュニケーション
・厳密で手順的な計画
・柔軟に再計画・管理できない
・変更を随時受け入れる
⇒計画外の事象が多いと混乱
3

4. アジャイル開発への期待
現場力の発揮
・コミュニケーション向上
・リズミカルな開発
・開発に集中できる
変化への対応
・タスク(カード)単位の管理
・イテレーション毎の受け入れ
4

5. アジャイル開発への壁
自社の壁
・開発標準(工程ごとの管理)
・紙ベースの報告(各種報告書)
・タスクボードの設置場所
顧客の壁
・契約(仕様＋変更)、窓口とスポンサーが異なる
・並行開発システムの組合せ(System of systems)
⇒ ウォーターフォール開発を
ベースに何とか改善したい
5

6. アダプタブル・ウォーターフォール開発
ウォータフォールにアジャイルの
要素を取り込む
・補完型チケット駆動開発
・追加のタスクをBTSで管理
・既存のルールは変更しない
6

7. チケット駆動開発（TiDD）とは
• BTS（ITS)を使う
• チケットを用いて作業の管理をする
• チケットがなければ（構成管理上の）更新をし
ない(No Ticket, No Commit!)
• アジャイ的(XPの4つの価値)
• シンプルな管理、見える化によるコミュニケーション改
善、未完了作業のフィードバック、実施する勇気が必要
⇒ 様々な実施方法がある

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

9. チケットの管理方法
• ワークフロー型
o 起票や終了には権限が必要
o 仕様の一貫性を保障できる
• オープン型（今回の例）
o 誰でも起票・終了できる
o 機敏さ、自由がある
＊アダプタブルWFでは特に規定しないが
オープン型が望ましい
9

10. TiDDの導入範囲
• 工程
o 全工程、一部の工程
• プロダクト
o 全体、一部
• メンバー
o 全員、一部
10

11. どのように導入するか
• 全体に適用
– プロセスがシンプルになるが、チケットが増える
• 部分的に導入
– 細かなチケットが作成可能、プロセスの強化
– 作業漏れ防止、コミュニケーション、などに効果
⇒ どちらが良いかではなく、ふさわしい方法が
ある
11

12. 目次
• TiDDとその分類（説明済み）
• TiDDの経験談
– プロジェクト概要
– 導入時の工夫
– 結果、効果
– 注意点
• まとめと感想
12

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

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

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

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

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

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

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

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

21. やり手
しんどい状況
TiDD
控え目
• 玉ちゃんの文化系入門より 21

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

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

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

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

26. まとめと感想
• システムテスト以降にTiDDを導入
• 計画できていなかった作業が管理できた
• 前向きになり、プロジェクトが元気になった
• 感想
– 意外と簡単！(備忘録のつもりで)
– もう少し上流でも使ってみたい(技術的な問題だけで
なく仕様変更もうまく扱いたい)
– 大学のH君を思い出した
26

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

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

29. ま け
お チケット駆動開発のコツ
リズムを作って、情報共有を習慣にする
– データの一元化
– 粒度が大きくてはいけない！
– 備忘録化(プライベートチケットも有効かも)
– 習慣になるようなルール(朝会、進捗更新)
– 見やすいレポートの準備
– 問題意識の共有(作業数、作業量)
29

30. アダプタブル・
ウォーターフォール開発の事例
～想定外の作業はチケットで補完せよ!～
おわり

31. KPT
• Keep：
• 情報の共有、コミュニケーション、協力
• チケットの自由な発行
• Probrem：
• リズムがなくなると手抜きになる
• Try：
• 要件管理との連携、スクラム(内乱だけでなく、
外乱も扱いたい)
• Redmine
• 定量的な発表

32. スクラム的な使い方
• イメージ(内乱だけでなく、外乱も扱いたい)
• バグでも要望でもとりあえずチケットを切る
o 切り分け⇒要望リスト(プロダクトバックログ)
• 納期を決めてマイルストーンを設定
⇒要件リスト(スクラムバックログ)
• 必要なら作業を分解
• 小さな要望なら簡単
• 大きな要件はタスクレベルではなくなるので、カスタム
フィールドを用いるなど、別の管理が必要
32

33. ひとりチケット駆動開発の経験
• タスクからスケジュールができるのは便利
– そのまま客先に出すには、ちょっと、、、
– 計画を考える道具にはなりにくい
• 楽しくなかった
33