[TiDD] チケット駆動開発における生産性、リスク、品質の考慮

てふかんで紹介のあった平鍋さんの講演紹介記事に

いまアジャイル開発に注目すべき理由として、平鍋氏は「従来のウォーターフォール式開発では要求が劣化することが問題」と指摘した。ウォーターフォール開発では、発注してから納品するまでに時間がかかる。開発している期間中に市場環境が変化すれば、欲しかった機能そのものが不要になってしまう可能性がある。実際、システム全体の60％以上が「使われない機能」であるという。

と書かれていました。これを読んで、なるほどと納得しました。それと共に、1990年頃に受けたインフォメーションエンジニアリング(IE)のセミナーを思い出しました。IEはIEFという自動生成ツールでプログラムを生成する開発法です。受講者から「自動生成であっても仕様は入力しないといけないはずだが、なぜ生産性があがるのか？」という質問があり、その回答がパレートの法則、いわゆる2割8割の法則でした。

パレートの法則は「2割の問題により8割の影響がある」というものですが、仕様で言うならは、たった2割の仕様が8割の工数を占めると言うことになります。セミナーの際の詳細な回答は忘れましたが、8割の工数を占める2割の仕様をツールでサポートすると言う意味だけでなく、8割の工数に当たる2割の仕様を捨てるという説明もあったように記憶しています。

これと平鍋さんの説明をあわせると、無駄な開発をしないことで60％の工数が浮くだけでなく、工数のたくさんかかる8割がうまく開発しない部分に入るなら、生産性は5倍以上になる可能性があります。

この理由をスクラムで説明してみます(最近はリリースバックログもあるようですが、K. Schwaberらの「アジャイルソフトウェア開発スクラム」を元に説明します)。ユーザの要望は明確でなく時間と共に変わるものですが、それらは優先順位付けされプロダクトバックログというリストが作られます。スプリング計画ミーティングを経て、優先順位の高い要望からスプリントバックログというタスクリストに載せられ、30日間のスプリント単位でに開発されます。スプリント内では日次スクラムという朝会を実施しながら、スプリントバックログが順次実施されます。

このようにスクラムでは優先順位の高い要望から開発されますので、期間内に収まるように仕様のスコープが変更されて実施されます。スプリント開始時点で優先順位の低いものが除かれますので、使われない機能や工数の割りに効果の低い機能、早く開発してもリスクが変わらない機能の開発や、あまり効果のないテストが実施されない、などの可能性があります。

このようなことをふまえて、チケット駆動開発を整理してみました。アジャイル開発でもあるチケット駆動開発では、スクラムのバックログにあたるチケットに優先順位がつけられ、順に実施されます。その優先順位を決めるルールを「チケットオーダールール」と呼ぶことにします。

チケット駆動開発のチケットオーダールールは選択的で複合的です。プロジェクトの目的によって、生産性、リスク、品質をコントロールできますので、いずれか、あるいは、バランスを決めます。また、単純に決めるのではなく、スプリント計画ミーティングや変更管理会議(CCB：Change Control Board)、トリアージ会議などが実際のルールになるかもしれません。

チケットオーダールールによって実施されるタスクが変わります。カタログスペックを求めるなら、機能あたりの工数が少ないチケット(タスク)を優先して実施します。行数ベースの生産性を高くするなら、工数あたりの行数の多いチケットを優先すれば良いでしょう。

また、リスクの少ない開発を求めるなら、よりリスクを低減できるチケットを優先する。リリース後の不具合を減らすなら、過去のリリース後の不具合の多いテストのタスクを、総不具合数を減らすなら、現在のプロジェクトでの不具合の多いモジュールのテストを優先します。

以上のように、チケット駆動開発においてチケットの優先順位を決めるチケットオーダールールを決めることで、プロジェクトの生産性、リスク、プロダクトの品質を制御できるのです。