Compartir a través de

コラム: あいまいな要求でもいいじゃないか

  • Artículo

こんにちは。 「コラム: ～」 というタイトルのものは、実は書きとめているものがいくつかあります。しかしながら、書き溜めたものをキュー待ちにして、次から次へと投稿しているわけではなく、書き溜めたものを出したり、その場のフィーリングで新規に書いて投稿したりしています。そんなわけで、つながりがあるようでなかったり、実は繋がっていたりするのですが、その辺、非常に読みにくくなっていますが、まずはご了承いただき、気分転換に読んでいただければと思います。実はコラムシリーズは、予想より多くの方々にアクセスしていただいているようです（＾＾ ということでこれからもちょくちょく書いていきたいと思います。

要求定義/開発、そして管理（Requirement Definition/Development and Management）の重要性は改めて言うこともありませんが、なかなか実践できていない現状があるのではないでしょうか。
# 要求管理ツールは購入したけど、結局・・・なんてことはないですか？（^^；
実はそんなに難しく考える必要はない（と極端ですが断言してしまう・・・）のですが、いろいろな利害関係者の絡みや契約などと直接的に関連することなどから非常にセンシティブに扱われます（ただ、うまくいかないと放置されることもしばしば。要求定義せずに設計に入ってしまうなんてこともあったりしますね）。

うまく実践できないひとつの理由として、要求を厳密に定義しようとしすぎる点が挙げられるのではないでしょうか。当然ですが、要求は契約などある一定のポイントまでに明確に定義する必要があります。あいまいな要求があってはいけないわけですね。

ただし、はじめから明確な、あいまい性の含まない要求を定義しようとするとドツボにはまります。元々あいまいでないものの方が少ないわけで、顧客とどんなにブレーンストーミングをあいまい性は残ります。あいまいだから要求を定義できない、書けないのではなく、実はあいまいであるということを書いておくべきなのです。極端な話ですが、まずは、TBD （To Be Defined） でもいいのです。「およそ～」とか、「多くの～」とか、「できるだけはやく～」などのあいまいな表現もまずは気にせずに書いてしまいましょう。

ただし、そのままではいけません。必ずいつまでにあいまい性を排除するかを決めないといけません。いつまでに誰が（顧客が、開発サイドが、第三者が）決めるものかを明確にすることで責任の所在も、契約時の条件も議論できるようになります。

あいまいな要求がどれくらいあるか、それらの量や質によりプロジェクトのリスクを測ることもできます。あいまいな要求は実はとても大きな可能性を秘めているともいえますね。

ちなみにここで使っている用語ですが・・・

Requirement: 要求

と訳してます。要求は、Request の意味で訳されることも多い（特に 変更要求: Change Request）ですが、ここで言っている要求は、要件と訳されることもある、ソフトウェアの仕様となっていく、契約上実施することが決まっているという極めてオフィシャルなものを指しています（それに対して Request はあくまでお願いごと、依頼事項の域をでていないものを指します）。

ながさわ

Comments

  • Anonymous
    May 06, 2007
    こんにちは。 GW （3連休後、2日間仕事して、4連休）は、天気がよい日が多かったので愛犬と家族で散歩に行きました。それと毎日のようにホームセンター（毎回違う店）に行き、いろいろな面白便利グッズを購入する日々でした。

  • Anonymous
    December 19, 2007
    PingBack from http://blogs.msdn.com/tomohn/pages/MSDNOFF2007.aspx

  • Anonymous
    January 24, 2008
    PingBack from http://blogs.msdn.com/tomohn/pages/MSDNOFF2007.aspx