要求管理
要求管理とは、製品、システム、プロジェクトのライフサイクル全体を通じて、要求を体系的に収集、文書化、検証、優先順位付け、追跡するプロセスである。
要求管理はまず要求の抽出から始まる。インタビュー、ワークショップ、あるいは直接の観察を通じて、顧客、利用者、社内の関係者が実際に何を必要としているかを明らかにする。収集された要求はその後文書化され、矛盾がないか確認され、システムが何をすべきかを示す機能要求と、セキュリティ、性能、使いやすさといった非機能要求に分けられる。優先順位付けはその後に行われ、多くの場合MoSCoW法が使われる。これは要求をマスト、ショールド、クッド、ウォントに分類する手法である。
文書化には通常、顧客が達成したいことをまとめた要求仕様書(Lastenheft)と、それに対応する提供者側の実現方法を記述した仕様書(Pflichtenheft)が含まれる。要求トレーサビリティ・マトリクスは、個々の要求をその出所、状況、そして後で要件が満たされたことを確認するテストケースに結びつける。アジャイルなプロジェクトでは、この役割をプロダクトバックログが担うことが多く、要求はユーザーストーリーとして記録され、スプリントごとに練り上げられ提供される。
プロジェクトの途中で要求が変わる場合、正式な変更管理プロセスが動き出す。すべての変更は評価され、コストとスケジュールに照らして検討され、正式な承認を経てはじめて採用される。この手順を省くと、提供内容が予算やスケジュールの調整を伴わずに徐々に膨らんでいくスコープクリープが発生する。しっかりした要求管理があってこそ、現実的な見積もり、明確な説明責任、そして検証可能な成果が初めて可能になる。
実践例
中堅の梱包機械メーカーが新しい受注処理ソフトウェアを計画している。要求管理の一環として、プロジェクトチームは営業・生産・出荷部門の12名にインタビューを行い、84件の個別要求を収集する。MoSCoW法による優先順位付けの結果、最初のリリースには31件のマスト要件が残り、18ページの要求仕様書にまとめられる。実装の途中で請求関連の要件が変更されると、変更管理はそれをトレーサビリティ・マトリクスに記録し、関係者全員が元の要件までさかのぼれるようにする。
Leanshiftの活用方法
要求管理とKaizenは同じ根本姿勢を共有している。何かを改善する前に、実際に何が必要とされているかを正確に理解しなければならない、という姿勢である。要求を丁寧に集め、一貫して追跡することで、改善作業が症状を追いかけるのではなく、本当の目標に届くようになる。その明確さ自体もプロセス改善の一部であり、本当に重要なことを浮かび上がらせ、他者が改善を続けるための確かな土台を与える。
よくある質問
要求管理とLastenheftのような要求仕様書の違いは何か?
要求管理は継続的なプロセスであり、要求仕様書(Lastenheft)はその成果物の一つにすぎない。要求仕様書は顧客が達成したいことをまとめたものであり、対応する仕様書(Pflichtenheft)は提供者がそれをどう実現するかを記述したものである。
プロジェクトにおいて要求管理はいつ始めるべきか?
理想的には、プロジェクト自体が始まる前の、コンセプトや提案の段階である。実装が始まってから要求を明確にすると、コストのかかる手戻りやスコープクリープのリスクが高まる。
Scrumのようなアジャイルなプロジェクトでは要求管理はどう機能するか?
一度きりの文書ではなく、プロダクトバックログを通じて反復的に進む。要求はユーザーストーリーとして記録され、継続的に優先順位付けされ、スプリントごとに練り上げられ提供される。