アジャイル開発と要件管理

　要求や要件管理に関する本「要求開発と要求管理―顧客の声を引き出すには」「成功する要求仕様 失敗する要求仕様」を読んで、アジャイル開発との関係についてメモ。

【1】IBMでは、「要求」と「要件」の言葉を意識的に使い分けていると聞いた。
「要求」とは、ユーザの生の要望。粒度が荒く、MECEでもない。
「要件」とは、SIが要求を咀嚼して、顧客が分かるレベルの要望にしたもの。

「要件」には3種類あると言う。
一つ目は、ユーザ企業の経営層の観点から見る事業要件。ビジネス要件とも言われる。
2つ目は、ユーザ企業の現場層の観点から見る業務要件。顧客の実際の業務フローのレベルに相当する。
3つ目は、システムの観点から見た機能要件。非機能要件は、性能や信頼性などに関わる要件として区別される。

我々技術者が見る要件は、システム要件に相当する。
しかし、顧客と話す場合、業務要件でなければ会話ができない。
更に、システムを売り込む時のように提案する場合、事業要件で話さなければ、経営層の心に響かない。

実際は、業務要件をまとめるのが要件定義であり、システム要件は基本設計(外部設計)の工程で行われる時もあるだろう。

【2】要件定義書を作る場合、顧客の現行業務を洗い出し、問題点を吸い上げて、解決策としてシステムを導入する点を入れる。
要件定義の作業で重要なポイントは、要件に漏れがないことだ。

問題点と要件はN対Nの関係で対応付けられるため、複雑になりがち。
MECEでなければ、要件定義書が分かりにくいし、その後の設計でも混乱の原因になってしまう。

実際の要件定義では、顧客に何度もヒヤリングしながら現行業務を理解して、問題点を洗い出していくので、要件を何度も書き直す。
そのたびに、更新漏れや依存関係の間違いが発生しやすい。

普通、要件定義書はExcelで作られるため、要件IDの項番がずれやすく間違いやすい。また、依存関係をハイパーリンクで作ってもよいが、保守が大変。
やはり要件定義は難しい作業なのだ。
要求管理ツールは、要件の依存関係と言うハイパーリンク機能を実現しているのがウリの一つだ。

最終的には、要件定義書の元ネタとなる要件は要件管理ツールで制御せざるを得ないだろうと思う。

【3】「要求開発と要求管理―顧客の声を引き出すには」では、要件の複数リリース管理で、要件にバージョンを入れる事を提案している。
つまり、1回、2回と小刻みにリリースしていく時に、要件もバージョン管理の配下において、要件の履歴や状態を管理しようとすること。

TestLinkのVer1.9betaでは、「SRS versioning」という新機能がリリースされている。
この機能の意味を僕は最初分かっていなかったが、これは、ソフトウェア要求(SRS)にリリースバージョンを導入できることを指す。

SRSをバージョン管理できる利点は、要件がリリースされているか、リリースされていないか、リリースされたならばどのバージョンに反映されているか、をすぐに判明出来ること。

特に、アジャイル開発のように小刻みにリリースしていく開発スタイルでは、これは非常に重要な機能になる。
何故なら、ストーリーカードをどのバージョンでリリースしていくか、というトリアージ(取捨選択)こそが、XPの計画ゲームであり、Scrumのスプリント計画であるからだ。

つまり、要求のバージョン管理は、リリース管理に密接に絡む重要な機能だ。
特に、アジャイル開発のように、頻繁にリリースする開発スタイルならば尚更だ。

TestLinkの要件のバージョン管理の機能の詳細を僕はよく知らないが、TestLinkの要件はテストケースと紐づけることができるため、TestLinkのテストケースが全て成功になってリリースされたら、それに紐づく要件もリリースバージョンが付与されると推測される。

要求管理ツールには、普通はリリース管理の機能として、要件のバージョン付け機能が付いているのもウリの一つ。

【4】TestLinkの要件には、要件同士をリンクする機能がある。
これは、要件の依存関係を表している。
つまり、要件定義書における要件同士のハイパーリンクと同じ機能だ。

「成功する要求仕様 失敗する要求仕様」では要件の依存関係の種類として「必須依存」「作業依存」「サブセット依存」「網羅依存」「価値依存」が紹介されている。

(以下、要求を要件とみなす)
・必須依存
　要求Bを満たして、要求Aを満たす場合。
　例えば、要求Bを削除すると、要求Aも削除される。
　依存関係の方向は、片方向と双方向の2種類がある。

・作業依存
　要求Bを実装すれば、要求Aの実装が簡単になる場合。
　要求の工数見積で重要になる。

・サブセット依存
　要求Bは要求Aの一部である場合。
　要求の親子関係に相当する。

・網羅依存
　子要求の機能の和が親要求の機能と同等になる場合。
　サブセット依存の一種。
　要求の工数見積で重要になる。

・価値依存
　要求Bを満たすことによって、要求Aのニーズが弱まる(強まる)場合。
　例えば、要求Bをリリースすると、要求Aの優先順位が下がる場合。

アジャイル開発おけるイテレーション計画やスプリント計画を作る場合、ストーリーカード同士の依存関係、ストーリーカードとタスクカードの依存関係を考えながら、ストーリーカードを取捨選択しなくてはならない。
だが、ストーリーカードの枚数が多いと、ストーリーカードが漏れたり、整合性が取れていなかったりして、リリースした後で要件漏れに気づく危険がある。

だから、XPやScrumでは、2～4週間と言う短い期間で複数回リリースする戦略を取ることによって、要件のスコープを小さくし、ストーリーカードの枚数を少なくするように制御している。

この時に、ストーリーカードの依存関係を種類できちんと区別できていれば、要件漏れの危険性はより少なくなるだろう。
特に、価値依存の場合のように、リリースによって要件の優先順位が変わってしまう場合は要注意だ。
何故なら、リリースによって、関連する要件の優先順位が下がるならば、その要件をイテレーションから外すことによって、余裕を作ることができるからだ。
できればその作業は、要求管理ツールで自動化できるとなお良いだろう。

【5】「要求開発と要求管理―顧客の声を引き出すには」にあるように、要求管理ツールでは、要件の依存関係を管理できること、更には要件のリリース管理つまりバージョン管理の2つの機能は必須だ。
その機能によって、要件からリリースモジュールまでのトレーサビリティが実現される。

要件のトレーサビリティの利点は、仕様変更によって要件を削除したり更新したりする時の影響範囲が分かること、更には影響範囲から工数見積もりを計算できることだ。

Redmineのチケットで要件管理をする場合、関連リンク機能にある「関連する」「重複する」「先行する」などを使えば、依存関係の種類を制御できるかもしれない。

要件定義と言う上流工程の作業の品質が悪ければ、いくら設計力やプログラミング力があっても、漏れた要件に気付くことはできない。
要件管理という発想をアジャイル開発に注入して、アジャイル開発を補強できないか、更に考えてみたい。