UltimateAgileStories iteration1の記事です。

1. 1
チケット駆動開発はアジャイル 1 次ブームの夢を見る 阪井誠
１．はじめに
アジャイル一次ブームに湧いた今世紀の初め、私達はどうしてあの様に興奮したの
だろうか。10 年を経た後にチケット駆動開発を実践してみて、そこにその理由を見出
すことができた。本稿では、かつてのアジャイル1 次ブーム、近年のアジャイル２次
ブームを振り返った後に、チケット駆動開発に見つけた理由について説明する。
２．アジャイル 1 次ブーム
まず、アジャイル一次ブームを振り返ってみよう。1999 年ケントベックのエクスト
リームプログラミングの本の出版によって、 アジャイル1 次ブームが始まった。当時、
英語版しかないにもかかわらず、ＸＰは多くの人に知るところとなった。私の所属し
た研究室でも輪講(交代で行う読書会)で取り上げられ、英語が苦手だったものの、今
までと違う何かに興奮したのを覚えている。
そして、ついに翻訳本が2000 年に登場。日本でも急速に普及する中、当時のエキス
パートによって具体的な技術が広く紹介されるようになった。そこには、従来の開発
法やプロセス改善法にはなかった、いくつかのポイントがあった。それは、現場から
のプロセス改善、 ツールによる効率化、 コミュニケーション、などである。もちろん、
顧客満足をめざして価値を提供するという本来の目的も多く語られていたが、興奮を
覚えたのはXP のアプローチが従来の開発方法の問題点を的確に指摘していたからだ
ろう。
従来の開発方法(以下従来法)はウォータフォール開発をベースにしており、組織的
な活動が中心で、ルールによって開発方法やコミュニケーションの中心となる文書ま
で定められていた。文書が主たる管理の対象であり、管理を目的とした多くの文書を
作成するルールも存在した。従来法では作業の効率化や成果物の品質向上は標準プロ
セスに習熟することによって得られるものと考えられていた。このため、標準から外
れるのであれば、まずパイロットプロジェクトで試行して、その効果を確認した上で
実施するという計画的で組織的なプロセス改善が基本であった。このような状況の中
で、生産性や品質向上につながる技術であっても、現場の要望したアイデアを実践す
る機会はあまり与えられなかった。
そのような状況の中で、XP で印象的だったものは、以下の3 つであった。
1

