ITの地殻変動はどこで起きているのか？～チケット駆動開発はなぜ生まれたのか

2009年になって、ITの地殻変動がどこに起こっているのか？を考えてみる。
＃ラフなメモ書き。

【参考】
InfoQ: Martin Fowler氏が語る陥りがちなスクラムの落とし穴を避ける方法

InfoQ: 複数のアジャイルチームでのバージョン管理

チケット駆動開発 … ITpro Challenge のライトニングトーク (4) - まちゅダイアリー(2007-09-07)

【アジャイル開発の問題点】
1990年代後半から、サーバー＋クライアントの2層方式を基本とするVBアプリからMVCを基本とするWebシステムへのリエンジニアリングがあった。
更に、システムが大規模化して、開発期間が短くなるSW開発の現場。

RUPなど、イテレーティブな開発プロセスの重要性が叫ばれるものの、実際の現場で運用するにはハードルが高かった。

2000年頃出現したXPは、ソフトウェアの歴史の中で、オブジェクト指向の次に当たるソフトウェアの革命。
SW開発が大規模化して官僚化していく中で、プログラマ中心の開発プロセスを提唱した政治的主張も併せ持つ。

オブジェクト指向は40年かかって、どのプログラミング言語でも当たり前の概念になった。
XPを代表とするアジャイル開発も、今後時間がかかっても、イテレーティブな開発プロセスの一つの例として普及するだろう。

アジャイルな開発プロセスの最大の特徴は、要件定義からリリースまでの短い期間で少しずつ開発していくこと。
このサイクルの単位がイテレーションと呼ばれ、小規模リリースというXPのプラクティスの一つにもなる。

アジャイルな開発プロセスの最大の利点は、重大な問題の早期発見。
要件漏れ、設計漏れ、あるいは、ビルド作業での重大な問題は、早期のリリースのタイミングで発見できる。
更に、顧客の要求が変更されても、次のイテレーションへ混ぜ込むことによって、システムへ反映できる。

しかし、最大の弱点は、イテレーションを管理するツールがないこと。
イテレーション計画は流動的なため、細かなタスク変更が多く、リアルタイムな進捗管理が難しい。

また、リリース後も機能追加や継続的なリファクタリングなどで、頻繁にソースが修正される。
更には、リリース後に稼動中の本番モジュールと、裏で開発中のモジュールの2つのコードラインが生きているため、バグ修正と機能追加が混在して、品質を維持するのが難しくなる。
つまり、高度な機能の構成管理ツールを必要とする。

もう一つ、XPが指摘した重要な点は、SW構成管理に関するいくつかのプラクティス。

ソース共同所有で、ソースのバージョン管理を再認識させた。
コーディング規約やペアプログラミングでソースの品質について再認識させた。
テスト駆動開発で、プログラマは、仕様をテストできる形でプログラミングするようになった。

そして、継続的インテグレーションで、コミットしたコードラインは、TestUnitで単体テストをクリアすることも含めて、常時リリース可能な品質を保証できるようになった。

そのおかげで、短期間のイテレーティブな開発スタイルが可能になる。

XPはScrumと異なり、マネジメント側面だけでなく、SW構成管理の側面も重視している。
その部分は、実は意外と意識から漏れていないだろうか？

【チケット駆動開発の意義】

チケット駆動開発のルーツは、BTS(バグ管理システム)。
古くは、Bugzilla、Mantis。

BTSは本来、障害管理に昔から使われていたが、このワークフローがとてもスムーズな為、障害だけでなくSW開発の一般タスクへ汎用化しようという発想が生まれた。
TracやRedmineは、チケット管理をメインとして、ガントチャート生成やバージョン管理との連携機能によって、プロジェクト管理機能を持つBTSを課題管理システム(Issue Tracking System)へ昇華させた。

そして、まちゅさんは、Tracのチケット管理からチケット駆動開発(Ticket Driven Development：TiDD)を提唱された。
まちゅさんの本来の主張は「チケット無しのソースコミット不可」。

このチケット駆動開発のアイデアを突き進めると、イテレーティブな開発を補完するアジャイルな開発プロセスであることが分かる。

チケット駆動開発の基本アイデアは、さかばさんによると、「BTSのチケットはXPのタスクカードと同じ」。
XPでは、アナログのタスクカードでPostItなどで運用する。
チケット駆動開発では、チケットとしてタスクカードをデジタル化する。

チケットは作業指示書でもあるから、ステータスや進捗率を入力すれば、リアルタイムに作業状態を追跡できる。
更には、作業開始・終了日、予定・実績工数を入力すれば、ガントチャートを自動生成できるから、進捗管理に使える。
チケットは本来、バグ報告票でもあるから、バグ修正に関するチケットの集計結果から、信頼度成長曲線を作成して、品質管理に使うこともできる。

つまり、プロジェクト管理をチケット管理に置き換えることによって、プロジェクト内部の作業全てをリアルタイムにモニタリングできる。
チケット入力の運用さえきちんとできれば、イテレーション計画の頻繁な変更もコントロールできる。

更には、チケット集計結果やSVNリポジトリ統計のメトリクスを、プロジェクト運営の意思決定の材料として出力できる。

もう一つは、メインラインモデルと言う構成管理の発想。
メインライン(trunk)とそれから分岐したコードライン(branch)によって、本番運用モジュールと開発中モジュールの2つのソース管理を使い分ける。

