チケット駆動開発を導入しても変わらないこと

ソフトウェア開発

Tracのようなツールを導入してチケット駆動開発を始めた人から必ず聞かれる質問の1つに、下記のようなものがある。

「チケットの数が多くて管理出来ません。やっぱりチケット駆動開発は無理です」

確かに、やること、やらねばならない事を片っ端からピックアップしてチケットへ放り込んでいくと、小さなプロジェクトでもあっという間にチケットの山が出来てしまう。沢山のチケットが並んでいるレポート画面を見るだけでも嫌になるし、ウンザリした気分にさせられるのは確かだから、このような拒否反応を示すのだろう。

でも、良く考えてみれば、これは少々変な話しだ。チケットで表現されている内容は、本質的にチケット駆動開発とは何ら関係の無く、従来からプロジェクトの中には存在していはずだ。今までの作業の中で、例えばWBSのような形でタスクの管理を行って来たのであれば、チケットは単にその形が変わっただけのものだから、チケットの数は「今までと同じ」はずだ。

今までそのようなタスクの分解・抽出を行っていなかったのであれば、チケット化することで初めて顕在化した問題であり、それこそがチケット駆動開発の導入でメリットだろう。埋もれていたタスクを引っ張り出してきたのはチケットの功績であり、チケット駆動開発自体には何の問題も無い。チケット駆動開発の導入により「従来よりもやることが増えた」と感じるのは実は誤解であって、今まで適切なタスク管理が出来ていなかった証拠ではないだろうか？

だから、冒頭の質問を受けた時には、こんな確認を行うようにしている。

  • 今まで、どのようなタスク管理方法を取っていたか？WBSのようなものを作って管理していたか？
  • 今までWBSで管理していた内容、項目数と違うか？もし違うのなら、その理由は何か？
  • メールや口頭でやり取りしていた、暗黙の作業をチケットの形で表現したのではないか？

WBSのように「最初に力を入れて作る割に、日々の更新が滞ってしまい、現場の実情と乖離してしまう」状況を改善するのがチケット駆動開発の目的の1つなので、チケットが増えて困るというのなら、それはプロジェクト運営として他に原因があるように思う。そのような本質的な問題を放置した状態でチケット駆動開発を導入しても、上手く運営できないのは自明のことだと思っている。