2. 2
現場からの改善 XP は実装中心だった。
： 開発者のコミュニケーションが重視され、
タスクボードを中心に、プロジェクトが運営されていた。日々、プロジェクトの様子
は可視化・共有化され、メンバー同士が協力し、アイデア出し合いながら開発を進め
るものだった。
ライトウェイトプロセス： YAGNI(You Aren't Going to Need It)の原則が、開発プ
ロセスに適用され、冗長なドキュメントを廃し、必要不可欠な情報で、プロジェクト
が運営された。
エンジニアリング(ツール＋工学)： XP そのものはアナログ的な要素を多く含むも
のだった。しかし、XP のエヴァンジェリストたちは高い技術力を持った人たちだった
ので、同時にEclipse や xUnit をはじめとする多くのツールが導入され、カバレージ
やメトリクスといったソフトウェア工学の技術が開発現場にもたらされるようになっ
た。
XP のこれらの特徴に触れることで、現場の技術者は目を輝かせ、狂喜乱舞した。あ
る人は上司を説得し、またある人は上司の目を盗み、現場で実践した。すべてが成功
したとは言えないかもしれないが、多くの成果や知見を得ることができた。
３．アジャイル二次ブーム
一方、アジャイル二次ブームは、一次ブームを包含したものではあるものの、少し
色あいが異なっている。XP の様なプログラミングを中心としたプロセスではなく、
Scrum に見られるように管理の色あいが濃くなった。それに伴って、注目されるツー
ルも eclipse からCI ツールの様に組織的なツールになった。
特に Scrum は、規律を中心とした従来型のプロセスからの移行も比較的容易である
とされ、多くの企業で導入や検討がすすめられている。その導入は、組織的に、既存
の管理との整合性を取りながら行われる事も多いようである。しかし、その様子を見
聞きしていると、アジャイル開発が普及することを歓迎したいとは思う反面、アジャ
イル一次ブームで目指したものと少し異なることから、危機感のようなものを感じて
いる。
それは、アジャイル開発に限ったものではなく、組織的なプロセス改善一般の問題
である「義務感」「やらされ感」によるプロセス改善の形骸化の可能性である。組織
的なプロセス改善の場合、改善を開始した当初はアーリーアダプタの協力によってう
まくいっても、組織全体に展開する場面で抵抗勢力が生まれることが多い。それまで
のプロセスは自分たちが築き上げ、改善してきたものであるのに、それを否定される
ように感じるからである。いわば、プロセスのNot-Invented-Here-Syndrom である。
2

3. 3
そこで、導入を進めるために行われがちであるのが、既存の管理との共存である。
既存の管理方法を残したまま、アジャイル開発を導入するのである。この方法は現実
的で、一見良さそうに思われるが、重厚な管理ドキュメントの存在が残ってしまう可
能性がある。ベーム先生の「アジャイルと規律」にあるように、重くなってしまった
従来型開発を軽量化するには、必要なもののみから組み立てのすか、従来型開発に詳
しいコンサルタントを頼まないとうまくいかないだろう。
幸いなことに、Scrum の導入とプロジェクトファシリテーションが同時に語られる
ことが多い。やらされ感を感じさせるプロセスや、ヘビーウェイトなプロセスにする
のではなく、開発者が主体的で自律的なソフトウェア開発が行えるように、プロジェ
クトファシリテーションが効果を発揮してくれることを期待している。
４．チケット駆動開発
チケット駆動開発は現場で生まれた開発法である。 (1)障害管理ツールのチケットで
タスクを管理する、(2)チケットと関連付けられないコミットは許さない、 障害管
(3)
理ツールを中心にプロジェクトを自動化する、開発法である。プロジェクトの情報が
一元管理され、更新に至った議論を含んだチケットの更新履歴がコードと関連付けら
れる開発法である。
図 1 チケット駆動開発
チケット駆動揮発では、個人の担当するタスクが記載されたチケットでプロジェク
トが管理される。チケットの情報はガントチャートで全体像を鳥瞰することができる
3

4. 4
だけでなく、担当者ごとやチケットの様々属性で検索し、一覧することが可能である。
また、単に一覧するだけでなく、優先順位付けやグルーピングすることも可能である。
チケット駆動開発の一日は以下のようにチケットに始まり、チケットに終わる。
 担当者は担当するタスクを確認し、優先順位に合わせて１日の作業を決め、１
日の終わりにその進捗を登録する
 スクラムマスタ/プロジェクトリーダは朝会を招集し、ガントチャートやチケ
ットの一覧で進捗を確認する
 プロダクトオーナ/プロジェクトマネージャは、メール等で知らされるチケッ
トの変更状況をウォッチする。また、イテレーション/リリースを示すバージ
ョンやマイルストーンごとの進捗を確認し、必要な調整をする
このような３重構造の一連の流れがあるが、その基本は組織でなく個人やチームで
ある。忘れてしまいそうな細かな作業を登録することや、ソースに関連付けられたチ
ケットの議論から問題の履歴が参照できることでトレーサビリティが確保されるなど、
担当者が楽をすることから改善が始まる。その情報はチーム内で共有され、さらには
組織的な管理も効率化される。
チケット駆動開発は必ずしもアジャイル開発そのものではない。しかし、チケット
をタスクカードのように使うことで、タスク管理だけでなく、イテレーションの管理
や構成管理との連携、見える化によるコミュニケーションの向上が図れるなど、アジ
ャイル開発にうまく適用できる。 しかも、従来型開発の補助的ツールとしての利用(補
完型)から初めて、チケットによるタスク全体の管理(完全型)、さらにアジャイル開発
にも柔軟に対応できる。
補完型チケット駆動開発：従来の管理方法はそのままに、障害管理や、細かな作業
の備忘録として用いる方法である。チケットとバージョン管理システムを連携するこ
とで、ソースの更新の履歴や議論を関連付けることができる。計画外の作業を管理で
きるほか、忘れてしまいがちな細かな作業の登録をすることで個人の作業も支援する。
チケット更新のメールが多くなる以外は、プロジェクトの管理方法は何も変わらない
ので、既存のルールの下でプロジェクトリーダの判断で開始できるという特徴がある。
完全型チケット駆動開発：プロジェクトの階層やチケットの階層を用いて、WBS の
構造をチケットに実現する方法である。すべての作業がチケットに記述されるので、
工数の集計などの管理が、全工程あるいはリリースの単位で可能になるほか、プロジ
ェクトの状況が「見える化」されてプロジェクト内の情報共有が促進される。
4

5. 5
アジャイルチケット駆動開発：アジャイル開発のタスクカードやストーリカードを
チケットに置き換えて管理する開発法である。チケットの階層や依存関係を用いてタ
スクカードやストーリカードを関連付ける方法や、プラグインを用いてよりアジャイ
ル開発に適した方法で管理することもできる。
５．チケット駆動開発の特徴
このように、アジャイル開発に向けて段階的に進化することのできるチケット駆動
開発には以下のような特徴がある。
１) 現場のメリットから改善が始まる
チケット駆動開発はプロセスを改善するが、それは組織のルールからではなく、
開発担当者が楽をできるという現場のメリットから導入を始めることができる。
従来のプロセス改善が組織のプロセスを改善することによって、将来的に個人
の幸せにつながるとして普及を進めていることを考えると、これは大きな特徴
である。従来のプロセス改善の担当者は、成功事例を集めて紹介する、ワーク
ショップを開いて組織の在り方を議論する、などの苦労を強いられていた。し
かし、チケット駆動開発は無理強いをしてやらされ感を感じさせる必要はない。
なぜなら、開発者は楽をしたいと思っているからだ。
２) 障害管理、課題管理、進捗管理、構成管理、情報共有、見える化、が一元管理
によって実現される
障害や課題、さらにタスクがチケットに記録され、障害管理、課題管理、進捗
管理が行われる。チケットは構成管理(バージョン管理システム)と関連付けら
れ、プロジェクト内で情報共有される。そこでは、計画との相違や負荷の偏り
など、プロジェクトの問題が「見える化」される。これらは障害管理システム
のチケットによって一元管理される。
３) ツールによって開発技術が向上する
チケット駆動開発を始めるために、障害管理システム、バージョン管理システ
ムという基本的なソフトウェアが導入される。これらのツールの導入によって
楽ができる経験をすることで、さらに、テスト管理ツール、 ツールなど、
CI 様々
なツールの導入の検討が始まる。それらは組織的な管理のためでなく、担当者
やチームが楽をするために導入されるが、同時に新しい開発技術が導入される
のである。
5

6. 6
６．おわりに
アジャイル 1 次ブーム、アジャイル２次ブームを振り返り、アジャイル 1 次ブーム
に感動した理由につながるチケット駆動開発の特徴を説明した。
チケット駆動開発はプロジェクト管理に有効なだけでなく、開発者個人の作業も支
援する。このため、現場主導で段階的にチケット駆動開発を導入することで、プロセ
スを改善することが可能である。組織的にチケット駆動開発を導入する際もやらされ
感が少なく、形骸化しにくいという特徴がある。
また、管理データが一元化され様々な参照方法が可能なので、管理を目的として類
似の書類を多数作成することも少なくなると考えられ、プロセスをライトウェイトに
移行させる開発法である。ツール導入と同時に技術も導入されるので、WBS としての
利用やテストツール、CI ツールなど、現場に効率的なエンジニアリング環境が構築で
きると考えられる。
アジャイル 1 次ブームの時にXP に感じた感動、それは現場からの改善、ライトウェ
イトプロセス、ツールとソフトウェア工学の導入による高度なエンジニアリングであ
った。あの時の夢を、 チケット駆動開発の実践によって、 ぜひ実現していただきたい。
6