要求管理プロセスのポイントは要件カバレッジとトレーサビリティマトリクス
要求管理プロセスについて良い記事があったのでメモ。
【元ネタ1】
@IT:みんなが悩む要求管理(8) 最終回 要求管理ツールの賢い使い方
まず、要求をWordのような文書ソフトで管理すると、要求の属性や履歴の管理が難しく、要求間でトレーサビリティが設定できないという欠点があります。
一方、要求を表計算ソフトで管理すると、要求を文脈の中で表現することが難しく、要求間でトレーサビリティを設定するのが難しいという欠点があります。
いっそのこと、要求を管理するためにデータベースをカスタマイズしたツールを使うケースがありますが、この場合でも、要求を文脈の中で表現することが難しく、ツールの保守にコストがかかります。
ある程度、大規模なシステム開発の場合は、市販の要求管理ツールを用いた方がメリットの出るケースが多いと思います。
IBM Rational RequisiteProを使った要求管理の事例。
興味深いのは、トレーサビリティマトリクス(追跡可能性マトリクス)だ。
これは、清水吉男さんが提唱する派生開発プロセスXDDPにもあるTM(トレーサビリティマトリクス)と同じだ。
TMは、上位要件を行、下位要件を列で表示したマトリクス。
上位要件に下位要件が紐づいている場合、マトリクスのセルに印が付く。
このセルがトレーサビリティを示す。
つまり、TMで印を付ける作業が、上位要件に紐づく下位要件の過不足が無いかを確認する作業に相当する。
これこそが要件カバレッジだ。
この要件カバレッジ機能を意識して設計すれば、要件を詳細化していくプロセスで、要件漏れや設計漏れをなくして、設計プロセスの品質を高めることができる。
【元ネタ2】
テスト管理のベスト・プラクティス 要件ベースのテストを使用する
要件管理では、要件漏れ・テスト漏れがないかという要件カバレッジ、つまりMECEの観点が一番大事だ。
要件カバレッジがあるからこそ、要件からソースコードやテストケースまでのトレーサビリティが実現される。
逆に、バグが発生した場合、バグの影響範囲を要件カバレッジによって即座に見極められるので、ブロッキングバグの修正・検証工数も最終的には計算できる。
特に、後者の機能は、要件カバレッジを利用して、バグから本来の要件に遡って、バグが発生した要件に関係する要件から修正対象ソースへ追跡できるという点で重要だ。
この手法は仕様変更にも使えるからだ。
そして、要件カバレッジの機能は、手作業ではなく、ツールでサポートすべきだ。
理由は、要件が数百、テストケースが数千もある場合、もはや手作業でカバーできないから。
TestLinkの要件管理機能は現在は不十分でも、すごく潜在性を感じる理由でもある。
【元ネタ3】
@IT:みんなが悩む要求管理(7) 第7回 要求管理と変更依頼管理の違いを理解しよう
変更依頼管理プロセスと要求管理プロセスの関係の図が素晴らしい。
変更依頼管理や要求管理は最終的には、ITILの変更管理に落ち着く。
大規模プロジェクトほど、ユーザからやって来る膨大な改善要望や障害修正の要求は、一旦溜め込んで、すぐに判断しない。
要件定義や設計チームの代表者が集まった変更審査委員会(CCB:Change Control Board)が、一旦貯めた要求リストから、次バージョンで実現すべき要件を抽出し、優先順位付けしていく。
開発者は優先順位付けされた要件リストに従って開発し、テスト担当者は検証していく。
つまり、上記の計画プロセスと実装・検証プロセスは、ITILの変更管理とリリース管理にピッタリ当てはまる。
要求管理や変更依頼管理は、ITILの変更管理プロセスできちんと追跡できるように管理すべきなのだ。
また、要求を一旦溜め込んで優先順位付けするプロセスは、Scrumのスプリント計画やXPのイテレーション計画に相当する。
すなわち、プロダクトバックログにまずはユーザの要求を溜め込んでおき、どのスプリントで実装するかは保留にしておく。
スプリント計画を立てる時に、プロダクトバックログからスプリントバックログへ実現すべき要求を移す。
これが本来のマネジメント、あるいは要求管理になる。
そして、このプロセスはツールで実現されるべきだ。
大量の要求の一覧を優先順位付けして、どのバージョンでリリースされたか、追跡できるようにするには、Excelで手作業で行うのはもはや難しい。
ツールのサポート無しでは作業漏れも発生しやすい。
このインフラは、おそらくチケット駆動開発で実装できる。
つまり、BTSと要件管理機能を組み合わせれば、上記のプロセスを実装できるだろう。
ツールで要求管理をサポートする。
要求管理を含むチケット駆動開発こそが、仕様変更に強いアジャイル開発を更にパワーアップしてくれるはずだ。
| 固定リンク
「プロジェクトマネジメント」カテゴリの記事
- なぜCCPMは挫折する?経営者の理想と現場の挫折をLycheeRedmineが解決する #redmine(2026.06.30)
- 製造業DXを支える工程管理とは?Redmineの大規模プロジェクト階層化における課題:プロジェクトツリーの設定継承と関連チケット制限の壁(2026.06.27)
- Redmine × AIがプロジェクト管理を変える:祝・Redmine20周年!RedmineJapan Vol.5の司会を全うして見えた「AI連携」と「製造業マネジメント」の未来 #RedmineJapan(2026.06.27)
- プロセスには「学習のループ」が必要だ(2026.06.20)
- JTCの壁を壊す「Redmine参謀本部」という戦略~現場の職人気質を活かす組織論(2026.05.19)
「ソフトウェア工学」カテゴリの記事
- なぜCCPMは挫折する?経営者の理想と現場の挫折をLycheeRedmineが解決する #redmine(2026.06.30)
- 製造業DXを支える工程管理とは?Redmineの大規模プロジェクト階層化における課題:プロジェクトツリーの設定継承と関連チケット制限の壁(2026.06.27)
- Redmine × AIがプロジェクト管理を変える:祝・Redmine20周年!RedmineJapan Vol.5の司会を全うして見えた「AI連携」と「製造業マネジメント」の未来 #RedmineJapan(2026.06.27)
- プロセスには「学習のループ」が必要だ(2026.06.20)
- JTCの壁を壊す「Redmine参謀本部」という戦略~現場の職人気質を活かす組織論(2026.05.19)
「TestLink」カテゴリの記事
- JSTQBのテストプロセスの概念モデルを描いてみた(2023.05.26)
- TestLinkの要件管理にUSDMを適用する方法(2023.01.22)
- TestLinkのテストケースはクラスとインスタンスの考え方で区別する(2023.01.22)
- テスト管理ツールCAT、TestRail、QualityForwardのオンラインのマニュアルのリンク(2022.09.24)
- テスト管理ツールTestRail、CAT、QualityForwardの感想(2022.07.30)
「チケット駆動開発」カテゴリの記事
- なぜCCPMは挫折する?経営者の理想と現場の挫折をLycheeRedmineが解決する #redmine(2026.06.30)
- 製造業DXを支える工程管理とは?Redmineの大規模プロジェクト階層化における課題:プロジェクトツリーの設定継承と関連チケット制限の壁(2026.06.27)
- マイクロマネジメントに陥ったチケット駆動開発の罠と再生戦略 #redminet(2026.04.26)
- 第29回東京Redmine勉強会の感想~今話題のテーマはJTC運用とAIによるプロマネ作業支援 #redminet(2025.11.09)
- RedmineJapan vol.4の感想part1~Redmine AI HeplerプラグインはRedmineのナレッジ活用を強化してくれる #RedmineJapan(2025.07.31)


コメント