プログラマの思索

@nobiinu_andさん、@two_packさん、@naitohさん、@haru_iidaさんと第0回関東Redmine飲み会を開催しました。
Redmineに関するマニアックなお話ができて楽しかったです。
またこういう機会を作りたいなと思っています。

皆と話していて、Redmineの背後にあるチケット駆動開発の面白さについて考えたことをメモ。

【1】チケット駆動開発は、Tracのチケット管理の経験を元にまちゅさんが提唱された。

チケット駆動開発 … ITpro Challenge のライトニングトーク (4) - まちゅダイアリー(2007-09-07)

チケット駆動開発(TiDD)が障害管理(BTS)や単なる課題管理(ITS)と異なる点は二つある。

一つは、「No Ticket, No Commit!」と呼ばれる運用ルールでチケットに構成管理情報を付与することで、ITSとSCMを連携する機能に着目したこと。

もう一つは、「Ticket First」「No Ticket, No Work!」と呼ばれる運用ルールでソフトウェア開発のプロジェクト管理をチケット管理に置き換えることで、マネジメントの問題をプログラミングで解ける問題に変換できること。

【2】前者は、OSSのツールを連携することによって、新しい使い方が判明して、その使い方によってソフトウェア開発の生産性が大きく上がる事実を示している。

RedmineはSVNが同一サーバー上だけでなく他サーバーへリモートで接続可能という機能のおかげで、チケットとSVNコミットログを簡単に連携できる。
そして、SCM連携と呼ばれるRedmineの機能によって、要件や仕様からチケットを経由してソースのリビジョン、更にはビルドモジュールまでのトレーサビリティを実現できる。
トレーサビリティによって、過去のパッチの変更理由を追跡できるだけでなく、現在修正中のソースが過去のチケットでどのような変更履歴を持つのかを調べることによって、ソースの意図をより深く理解することも可能になる。
従来のAgile開発、ひいてはソフトウェア開発では実現できなかったトレーサビリティという性質によって、ツール上で厳格な変更管理を運用することも可能。

つまり、トレーサビリティという性質は、ITSとSCMの連携によって生まれたが、同様に他のツールとITSやSCMが連携することによって、新しい使い方を発見できる可能性がある。

@haru_iidaさんは、ITS・SCM・CIの三つのツールを「ソフトウェア開発の3種の神器」と呼んで、ツール同士の連携でソフトウェア開発のインフラを拡張できることを示唆されている。
又、古いツールを使って新しい使い方で利用する現象を、上田さんは「チケット駆動開発はAjaxみたいだね」と話されて、なるほどと思った時がある。
僕は、Redmineの対象バージョンをXPのイテレーションと同一視する運用によって、初めて自然にAgile開発を経験できた。

ITS・SCM・CIだけでなく、テスト管理や品質管理、コードレビューのツールも連携できれば、新しい使い方を見つけることができて、更に開発の生産性を高めることができるだろう。

【3】後者は、ソフトウェア開発のプロジェクト管理を主導する役割がマネージャからプログラマへ移ってきた事を示唆している。
ソフトウェア開発をツールでサポートする発想は従来から試されており、そのようなツールも販売されたり、ツールとセットで開発プロセスが提唱されたりした。
IPA(情報処理推進機構)も昔から、メトリクスを収集するツールはフリーで公開している。

EPMツール：情報処理推進機構：ソフトウェアエンジニアリング

しかし、結局普及しなかったのが現状ではなかろうか？

普及しなかった理由は、ツールそのものが使いづらい点もあるが、「上から目線」の発想にあると思う。
下記のBlogに書かれているように、PMOや品質管理部門が開発チームを教育しようという発想が根底にあり、現場の開発者が顧客(マーケット)であるという発想がそもそもなかったのが最大の原因だったのだろうと思う。

ＰＭＯとプロジェクトマネージャ｜HATのブログ

「プロジェクトが遅れない理由」も数値化できる － ＠IT情報マネジメント

チケット駆動開発はTracのチケット管理から生まれた経緯もあって、現場の試行錯誤の中から生まれた開発プロセス。
だから、開発者が作業しやすいように、作業履歴を残しやすくしたり、タスクとソースのコミット情報を連携したり、進捗が分かるような仕掛けがITSに自然に実装されている。
チケット駆動開発は決して、PMOや品質管理部門、あるいは高尚な理論から生まれたアイデアではない。

チケット駆動開発では、SCMと連携する機能を持つITSをソフトウェア開発のタスク管理へ適用すると、スコープ管理をAgile開発のイテレーション管理へ置き換えたり、タスクの順序入れ替えをチケットの取捨選択に置き換えるなど、まさにXPの計画ゲームっぽいことが簡単に運用できる。

そして、マネージャや開発者から寄せられる苦情や改善要望は、ITSの一機能として実現すればいい。
特に、進捗報告や課題一覧は、マネージャやユーザの観点と開発者の観点で大きく異なるけれど、その問題はチケット集計機能というビューを使い分けることで解決できるはず。

チケットの粒度と進捗ビューの関係: プログラマの思索

チケット駆動開発は進捗報告作りをどのように解決しようとするか？: プログラマの思索

Redmineが使いづらいと言う質問～開発業務をRedmineへマッピングできていない: プログラマの思索

プログラミングに携わる者としてチケット駆動開発が面白いのは、ITSの機能にベストプラクティスが含まれているため、その機能に慣れると自然に良い習慣が身に付くこと。
逆に言えば、ソフトウェア開発で利用するツールが古いと、最新のベストプラクティスが使えないために、開発の生産性が停滞してしまうこと。
つまり、より拡張された概念であるソフトウェア構成管理のツールがソフトウェア開発の作業手順、プロセス、生産性に制約をかけているのだ。

Excelのプロジェクト管理から脱却せよ～SW構成管理を見直そう: プログラマの思索

ソフトウェア構成管理がソフトウェア開発の作業手順に制約をかける: プログラマの思索

構成管理のアンチパターン～TiDD初心者が陥りやすい罠 #tidd: プログラマの思索