[#TiDD] チケット駆動開発はプロセスを軽量化する

かつてアジャイルと言えばXPだったころ、従来法とアジャイルの比較として

「ヘビーウェイトプロセスとライトウェイトプロセス」

という表現が用いられることがありました。ヘビーというのは機敏でないという意味もあると思いますが、管理プロセスが肥大したという意味合いもあったと思います。

１．なぜ管理プロセスは肥大しやすいか

従来法の重さは、肥大化した管理プロセスにあります。メトリクスに関してもバシリ先生のGQMでは計測はトップダウンで行われるべきであり、

計測のの目標があって、その目標を遂行するために尺度が定義され、計測が行われなければならない
* 楠本 真二, “ソフトウェアメトリクスの研究動向,” 第4回エンピリカルソフトウェア工学研究会, 2004. (PDF)

とされています。不要なメトリクスを集めるべきではありませんし、不要な管理ルールも冗長なだけです。しかし、「アジャイルと規律」でベーム先生が

「熟練していない人たちは、安全策をとってすべてを取り入れ」(P.189)

と書かれているように、検討されたメトリクスや品質プロセスの多くは、取り入れられることはあっても、削られることはなくプロセスが肥大化してしまいます。もちろん、大切なノウハウは実践されるべきですが、存在しないリスクの確認を手間暇かけることに多くの労力を割くことはないでしょう。

２．肥大化した管理プロセスの問題

このように管理プロセスの肥大化により、以下の3つの問題が生じます。

a) 管理作業の集中によるプロジェクトが鈍重になる

TSPガイドブック:リーダー編にアイアコッカの「ボスのスピードがチームのスピード」(p9)という言葉が出ていますが、管理作業が増えるとリーダーがボトルネックになり、プロジェクトの機敏さがなくなります。

b) 管理データの増加

プロセスが肥大化すると、管理のためのドキュメントも増えます。同じようなデータが、ミーティングや報告経路の種類によって様々な観点で利用されます。これらのドキュメントを作成するには、データ収集、集計、報告作業が大変です。

c) 情報の遅延

肥大化した管理プロセスの多くは、紙のコピーやExcelファイルのメール送信で配られます。データの収集、集計、さらにそれをもとにした報告書をリーダーが作成するまで報告されません。また、報告は組織構造を下から上に順次行われることから、時間的にずれ他データが報告されます。そこで、

• 新しい問題が報告されていない
• 最新の状況が確認できない
• 解決した問題の確認や検討をしてしまう

といった問題が生じてしまいます。もちろん報告にはスナップショットという面もあるのですが、最新の状況が確認できるに越したことはありません。

３．チケット駆動開発はプロセスを軽量化する

チケット駆動開発は以下のようにプロセスを軽量化します。

a) 管理作業の分散

進捗管理や障害管理では、口頭あるいはメールでのデータ収集、エクセルによる集計・グラフ化、ファイルの共有あるいはメールによる報告といった管理作業が必要です。BTSを用いるチケット駆動開発では、データ収集は担当者がチケットを更新し、自動でガントチャートが更新され、マイルストーンやサブタスクの進捗を自動で集計します。つまり、管理作業は純粋に管理することだけになるのです(チケット更新の作業のうち一部を管理者だけの権限にしておくことも可能です)。

b) データの一元管理

同じようなデータがあり、収集、集計、報告が大変というのは、データが正規化されていないからです。"One fact in one place"のルールに従って基本的なデータを一元管理し、推移従属なデータをその都度作成すれば、このような負担はなくなります。BTSは必要な情報は抽出条件を指定して一覧で参照できますし、よく使うレポートはあらかじめ定義しておけば、定型業務の報告として利用できます。

c) リアルタイム

データは報告書と独立して、その時点のデータをリアルタイムに参照できます。報告書が順次送られる場合でも、新しい問題を含めた最新情報が参照できますので、すでに解決したことを知らず状況を確認したり、解決策を検討することもないでしょう。

４．従来法にもアジャイルにも

このようにチケット駆動開発は管理プロセスを軽量化します。これは管理プロセスを削減するのではなく、現状の管理プロセスそのままで、作業の分散、一元化、自動化によって効率化するものです。これはチケット駆動開発の大きな特徴です。

今回は触れませんでしたが、アジャイル開発においてもチケット駆動開発は有効です。アジャイルは人間重視の観点から、タスクカードのようなアナログ情報が用いられています。タスクカードはとても人間的で、進捗の見える化やスコープの変更などに有効です。しかし、電子化されていないことから、タスクカードの保存が困難なほか、構成管理ツールとの連携による履歴の検索も容易でなく、タスクボードという物理的な制約を受けます。チケット駆動開発はタスクカードをチケットに電子化するので、これらの問題を軽減してくれるでしょう。

最近のアジャイル2次ブームで、既存の管理とアジャイル開発を整合させる動きがあるようです。そのようなときにも、管理プロセスを肥大させない方法として、チケット駆動開発はきっと役立つでしょう。