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

成功する要求仕様 失敗する要求仕様 アラン・M・デービス 萩本 順三 安井 昌男 日経BP社 2006-11-02 売り上げランキング : 2037 おすすめ平均 Amazonで詳しく見る by G-Tools

ソフトウェアの仕事をする上で、限られた時間制約の中でユーザを満足させるものを確実にリリースするには、ステークホルダーの要求をしっかりと聞き入れ、具体的なソフトウェアイメージに変換し、その要求を満たすための設計がスケジュールに与えるインパクトを検討し、間に合うかどうか、その要求を受け入れてよいかどうかを判断しなければならない。

これを本書では医学用語を用いて「要求のトリアージ」と呼んでいる。

私も仕事のなかで、トリアージをする機会は多い。

すべての要求を受け入れた場合は、製品は期日どおりにリリースすることはできない。
すべての要求を否定した場合は、その製品はユーザの求めるものではない。

その中間点ともいえる「ちょうど十分な要求」を導くための多くのメッセージが本書にはこめられている。

とくに勘違いしてしまいそうなのは 6と7 について。
文中にもしつこく書かれているのだけど、「要求への変更は善であり、悪ではない」「要求変更の流れを阻止しようとしてはいけない」というのは大切な視点だと思う。
否定を繰り返した結果、必要な要求が出てこなくなるような状態になってしまっては、もうその製品には誰も興味を持っていないのと同じで、価値がないともいえるかもしれない。

要求を受け入れることは、ソフトウェアの設計においては、負担になることが多いわけだけど、これをしなくなってしまっては、魅力のあるソフトウェアのリリースはできなくなる。

トリアージを定量的に行うことは難しいけれども、少なくともチーム内では、その判断レベルをそろえて、ステークホルダとの調整をうまくやっていきたいものである。
「ちょうど十分な要求」の先にこそ、顧客満足はあるはずなのだから。