現代のチケット駆動開発ではどこに課題があるのか？ #redminet #redmine
僕が2008年に「Redmineでチケット駆動開発を実践する～チケットに分割して統治せよ 」をKOFで発表してからもう15年以上経った。
現在地点では、チケット駆動開発をベースとしたソフトウェア開発は、アジャイル開発であれ、WF型開発であれ、たぶん当たり前になっているだろう。
Redmineでチケット駆動開発を実践する～チケットに分割して統治せよ | PPT
では、現在地点におけるチケット駆動開発の課題は何があるのだろうか？
チケット駆動開発のどこに問題が起きているのだろうか？
僕個人の考えでは、2つの問題があると思う。
1つ目は、チケット駆動開発がマイクロマネジメントのツールに化してしまっていること。
もう1つは、大規模チームでチケット駆動開発を運用するノウハウがまだ蓄積できていないこと。
前者の問題点は、伊藤直也さんがツイートされている。
Xユーザーのnaoyaさん: 「タスクを細かく洗い出してチケット切って開発みたいなの、自分は基本的に信用してない マイクロマネジメントで作業者から自分で物事を考えて進める思考や責任を奪ってる」 / X
Xユーザーのnaoyaさん: 「2週間とかの期間がある中で、どこで本気出すかは各々の自由だしそれはコントロールできるものでもない マイクロマネジメントはその裁量を奪うだけだ」 / X
本来のチケット駆動開発は、タスク管理をプロマネから開発者へ権限委譲し、開発者自身がアジャイル開発をベースにタスクを消化していくことで、ソフトウェアを開発するスタイルだった。
開発者の自主性を引き出す効果があった。
しかし、チケットをWBSとみなせばWF型開発にも適用できるので、プロマネが計画時点でPJ計画書に基づいてWBSをチケット化して開発者に押し付ける運用も多く見かける。
つまり、開発者がタスクを考える必要もなく、プロマネがチケットを担当する開発者をマイクロマネジメントするための道具になってしまった。
すなわち、開発者がシステム開発するためにタスクを詳細化していく思考を奪ってしまい、単純労働者の地位に押し付けられている。
こうなってしまうと、チケット駆動開発はアジャイルさを失い、ガチガチのマイクロマネジメントの道具になってしまっている。
そこから脱出し、本来のチケット駆動開発の良さを引き出すには何が必要なのか？
後者の問題は、大規模なチケット駆動開発により、管理の複雑性が増していることに起因しているのだと思う。
元々、チケット駆動開発は数人レベルの小規模なチームによる開発経験から生まれた。
だから、少人数で俊敏に開発するアジャイル開発と親和性が高い。
そこから、アジャイル開発のプラクティスを取り入れると開発が上手くいくことが分かり、チケット駆動開発のプラクティスやアンチパターンも色々分かってきた。
また、チケット駆動開発は元々柔軟なワークフロー管理機能を持つので、ITILによるソフトウェア保守、情シスのタスク管理、システム監査、カスタマーサポートなどにも適用できる。
つまり、色んなプロセスをチケット駆動開発で実現できる。
そこが、チケット駆動開発の面白さの一つだと思う。
しかし、チケット駆動開発の適用範囲が広がり、ユーザ数やチケット数が膨大に増えていくと、複雑性が増して、単純な運用ルールだけではじきに手が負えなくなる。
大規模なチケット駆動開発では、複雑性を制御するために、何らかの標準プロセスの実装が必要になってくるのだと思う。
では、大規模なチケット駆動開発による複雑性は、どのように解決すればいいのか？
Redmineコミュニティで今までに語られたアイデアの一つとしては、Redmine警察やRedmine職人のような役割を設けたり、定期的な棚卸し会を運用するなど、組織として運用する仕組みを作ること。
他には、大規模アジャイル開発のフレームワークであるLeSS、SAFeなどのアイデアを参考にして、チームやプロセスを階層化して管理する手法もあるだろう。
2つのテーマに関するこの辺りの問題点、解決法を整理してみたいと思う。