メインラインモデルの利点は、バグ修正と機能追加という相矛盾した開発での品質を確保する。

本番運用モジュールはbranchとして管理し、障害修正のみ反映する。
開発中モジュールはtrunkとして管理し、機能追加して、いつでも最新機能を持つ。
当然、バグ修正のマージ作業はその都度、本番ブランチからtrunkへ反映させる。

このソース管理手法は、偶数バージョンは保守コードライン、奇数バージョンは新機能追加のコードラインと使い分けるRubyのように、多くの実践例がある。

但し、弱点は、マージ作業が発生することだが、Subversionならmergeコマンドによる自動化やマージトラッキング機能などで、マージ作業のコストは格段に下がりつつある。

【チケット駆動開発の新たな利点】

チケット駆動開発とメインラインモデルの組み合わせによって、SW構成管理に別の要素、変更管理の観点が出てくる。
これは、リファクタリング・バグ修正・機能追加など混在した修正理由による追跡が可能になったこと。

システムの大規模化によって、わずか1行のソース修正であっても、検証コストは大きくなる。
ソース修正の影響範囲が確定できなければ、安易にパッチを当てることもできない。

しかしながら、チケット駆動開発のインフラのおかげで、

「ソースAの修正で影響を受けた過去のソースはどれか？」
「バグXの修正はビルドYに反映されているか？」

の追跡が可能になる。

更には、メインラインモデルのインフラのおかげで、バグ修正と機能追加は別々のコードライン上で行うから影響範囲を狭められる。

上記の運用によって、ソースからリバースして設計するのが非常にやりやすくなった。

昨今のSW開発では、RailsやSeasar等のフレームワーク、JUnitなどのTestUnitによって、単体テスト品質は維持できる。
更に、継続的インテグレーションのおかげで、常時リリース可能なコードラインを保障できるインフラもある。
しかしながら、設計者が作る肝心の仕様書の品質が非常に低い。

その理由の一つは、動くプログラムもできていない時の要件定義や設計には必ず重大な漏れが発生しやすいこと。
これは、短期間のイテレーティブな開発で、早期に失敗を発見することで対応可能。

もう一つは、アジャイル開発によって、仕様書にも頻繁な修正が入り、その整合性を保障するコストが大きいこと。

仕様書を作るSEのモデリング力にも問題があろうが、SEの本来の仕事は、顧客の要望から本来の要求を吸い上げて、システムの論理的整合性を保障するのがお仕事。
一つの仕様の変更が他の機能にどれだけ影響を及ぼすのか、考慮できるインフラも必要。

その時に、変更管理のインフラがあると、例えば、過去のパッチの経緯から今回の修正では別の機能にも影響があるとか、今回の仕様変更で上がった別のリスクは既に過去のパッチで反映されているので対応不要、などのような回答を見つけることができる。

SEとは、要件や仕様の変更管理に関する仕事が実は非常に大きいのだ。

【チケット駆動開発の可能性】

チケット駆動開発は、XPのタスクカードをチケットへデジタル化することによって、下記の新しい視点をもたらした。

・バグ修正や機能追加、仕様変更などの新たなワークフローを定義できる
・チケット集計結果から、ソフトウェア・リポジトリ・マイニングによって有用なメトリクスを出力できる
・進捗、品質をリアルタイムに計測できるため、プロジェクト運営の意思決定の材料として使える
・ソースの変更をチケットと関連させることによって、ソースの変更理由が追跡可能になる

今、僕が持っている疑問点は、XPのストーリーカードは、チケット駆動開発のどの機能に配置されるべきなのか？という問い。

変更要求を親チケットに書いた時、更に細かな作業は子チケットとして分割されて、チケットの親子関係が発生する。
その場合、チケットの親子関係をどのように表現したら、プロジェクト管理で使い物になるのか？

この問いは、究極的には、要件管理に辿り着く。

チケット駆動開発は、SW構成管理に変更管理という観点をもたらした。
今は下記のトレーサビリティを保障するインフラまで作れる。

TestLinkのNGのテストケース
→Redmineのバグチケット
→修正ソースのSVNリビジョン
→Hudsonのビルド番号

しかしながら、要件は一体どこに配置すべきなのか？

今、試そうと思っているのは、TestLinkの要件管理機能。
TestLinkには、要件のCSVをインポートして、テストケースと紐付ける機能がある。
テスト実行後、テスト結果の画面で、要件がテストケースをどれだけ網羅しているか、更には、要件に紐づくテストがどこまで消化されているか、表示する機能がある。

この要件網羅の機能があるので、この機能を使って、W字モデルのような開発を行いたい。

すなわち、要件定義や設計工程で仕様書を作ると同時に、テスト計画やテスト仕様書も作り、そこで要件漏れや設計漏れをあぶり出したい。

丁度、テスト駆動開発が、テストプログラムを先に作ってから実装するように、テストケースを書きながら仕様書を作るようにすれば、検証可能にならない仕様は問題点として、はっきり出てくるだろう。

残念ながら、TestLinkのver1.7.4の要件管理機能は現場で使えるレベルではない。
しかし、ver1.8からXML-RPCが使えるので、RubyやPHPのプログラムでTestLinkを操作して、要件とテストケースのアサイン、更には要件カバレッジ出力を試している方もいる。

下流工程の構成管理は、オープンソースの各種ツールが揃ってきた。
目指すは、上流工程の成果物の品質Upのために、構成管理のインフラを整えることだ。