[#TiDD] チケット駆動開発で気付いたアジャイル開発の仕組み

アジャイル開発とはなにか？それは聞く人によって大きく変わります。このため、本に書かれたそのままに実施したつもりでもうまくいかないこともあるでしょうし、開発チームの制約に合わせて実施する場合には危険が伴います。恥ずかしなが失敗したからこそ気づいた「チケット駆動開発に隠れたアジャイル開発の特徴」を説明します。

１．ライトウェイトプロセスだけではない！

2000年から始まったアジャイル1次ブームでは、1990年代半ばからブームであったCMMとの比較で語られることが多かったように思います。

よく言われたのは、無駄を排除した「ライトウェイトプロセス」という特徴です。ドキュメントは必要最低限にして、コード中心にプロジェクトを運営する。進捗管理もタスクボードで、計画済み、実行中、完了と3つのステータスのみで管理される。当時、とてもショッキングなプロセスでした。

ケントベックさんの白本(最初のXPの本)が(私には)わかりにくく、スクラム・ブートキャンプも無い時代とはいえ、ライトウェイトプロセスと言う特徴に、私は強く興味を持ってしまいました。

２．恥ずかしい失敗事例

XPがブームになったころ、たまたま研究開発プロジェクトを担当することになり、真似事をしてみることにしました。当然のことながらタスクボードを用意しなければいけないのですが、会議用のホワイトボードはあるものの占有もできず、空いている壁もありませんでした。

そこで考えたのが、機能的に同等のものを用意することです。機能を考えてみました。

・タスクボードの情報はみんなで共有できる
・タスクは3つのステータスで管理される

思い浮かんだのは、たったこれだけです。そこで、ファイル共有サーバを用意して、左にタスク、右にステータスを示す3つの欄を持つエクセルシートを置きました。タスクの一覧の作成後は、みんなでレビューしました。

タスク名	ToDo	Doing	Done
XXの開発		〇
YYの開発	〇

結果は最悪でした。

・タスクが荒くて進捗が見えない
・めったに更新しないので、誰も参照しない
・リスクが高く、だらだらした開発

当時はアジャイルの親切な本もなく、アジャイルの良さとしてタイムボックス管理によるスコープの変更がようやく知られるようになった頃でしたので、なぜ失敗したかも良くわかりませんでした。

その後、@agilekawabataさんと出会い、XPのプラクティスに関する論文を書いたり、XP祭り関西の2006のスタッフなどをして理解を深めましたが、それぞれのプラクティスと繰り返し開発のメリットは感じたものの、過去の失敗の原因としてピンとくるものはありませんでした。さらにしばらくして@akipiiさんと出会い、聞きかじったチケット駆動開発を実践することで、ようやくアジャイル開発の仕組みに気付いたのです。

３．チケット駆動開発で気付いたアジャイル開発の仕組み

チケット駆動開発を簡単にいうと、タスクボートとタスクカードを、障害管理ツールの一覧とチケットで実現したものです。通常の障害管理ではチケットを障害(バグ)票として使いますが、チケット駆動開発では細かな作業も備忘録のようにチケットに記述していきます。他人の作業も登録できますので、時には作業指示書にもなるものです。

実践してわかったのは、以下の様なメリットです。

コミュニケーション
タスクカードであるチケットがコミュニケーションの中心となっていました。チケットは備忘録、作業指示であると共に、作業に関するコメントの書かれた掲示板でした。チケットとソースコードを関連づけることで、ソースの修正理由をチケットの履歴によって知ることができましたので、問題が発生した際にソース解析の参考になりました。

集中
開発中に発生した仕様変更や、問題の発生によって増えた作業も、直接指示されるのではなく、チケットを介して指示が行われるようになりました。担当者は都合の良い時に自分の担当するチケットや自分が報告したチケットを確認すれば良いので、作業に集中できるようになりました。

リズム
チケットがプロジェクトの中心になると、日々の朝会の前後には担当のチケットを確認するようになりました。チケットを確認しながらその日の計画を立て、1日の作業の後に司直を更新する。そんな日々のリズムに慣れると、作業が快適に感じるようになりました。

これらは、以前失敗した際には気付かなかったアジャイル開発の仕組みによって実現できました。それは、以下のような仕組みです。

・情報が一元化されるとチケットに依存する
・チケットの粒度が細かいと、日々の確認が必要になる
・チケット確認を中心とした開発のリズムが生まれる

これらは仕組みというほどでもないかもしれませんが、あまり説明されていないのではないでしょうか？アジャイルは実践重視ですので、これらは経験の中で習得されていくのかもしれません。このような仕組みを理解しないまま、タスクボードを機能的にとらえてしまったので、恥ずかしい失敗をしてしまったのだと思います。

４．チケット駆動開発はアナログを超えるか？

これはプロジェクトによると思います。アナログは情報量が多く、一目で多くのことを知ることができます。かつて私が失敗したのは、エクセルで一目でわかる範囲にタスク分割したからで、もっと画面が広ければ進捗がわかる程度にタスクを分割したかもしれません。

チケット駆動開発は、情報量の少なさをデジタルの特徴で補います。様々な条件でチケットの一覧やグラフを見ることで、担当チケットやガントチャートなど状況に応じた情報を一目で見ることができます。また、ワークフローや構成管理ツールとの連携といった、デジタルならではの特徴によって欠点を補っています。ステータス変更の際に何らかのチェックの必要な場合や、派生開発など過去の履歴を参照するようなプロジェクトには有効でしょう。

５．まとめ
アジャイル開発は一部だけを導入しようとしてもうまくいかないと言われることがあります。それは、ここで述べたような仕組みが隠れているからではないでしょうか？チケット駆動開発は、アジャイル開発の一部をデジタル化するだけでなく、さらに強化したものです(強化したものの一つに“No ticket, No comit!”のようにチケット駆動開発独自のルールもあります)。チケット駆動開発にあるアジャイル開発と類似の方法に関しては、アジャイル開発が参考になりますし、私のようにアジャイル開発がピンとこなかった人にはアジャイル開発の仕組みを考えさせるきっかけにもなるでしょう。

アジャイル開発にあこがれながらも何らかの事情によってできないのなら、チケット駆動開発を検討されてはいかがでしょう。