[TiDD] チケット駆動開発の意義

方法論としてのチケット駆動開発の意義を考えてみました。

１．コンパクトな方法論

昔の方法論は今から比べるとコンパクトなものでした。構造化設計ならトップダウンにはトランザクション分割、ボトムアップにはSTS分割があり、あとはモジュール強度とモジュール間結合度を考慮できれば基本的に十分でした。

最近の方法論はプロセスの議論と結びついているので、とにかく巨大で、実施するのが大変です。このため、方法論は巨大なプロジェクトで実施されますが、普通のプロジェクトではフレームワークや開発環境をベースにした開発スタイルあるいは思想の導入にとどまっていると思います。

チケット駆動開発は技術よりはライトウェイトなプロセスのルールが中心ですが、開発全体を統率できる可能性を感じています。

２．高付加価値ソフトウェアへの対応

かつてのアーキテクチャを重視していた頃は、アーキテクチャの実現に多くの工数が必要でした。近年はフレームワークを用いることで、少ない工数で高付加価値ソフトウェアを開発できるようになりました。

このことは、プロジェクトの管理を困難にしました。従来は開発規模は行数で見積もることが多かったですが、行数に比較して多くの機能が実現できる用になったので、行数による管理は困難になりました。

そこで、画面数や機能数を元に見積もることも増えました。しかし、機能数や画面数と必ずしも比例しない環境の構築や運用テストなどの存在がプロジェクト管理を難しくしています。

チケット駆動開発はプロジェクトをタスク数や工数といった直接的な尺度で管理しますので、近年の高付加価値ソフトウェアに向いていると思います。

３．オープン環境

かつてのプロセス改善では、ツールによってプロセスを自動化することが多かったものです。しかし、最近はツールが肥大化し環境になっていますので、プロセスが特定の環境に依存しやすくなっています。

しかしチケット駆動開発は、ツールへの依存度が低い方法論です。どちらかというとRedmineが向いているのではないか、という個人的な感想はあるものの、Tracの方が自由度が高くて良いといわれる方も
おられます。

このように、チケット駆動開発は特定のツールに依存しないので、将来、利用しているツールの開発が中断された場合も、(環境の移行は必要ですが)方法論を大きく変える必要がありません。ツールの購入費用も不要ですので、安心して始めることができます。

このようにまとめてみると「さすが開発現場で生まれた方法論だなぁ」としみじみと思いました。