システムアプリケーション開発・要望項目の「緊急度」のつけ方について

質問

システムアプリケーションの専門家や経験者の方に質問です。私は現在システムの追加開発を進めています。利用者の要望を一覧として挙げて、その優先度を決めようとしています。A,B,Cの3段階でつけるのですが、たとえば私が今考えているのは
A：現在暫定対処として回避している障害
B：品質向上につながるもの
C：できればあってほしい機能で、運用で十分カバーできるもの
というような位置づけです。しかし、一般的にはどのような位置づけになるのと思いますか？一般的でなくてもいいのでご意見をお願いします！

回答No.3

noname#94337 · ベストアンサー

はじめまして　jcg02524です。

専門家でも回答内容が違う可能性があります。が、自分なりに回答したいと思います。

前提なのですが「新規開発」「追加機能に関する開発」は担当する会社の力関係や要求定義の目的に依存すると思います。
※「要求定義の目的」について明確なため回答しません。

力関係とは・・・
通常の会社では「経営層」と「現場層」が存在します。
開発する上で、どちらの力が強いのかによって異なると思います。
※不具合や障害は感覚的に優先度は高いのですが新規、追加開発ではありえないと考えているため、ここでの優先度としては含めません。

【経営層が強い場合】
(1)数値化し、現状把握するためのもの
(2)会社全体の共通問題点に関する改善（品質も含む）
(3)会社が生業としている主軸の改善

【現場層が強い場合】
(1)外部要因による工程改善（国の法改定など）
(2)工程合理化
(3)あってほしい機能

最後に・・・
いくつかあげましたが、ユーザーにとっての費用対効果の高いものが本当の優先度だと思います。

回答No.5

R32C

請負で開発しているケースを想定すると、

結局、３つ項目の組合せなのかと思います。

1)ユーザーが必要(MUST)というもの、そうでないもの
2)不具合で、ユーザー側（運用）で回避できないもの、できるもの
3)対応が容易なもの、そうでないもの

3)なんて、開発側の都合って、どうかと思われるかもしれませんが、
実際、多くの不具合があって、対応に追われる場合は、この選択肢も
必要だと思っています。デスマーチなプロジェクトは、必須なのかもしれません。

2)についても、運用で回避できないなら、ユーザーがMUSTなんだけど、
さしあたって当面使わない機能だったりする場合は、優先度が下がったりしますね。

1)ユーザーがMUSTと言っていても、不具合でもなく、対応が非常に大変なものは
優先度を上げなくてもよいのですが、この辺は、顧客との協力？関係によるので
なんともいえないところです。

また、不具合が多く残っている段階での追加開発なのか、そうでないのか、
また、追加の費用をいただいて実施するのか、瑕疵責任における無償対応なのかに
よっても変わってくるかと思います。

回答No.4

noname#94337

ANo.3の修正

※経営層の順位が逆でした。

【経営層が強い場合】
(1)会社が生業としている主軸の改善
(2)会社全体の共通問題点に関する改善（品質も含む）
(3)数値化し、現状把握するためのもの

申し訳ありません。

回答No.2

Tiffa9900

自社システムの開発なのか、自信がソフトウェア会社の社員で相手が顧客なのか？によって変わると思いますが、

私なら機能の難度や既存システムへの影響度等を提示した上で、「優先順位は利用者に決定してもらう」ですね。
あえて優先順位をA～Cの3段階で考えると、納期は別に検討するとして、
A:どうしても必要なもの
　企業戦略上必要。
　法律上(会計や決算などに関連)必要。
B:コストダウンや品質ＵＰに繋がるもの
C:その他

ちなみに、あげられている3段階でAは論外だと思います。
暫定的に対応しているのであれば良いのかもしれませんが、対応してしかるべき問題ですよね。
あと、Cはシステム化する必要はないような？費用対効果を考えた上でやる・やらないを検討した方がよいかな。

回答No.1

n4330

・経営上急ぐもの
・顧客との関係で納期が決まってるもの
・利用者が急いでくれと煩いもの

私ならこれの優先順位を高くする、質問に有った例はその後でBACの順で、Aはその内にする、Cは暇になったらする。