[TiDD] チケット駆動開発におけるリスク低減法

リスクとは、以下のような定義になっています。

　　リスク＝問題の発生確率×影響

この式から考えると「リスクが高い」というのは誤用で、「リスクの問題が発生する確立が高い」あるいは「リスクが大きい」というのが、正しい表現でしょう。

従来のリスクマネージメントでは、このリスクを避けるか、貸し倒れ引当金のようにリスクをあらかじめ見込むかの方法がとられていました。近年ではリスク駆動あるいはリスクベースという考え方によって、リスクを少なくするという対処法が取られることが多くなっています。

チケット駆動開発では、チケットの優先順位に従って開発します。1日の作業や1イテレーションあるいは1スプリントなど、一定の期間で実施できる作業を優先順位に従って選択すれば、開発プロセスに関係なく、アジャイル開発の特徴と言われている「スコープの変更」が行えます。

この優先順位を決める際に単に重要度だけでなく、リスクの計算に基づいてチケットの優先順位を考えたなら、チケット駆動開発でリスクを低減することができます。さらに、リスクを考慮した上でチケットを分割すればより効果的でしょう。

具体的に考えると、早く実現したほうが良い(リスクが小さくなる)場合と、遅らせたほうが良い場合があるでしょう。

１．早めに実現した方が良い場合

基本的に、将来の方向性が決まる場合です。

- 性能や実現可能性の技術検証
- ユーザインタフェースのユーザビリティなどの不確定要素がある
- 継続する開発の見積もりに利用する
- 影響を受ける作業が多い(クリティカルパス)
- ビジネス上重要

２．後回しにした法が良い場合

後戻りが難しいものは、決定を遅らせた方が場合もあります。

- 何らかの影響により変更の可能性のある
- ビジネス上重要でない

これらを元に優先順位を考える場合、具体的な影響度を考えにくい場合もあるでしょう。そのような場合は、影響度を5段階あるいは10段階にランキングすれば、大まかな計算が可能になるでしょう。

また、チケットの分離・分割も効果的です。ある程度の規模があり、内部にお依存関係がない場合、リスクの含まれる部分と含まれない部分を分割して、ふさわしい時期に実施することが考えられます。

単純に分割できない場合も、アーキテクチャや実装を考える際にリスクのある部分を分離できるように「抽象レイヤを入れて分離する」という方法もあります。ただし、現状のリスクだけを考えると良い方法ですが、将来にわたって問題がないかを良く検討してください。

日本の契約形態では、チケット駆動開発を用いても容易にスコープを変更できない場合もあるでしょう。しかし、同じソフトウェアを開発する場合でも、実施する順番やチケットの分割を工夫すれば、少ないリスクで開発することは可能なのです。