チケット駆動開発の適用範囲part5～どの工程をカバーするのかという質問

チケット駆動開発を実践していると話すと、チケット駆動開発ではどの工程をカバーしているのですか、という質問をよく受ける。
考えたことをラフなメモ書き。

【1】「チケット駆動開発ではどの工程をカバーしているのですか」という質問は、マネージャやリーダーからよく聞かれる。
彼らの意図としては、ウォーターフォール型開発において、チケット駆動開発がどの工程にうまくはまるのか、どんな利点があるのか、を知りたがっているようだ。
特に、開発工程のタスク管理やテスト工程の障害管理以外に、要件定義や設計の工程でも使えるのか、という疑問があるらしい。

僕は、チケット駆動開発は特定の工程をサポートするわけではなく、プロジェクト管理全般をサポートしている、と回答するようにしている。
チケット駆動開発は本来、ソフトウェア開発のタスク管理をチケット管理に置き換えることで、プロジェクト管理をマネージャのようなベテランだけでなく、1年目の開発者でも体験できるような仕組みだと思っている。

ソース管理やビルド管理とチケット管理が連携することによって、チケットを起点としてソース修正からモジュールのビルド、リリースに至るまで、一括管理できる利点がある。
つまり、チケット駆動開発は、ソフトウェア開発のインフラに相当する側面がある。

【2】チケット駆動開発を開発者の観点で見ると、ToDoリストの管理に近い。
例えば、Redmineのチケット管理もそうだし、GitHubやBitbucketのIssue管理も同様だろう。

すると、ソースという成果物をソース管理のリポジトリで管理する時に、チケットに仕様変更や要望、障害報告を書いておけば、チケットが起点となってソースが修正されてブラッシュアップされていく。
つまり、チケットとソースが連携することによって、成果物と仕様変更を一括管理できる。
ここから「No Ticket, No Commit」という運用ルールが生まれている。

開発者の観点におけるチケット管理の運用においては、設計だけの工程、開発だけの工程、テストだけの工程はありえない。
一つのチケットで、どのような仕様で確定したのか、どのように修正したのか、リリース後のユーザの評価はどうなのか、という履歴が全て残る。
その意味では、チケット駆動開発はすべての工程をサポートしている。

【3】チケット駆動開発を管理者の観点で見ると、プロジェクト管理として使いたい要望が多い。
マネージャやリーダーとしては、進捗管理、品質管理、課題管理をRedmineのようなチケット管理ツールで、プロジェクトに関わる全てのアクティビティを管理したいのだ。
そうすれば、Redmineのチケットを常に監視することによって、プロジェクトがどんな状況にあるのか、をリアルタイムに把握することができる。

彼ら管理者としては、チケット管理ツールの進捗管理機能を強化して欲しいという要望が多い。
例えば、Redmineの最新版2.3においては、ガントチャートにMS ProjectのFS関係(先行・後行く)やイナズマ線を表示する機能が追加されている。

Redmine 2.3新機能紹介: ガントチャートでチケット同士の関係とイナズマ線を表示 | Redmine.JP Blog

上記の記事には「イナズマ線描画機能は 伊藤忠テクノソリューションズ株式会社 (CTC) 様のご協力により実現しました」という文言が記載されていて、大手SIの管理者がRedmineのガントチャートをもっと強化して欲しい要望を持っていた事実を示していると思う。

管理者としては、工数管理もチケット管理で代用したいものだ。
「チケット無しの作業は不可」(No Ticket, No Work)を運用しているならば、チケットに必ず予定工数と実績工数が記録されるので、後から集計可能になる。
そうすれば、EVMの仕組みを使って、CPIという開発ペースを計算して総コストを予測することも可能になる。

管理者の観点では、チケット駆動開発はメトリクス収集ツールという側面がある。
管理能力の優れたマネージャは、単なるプロジェクト運営だけでなく、プロジェクト終了後にメトリクスをきちんとまとめておいて、そのノウハウを他のプロジェクトへ適用したり、自分の研究材料に使ったりしている。
つまり、できるマネージャはきちんとPDCAサイクルを回していて、特にCheck、Actionの部分が優れている。

【4】チケット駆動開発の弱点はいくつかある。

まず、チケット集計というビューが弱い事実があると思うが、個人的には、RedmineのようなRailsアプリならば、不足した機能はRubyで実装すれば良いという問題に置き換えられると思っている。
プロジェクト管理の問題をプログラミングの問題にすり替えることによって、もっと色んな手法が試されるべきだと思う。

また、チケット駆動開発のロールは管理者・開発者・報告者という障害管理ツールの名残りがあるために、Scrumのようにユーザを巻き込んで、開発チームとユーザ、プロジェクトマネージャのバランスを保つ仕掛けは実装されていない弱点がある。
でも、顧客自身に仕様追加や障害報告をチケット登録するような運用ができるならば、チケット上で顧客と開発チームが相互対話する環境が整うので、顧客を巻き込んだ開発スタイルは可能のはずだ。
ITILのようなインシデント管理・問題管理・変更管理プロセスに当てはめれば、多分うまくいく部分があると思う。

それから、チケット駆動開発はアーキテクチャ設計やテスト管理には有効ではない。
テスト管理にはTestLinkなどのようなテスト管理ツールが必要だろうと思っている。
アーキテクチャ設計は、プロジェクト管理とは別のスキルが必要だ。

最近アジャイル開発がソフトウェア開発で有効と思われている理由の一つは、ソフトウェアのアーキテクチャ設計で絶対のベストプラクティスが存在しないために、その時代の技術を使って試行錯誤しながら作っていかざるを得ない事実があると思う。
つまり、アーキテクチャ設計ないしソフトウェア工学が分野として不十分ないし弱いために、アジャイルという開発プロセスでその弱さを代用している面があると思う。

その辺りはもう少し考えてみる。