要求マネージメント

製品を開発する際、まず要求分析をするかと思います。
しかし、それらの要求についてどの「要求」を実現するべきかという選択が、その製品（システム）の大きな分かれ道になります。
要求の選択し間違えると、ユーザのニーズを満たすことのできない不必要な機能を実現してしまい、全ての工数（開発・評価・サポート）が無駄になってしまう可能性があります。
なので、どの要求を実現すべきか（要求マネージメント）は、大変難しく重要な活動になります。

要求の定義

まず”要求”とはなんでしょうか？

求めるシステムの見た目にわかる特徴

です。見た目で分からないものは、要求仕様ではありません（バグ修正など）。
また、正当（妥当）な要求とは、以下の2点を満たす必要があります。

1. その要求が実現されていることを、システムの外側から見てわかること。
2. その要求が、システムを使うことになる顧客やステークスホルダー（利害関係者）の、何らかのニーズを満たすことに役立つこと。

要求の提案できるヒト

要求を提案し、どの要求を実現すべきか検討は「ステークホルダー」によって行われます。「ステークスホルダー」とは、以下の人たちです。

ロール	特徴
顧客	システムを購入するヒト。小売店などの販社も含みます。買う・売るための視点を持っています。
ユーザー	システムを利用するヒトです。使うための視点を持っています。
マーケティング	市場動向、将来的なニーズ、有効な機能と取り合わせ、売れ筋機能の知識を持っています。
開発	技術的観点から可能になる要求の提案、現実味の無い要求の排除、今後の要求を取り入れやすくするために特定の要求の擁護ができます。
テスター	要求がテスト可能かどうかの判定/警告ができます。
サポート	普段ユーザ対応を行っているため、ユーザーニーズへの鋭い洞察/検証ができます。
喪失者集団	要求の実現によって、権力を失う個人・組織です。リリース直前で猛反発を受ける可能性があります。彼らも含めて議論する必要があります。

各ロールでの感性を活かし、要求を導き出す必要があります。
＃一般的に、マーケティング（や企画）区と開発区だけで、要求・実現を決めてしまう組織が多いかもしれません。

要求のマネージメント

要求をマネージメントを行うために、ステークスホルダー達は以下の活動を継続的に行う必要があります。

作業	内容
1.要求の導き出し	ステークスホルダーから要求の候補を集める活動
2.要求のトリアージ*1	利用可能な開発リソース、市場投入時期、収益目標、ROIなどに照らして分析を行い、どの要求を満たすべきかを決定する活動
3.要求の仕様化	求められているシステムの外的なふるまいを文書化する活動

まとめ

ウォーターフォールやアジャイル開発の工程で「要件決め→設計/実装→評価→リリース」などで機能を作りこみますが、最初の「何を実現すべきか」の判断はとても重要です。
この判断を間違えるとニーズを満たせなかったりと以降の作業が全て無駄になってしまいます。
要求を正しくマネージメントして、確実に価値提供できるようにすることが大切です。

参考

成功する要求仕様 失敗する要求仕様

*1:トリアージ：災害などで多数の負傷者が出たときに、緊急の手当を加えれば生命が助かる見込みのある負傷者よりも、生命にはまったく危険のない負傷者を先に治療したり、医療機関に搬送（はんそう）したりすれば、助かる命も助からないという事態がおこります。このようなことがおこらないように、治療や搬送の優先順位をつけて、負傷者を分類することをトリアージといいます。