More Related Content
Similar to チケット駆動開発はアジャイル1次ブームの夢を見る (20)
More from Makoto SAKAI (20)
チケット駆動開発はアジャイル1次ブームの夢を見る
- 1. 1
チケット駆動開発はアジャイル 1 次ブームの夢を見る 阪井誠
1.はじめに
アジャイル一次ブームに湧いた今世紀の初め、私達はどうしてあの様に興奮したの
だろうか。10 年を経た後にチケット駆動開発を実践してみて、そこにその理由を見出
すことができた。本稿では、かつてのアジャイル1 次ブーム、近年のアジャイル2次
ブームを振り返った後に、チケット駆動開発に見つけた理由について説明する。
2.アジャイル 1 次ブーム
まず、アジャイル一次ブームを振り返ってみよう。1999 年ケントベックのエクスト
リームプログラミングの本の出版によって、 アジャイル1 次ブームが始まった。当時、
英語版しかないにもかかわらず、XPは多くの人に知るところとなった。私の所属し
た研究室でも輪講(交代で行う読書会)で取り上げられ、英語が苦手だったものの、今
までと違う何かに興奮したのを覚えている。
そして、ついに翻訳本が2000 年に登場。日本でも急速に普及する中、当時のエキス
パートによって具体的な技術が広く紹介されるようになった。そこには、従来の開発
法やプロセス改善法にはなかった、いくつかのポイントがあった。それは、現場から
のプロセス改善、 ツールによる効率化、 コミュニケーション、などである。もちろん、
顧客満足をめざして価値を提供するという本来の目的も多く語られていたが、興奮を
覚えたのはXP のアプローチが従来の開発方法の問題点を的確に指摘していたからだ
ろう。
従来の開発方法(以下従来法)はウォータフォール開発をベースにしており、組織的
な活動が中心で、ルールによって開発方法やコミュニケーションの中心となる文書ま
で定められていた。文書が主たる管理の対象であり、管理を目的とした多くの文書を
作成するルールも存在した。従来法では作業の効率化や成果物の品質向上は標準プロ
セスに習熟することによって得られるものと考えられていた。このため、標準から外
れるのであれば、まずパイロットプロジェクトで試行して、その効果を確認した上で
実施するという計画的で組織的なプロセス改善が基本であった。このような状況の中
で、生産性や品質向上につながる技術であっても、現場の要望したアイデアを実践す
る機会はあまり与えられなかった。
そのような状況の中で、XP で印象的だったものは、以下の3 つであった。
1
- 2. 2
現場からの改善 XP は実装中心だった。
: 開発者のコミュニケーションが重視され、
タスクボードを中心に、プロジェクトが運営されていた。日々、プロジェクトの様子
は可視化・共有化され、メンバー同士が協力し、アイデア出し合いながら開発を進め
るものだった。
ライトウェイトプロセス: YAGNI(You Aren't Going to Need It)の原則が、開発プ
ロセスに適用され、冗長なドキュメントを廃し、必要不可欠な情報で、プロジェクト
が運営された。
エンジニアリング(ツール+工学): XP そのものはアナログ的な要素を多く含むも
のだった。しかし、XP のエヴァンジェリストたちは高い技術力を持った人たちだった
ので、同時にEclipse や xUnit をはじめとする多くのツールが導入され、カバレージ
やメトリクスといったソフトウェア工学の技術が開発現場にもたらされるようになっ
た。
XP のこれらの特徴に触れることで、現場の技術者は目を輝かせ、狂喜乱舞した。あ
る人は上司を説得し、またある人は上司の目を盗み、現場で実践した。すべてが成功
したとは言えないかもしれないが、多くの成果や知見を得ることができた。
3.アジャイル二次ブーム
一方、アジャイル二次ブームは、一次ブームを包含したものではあるものの、少し
色あいが異なっている。XP の様なプログラミングを中心としたプロセスではなく、
Scrum に見られるように管理の色あいが濃くなった。それに伴って、注目されるツー
ルも eclipse からCI ツールの様に組織的なツールになった。
特に Scrum は、規律を中心とした従来型のプロセスからの移行も比較的容易である
とされ、多くの企業で導入や検討がすすめられている。その導入は、組織的に、既存
の管理との整合性を取りながら行われる事も多いようである。しかし、その様子を見
聞きしていると、アジャイル開発が普及することを歓迎したいとは思う反面、アジャ
イル一次ブームで目指したものと少し異なることから、危機感のようなものを感じて
いる。
それは、アジャイル開発に限ったものではなく、組織的なプロセス改善一般の問題
である「義務感」「やらされ感」によるプロセス改善の形骸化の可能性である。組織
的なプロセス改善の場合、改善を開始した当初はアーリーアダプタの協力によってう
まくいっても、組織全体に展開する場面で抵抗勢力が生まれることが多い。それまで
のプロセスは自分たちが築き上げ、改善してきたものであるのに、それを否定される
ように感じるからである。いわば、プロセスのNot-Invented-Here-Syndrom である。
2
- 4. 4
だけでなく、担当者ごとやチケットの様々属性で検索し、一覧することが可能である。
また、単に一覧するだけでなく、優先順位付けやグルーピングすることも可能である。
チケット駆動開発の一日は以下のようにチケットに始まり、チケットに終わる。
担当者は担当するタスクを確認し、優先順位に合わせて1日の作業を決め、1
日の終わりにその進捗を登録する
スクラムマスタ/プロジェクトリーダは朝会を招集し、ガントチャートやチケ
ットの一覧で進捗を確認する
プロダクトオーナ/プロジェクトマネージャは、メール等で知らされるチケッ
トの変更状況をウォッチする。また、イテレーション/リリースを示すバージ
ョンやマイルストーンごとの進捗を確認し、必要な調整をする
このような3重構造の一連の流れがあるが、その基本は組織でなく個人やチームで
ある。忘れてしまいそうな細かな作業を登録することや、ソースに関連付けられたチ
ケットの議論から問題の履歴が参照できることでトレーサビリティが確保されるなど、
担当者が楽をすることから改善が始まる。その情報はチーム内で共有され、さらには
組織的な管理も効率化される。
チケット駆動開発は必ずしもアジャイル開発そのものではない。しかし、チケット
をタスクカードのように使うことで、タスク管理だけでなく、イテレーションの管理
や構成管理との連携、見える化によるコミュニケーションの向上が図れるなど、アジ
ャイル開発にうまく適用できる。 しかも、従来型開発の補助的ツールとしての利用(補
完型)から初めて、チケットによるタスク全体の管理(完全型)、さらにアジャイル開発
にも柔軟に対応できる。
補完型チケット駆動開発:従来の管理方法はそのままに、障害管理や、細かな作業
の備忘録として用いる方法である。チケットとバージョン管理システムを連携するこ
とで、ソースの更新の履歴や議論を関連付けることができる。計画外の作業を管理で
きるほか、忘れてしまいがちな細かな作業の登録をすることで個人の作業も支援する。
チケット更新のメールが多くなる以外は、プロジェクトの管理方法は何も変わらない
ので、既存のルールの下でプロジェクトリーダの判断で開始できるという特徴がある。
完全型チケット駆動開発:プロジェクトの階層やチケットの階層を用いて、WBS の
構造をチケットに実現する方法である。すべての作業がチケットに記述されるので、
工数の集計などの管理が、全工程あるいはリリースの単位で可能になるほか、プロジ
ェクトの状況が「見える化」されてプロジェクト内の情報共有が促進される。
4
- 6. 6
6.おわりに
アジャイル 1 次ブーム、アジャイル2次ブームを振り返り、アジャイル 1 次ブーム
に感動した理由につながるチケット駆動開発の特徴を説明した。
チケット駆動開発はプロジェクト管理に有効なだけでなく、開発者個人の作業も支
援する。このため、現場主導で段階的にチケット駆動開発を導入することで、プロセ
スを改善することが可能である。組織的にチケット駆動開発を導入する際もやらされ
感が少なく、形骸化しにくいという特徴がある。
また、管理データが一元化され様々な参照方法が可能なので、管理を目的として類
似の書類を多数作成することも少なくなると考えられ、プロセスをライトウェイトに
移行させる開発法である。ツール導入と同時に技術も導入されるので、WBS としての
利用やテストツール、CI ツールなど、現場に効率的なエンジニアリング環境が構築で
きると考えられる。
アジャイル 1 次ブームの時にXP に感じた感動、それは現場からの改善、ライトウェ
イトプロセス、ツールとソフトウェア工学の導入による高度なエンジニアリングであ
った。あの時の夢を、 チケット駆動開発の実践によって、 ぜひ実現していただきたい。
6