チケット駆動開発の参考書「Redmineによるタスクマネジメント実践技法」

ソフトウェア開発 Trac 本

Tracを使い始めたきっかけは、情報共有用のWiki(PukiWki)、障害管理（影舞）、ソースコードビューワ(ViewVC)というツール類を一つに統合出来ると分かったからだ。元々、リポジトリ内のソースコードや障害情報をウェブブラウザ経由で参照していたのだけど、それらのURLリンクを辿って、例えば「障害情報からソースコードの該当箇所を参照」したり、「打合せ時にソースコードの該当箇所を参照」するようにしたら便利だと分かり、あちこちにリンクを貼りまくった記憶がある。当時はこんな素朴な仕組みでも快適に使っていたのだ。

しかし、一旦Tracを知ってその便利さに慣れてしまうと、もう元のツールには戻れなくなってしまった。Wikiからソースコードやチケットへのリンクが容易に作成出来て、マイルストーン毎に何の作業がどれだけ残っているのか「見える化」可能なのだ。こんな便利なツールは他に無い！と判断して、さっさとTracへ移行してしまった。それ以来、BTS本来の目的である障害管理だけではなく、議事録や仕様書の作成、マイルストーンでの工程管理など活用領域を他にも広げ、今ではTrac無しのソフトウェア開発なんて考えられないほどになっている。チケット駆動開発(TiDD)という言葉を知ったのはかなり後になってからだけど、その基本的な考え方が自分たちのやり方と良く似ていることに気づいて驚いたこともある。

そんなチケット駆動開発の方法論が包括的にまとめられたのが「Redmineによるタスクマネジメント実践技法」だ。単なるツールの紹介だけではなく、そのツールを如何に使いこなして日々の業務を回していくか、チケットを中心に開発プロセスをどのように改善していくか、という点が著者の経験を交えて細かく説明されているので、Redmineを導入してこの書籍をマニュアル代わりに使えば、直ぐにチケット駆動開発を実践することが可能だ。Excel文化からいきなり移行するのは難しいかも知れないけれど、少しでもウェブベースのBTSを触った経験があるのなら、それほど違和感なく取り組める方法だと思う。

このような「自分たちの手で現場の業務改善を図る」というのは昔から工場などの生産現場では良く行われており、そのような流れがようやくソフトウェア開発の現場に入ってきたことは素直に歓迎したい。ソフトウェア開発の現場では、仕様書や障害情報などを何でもExcelのファイルへ入れて管理することが多くこのようなツールの価値を軽視する傾向が強いけれど、そんな非効率的なチーム運営は、RedmineやTracという武器を使って効率良くラクして運営するチームには適わないのではないかという気がしている。開発現場の品質改善も開発者自身の手によりボトムアップの形で生まれているのだ。そんな優れたノウハウを自分の仕事に生かさないのは勿体ないことだと思う。

なお、書籍の中ではRedmineがメインに取り上げられていてTracが劣勢（のように見えるの）だけど、私自身はTrac派なので（だからブログではTracに関するエントリが多い）少しだけ援護すると、プラグインの追加や運用の工夫によってRedmineとほぼ同等のことが可能であり、ツールの差異は本質的な問題ではないと認識している。どのようなツールも得手不得手の領域があるので、互いに比べた上で自分たちに合ったものを使えば良いと思う。*1

Redmineによるタスクマネジメント実践技法

Redmineによるタスクマネジメント実践技法


関連

*1:Redminならチケット駆動開発が出来るけどTracでは出来ないという趣旨の発言を聞いたことがある。これはチケット駆動開発の本質を理解していない証拠だと思う。